Some less known things about TOS, reasons of bad programming of SW

[ParanoidLittleMan]

I write this after 32 years of practice with TOS, after dealing with over 1200 games + other SW, so yes, I saw lot of Atari SW, and how it is coded.

I guess, some don't like threads like this - why talking about negative things, Atari made great job ... etc.  Well, there are some really strange, and could say silly solutions in TOS. On top of it documentation is everything but not complete and error less.

Goal is to point on it, and help programmers to do it better. Or even to make TOS better ?

And believe me, some old bad practice is still on.

 

TOS is split in 2 clearly separated parts - so called GEMDOS, first part, what initializes HW, deals with disks, storage, simple txt output, peripheral input. And surprisingly even with VDI (graphical output) . Later is especially strange because VDI is not initialised before second part, AES starting .

AES or GEM is what deals with windows, dialogs, so basically GUI, + Desktop.

This separation self is good thing, and is done well - 2 parts communicate via Traps, system variables, and is even possible to combine GEMDOS from one TOS version with AES from other.

But there is confusion with VDI. Why it is in GEMDOS part, while even not initialized there ? Then, same Trap #2 is used for VDI and AES function calls, with only different value in register d0 . I'm sure that this is reason why so many SW using AES calls without real need for. There are lot of games which have no windows and other AES (GEM) stuff, but using AES calls to read mouse, keyboard and other simple things. All that can be done with VDI and/or Line-A calls.

Ah yes, Line-A is not initialized in GEMDOS part too .

Why is using AES so bad ? It is a bit slower, but real bad thing is that more RAM is taken by TOS in that case, so there will be less free RAM for SW.

Concrete:  if starting SW from Desktop as PRG (and it must be extension PRG if using AES calls) start address in TOS 1.04 is $12596 .

If starting non AES calling SW, with extension TOS from Desktop start address is $F196 -  13 KB more free space.

And if starting SW from AUTO folder then start address is $AA56 - yet 18 KB more free space.

But, despite extension PRG needed, you can not run AES SW with AUTO run.  Yes, this is another confusing solution. And I really don't see why it is so, except someone was shallow.

And there is possibility to have even more free RAM for non-AES SW:  in TOS 1.04 end of GEMDOS workspace is $611C - what is beyond that is used by AES, Desktop. So, if AUTO run SW could load to that address - another 18 KB free RAM  .  Total possible save: 13+18+18 KB = 49 KB. Not little.

 

I saw that space used by one very known game:  Dungeon Master . It has AUTO start, and detects that free space according to TOS version, and puts some code, data there. With it, game works with 512 KB Ataris . As I know Amiga v. needs min 1 MB RAM.  Nice job FTL crew ?

 

I wrote already about input handling code in TOS, and poor documentation for. That's culprit for that many games have problems in later TOS versions - mostly joystick works not. but may be mouse and keyboard problems too (Tracker) .  Programmers just did not see way to read joystick properly via TOS. Even STOS, done by good programmer suffers from that problem.

 

Of course, it's not only Atari and TOS to blame. There is lot of SW not well coded, coded against recommendations, then not tested well ...

Probably stupidest error is that SW works well with 512 KB RAM, but crashes with more - sometimes it is 1 MB and more, sometimes 4 MB RAM .

Concrete reason for 4 MB crash is usually that some operations simply have no proper loop control, and may run out from 4 MB RAM space, and then bus error happens. Not just lack of testing.

There is lot of SW written to specific RAM area, instead of by TOS normal relocatable code . And that's another common reason for not working on higher TOS versions, because they usually allocate more RAM for self, so SW may conflict with TOS workspace. Exception is TOS 1.04 which needs less RAM than TOS 1.02 . While TOS 2.06 needs pretty much more.

Ah, 2.06 - they made some changes in floppy code, what is another reason for incompatibility - mostly games. Using Timer-C there was not much good idea.

And even TOS start address changed when they releases STE - from $FC0000 to $E00000 - clearly because 192 KB was not enough. And that again caused some crashes ...

 

