Common mistakes in Atari ST SW, bad practices

[AtariZoll]

This is based on what I seen, mostly in games - and count is over 1000 examined more-less ones.

Will start with not game: GFA Artist - jump to fixed address in ROM. That results in work in only 1 TOS version, and only 1 language v. in it. Maybe programmers found that it is good regional protection, but what when user gets TOS 1.02 or higher ?

Performing some AES calls, while it would be better with VDI or Line-A calls. Like reading mouse, displaying some texts ... Many of such SW could work well with AUTO run instead Desktop run, without AES calls - what means faster start, less RAM usage ...

Writing not relocatable code for TOS calling program. - Very common bad practice. The result is working not on higher TOS versions, from hard disk and like. Lot of RAM in machine helps nothing. Also, helps not if program writes: "Insufficient RAM"

Not testing on machines with more RAM. Works with 512KB, 1MB , but fails with more. Especially 4MB is problem. They use code what writes higher and higher, and tests is it really written in RAM. If reading back matches not, they stop, and set it as top of RAM (why not using phystop genie ?) . When reaching 4MB bus error appears, and adios ...

Input read problems, especially joystick. . Now, this is case when I blame more DR, Atari than programmers of Atari SW. Whole solution in TOS is messy. Documentation is incomplete, details are missing. The result is work only in specific - mostly low TOS versions. And as best, even not TOS calling games suffer from input read problem - many Psygnosis games for instance.

So much for today. May be that to be continued

[felicemaggie]

You've made some interesting points here. Although regarding not testing in machines that have more than 512K or 1 meg of RAM, I wanted to make a couple of points.

Back in the day (and this may not have been specific to just the UK market) when stores were selling Atari and Amiga systems.

512K and sometimes 1MB of RAM were pretty much standard configurations back then. Very rarely were 2MB and 4MB expansions on sale in stores; although for those of us who visited the Atari shows in London and elsewhere then they were on sale at these events; although the price was quite expensive.

Whilst Atari did have the Mega ST's and later Mega STe models around with the larger memory capacities, unless you happened to live in one of the major cities such as London, these were not seen very often in stores.

So therefore the base configuration, particularly for games, was 512K as a basic standard, with the 1 meg ST being a bonus if you happened to have it.

Only in later years, when the popularity of both systems had dipped a bit in favour of PCs in their early days (ca. 1993 or so) then memory expansions did get quite a bit cheaper and more widely available, certainly at Atari shows.

There was a difference with the Amiga and that was because the stock A500 didn't quite have enough memory inside it to run many of the games. Therefore, the 1 meg expansions were sold alongside the systems and owners were encouraged to fit the extra trapdoor expansions as a general marketing ploy, at least in the UK.

[AdamK]

You should avoid using Line-A calls, as they are not compatible with clones and never CPUs. Not to mention, that they're completely multitasking unfriendly.

[Eero Tamminen]

Performing some AES calls, while it would be better with VDI or Line-A calls. Like reading mouse, displaying some texts ... Many of such SW could work well with AUTO run instead Desktop run, without AES calls - what means faster start, less RAM usage ...

Line-A was already commented, so I'm just going to add few other notes:

* At least according to Compedium, VDI virtual workstation open call should get as the handle argument a return value from graf_handle(), which is an AES call (for some reason, the handle thing isn't mentioned in TOSHyp).

* If a graphical, non-GEM program is expected to work reasonably with MultiTOS, it still needs to do few AES calls at start and at end. Otherwise other programs will overwrite over its window, desktop isn't refreshed properly when the program exits etc.

<rant>
Unlike other OSes, Atari's AES is lacking any kind of reasonable support for fullscreen programs.
</rant>

EDIT: EmuTOS docs contain a detailed list of issues in programs: https://github.com/emutos/emutos/blob/m ... atible.txt

[AdamK]

<unrant>
I think Irata (the never finished GEM-Friendly real time strategy game) was able to create reasonable workaround for firescreen
</unrant>