HAGA is abbrev. of 'Hard disk Gaming Atari' . After some years of
experience with this, I felt that it is time to make new system, which
will work for all people with regular Atari machines in range 1040
ST up to Falcon . With all decent hard disk drivers, 1GB
Falcon partitions etc. No plans to support running games from Mint,
Magic, for running on CT6x and other accelerators, add-ons. Very likely
it will
not work well on them, so turn off if possible, or use another machine,
emulator.
Features:
- Most of games will work with 1MB RAM min.
- Fast loadings - with more RAM and 68030
even faster
- Support for all game categories:
TOS calling and TOS
killing ones, those running at low RAM and using TOS calls.
- TOS version incompatibility problems
solved by using modded TOS
1.04 in high RAM
- Solutions for specific game bugs (yes,
they exist) , like
24-bit bus mode for TT .
- Work with any decent hard disk driver
(correct PUN info),
1GB Falcon partitions.
- Exit to Desktop, gamestate savings. Later
with
autoincrementing filenames, up to 100 saves. Very easy and fast
restoring of game pos, because savestates are TOS executables. Adding
comments in savestate files possible.
- Showing
file number during saving state.
- Optional autosave by pressing Desktop exit key - for
case of accidental key press, or those who like it.
- Support for configs with lot of RAM occupied - max
some 1600KB on Falcon, 4MB machines. However, expect problems
with diverse third party disk caches and similar - they should be
avoided.
- 'Smooth loading' support - only with latest my hard
disk drivers. Even without caches, RAMdisk, fluid load without sound
interrupts and screen flashes, color changes. See video below.
- Work from floppy too. At least those which fit on 1
floppy. If space is tight you may drop PCH image. And of course work
from HxC floppy emulator. Then more space available - as it supports
some high density formats not possible with real floppies. For more
details: drop me mail, or ask in forum.
Gamestate savefiles (snapshots): they hold all
data needed to restore complete game and machine state to same as it
was in moment of pressing key for it. Size of files depends from game's
RAM usage. Typically it is 513KB for games running from floppies on
512KB ST machines. Of course, you may run savestates only in
game's directory, because it uses files there.
Running savestates on
different machine than on which were recorded: it is possible,
except running on different base machine. So, snapshot done on Falcon
will not work on ST or versus. Snapshot made on STE may work on ST,
except few cases. It could be done, but is too complicated by some
games, and I don't see that there is interest for it. What is
interchangeable for sure: snapshot made on ST with some hard disk
will work on another ST, with different RAM size, different hard disk,
driver. It will work on Steem, Hatari too.
Falcon, TT specific: there is included a lot of
support for making this machines as much as possible ST(E) compatible -
like CPU speed, cache settings, bus settings - for instance 24-bit bus
emul. for TT. Still, there are cases when game code must be corrected
at some places - like stackframe dependant ones. Then, we have other
problems - not 100% compatible video registers, timing, CPU pipeline
related etc. All in all, in some cases making game to work on Falcon,
TT may be pretty time consuming.
For now, only running from ST compatible resolutions is supported. You
may start from some other, but exit to Desktop will be not OK. I
do not plan support for non-ST resolution start. Partially because we
have some nice games working in ST high res (too) . It means that if
you start from ST low or ST med mode, it will run in color. If start
from ST monochrome mode it will run in mono, 640x400 mode. All it on
same (VGA) monitor !
Currently this is under development, and not much games are
done with HAGA. I expect that in max 2-3 months it will be finished,
and lot of games will use it.
Significant progress is made in first month. Check adaptation DL page
for new releases.
Some technical details, in deeper look:
There is number of specific tasks needed by hard disk running of
old, floppy games. Like HW test, config, installing modded TOS in RAM,
Desktop Exit, saving gamestates etc. So, idea of library file,
containing code and data for them is normal. It helps to have shorter
launcher and statesave files, easier making of launchers, and easier
updating. + saves space on hard disks - such files are called often
shared files. Placing them in specific path allows that we need HAGA
and other library files only in 1-1 copy on whole hard disk, for
many-many games.
Depending on used hard disk
driver, available RAM, CPU there are diverse ways of accessing
data on hard disk. Main problem by hard disk access is RAM conflict.
TOS workspace, hard disk drivers are tied to lower RAM area. But most
of games too. To resolve this, we can place modded TOS and hard disk
driver in High RAM, but it is not simple, especially with usual hard
disk drivers, which are not relocatible. But that way is the
fastest. Another way is to swap by every disk access request of
game low RAM area, where game is with high RAM
area, where TOS and hard disk driver are saved before game start, and
swap back both after finished disk access. + need to deal with MFP,
interrupts, etc. All it may be time consuming, and slow in case of
accessing many short data chunks, files. Fortunately, by TT and Falcon
we can use PMMU for very fast virtual RAM area swap - in
microseconds. Similar is not possible on ST(E), only with HW
add-on, which can swap RAM areas if placed between MMU chip and RAM.
So, only for electronics.
Smooth loading: TOS killing games use own code for floppy access.
While doing it may play music, updating screen palette
(many
games have more than 16 colors at once on screen thanx to changing
palette at concrete screen position). It is beause floppy operates via
DMA chip. But by usual hard disk access from such games, we need
to activate TOS and hard disk drivers, what requires disabling all
game's interrupts, MFP usage etc. So, by disk access music will stop,
screen may flash,, flicker. And if it is combined with slow RAM
swapping it may be not nice.
Good solution against it is usage of RAMdisk. But it is not always
avaliable, especially on 1MB machines.
Still, 'nice loading' is possible, even with little RAM - if we have
special hard disk driver, which is not MFP timer dependant, is
relocatible (latest version uses PP hard disk driver and buffers in TOS
save space - 40KB RAM saved !) , + specially
modded TOS, which can run in High RAM, and it's workspace is in high
RAM too. + some tricks with interrupts, MFP. Then may perform
hard disk access without stopping game's interrupts responsible for
music playback control and colors on screen. So, will have nice
loadings even with 1MB machines. See video below. All it needs
careful design of hard disk driver, modded TOS + some special care with
games - must disable all DMA chip accessings for instance.
Video above shows 2 loading ways. Difference is best visible
by loadings right before start of play. Pos. 37sec-43 sec is loading
with RAMswap and system suitable for any hard disk driver. Pos.
1m51sec-1m56sec is with special hard disk driver, which allows game
interrupts to work normally. Not much faster (except in case of
many short loadings), but no flashes and audio freezes.
RAM
usage, layout for different configs, max allocated RAM sizes:
With my older system
one of problems for many people was need to decrease allocated RAM -
because it was made for economic RAM usage.
HAGA is more flexible in this, and here is detailed RAM usage
description, and max allocated RAM sizes for diverse configs:
Usual way in this is to fill RAM from top towards bottom (while TOS
does exactly opposite, as is known). So, we will have more-less
workspace in middle of RAM. What is used for launcher self, RAMdisks,
caches etc.
By HAGA it is little more complicated, because 68030 PMMU swapping
system, where pages can not be at any RAM pos.
1040 ST(E):
Game: 512KB
Workspace: 200KB or 290KB if no GOS used. Usually used for read-ahead
cache - faster loadings.
GOS4 or 5: 90KB
TOS save: max ~180KB - Enough for TOS 2.06 and hard disk
driver using 60KB . Of course no ACCs etc.
HAGA: top 32KB .
Total 1MB .
Max allocated RAM by hard disk driver and
other is about 70KB - with T2.06. Little more by older TOS versions.
ST(E) with 2MB (or 2.5), 512KB games
Game: 512KB
Workspace: Up to 400KB. Usually used for read-ahead cache - faster
loadings.
GOS4 or 5: 90KB
TOS save: max 512KB.
HAGA: top 32KB .
Total 2MB .
Max allocated RAM by hard disk driver and
other is about 300KB .
ST(E)
with 2MB (or 2.5), 1MB games
Game: 1024KB
Workspace: Up to 200KB. Usually used for read-ahead cache - faster
loadings.
GOS4 or 5: 90KB
TOS save: max ~300KB .
HAGA: top 32KB .
Total 2MB .
Max allocated RAM by hard disk driver and
other is about 180KB .
TT
with 2MB ST RAM, 512KB games
Game: 512KB
Workspace: Up to 370KB + opt. 512KB.
Usually used for read-ahead cache - faster loadings.
GOS4 or 5: 90KB
TOS save: 512KB - always at 1MB-1.5MB space.
HAGA: top 32KB .
Total 2MB .
Max allocated RAM by hard disk driver and
other is about 800KB .
TT
with 2MB ST RAM, 1MB games - not supported currently
ST(E)
with 4MB, 512K games
Game: 512KB
Workspace: Up to ~2300KB. Usually used for read-ahead cache - faster
loadings.
GOS4 or 5: 90KB
TOS save: max 512KB .
HAGA: top 32KB .
Total 4MB .
Max allocated RAM by hard disk driver and
other is about 1400KB .
ST(E)
with 4MB, 1MB games
Game: 1024KB
Workspace: Up to ~1800KB. Usually used for read-ahead cache - faster
loadings.
GOS4 or 5: 90KB
TOS save: max 1024KB .
HAGA: top 32KB .
Total 4MB .
Max allocated RAM by hard disk driver and
other is about 1400KB .
TT,
Falcon with 4MB+, 512K or 1MB games
Game: 512KB-1MB
Workspace: Up to ~950KB. Usually used for read-ahead cache - faster
loadings.
GOS4 or 5: 90KB
TOS save: 1MB. Always
at 2MB-3MB space.
HAGA: top 32KB .
Total 4MB .
Max allocated RAM by hard disk driver and
other is about 1300KB .
As is visible, there are
several schemas. People with 4MB machines should have no problems at
all.
I don't know about 2MB TT users - likely not much of them playing
games, so support is only for 512K games currently. 2MB ST(E) owners
should have no problems too - assuming that hard disk driver installers
will not set much RAM usage, and users will not install RAM eating ACCs
and similar.
1MB machines can run only 512KB games (it means games running from
floppy on 512KB machines) from hard disks, of course. And must take
care about low RAM usage by drivers. Only minimal resident SW allowed.
P. Putnik, Jan- Febr. 2012.
|