Page 1 of 1

Generally about incompatibility

Posted: Wed Sep 10, 2008 12:30 pm
by ppera
Little boredom here :D :

I will list some reasons why games not run on specific platform(s), without intention to be complete (as some problems are still not clarified) or to list them in some order by how frequent they are.

1: Game runs on machine with 512KB, but not on machines with more RAM. This is probably something stupidest possible, but is not so rare, unfortunately.
The reason is always bad programming. In most cases crackers are culprits, but happens by originals too.
Solution can be to try another crack, and more perspective: using one of small utils to set machine to act as has only 512K - for ST, STE. Get it here: viewtopic.php?f=15&t=13610&p=115356&hilit=mmu#p115386

2: TOS version related:

2.1: Game is written so that runs on fixed, low RAM locations (not relocatable code). As newer TOS versions reserve more RAM for system, game code will conflict with system, and crash is almost inevitable. Examples: Millennium 2.2, Sapiens.
In some cases game will give message about insufficient RAM at start. Even on machines with 4MB. But game checks actually is there enough free space between system and 512KB.
Possible solutions: running game from AUTO folder. Looking for adapted version. Using Hole.

2.2: Timer C stop problem. It happens on TOS 2.06 , 4.xx (Falcon) . Examples: Space Harrier, Falcon F16, FOTI.
Reason is that Atari changed TOS code by Trap calls, and system will stuck if timer C (200Hz) is stopped by regular Traps.
Solution is: using adapted versions where restart of Timer C is solved somehow. Or running lower TOS version in RAM.

2.3: Sometimes code runs well on some TOS version(s), but not on another one(s). It is mostly because of bad programming (even bugs sometimes), bad system function calls, jumps in ROM and similar.
Solutions: trying with another crack. Looking for patched version. Example: Predator.

3: Hardware related:
Mostly when try running ST(E) games on Falcon.

3.1: Different CPU in Falcon - Stack frame is different by interrupts and Traps. CPU cycles are different. There is cache in CPU. Used stack space is bigger.
Solutions: turning off code and/or data cache. Increasing stack space. Setting CPU clock to 8MHz.

3.2: Falcon uses PMMU table for normal work. It is placed at $700. If some game writes in that area it will crash. Solution is moving of PMMU table in unused RAM.

3.3: PSG shadow registers - Falcon will crash by long writes to PSG (YM) registers. Cure is setting of so called STE emulating bus mode. In some cases it will result with very bad sound, Then only correcting game code may help. Example: Princ of Persia.

3.4: Different video HW registers: screen disalign may happen by direct writing in video base registers. Solution is to use system calls by setting screen base, resolution. There are likely some other problems, as some games crash, freeze by certain points, what needs further investigation.

4. Special, mixed problems: As STE has palette of 4096 colors instead 512 by ST there may happen some problems because of that. Example is Defender of the Crown by which raiding stucks if run on STE. Cure was to correct palette by some pictures where were invalid 12-bit entries instead 9-bit ones. However, it was TOS version related too, since by older TOS versions game worked without stucking (Steem).

Here is one, little older, but very good Falcon compatibility list - we probably have no better so far...

to be continued...

Re: Generally about incompatibility

Posted: Sun Nov 09, 2008 8:51 am
by Klapauzius
Here's another article on game incompatibility:

Yes, it's meant for the Amiga and many points are Amiga specific, but you can still find a few points that will also apply for the Atari world, like issues with the CPU caches, exception stack frames, etc.. :-)

Re: Generally about incompatibility

Posted: Sun Nov 09, 2008 3:25 pm
by ppera
I hoped when started this thread that some people will add his own experiences, Klaz in first place :D

Re: Generally about incompatibility

Posted: Fri Feb 05, 2010 5:22 pm
by carmel_andrews
I know that this will take some time, but if I could suggest that a group of forum members put together the definative what works and what doesn't work compatibility lists for menu and non menu games

Re: Generally about incompatibility

Posted: Sun Oct 09, 2011 2:24 pm
by beanz

Anyone know if PAL ST games will work fine on an NTSC Atari 520STFM (using the TV not a monitor). I know several other systems chop the bottom of the screen off.

Re: Generally about incompatibility

Posted: Mon Apr 29, 2013 8:43 pm
by Zodiac
I've got a question regarding this:
I noticed that some game releases state not only that they need 1 MEG on the cover, but also list only the models that came with that amount of RAM (e.g Atari ST 1040 etc.)
As an example, see ... _9761.html

Is there something that would prevent the early models (going back to the Atari 260, 520) from running these games even if RAM was upgraded? Aside from the issues mentioned before (TOS etc.)

Re: Generally about incompatibility

Posted: Tue Apr 30, 2013 8:05 am
by AtariZoll
Short answer is: no .
And what I see on cover of Knighs of the Sky is listing of regular models, + "1MEG required" . There is no mention that will not work on some 520 expanded to 1MB or more.

Re: Generally about incompatibility

Posted: Fri Jan 02, 2015 9:13 am
by AtariZoll
After 6 years, time to add some things :D

3. Hardware related

3.4 Falcon and TT have different usage of Vfreq. ($FF820A) register - writing to it some value what is OK on ST, STE may kill video on TT or Falcon.

