Just want to say the amount of amazing work that goes into this project is fantastic. They've taken the original Digital Research x86/PC GEM/GEMDOS sources and.. reworked them to basically duplicate all the work Atari did back in 1984/85 on their ST/68k port. Plus bug fixes. Plus pretty much all the feature work Atari did after that. Plus modernizing the code generally. Plus their own new features. Plus making it work on ColdFire systems (eval boards & the Firebee). Plus making it work on the Amiga and other 68k systems. All the while keeping it compatible, fitting in a 192k ROM.
It started as a ROM image for ST emulators (hence the name) but has actually become an excellent open sourced GPL'd GUI operating system for 68k computers, obviously especially the Atari ST.
It's a labour of love and the project maintainers do a great job. It's better than Atari's original ROM TOS while still maintaining absolutely excellent compatibility.
I can’t say enough good things about this project and its developers. A year or two ago, I decided to write a driver to allow EmuTOS to use the RTC found in Jookie’s excellent UltraSatan hard drive emulator.
They took the time to do a bunch of hand-holding on the mailing list, and worked with me until the driver, along with some minor restructuring to how things were handled with external RTCs, were working and merged.
I use it pretty-much exclusively on my (currently 8) ST variants. It’s a much nicer desktop experience, and brings all sorts of cool features to the table such as (some level of) FAT32 support. It’s also been ported to a crazy list of M68K systems including the Apple Lisa.
Development is still very active, and things are being improved and added all the time.
Although of little commercial value, this shows the power of an open platform. Current smartphones are thousand times more powerful than the old Atari ST, nevertheless, you won't be able to do anything useful or fun with them a few years after support ends because you can't easily replace its software/rom/firmware.
Motorola m68k @ 8mhz = ~1.4 MIPS
vs ARM Cortex A72 @ 18,375 MIPS
So actually 13000 times more powerful just in that one metric (instructions per second). Though of course it's more than that, as throughput in memory access, and concurrent operations and 64-bit math etc obviously much faster.
In fact, while I don't want to be mean, you're missing two or possibly three different points... among which are the reasons I posted this link.
[1] It's not that TOS is less advanced than AmigaOS. Yes it is, and anyone who knows them realises that, but that's not the issue here. The issue is that this FOSS project has brought these two platforms together after about 35 years, and that's both really technologically impressive and also just plain fun.
[2] It means in principle that Amiga owners can run Atari apps, and the ST had some impressive apps.
[3] AROS is great but it's an x86 OS. It doesn't readily run on classic Amigas, or even especially well on the handful of later PowerPC Amigas, AFAIK. It also doesn't run natively on modern RISC hardware, like say the Raspberry Pi.
[4] But because it doesn't, that's prompted the creation of another really cool
FOSS project, Emu68 -- a native 68K emulation environment for Arm, something comparable to Apple's nanokernel for running Classic MacOS on PowerMacs.
[5] Creating an OS that's as good or even better than the original while running on original hardware is impressive. Improved localisation opens it up to more people. That's good. It enables reviving vintage kit more easily, and expanding it. That's great.
You were so busy mocking something that you didn't stop to consider all the good sides.
[6] We know TOS was limited. We all know that. OTOH its simplicity enabled this. Its simplicity also was part of why the ST survived as a musicians' tool of choice for decades after it went out of production: super low latencies for music, and so on.
But others knew that TOS was limited, which drove a 3rd party OS market, with products such as MagiC:
So, yes, while you just wanted to do some advocacy, you missed a huge amount of great work by a committed community.
Not cool, dude.
Leave the Amiga-v-ST hate in the 1980s where it belonged. It wasn't very welcome then. They're both great computers. But hey, then the fans were children, so they can be excused.
I only recently tried FreeMiNT for the first time. It's a really weird feeling to come back to the Atari platform and see something that looks familiar but has been updated and dragged, if not into the present day then into the late 90s at least. Gone is most of the CP/M heritage of the original TOS; instead, it's a UNIX-like OS with a lot of the GNU userland. For me, using it is exciting like using Linux in the late 90s was exciting. It just leaves me feeling rather sad that Atari exited the computer market before the OS was quite ready and the community had to finish the job.
(And if you're wondering how this is relevant to EmuTOS, well, EmuTOS is used as part of the boot process.)
I have no idea if it's in any way viable, but something it would be immensely cool to see is some combination of Emu68 (or some other bare-metal emulator) and EmuTOS and FreeMINT, some combination that made it possible to run FreeMINT directly on a Raspberry Pi as the OS.
Not in an emulator under Linux. As the only OS.
ISTM that even a $5 Raspberry Pi Zero should be more than powerful enough to run this well.
I confess I would really like to see EmuTOS and/or FreeMiNT running directly on the Raspberry Pi, though I suspect it would be a huge amount of work. Right now, if you want Atari compatible hardware, you can either pay $$$$ for a vintage machine (and replace all the capacitors), or you can get something like a Vampire V4SA and put in a lot of effort to make it work run anything.
Raspberry Pi is a really nice (and relatively simple) hardware platform that would be great for running something like this and I have thought about it myself. Something like adding ARM [32|64] support to the kernel and then using an emulator of some sort to run 68k usermode programs. But I don't think FreeMiNT has ever been ported to any other architecture and imagine it would be a _huge_ effort.
Natively would be amazing but a vast amount of work.
The way Apple moved classic MacOS from 680x0 to PowerPC was to write a tiny kernel emulator, with an API to run native stuff on the metal, and run more or less the whole OS under emulation, profile it and just translate the most speed-critical bits.
That's a lot of work for a FOSS project but given the performance delta between 1980s 680x0 and 2020s ARM, total emulation of the whole thing should be perfectly fine. It's how the PiStorm Amiga upgrade works.
Got it. Thanks for explaining; I was definitely assuming running natively. I quite like the idea of running Aranym without a full OS but with something like Ultibo or Circle (neither of which I'd heard of before you mentioned them so thanks for putting them on my radar screen) but I'm not quite clear how much OS functionality it would miss in that sort of environment.
I came to this because I was involved in a very very minor way with FreeGEM and the project to resurrect PC GEM after Caldera made it GPL.
There was the idea to somehow port TOS to x86, but as we discussed it, the issues became clear. A native ST os on x86 couldn't run ST apps, because they're 680x0 code. And it won't run PC apps either, as they target PC OSes, not TOS/GEM.
Even if it's doable, it's a vast amount of work and there's no point. You still need emulation.
This is also why Apple ended up buying NeXT and switching OSes. Remember, Apple already had a UNIX: it had A/UX. But A/UX is a native 68030 Unix, with integrated classic MacOS. If Apple ported the underlying Unix to PowerPC, the embedded MacOS part that provided the UI wouldn't work, and MacOS apps wouldn't work. Without that, there's no point.
So Apple built a 68k emulator and ported the OS to the emulator. Then it speed-tweaked some bits. It worked and it delivered fast RISC Macs for a decade or more, which could still run old 680x0 Mac apps, but also allowed for new PowerPC apps to be delivered.
It was a good strategy, but it left them in a dead end. Copland failed, and so that's why NeXT, which was an excellent deal.
Well, honestly, we're not going to see any major new ST/TOS apps in 202x. It is not going to happen.
But there is this rather neat all-FOSS OS, or even pair of OSes: EmuTOS and FreeMINT. And they have apps, and programming languages, and are still vaguely usable.
So my thinking was: is there any way to glue together some existing code that enables them to run, providing an emulated 680x0 environment, on this cheap readily-available ARM hardware, without there being a whole other OS underneath?
I assume you refer to BeePi, which is a fantastic thing but it doesn't run FreeMiNT as the _only_ OS on a Raspberry Pi. It basically packages up a Raspbian OS with the Hatari and Aranym emulators running on top of it, with EmuTOS/FreeMiNT running on top of that. I've got it running on one Raspberry Pi and it's quite nice; unlike Aranym on my Mac, I can actually get networking to work. But it's not running an Atari OS directly on the Raspberry Pi hardware, which is a shame.
That's tricky. My friend did this with the C64 (BMC64) by making VICE run basically as a unikernel on the Pi. It's a lot of work. There's payoff there for something like the C64 where latency is super important for video games etc. But on the ST, I dunno if I see the advantage esp if you're running MiNT etc.
If you mean actually running the OS sans emulation, like a port of TOS/MiNT to ARM; I actually started down this road many years ago, trying to port as much of EmuTOS over to native ARM as I could... and others have fiddled with it, too. But it's a huge endeavour with little payoff. There's no binaries to run, so you'd end up hosting an emulator in it, and the endianness is entirely different so it's just... awkward. I found the transition to 32-bit and little endian and totally different graphics hardware made much of the EmuTOS sources useless.
Take something like the AES. It uses 16 bit big-endian values throughout, hardwired into C-structs, basically. And this maps 1:1 with resource file contents. You either have to rewrite everything incompatible with ST-AES and resource files and use 32-bit little endian. Or you have to be constantly swizzling values back and forth. Or do both. Awkward.
Or the VDI that's written there. I actually made "ok" progress writing a fresh VDI from scratch for the Pi framebuffer. But then... what's the value? The API is not really compatible because word sizes, framebuffer depth etc. It just starts to look really anachronistic.
Apologies, I was assuming that lproven was talking about baremetalling it but apparently not.
Re endianness, I confess I hadn't even thought of that aspect of it. (I understand that Cortex-A processors can run in big-endian mode but I bet it's not that easy.) And I bet there are a million other things that would be hard to make work.
But I still wish EmuTOS/FreeMiNT could be made to run on a modern CPU. It makes me sad to think that the 680x0 architecture basically isn't going to go much further than the Apollo 68080 (or Coldfire...), whereas a modern ARM (or X86 or even RISC-V...) chip is stupendously more powerful and I'd love to be able to run those OSes on that. Oh well, I can dream I guess...
I tried booting an RPi in big-endian and I was unable to get it to work. Maybe there's a way. I'm not an ARM expert, so.
It's probably more reasonable simply to boot directly to a bare metal 68k emulator -- one that doesn't emulate any hardware other than the CPU but passes through to the underlying video etc hardware -- and host a fork of EmuTOS there.
The MagiC stuff was unfortunately just opened sourced 15 or more years too late.
And also, AFAIK, it's mostly written in assembler.
It would be a gargantuan task to turn it into something that other people could maintain and contribute to, I suspect. Let alone get it running nicely on ColdFire etc. etc.
Re the timing, yes, I agree. But, remarkably, it was still on sale for a long time. I think I obtained an eval or review copy of it at some point, but I didn't really know what to do with it -- my ST experience is fairly minimal. :-(
I suspect, but do not know, that part of what killed it might have been the Mac OS X migration to Intel (and around the same time, Windows' move to 64-bit). I think MagiC ran on PowerMacs and used some of the OS's 68K-to-PowerPC translation somehow, but that stopped working after Snow Leopard.
I didn't know what it was written in, but I can say I'm not shocked. ;-)
I was kind of hoping maybe there'd be stuff in their VDI implementation that the EmuTOS people could maybe work from to maybe improve some VDI performance or flexibility. But I don't think it got on anybody's radar.
And yes, I believe MagiC naturally didn't survive the transition from PowerPC to x86. I'm surprised it survived 68k to PowerPC, TBH.
I never used MagiC back in the day, it came after my Atari days were over. But I've played with it since and it's really quite impressive. Definitely an imaginable alternative Atari timeline there.
AIUI, AFROS more or less came about because there were multiple competing replacements for various bits of the GEM stack: AES, VDI, desktop, etc. (Mostly from the German market, AFAICT. I am not sure why.)
One of the differentiators between these became that some were or went FOSS. Eventually, there were FOSS components for more or less all of TOS+GEM, so a new focus came into being: replace the handful of missing parts, so that an entire OS from bootloader to desktop, could be built from free software.
Again, this is only AIUI as an external spectator. When ARANYM and other FOSS emulators came along, they needed at least some ROM firmware to start the soft-loaded all-FOSS replacement OS. IIRC that was the genesis of EmuTOS.
An alternate market to the FOSS stuff and the various commercial replacements to make your ST go faster, was a commercial whole-stack replacement. I think there were several of those, too, but MagiC was the only one I know of that actively chased users on other platforms once the supply of new Atari kit dried up.
Aside from this: a friend on Twitter is very upset that this OS they disliked so much is still around, a bit like some posters here. I'm amazed at the residual hatred for this OS after over a third of a century. It really saddens me.
Some people clearly love it.
I think in a way -- maybe I am reaching too far here -- but ISTM it says something positive about a software platform if it inspires such strong feelings.
It makes me think of Vi and Emacs. I cordially detest both. Many people love one and hate the other. I make my living from xNix, but I don't actually like it much. Never did. I'm not a programmer; much of why programmers love xNix just gets in my way.
There were other, non-xNix-like OSes that were much more pleasant to use. I loved RISC OS back in the day, but while I still have it running now, I don't have much use for it in 2022. I loved classic MacOS, too. I must try to get my two old gigahertz-class G4 Macs running again so I can run the revived edition of MacOS 9 that can run on late-era OS-X-only G4s. At least I could do some paying work on that.
I have an Amiga, and I respect AmigaOS, but it is hard work trying to use modern Amiga-like systems in the 21st century when you didn't really know it back in its prime. I have repeatedly tried to get AROS running on bare metal with no joy. I did get MorphOS onto on my Mac Mini G4 in the end, but my word that was hard work, involving multiple preparatory steps with Classic and OS X and Ubuntu PowerPC.
Yes, the Amiga was more capable, but Amiga enthusiasts don't get that the price of greater capabilities is greater complexity, and that's off-putting.
Maybe TOS appeals to people because it's so much simpler? And because in some ways it's DOS-like, and that's familiar too? And maybe that's why this modular re-creation exists?
It's good to hear that Amiga users are finally getting their act together and doing the open source thing after years of fighting over who was going to make a few pennies off the dated corpse of AmigaOS.
In the meantime, your tone is inappropriate for a post about an open source volunteer run project. And, no, the original title was not inaccurate or misleading. EmuTOS runs on Amigas and works fine on them. That you have some chip on your shoulder that someone might accidentally run it instead of AmigaOS (?! as if) is your own concern.
Finally, as for TOS being some woefully inferior garbage product that AmigaOS dwarfs in its inelegancy is ridiculous. It's fairer to say that both are products of an early 80s mindset just in different ways.
Yes, AmigaOS has proper multitasking. But it also had no memory protection for a long time (ever?), and from I remember doesn't use the 68k's TRAP syscall mechanism to perfom syscalls. It had no real standard GUI toolkit to start. It had some real sexy stuff, but also some missing stuff.
TOS/GEM was not multitasking, and was built to run things single process apart from the cooperative multitasking in desk accessories; but GEM explicitly has APIs designed for a multitasking environment and was built to do so later. Interprocess mailboxes and events. Concepts of process/workstation handles, etc. Hooks that later revisions to the OS built on. Why didn't they do it right away? Because at that point, on an 8mhz 68000 with 512kB of RAM this was, frankly, mostly silly.
It's nice the Amiga did multitasking, and the hardware was clearly awesome. But the lack of timeslicing (and the cheap beautiful monochrome monitor, DOS compatible floppies, etc.) actually made the ST more appropriate as a productivity machine in the context of e.g. music studios.
Other poster is right: leave the weird sectarian platform battles in the 80s. It was silly then but it looks even more ridiculous now.
> It's good to hear that Amiga users are finally getting their act together and doing the open source thing
AROS has been around since the 90's. I remember when Aaron Digulla first posted about it on comp.sys.amiga.misc around ~'93 or so. It's not instead of the fighting over AmigaOS, but in addition to it. Different people.
> Because at that point, on an 8mhz 68000 with 512kB of RAM this was, frankly, mostly silly.
The Amiga showed it wasn't silly at all. We used the multitasking heavily. I usually had multiple productivity apps up at once, alongside music players and other stuff.
TOS is literally a dogshit, brain-damaged OS design. But I still appreciate being able to run the open emuTOS on my Amiga.
And while I like AmigaOS, dos.library (TripOS-derived) is awful and doesn't match the rest of AmigaOS. Of course, it still is better than anything TOS and its CP/M heritage, but I wouldn't dare call it good.
V36 onwards, dos.library was made much more sane, but it unfortunately has to still be compatible with older dos.library, forever.
It's not dogshit, it's appropriate to the resource constrained use cases of the time.
But also, "TOS" really means three separate cooperating things:
1. GEMDOS, which is sorta the bastard child of MS-DOS and CP/M but foisted onto the 68k. And yeah, it's a bit braindamaged; it has the feeling of something DR threw together to get GEM working on non-MSDOS environments ASAP, and there's parts of it directly copied from CP/M 68k, I believe. But it also made porting from DOS and CP/M really easy.
2. VDI, an actually quite nice (for the time) graphics abstraction system with a concept of multiple devices and 'workstations' (drawing endpoints). E.g. same syscalls could in theory drive a monitor, a plotter, a laser printer, etc. Mostly incomplete on the ST, but the underlying concept actually quite nice and not really seen on the PCs til a long time later. I am not sure the Amiga had an equivalent.
3. AES ("application environment services"); concepts of event mailboxes and events and messages, higher level application APIs, mixed up with a rather low-level (but at least consistent) GUI toolkit. Unfort, it's really what I'd call the syscall-side of a UI toolkit, missing the... user space side. It's asbent the right abstractions to make using it easy (handling redraws, standardized event loops / registering common event handlers, etc).
Anyways, I'd argue actual GEM -- the last two parts -- was actually quite elegant. Just never finished. And also it had to fit in a 192kB ROM.
Atari actually made some real good strides in the early 90s to finish it off ("MultiTOS" based on MiNT etc). But too late.
I read programming books from the era recently, as I never had an ST and was curious about it, and wrote some code to play with it (with vasm and hatari). It turned out much worse I had thought it'd be.
Of course, my issues are mainly with GEMDOS (CP/M isn't great, but the 68k port sure is awful) and with the call conventions used everywhere (e.g. stack for function call parameters, use of traps for VDI).
GEM (the non-VDI part of it) and only GEM is reasonable, and not actually good. Just not brain-damaged.
TRAP is the right way to do it though. They're syscalls. That's the m68k way of doing syscalls and to elevate to supervisor mode etc.
From today's POV some of the stuff in the VDI and AES maybe doesn't belong in "kernel" and would be done user space. But it was the 80s, and it all had to fit in 192kb, there were no shared libraries. It was a different time.
>TRAP is the right way to do it though. They're syscalls. That's the m68k way of doing syscalls and to elevate to supervisor mode etc.
Yes, if you're implementing a UNIX. Of course, the fundamental mistake was using CP/M 68k as the base. GEM ended up effectively being just a GUI for CP/M, similar as the DOS version, rather than a modern system as AmigaOS attempted to be (minus the TripOS mistake... but at least dos.library fits on top of exec and the rest of AmigaOS, rather than being at the bottom of the stack).
The use of stack rather than registers for passing parameters is a particularly bad fit for the 68000. It effectively slows down the system considerably, as it adds significant overhead per-call.
>From today's POV some of the stuff in the VDI and AES maybe doesn't belong in "kernel" and would be done user space.
Agree 100%. I love how AmigaOS's exec.library got this right. In 2022, the world's still stuck with UNIX clones and struggling to move past that. Recently, with Haiku, Genode and Fuchsia there's finally some excitement again.
FWIW having seen the sources for both, GEMDOS isn't based directly off CP/M68k sources. There are commonalities, in particular in the names of functions, trap locations, etc. and some bits of stuff that is common (executable format for one) but they're entirely separate codebases. Most of CP/M68k is written directly in assembler. While GEMDOS is largely C.
GEM on the PC was written to run on MS/DOS. So I think to make a portable GEM for other platforms they made something with an API and filesystem closer to DOS but written by people who were clearly familiar with CP/M, and had access to CP/M68k sources.
The first platform to run GEMDOS on 68k was the Apple Lisa. That was the dev machine DR used.
And in fact EmuTOS itself now boots on the Lisa again.
What's interesting is I know Mac OS Classic used the same "push the args to the stack and call TRAP" syscall process as well. I suspect because of this that the Lisa did as well, though I couldn't tell you for sure since hardly any docs are out there for that. Digital Research was not unique in choosing these scheme. Maybe DR copied Apple, even tho the timeline seems wrong there.
FWIW you got me interested, so I'm reading the CP/M68k sources right now and from the bits I've read, I do see the stack based calling convention there, as well:
_bios2:
* For all BIOS functions with a word parameter
* Word parameter follows function number
move.w 6(sp),d1 * get 1st parameter (word)
_bios6:
_bios1:
* For all BIOS functions that have no parameter other than function number
move.w 4(sp),d0 * get function number
movem.l d3-d7/a3-a6,-(sp)
* * save C register variables
trap #3 * do BIOS call
* * returns value in d0
movem.l (sp)+,d3-d7/a3-a6
rts
There does seem to be evidence that there was a multitasking Concurrent CP/M, and/or Concurrent DOS, and/or FlexOS, from DR for 68K. It looks like it got to at least v1.2 and maybe later.
How much of that got into EmuTOS, I don't know, and I'm not sure if binaries or source of FlexOS 68k survived.
If they did, as I wrote here, they are probably arguably FOSS now:
If we go there, I understand FreeMiNT is the way to go.
But I have not played with anything beyond emuTOS for now. I think there's still a lot of good work to do there, particularly making it work, and work well, on more m68k hardware than the Atari platform.
It started as a ROM image for ST emulators (hence the name) but has actually become an excellent open sourced GPL'd GUI operating system for 68k computers, obviously especially the Atari ST.
It's a labour of love and the project maintainers do a great job. It's better than Atari's original ROM TOS while still maintaining absolutely excellent compatibility.