I 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 categorized them:
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 .
So, little about common mistakes, not best solutions in Atari ST(E) games:
1: Not starting game from AUTO folder, even if it works. This is present with many STOS games - and they all can work from AUTO folder, as STOS does not use AES function calls and other functions present in AES (GEM) part of TOS. Why using AUTO folder run if game works fine with regular start from Desktop (doubleclick to starting PRG) ? For instance it is simpler, faster, works right after machine reset, and no need that user click on Desktop some file names. Plus, it uses less RAM by TOS, what may be good for some games. I did correct it in I think all my game adaptations of such cases - well that was useful to be able to do adaptation before I solved work all of AES using games from hard disk (so those which work not by simple copying all DIRs, files to some DIR of hard disk). And whole hard disk running system needs less RAM, as we need only GEMDOS part of TOS in RAM (yeah, confusing name, as GEM is not really present in that part of TOS - they just called it so as some reference to Atari with graphical environment manager , or AES ... ) . I say that instead 'GEMDOS' should use some other short name - like ASTDOS .
2: Doing code what works not well under all TOS versions. This is pretty complex, and I guess that only programmers can really understand it. Especially in beginning, so early Atari ST SW programmers wanted to make things simpler for coding, and therefore used some, well I would call it 'dirty tricks' or hacks - using some TOS (in ROM) code section, to make SW code shorter. Like direct call of some TOS code part. Or using some not documented 'system variables' . I guess that it was partially because OS changes with 8-bit computers were very rare, or not at all, during many years - was no need for updates.
Examples: GFA Artist - direct calls of code in specific section of ROM TOS, and specific TOS version - German TOS 1.00 .
As code section is on different address even on different lang. TOS 1.00 it works only with TOS 1.00 De .
Similar is with mouse code in game Tracker. What I was able to fix , so works with any TOS version, so with TOS 1.04 UK in RAM - what is what I used most for hard disk adapts. Sure, I could fix GFA Artist too, but it is not game, so maybe if some people asking for it ...
3: Also TOS version differences related: few games have errors in code part what performs TOS function calls - mostly Trap #1, Trap #13, Trap #14 . There are some rules how those TOS functions work - and here is interesting about which 68000 CPU register contents are saved during call execution and restored at end of it. Well, some games did not it properly, and it worked only because some TOS function calls in early TOS versions did not change more CPU register values (those on range D0-D3 mostly) .
Best example for it is Prince Of Persia. I needed lot of time to find exact problem . Correction self was not too hard after that.
Even disassembled game's code - really time consuming. But good part of all it was that I was able after it to do much faster DMA audio version of it (STE only, of course) .
4: More TOS version differences related: there is code for keyboard, mouse, joystick read in TOS, and of course it uses some RAM locations for variables - like pressed key code, joystick action, mouse position, and like. However, their addresses are not fixed, as is case with 'official' system variables (can find many sites, DOCs about) - I would dare to say - it is Atari's fault - even if they knew about all those peripherals and IKBD chip handling it , they just did not assign addresses for it. And really not much space is needed for it - like 40 bytes max.
The result: to spare self from writing complete not TOS code/functions using code for reading user input (kb. , mouse, joystick) many programmers gone easier way (what just needed some tracing and following it) - they went on simple reading those addresses with input related variables . And it worked well - yeah - with that specific TOS version (sure, did last couple years) . Even in different lang. versions - huh, better than direct address calls :-) Sorry, but we are in some 40 years since first TOS version releases, so not impressed with that attitude.
Sure, there is solution for this problem - use addresses for TOS version on which player running the game :-) And this was done in STOS - with partial success, as it was was at beginning for TOS 1.00 ans 1.02, later for 1.04 too (without changing STOS version number :- . Btw. I did STOS compiler v. what is good for all TOS versions (with different approach, system).
What here matters is that in case of hard disk adaptations idea of using same TOS version (in RAM) for all games means that we need to correct those addresses only once, and in game code, so no need for some special TOS v. detection, address lists (used by STOS), just to once correct those addresses in game code (well, may be simpler or not, depending how it is done by coders).
And this is maybe case in which most of games are involved. Really can not remember at moment any concrete title.
5: Very interesting case of Dungeon Master (FTL): this is probably most appreciated and among most popular games for Atari ST. Released in 1987. What is interesting here is that it is as I know only one game (sure, it's successor (or as some say 'data disk') Chaos Strikes Back ) using special RAM area, which is normally unused in case of AUTO folder start of SW .What I'm talking about ? There is some about 16 KB RAM area (in TOS 1.04, address range roughly: $6000-$A000) what is left unused in case of AUTO folder start. In usual Desktop SW start it is used for diverse functions, variables etc. FTL wanted that Dungeon Master work
with Atari STs with single sided floppy (therefore 2 level packing was used) and with 512 KB RAM machines. Just to mention: Amiga version needs min 1 MB RAM . So, all indicates that they did some extra effort and found and used that 16 KB unused RAM - and that was enough that it work with only half MB RAM . Nicest thing is that it is in balance with at game finish written life philosophy.
Considering adapting it, I did multiple versions in time - because that special RAM handling needed special measures.
And because this game uses kind of sampled audio play via PSG chip, what uses pretty much CPU time, I decided to make STE DMA audio using sound version. Sure, it needed more RAM to work (1 MB) and good audio sources (was not hard to find - PC and other versions). So, most work was with conversions and code for it. The result is better audio and little faster, smoother gameplay. And all it worked well with Chaos Strikes Back . And something 'weird' : it worked even via floppy based play - sure, not with single sided floppy :-)
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 2700 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 confuse crackers.
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.
So, 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 : idiots .
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 common 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.
Thanks for the explanation, appreciated. :)