ParanoidLittleMan Posted November 22, 2019 Share Posted November 22, 2019 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) . 3 2 Quote Link to comment Share on other sites More sharing options...
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.