5 ms·

In the UK, its main contemporary in the non-PC realm was the Atari ST, which was cheaper, arrived on the market sooner, and took the “professional” market becau

In the UK, its main contemporary in the non-PC realm was the Atari ST, which was cheaper, arrived on the market sooner, and took the “professional” market because of its excellent mono monitor (“small, but perfectly formed”). The ST didn’t multitask, but Amiga multitasking wasn’t memory-protected, so crashing something meant you could (would) lose everything running. It also couldn’t do the graphical tricks the Amiga could do, ceding the VFX market to the Amiga with its genlock. The Amiga’s graphics and sound were both better than the ST, but games were comparable on both, and did I mention the ST was cheaper ? What the ST could do (and well) were things like DTP (Calamus, Calligrapher,…) and MIDI (there are still rare sightings of ST’s in audio studios, 20 years ago they were ubiquitous). Those two gave it legs to run for far longer than you might expect, because Macs were outrageously expensive at the time.

doener 3mo ago
> but Amiga multitasking wasn’t memory-protected This was not the case for Windows 95/98 and ME, either BTW IIRC. Only with Windows XP Microsoft introduced memory protection for the mass market.
- jorisw 3mo ago
  Probably Windows NT rather, which turned into Windows 2000 (and then XP)
- mmustapic 3mo ago
  No, Windows 95 had memory protection for 32-bit apps. Usually when a 32-bit app crashed, the rest of the OS worked fine.
  - tialaramex 3mo ago
    There's definitely a difference in magnitude in how likely crap software is to set the world on fire and ruin your day between Win95 and Amiga. One big problem is that Amiga "multi-tasking" while not co-operative like Mac or Win 3.x, can be switched off as a convenience for programmers. So all that needs to go wrong is a program switches off multi-tasking to do something and then gets stuck before restoring it. The program which crashed is dead but you can't fix that because it turn off multi-tasking.
    - vidarh 3mo ago
      In all the years I used an Amiga, I don't think I ever had the machine crash because they used Forbid(). I'm not saying it never happened to people - I'm sure there were badly misbehaving programs in use -, but using Forbid()/Permit() outside of very tight sections was very firmly frowned on, and Forbid was overall relatively uncommon apart from games which took over the system on purpose.
  - vintermann 3mo ago
    In theory it had memory protection. Processes were reasonably protected from accidentally stepping on each other's tires, but the OS was not. Any app that tried to be clever (which there were plenty of understandable reasons for) or was actively malicious could mess with absolutely everything.
- thijson 3mo ago
  Windows 3.11 was pretty unstable, because it wasn't using protected mode. I remember how unstable the Macs were back then too before the introduction of OSX. Applications also had to voluntarily give up control of the CPU, cooperative multitasking. That's bad when an application crashes and takes down everything with it.
  - p_l 3mo ago
    Windows 3.x could (and defaulted to where possible) to running in "386 enhanced" mode which actually used protected mode, IIRC. The problem was that the Win16 part ran all in one address space, and the separation support was mainly used to handle DOS windows.
UncleSlacky 3mo ago
The UK also had the Sinclair QL (68008-based) in 1984 for £399, famously owned by Linus Torvalds: https://en.wikipedia.org/wiki/Sinclair_QL#Linux https://en.wikipedia.org/wiki/Sinclair_QL#Linux
smallstepforman 3mo ago
To support protected memory, you need an MMU, and the base 68000 did not ship with an MMU, however the 68020 and later did. The Amiga 3000 onwards should have defaulted to MMU and had a flicker fixer and chunky graphics and 16 bit sound to really succeed. Another multiverse timeline, perhaps.
- vidarh 3mo ago
  The A3000 had a ficker fixer. If you meant that the other later models should have also included it, I agree. Regarding the MMU, the problem was/is the OS. AmigaOS uses message passing between processes extensively, and those messages often involved passing pointers to structures that the receiver expected to be able to dereference and even writ to in some cases. I'm on record repeatedly arguing over the years that it would be possible to retrofit at least limited memory protection onto AmigaOS, but it's decidedly not something that'd be simple to do, and most likely you'd need to basically sandbox old apps and create new API's for new apps to do it properly.
  - amiga386 3mo ago
    It would be simple, but somewhat incomplete. It would not look like a virtual memory subsystem where merely accessing an address can allocate physical RAM to it. The API is already there! AllocMem(, MEMF_PUBLIC) allocates shared memory, otherwise you get private memory. You can then enforce memory protection around that, but obviously the entire OS is still built on message-passing between tasks where the message itself remains at exactly the same (public) address and isn't copied between private memory spaces, and there's a gentlemens' agreement as to who currently owns it (PutMsg/ReplyMsg) Software like Enforcer and MuGuardianAngel already checked this, and dinged your program for accessing non-allocated memory.
    - vidarh 3mo ago
      I think "somewhat incomplete" is underplaying it as such a large proportion of message exchange tends to include pointers to shared structures. That the message handling uses intrusive lists doesn't help. So "simple" really depends on where you set the bar for what you consider useful levels of memory protection. I still think it's possible but doing it to a meaningful extent would be a long tedious effort, at least for my definition of meaningful. You have Janus-UAE which sandboxes/emulates M68k apps for AROS "rootlessly" in that it bridges a number of structures etc. That mostly solves the problem on modern hardware for legacy apps, though it's a painful solution. Then you could aggressively upgrade message formats for "native" apps to replace pointers with opaque handles. If done at the time you could of course had relied on more of the developers of various apps still being active and willing to update their code and might have been able to avoid the Janus-UAE approach, but there was never a point at that time where anywhere close to a majority of users had MMU's,
