4 ms·

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.librar

by snvzz 4y ago

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.

cmrdporcupine 4y ago
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.
- snvzz 4y ago
  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.
  - cmrdporcupine 4y ago
    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. That AmigaOS didn't use TRAP is a bit odd.
    - snvzz 4y ago
      >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.
      - lproven 4y ago
        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: https://www.theregister.com/2022/08/04/the_many_derivatives_of_cpm/ https://www.theregister.com/2022/08/04/the_many_derivatives_...
        4y ago

by snvzz 4y ago

cmrdporcupine 4y ago

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.

snvzz 4y ago
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.
- cmrdporcupine 4y ago
  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. That AmigaOS didn't use TRAP is a bit odd.
  - snvzz 4y ago
    >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.
    - lproven 4y ago
      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: https://www.theregister.com/2022/08/04/the_many_derivatives_of_cpm/ https://www.theregister.com/2022/08/04/the_many_derivatives_...
      - 4y ago