Number 32, Atari ST and me

[ParanoidLittleMan]

This is not usual thread, and maybe rather belongs in programming section. But I think that may be interesting for those not so familiar with binary numbers.

 

So, this year is 32 years since I bought my first Atari - ST 520 , with TOS 1.00 De, in Germany.  I was then guess what:  32 years old ?  And what ST means ? Sixteen thirty two . It was time when 16-bit micros, with 16-bit CPUs started to take over the market. And Motorola 68000 was leader then. CPU has 32 bit registers . Most of operations have 32-bit mode . Rare exception is multiply - that works with 2 16-bit values, while result is 32-bit . Similar is with divide - of course then divider is 16 bit, and result is 32 bit too, but special.  Surely, doing full 32 bit for them would take a lot of extra logic in CPU .

Now, how much Tramiel (or who's idea was that 'ST') was right with calling it 32-bit ?  Address bus is 24-bit, so partially right. CPU was for sure more 32-bit than 16 . The real thing by me is SW. Including TOS . How much 32-bit TOS is ? Indeed much more than DOS of that time, done for not 32-bit CPU 80286 . It could address much more than 2 POW 16 RAM (64 KB), but that was with segments. While 68000 could address all it linear, with real 32-bit program counter.  And in TOS there is lot of 32-bit jump, jsr, memory access.

The bad part: Despite said about TOS and DOS there is something really absurd:  how it happened that hard disk filesystem of TOS - bigGEM - variant of FAT16 is not really 32-bit one, and FAT16 of DOS - bigDOS is more 32-bit ? Without going in deep details, just this:  BGM (bigGEM) uses still 16-bits for sector addressing inside 1 partition (logical drive), for capacities over 32 MB. While bigDOS using then 32-bit addressing.  After years spent with examining TOS 1.04 and others, dealing with hard disk driver SW I can have only 1 explanation:  the problem was used Alcyon C compiler by Digital Research. It had some limitations with unsigned integers and who knows what else, and they went on using 16-bit code for sector addressing, for partition sizes over 32 MB. And because that needed to use large logical sectors instead native, 512 byte long sectors. And incompatibility. And less efficient work.

https://atari.8bitchip.info/ASThdFAQ.html

The worst thing is that it did not change over years, so even TOS 4.0x, from 1992 still using those large logical sectors - only that expanded max partition size to 1 GB, at price of logical sector length of 16 KB . And that meant cluster size of 32 KB, just to not forget about what this thread is ?

Atari SW was generally better in this. There were better compilers than Alcyon. Surely capable for good 32-bit code. And that was important, as program code and data sizes went up. Over 512 KB - only for main executable.  Atari ST was popular, especially in Eu . CPU was powerful enough to be able run games with good scroll without extra HW support.  Or for some serious, like CAD, databases usage. I knew people using it for their business. 

There is another thing what should be 32, but is 16 in TOS - count of accessible logical drives - starting by A: .  Well, I can proudly say that it is fixed too now ?