rwmj 3mo ago
I think the Acorn Archimedes (1987) might be the closest UK vision to the Amiga. Of course it was 2 years later. But, mouse-oriented interface, graphics central, kind of 32 bit CPU with limitations (similar to the 68k which is 16 bit aspiring to be 32 bit), thoroughly weird desktop environment.
- pjmlp 3mo ago
  And a great BASIC with inline Assembly.
  - rwmj 3mo ago
    That was awesome, but to be fair it was a carry-over from BBC BASIC.
- amiga386 3mo ago
  nitpick: ARM1/2 were 26-bit. The PC register used the bottom 26 bits for the address of the next instruction, and the upper 6 bits for status flags. Lots of code involves getting or twiddling those flags by amending the PC register directly. There is nowhere in the architecture you could put the missing 6 bits. This was unlike the "24-bit" 68000 where the hardware package actually only had 24 address lines, but its address registers and PC were 32-bit. https://en.wikipedia.org/wiki/26-bit_computing#Early_ARM_processors https://en.wikipedia.org/wiki/26-bit_computing#Early_ARM_pro... The ARM3 resolved the situation by adding a separate 32-bit clean PC register and a separate status register, instead of the combined monstrosity. All software had to be rewritten to use the new registers if it wanted to be "32-bit clean", unlike 68000 software which either just worked fine, or revealed the programmer was an imbecile who thought they could get away with storing random data in the top 8 bits of addresses. Bonus: the Archimedes memory map (00000000-03FFFFFF, i.e. 26 bits) https://www.chiark.greenend.org.uk/~theom/riscos/docs/ArcMemMap.txt https://www.chiark.greenend.org.uk/~theom/riscos/docs/ArcMem...
  - vidarh 3mo ago
    > or revealed the programmer was an imbecile who thought they could get away with storing random data in the top 8 bits of addresses. Case in point: Microsofts Amiga BASIC.
pjmlp 3mo ago
To match the Amiga in gaming, only from STE improvements onwards. At least when the Amiga crashed it got to do some meditation. :)
- spacedcowboy 3mo ago
  ST crashes, meanwhile were “da bomb”

doener 3mo ago

> but Amiga multitasking wasn’t memory-protected This was not the case for Windows 95/98 and ME, either BTW IIRC. Only with Windows XP Microsoft introduced memory protection for the mass market.

jorisw 3mo ago
Probably Windows NT rather, which turned into Windows 2000 (and then XP)
mmustapic 3mo ago
No, Windows 95 had memory protection for 32-bit apps. Usually when a 32-bit app crashed, the rest of the OS worked fine.
- tialaramex 3mo ago
  There's definitely a difference in magnitude in how likely crap software is to set the world on fire and ruin your day between Win95 and Amiga. One big problem is that Amiga "multi-tasking" while not co-operative like Mac or Win 3.x, can be switched off as a convenience for programmers. So all that needs to go wrong is a program switches off multi-tasking to do something and then gets stuck before restoring it. The program which crashed is dead but you can't fix that because it turn off multi-tasking.
  - vidarh 3mo ago
    In all the years I used an Amiga, I don't think I ever had the machine crash because they used Forbid(). I'm not saying it never happened to people - I'm sure there were badly misbehaving programs in use -, but using Forbid()/Permit() outside of very tight sections was very firmly frowned on, and Forbid was overall relatively uncommon apart from games which took over the system on purpose.
- vintermann 3mo ago
  In theory it had memory protection. Processes were reasonably protected from accidentally stepping on each other's tires, but the OS was not. Any app that tried to be clever (which there were plenty of understandable reasons for) or was actively malicious could mess with absolutely everything.
thijson 3mo ago
Windows 3.11 was pretty unstable, because it wasn't using protected mode. I remember how unstable the Macs were back then too before the introduction of OSX. Applications also had to voluntarily give up control of the CPU, cooperative multitasking. That's bad when an application crashes and takes down everything with it.
- p_l 3mo ago
  Windows 3.x could (and defaulted to where possible) to running in "386 enhanced" mode which actually used protected mode, IIRC. The problem was that the Win16 part ran all in one address space, and the separation support was mainly used to handle DOS windows.

