Jump to content
IGNORED

SW Programming for Atari ST - what way is best ?


Recommended Posts

Well, only one answer can be true, and that's - there is no such thing as 'best' - in this case, as it is with most of things in reality.

What is best is:  compromise, balance, harmony ... And I would add: experience, doing it in way what is best for program's purpose, target users . Yeah, latest means well known thing: what is best is subjective.

 

Atari ST SW is very interesting because it was made in years where C  gradually became most used progr. language for home computers too. And CPU had support for it (yeah, those link commands for instance) .  Here to add that C compilers in those years were not so efficient as modern ones - surely because limited computer power, RAM. And of course limited experience, time for development.

 

So, as is known, TOS is written in big part in C, about 80-90% . Rest is done in ASM. And that's good, could say best compromise. Speed critical parts were done in ASM. Here to add that ASM code is not only faster in execution, but shorter too. 

And because coders of TOS (at Atari and DRI) encountered one unexpected problem in 1984-5, they were forced to make TOS 1.00 code shorter, so it fits in 192 KB space. Or to remove some functions. And here came compromise in action: no drastic measures like enlarging ROM space for TOS (price increase), no removing functions.  No even doing more parts in ASM - although it would be 'best' - yeah, but how much time programmers with short time experience with 68000 ASM programming would need for writing some 50-100 KB ASM code ?

So, they used special way, called Line-F emulator. It is actually subrutine call, but instead 4 or 6 byte long code for, it is only 2 bytes long, + 1 of them is data (function #) . With it some 5-6 KB space is saved, and it fitted. At price of little slower execution. Yeah, compromise.

 

And is worth to mention another OS done for Atari ST:  Magic . It has %-ally more ASM than C. I would say about 50-60% . And probably they used better C compiler. And yes, there were better ones than what DRI made (Alcyon) in those years.  Still, Magic never became much popular, maybe only in Germany. I guess that multitasking was not so important for people then (I really did not miss it much). There was better FAT16 than in TOS, but that was useful only for people with larger hard disks.  So, yes, TOS was good compromise ?

 

  • Like 3
Link to comment
Share on other sites

Quick look says that with EmuTOS it is same as with TOS 1.xx - about 15 % is ASM . Talking about 192 KB version for STs .

Of course, today the generated C code, with new C compilers is faster, shorter, so can put more of it in same space.

Comparing what is done 35 years ago with today SW (EmuTOS 1.00 recently released) is not really good idea.  + there are EmuTOS versions with 512 KB size, with much more features, of course, but you can not run them on some ST, STE . So name EmuTOS is OK ?

 

And funny thing is that despite all said, EmuTOS is slower with hard disks than good old TOS 1.04 (did not check other versions). Well, I'm sure that they think it different, but I have my methods of measuring, and believe in them, of course.  Yeah, some may ask: how can it be slower when is compiled with better compiler ? 

And that leads to so far here not mentioned, but really very important thing:  efficiency of source code, concept. Well, DRI knew some things well, and Atari's FAT16 is pretty fast in fact. Could be better  (faster than Amiga's filesystem- with floppy, with hard disks) . And could be slower - as we see, even 35 years later. , the later is slower.

 

And, even I did not plan to talk about it here, but since EmuTOS is mentioned: 

What OS is better - compatible with old, new SW for machine, family ?  Or OS not so compatible (and not so here means at least 30 % of SW) - made with forcing some standards or whatever at all cost, just to be good looking on paper, and ignoring real needs of users - running good old SW on their old machines, or in emulators ?

Let's be real: no one sane will use his old Atari or even it's clone to run only new SW. The real thing is old SW. + I'm sure that EmuTOS is not compatible even with some new creations.  Sure - they will say - blame programmers of that SW - they 'hack', not programming - and I write it from experience. Written concrete case(s) right here, in this section..

It is nice that there is real FAT16 in EmuTOS, but it is not compatible with lot of SW. Solution is easy: allow it to use instead built in driver usual Atari ST way: hard disk driver autoboot.

 

Repeating myself: good SW is what is good for users. In case of OS users are SW too ?

 

Edited by ParanoidLittleMan
grammar correction
Link to comment
Share on other sites

Well, to my understanding, the initial use case of Emutos is to have an OS compatible with TOS api (bios/xbios/gemdos/vdi/aes) to avoid legal problems with using copyrighted material on emulators and new clone. That it can be used as an alternative OS on real legacy hardware is a bonus.

 

Even on STe, I would keep TOS 1.62, I would not go into even TOS 2.x because of compatibility problems with old games, exactly like you said.

 

Link to comment
Share on other sites

Yes, formally, on paper original TOS versions are all under copyright. In reality nobody cares, nobody asks in last 15 or more years sites which host them for DL, to remove them . To add that there is much worse piracy on right now - new SW, new movies, music etc. For instance known HW add on manufacturer for Atari machines won't go in modded TOS distribution if it is not copy protected. Hard problem in case of ROM chips. Is solution to give all SW for free ? Maybe, but not in this World, where life is more and more expensive. Plus, doing SW requires time, some equipment, WEB host, etc. All it is money.  I added it on, because they usually prefer free SW. Well, as things are today, people will rather pay something, if it is what is better for them. Windows vs. Linux for instance. And I use both over 25 years.

 