3.5 Reading Video pointer registers ($FF8205-9) on TT. Falcon is somehow slower and seems not reliable - probably because pipeline, PMMU. If SW using it for accurate syncing, it may freeze. I needed to mod code in some cases to make game work on TT< Falcon.

3.6 68030 CPU pipeline related. That CPU reads normally 3 instructions ahead, before execution. And if self-modding code writes in RAM area where they are located, that change will not go to CPU execution unit, so old state will be executed. Solution is to add some jump in that process, what will break pipeline, and force CPU to read actual RAM state. Examples: Voyager (lot of to correct), Infestation, Astro Marine Corps, Vroom, Maupiti Island, Parasol Stars (later 3 only in depacker) .

3.7 PSG port 14 - it is used in ST, STE only for floppy drive and side selection - 3 bits. Some additional bits are used in Mega STE and Falcon. SW should keep all bits 7-3 unchanged by floppy access. But it is not case always, and therefore some unwanted interrupt triggerings may happen on mega STE, what usually crashes. Or may kill IDE port on Falcon.

5. Regional limitations

Some SW is allowed to run only in specific regions. And how computer knows where it works ? By TOS language version or by video refresh rate (50 or 60 Hz) . So, SW (mostly games) may check TOS language (flag is in TOS header) or V. refresh rate. If matches not, it freezes or resets, usually without any message. Example: Star Wars. There is lot of ...

As carmel_andrews suggested, it would be useful to compose some list, database about all known incompatibilities in Atari SW. It should have SW title, opt. version # (if known), opt. region of release as descriptors of exact variant. Then concrete incompatibility(es) and possible exact problem description in short .
Something like:

Tracker : works only with TOS 1.00 UK/US - jumps in ROM used.

Maybe could add those fields to Atarimania database, and to currently under update GameBase ST :idea:

Re: Generally about incompatibility

Posted: Fri Jan 02, 2015 11:41 am
by Eero Tamminen
ppera wrote: 2.3: Sometimes code runs well on some TOS version(s), but not on another one(s). It is mostly because of bad programming (even bugs sometimes), bad system function calls, jumps in ROM and similar.
Solutions: trying with another crack. Looking for patched version. Example: Predator.

Using undocumented, TOS-specific vectors. E.g. input handling in most STOS games, and input handling in Reservoir Gods' Falcon games. For former, one can use patched games. Latter is only an issue with EmuTOS because only TOS4 & EmuTOS support Falcons, and it can be worked around with this: ... d=26841274

Re: Generally about incompatibility

Posted: Fri Jan 02, 2015 11:58 am
by AtariZoll
Yes, input handling is one of worst coded parts in games. I saw many diverse incompatible, overcomplicated code. But it can be solved pretty much easy, in fact. Likely, there was not enough info, doc available in 1980-es about that, including IKBD chip programming.
STOS is one of examples how not to do it. But it has so called STOS fixers, which can "patch" executables to work in most TOS versions.
I did not deal with Reservoir Gods games. Don't think that much people using EmuTOS for gaming, especially not on real HW - actually, I would be surprised if anyone uses it :D

Funny thing is that even some games, which use direct HW access, so not using TOS calls fail on some TOS versions 8O
Heimdal has some graphic bugs if TOS is at $E00000 .
Then, there is region check in Star Raiders, what assumes that TOS is at $FC0000 - it crashes therefore on STE. "Nicest" thing is that it is published by Atari self :mrgreen:

Re: Generally about incompatibility

Posted: Fri Jan 02, 2015 12:13 pm
by Eero Tamminen
AtariZoll wrote:Don't think that much people using EmuTOS for gaming, especially not on real HW - actually, I would be surprised if anyone uses it :D

I don't think anyone uses it on original Atari HW, but on new FPGA based HW some might. Suska & MiST emulate original Atari. With Firebee using ColdFire CPU and EmuTOS not having m68k emulator like FireTOS has, EmuTOS is unlikely to be used with old games, only with new ColdFire builds of the games. :-)

Firebee has still too many issues that discussing its (non-GEM games) compatibility doesn't make much sense. Issues with e.g. accelerators for original Atari HW might be relevant though?

Re: Generally about incompatibility

Posted: Sat Jan 03, 2015 9:13 am
by AtariZoll
Old SW's compatibility with diverse accelerators, clones is special area. I really don't want to go in it. Focus here is on compatibility with regular Atari machines. It self is problematic enough, and still some things are not researched enough. With accelerators and clones often may happen that SW fails because high speed only. I'm sure that people owning such beasts don't care much for old ST games. They play games compiled specially for them, their OS.

There are things what can not be solved with some system routines - like existing trap for reading SR in user mode (what is priv. violation with 68030) in TOS 3.06, 4.0x (TT, Falcon)) . Stackframe and pipeline related incompatibility can be solved only with changing code of SW. And that's lot of tracing, testing.

I think that who want to run old SW with new HW should go Mist or Sushka way, or to use SW emulators on some faster, modern machine - and later can be done with small sized boxes too :D

Re: Generally about incompatibility

Posted: Fri Feb 23, 2018 5:12 pm
by TheMilford
Great post. Just getting into ST. Got a 1040ST(f)... plan to upgrade to TOS 1.04 to better ustilize MIDI sequencing programs like Notator, Pro 24, etc. But would also like to play games like Sierra and SSI. any known compatibility issues?