Adapting Atari ST(E) games for running from hard disk explaining process, problems, systems, game categories ...
started with this actually in 1992 - when had first time hard disk with
my Atari ST. But most of work is done since 2007, and with big help of
Steem Debugger v 3.2 - it makes process of tracing, testing much faster
and more efficient.
So, why calling it 'adapting' ?
Because it is not 'cracking' - well may need to deactivate copy
protection, but in most cases it is not hardest part. It is not
'patching' - as many call it. Sure, there are some corrections in game
code needed, but that's only part of what all is needed to make it work
from hard disk instead floppy.
Since beginning it was
clear that what's needed to do depends in big part from game's code,
how it performs disk access and diverse common functions. So, I
Games using TOS functions for disk (file) access.
Usually they use other TOS functions too - like screen settings, RAM
allocation, etc. It means that TOS workspace must be intact - and
it is about 25-40 KB (depending from TOS v.) in case of AUTO folder run
games, or some 80-100 KB by games using GEM (AES) too. So, we
have here 2 sub categories: AUTO run ones and AES using ones (which can
also start automatically since TOS 1.04 by Application setting (saved
in DESKTOP.INF) . AUTO folder run games are most common, about 50%
of games is such. And there are some which don't use it, but could -
just authors were not aware about it - not so good knowledge,
experience with TOS .
Games using direct floppy controller chip access (with custom code) for reading/write from to floppy. Abbrev: DFC . It
has advantage that no need for TOS workspace, so that RAM area can be
used for game too. But it needs some knowledge of ST's floppy
controller chip programming. Well, actually first ST games were such,
from simple reason: TOS was not complete in 1985, so only way was DFC -
otherwise would need TOS in RAM, so much less RAM for game, and with
very early TOS, so not really reliable. In any case, at 1986 most of
games used TOS functions, and much more games were released. DFC
system is harder to adapt, and in big part because custom DFC code is
often really hard to follow and understand. And there are diverse ways
of floppy read - some games use not sectorwise read but reading whole
tracks with cpecial code - it has advantage that more data fits on
disk. And of course most of copy protections is with custom code
too. But some games use TOS function XBIOS 8 for that - easier to
crack for sure. About 1/3 of games is with DFC (well, some claim
different, but believe me - I dealt with over 1700 games, so certainly
know it). Benefit is more RAM for game, possibly faster disk access (if it is coded well) . Doing
hard disk adapt is harder - mostly because need to understand floppy
code and changing it with hard disk access one. And sometimes it is
really hard and code is strange, probably sometimes intentionally, to
Today hard disk adapt needs to work without floppy drive attached to Atari -
because lot of people have no (good working) floppy drive with his
Atari. And actually, I use mine without attached floppy 99% of time in
last 10 years. That means need to remove/deactivate all floppy
access in code, what is for sure + work compared to cracks.
from above is clear that hard disk adapt needs more work and changes
than so called crack (just deactivated copy protection).
Let see some examples, typical cases: Game
is with regular files on floppy(es), no copy protection. Some may
think that it is enough to just copy all files to some folder on hard
disk and it will work. Well, will work in some 1% of cases. Like
because: files are accessed with path: A:\FILENAME . That's easier case - can be solved by editing it to just FILENAME (relative addressing) - in executable file (*.PRG. *TOS). But
most need some changes in code because diverse things - like DIR change
... And if game is on multiple floppies there are diverse ways of
detecting which disk is inserted - sometimes really weird ways. All it
needs special corrections.
Solution number one for above
is using floppy image files in hard disk adapt, and some kind of
virtual floppy system - and it is best to use TOS in RAM for that.
What solves TOS version compatibility problems too in big part.
So, I disassembled TOS 1.04 in 2009, only it's GEMDOS part, and
used it for games starting from AUTO folder (they don't need GEM/AES
part). There were some changes in it, of course. It worked not with
floppy image files, but with game files in special DIR, where they were
accessed via hard disk driver - placed in high RAM too. So was no need
to switch back to driver what built in TOS used after power on. And
that means faster file access, no need for swapping large RAM areas (of
game and of starting TOS workspace) - yeah that's how Amiga's WHDload
works. And some 'geniuses' in Atari ST 'scene' took that concept
for their so called 'ULS' - universal loading system. I would not
even mention it here, but because they claim that I stole it's code and
used in my adapts ('patches') need to say little more here. Claim is
just nonsense. My systems in 2009-11 were pretty different . Starting
with using TOS in RAM, pretty direct hard disk access from game - so
whole concept was different. In any case I was able to do plenty
of adapts, and actually count of them was bigger than all those using
ULS , already in 2011. Partially because my systems supported TOS
function calling games, unlike so called 'ULS' - with that name it
should support all Atari ST game types, categories. All what can say :
Back to technical details: My system
with TOS and hard disk driver in high RAM was pretty good for all game
categories, except GEM/AES using games - what needs whole TOS in RAM.
So yes, I was aware that it needs to be solved once. But it needs more
disassemling of TOS code, what goes very slow - no sources available
for 1.04 . Disadvantage was work with only mine and couple
other, most popular drivers. Because work in high RAM needs some
special code, and most of drivers was not really good for it. So,
in 2012 I made my version of Whdload concept for Atari ST - using
original hard disk driver in low RAM, so swapping RAM areas when disk
access is needed. To lower count of those swaps read ahead cache is
used. Unlike ULS I used special DLL like file, called HAGA with
common functions - like HW detect, RAM config, starting game, exit,
state saves support. So, launcher of games performed calls of those
comon functions from HAGA (placed at top of ST RAM) instead having all
that code in every game launcher. Advantage is that changes, updates
will be done in HAGA file, and no need to update all game launcher
files. Yeah, so goes when someone 'steals' code :-)
State saves: Another
extra feature of my adapts. User can perform save of current game state
(position) at any time. And can play at that pos later, any time ...
Well, it needs adding special changes in game code for
intercepting those keyboard presses - there is another, for exit to
Desktop too. This stays for games not using TOS functions for
keyboard, mouse, joystick read. TOS function calling games
use in some 50% of cases TOS input read. So, I just added special
short code to TOS in RAM for that - and then no need to bother with
code change. Need only to give keyboard codes for state save and exit
to Desktop - usually they are slash and * on NumPad.
Further HAGA development: Finally,
in 2018 I went on disassembling AES/GEM part of TOS too, and it
made possible to have whole TOS in RAM, for such games (examples:
BREACH, chess games ....) . I called it HAGE (hard disk
gaming for AES games) . And it works with ST floppy image files, what
is better than work with some DIR . ST image files can be up to 4 MB
size (FAT12 limit), so can put there content of multiple floppies. But
can even go on using FAT 16 for those images, so no real size limit .
It was so good that I made HAG2 - what is actually GEMDOS part of TOS
only in RAM (for AUTO start games), but using ST image files.
What to say - process of adapting with HAGE and HAG2 is easier and
faster in most cases. In 5 years made hundreds of adapts with them.
There is special page about latest development in 2023. You came here probably from it.
there are diverse extra goodies, like screenshots from games, game's
cover (box) scan conversions (hi-color, so more than 16 colors at once
on screen), and something what others did not: special image with all
adapts, with optimized driver, game start menu program what can display
game and cover pictures, some game data - like game type/category,
video mode (C(olor) and/or B(W), usable controls ). Some games
are in multiple versions, that's why number 1902 is shown . And
there are some improvements done for some games - like extra audio file
play during play (STE only), better scroll, controls - OIDS, Uridium,
Great Giana Sisters ....
Just finished hard disk adapt of less known game Lords of Doom (similar to Dungeon Master). Graphic is very good, no character selection at start, and I can not say about game play for now.
The reason why mention it here is that it was one of hardest cases to
solve redirection of floppy code to hard disk. Game's custom FDC code
is really weird, strange and must say: not efficient. Needed 3 days to
make it work. And it is on 2 places - with some differences,
without real need. All it could be done with same code. And to
add that ingame saves of gameplay have again own floppy code - it using
XBIOS 8/9 actually. Really strange. I did not bother with it - even if
it would be easy to solve - because no need for using ingame
saves/loads. HAGA state saves are simpler and faster to use. To add that game uses some TOS functions too. For instance for screen settinga, and even for reading mouse and keyboard. But
not GEMDOS filesystem - most likely to have more RAM for game. So,
solving keyboard read for state saves and exit to Desktop was different
than usual. And I did English and German versions. Don't see
Eng. v. at atarimania. They are same except textual messages.