Atari ST(E) versions, TT, Falcon & SW compatibility

[Petari]

Why some program (game) works not on my Atari ?  This is one of most common questions posted on forums.

Answer is not simple at all. If you want quick answer, then better leave this page and find someone smarter for it  :-) If you are really interested then be patient. All here is result of 24 years experience with Atari ST serie and dealing with lot of games, TOS, disks, tools etc.

 To better inderstanding the whole issue we start with little theory:
There is generally 2 kind of SW for Atari ST serie (in further text just ST) : SW using TOS calls and SW not using TOS calls. Obviously, later then must self to take care about everything - floppy access, screen output etc. Later is harder way, but has some benefits: more free RAM, as TOS occupies over 100 KB of RAM as workspace. Faster work - TOS calls are not the fastest way to do something. Especially doing repetitive some simple thing via TOS call may be very slow.
TOS allocates RAM in simple order, from bottom to TOP. Most low are system variables, then GEMDOS variables, workspace. Size depends from TOS version - later ones use always more and more RAM.  For instance TOS 1.04 :  GEMDOS workspace is up to $611C, then AES, Desktop workspace up to $A84E, then Desktop, AES RSCs ... up to $F096 .  After it is user space. But not always. Some additional space is needed if running SW using AES calls (PRG extension).

And right here begins the most common incompatibility problem: game works with TOS 1.02 but fails with 1.04 or 1.62 or 2.06 .  The reason is that TOS 1.02 uses less RAM for TOS. So, there is more space left for game self.   I hear as you say: but I have 1MB RAM (or more), and on game box stays 512KB RAM. So it should work with my TOS 2.06, as it uses only 40KB more RAM for TOS than 1.02 !?  That is good reasoning, and there is a number of games + serious SW which will work well on TOS 2.06 when there is 1MB or more RAM in machine. But there is even bigger number of games (in first place games) which will fail in mentioned case. The point is that programmers were just lazy - they wrote code not relocatible, but for fixed RAM area. It is naturallly area below 512KB boundary. So, RAM over 512KB is simple not used. Stupid, for sure. And if too much low RAM is occupied - by TOS or by user (with for gaming not needed ACCs and similar) game will crash, as there is no enough RAM from beginning of free space to boundary of 512KB.
And when we are at RAM sizes: there is even more stupid case, fortunately not so common: game works with 512KB machines, but not on those with more RAM ! Or works with 1MB, but not with more. Again, it is beause bad programming, lazyness of coders.

The solutions for cases above:  talking about running SW from floppies or HxC emulator:  running SW on machine with lower TOS version. Trying with some fixed version of SW.  SELTOS, RAMTOS - they install TOS in RAM, so may install older versions, if machine allows it. But you can not run older versions on any machine (Mega STE).  Too much RAM case is easy to solve - there is SW which will turn off RAM above 512KB or 1MB.

Of course, for beginner it is enough hard to determine what causes crash at all. Because number of possible reasons is not small.
So, the other possibilities:

Game works only with few TOS versions (or only 1 v.), and may crash even on same TOS version, but with different language. It is again because of bad programming: code which try to read keyboard, mouse, joystick on fixed RAM addresses, while it is not on fixed addresses, and depends from TOS version.  Or similar, code assumes some structures, but they also may change ... Worst is that there are even direct jumps in TOS ROM in some (GFA Artist) - such usually work only on specific TOS revision, like TOS 1.00 German only.  The easiest way to run such SW is using emulator where can simple select required TOS version. Or looking for fixed version - Arkanoid is fixed by couple people, so mouse works with any TOS version, unlike by original.

Game works not on TOS 2.06 :  if the reason is not something of above described it is usually Timer-C problem. Earlier TOS versions may run with Timer-C working different than TOS set, but not TOS 2.06 . Examples: Space Harrier, FOTI . Solution is to get fixed game version or ...
In case of using original floppies may happen that with TOS 2.06 we can not start game at all, or even not to open disk. The reason is the copy protection, namely Copylock and CRC error in sector 6, what prevents access to files on disk. But it was not problem for earlier TOS versions, as they did not read that sector. Solution: use crack !  :-)

Game fails on STE: usually it is because of TOS version. But in rare cases may be bug in SW (again that bad programming !). Examples: Hyperforce and Grand Monster Slam. Both have same bug - overrun in color setting code, what screws STE line skip register and causes corrupted screen on STE.  Solution - use fixed version. Special case is Defender of the Crown : it will stuck on STE after start because of fading rutine, which is not ready for 4096 colors. Use fixed version !

Things increasing already big confusion:  some SW will just write: "Insufficient RAM" in case when too much low RAM is occupied, so people with 1MB or more RAM will wonder what the hell is happening.  Going to some of 'great' Atari forums: there may read every amount of shallow and incorrect replies in threads, but not much of people with real knowledge. Actually, all this is too complex for simple thread reply, and one of the reasons why I just writing this :-)   .



SW not using TOS calls:
Such SW has much less compatibility problems. Because all above mentioned RAM allocation, Timer etc. problems can not happen. + not TOS depeending SW is written generally by more experienced programmers, so less bugs.


So, what machine to buy/get:

No easy answer too:
Best is STE for sure - best sound and graph, easy RAM expansion.
Even better is STE with some mass storage device, Flash card based - so US or some other, CF based solution.
But what with games and hard disk ? Well, best games are adapted for hard disk already. Over 500. So, need only to get HW, install SW, write flash card, set some things and enjoy :-)
The top:  Mega STE. There is a number of games benefiting from 16MHz CPU clock.


If above is not suitable for you:  get only STE.

If fraid that SW will not run on STE get 1040 ST or Mega ST.
It is cheaper too, of course.

Usual opinion of Atari 'experts' (on forums) is that STE is not much compatible with old games. It is only partially true, and stays not for advanced and experienced users (as myself    ). 95 % of problems on STE are because of TOS version. Others are mentioned bugs and similar.  Since I have solved running of TOS 1.04 core on any ST compatible, so on STE too, TOS version related incompatibility is not problem for my later hard disk adaptations. Launcher will install TOS 1.04 core in high RAM, and game will work fine. It is case when files D15R_HH4.FIC are present in archives. And there is a lot of such games already adapted. Beside TOS incompatibility override it offers gamex (exiting game and saving state for later continuing), RAM allocation problem override, + optional trainer, cheat.
All in all, STE is 100% compatible in good hands. No ST game which can not be fixed/adapted for STE in reasonable time (couple hours max).

With TT and Falcon is different: there is too much HW difference in compare to ST. CPU in first place. But video, MFP, etc. behave different too.
Often just too fast CPU is the problem - and by TT you can not set CPU clock down.

Stackframe difference problem:
68030 has bigger stackframe for interrupts, traps - 8 bytes. So, code which manipulates with stack content will fail.
Simple case:  
bsr   subrut
....
subrut  move sr,-(sp)
....
rte

It will fail on TT, Falcon.
Need to replace rte at subrut end with:  move (sp)+,sr ;  rts  .

It was simple case, there are much harder to find and fix.

Less known problem:  pipeline related, appears only in few titles (at least I saw in few) .

move.w  d7,label+2
label   bra  xxx

This will fail on 68030 because CPU fetches about 3 instructions ahead (pipeline). So, change of branch will have no effect, CPU will execute old branch.  Need to add some jump between write and execution, to break pipeline (force reload).

Very hard to find in code. I did special version of Steem Debugger to help in it.  In case of Infestation needed to correct about 30 places
!  Another cases:  Voyager (same programmer, Dan Gallagher).    Vroom, Maupiti Island.