| Probably most is not aware that TOS consists from 2 clearly separated parts:
1. The GEMDOS part, what actually contain: early HW initialisation (after power on, reset), BIOS, XBIOS, GEMDOS
and character sets (8x8 and 8x16 px) - latest is placed after AES part, from for me unknown reason.
2. The AES part, what contain AES (GEM) self, then Desktop. At the end are some RSC structures for Desktop, file selector.
AES part, Desktop never calls some subrutine from GEMDOS part directly - all it goes via system calls, so Traps - #1,2,13,14 .
That's very good - thanx to it, we can combine GEMDOS and AES from different TOS versions.
As is known, most of TOS code is done in C, in ASM is
done mostly low level HW accessing part. Myself think, that it was
choice what seemed then as only reasonable, and they just followed
usual way, used with Intel 16-bit CPUs (8086) .
But, it is now clear, that Atari and DR (Digital Research) did not have
good enough C compiler in those years (at 1984 to 1992) - hmm... maybe
the Orwell's year was the problem :-)
They had problems to fit TOS in provided ROM space (192 KB) - in big
part just because not efficient C compiler. And maybe because
programmers were not experienced with MC68000 CPU coding. Not
only that code generated is not much efficient, considering space and
speed, some simple things were done not optimal. And that could save
plenty of space.
Addressing: in TOS versions 1.xx there is no short
addressing used at all . With 68000 normal addressing is 32-bit. But,
if address is in range 0-$7FFF or eqaul to and above $FFFF8000
you can use 16-bit addressing. That saves 2 bytes per addressing. And
since there is plenty of it in code, that can save some 4KB only in
GEMDOS part - and it is what is possible with TOS 1.04 and 1.06/1.62
(which are pretty much the same). In case of 1.04 4KB means a lot,
since there is only 1KB free space in org.
What happened in 1989, when 1.04 and 1.06 were released ? 192KB for
1.04, and that was not enough for straight code. They needed to use
Line-F emulator to save some space. With 1.06/1.62 it was better, since
there was 256 KB space in STE.
Looking in TOS 2.06 code says that most of it is optimised, so 16-bit
addressing used when it is possible. Little funny that then was no real
need for it in 256 KB TOS ROM.
And we are at for me biggest mistery in TOS: FAT16 filesystem
code, with Big partition support (over 32 MB), and yet 16-bit recno
(called logical sector too) - sector address in fact. There are some, mostly incomplete TOS sources available.
And there stays for recno variable: "it should be 32-bit" . Great !
Then why is not changed to it ?
Well, my latest founds (end of June 2018) indicate that used Alcyon C
compiler was bad with unsigned integers even in 1991.
What is really something even hard to believe. What developers of it
did over 6 years ? Of course, it could be solved even with that flaw of
compiler, at some extra work.
What is sure is that it did not happen. Not in Atari. Some did it -
MagiC first, most likely. And as last - I did it, but not in C sources,
but in disassembled S 'source' . That way had it benefits, but was for
sure much harder than doing all needed corrections in C. Main benefit
was that I needed to look how to manage GEMDOS code length same, or
shorter, since right after it comes AES, what I did not want to change
or move. As I seen all those not necessary long addressings, normal was
to go on optimising. It needed some more accurate disassembling (labels
instead constants in some 10 sections, actually) - and that resulted in
4KB shorter code, even with added things.
Now, in 2018, I can only think that reason for was lack of motivation of
employees. I hope that we will hear something from someone involved in
it, some day.
Adding at end of June, 2018: I think that I will not bother anymore myself with
trying to contact someone of people, which worked at Atari, maybe DRI
that time. That's just too frustrating, and even if you make someone to
respond, that's usual short answer - maybe will talk, will see
... Then nothing. So, forgive me if there are some mistakes
and too much speculation. That's all what I can to provide. I
like to know what and why happened, and if people talk not, there is
something what talks: code in TOS .
I seen lot of it there, what could be done better, often with really simple solutions:
digged little more in TOS, and seen that AES RSC and Desktop RSC +
Desktop.inf template are copied 1 to 1 in RAM, and that's some 16 KB in
case of 1.04 and 1.62 - so they are in ROM and RAM at once. Indeed,
some parts must be in RAM, because of changed coordinates, flags, then
editable txt, but there is lot of static txt, what could be accessed
from ROM. After disassembling AES part, I seen that it is simply copied
all 3 together. And that's good for packing. So, I packed that section
(what is at very end of TOS ROM), and that went shorter 10 KB.
And was able to optimize AES code too - shorter 2 KB. So, at the end, I
was able to make TOS ROM code for 1.04 and 1.62 shorter for 16KB.
Without removing anything !
To add that in 2.06 it is done better - static parts stay in ROM, no
copy to RAM. And there is more important, since all it is longer.
This opens whole new perspectives - there is lot of free space now even
with 1.04. And it can now be modded to work with 68020-30 accelerators.
It's not possible with 1.04's AES, because line-F emulator. But now we
can use Desktop of 1.62 in 1.04 (they are practically same, except
line-F). It is longer some 8KB because not using line-F, but straight
subrutine calls - and now, there is space for it in 192KB ROM space. I
have already 1.04 modded for long stackframe, so that can be assembled
in short time. And of course, there will be still place for improved
FAT16 and Virtual Floppy.
Next thing to do is little 'artwork' - changing Desktop icons, to
clearly indicate modded TOS v. Sorry, no plans for some multi color
icons - that would need more RAM and AES extensions.
More can follow, some day :-)
PP, May 2018.