Spanish TOS 1.62

Swiss German:  1.02SG   1.04SG   2.06SG    1.62SG - this one is built by me, using 1.06SG and 1.62DE .
Interesting is that in this SG TOS versions even 3 different keyboard tables are used. 1.02 and 1.06 have same, and I used it in 1.62 - by recommendation of Atari fella from Switzerland. What is in 1.04 is very similar to German, and ß is on same key. In 2.06 is something diff. I can not say more - try it if want. Warning: in emulators it will probably work not 100 % faithful.

Magic 6.2 Eng  translated fully to English, with some additional files, MagicRAM ...

Spanish TOS 1.62 + little gift in free ROM space, the key is g :-)

1.04UK without Line-F  - Special 1.04 build, using AES code from 1.62, which is without Line-F 'calls' - since it was in bigger ROM space (256 KB (STE)  vs. 192 KB for 1.04 (ST) ). Still, it fits because used optimizations and packing of RSC, Desktop.inf template data. Actually there is exactly 11000 bytes of free space at end. And nothing is removed, and there is patch for large file sizes displaying added - against crash in textual mode. Some related interesting details about problems by placing TOS in planned/limited ROM space in first years - below.
Ah, and according to some speed test SW like QUINDEX, GEMBENCH GEM dialog and window operations are faster by some 7-10% with this than regular 1.04.




Some  good games can fit well in TOS ROM space. From TOS need only HW init and some basic functions like txt print - in case of games not using  TOS calls (txt print is used for trainer settings actually).

Archipelagos for ST machines

GoldRunner for ST

GoldRunner for STE

And even those using TOS calls can fit, but shorter ones. Usually only GEMDOS part of TOS is needed.

Garfield for ST

Atari program to split ROM image into Hi, Lo parts, in 6 parts for STs  Fix of CRC for TOS 2.06 opt.

TOS dump PRG - will save binary image of ROM TOS, with version number and language code.

Time Set programs  Short programs to set Atari ST system time good for years at 2000 .
Needed because TOS is not ready for years at 2000 if there is no active RTC chip.

By some sources Atari planned in 1984 that ST (basic model) will have 128 KB ROM and 256 KB RAM. That was just too optimistic for machine with graphical user interface and 68000 CPU, especially as big part of TOS code was done in C, and only smaller in ASM.
And what happened  at beginning of 1985 ? They abandoned 256 KB RAM idea, 512 KB was basic amount, and for TOS ROM 192 KB was provided - what should go in 6x 32  KB (EP)ROMs . But TOS was not ready, and they had problems with code size - did not fit in 192 KB. So, in beginning ST was shipped with only 16 KB Boot ROM, what loaded TOS from floppy into RAM. And could load some SW too, like game. They even supplied DRI Basic, what was by me just bad move - I did read some reviews where they were shocked with how little free RAM left for Basic programs in machine with whole half MB RAM ! (Yes, then it was a loooot). Plus, DRI Basic was just not user friendly, feature rich, and never became popular.
Programmers got as main task to squeeze TOS in 192 KB space, without removing anything relevant. More ROM chips were out of consideration because space and price, and also using larger capacity ROMs would cost too much. And they managed to shrink size of TOS 1.00, so it fit in 192 KB.
How ? With tricky solution called Line-F emulator. Based on fact that any opcode starting with hex $F is not implemented in 68000 (reserved for later revisions of CPU). So, they used in AES/Desktop (or GEM) part of TOS Line-F instead usuall bsr, jsr subrutione calls, which are usually 4 or 6 bytes long.
Line-F can be only 2 bytes long, and from that 12 bits can be used as data ! And yes, that solved the problem, and it went in 192 KB space . The price: little slower work. And of course, plenty of time, effort to code all it.
Well, what I can not understand is, how they did not see much better way: packing of RSC/desktop.inf template block, what is located at very end of TOS, and is simply copied to RAM at AES init. There is lot of text, some graphic (icons), so it is well packable. Even with not much efficient packer would save some 7-9 KB space (data is about 16-18 KB), and that would solve fitting in 192 KB space. And that's not theory - I did it, and it works fine, more space is welcome.  
With better, well much better C compiler than Alcyon plenty of space could be gained with code optimizations - like short addressing whenever it is possible,  etc. That self would give another 8-9 KB free space. But it seems that DRI was not motivated too improve it. Even in 1989 it was not efficient, and I saw some strange bugs in 1.04 for instance - like same branch 2x in row (compiled code part).  And C compiler is probably main culprit for not so good FAT16 (for hard disks) in TOS. What hurts most is that they did not use 32-bit sector addressing on really 32-bit CPU ! Some others used it with 16-bit CPU (80286) .




    PP,  Febr.- March  2021.