Why Some Old Computers Are Interesting
hccc.org.uk
hccc.org.uk
Compared to the computers from the previous century which could be built, modified, repaired and operated consciously, modern ones are more of disposable magic-button black boxes which will turn into pumpkins as soon as the vendor servers turn off and go extinct like ancient magical creatures as soon as the factory in Taiwan shuts down because nobody has a serious idea about all their internals and how to produce them anymore.
Sadly, there already is a generation of programmers who aren't even interested in being able to assemble their own PC from a set of boards, let alone understanding anything about things like registers and the physics behind them.
UPDATE: yes, I would say the same about cars.
When RISC-V and open source FPGA toolchain become more popular, I guess more and more programmers will come back to play with hardware.
As far as hand soldering an FPGA, you’re gonna have a hard time finding any that aren’t BGA simply because of all the IO. They exist, but probably not in dev board form as they’re really limited in IO and cells.
i think there are still xilinx CPLDs in TQFP too.
should be boards floating around for any of them. if not, well, only reason you'd want to hand solder it is because you're making your own board. a simple dev board is great practice to make sure you've got your package correct.
Just to avoid possible confusion, I think you meant "I can't explain", is that right?
Meaning - the state of the art stuff can't be explored by normal people, but over time the knowledge and tools trickle down and it becomes democratized.
Older cars were accessible to shadetree mechanics, who could work on most stuff. When they became electronic, it cut some people off... until things like canbus became known, and later tools became generally available to folks with a laptop.
Only twist nowadays is manufacturers are actively preventing some things through cryptographic signatures and the like. Hopefully, eventually, this will get tools to allow people to mess with things.
In addition, visiting these old devices IRL is pretty instructive: one thing that always strikes me when I visit the Computer Sheds in Yorkshire (http://www.computermuseum.org.uk/ - an absolute gem BTW) is the enduring problem of thermal management. Up close, those old mainframes are basically huge air conditioning systems with some chips attached. My understanding is that managing heat is >still< the ultimate factor limiting performance (otherwise we could just stack up silicon in 3D)...
It seems fitting that I'm hearing the fans spin up to full blast on my ThinkPad X1 Extreme laptop supercomputer as I compile some code in an Ubuntu VM while starting up a CPU-hungry Point Of Sale system in a Windows VM, and reading your comment on the Windows host OS.
It is nice that I can step away from the computer and just listen for the fans to quiet down again to tell when everything is ready to go.
In any case I think the POS software may be the main culprit, as it normally runs on a standalone machine and wasn't designed for power savings. I did set the Windows VM it runs in to "Power saver" but it doesn't seem to have helped much.
(Sorry if this is off topic for the thread!)
If not prepare for a performance boost, and a quiet Fan ;)
https://github.com/hirschmann/nbfc
I'm asking because I'm wondering how often it hits 99 degrees and throttles. And if it doesn't, I really need to take a closer look at it, because that would be incredible.
Dell and HP machines have this problem, 6 core Intel processors run slower than 4 core ones because the former always throttle (even though the TDP is supposedly the same).
If you want, you can use Throttlestop to set better controls/limits on clocks and power (and possibly undervolt it) for better performance, battery life and temperatures.
We had much less going on when we joked that you know who is compiling or running any sort of serious work in the office by hearing whose MBP was whining hard with its fans.
Each one had a noisy keyboard and a noisy printer. The keyboard didn't have a nice click like a modern keyboard, more of a loud scrunchy sound. The printer was even louder and rang a bell if you had a line too long.
You could always tell when the mainframe crashed. Everyone's Teletype printer stopped all at once, and everyone started mashing down every key on their keyboard out of frustration.
Game laptops or workstation laptops are better solution(s) but the best is getting a desktop. I'm not joking and I'm aware of taking a device with you everywhere.
Wasn't the disk controller chip in the BBC Micro significantly more powerful than the main CPU? I think some games used it as a coprocessor.
Now, on a more serious tone, any processor in the machine you could detect could be used to offload some processing from the CPU. I wonder if that wasn't done with 1541 or 1571 Commodore floppy drives. I know there was software that wrote new functionality onto the drive's memory to make disk IO faster.
With enough memory, you could sort a text file and write the output to a new file without ever bothering the CPU. I don't think that was ever actually done, but the drives also ran 6502 processors, and the 1571 ran at twice the main computer's clock.
The 1571 used the burst mode of the CIA IIRC (also IIRC it wasn't done in the 1541 to be compatible with the VIC20) so there were more possibilities there.
Well... As long as the code takes longer to compute than it takes to push/pull the data, it's still a win.
I really can't think of any practical usage, of course. Maybe transforming ASCII files to EBCDIC ones without involving the CPU, or generating CRC32 values for the files on disk.
There's no I/O controller, just two "Complex Interface Adapter" which each have 8 I/O ports, readable/writeable by the CPU using standard LDA/STA, etc. instructions. (The CIAs also have a timer and can generate IRQs).
IIRC 3 bits from CIA #2 can set/read each pin state. The CIA won't do anything to those on its own at all.
I think there were plans to use something like IEEE-488 or GPIB but scrapped due to cost.
So you can definitely write a program to implement a faster protocol than the one in the Kernal/1541 ROM (e.g use DATA and CLK as data lines and use ATN to sync, doubling transfer rate), but the CPU will still need to be 100% utilized in the (shorter) transmission.
Up until mid-90s, there was a real diversity of ideas and architectures in computing. 68K, PPC, x86, RISC, ARM, MIPS, i860, and I'm forgetting a lot of others. There were a lot of interesting ideas, some of which did become standard, while others died either for technical reasons (lack of adequate 3D capability on the Amiga) or because of business deals that didn't pan out (such as BeOS on Macintosh being dumped in favor of buying out NeXT).
Of course x86 seems standard and humdrum today, but it wasn't necessarily meant to be that way.
We could have been running BeOS on i860-based hardware, with MiniDiscs for removable storage, if things had panned out differently. And I find that fascinating to consider, when examining old computers.
I wonder why that never amounted to anything. If I recall a few drives was made, but the cost just meant they where out of reach. The disc was just so cool, like take out of a sci-fi.
I think what killed them was ultimately the iPod.
If you had to pick between an MP3 player with 32MB or maybe 64MB of fixed internal memory, or a Minidisc player where each disc could hold a full CD album and you could swap them as easily as a CD or a floppy disk, the choice was pretty clear, especially when you looked at it as a logical progression from a discman. The ATRAC codec is a mostly-OK lossy codec. Not full CD quality, but it was comparable to MP3 at the time.
(Minidiscs never supported MP3 until right at the end of Hi-MD, otherwise they were ATRAC and eventually CD-quality PCM only.)
The final iteration (Hi-MD) could hold 1GB of data or 94 minutes of full CD-quality uncompressed PCM audio, but that was too little and too late when it came out in 2004.
As for using Minidisc for data, that was a slightly different kettle of fish. The format was absolutely capable of doing it and the original discs could hold 140MB (increasing with later format revisions), which would have been absolutely groundbreaking in the early 90s. All of the technology was mature and proven and fully capable of displacing both the floppy disc and the CD. This was before the Zip disk, with higher storage capacity and actually reliable. The magneto-optical Minidisc could theoretically be rewritten millions of times, and sure each disc was a bit expensive initially, but they were super durable with a tough plastic shell, and 140MB of storage was more than a lot of people's home computers had at the time.
Unfortunately the record label arm of Sony were terrified of organized illegal copying and distribution, and because everyone was generally stuck in a mindset of seeing Minidisc as a cassette tape replacement rather than a general data storage format, it was stuck with real-time dubbing only (some devices with integrated CD and MD players offered high-speed dubbing, but it was still just dubbing, not data transfer). It didn't get data storage capability until the Hi-MD in 2004, which again was too little too late.
Combined with Sony's general insistence on keeping their formats proprietary and locked down (see Memory Stick, UMD, Betamax, DAT and so on), everything just conspired to not let the technical capabilities of Minidisc come to fruition.
There was an MD Data format, but it never really got off the ground. It used special incompatible MD Data discs, which were rare and expensive, plus the drives themselves were big, clunky and expensive.
Minidisc was legitimately a big hit for a while, for portable music. But it never quite displaced the CD and it never became the data storage format it could have been. And now we've got cheap flash memory, so even the idea of a magneto-optical disc seems a bit quaint and antiquated.
1. 8-bit bytes (7,6,9 were common) 2. Byte-level addressing (word addressing was common) 3. One's complement
These are the lineage of machines Knuth implemented his famous ALGOL-60 compiler on. There's a nice video about the B6500 that was discussed on HN years ago: https://news.ycombinator.com/item?id=7880027
I did some work adjacent to a UNISYS ClearPath "A Series" machine and later a PC-based version back in the early 2000s. Watching the operators and field service technicians working on it I got a feeling of a very mature environment. (Not necessarily fun to use by the look of it.) I got a bit of an IBM AS/400 feeling watching users interact with it in terminal emulation. For somebody with a Unix and MS-DOS background it just seemed odd.
After that contract was up I mostly forgot about it. I heard a talk where Alan Kay referred to some old Burroughs system. I got to reading about Burroughs and learned UNISYS was a successor. That led down a rabbit hole that ended up at these B5000-descended machines.
It looks like it was a well thought-out architecture that persists today (albeit in software, rather than hardware). The operating system, MCP, is still under development.
MCP is, by far, the most user hostile OS I've ever seen. It's no surprise Bonnie McBird, who wrote Tron's screenplay and is Kay's wife, used it as the name of the villain.
I'd love to see her original script before it got ruined. Sounds like her and Kay were pretty bitter about it.
https://web.archive.org/web/20030109182549/http://www.tron-s...
But that’d be a lot to demand on that age. They already had artificial life for their credits and that’s impressively prescient.
Good times...
... with respect for constrained environments, by way of contrast, via https://github.com/globalcitizen/taoup
UpToDate MVS distribution: http://wotho.ethz.ch/tk4-/
UpToDate vm370 distribution: http://vm370.org/VM/V1R1.1
390 Emulator: https://github.com/SDL-Hercules-390/hyperion
Best 3270-Terminal for windows: http://www.tombrennansoftware.com/download.html
3270-Terminal for *nix or Win: http://x3270.bgp.nu/
I wonder if my 3270 font would work with Vista tn3270... It doesn't with x3270 :-(
Are they? Or are we just slowly forgetting that everything in modern software is composed of concepts invented pre-1980 (and in fact pre-1970 for the most part)?
It's called "Turing's Curse" [0]
To clarify, it's the "surprisingly" part that is not true. Certainly the software is sophisticated. What is surprising is how often we think our modern software is "sophisticated".
[0] https://www.youtube.com/watch?v=hVZxkFAIziA
EDIT: but, I guess we have done some modern cool stuff with GPUs, consensus algorithms including PoW, and a few cool ML model architectures and training techniques.
Meanwhile (I can't be the only one who's noticed this?) it seems like it takes a team 5x as large 2x as long to write a program that does the same thing as some 80s or 90s equivalent.
I'm not sure what to make of that.
While I can't attest to team performance, I wrote a toy compiler over the long weekend here just now. There were wizards who could do that 30 years ago in a weekend, of course.
But I'm not one of them. It occurred to me that if I hadn't used Haskell and some great libraries, built with a compiler that takes hundreds of MB of RAM to run, and was instead using C or assembly even, I'd probably still be trying to get integers parsing correctly.
The productivity increase of modern development tools seems real enough to me.
I figure it's not the language, so much as the libraries and tooling around the language. Back in the day, one couldn't stick a term in the project definition, have the compiler automatically download and assemble a library, then invoke it with one line in the program code, all within 10 seconds. You'd have to start with "is this a digit?" and build up from there, like I did back in my CS courses with Pascal, once upon a time.
In the home-computer field, for example, using off-the-shelf cassette tape as storage, compiling code in multiple passes with persistence, simpler byte-code interpreting to increase code density, memory bank switching and other techniques are part of the charm of using that hardware.
Also, it is usually impressive to watch anything useful and quickly being done by constrained hardware.
Interestingly, a lot of the system services on macOS run on the power efficient but slow cores on the M1, keeping the beefy cores to user applications. I wonder if Linux can have an attribute for executables that indicate a preference of which kind or processor it should be preferably scheduled to.
If the program does a bunch of AVX once in a while, that can work well. If it's mostly AVX, and multithreaded, then you might likely spawn too many threads. If it's like one AVX instruction in each loop, that would also tend to be bad.
Balancing load would probably be a lot trickier than with SMP, but today's SMP is already tricky because frequency changes with the number of cores in use; it's not always optimum to run N threads on N cores anyway.
[1] and really, I think this meaning of transparent is really opaque; you don't want the program to know what core type it's running on.
Funny to see the analog side isn't able to keep up with the digital hardware. That's peak Seymour Cray.
http://www.chilton-computing.org.uk/acl/literature/reports/p...
Solution: Go behind it and flap the large access door a couple of times, and then it would start up and finish a compile. As you were waiting for the printouts it would keep cooling down and do the next job if it was not too long.
“With the exception of the Intel Itanium family, all of the architectural features that contribute to the performance of today's microprocessors first appeared (and were pretty fully explored) in a series of "mainframe" computers designed between the late 1950's and 1975.”
Here are just a few innovations hugely important to performance that came later: general out of order execution with precise exceptions, shared memory multiprocessor, memory disambiguation prediction, memory renaming.
Some of the innovations introduced during the described era were by no means “fully explored” either. For example, branch prediction advanced rapidly through the 80s and 90s, and the best branch prediction algorithm known today (TAGE) was developed in 2000s.
And, of course, architectural innovation continues to this day.
For example, it has built-in cryptography instructions.
The need to execute as many "programs" as possible to have a high transaction rate has pushed the design towards these intriguing constraints.
My interpretation of the ( frustratingly sparse ) documentation for the AWS Nitro hardware support seems to imply that it's pushed a bit more of the processing back out to the peripherals - which seems to buck the trend, but also seems highly effective.
For example, so far as I can tell, AWS's NVME drives have a lower latency from within a Nitro EC2 vm than a 905P Optane accessed from a KVM VM with PCIE passthrough on my play machine at home - although it's possible I've done something wrong with the setup!