Compatibility is bad, and not only with games. Much worse than in case of TOS 2.06 . I talked with people working on it few years ago. But as usual, they act 'academic' , even if I went on university too. And on something what they not, it seems - school of life ?

 

 

Link to comment
Share on other sites

OK, let's do little language talk here (and I hope that will not be accused for talking about what I don't know ? ) :

Spor in slav languages (in Czech, Serbian, Croatian for sure) means something like dispute. Sporny or sporni would mean disputable., but others, mentioned in previous  post are OK too.

So, maybe to make in this compromise too. German with some slav influence. Or mixed roots .

Link to comment
Share on other sites

Surely, it is best to have it all in single file. For instance I integrate GEM RSC files (which are 'compiled' with special programs for it) in main executable (usually only file). And it is fine while computers of average users have enough RAM for that.

Something like C compiler might be simply too much for Atari ST with 512 KB RAM. So, it needs multiple files, and not only data files, but those with code, and load what is needed at moment, then reload other .... Not really ideal for floppy only people.

 

And there are games too, with multiple levels, and some load new levels as practically separated executable, with integrated graphic, sound. Maybe even written by different team than other levels.  Example:  Iron Lord .

Link to comment
Share on other sites

2 hours ago, Donna45 said:

After you know the language you are going to program in, it is important to think what would be the simplest way of starting your program. A good start is to put all your code in a file called. Do not think that you can do better. The advantage of such a file is that in the first compile you get a simple example that you can compare your idea with. This does not give you the advantage of a program with a specific and complicated design. 

Do not fear the linker. It's your best friend in facilitating code modularity. 

Link to comment
Share on other sites

I got enough modularity using includes in my first asm project. However I doubt to get reusability like this, beyond trivial things.

 

To me linker is your friend as soon as you have libraries (especially 3rd parties libraries). And then I believe that most of the time it means high-level languages, with C calling conventions its heavy use of the stack.

 

I see that in asm, I tend to favor meta-programming using macros and trying to avoid using the stack and subroutine. I mean I have key sections that are subroutines, but then each are a big chunks of code, contrary to what I do in C/Java where one try to have short function, extracting parts when it's getting too big.

Link to comment
Share on other sites

Well, high level languages favor "speed of reuse", avoiding globals speeds mix-n-match. They like to use the metaphor of L'ego bricks to play with (and I totally profit from this in my daily job with Java)

 

To me the strong point of asm is to be able to micro-manage the scarce ressources we have for better efficiency .

 

 

Link to comment
Share on other sites

  • 4 weeks later...

As an aside...  When you start to study the Atari ST system routines it *really* gives you the impression they mashed a bunch of stuff together under a very tight deadline.  Which is exactly what they did.  :)

 

The outcome was a pretty good machine that kept Atari going for a few more years.  

Link to comment
Share on other sites

19 hours ago, ParanoidLittleMan said:

I agree with that. The reason for tight headline was probably lack of experience with 16-32 bit CPU, GUI. Surely they misjudged ROM and RAM size needed for good and fast work. Original plans were with 256 KB RAM and 128 KB ROM.

 

When did they start working on the ST?  It was released mid 1985 so probably sometime in 1984?  The 68k was released in '79 so I suspect lack of experience with the silicon wasn't a major factor.  The end result is the natural consequence of having multiple teams just banging away on their stuff without any overarching architectural software direction.  When they came together they then had to go through an exercise in trimming duplicate code/features to fit the memory budget.

 

Some of the foundational code in the bios can be easily outperformed with hobbyist level assembler skills (LINEA anyone?).  I'm sure they were working from the general case though e.g. "Get something that works good enough...we have other stuff to do!"

 

There's a blog out there from someone who was on the ST team - the story sort of reinforces the above - it's an interesting read from the perspective of Atari History *AND* quick turn around product development and the trade offs that have to be made during the process.

 

Link to comment
Share on other sites

4 hours ago, damosan said:

When did they start working on the ST?  It was released mid 1985 so probably sometime in 1984?  The 68k was released in '79 so I suspect lack of experience with the silicon wasn't a major factor.  The end result is the natural consequence of having multiple teams just banging away on their stuff without any overarching architectural software direction.  When they came together they then had to go through an exercise in trimming duplicate code/features to fit the memory budget.

Development started just after Jack Tramiel and Shiraz Shivji left Commodore in early 1984 before they bought Atari.

Link to comment
Share on other sites

13 hours ago, ParanoidLittleMan said:

LINE-A is actually coded in ASM.

I know.

 

They were coding for the general case trying to be conservative with memory consumption, etc.  It's all a balancing act of course.  We also know it's relatively easy to outperform the LINEA routines across the board if you cache line indexes, etc.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...