Game hard disk adaptations - little history, diverse systems

[Petari]

I started with it actually very long time ago - in 1992. Then made couple games to work from hard disk. After I made IDE adapter, and used some 60 MB 2.5 inch drive, with my ST expanded to 2.5 MB, with optional TOS 2.06 - only it had then IDE autoboot support.
It were simpler cases, mostly just copying all game files to some DIR on hard disk and start is usual way. Maybe some simpler corrections of path.

Renewed interest for games from hard disk with Atari ST family started about 2008, and important factor in it was Steem Debugger (v 3.2) - with it tracing game code and other things, testings were/is pretty efficient and that made whole process faster. Of course, testing it on real Atari HW is always necessary, if possible with multiple platforms, so STs, STEs, Falcon, TT .
Easiest is to make single file (so some *.PRG or *.TOS file only) to work from hard disk. But it is not always just to copy it to some DIR on hard disk, or from right about at 2005-2008 - Flash Card. And first Flash cards were CF cards, SD cards came little later. So, good for IDE adapters (well, mostly Sandisk brand). Capacities were not so big - first one I bought was 128 MB. Pretty good for Atari ST.
Important part of this 'business' is categorization of games by how they access data on disks, do use TOS functions - for disk access and other things. Because that determines what system can use to make it work from hard disk instead floppy(es).
Page about: Category list
Since most is with using TOS calls, functions it was natural to go on solution with running one specific TOS version in RAM - that solves TOS compatibility problems, disk access and other things.
Choice was of course TOS 1.04 - and it can work with Falcon and TT too, with some corrections - mostly stackframe related.  So, in 2009 in disassembled TOS 1.04 (UK v.), and only GEMDOS part it - not GEM, Desktop part. Because plenty of games starts from AUTO folder - what is before GEM init. Or from floppy bootsector - also before ...  That took plenty of time. But was worth.
Disk access via TOS 1.04 in RAM: that's very important part. If game uses usual trap #1 file access, it does not need changes in code, maybe filenames/path part. Just placing game files in game's DIR on hard disk, and accessing them from there - game will see it as access from A: . Of course it was possible with couple smaller modifications of TOS in RAM, in further text GOS (gaming OS) .
It solves also following case:  there are games which code is not relocatible, and are coded to run from low RAM area. But that is normally occupied with hard disk driver. So, conflict. GOS solves it too, as it clears low RAM, and 'boots' or AUTO runs game .
Games without regular files: it is called direct floppy controller access - game does not use TOS calls, usually any, not only disk related. That has advantage of more RAM for game. But solving running of such from hard disk is harder - it needs good ASM knowledge, floppy controller (WD1772) commands, etc. Need to trance code of game, find floppy access parts, understand how it works, and then change to code what accessing floppy image on hard disk - it's specific section, like some sectors on floppy.
And GOS helps in it too. My solution was unique:  there is even shorter GEMDOS part of TOS, mostly disk related, filesystem related, FAT16 code - for accessing specific part of image file. But it needs to 'boot' hard disk driver for that OS in RAM. And that's not so simple, and it supports only mine hard disk driver, HDdriver and AHDI . Surely, they were used most. In case of my driver it wast just copy of driver core to high RAM, set couple vectors - condition for it is fully relocatible code.
Advantages:  fast and direct hard disk access, without longer periods for RAM swap.
Disadvantage: work with limited number of hard disk driver SW .
I made hundreds of game adapts with that system, what called GAMEX - there was added code for simple exit to Desktop from game, and state saves . Those functions need some extra RAM, but it was there anyway - most of games working with 512 KB RAM from floppies needs 1 MB min for even simple hard disk run (driver takes some RAM, and that's usually enough to now work with only 512 KB).
At the end of 2011 started work on new system, called HAGA - hard disk gaming Atari. Idea was that it work with all decent hard disk driver SW, and to add some new features.
To be continued ...

[Petari]

HAGA concept is same as what WHDload for Amiga uses:  saving OS workspace before game start in high RAM, together with state of HW - including screen, MFP, etc. Then low RAM will be free for game. When some disk access is needed low RAM (what usually contain game's RAM too, whole or just part of it) needs to be saved, and of course HW state in that moment, then OS state must be restored - so basically RAM content swap to do. Then perform disk access via hard disk driver what is active when OS works. When it is done, must do another RAM content swap, HW state restore ...  RAM content swap is what may need some time - depends from size, hard disk speed - may take some seconds, and meanwhile game is frozen.
And that's the disadvantage of that system. And again, it is easier with not TOS functions calling games.
I released first games with HAGA system in Jan of 2012. State saves and TOS calling game full support came little later. Still, it was only for games not using GEM/AES .
To make less pauses by disk access there is read ahead cache containing game files or image of floppy(es), so if required data is in cache, it is simple RAM read, and no need for those RAM swaps. More RAM in Atari - less real disk access.
Did plenty of games with HAGA system. But not all worked with it - mostly TOS calling games. Because of game files access, what was some kind of RAMdisk, with own simple file handling. To be more compatible with sometimes weird game code I used sometimes ST floppy images (of game) and special RWABS like access to it, + XBIOS 8 disk read (based on geometry) .
And about 2018 came time to do full TOS in RAM support - so not only GEMDOS part, but complete, with GEM/AES and even Desktop. That needed disassembling of that part of TOS too - done when dealt with improved TOS.  And I used diverse optimizations, so that TOS in RAM took less than 192 KB . system is called HAGE (E is for AES) . And that was good for games using GEM . Like Breach . And was useful for those who used some AES calls, without real need, but so was simpler for coders, or they just were not aware that can solve those things - like mouse read with functions in GEMDOS . Earlier I changed some games code - replaced Trap #2 $C8 calls with Trap #2 $73 calls (this was for Atari ST programmers).
HAGE works only with ST floppy images. Which can be much bigger capacity than real floppies. Good for put all files of multifloppy games in 1 image.  And yes, AES calling games are always with regular files.

And for the end the bragging part:  it is only me who dealt with so big support for TOS calling games - Klapauzius developed some limited support, having code for some most used TOS calls (trap #1), so solved hard disk 'patching' of some nice games. While 'great' D-bug, CJ did not care for such games. They cared only to give name 'universal' to their system. But what else expect from them ?
I can say that I have now systems, libraries for all types of Atari ST family games. Can solve hard disk adaptations of them, together with state saves. Yeah, number 1600 is not only result of lot of time spent with adapting games, but developing supporting code, TOS in RAM (with some changes), and like. And those things made possible to do adaptations for concrete games often in much shorter time than without them.