For the end of this post (did not list all bad things) probably stupidest SW error:  IKBD chip has own clock, which btw. can be used permanently, so when machine is powered off - by adding battery there - I made it back in time, and it worked fine when machine was used regularly - IKBD chip consumes much more current than usual RTC chips. So, in that chip year is stored as 2 digit BCD value - what means span from 0 to 99 - 100 years.  But what was done in TOS ? They added 80 to year value (what is as is well documented current year minus 1980, so it starts at 0 for that year, and is for instance 7 for 1987) before writing it to IKBD chip, and then of course needed to subtract 80 after reading from . Hurra ! - instead 100 years span, we have now 20 years. 1980-1999.

Luckily TOS has own timer, what can go over 1999, so works with Y2K values - well, if regular interrupts are allowed. But is not possible to get proper year from IKBD chip at boot (where is code to copy it to TOS timer) .

 

 

 

[Cyprian]

interesting topic.

 

Regarding AUTO programs, did I correctly understand, at this point GEMDOS is initialized but not LINE-A/VDI/AES?

If I remember correctly I saw AUTO programs which were showing AES dialogbox, or using LineA/VDI stuff. Is it possible then?

[ParanoidLittleMan]

Yes, Line-A, VDI, AES , and I add here mouse (cursor) too are not initialized when AUTO run code is executed. But it is before AES part start, so AES can not be initialized there.  VDI, Line-A and mouse can. With little special code, and it works, even if only first part of TOS is executed from RAM, and no AES at all.  This is what I use with TOS calling game in files D15* .  In games Line-A is used mostly, but there are VDI calls too.

AUTO programs which show 'AES dialogbox' have own code for it, that works not via AES .

AES is executed as TOS APP after AUTO run sequence, combined with Desktop.

In my iTOS I have now option for AUTO run of AES PRGs, that works so, that AUTO run is performed after AES init, right before Desktop start. Some manipulation with stack is necessary for it.

[Cyprian]

I've just found an example - ANTIBOMB. It runs from AUTO and shows AES dialogbox instead of bombs in case of an exception.

https://www.exxoshost.co.uk/forum/viewtopic.php?f=25&t=2342&sid=866db3a194347497c1eb2cef579d58ce

 

I didn't look at the code yet, but I see "appl_init" / "appl_exit" labels there.

[ParanoidLittleMan]

Oh, nice Atari fella exxos don't allow looking his forum without registering. No thanks, I don't need to read 5 months long thread about IDE adapter design, while I did it self, without Internet in 2 days, in 1992 - just an example.

My first thought was that that ANTIBOMB installs self during AUTO run, but does not perform any AES calls then. AES calls will happen after AES init and Desktop start, when running some SW and it crashes.    OK, let's use good old google - what I don't do much often lately. And found it quickly, of course. And what the Hell, I was right ?  Just try it like this:  copy ANTIBOMB as first in AUTO folder, then other PRG what is supplied with - EXCEPTIO.PRG as second in AUTO folder. Reset, and will see that no Dialog appears. It will appear when EXCEPTIO is not in AUTO.

Link for DL: http://www.chillichai.com/atari-st-review/cover-disk-downloads

STREV06_2 .

To add that in my improved TOS, with option to force AES AUTO run, dialog appears when both are in AUTO folder.

Not bad PRG, that ANTIBOMB, and I never heard about.  Too bad that I got used on Steem Debugger ?

[Cyprian]

thanks for verification

 

[ParanoidLittleMan]

Just spotted strange bug or whatever in TOS 1.02 - while tested new version of floppy image runner. When opening floppy A: in Desktop RWABS (BIOS 4) call will be performed, with destination address = 0 . What causes of course crash . So I needed to add something against - and just added short code what in case of address = 0 just skips whole call, with OK return (just for first test). And that made it work well - not surprised, because had similar thing in some other SW.  Then was curious what real floppy code does with address = 0 in TOS 1.02 . Traced it, and yeah, it does same, just skips with ret = 0 (OK) .

Funny thing. Not sure what is all it, maybe some strange system to init floppy access at all in Desktop ? Does not look as some bug, because this is  clear case of cleared address value in TOS code:

  .....
$FE1BA8   clr.l -(a7)  * address
   clr.w -(a7)   * R/W flag - 0 for read
   move.w #4,-(a7)  * BIOS 4 
   line-F #$1A0 * This leads to trap #13 

 

[ParanoidLittleMan]

