It is 40 years now since first Atari ST models arrived in shops, so really good time period to write some interesting and actually even useful details for people using still them, and/or want to run, check old Atari ST SW even on not original machines - like emulators on modern computers, or HW kind of emulators (MiSTer for instance) .

   As could expect after first paragraph, Atari ST was launched in 1985. As next generation (for that time) home/business computer, with GUI (graphical user interface), mouse as standard equipment, floppy drive, hard disk support in HW and OS. Atari ST's OS is called TOS, and consists from 2 main parts: GEMDOS - responsible for boot, HW, disk/file handling. And GEM - graphical environment manager , + Desktop as part of it, where most common tasks can be performed.

  Here will not go in HW details - there are pages here and all around WEB dealing with it. This page is dedicated for Atari ST TOS (as title says), and all it is actually not so simple. Only one thing - used CPU (main processor) is Motorola 68000 - then pretty advanced and not so cheap CPU, but prices went down, as prices of memory chips too.

  So, the new owner of Atari company decided to develop and launch new home and partially business computer with GUI OS (graphical user interface operating system) - as it was then 'in' , together with then in Motorola 68000 CPU (yeah, was in Macintosh :-)  ).  And there were some good ideas:  being compatible with then mainstream PC and it's DOS (based in big part on CPM) , having plenty of RAM, and CPU what can deal with it - what actually means 32-bit program address counter. And it was 68000 CPU then, among affordable ones for home computer.  All it about CPUs is pretty well known, probably main thing was to get them among very good conditions. And Tramiel was good in such things.  More complex thing: developing OS for that CPU, and much more complex one than OS for that time home computers . So, Atari c.  choosed DRI (Digital Research Inc.) for that task - and DRI had good reputation as developer of CPM .
  Sure, it was good way, as there were no people with some better experience in all it at Atari c.  . DRI made his 'Concurrent DOS' for PC, and it was not big success, but worked well. But as I see, they did not have any experience with 68000 CPU - and that may be really important part of whole TOS history.   How some OS for PC, Mac and like computer was developed then ? Well, for sure in C language - well biggest part of it. And that needs good C compiler. Well, here we are at part what can explain some problems in TOS (yeah, I used word 'can' instead 'explains' simply because all it is my interpreting of reasons, details and like. I just don't like claiming as for sure of things about which not have complete access and all informations.  Everyone who comes with better explanation(s) is welcome.
 
 First TOS version:  it is called floppy TOS 1.00, and was present in early STs - spring of 1985 . It was just shorter ROM, with code to load TOS from floppy - and that was not how it was planned. Big disadvantage is of course that it uses lot of RAM, so only about half of 512 KB left for SW what user runs.
 Most interesting part in it is reason for it.  And it is that TOS 1.00 early development v. did not fit in 192 KB ROM space . Designers gave 192 KB space for TOS ROM, what goes in 6x 32 KB ROMs, and there are 6 28 pin sockets for that. Well, better would be to use 2x 128 KB - more space and only 2 ROM chips (still 28 pins with factory programmed ROMs, in case of EPROMs it needs 32 pin sockets) . So why 192 KB, 6 chips ? Only reasonable explanation is prices of ROM chips then.  
 How they made it fitting in 192 KB space ? Nothing is removed, programmers found a way - and it is done with so called Line-F emulator - will not go here in details how it works, what matters is that it makes possible much shorter code by TOS AES function calls , and there is lot of them in AES part of TOS, for screen operations, GUI functions.
 With it they made TOS size shorter by some 8 KB, and that was enough to fit in 192 KB space.
 First Atari STs with complete TOS 1.00 in ROM arrived in shops in November 1985 . That was big improvement, and I would say important for bigger sales, much more new SW for ...  For instance ST games before it were with low level floppy access, so not using normal filename/DIR name based access, as it was not in ROM, and if would load TOS in RAM, some 200 KB less space would be for game . Not to mention cases like DRI ST Basic - with 512 KB RAM only some 10 KB left for Basic program - what was mentioned in some magazines as big flaw.
 And yes, sales went up, especially in Germany, West Eu. And more and more SW was developed for.
And actually, most of games, some 65 % was with disk (floppy) access via TOS functions (FAT12 filesystem).
  Here need to mention some silly writings in later years - worst I saw is on Github, and says that Atari SW SW was buggy, as TOS was buggy too. Mentioning that old SW  " rely on weird patterns or buggy TOS error codes to work properly" .
  Total stupidity . Before going in such talk should look TOS DOCs and other literature - and there is plenty of it online.  Filesystem TOS calls are pretty well done, and nothing is weird. And it works reliable. I know it well, as I programmed it since 1987. Bought Atari ST ProfiBuch at same time as Atari ST.

  Further TOS versions:

  TOS 1.02  -  called Mega ST TOS, as it came first in Atari Mega ST - 'professional' model with separated keyboard, bigger case with place for upgrades, hard disk, with expansion connector. Some smaller improvements and added support for then new blitter chip. Year is 1987 .

 TOS 1.04 - year is 1989, and it is called Rainbow TOS because Atari logo effect in Desktop Info. It has pretty much improvements and is actually latest TOS v. designed for ST machines (incl. Mega ST) .
 For instance max supported partition size is 512 MB (in 1.00 and 1.02 it was 256 MB), faster and more reliable work with hard disks, some Desktop improvements.  Still with Line-F emulation.

 TOS 1.06 - year 1989, for then new Atari STE (E is for 'enhanced' ) - pretty much same as 1.04, for instance filesystem code is practically same. It has extra code for new HW in STE:  audio DMA, enhanced color palette, HW scroll in video chip.
 And because it did not fit in 192 KB ROM space, so start address is changed (from $FC0000  to  $E00000) and size is 256 KB, in 2 ROM or EPROM chips (32 pins) . And need to mention: some SW worked not because that TOS ROM address change, so needs patching. Luckily they did not use Line-F emulator, as there was enough space for direct code, and that means some 8% faster work of diverse screen operations.
 Unfortunately there were couple bugs, so version 1.62 was released soon. I would add that I found bug in audio mixer code - as it has 2 audio sources - usual PSG as is in STs (YM chip) and DMA audio. It will set 4x lower DMA audio level in some cases, and that means too silent DMA sound, especially bad if works together with some PSG audio. I made patch for it. Was not fixed by Atari.  Probably because not so many SW, game used DMA audio.
 And yes, 1.62 is latest official TOS v. for Atari STE machines.

 TOS 2.05 - 1991, came with first Mega STE machines. Soon v. 2.06 arrived, with some fixes. It has pretty much improved Desktop, IDE hard disk autoboot code and other things added.  And is made to work on ST and STE machines (but needs little HW add on with STs, because different ROM start address).  Not recommended for gaming:  uses more RAM, so some games will not work, even if there is 1 MB or more RAM, as some are coded for lower start address, and it conflicts with TOS 2.06 workspace. And floppy code is changed too - it uses Timer-C (because HD floppy support) and if game changed Timer-C settings floppy will not work.

 TOS 3.06 - 1991 - TT TOS.  Pretty similar with 2.06 .
 TOS 4.02 - 1992 - Falcon TOS .  And there is 4.04 - later Falcon TOS - it has max 1 GB partition size support. 4.02 same as 1.04-2.06 .

  Of course nothing is perfect, so little about Atari ST TOS flaws:
 It will be not about all of it, plus it is for sure little subjective. There are problems with some situations which happen only by little %-age of users, and some patches, fixes, programs for were released.
  I was always interested a lot for storage, and in the beginning (1987) coded some floppy utility SW - like floppy format program, some copy accessory solution combined with RAMdisk . That was useful in those times when only small %-age of people had hard disks.
  And prices went down, so I bought my first hard disk in 1992 - IDE one, 40 MB capacity. After reading how IDE disk work in  PCs (in book about PC HW) with usual home/small business computers (with lot of details) I realized how IDE adapter for Atari ST needs to be designed.
 And I did it, and it worked well. Used then exising hard disk driver SW like AHDI. Important thing even then was easy data transfer with some PC (of course with DOS then) - and it worked well actually. But little later I found that it worked well only until partition sizes of max 32 MB . And I was for having couple smaller partitions instead one bigger one (as I do today, still) - that makes it little better organised. It was when I purchased some larger capacity IDE drives ( 2.5 inch, 160 MB) - and tried with bigger partitions than 32 MB. ) - Well, it needed lot of time and experimencing to realise that 32 MB limit.
 And of course it was bigger and bigger flaw as hard disk capacities raised.
  This is really longer story, so I will jump to what I realised many years later - like about 2001-2008:
 TOS-es FAT16 filesystem is not fully compatible with then widely used DOS FAT16 filesystem. It was not bigger problem with smaller disk capacities earlier.  So, after lot of experimenting, tracing I found exact reason:  TOS FAT16 uses only 16-bit sector addressing - and that's good only up to 32 MB partition sizes. Over it 32-bit sector addressing is needed - and that was present in PC DOS, even with 16-bit CPUs .
 TOS programmers went on solution called large logical sectors - simply joined multiple sectors as group, and so could address all sectors on larger sized partitions with 16-bit value - like on 64 MB partition - what  is 131072 sectors - logical sector size is 1024 bytes . And of course more with larger partitions - 512 MB means 8 KB logical sector size. But is is actually worse - max logical sector addressing value was not 2 POW 16 -1 , but 2 POW 15-1 (TOS 1.04 and higher) . So, with partition sizes between 256 and 512 MB logical sector size is 16 KB . And that's not good - means less efficient work, need for larger buffers .
  And of course everyone will ask :  why it happened ? To be sure, we should know how it was with DRI's Concurrent DOS for PC . I did not think about it earlier. But if then it was with 32-bit sector addressing, then I have only one explanation: DRI C compiler for 68000 CPU had some flaws - like being not accurate with 32-bit integers. So they used 16-bit ones in filesystem .
 I even saw some comment in C source file for TOS 2.06 - 'it should be 32-bit' . I never saw C sources for some TOS 1.xx . And if it was not 32-bit in 2.06 certainly was not in any TOS 1.xx  .
  OK, it's easy to be smart now. In those years - at 1984 people did not have experience with 68000 CPU, so it was not easy to programm it in ASM, or to make very good C compiler for it. Actually, maybe better question would be: why it was not made 32-bit in later TOS versions ?  Sure, it would break compatibility.  And if Atari would last longer, that would be must to correct.
 Anyway, all it still does not mean that Atari ST TOS was buggy. Just that some things could be solved better, even then.
