Personal Computing on an Amiga in 2021
thedorkweb.substack.com
thedorkweb.substack.com
> Ensoniq was founded in 1982 by former MOS Technology engineers Robert "Bob" Yannes (designer of the MOS Technology SID chip for the Commodore 64 home computer), Bruce Crockett, and Al Charpentier. Their first product was a software drum machine that ran on a home computer.
> In January 1998, ENSONIQ Corp. was acquired by Creative Technology Ltd. for $77 million, and merged with E-mu Systems to form the E-Mu/Ensoniq division. The fusion with E-mu sealed Ensoniq's fate: after releasing an entry-level E-mu MK6/PK6 and Ensoniq Halo keyboards - essentially keyboard versions of the Proteus 2500 module - in 2002, the E-Mu/Ensoniq division was dissolved and support for legacy products was discontinued soon afterward.
I told him of the bad review in Future Music. He was a bit annoyed but explained what they had missed in the review.
A nice guy.
That A1000 ended up with 4MB, 14MHz 68020, SCSI controller, and 80MB of disk 'borrowed' from a Sun.
Sure the OS was a bit different, but it's basically a cut-rate Sun 3/60. So many earl Amiga devs were Unix nerds sitting in front of Suns all day and wanting something close to that feeling for home. Macintosh (lol), IBM PC (lol DOS).
Pretty much wasn't until Linux that the PC actually became useful at all.
This. I got lucky to experience a SGI Indy when it came out and although going from my beloved Amiga to a 386 running DOS "because CPU speed" (and because the PC was obviously where it was heading) was a really bitter move. Then a 486. Then I discovered Linux and my 486 + Linux was my "poor boy's SGI Indy". Great memories (and still rocking desktop linux on my workstation on a daily basis).
You could overload the system in other ways though, particularly disk I/O in Workbench.
Even more mind blowing is that the visible screens could have different resolutions. The display hardware could switch modes per scanline while keeping the same output frequencies, so you could have a low-res/high-color screen on the top half of the monitor with a high-res/low-color screen on the bottom half.
Then bitwise is right.
Windows 98 crawled under a Pentuim@133 and 64MB of RAM (we had that in the library), but Windows 95 without that crapware called IE4 + ActiveX was fine.
At least the vast majority of customers we had to support had 386 DX's or 486's.
In other words, would it make sense to port it to the PC or maybe Raspberry Pi? It sounds like it would be fun to play with it, but I lack the hardware, and I am not sure I'm willing to sink money into it without having an idea of what I am getting into.
That can be overcome with enough brute force; although emulators like FS-UAE can still struggle to keep realtime with some workloads.
There are FPGA reimplementations of Amiga hardware, if you wanted something more 'realistic'.
The bigger issue is applications that bypass the hardware abstraction layer or throw away the OS entirely, typically games and quite a few productivity applications.
I suggest looking at MorphOS and AROS
https://en.wikipedia.org/wiki/AROS_Research_Operating_System
The nr. one thing any new OS should learn from the Amiga is its motto: "simple things should be easy, complex things should be possible." Not "Simple things should be possible, complex things should be Dark Souls"!
The next biggest thing would be the use of pervasive inter-process scripting. ARexx (I wouldn't choose it today but it worked) gave you amazing power to combine applications and automate various tasks - a bit like the Linux command line does, except it works everywhere. To illustrate, there was an ARexx script that combined a mail application with a chess playing game to create a chess-playing robot: you could mail it a board and it would make the next move, and mail it back. You could get two Amigas to play chess against each other, and thus avert nuclear annihilation.
"Screens", we would now call them virtual desktops, were way better than virtual desktops because applications are aware of them, and can be configured to run on a specific screen. Thus you don't waste time setting up new virtual desktops, moving windows across, etc., it's all automatic.
Assigns let you add globally valid short names for directories and devices. An assign can refer to multiple directories, and it can be deferred, meaning it is hidden until you refer to it. I really miss those on other OSes. Yes, you get links. No, they aren't the same. You don't have to create an assign in a location (they are always global), you don't need weird syntax for creating links, and you can delete them without fearing for your data.
The OS is essentially a microkernel that uses message passing for asynchronous communication, and that uses dynamically loaded drivers for things like devices and file systems. For modern usage you would really have to add memory protection (it wasn't available on the hardware of the time), and resource tracking (it wasn't finished in time for the Amiga launch).
And its culture was just different. The Amiga had so many small, simple productivity tools (it also lacked big, complex productivity tools, but that's another story). You had simple, yet powerful programming languages, music creation tools, drawing tools, etc. The tools of today are orders of magnitude better, but that power has come at the cost of considerable complexity. DPaint 2 can't hold a candle to the Gimp, but at least I knew how to draw lines with it. And is there even a single music creation tool for modern OSes that isn't either a sample arranger or a fullblown score editor?
So it can certainly be done. The question is, will you end up with the same joyful platform and the same joyful culture? I sort of doubt that: without a captain on that particular ship, odds are it will quickly turn into a Linux reskin. The world already has enough of those, and even if that weren't to happen, part of its magic was in the applications it ran. Just ports of existing Linux tools wouldn't have that. So I'd love to see a proper AmigaOS port to modern PC hardware, and it would totally rock - but I just can't see it gain the same momentum it had back in the day.
But yeah, if you did weird things like mucking with hardware registers directly or used undocumented fields of a struct, then yeah, you could have a problem.
One common problem was when applications assumed all memory was reachable by the custom chips; the later addition of fast ram (which was ram that wasn't slowed down by custom chips accessing it, thus starving the CPU of memory cycles) could break those. Another example is using the upper 8 bits of pointers, which was safe on 68000 but not on 68020 and up which had a full 32-bit address bus. Making assumptions about OS structures was also a favorite of many hackers, and something that invariably broke on later OS releases. However, if you stuck to the API you were fine, and many applications run without problems on all OS releases from 1.2 to 3.1.
Too bad AGA was too little, too late. If it was released a few years sooner, say with the A3000, it might've been different. ECS barely added anything over OCS, other than extra chip RAM. There were a few modes hardly anyone used.
> So I'd love to see a proper AmigaOS port to modern PC hardware, and it would totally rock - but I just can't see it gain the same momentum it had back in the day.
I've long toyed with the idea of trying to pull pieces out of AROS to do something like that which takes the good bits without the bad (e.g. losing memory protection is not something I'd like), but it's tricky. I think a "Linux reskin" by someone who actually is familiar with both would be the best bet. But it'd be a lot of work.
Maybe an "Amiga layer" to provide some of this. E.g. quite a bit of functionality could be done by a combination of FUSE filesystems to make things (e.g. assigns, datatypes) accessible to all apps, and then you can build libraries and tools separately to expose them in nicer ways where needed.
For screens, I think many of the programmable window managers would be a decent basis for providing APIs like that. E.g. bspwm, while predominantly a tiling wm, does support floating windows too and pretty everything can be controlled over IPC.
For ARexx, we have dbus, and while dbus has always seemed overengineered to me, providing a wrapper that provides a simplified interface might well be doable.
But you're absolutely right about the culture differences, and I think that's the biggest challenge. This worked on the Amiga because "everyone" coalesced around a set of standard tooling. To get something like that to work today I think you'd have to have a group of people willing and committed to expend a lot of time working to get support for these things into existing open source tools before people would start to see the benefits.
But rather than try to copy things like how Workbench looked (which I don't think anybody really cares about), it would perhaps be more useful to try to add the best Amiga parts into other systems. The pervasive scripting would be a good start: I'd love to be able to script as much as on the Amiga in Windows or Linux. Obviously it would require some thought on security, we don't need scripts running rampant.
I wouldn't couple it to a specific language, and in fact I don't think that was the case with ARexx anyway: the interface was open enough that other scripting languages could have been supported on the existing ARexx infrastructure.
I'm not going to do the work though ;-) Got enough going on ATM...
This distinction has been reduced to next to nothing in Linux. clone() is like fork() but allows sselective sharing that allows both more sharing (sharing the same memory space) and less sharing than fork (e.g. it can put the new process in new cgroup namespaces etc.
> (which I don't think anybody really cares about),
I don't care about the look, but I do care about the spatial layout of it. It really annoyed me when Gnome dropped support for that for Nautilus. My memory is very strongly spatial, and having windows reopen in the same spaces etc. was an awesome memory aid. Other than that I agree - I'd mostly use DiskMaster II for actual file management, and most "holdouts" today seems to favour Directory Opus Magellan (which can also be used as a Workbench replacement)
> The pervasive scripting would be a good start: I'd love to be able to script as much as on the Amiga in Windows or Linux. Obviously it would require some thought on security, we don't need scripts running rampant.
So I actually took a look at Dbus again thanks to this discussion, and it obviously have had to deal with the security aspect, and it seems to be solved largely by a separation into multiple buses. The problem as I see it with Dbus from what I've looked at is that it wants to be a "proper" RPC system. That is, it's complex because you have to connect to a given bus, then to a given service, then find a specific object, then get the interface from the object. E.g. here's a Ruby example using ruby-dbus [1]:
require "dbus"
sysbus = DBus.system_bus
upower_service = sysbus["org.freedesktop.UPower"]
upower_object = upower_service["/org/freedesktop/UPower"]
upower_object.introspect
upower_interface = upower_object["org.freedesktop.UPower"]
on_battery = upower_interface["OnBattery"]
if on_battery
puts "The computer IS on battery power."
else
puts "The computer IS NOT on battery power."
end
address "org.freedesktop.UPower"
if on_battery
...
I think it's interesting to note that DBus is this complicated in large part because it imposes structure on the services that could have been built from a far simpler abstraction (allow messages directly to a service; provide the object/interface abstraction by using a reserved command/message name to query the service for capabilities; simple services would just process messages to the service endpoint - more complicated ones would work as before)
Reading the specification, it's not as bad as it looks. It has a lot of complexity that can be hidden, and e.g. the "interface" specification is optional (you "just" risk that the target object implements multiple interfaces with the same method names, so it's up to those writing services to tell you), but it seems many clients refuse to let you omit it easily (ruby-dbus allows you to choose the default interface to specify, but it doesn't look like it lets you omit it entirely).
It'd be interesting to try to tweak/wrap ruby-dbus to see if it's possible to hide enough of the complexity in a reasonable way. E.g. "guessing" the default object name and omitting interfaces unless specified would get you pretty close to decent defaults.
Running an introspection tool, there certainly are quite a few interfaces registered with dbus (and one of the things with dbus that ARexx doesn't have is the ability to register endpoints for programs that are not currently running that allows "activating" them), but if people see examples like the first one above you have to be really dedicated to want to keep diving into it.
> I wouldn't couple it to a specific language, and in fact I don't think that was the case with ARexx anyway: the interface was open enough that other scripting languages could have been supported on the existing ARexx infrastructure.
The port/command execution is open enough, certainly. A good example would be FrexxEd (one of the co-authors was/is Daniel Stenberg of CURL fame), which used "FPL" (a C-like language) as its main scripting language, but all the editor specific commands are shared between FPL and the ARexx port.
The language interpretation for ARexx is provided by ARexx - the hosts only need to provide the ability to execute commands.
In terms of providing the capability, I think you really only need the ability to simply send commands to a given port, and then shell scripts or whatever language people prefer can do the rest. An "rx" variant that either lets you specify the port to address or defaults to address whatever port is specified in an environment variable would make it almost seamless.
> I'm not going to do the work though ;-) Got enough going on ATM...
This is the problem. So many of us miss parts of what the Amiga does, but they're conveniences that are easy to miss and want but hard to justify putting in the effort on. Especially as many of them are just sufficiently dated that they'd need some rethinking, and suddenly it's a lot of effort.
You put it quite well when describing the overall motto.
The part about DataTypes:
"Datatypes describe a file format and tell the OS how to handle it. Any datatype-aware program can use any file format as long as a relevant datatype is present."
Doesn't looks that different from how codecs are used in modern OS's. AFAIK, as soon as ffmpeg or gstreamer learns new formats or how to use hardware codecs, so does every program using them without the need of even recompiling. Of course, doing that 30 years ago is another thing.
And:
"RAD: is a fixed-size bootable RAM disk that survives soft reboots. Equivalents exist for most modern Operating Systems. They’re worth trying out. You don’t really know how useful they are till you lose them."
Maybe I can change my mind if I use them, but I really don't feel the need. On my notebook, I simply close the lid and when I open it, it is mostly in the same state I left; some system I used are stable enough to have months of uptime; using /tmp/ seems enough for me. I once had I power failure and recovering whatever was on /tmp/required booting from a keychain but it was easy to do and a very rare occurrence.
The "RAD:" may be interesting on not specially stable, non high uptime, /tmp/-lacking systems but I can't see how they can be relevant on modern OS's.
More importantly, how many applications actually use these as their primary means of accessing file types?
Chrome doesn't learn a new image type if I drop in a file. LibreOffice doesn't. Certainly not from the same one. Gimp doesn't. There's no reason why all of those should not be able to load a new image type without updating the applications themselves, just by dropping in a datatype/codec.
The concept isn't anything magical - or new -, but it's still largely forgotten and ignored outside of small islands of use.
We have all kinds of little API's to do this for specific types of files, like e.g. ImageMagick's "convert" for images, ffmpeg for video etc. as you mention, but what we lack is a unified API, the ability to drop plugins in for new file types, and for applications to actually unify around using a specific standard.
Heck, we even have a workaround to avoid needing application support: A FUSE filesystem to trigger conversion to suitable target filetypes.
This is the same issue with a lot of the things we're missing from AmigaOS. They're not hard to do. E.g. "assigns" are conceptually largely a OS-provided way of creating PATH's for everything you'd like, for example - it can also easily be provided via a FUSE filesystem. Dbus "almost" gets us to what AREXX provided, but is just not supported as widely or as simple for regular users to get started with.
What was special with the Amiga in that respect was that these things were embraced fully across the board, and integrated into the culture surrounding the Amiga.
There have been attempts, such as OLE and ActiveX on Windows, or KParts in KDE 2 (and dcop from Qt 2) (or was it 3?), or Intents on Android, or WebIntents, but yeah, none of them became universal, and many of them had security problems.
Of course it's also more complex to do on a system where you expect security (no memory protection on Amiga's made that rather moot), but I think a targeted attempt to do just the minimum datatypes does - or even less, would still be valuable. E.g. many of the security issues are related to embedding a widget, but just providing a unified mechanism for loading and saving which could easily be sandboxed and interfaced to via a dumb pipe (still security issues in validating what's passed over that of course).
The problem is that many kind of ignore using them.
It's not an interesting or useful difference. The thing Datatypes lets you do is pointlessly spell things differently. Once you spot that you ask yourself, "Why am I doing this?" and the answer is only that you need to interoperate with other people who hadn't settled on one way to spell things so the best route forward is consolidation.
Most applications gain nothing from having, say, yet another mediocre bitmap graphics format. You just made your system more complicated without any improvements whatsoever. Clearly we should agree to just stop doing this. And we did.
> Gimp doesn't
Actually Gimp does. Gimp's file format handling is all via plug-ins. As with ImageMagick in this context maybe you actually needed to rescue crappy 1980s files you found on a floppy disk or whatever. But this helps us see what's going on - because Gimp's image file format handling is only for import and export of necessity Gimp itself is richer than any of these formats. Its native XCF format reflects a superset of the features you can care about.
But anything Gimp's native images can't do, you can't "add" using these plug-ins. The SVG plug-in for example can't magically make Gimp understand vector images, it just has to render the vector image as pixels because that's all Gimp understands.
So in the end any innovation is rendered pointless by this abstraction, the only way for an innovative idea to flourish is to sidestep a "datatypes"-like abstraction altogether.
> actually unify around using a specific standard.
You've almost understood. Instead of adding a layer of abstraction, and then unifying around this unnecessary layer, we instead chose to just use a specific standard format. The problem you're intent on solving vanished.
Didn't you ever wonder why Datatypes seemed so brilliant for image files, and kinda sorta OK for music, and then basically of no value at all for most other file formats? It's because there really were sixty different crappy pixmap formats that were completely interchangeable and half a dozen PCM audio formats likewise. But that's not what happened in other domains, because it's pointless.
Applications gain a tremendous amount of usability for me by being able to read or write the formats I actually use. Instead we rely on a hodgepodge of scripts and tools to do format conversion manually.
Amiga applications released decades ago can load webp files for example, whether or not the people who wrote them are still releasing updates or are even around. It might not matter to you. It matters to me that files keep being easily accessible.
Today there are plenty of tools I use regularly that can't load or save various formats I regularly use directly. That is pointless, when providing a mechanism to reuse conversion was a solved problem decades ago.
> Actually Gimp does. Gimp's file format handling is all via plug-ins.
But it's not reusing system-wide plugins, which was the point.
> You've almost understood. Instead of adding a layer of abstraction, and then unifying around this unnecessary layer, we instead chose to just use a specific standard format. The problem you're intent on solving vanished.
Unfortunately you failed to understand. We haven't unified on a standard format. We never will, because we get new requirements regularly, and people also create new formats for arbitrary and stupid reasons as well. Format conversion will always be necessary to handle formats produced by different tools.
We can choose to do that "out of band", or we can choose to re-implement it for applications time and time again, or we can move towards a unified system. Today we do the first two. A tremendous amount of time is wasted implementing conversion and loading and saving for different applications, and a tremendous amount of time is wasted on doing out-of-band conversion. I've spent the better part of the last month dealing with crappy data conversion because a tool I need to feed data into implements it's own conversion in a badly broken way instead of reusing a better one, forcing me to go via another format. The amount of developer effort wasted on this bullshit is massive, and the amount of inconvenience for users is too.
> Didn't you ever wonder why Datatypes seemed so brilliant for image files, and kinda sorta OK for music, and then basically of no value at all for most other file formats? It's because there really were sixty different crappy pixmap formats that were completely interchangeable and half a dozen PCM audio formats likewise. But that's not what happened in other domains, because it's pointless.
No, I didn't wonder that, because the limitation there was that Commodore went bankrupt and datatypes was not progressed to cover additional domains, and the Amiga community was not large enough to take on the task of covering more complex structured data options. Meanwhile we still depend on conversion filters for all kinds of other formats all the time for e.g. office suites. So no, it's not pointless.
No, but an SVG datatype can present itself as both bitmap and vector and an application that wants a bitmap can still read an SVG as if it were a bitmap.
> It's because there really were sixty different crappy pixmap formats that were completely interchangeable
Any data type that’s generic enough can present itself in multiple ways as long as it’s possible to translate (even if with losses) to those ways.
WebP is much newer than most Amiga applications. Since someone wrote a WebP datatype, an Amiga word processor written in 1994 can embed one in a document. An Amiga graphics app released in 1997 can open one and edit it. Literally every Amiga app that can use the datatypes API now supports it, without a single recompile or changed line of code, because someone wrote that loader. That’s pretty powerful.
That's literally just spelling. The exact same pictures could have been added to the document in 1994, only the file format changed.
People keep doing this, as others have observed. And they always get stuck in the same place, they can make different raster image formats work, although each time this happens they find there are fewer anybody cares about, and they can do the same trick with PCM audio, although again not many options anybody cares about (MP3 is about as exciting as you get these days) and then they run out of steam.
This is not a rich seam of unexplored possibilities, it's a small hole in the ground that people keep clambering down into - certain they'll find treasure and then disappointed when it is in fact just a small hole in the ground.
It's the Oak Island money pit of technologies.
You keep arguing for inconveniencing users and developers, who still need the conversion tools anyway, to avoid standardising the conversion tools. It makes absolutely no sense.
Yes, it is. You don't even try to pretend otherwise, the format isn't delivering new semantics here. The existence of the extra formats that caused Datatypes to be created is an artefact of history, like TIFF, and best left there.
> It is additional manual steps vs. having the computer do things for us.
"Having the computer do it" for every format in every program incurs an unending maintenance and security burden for all systems across all time, whereas lift-and-shift averts that.
> You keep arguing for inconveniencing users and developers
You have chosen to inflict misery on yourself, I don't have any part in that.
> It makes absolutely no sense.
And yet I suppose that today you will continue as before, blaming others for things you choose, and perhaps lamenting that whichever bunch of crooks currently own "Amiga" aren't shovelling more money into the pit.
The formats exist and are being used, and new ones keep being created. That is the problem. You can keep pretending we don't need to deal with them. Maybe you don't, but I do have to deal with format conversion on a daily basis, as I don't live in a fantasy world where everyone chooses to use the formats I would prefer.
> "Having the computer do it" for every format in every program incurs an unending maintenance and security burden for all systems across all time, whereas lift-and-shift averts that.
Having the computer do it for every format in every program in terms of the actual conversion is exactly what we have today because of the lack of use of things like datatypes. On top of that we have piles of conversion tools to deal with moving data between programs that don't implement the same set of formats.
What we're lacking is automation and deduplication of effort.
There's no added security concern here to automating the execution of code we already execute.
If anything avoiding crappy reimplementation of formats all over the place would be a substantial reduction in complexity and make it easier to actually put in the effort to produce something more robust.
Meanwhile what you're engaged in is meaningless sophistry given that your proposed solution of just getting rid of these formats is not an option available to us.
> And yet I suppose that today you will continue as before, blaming others for things you choose, and perhaps lamenting that whichever bunch of crooks currently own "Amiga" aren't shovelling more money into the pit.
I don't care who currently own Amiga. It's entirely irrelevant to this conversation.
But your non-solution does not become any more of a solution whether or not I get the time to do something about my workflows.
That’s just because it’s part of the OS. On a Mac you have lots of high level APIs to interact with programs and data that form the visible layers of the OS. On Linux there is a hard border between GUI and OS and a mechanism like this would be more at home in Gnome or other desktops.
Another factor that drove adoption is software scarcity. Back then it wasn’t trivial to just link to a library that reads GIF files and it was much easier to use OS services for that. The cost comes in portability. I can write a Mac or Linux app that can be compiled and runs on mostly anything, but the moment I use OS services, it’s no longer portable.
It's also not as simple as it being part of the OS, though space constraints certainly would favour OS libraries - the Amiga world is full of APIs that were adopted across the board despite not being part of the OS.
E.g. XPK is a good example: If you want to support compression in an Amiga app, you'll most likely use XPK, which gives you instant support for every compression algorithm someone wrote an XPK library for.
What is more likely to have mattered was in general whether or not a potential user would be likely to already have a library installed. My first hard drive was 20MB. What an application chose to install was a big deal, and that certainly encouraged people think about sticking to options that were popular and that likely to would save space.
Regarding the "hard border", it's worth keeping in mind that while datatypes could be used for visual elements, it could also be used for "headless" load/save/conversion. Putting something like it in e.g. Gnome would be less valuable than providing the "headless" part, because the format conversion is the most valuable aspect. And that part is incidentally also the easiest part to make portable.
https://docs.microsoft.com/en-us/windows/win32/wic/-wic-lh
However it is exactly as you put it, it is exposed at application level, so unless an application calls into WIC, it will never be made aware of new WIC components deployed into the system.
When "posted" to the clipboard (either in response to pasting, or because the application itself wants to, e.g. because it's being closed), the clip is written as an IFF file to the assign "CLIPS:". Like any other assign, CLIPS: can be reassigned anywhere, including RAD: or RAM: or disk. Unless I misremember badly, CLIPS: defaults to a directory in RAM: possibly indirectly via T:
Since AmigaOS will request volumes that aren't currently in a drive, you could even reassign the clipboard to a floppy with a given label, and the OS would pop up a requester asking for it to be inserted as needed.
That's a great feature and it should be forward-ported to modern OS's.
You could do it with FUSE relatively easily: Make a FUSE filesystem that acts as an overlay, so, say when you access /<path to the fuse system>/foo it looks for /<path to mount>/foo and if it doesn't find it, pop up a window with "Please insert volume 'foo'"
Frankly there are a lot of these things that would be quite straightforward to support on Linux that'd be "nice to have" but are not quite essential enough to motivate someone to do it.
Data types, on the other hand, were absolutely amazing. Sure, ffmpeg covers some of it, but datatype support was, and remain, a killer feature of AmigaOS. Want almost universal support for a new format, including support by legacy applications? Datatypes. Want to replace a common format's encoder with somerhing else? Datatypes.
The other killer feature of AmigaOS applications was the AREXX support, which allowed advanced scripting far before it was available on other consumer platforms.
There are probably a bunch of other machine candidates that feel this way to someone out there!
I know the exact sensation you describe here. But I can never decide whether it's a property of the thing itself, or where I was in my life when I stumbled onto it. My hunch is that it's mostly the latter: artifacts feel seminal when they hit as a formative time when we first gained a new capability.
I'll always have a fondness for the Apple IIe and the early Macintosh because those were what I had when I first started using computers to create. I'll always love late 90s electronica because that's when I fully discovered my love of music. My Lodge Dutch oven will hold a special place in my heart because I got it right when I was really learning how to cook.
That being said, I do think there is something special about that era of machines, even outside of our right-place/right-time nostalgia for them. I cut my early computing teeth first on a Timex 1000, later on a Commodore 128, and finally an Amiga.
The Timex was... ok. It was fun enough to pfaff about with, but so limited that it didn't really capture my attention in a special way. The Commodore? Amazing. It is responsible for my entire technical career trajectory. I loved exploring its edges. It was a powerful-enough system that Real Things™ could be done, yet still simple enough that the entire machine could live in your head, so to speak. The Amiga? It was amazing, but it was almost too much. I couldn't hold the whole machine in my mind any more, and had to rely of greater level of abstractions to get things done. What was doable was incredible, but there was an undeniable sense of loss, too. At least for me.
Some designs are made by passionate talented people pushing the limits of their own skills and imaginations to explore what might be possible.
And others are made by mediocre people throwing some some minimal-cost low-effort derivative crap together to make as much money as possible.
One is an inspiration. The other is kind of offensive.
I suspect a lot of computer nostalgia is really about chasing that first feeling. I also suspect that's a lost cause, because you can't find the limits of imagination on the trailing edge.
Of course you can get echoes of it. Which is almost reassuring - but I really wish there were more high-skill high-imagination projects in computing today.
But, I've read a lot over the years about computers from then and have spent a lot of time on modern computers.
The Amiga, from what I can tell, was actually special, not just from a nostalgia sense.
They seemed to push the boundaries of computing at the time, gave a glimpse of what could be but were stuck in that inbetween phase and just couldn't quite make it.
I think they deserve all the praise they get. They seem like they were one hell of a machine for the time and despite the huge diversity of things like linux distros and such these days, things like the RPi and various comparable devices, a huge range of consoles, phones and other arm based things, there really isn't anything like the old days of computers where everything was different and devices were made to be tinkered with.
Not to say everything about that era sounded awesome or better or whatever, but something does seem to have been lost that machines like the Amiga seem to embody.
I will keep looking, but breaking up the thing that was in one way or the other part of my life for >25 years felt very strange. So many memories. So many firsts. And I believe that this is a big part of that feeling of specialness such things have.
A new laptop doesn't provide any firsts for me. Nothing new. Maybe faster. Maybe a better keyboard. But nothing new.
PCI SCSI controllers are around and fairly cheap, looks like there are even some PCIe ones out there (not as cheap). I've never gotten as far as the software side of it though. I imagine one might create an image of the disk, and use it with Mini vMac, but I think I still need to figure out the SCSI setup. (I have a PCI SCSI card that I was attempting to use to interface with some tape drives-- different story.)
the old ui widgets can't really (I assume) vary that much in properties or location (the layouting is stricter and will break if you push it too hard)
It would dynamically calculate a minimum window size based on the components inside and you could then resize the window as you wanted with things calculating and resizing as you go, adapting to font selections and themes.
The actual implementation is archaic by todays standards but it did use attributes on UI objects to determine min/max sizing and other things, similar to CSS in concept.
Sadly no font sensitivity on display (possibly because Amiga owners take it so much for granted that they don't think of it as special), but it shows what MUI can do in terms of GUI elements, window resizing, etc.
After leaving the Amiga for Windows, the three biggest things I hated about its GUI were all those endless non-resizeable windows, the complete lack of font sensitivity, and the horrible scrollbars that didn't show your actual content size (and that snapped back if you moved out of some invisible box). And here we are, twenty years later, and nothing has improved at all...
To be blunt, a lot of modern UI are like pretty glass Norman doors... lest you dirty our pretty frosted glass with your filthy hands for the sake of usability, what will the stake holders think!
I am not blind to aesthetics, but I believe form should emerge from function, as per Dieter Rams. Hopefully we will swing back towards prioritising function, but it doesn't have to look dated.
Suns were not really designed for desktop use - they more or less aimed for the generic case. SGIs, however, were built to be experienced.
It is a shame that such a small set of features jumped from workstations to the PC.
It was the first camera that came with a computer and it had a pretty easy interface from C so that + a small embedded HTTP server and we were off to the races.
The funniest bit to me is still that people simply would not believe they were looking at a live image from the other side of the world. More than once I had to go in front of the cam and wave at people or show them some tekst :)
Eventually I automated that by putting a remote controlled fan + light (and a mobile of paper cranes) in front of it, but then people would claim that I was faking it. Tough crowd :)
Volume 2 is on IndieGOGO
maybe a classic II or an SE/30 if you want the original form factor
I guess most of the expense is spare parts and shipping?
If you want a Free AmigaOS try AROS: https://aros.sourceforge.io/ it can run on PCs and 68K Amigas and has a Kickstart ROM replacement.
Amiga 3.5 and 3.9 were created by a German company back in 1999/2000 and require a 68020 or better processor.
https://en.wikipedia.org/wiki/AmigaOS#AmigaOS_3.5,_3.9
3.1.4 and 3.2 were created by Hyperion Entertainment. 3.1.4 and 3.2 by the looks of it support all the 68000 series processors and these as stated in the article are more recent.
They also were not developed by the same company. 3.5 and 3.9 were developed by Haage & Partner, 3.1.4 and 3.2 were developed by Hyperion Entertainment.
There's even an AmigaOS 4.0 from Hyperion which is PowerPC only.
For extra bonus points, there's MorphOS which is a heavily AmigaOS influenced OS. PowerPC only, runs on some of the older PPC Macs.
And there's also the open source AROS reimplementation of AmigaOS 3.1 (with a lot of extras).
(I'm sure I got a lot of details wrong, been years since I last did Amiga stuff.)
I guess it's the latter, but I was wondering if any of the classic mod trackers had external sync capabilities. Back when I was still using them I never investigated if I could sync.
I’m not anti-upgrades—-just curious :)
Don’t expect a screen resolution anything like the ones shown in the article though and RAM and the 68020 become an issue fast working with a lot of recent files. The author has a lot more RAM than me and it definitely shows.
Up to the 3000, IIRC, Amigas were tied to TV frequencies, so you wouldn’t get more than 200x640. You could do interlacing and get 400 lines, but you’d want to claw your ever out in 10 minutes.