UncleSlacky 3mo ago

The UK also had the Sinclair QL (68008-based) in 1984 for £399, famously owned by Linus Torvalds: https://en.wikipedia.org/wiki/Sinclair_QL#Linux https://en.wikipedia.org/wiki/Sinclair_QL#Linux

smallstepforman 3mo ago

To support protected memory, you need an MMU, and the base 68000 did not ship with an MMU, however the 68020 and later did. The Amiga 3000 onwards should have defaulted to MMU and had a flicker fixer and chunky graphics and 16 bit sound to really succeed. Another multiverse timeline, perhaps.

vidarh 3mo ago
The A3000 had a ficker fixer. If you meant that the other later models should have also included it, I agree. Regarding the MMU, the problem was/is the OS. AmigaOS uses message passing between processes extensively, and those messages often involved passing pointers to structures that the receiver expected to be able to dereference and even writ to in some cases. I'm on record repeatedly arguing over the years that it would be possible to retrofit at least limited memory protection onto AmigaOS, but it's decidedly not something that'd be simple to do, and most likely you'd need to basically sandbox old apps and create new API's for new apps to do it properly.
- amiga386 3mo ago
  It would be simple, but somewhat incomplete. It would not look like a virtual memory subsystem where merely accessing an address can allocate physical RAM to it. The API is already there! AllocMem(, MEMF_PUBLIC) allocates shared memory, otherwise you get private memory. You can then enforce memory protection around that, but obviously the entire OS is still built on message-passing between tasks where the message itself remains at exactly the same (public) address and isn't copied between private memory spaces, and there's a gentlemens' agreement as to who currently owns it (PutMsg/ReplyMsg) Software like Enforcer and MuGuardianAngel already checked this, and dinged your program for accessing non-allocated memory.
  - vidarh 3mo ago
    I think "somewhat incomplete" is underplaying it as such a large proportion of message exchange tends to include pointers to shared structures. That the message handling uses intrusive lists doesn't help. So "simple" really depends on where you set the bar for what you consider useful levels of memory protection. I still think it's possible but doing it to a meaningful extent would be a long tedious effort, at least for my definition of meaningful. You have Janus-UAE which sandboxes/emulates M68k apps for AROS "rootlessly" in that it bridges a number of structures etc. That mostly solves the problem on modern hardware for legacy apps, though it's a painful solution. Then you could aggressively upgrade message formats for "native" apps to replace pointers with opaque handles. If done at the time you could of course had relied on more of the developers of various apps still being active and willing to update their code and might have been able to avoid the Janus-UAE approach, but there was never a point at that time where anywhere close to a majority of users had MMU's,

rwmj 3mo ago

I think the Acorn Archimedes (1987) might be the closest UK vision to the Amiga. Of course it was 2 years later. But, mouse-oriented interface, graphics central, kind of 32 bit CPU with limitations (similar to the 68k which is 16 bit aspiring to be 32 bit), thoroughly weird desktop environment.

pjmlp 3mo ago
And a great BASIC with inline Assembly.
- rwmj 3mo ago
  That was awesome, but to be fair it was a carry-over from BBC BASIC.
amiga386 3mo ago
nitpick: ARM1/2 were 26-bit. The PC register used the bottom 26 bits for the address of the next instruction, and the upper 6 bits for status flags. Lots of code involves getting or twiddling those flags by amending the PC register directly. There is nowhere in the architecture you could put the missing 6 bits. This was unlike the "24-bit" 68000 where the hardware package actually only had 24 address lines, but its address registers and PC were 32-bit. https://en.wikipedia.org/wiki/26-bit_computing#Early_ARM_processors https://en.wikipedia.org/wiki/26-bit_computing#Early_ARM_pro... The ARM3 resolved the situation by adding a separate 32-bit clean PC register and a separate status register, instead of the combined monstrosity. All software had to be rewritten to use the new registers if it wanted to be "32-bit clean", unlike 68000 software which either just worked fine, or revealed the programmer was an imbecile who thought they could get away with storing random data in the top 8 bits of addresses. Bonus: the Archimedes memory map (00000000-03FFFFFF, i.e. 26 bits) https://www.chiark.greenend.org.uk/~theom/riscos/docs/ArcMemMap.txt https://www.chiark.greenend.org.uk/~theom/riscos/docs/ArcMem...
- vidarh 3mo ago
  > or revealed the programmer was an imbecile who thought they could get away with storing random data in the top 8 bits of addresses. Case in point: Microsofts Amiga BASIC.

pjmlp 3mo ago

To match the Amiga in gaming, only from STE improvements onwards. At least when the Amiga crashed it got to do some meditation. :)

spacedcowboy 3mo ago
ST crashes, meanwhile were “da bomb”