Hard disk (FAT16 filesistem) flaws became problem much later - like in 21-st Century. Remember:  max partition count is 14 (C-P), max partition size is 512 MB - it means 7 GB - and not much people had so large capacity hard disk in year 2000 .

  How to solve work of good old Atari ST SW in this years (2020-es) ?

 It is actually complex question. Some prefer making very detailed images of original floppies, and there are devices and SW for such image making. Image sizes may be pretty large - like 50 MB for 1 floppy image. And latest emulators support those formats.
 I'm not fan of it - for instance because I already made hundreds of hard disk adaptations before those devices appeared. And of course hard disk run is faster, added some corrections, better TOS version compatibility , and state saves at any moment during play. Not to mention cheat options.  Of course some will say that only original is real . Their right.

 Other way, still with floppies is using so called 'cracks' - they were done long time ago, and most of it is on so called menu disks, packed with system what has slow depacking with Atari ST - so longer waitings, not present with original.
 And there are errors, corrupted parts (for instance during copying it) and what I hate : lot of cracker, pirate crew messages before game start (sometimes even in game) - mostly self praising.  Let's just say: obsolete, unreliable.

 Third way is running games, old Atari ST SW from hard disk, now rather SD cards. And some dealt with it already in 90-es. Like crew Superior. It worked only with partitions under 32 MB size, what was good then, and now ? We know answer.

  And how is it in 2025 ? I'm sure that most of people with real Atari HW now using some mass storage for running old SW. Because old floppy drives and disks are broken, unreliable, and fixing is almost impossible.  SD cards are cheap now, and with huge capacities for not so huge sized old Atari ST SW, data . That means that all it can fit on single 8 GB SD card.

 And there are ways without old Atari STs : emulators: SW and HW ones. Can they run all Atari ST SW well ? Sure, except few rare cases. And of course, many consider it as not true retro computing. And even on them will need original TOS versions and full hard disk driver (by AHDI concept, working with low level disk access) to run all old SW what has hard disk install options, and all hard disk adaptations.  That's why Steem uses pasti.dll - what is real ACSI hard disk emulation . In Hatari there are more hard disk emulation ways - BASIC ACSI (as pasti.dll) Max 1 GB accessible, ICD ACSI - much more accessible, using protocol developed by ICD - designer and manufacturer of ACSI-SCSI adapters, for capacities of over 1 GB .  And there is IDE emul. too in Hatari. + so called GemDOS - basically same as 'Hard disk' in Steem - not compatible with all old SW, hard disk adapts, and it works only with TOS in ROM, not with TOS in RAM .

 Conclusion:  original TOS is done well. It works good in 99.9 % cases. Especially for people who know it's limitations.
 Those which praise and recommend EmuTOS just don't have correct approach, attitude, and worst: have no enough experience with old Atari ST ans SW for it.  Sure, there are some flaws, as in everything. But rear flaw is blaming some(one) that did not made SW for standards coming years, decade later.
 
 What about TOS can see on diverse WEB sites, forums ?
   Well, there is lot of it, and I did not see much really good writings. Saying that Atari ST was much like Commodore 64, just because was designed by team with lot of people who worked on C64 design, boss was same (Jack Tramiel) is wrong. As I wrote many times C64 was designed mostly for games, with pretty limited Basic in short ROM . So, there was HW support for diverse graphic operations. And it was manufactured in South Korea, and quality was not that good. Failures were more frequent than in other home computers , and I know it well, as I serviced them. PSU had design error (bad cooling, as alu. plate was covered) .
 Atari ST was manufactured in Taiwan, some components in Japan. Much better quality and much less failures, need for repair.
 And designed as universal purpose home computer, good for business too (can see in some movies from that era in offices) .
There is no HW support for gaming in first release, only blitter chip since 1987 . In 1989 little more support in STE .
  But programmers need some time to develop good code for efficient usage of new HW, plus need to make version what works on bare STs without new HW, as they are still in majority. So, there is really low count of games using blitter, STE HW scroll, DMA audio (well this needs more RAM too) .
 Can read more about diverse details, especially about TOS FAT16 filesystem of this site. On homepage are diverse links, including page about my improved TOS versions. What to say - it can be done only if you know well what you improving.

 

 

    PP,   July 2025 .