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 .
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
Game instead TOS
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
Supporting SWAtari 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.
Interesting details from TOS historyBy
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.
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.
? 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.