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.
  Converting ? Sure, some think that it is something possible to do with some SW what does converting - I must disappoint - no such SW, and will be not in next 1000 years. Things are wery complicated, and ways of programming are very diverse. Plus, TOS is not simple, diverse versions are done and some of worse problems is when game works not (well) under all TOS versions. Must say that culprits are game programmers in most cases, but we can blame Atari too - for not making enough detailed DOCs for TOS, and for not making all details future proof (like TOS start address - for instance).

  Special things needed too.
 There is plenty of quality games which are well programmed, designed, but starting of them is not so well done, then they may use more RAM than needed - usually because not using AUTO folder automatic start for games which can work that way - for instance all STOS games. And same stays for SEUCK games, plus starting is not so simple as it can be. I guess that people with programming talent did not care much about learning, experiencing details of TOS, Desktop .
 So, I made lot of new floppy images of lot of games, with more user friendly approach, with fixed some errors, what includes removing of pyrate messages too. And those floppy images are in most of cases good for running from hard disk (now rather SD cards) as my later systems of game adapting work with ST floppy images in most cases.

 Then, lot of games (mostly freeware) are available in images of floppies where are multiple games, often packed and sometimes not directly runnable - need some further steps. So is at Atarimania, which is biggest source of Atari ST SW image files. 99.9% of it is not copy protected now, and there are some games, SW old 40 years now.  So, I do separating of games and putting only 1 game in 1 image file (except cases when games were made to be together on floppy(es) compil). That makes usage simpler. Unpacking packed files in most cases and writing so them to image file(s) - because unpacking during game start, run is often pretty slow .
 And now storage is cheap and high capacity, so packing is not useful . I use it very rare, with my unpacker what is very fast, when it makes things better usable. All it may need some extra time, as there are some not well supported packers - SPV3 for instance - none of know depacker SW handles it well, so I needed to do depacking using Steem Debugger tracing, and that needs some extra time. Luckily need to do it only once and save things unpacked.

 

  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 .

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 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 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.

 Then, 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.





    PP, June 2023 - Aug. 2026 .