Making Atari ST SW around 1987

News,announcements,programming,fixes,game patches & discussions.

Moderator: Petari

Post Reply
Petari
Software Moderator
Software Moderator
Posts: 560
Joined: Tue Nov 28, 2017 1:32 pm

Making Atari ST SW around 1987

Post by Petari » Tue Aug 14, 2018 9:55 am

This is intended as some kind of reminder for those which were active in those years, and probably as something new for those who like to talk about not clean coded, so not good SW, who now talk about making it platform independent ...

So, what someone, some firm, crew who decided to make some Atari SW needed then: surely not Internet access. Some Atari for sure, and literature.
And there was not much of literature available. Atari published some Hitchhiker Guides and like. I guess that it was little better in Germany, as country where most of Atari STs was sold. There was Atari ProfiBuch, pretty much complete book with TOS, HW parts, even some code examples in C and ASM.
There were books about MC 68000 CPU too, of course.
Many of them were experienced with some 8-bit CPUs like Z80. What means usually no practice with C too. Actually, C was not much used in home computer area before ~1985. So. using ASM was choice of many, especially for games. And old habits can not vanish just like that. So, there is lot of unnecessary test, or even worse, compare with 0 instructions after data move. Because 68000 is smarter (evolution) and sets flags during data move, unlike Z80 . That's not some error in fact, just makes code little longer and slower.
The real headache starts when you need to use TOS function calls. Then you realize that available docs does not cover everything, there are some errors too. And that can not solve everything with TOS calls. And of course that it may be just slow.
I think that best example for poor docs is XBIOS 34 Kbdvbase function. There are vectors for keyboard, mouse, joystick read, which addresses you can read with this function, but docs just don't explain in detail how to read, interpret data when intercept (hook) there. Even today, I don't see complete docs for joystick read, for instance, although it is pretty simple.
So, programmer who wanted to read joystick could use own, direct ACIA chip access code - what is not so easy, but at least it is pretty well documented in Profibuch for instance. Looking in TOS code for input read helps a lot too, and I'm sure that many used that.
Using TOS joystick read, and look variables for it's state. That's very simple, but there is problem: those variables are not on same loc. in diverse TOS versions. Yes, this is exact reason why many games work only in TOS 1.00-1.02 for instance. Even STOS did not solve it better. It uses address tables for different TOS versions, and later ones just missing.
Another example of poor docs is example code for ACSI hard disk sector access in Hitchhiker Guide, what was printed in ProfiBuch 1987 too (not in later editions). That works, but only when only 1 device is attached. In case of more not. So, just another case where programmers self needed to figure out proper way. Yes, this latest is what was needed so many times. All that talk about clean programming from people who made couple programs, mostly for own pleasure just shows how they have no knowledge about what early programmers did, lack of respect. It was pioneer work, regardless from intentions. Some did it for money, some to learn something, making something usable for people. But every programmer wants good, reliable and reasonable fast SW. If possible compatible with future OS versions. And that latest is just what was not much successful in case of TOS.
You can blame programmers. and they are who used not future proof code in many cases. But that was sometimes caused just by poor docs.
On the other side, Atari made some unexpected changes in HW and SW design - most in TOS 2.06, what is known as 'not good for gaming' .
I just can say that if high level programmers at DRI and Atari made some mistakes, why we should expect that programmers of diverse SW would be better ? They did in most cases very good job, and in many excellent one. Pushing HW to limits, and sometimes even over it - like Spectrum 512 - who would expect then that it can show all 512 colors at once ?
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

Post Reply