▲ 125 points
back
45 comments
There's a really good interview with one of the 68060 architects that posted recently https://www.youtube.com/watch?v=1takr2k7Yfo just sit through the intro trust me it gets deeper than you'd think from the first impression.
Probably one of the better CPU interviews I've seen in recent times. He spills some interesting knowledge, the 68060 was a kind of serendipity for Mot that was otherwise winding up the 68k. It was partially acquired and acquihired from an external fabless design startup. Fills in some gaps as to why the CPU wasn't as well known as priors (obviously there were more choices by the time it came out). And a bit of tangents into Coldfire, ARM-M, and RISC-V.
I love retrocomputing but I never really understood running a modern OS on old hardware. I have System 7.5 on my LC575 and NeXTSTEP 3.3 on my turbo color slab; I could run NetBSD on both, but I could also do that on modern hardware with much better software support (and build times that wouldn't take an epoch).
It's cool, and I'll still support it, but I won't understand it :)
As someone who mostly gets my retrocomputing kick from running modern software on old RISC hardware, I'll try to explain why that's my thing.
Typically, these venerable beasts come from a more "civilized" era of computing, at least that's how I feel. I wasn't around to actually experience it, coming up when real UNIX™ was already pushed to the fringes. I'm completely aware that I'm romanticizing, but for me, there is something about these machines that a PC just still can't exactly match. Trying to move a mouse and typing with broken keyboard layouts through a buggy-as-hell IPMI interface that was somehow bolted to a machine that, from it's inception, never was meant to be operated remotely, just feels like a hack. It might get the job done, and it's cheap, but it most certainly isn't elegant. The PC as a whole just isn't elegant.
But these old SUN and IBM machines, they're something different. Tools from professionals, for professionals. With remote management built into the machine from the inception! No stupid GUI with whacky translations in sight!
Of course I'm also fascinated by Solaris, AIX and HP-UX and whatnot. But running modern software on these machines has it's own appeal to me. My retrocomputing itch is to show off these machines, experience them. And what better way to do that than to actually use them to host modern software, impress people by showing how capable they still are, maybe as a glimpse into a future that never was.
I felt this way in my late teens and early 20, when I spent a lot of time e.g. finding a pipeline for playing YouTube videos on sun4m machines running NetBSD.
I'm now in my late 20s, and my impression is these machines were largely always hacked together piles of garbage, they had just cost a lot more ;)
There were highs of elegance, yeah. The OpenBoot PROMs introduced with the SPARCstation were marvelously functional and beautifully elegant, especially compared to the previous pre-boot environment. But when you look under the cover, you find a million patches of duck tape, like Sun having to force their compilers to avoid using the o7 register due to speculative instruction prefetching sometimes triggering DMA activity on a peripheral card and causing an unintended side effect. This was due to one buggy CPU (the 80 MHz Weitek upgrade CPU for the SS2), but the bug required changes for all sun4c kernels (at an minimum).
Or how the ILOM on newer SPARC servers are just embedded PowerPC chips running RedHat Linux. At least in the late 2000s :)
At the end of the day, NetBSD on my SPARCstation 2 is cool, super cool even -- there's even EXA acceleration support for the CG6 framebuffers in X!
But ultimate NetBSD/sparc is basically identical to NetBSD on my raspberry pi. I can even run the big endian port if I want a BE system!
On the other hand, running a contemporary OS like SunOS 4, or something exotic like Sprite, gives a very different experience. And honestly, these 80s OSes themselves feel more "elegant" in a hacker sort of way.
(I'd agree that most mid/late 90s+ Unix systems mostly just feel like worse versions of modern Linux/Unix, though)
While individual implementations may or may not have had horrible bugs or consisted entirely of hacks, I think just carrying forward the expectation of having a proper, all-powerful text prompt into the firmware that can easily be made accessible remotely would have been a real boon to the foundations of server hardware. With time, the bugs could have been fixed and the hacks replaced with proper implementations.
I think this boils down to a cost problem more than an engineering or cultural one. If you look at the original Itanium machines of the early 2000s, they had BMCs like the Sun ones, and they ran EFI as the base firmware, often with no graphical head. Pure serial!
There's no reason you couldn't build a solid, headless PC-compatible architecture based around EFI. It would just... cost money. Even in the retrocomputing stuff you see the same thing happen. Older VAXes had very rich boot PROMs, but by the time you get to models like the 4000 "Very Low Cost", most functionality was stripped out of the PROM to save space and cost.
same here, I feel all sorts of sadness since this sort of thing use to bring so much joy but now bring a bunch of yawn. i had sun 3s, earlier sparcs, IPX, IPC, decstation, HPs, SGI and you are right, it took getting older to feel the same. but then again, even modern systems software/hardware are surprisingly hacked together piles of garbage too. it all depends on how you define garbage.
I got paid by my university to decommission and throw out a bunch of Sun SPARC rack mounts. Like anything else these machines had to be maintained except due to licensing issues they were always susceptible to exploits, were woefully out of date, and were missing major utilities that existed on Linux by this point due to again licensing issues. And because no one bothered to compile for SPARC pretty much installing anything modern required very slowly compiling everything and hoping you didn't get a weird SPARC only machine error in the compiler which actually happened quite a bit. Even worse I remember at the time my gaming laptop that I used for university coding work was already much faster. The one benefit from the experience was that it really drove home just how hard it is to maintain a cpu arch that isn't popular.
> There were highs of elegance, yeah. The OpenBoot PROMs introduced with the SPARCstation were marvelously functional and beautifully elegant, especially compared to the previous pre-boot environment. But when you look under the cover, you find a million patches of duck tape, like Sun having to force their compilers to avoid using the o7 register due to speculative instruction prefetching sometimes triggering DMA activity on a peripheral card and causing an unintended side effect. This was due to one buggy CPU (the 80 MHz Weitek upgrade CPU for the SS2), but the bug required changes for all sun4c kernels (at an minimum).
Do not look at ACPI, boot firmware, or the CPU microcode, instruction match "patch" modes, chicken bits, or any of the other horrible hacks required for modern CPUs to run :)
CPUs have more or less always operated under the same constraint as any other engineering project, which is to optimize the cost/value of the thing. That means at some point you bake the silicon that is guaranteed to have known and unknown bugs in it. CPUs sit in a different place in this spectrum than software does, thanks to the relative ease of software patching, but underneath it's bugs and hacks. So they do certainly get far stronger testing and verification treatment before shipping. But there is enormous infrastructure baked into the silicon purely for finding and fixing bugs that inevitably escape that QA. Everything from leaving a sprinkling of spare gates and latches around the chip so you can use them for post-synthesis or metal-layer fixes, fallbacks and and fixups everywhere. There are watchdogs or hang timers or state condition checks in the core and SMP fabric so if some known or unknown condition causes deadlocks or livelocks, you can hit it with a hammer and go to some slow mode (e.g., single-issue, non-speculative, in-order) for a while to clear it up.
CPUs in embedded or certain vertically integrated shops did have the issue that fixing bugs in the compiler or their applications was viable so you would get a bunch of craziness leaking out (there are or were patches in binutils to pad code so it doesn't put branch instructions at the end of a page, things like that, for more than one CPU). ARM and x86 CPUs today would absolutely ship with bugs like this if backward compatibility were not extremely important and if the hardware vendors had more control over the software stack.
There were a bunch of serious user-visible speculative execution bugs in ~all modern high performance CPUs within the last decade (yes, AMD, ARM Ltd, and I believe Apple all had speculative execution security side channels too). Occasional issues with user and supervisor level can be seen in errata documents too, often they can be fixed with "firmware" (which means microcode, chicken bits, etc), but they still exist.
True! That was my point exactly, that (for the most part) the old workstations weren't special or magical relative to PC hardware, when you pull old DEC and Sun hardware manuals on Bitsavers or whatever they're chalk full of ink from manual corrections and errata. Old Ethernet NICs are especially bad... :D
This isn't to disparage them, either. GP admits they are romanticizing, I'm just offering my own perspective on it. When I call old stuff "hacked together piles of garbage", it was meant with the loving connotation of someone who's home office has a MicroVAX 3400, Sun 4/75, DEC PWS 433a, and a POWER9 workstation piled in the corner, all on a KVM switch. I love tinkering on these old machines, but I think it's healthy to remember they're not beacons of 80s/90s perfection, but products that were made and sold under time/cost constraints, as you said.
... Though, I will say, the MicroVAX was running from the late 80s until about 2018 in a university environment, and its HDDs still report no errors. That is pretty remarkable ;)
To add a bit of context: I'm not even romanticizing the actual implementations, which may or may not have had horrible bugs and errata. Rather, it's the abstract concept, the ability to have a reasonable expectation that, for example, the firmware would be completely operable, scriptable and so on and so forth from a serial line. Stuff like this.
Mirrors the Amiga experience. PC architecture still is a hack compared to 1200.
And dealing with COM and Powershell leaves a bit to be desired versus datatypes and ARexx, oh well.
Ports, man, ports.. datatypes I think weren't #1. oh well...
For me: the retro operating systems are where it's at for having fun, but at the same time, being able to boot something modern to image a drive/edit partitions/copy files from the network/etc is also super helpful sometimes.
For me, i have some old (2000s/2010s) live CDs that i use for that purpose on PCs. On PowerPC Macs, they're powerful enough that having a vaguely modern browser is super useful for downloading software and drivers. And to do that you usually need a "modern" (snow leopard, 2008?) OS even if the hardware is ~2002
Also: for me the ultimate thing in retro computing is just _doing it because it can be done_. I spent weeks getting a PCMCIA 10/100 card working on DOS 6.22/WfW 3.11 just because i believed it could be done and i wanted it to happen. I built a Spotify frontend in .NET 2005 for 95/98 because, why not? I've got windows 2000 server on a Supermicro board from 2010 because, again, i believed it could be done, so I had to try lol
you would live NetBSD
I am kind of the opposite.
I like retro computing but I never find myself using old software on old hardware. It is basically a museum piece sitting on a shelf at that point.
If I actually want to use my hardware, I want new software on it. If I am going to create software for it, I want to use modern languages and modern language versions. I want modern media codecs. I want to be able to read modern media and use modern filesystems. I want Linux on it if I can, including the conveniences of modern package management. I may want to use containers.
If it is going to connect to the Internet, I want it to be secure.
I do not want to deal with pointless compatibility problems, limited aofrware selection, or decades old bugs.
For me, part of the fun is seeing how much you can make old hardware do. And with new software, that can really surprise you sometimes. And in this age of the cloud, the hardware may not be the bottleneck you think it is.
I will give two examples. First, I have used OpenCode to write native software on old platforms. Toy compilers can be fun. The locally running software is not that demanding with the hard work being done in the cloud by a frontier AI but with the results tested locally and natively on the old hardware. This is a lot more fun, and makes more sense, than doing it in an emulator.
Second, the core of my homelab is Proxmox running on a 2013 Mac Pro. It runs dozens of VMs and containers. It cost me $200. Where else am I getting 64 GB and 12 cores for $200?
this solution (hardware AND software) was built and designed for a time that no longer exists. i simply will never understand your attitude, when you can buy a raspberry pi and have a completely better experience in every way other than going "WAOW, Modern Firefox on my PowerMac"
Despite the venom, I do not need you to agree with me.
I am not going to feel foolish enjoying excellent keyboards and screens instead of whatever I cobble together for a Raspberry Pi.
And it seems you just decided to ignore the whole native dev thing as well as the homelab. How many virtual machines and software defined networks do you run on Rasberry Pi?
I guess it also depends on what you mean by retro. I got a 2013 MacBook Air for $50 almost 2 years ago to take on a backpacking trip. It runs Chimera Linux now, with packages from an Arch Linux container. I used it at the park for a few hours this weekend. I took a video call on it this morning. My Rasberry Pi is not going to be better for any of that.
Anyway. I am glad you disagree. I would like my old hardware to be more affordable so the less demand the better.
again, a lot of this hardware and software was built for a time and a place. to understand what they were creating and the limitations they faced.
waow! i am using facebook on an sgi! waow!
funko pops.
> I am not going to feel foolish enjoying excellent keyboards and screens instead of whatever I cobble together for a Raspberry Pi.
you can plug a nice input device and display into that. you uh... you knew that right?
> I guess it also depends on what you mean by retro
i literally said powerpc, so i guess, start there. x86 laptops are very common, insanely common in fact.
> Despite the venom, I do not need you to agree with me.
lol
it shows you what we could have if we were sufficiently advanced. think about it, it's software, all bits. we could theoretically have had all of this a long time ago.
Linux is a retro OS, the odd thing is that we run a retro OS on part of a modern SoC. Shouldn't an OS run the whole banana?
Linux is a modern and versatile kernel. You can use it inside a retro emulator, supercomputer operating system, smartphone OS (Android) or desktop operating systems for modern SoCs and lots more.
Linux is not in any way, a retro OS.
The implication is clearly that the core design dates back to UNIX in the 70’s.
But many aspects of its core design are also 21st-Century concepts, developed anew in a fresh era, and are still very much widely deployed and in active full development.
Therefore, Linux is not retro.
I used to collect old hardware and try to install NetBSD/OpenBSD on them. For me, a lot of the fun was the "challenge accepted" aspect. Getting them to boot and work on some weird and obsolete machines felt like winning a small battle.
Agreed. And I always learn a lot as well.
Bringing up new software on old hardware is kind of like learning how assembly language works while the “why not use a Pi” approach is more like writing it in Python.
They both have their place but, to me, the “I will never understand” crowd is missing out.
> It's cool, and I'll still support it, but I won't understand it :)
to be fair, m68kl is from that period of time. so it's the rare "acceptable" option to me
but yes, i wholeheartedly agree
68k outliving 486 support in the kernel will be hilarious
Is it still supported? The “News” page on the linked site reads:
Current Linux/m68k Releases
As of today, the following versions of the Linux/m68k kernel are "current":
Linux/m68k 2.0.36, released 5 February 1999, is a stable 2.0 series release. Users of earlier versions should probably upgrade; it's well worth it.
Linux/m68k 2.2.10, released 19 July 1999, is a developmental release (despite the 2.2 version number).
Linux/m68k 2.4.5, released 5 June 2001, is an experimental release. (More recent patches may be available in the linux-m68k mailing list archives.)
There are files for it in mainline:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Well, this page/project certainly isn't, but Wikipedia says it's still in the kernel:
https://en.wikipedia.org/wiki/List_of_Linux-supported_comput...
yes, you can still run current debian on a 68k machine
But it makes a kind of sense, right? There's long been straightforward upgrade paths for 486 users, making the 486 effectively totally obsolete and killing most of the demand for continued support. Whereas 68k machines have effectively become trapped in time, and their users are still going to work to keep support going.
NetBSD still support 486 and even 386 i think. Out of tre box. Netbsd supports even vax 780 from 1979 (first modern 32bit architecture) :)
ColdFire exists ;)
I would imagine there are actually more 68k devices out there than 486 and, I am told, the 68k architecture is much more enjoyable to work with.
Someday i hope to get Linux running on my Mac LCII... After i replace the power supply, and all the caps....
I was having fun building a custom distro for my 386 until the drive containing all the work died and coincidentally my backups had started failing without me noticing.
In case you want to get started again..,
I guess I could contact them to describe how to write an interrupt driven keyboard driver for the late model Macintosh machines. The documentation provided by Apple was incorrect.
Very interesting to see this pop up on HN just after I spent a few days making Alpine/m68k a thing.
(just a personal tinker project - don't look for it upstream any time soon unless I get extremely bored)
Not recommended for new designs.
Back in the day it would be great, but in current day, what could I possibly run on my 020 system that would make Linux preferable over the system's original OS and its dedicated (possibly FOSS) software?
Consider Netbsd.
In my experience, it is a much more workable choice on m68k.