And more bad programming: Omikron Basic - dealt with game Star Command (what is not compiled, but interpreted btw. , so nightmare to trace) - not saving registers a0-a3 before trap calls, and then using them after - but value in may be changed (depending from concrete call) . It made not problems, or at least not crashed this game with early TOS v. 1.00 and 1.02, but at 1.04 it fails.  Btw. similar problem exist in Prince of Persia too (coded in ASM).  Well, should we blame here coders or Atari ? Really hard to say how docs were good and available at 1987-8 .

And another bad in Omikron Basic, but present in many other SW: pulling out some address from TOS code, surely in purpose to save some programming.

Worst is when go on fixed TOS ROM address and perform direct call (GFA Artist) - that works only with 1 TOS version, only specific lang.

Getting somehow ROM code start address (like in some register after trap call, what is case by Omikron, and not only in it) - then assuming that needed address is for instance 10 bytes higher, or something like. Of course, that will fail in later TOS versions.

Patching errors like this is really hard, and needs lot of tracing. Without Steem Debugger almost hopeless (well, if you don't want to get grey hair during only 1 case solving ? ) .

 

[mikro]

I like how you can say that apps like Omikron Basic or Prince of Persia use dirty/faulty programming techniques and give you headache when patching on one hand and on the other hand trash EmuTOS authors when they refuse to implement such workarounds.

[ParanoidLittleMan]

That's not correct - or in other words, you trying now to trash me ?

What EmuTOS team admittedly do is to make it 100% according to TOS documentation. And that's simply bad idea - because same reason what I talk about here - TOS docs are incomplete, with some errors. They even do not support famous program Spectrum 512 - which (as many other) work not under EmuTOS - because it uses some 'dirty' trick to override some TOS problem, surely as result of poor documentation.

What I explained here is that programmers were sometimes forced to do like that.

And I wrote about concrete cases at AF, what they did not like.  The things are that when docs are incomplete you need self to examine function and judge how it works, what are return parameters, and even sometimes how to use it at all - probably best example is joystick read via TOS - no complete guide for usage, not even in newest, updated (not by Atari) TOS docs. I could write some other examples, but who is interested can find them - even in this forum.

What is more important today ? To be able to run good old SW on Atari, emulators, or have some 'perfect' TOS (actually perfect only on paper) under which some 30% of SW works not properly or at all.

[WhataKowinkydink]

The thing that gets me about TOS/GEM is that it isn't multi-tasking....

[Cyprian]

there is a multi-tasking, non-preemptive multi-tasking.

GEM in ROM allows you to run 7 programs at once - six accessories and a main PRG

 

http://www.stcarchiv.de/ap/04/multitasking

 

Edited March 20, 2020 by Cyprian_K

[ParanoidLittleMan]

It is not real multitasking. Usually called quasy-multitasking. And user can not start new task just like that.

In case of Atari ST it is MagiC which OS had real multitasking - just another case when some(one) independent did it better and faster .

Atari/DRI worked on it in case of Falcon OS, but it was just too late.

In my opinion it was too early for multitasking in 1985 and few years after it. One of the reasons is lack of support in CPU for that. I really did not see someone serious complaining that TOS has no multitasking. Users were happy to have plenty of RAM, GUI, lot of colors in those years, for less than 1000 bucks.

[Cyprian]

yes and no.

TOS allows user to have running up to seven applications at the same time. They switch the context on their own (e.g. via Event-multi).

This kind of multitasking is called non-preemptive or cooperative:

https://en.wikipedia.org/wiki/Cooperative_multitasking

 

That's true six applications "accessories" can be changed during booting process, but they still work in multitasking.

[xorcerer]

On 11/27/2019 at 1:33 PM, ParanoidLittleMan said:

[..]

Link for DL: http://www.chillichai.com/atari-st-review/cover-disk-downloads

STREV06_2 .

To add that in my improved TOS, with option to force AES AUTO run, dialog appears when both are in AUTO folder.

Not bad PRG, that ANTIBOMB, and I never heard about.  Too bad that I got used on Steem Debugger ?

Just to update link (outdated now) to ST Review coverdisk archives, currently here (link updated 9.05.2022):

https://chillichai.com/atari-magazine-archives/atari-st-review/

Thank you for great food for thought! I've always avoided TOS as much as possible (yes, unclear and missing docs weighed in), but I had to - at some point - not to rewrite a lot of basic functions. Your input on AUTO specifics is very valuable - thank you again.

Edited May 9, 2022 by xorcerer
new links