Why bother with old technology? (2013)
retrotechnology.com
retrotechnology.com
An early-ish 8086/8088 PC clone is a possibility, but the Atari/Amiga/Macs will have better graphics options and won't have segment/offset memory addressing.
But then they aren’t much simpler than our modern desktops running their own Unixes.
I wouldn't consider an X server running on one of those "still useful" but others might disagree.
The killer feature of this specific 43P was that it came with a gargantuan Intergraph CRT monitor.
They're the original Arm based computers (not counting the development processor for the BBC Micro) and some of the earliest system on a chip computers.
Might be fun if you fancy playing with Arm assembly language.
https://en.wikipedia.org/wiki/RISC_OS
https://en.wikipedia.org/wiki/Acorn_Archimedes#Later_A-serie...
https://en.wikipedia.org/wiki/Risc_PC
[1] I say Risc OS but they actually also supported a Unix like called Risc ix.
There are some resources here if you’re curious and want to see screenshots. (Not my site)
What did you use A/UX for?
If you go the emulated route (e.g. SIMH), I'd go with BSD 4.3 or Sun SunOS 3.5. That's where I started out with Unix so there's a lot of nostalgia there.
For an example of something that smooths a lot of things over, using a nice, high-level USB library is abstracting away a huge amount of the issues involved with that sort of signaling. If you want to deeply understand how computers communicate with each other over wires, you're probably better off studying RS-232 first.
But then I did some programming for a 6800 with something like 40 simple instructions, and I "got it", and the -10 became simple, too.
I was recently speaking online to someone trying to get into it from a fresh start, and they lent me their perspective (kinda like a rubber duck debugging session), and I was a bit appalled at how hard it is to get into web development at this level now. I ended up recommending an approach in which one recapitulates the browser's development cycle if you want to really understand what's going on out there... it isn't the best choice technically in the short term because it's a long path to tread just to do "this one thing", but if you want to be similarly flexible and know how to work with the mess of technologies out there, for path-dependent and historically-contingent reasons (that is, opposed to any other good reasons), I think it may still be the best way to go.
And to be honest, there's still a lot you can do with server-side generated HTML, the tags in modern HTML, and a bit of pure Javascript. There are good reasons to move beyond that; I don't mean that in a "back in my day" sort of way. But if you do start there, the rest of the stack makes a lot more sense than trying to start directly with React as your first intro to the web, as fine as React may be.
I bounced off of React & friends a few times before discovering the Lean Web movement. I'm genuinely happier for having found it. As a beginner, things like React and Elm feel opaque and obscenely complicated, all in order to solve problems that I don't actually have. Vanilla HTML+CSS+JS offers a much more pleasant learning curve, and has made it a fair bit easier to maintain momentum as I learn. From what I can tell, I'll probably also be able to take them really, really far before I need to adopt a front-end framework.
I'm actually kind of wondering, now that I am more familiar with the history of the technology, if the continuing popularity of front-end frameworks is largely a hold-over from an earlier time when Web standards were weaker. Vanilla JavaScript and CSS have become a lot more capable over the past few years, but dropping back down to them may be technically or socially difficult. It's always easier to add more things to the pile than it is to take them away. Sunk costs and all that.
I'm not familiar with 6800, but I've heard people rave about 6809. I did do some 68000, and it was pretty good too.
Oh, and IBM 370 type assembly is pretty interesting too, and very high level. for example, I think they could pretty much 1:1 map fortran statements to assembly statements. I also vividly recall the 4-register block move with pad - src addr, src len, dest addr, dest len, and pad was a high-order byte in one of them.
"Who cares if it doesn't run on 80386?"
"Who cares if it doesn't run on PowerPC?"
"Who cares if it doesn't run on 64 bit?"
"Who cares if it doesn't run on ARM?"
And now: "Who cares if it doesn't run on 32 bit?"
They write code that makes assumptions about endianness, about sizes of pointers, about floating point formats, and then come up with rationalizations about why it shouldn't matter if their code only compiles and runs on one architecture.
If we had taken all of them at their word, every architectural upgrade would require a rewriting of a majority of software instead of a recompile, and the open source world would be vastly different, and not in a good way.
Old technology is a way to teach people about our roots, how our current path was informed by those roots, the lessons learned from mistakes, and the lessons learned from the successes.
Code that has been functional, untouched, for decades has a nobility; but a job that has been worth re-coding the solution every few years is actually important.
"This isn't something I want to spend my time on" isn't a rationalization, it's a simple statement of preference. I personally feel absolutely no cognitive dissonance or regret about all the hand-coded PPC I wrote a couple decades ago, nor do I accept someone else wanting me to feel bad about it. It was (and needed to be) optimized for the machine I was working on at the time, and if I were moving it to a new platform, I probably would have wanted to do the same for it, too. As it turns out, though, the need never arose. The code was abandoned before the platform was. In short, YAGNI.
Similarly, "This isn't a worthwhile expenditure of our company's resources," isn't a rationalization, it may be a simple statement of business reality. To take a simple example, a video game studio producing an exclusive title has very different incentives around code portability than an indie studio that plans to release on 5 different platforms. What's the point of developing your game to work on iOS if you have no plans to - and may even be contractually not allowed to - release it on that platform?
With function inlining, you can often move your little weirdo bit of code into a function that is off the main call path and if people don't like it, they don't have to look at it. Also the fact that your change is in a single commit means they can always revert it if they don't like it (a bluff almost nobody calls).
More importantly, when it comes time to port the code, the intent of your weird little code is both known and self-contained. They can decide what to do about it and have a path to do it.
When your clever tweaks are peppered throughout your data architecture and half of the code base, then porting is a costly affair. And in some cases just updating your tools is hampered as well.
Creating emulators today is vastly better use of resources than anyone writing ancient console games considering long term portability issues.
But, to get more practical: The wider your compatibility surface is, the harder and more time consuming your software is to write.
I once worked on a C# desktop product in the early 2010s where we had a requirement to support Windows XP. This prevented us from using newer features in C#, like the task API, which added a lot of complexity to our UI code. (It's much easier to write UI code in C# when you can "await" in one line instead of dealing with callbacks.)
Another drawback (of remaining compatible with Windows XP) was that we had to stick with an old version of .Net, which had bugs. Specifically, we were making a XAML UI, but XAML support in .Net for Windows XP was buggy.
Furthermore, we had to test our product on Windows XP, in addition to both 32-bit and 64-bit versions of Vista, 7, and 8.
Eventually product management realized that it cost more to support Windows XP than the additional sales it would make, so they dropped the requirement.
So, yes, "Who cases if it doesn't run on XYZ." Supporting "everything" often has real consequences and real costs.
Many of my synths use 3.5" floppies. The ones that use FAT formatting can easily be used with a USB floppy on a modern computer, but the ones that have their own proprietary disk formats (most of them) require software with direct access to the floppy that can't be got through a USB connection. So, for those, I have an old Windows laptop with built-in floppy and software like Omniflop to manage those disks.
Probably one of the greatest things to make old tech more manageable (for me) is the SCSI2SD project, which makes an SD card into a SCAI device. Since SCSI was hugely popular with classic samplers (synths that can record audio and use the recorded audio as the sound source in the synth sound) I have a half dozen SCSI2SD drives so I don't have to keep ancient parallel SCSI dive alive.
I play around a lot with retro networking and have exposed myself to all sorts of old protocols, technologies, etc. that maintain my interest much more than the IP monoculture of today.
Also I get to practice skills I otherwise wouldn’t. I’ve done more hardware hacking reverse engineering in retro stuff than modern stuff, partially because it’s simpler, partially because I actually have a real goal or objective, versus just doing something for rote.
Indeed - recently discovered the Transputer and Connection Machine and their attempts to build and code parallel machines!
More modern examples of retro tech include Chuck Moore's GA144 a forth based 144 core asynchronous chip
For example writing an emulator for an older 8-bit CPU will be a simple problem overall to tackle than x86.
That said, sometimes using modern technology is better for teaching since there are more tools and resources that exist today to help you learn today's technology than there are for older technology.
So it depends. But it's definitely worth not completely ignoring old technology when learning a topic in case the older tech _is_ easier to learn because it's simpler.
UI latency is a never ending source of frustration to me, in large part, because it simply shouldn't exist with the computing power we have at our fingertips.
On the other hand we have Microsoft Outlook and Microsoft Teams that are both absolute bastions of waste and instability. And not just in compute terms either, but in terms of my time - the finite number of breaths and heartbeats I have left - that is squandered in waiting around, restarting, rebooting my machine, because of these unstable, crashy behemoths.
"This code only has to run on the 1401, when we get a new system it won't be compatible, so it won't be around long anyway. Next time we'll write a better version incorporating our experience from this one, and taking advantage of the new hardware."
Then IBM System 360 made things backward compatible, and the world broke. We saved tons of programmers time, and Y2K was a secondary effect of those savings.
In the meantime much has happened. So Modern processors were designed to seamlessly run existing software.
For example Memory used to be fated the processors clock cycles so fetches were free. Now it’s 100x slower. So we put caches in to fool the software into thinking it’s just as fast as it used to be.
So all software runs in a bubble like it was still running on a PDP-11.
Just like the body continues to carry around a liquid environment with a salinity level equal to the ancient ocean.
Sometimes, old ideas are not fully known or understood, as our field is relatively new. Going back to the writings of Engelbart or Papert, I've discovered some new things about original intent that the first implementations missed.