Hacks

This is under construction.

Generally about gaming from hard disks on Atari ST and compatibles:

This is not something special - using modern storage with old micros is 'in' in last decade. Spreading of Flash storage medias as Compact Flash and SD cards just uplifted it. So, we have now diverse interfaces for all popular old micros. Myself designed first 8-bit IDE IF for Sinclair Spectrum, some Atari ST hard disk interfaces and later CF version of 8-bit IF. With Atari ST serial Satandisk and UltraSatan are most popular. While US is not too cheap, cards are - you can buy for 10 Euros 4GB SD or CF card. Enough for all Atari ST games, believe me.

But above is just theory - most of games will not work from your SD card. Well, situation is actually better: most of quality games WILL work - because they are already fixed (adapted, patched) for running from some hard disk.

Whole gaming from hard disk issue is pretty complex matter, and I will try to give here some clues, for people interested about more than just "is it work on my Atari" .

Why it is so complicated on Atari ST, TT, Falcon ?

Because most of games were coded for working from floppies only. Because of changes in TOS versions, bad coding and even bugs in games etc. TT, Falcon is special problem: they are not 100% compatible - CPU is main difference, but there are others too.

Little statistic: about 67 % of Atari ST games use TOS calls for disk access and rest 33% use own code for as said floppy only access. Some people claimed different ratio, but what I wrote is based on examining about 600 games.

We could expect that by TOS calling games we can simple copy all files on hard disk and run them. It works in couple % only. Even after removing all copy protections. Usual reasons are: files are prefixed with A:\ or similar. Code is not relocatible in RAM, and will crash if there is hard disk driver (or just higher TOS version, taking more low RAM) . So, we need to do some measures. It can be changing gamecode self - what is hardest and slowest way. Better is to give same environment to game, as it is when runs from floppy. It includes freeing low RAM for game, assign hard disk partitions to logical A, etc. Floppy Image Runner is SW what can install floppy image (ST, MSA) as RAMdisk assigned to A, so many games will then run from hard disk. But it is not good for multifloppy games.

I developed more advanced solution, called GOS. It is actually TOS 1.04 core, modded and reassembled so that can run in High RAM, with hard disk driver also in High RAM. It solves RAM conflict and TOS compatibility problems. There is Falcon, TT version of it. Only real flaw is that no support of 1GB Falcon partitions, as TOS 1.04 can max 512MB.

So much about TOS calling games. Games with direct floppy access need more work in most of cases. Work from hard disk is possible only by changes in gamecode. It may be relative easy, but may be pretty hard - I saw a lot of very strange, inefficient, overcomplicated floppy loaders. Then, copy protections, checksums make it even harder. And we have RAM conflict too. TOS has hardcoded workspace for lowest RAM space - it is about 40KB, but higher TOS versions take more. To achieve disk access during gameplay we need to resolve RAM conflict and some other problems as interrupts, MFP etc. I will not go here in more details and all possible solutions. All what can say is that there are more ways. Every has its goods and bads. More can read at - http://forum.8bitchip.info FAQ section.

Development is not finished: I working currently on HAGA (HArddisk Gaming Atari). The goal is to give solution for most of people, configurations. In way somekind similar to WHDLoad - by using few library files for common functions (by WHDLaad it is Master). I started with it already by GOS. The benefits are smaller launchers, easier to code, and easier update - you need only to replace 1 file in libDIR. So far, you can play Space Ace, Dragon's Lair serial on your ST(E), Mega ST(E), TT, Falcon, with any decent hard disk driver, 1GB Falcon partitions too. With fast loadings, even with only 1MB RAM.

We are most likely in last decade of using old Atari machines. They will stop working gradually. Or become unreliable (2 of my Ataris are already such). And we can not do much against. So, enjoy until can, and try to learn little while...

One of frequent questions is about porting WHDLoad (Amiga) for Atari ST serial: Considering WHDLoad porting for Atari ST and compatibles: I don't think that we can do it 100% . 2 machines are different. CPU is same, but many things differ. Amiga has no filesystem driver ( what handles hard disk file access too ) in ROM, as ST serial has. There may be other differences related with OS calls used by games, and how games are sensitive on TOS versions (Amiga OS versions), I really don't know much about Amiga. Then, WHDLOad is based on Master-Slave concept, where Master is some kind of function library for common tasks, what slaves (for every game special one) must call. Master is not free by Amiga. I don't think that anyone here wants commercial WHDLoad equ. for Ataris :-) But Master-Slave concept seems as very practical for me, especially as I already did someething similar with functions in later GOS versions - GOS5 handles hard disk access, reinstalling of hard disk drivers in High RAM and init of TOS 1.04 core in High RAM. I go now further, and make HAGA, what will have much more library functions, and diverse ways for accessing files from hard disk, during gameplay. Basically, it will be same Master-Slave concept, but I don't like to call it so. Game launcher will call library functions, lets say like that.

But loading files during gameplay is just part of problem. We have a lot of TOS function calling games (2/3). This is what needs support too. And we can not take something from WHDLoad for that.

Instead thinking about ULS port (what is ported in some extent, yes) we need to make solutions specific for Atari needs. To achieve that all games, or at least all good games can be run from hard drives. First step in it is understanding the problems, reasons why some game works not etc.

I did categorisation of games by way how it can be fixed for hard disk run:

