- Welcome to 8BitChip Forum.
Recent posts
#1
General chat / Just visited thread at atariag...
Last post by Petari - 23-02-2026, 21:48:00 Oh yeah, people leading that 'forum' are some fair, responsible, deep thinking and so on ... Like some businessman caring only about profit.
New game adapts - 2021
Of course it is locked
Well, what we can see there ? Some people which vanity is 'hurt' - as they say, because I'm not polite. Sure I'm not it. I'm pretty old. and I have something called 'life experience' - after working diverse jobs over decades, and most of them was with lot of people. Even when I worked with electronic and computers.
Had over 10000 costumers in my service years with such machines. And can say that some 99% of customers was fair, pretty much polite. Unlike it is with 'big' Atari forums in 21st C.
And I blame forum admins and their circle for it. Well, + whole nowadays politician attitude - really very bad example, especially for youth.
So, in that thread most anti-me was Tillek, as he got insulted that I called him shallow. Well, he confirmed it multiple times, even later - like his writing about me being banned from some 5 Atari forums.
Actually, I was banned from 2 'big' Atari forums only. Some I left on my will. But real problem is Albert, admin at atariage in later years. I can say only that he is shallow too. And unfair.
What about banning Cyrano Jones, who wrote multiple times that I stole his ULS code ? Everyone with little programming knowledge can check how true is it. Total ridiculous nonsense. I stole something what he never did - like did code for adapting games using TOS calls, TOS functions and other things in TOS ?
This self is enough proof how big bullshit is there.
For the end of this writing: for bad (things) only thing what it (they) need is that people let it to function - then it will be just worse and worse (as it goes since 2020). Only way to stop bad/evil is to stand up against. Sure, it is not easy, it may be even dangerous. But no other way. Nobody will do it instead us. And it happened many times in human history.
So, what was my asocial behav. there ? That I openly criticized some bad writings, bad and unfair behaving - giving advantage to people from own circle, or those who licked admin's ass ...
Example from atari-forum: someone wrote about his SW for Atari ST and what system used , and he wrote too that it is only way how it can be done. On what I reacted with some comment in mocking style - because it is known basic, general rule that things can be done in multiple ways - and of course stays for SW too.
What moron moderators and admin there did ? Deleted my comment as it was so insulting. Well, for me was insulting what that vain person wrote, just to increase opinion of shallow people about his creation.
Yes, most of people is not aware about many/most of some general rules in this World, universe. So, I'm bad person because I would like to point on some, talk about ...
And worst: many place selfishness, egoism ahead doing something for common interest.
New game adapts - 2021
Of course it is locked
Well, what we can see there ? Some people which vanity is 'hurt' - as they say, because I'm not polite. Sure I'm not it. I'm pretty old. and I have something called 'life experience' - after working diverse jobs over decades, and most of them was with lot of people. Even when I worked with electronic and computers.
Had over 10000 costumers in my service years with such machines. And can say that some 99% of customers was fair, pretty much polite. Unlike it is with 'big' Atari forums in 21st C.
And I blame forum admins and their circle for it. Well, + whole nowadays politician attitude - really very bad example, especially for youth.
So, in that thread most anti-me was Tillek, as he got insulted that I called him shallow. Well, he confirmed it multiple times, even later - like his writing about me being banned from some 5 Atari forums.
Actually, I was banned from 2 'big' Atari forums only. Some I left on my will. But real problem is Albert, admin at atariage in later years. I can say only that he is shallow too. And unfair.
What about banning Cyrano Jones, who wrote multiple times that I stole his ULS code ? Everyone with little programming knowledge can check how true is it. Total ridiculous nonsense. I stole something what he never did - like did code for adapting games using TOS calls, TOS functions and other things in TOS ?
This self is enough proof how big bullshit is there.
For the end of this writing: for bad (things) only thing what it (they) need is that people let it to function - then it will be just worse and worse (as it goes since 2020). Only way to stop bad/evil is to stand up against. Sure, it is not easy, it may be even dangerous. But no other way. Nobody will do it instead us. And it happened many times in human history.
So, what was my asocial behav. there ? That I openly criticized some bad writings, bad and unfair behaving - giving advantage to people from own circle, or those who licked admin's ass ...
Example from atari-forum: someone wrote about his SW for Atari ST and what system used , and he wrote too that it is only way how it can be done. On what I reacted with some comment in mocking style - because it is known basic, general rule that things can be done in multiple ways - and of course stays for SW too.
What moron moderators and admin there did ? Deleted my comment as it was so insulting. Well, for me was insulting what that vain person wrote, just to increase opinion of shallow people about his creation.
Yes, most of people is not aware about many/most of some general rules in this World, universe. So, I'm bad person because I would like to point on some, talk about ...
And worst: many place selfishness, egoism ahead doing something for common interest.
#2
Software / Re: Chip's Challenge
Last post by èné - 19-02-2026, 18:06:21Hey Peter,
You can find the codes over at gamefaq: https://gamefaqs.gamespot.com/pc/565288-chips-challenge/cheats (scroll down a bit)
You may enter the codes at the start of the game (ather the short intro).
I mainly reported here to point out that this was yet anoter ST faulty port, ie the game cannot be completed without the cheatcodes. Didn't expect any sort of patch actually (well maybe a bit).
The 'bugggy' levels:
* 59 (code: BLDM), no exit available it seems, but as this level (a maze) differs from the other versions, cannot be 100% affirmative.
* 93 (REKF), this level cannot be finished since it's impossible to push a block on the gravel (gravel = floor with little stones). In the other versions, it works flawlessly.
* 99 (XUVU), one needs to grab some keys here. The problem with the ST version is that's impossible because as soon as you take a key, you are immediately killed by the bugs that are right behind (the keys). In the others versions, you just need to be quick (to avoid the bugs), but it's still doable. Not in the ST version.
* 112 (NJLA), some sort of barrier - which soudn't be there, prevents to reach the exit.
* 124 (TASX), The mechanism with the fireball which is supposed to make you able to pass through the plant doesn't work in the ST version (the plant still retains you, which isn't normal).
* 126 (QRLD), same problem as level 93, cannot be completed because you are not able to push the blocks on the gravel.
There are a few other levels that are buggy. I'd say thare are about 10 levels that don't work in the ST version.
Once again I don't request any patch. I know it's too much work + it's the ST (and Amiga) version itself which has a problem. I don't see what you could do here (other than specify that it is bugged on the page description).
You can find the codes over at gamefaq: https://gamefaqs.gamespot.com/pc/565288-chips-challenge/cheats (scroll down a bit)
You may enter the codes at the start of the game (ather the short intro).
Quote from: Petari on 09-02-2026, 15:37:18Btw. not only game in which are some not passable levels. I corrected couple, but that's enormous work.I understand
I mainly reported here to point out that this was yet anoter ST faulty port, ie the game cannot be completed without the cheatcodes. Didn't expect any sort of patch actually (well maybe a bit).The 'bugggy' levels:
* 59 (code: BLDM), no exit available it seems, but as this level (a maze) differs from the other versions, cannot be 100% affirmative.
* 93 (REKF), this level cannot be finished since it's impossible to push a block on the gravel (gravel = floor with little stones). In the other versions, it works flawlessly.
* 99 (XUVU), one needs to grab some keys here. The problem with the ST version is that's impossible because as soon as you take a key, you are immediately killed by the bugs that are right behind (the keys). In the others versions, you just need to be quick (to avoid the bugs), but it's still doable. Not in the ST version.
* 112 (NJLA), some sort of barrier - which soudn't be there, prevents to reach the exit.
* 124 (TASX), The mechanism with the fireball which is supposed to make you able to pass through the plant doesn't work in the ST version (the plant still retains you, which isn't normal).
* 126 (QRLD), same problem as level 93, cannot be completed because you are not able to push the blocks on the gravel.
There are a few other levels that are buggy. I'd say thare are about 10 levels that don't work in the ST version.
Once again I don't request any patch. I know it's too much work + it's the ST (and Amiga) version itself which has a problem. I don't see what you could do here (other than specify that it is bugged on the page description).
#3
Software / Re: Chip's Challenge
Last post by Petari - 09-02-2026, 15:37:18I dealt with this game in 2015 and admit that don't remember it. Just looked my YT video of it.
Are those level codes available somewhere ? Is there some hacked one release with selectable start level or like ?
Btw. not only game in which are some not passable levels. I corrected couple, but that's enormous work.
Are those level codes available somewhere ? Is there some hacked one release with selectable start level or like ?
Btw. not only game in which are some not passable levels. I corrected couple, but that's enormous work.
#4
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).
#5
FAQ / Re: Adapting Atari ST(E) game...
Last post by Ronald J. Hall - 01-02-2026, 03:05:49Thanks for the explanation, appreciated. 
#6
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.
#7
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.
#8
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.
#9
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) .
#10
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.