- Welcome to 8BitChip Forum.
Recent posts
#1
Software / Chip's Challenge
Last post by èné - 02-02-2026, 04:17:05The st version is faulty, some levels cannot be finished. i tested all 144 levels (actually 148 with the 'extra' levels) nd 5-6 are corrupted. Whenever it happened (bug or unplayable because of a faulty code) i had no other choice but restarting the game, and access the next lewel through the cheat-codes. This game has far too many levels anyway (though it really is enjoyable, but too much is just too much). Note that i didn't play with your version this time but i did run it to make sure and it's the same (ie missing elements or not responding the way thery are supposed to). There is one level though where your version makes a real difference: with mine, level 148th is unplayable while all plays fine with yours - But that's pretty all (i don't care about 148th cause it is just an 'extra' 
).
On a side note, the st & amiga versions have about 15 levels which are differents compared to the others versions (go figure) but these actually are just 'reversed levels' (with the starting point located somewhere else however the levels remain exactly the same) while the others versions (even the 8 bits ones for that matter) were granted with 15 originals levels (new puzzle, levels design..). No idea why but that's plain fact. Last, the amiga version has exactly the same issue than the st one (no wonder since the levels are identicals).
).On a side note, the st & amiga versions have about 15 levels which are differents compared to the others versions (go figure) but these actually are just 'reversed levels' (with the starting point located somewhere else however the levels remain exactly the same) while the others versions (even the 8 bits ones for that matter) were granted with 15 originals levels (new puzzle, levels design..). No idea why but that's plain fact. Last, the amiga version has exactly the same issue than the st one (no wonder since the levels are identicals).
#2
FAQ / Re: Adapting Atari ST(E) game...
Last post by Ronald J. Hall - 01-02-2026, 03:05:49Thanks for the explanation, appreciated. 
#3
FAQ / Adapting Atari ST(E) games fo...
Last post by Petari - 30-01-2026, 20:57:35 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.
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.
#4
FAQ / Re: Finally some intelligent t...
Last post by Petari - 27-01-2026, 09:26:08 I waited little with buying my next home computer after Sinclair Spectrum. And decided to buy Atari ST or then new Amiga 500 - April 1987 . Prices were pretty similar - about 1200 DEM for 512 KB RAM and 2 sided floppy drive. What was not similar was available SW for machine - was much more for Atari ST . And there was Atari ST Profibuch - pretty useful for programming, HW upgrades and like.
So my dilemma did not last much - bought Atari ST, basic model, with plan to upgrade it soon - expanded RAM to 1 MB at end of year, added 2 side floppy drive .
Here to add that Amiga had new kind of OS, disk filesystem, while Atari ST went on compatibility with then widely used FAT12, FAT16 disk systems. What was good for some easier data exchanges with PC (with DOS then) users.
So my dilemma did not last much - bought Atari ST, basic model, with plan to upgrade it soon - expanded RAM to 1 MB at end of year, added 2 side floppy drive .
Here to add that Amiga had new kind of OS, disk filesystem, while Atari ST went on compatibility with then widely used FAT12, FAT16 disk systems. What was good for some easier data exchanges with PC (with DOS then) users.
#5
FAQ / Re: Finally some intelligent t...
Last post by Ronald J. Hall - 26-01-2026, 19:32:50I agree. People seem to forget the cost angle too.
When I was looking for an upgrade into the 16 bit world from my Atari 8bit,
the ST was by far, the best performance vs cost ratio that I could find.
The Amiga was released later that same year, but man, $1500.00 just for
the main unit, keyboard and mouse! Too rich for my blood.
I picked Atari ST and I've never regretted it.
When I was looking for an upgrade into the 16 bit world from my Atari 8bit,
the ST was by far, the best performance vs cost ratio that I could find.
The Amiga was released later that same year, but man, $1500.00 just for
the main unit, keyboard and mouse! Too rich for my blood.
I picked Atari ST and I've never regretted it.
#6
FAQ / Finally some intelligent threa...
Last post by Petari - 26-01-2026, 18:59:46TOS boot disk talk
Yeah, adding cartridge (normal capacity is 128 KB) - sure, that's what average user does - order (buy) some cartridge to make his not so cheap computer working well ? Sorry, I named this 'intelligent thread' - and yes, there are some such posts. If you are interested really, please read all it carefully, and most important think about it really carefully. We can easily blame people for some mistakes, but without knowing details all it is just shallowness, and often with really bad conclusions.
Tramiel was good, surely not perfect, made many mistakes, but that's the price of doing something new - there were mistakes with C64 too, still, it was most sold 8-bit home computer. ST was good idea, and pretty well sold. ST means compromise between 16 and 32 bits - and I think that it was done very well, if not best in those years (1985-1989) .
Yeah, adding cartridge (normal capacity is 128 KB) - sure, that's what average user does - order (buy) some cartridge to make his not so cheap computer working well ? Sorry, I named this 'intelligent thread' - and yes, there are some such posts. If you are interested really, please read all it carefully, and most important think about it really carefully. We can easily blame people for some mistakes, but without knowing details all it is just shallowness, and often with really bad conclusions.
Tramiel was good, surely not perfect, made many mistakes, but that's the price of doing something new - there were mistakes with C64 too, still, it was most sold 8-bit home computer. ST was good idea, and pretty well sold. ST means compromise between 16 and 32 bits - and I think that it was done very well, if not best in those years (1985-1989) .
#7
News / STE or not STE compatible
Last post by Petari - 24-01-2026, 18:56:21Judge yourself: Are they awake ?
Atari STE deserves better. Or maybe, those who made it STE compatible deserve better.
Atari STE deserves better. Or maybe, those who made it STE compatible deserve better.
#8
News / More useless threads at ataria...
Last post by Petari - 24-01-2026, 13:31:52Look this one: aage is aged
At atarimania can see some details: amania is not aged
Anyone said: devil is in details ?
From my own experience: using STE DMA audio instead PSG (partially) digitized sound may improve graphic frame rate little. But it depends from other things too - how video displaying code is done.
Well, usual advice is: believe own eyes instead what you can read on Internet. Or it was same some 30-40 years ago, except instead 'Internet' it was TV or press :-)
At atarimania can see some details: amania is not aged
Anyone said: devil is in details ?
From my own experience: using STE DMA audio instead PSG (partially) digitized sound may improve graphic frame rate little. But it depends from other things too - how video displaying code is done.
Well, usual advice is: believe own eyes instead what you can read on Internet. Or it was same some 30-40 years ago, except instead 'Internet' it was TV or press :-)
#9
General chat / Re: Question about PP hard dis...
Last post by Petari - 12-01-2026, 19:00:30 Hola,
Yes, and you can read more, see some YT videos here: hd adapted games
Just to add that I don't like when people call it conversions, or 'patches', cracks . It is much more complex and may need days of work to solve 1 game. Some games have really weird floppy code - talking about those not accessing floppies via TOS functions. And just to understand how it works lot of tracing is needed. Then need to replace parts of it with links to hard disk access code, including needed conversions. Hard disk access is not so simple, as during gameplay that normally works not - there are diverse ways to solve it, and it is not simple.
Then come TOS version compatibility problems, some not so good code in games what need correction, and so on.
Longer story. May read some details on my site.
Then extra functions: state saves, exit to Desktop, unlimited lives and other cheats - and some games really need them. All it costs time - and time is what ? You know it. And time is needed to make all it work from single image file on most common Atari ST(E) models. Yes, single file, but not same for all TOS versions - there is image for TOS 1.04 and higher - 7 GB, now with over 2660 games. And 3.5 GB for TOS 1.00 and 1.02 because TOS v. limits. It has some 1900 games. Other thing is RAM in machine: min is 1 MB. For games needing 1 MB with floppy run 2 MB is needed with hard disk run. And rare case 2 MB for floppy run games need 4 MB. Well, now is not so hard to do TOS v. upgrade and expanding RAM. And to add: overall work with hard disks (now rather SD cards) is much better with later TOS versions - not only accessible size limit is in question - faster and more reliable work.
There is kind of pricing, and it is not for games self, which are btw. accessible for free as floppy images online. I ask donation for my work in latest 17 years for making them runnable from modern and now cheap mass storage. Imagine how much work is needed to just put together properly so much SW, easy selectable and startable, plus making simple reading additional instructions and like + starting different versions of game.
Donation is now like 25 Euros, and it may be more soon considering that inflation is still on.
Running from floppies is now really problematic in many cases because old floppy drives and disks getting bad, unreliable - and hardly replaceable, as not manufactured for long time. I don't even attach floppy drive to my Ataris in latest 10 years. Only in rare cases for some testing. So, hard disk adapt must deactivate all possible floppy accessing, because it may cause crash, freezing without floppy drive (or Gotek and like) .That's additional work. And even if source is some crack (what I don't like, but often no
other) they may be remains of copy protection which needs deactivating.
Other time consuming is finding good image of game - wrote about it here and on other places multiple times.
Yes, and you can read more, see some YT videos here: hd adapted games
Just to add that I don't like when people call it conversions, or 'patches', cracks . It is much more complex and may need days of work to solve 1 game. Some games have really weird floppy code - talking about those not accessing floppies via TOS functions. And just to understand how it works lot of tracing is needed. Then need to replace parts of it with links to hard disk access code, including needed conversions. Hard disk access is not so simple, as during gameplay that normally works not - there are diverse ways to solve it, and it is not simple.
Then come TOS version compatibility problems, some not so good code in games what need correction, and so on.
Longer story. May read some details on my site.
Then extra functions: state saves, exit to Desktop, unlimited lives and other cheats - and some games really need them. All it costs time - and time is what ? You know it. And time is needed to make all it work from single image file on most common Atari ST(E) models. Yes, single file, but not same for all TOS versions - there is image for TOS 1.04 and higher - 7 GB, now with over 2660 games. And 3.5 GB for TOS 1.00 and 1.02 because TOS v. limits. It has some 1900 games. Other thing is RAM in machine: min is 1 MB. For games needing 1 MB with floppy run 2 MB is needed with hard disk run. And rare case 2 MB for floppy run games need 4 MB. Well, now is not so hard to do TOS v. upgrade and expanding RAM. And to add: overall work with hard disks (now rather SD cards) is much better with later TOS versions - not only accessible size limit is in question - faster and more reliable work.
There is kind of pricing, and it is not for games self, which are btw. accessible for free as floppy images online. I ask donation for my work in latest 17 years for making them runnable from modern and now cheap mass storage. Imagine how much work is needed to just put together properly so much SW, easy selectable and startable, plus making simple reading additional instructions and like + starting different versions of game.
Donation is now like 25 Euros, and it may be more soon considering that inflation is still on.
Running from floppies is now really problematic in many cases because old floppy drives and disks getting bad, unreliable - and hardly replaceable, as not manufactured for long time. I don't even attach floppy drive to my Ataris in latest 10 years. Only in rare cases for some testing. So, hard disk adapt must deactivate all possible floppy accessing, because it may cause crash, freezing without floppy drive (or Gotek and like) .That's additional work. And even if source is some crack (what I don't like, but often no
other) they may be remains of copy protection which needs deactivating.
Other time consuming is finding good image of game - wrote about it here and on other places multiple times.
#10
Software / Re: Original source files for ...
Last post by Petari - 12-01-2026, 09:07:49I have ASM S files for complete TOS 1.04 and 1.62 . I needed it for iTOS (my improved TOS, with better FAT16 code in first place, and other things - see page about on site here) .
I don't call it TOS sources as that would be C sources in biggest part. It is result of disassembling TOS versions - that is hard and time consuming process - some things can be done only manually to be correct.
So, complete TOS 1.04 ASM S is about 920 KB long, in single file. Or can have GEMDOS and AES part separately.
Even 920 KB S file can be assembled with Atari ST and Devpac - will need 4 MB RAM . It may take longer time - like half hour to 1. I do it with Steem emulator accelerated to max speed, so needs 1-2 minutes .
Test of accuracy is simple - just need to compare result of assembling with original TOS binary - can do it with Total Commander for instance. And yes, it is 100% same when all is set properly in Devpac.
So, no need for some newer 68000 assembler SW, lot of S and other files - as wrote complete TOS in ASM S format in single file.
I don't call it TOS sources as that would be C sources in biggest part. It is result of disassembling TOS versions - that is hard and time consuming process - some things can be done only manually to be correct.
So, complete TOS 1.04 ASM S is about 920 KB long, in single file. Or can have GEMDOS and AES part separately.
Even 920 KB S file can be assembled with Atari ST and Devpac - will need 4 MB RAM . It may take longer time - like half hour to 1. I do it with Steem emulator accelerated to max speed, so needs 1-2 minutes .
Test of accuracy is simple - just need to compare result of assembling with original TOS binary - can do it with Total Commander for instance. And yes, it is 100% same when all is set properly in Devpac.
So, no need for some newer 68000 assembler SW, lot of S and other files - as wrote complete TOS in ASM S format in single file.