Moderator: Moderator Team
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: http://www.atari-forum.com/viewtopic.ph ... mu#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...
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..
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 http://www.atarimania.com/game-atari-st ... _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.)
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.
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 .
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
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: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.
http://sourceforge.net/mailarchive/mess ... d=26841274
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
Funny thing is that even some games, which use direct HW access, so not using TOS calls fail on some TOS versions
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
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.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
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?
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