1. The simplest case : just copy all files to some DIR on hard disk and play. There is only few such - like Knights of Sky (but only latest edition), most of Sierra games ... Here belong games with included hard disk installer too. However, it may not work on some configs, often can install only on specific partition, folder. And because of copy protection original must be in A . Then, here may belong some cracks too - where load is with only relative path. Beacuse of RAM allocation problems, game must be coded so, that can run at any RAM loc. Otherwise will fail on higher TOS versions and hard disk drivers taking more RAM (buffers). I did not make some statistic for it, but guess that only some 20% of games is coded to run at any RAM loc. Finally, even if all above conditions are fullfilled, game may fail on Falcon, TT . Usually because: stackframe problem, some writings in video registers, bad code, often sensitive on TOS version - (Prince of Persia) , then even some bugs, which appear only on TT mostly , etc.

2: Singlepart game (or singleparteable) : after start no more disk access. So, we don't need to care about hard disk access. Only need to load all to proper RAM pos, set needed things for start and jump ... If game uses not TOS calls it works pretty well in almost all cases (except possible Falcon, TT problems - see above) . If such game uses TOS calls, we may be in trouble, especially if is not relocatible (runnable at any RAM loc) . It is long story, and I can not go here in all details. What is important is that problem can not be solved without : A: making game relocatible (too much work, almost impossible) . B: having some lover TOS version in RAM , what will then work with game occupying RAM area conflicting with higher TOS versions workspace. Or at least having all by game needed TOS functions in RAM - this is what Klapauzius did.

3: Multipart games - which accessing disk during gameplay - usually to load some new stage or similar. Here we have 2 main sub categories : Games using TOS calls, so accessing disk via them too, and games not using TOS calls for floppy access (there is no game which accessing hard disk with own code, normally) .

3A : Knighs of Skies belong here. And hard disk access works well. But most is not such, and we can have several diverse problems - like file access with absolute path A: , low RAM conflict, Timer C problem with some hard disk drivers, TOS incompatibility problems etc. Even mentioning all is too long. But everything can be fixed. Worst problem is low RAM conflict, and happens if game is not relocatible.

3B: Direct floppy access, multifloppy games with it. As already said in first post here, some changes ic gamecode must be done, to redirect floppy calls to hard disk calls. It is the hardest part in most cases - understanding how loader works without sources may be time consuming. Fortunately, there are some common systems used, and for instance all games by UbiSoft where Markus Fritz did floppy part have prectically same floppy code. And of course, all mentioned above about TT, Falcon specific problems stays here too.

I will not go in further details about all possible situations.

The solutions:

First used was RAMdisk. And is still in use, although mostly from speed reasons. It is in fact very practical, fast and reliable + simple solution. Drawback is need for RAM, what may be lot by multifloppy games. So, loading from hard disk during gameplay must be solved somehow. First who did it by Atari ST is crew Superior, some 20 years ago. It was FFLS driver. Little outdated, as works only with ACSI and max 32 MB partitions.

Continuing about solutions for case 3B (hard disk access by games which 'killing' TOS : ULS is another solution - based on swapping low RAM area content when disk access from game is requested. Then game content goes in High RAM, before start saved TOS workspace, CPU vectors etc. + hard disk driver go low. After finishing disk access all mentioned must be swapped back - so game low, TOS WS++ high . It is good concept considering compatibility with hard disk drivers. But may be slow in case of many short disk accessings, so WHDLoad recommends to use always RAMdisk if there is space for it. And by Atari patches is so too . GOS is my solution, similar to FFLS, but it can write to hard disk too, working with all hard disk types via installed drivers etc. Only real drawback is not suporting 1GB Falcon partitions. New development by me is HAGA - RAM area swap concept too, but with some improvements as using PMMU on TT, Falcon, library files with functions etc. Will take couple months to finish it.

So much about hard disk access by TOS 'killing games' .

And I think that here finishes whole idea about porting WHDLoad to Atari ST : Because now come Atari ST specific problems, mostly TOS related :

Example for start: there is game Millennium 2.2, using TOS calls, mouse. It even can not be started from AUTO, because then no mouse available. But is not relocatible, and placed to very low RAM (around $13000) . Conflict with some higher TOS v., hard disk driver is inevitable. There is alleged hard disk fixed version in Atari ST Gamebase. But it works only under emulators, GEMDOS hard disk emulation, which takes no RAM for hard disk drivers. So, it is not really hard disk fixed. To achieve work of Millennium 2.2 on real Atari with hard disk driver installed we need to solve RAM conflict somehow . My first working solution was Hole - tricky solution what moved hard disk driver in high RAM . But it solves not problems by higher TOS versions (Falcon, TT) . Even if you achieve somehow that game works, and disk access is good, likely will be unable to name space ships - as it uses some TOS calls, which fail because RAM conflict.

Good solution for this case is TOS in high RAM, hard disk driver in high RAM . Then no RAM conflict, and game will work well . This is what GOS (Gaming OS) makes possible. And there is a lot of games where it is required. Basically, GOS is disassembled, modded TOS 1.04 GEMDOS part, for work in High RAM. And it solves other things too, as TOS version problems with badly coded games (Prince of Persia) . As it is TOS 1.04, there is 512MB partition limit - only real flaw, as already stated.

To resolve that GOS work with 1GB Falcon partitions, we need to use 2 things at once : GOS self, so GEMDOS in High RAM , + RAM swapping technique, fortunately working very fast on Falcon - and it will not cost us extra RAM, as TOS is already saved in purpose of Desktop exit. This is next step in HAGA development.

Thanx for your patience ;-)

http://atari.8bitchip.info/fromhd.php

There are games fixed for hard disk running, but you may find more explanations, and even some sources related (in ASM) .