Old computer systems are fascinating from many points of view: The article discusses the software used to wring the last drop of performance out of hardware that we would probably now consider to be inadequate for running a disk controller. It's super cool that many of these systems are now available as emulators! I was a little surprised that the author only got twice the performance of the DtCyber in an emulator until I saw that they were emulating on an 800MHz P3 :)
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)...
> My understanding is that managing heat is >still< the ultimate factor limiting performance
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.
Not specifically, but the top of the keyboard does get warm when all this is going on. Do you or anyone have any recommendations for temperature monitoring software for a ThinkPad running Windows with various other OSes in VMs?
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.
Thanks for the tip. Yeah, "Intel Virtualization Technology" and "Intel VT-d Feature" are both enabled by default in the BIOS (in fact it doesn't let you turn them off).
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.
Ah yes, these fans may get loud, but they are nothing like an office back in the day full of hackers on ASR-33 Teletypes!
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.
Everything that is thin and light is going suffer from heat earlier than a bigger laptop.
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.
That's ludicrous. The 6502 is the best 8-bit processor that ever existed ;-)
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.
There's every chance I'm remembering it wrong - the double the clock speed certainly rings a bell. Got a weekly video call with a friend who still regularly hacks on a Beeb, so will try and clarify and update my comment tomorrow :)
The Beeb and the Ataris ran at 2 MHz. Apple II, VIC-20, C64, and 1541 all ran at 1 MHz. The 1571 ran at 2 MHz, same as the C128 (except when pretending to be a 64)
The 1571 was the drive meant for the C-128, which could also run at double speed (2 megahertz!) with the C-64 video chip disabled and the 80-column video running.
On the C64/1541 you could definitely upload code to one or more of the 256-byte 1541 disk buffers and make the drive execute it. The problem is you have 3 pins to transmit your data and those are not connected to any communication facility like an ACIA - you have no choice but to involve the CPU in some bit banging there.
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.
> The problem is you have 3 pins to transmit your data (...) you have no choice but to involve the CPU in some bit banging 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.
They did, but the CPU still has to manually manipulate the ATN, DATA, and CLK pins.
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.
One thing you could setup on the Commodore drives is file copying from on drive to another without it going thru the computer, they just talked to each other. You could also do the same thing if you had a straight text file and sent it to the printer (I am not sure which printer models) with again not using the computer after the handshaking was set up.
The college I went to had air cooled tape drives. For some reason one unit would get too hot and stop working.
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.
Most things are interesting simply due to the fact that they were produced by and through the constraints of their time. Seeing how people solved these contextual problems very often is fascinating. And then there's the spirit/aesthetics/goals of the era.
The university I went to had used Xerox Sigma 6/7/9s. One of them is now in the living computer museum. Yeah! After programming 6502 assembler in high school, having multiple blocks of 16 32-bit registers was breath-taking. My brain was wired to the 6502 X/Y/A thing so I doubt I ever used more than 5-6 of them at a time. After doing a lot of 8-bit micro and X86 assembly, doing ARM assembly for the first time felt similarly freeing.
> In fact, the operating systems that run on "old computers" are surprisingly sophisticated and complex.
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".
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.
I think there was a certian degree of bravery (or foolishness really) that authors of older software had WRT their willingness to couple with certain things (poking registers/DMA with specialized hardware, monkey patching OS components etc.)
We have a lot more layers of abstraction, in the name of productivity. That's certainly more complex, and from a certain point of view, more sophisticated.
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.
> 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.
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.
It's literally two lines, yet it handles hexadecimal and octal too. :) Of course, if you set up some parser combinators with a nice library in C, it could be a one liner in C too.
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.
> But the PP concept and the offloading of the OS from the main CPU is still a very interesting idea - and one which is unlikely to be explored in foreseeable future machines.
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.
Can the kernel do it transparently on asymmetric core machines? Intel did show one some time ago and you can kind of manufacture cores with bigger caches and more execution ports by turning off SMT for them, turning an 8-core x86 into 8 "cores" with smaller cache and another 4 with twices as much L1.
I don't think you can be totally transparent; [1] if the cores are really asymmetric, there will likely be timing differences. But, you could certainly do things like if only the big cores support AVX, indicate AVX support to the program, and if it's running on the little core when it hits an AVX instruction, the kernel handles the invalid operation fault by rescheduling it to run on the large core.
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.
I think the best way would be two different approaches. One, perhaps based on nice values or other priorities, that would push scheduling to the smaller cores and one, one-way, where some form of program metadata indicates which kind of core would be optimally suited to run it without the program having any awareness of it.
One thing I always notice on the CDC 6x00 family is that the vectors on screen are drawn so fast (to fit enough text on the high persistence phosphor before needing to redraw) that analog artifacts appear on the fonts themselves, giving them a whimsical, almost Comic Sans, look.
Funny to see the analog side isn't able to keep up with the digital hardware. That's peak Seymour Cray.
What has always fascinated me about old hardware/software is the "what if" aspect.
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 actually have one family member that uses mini-discs. Mostly to listen to older stuff that she only have on mini-disc, but that's also an indication of how durable those things are. Getting new mini-discs plays is however getting extremely difficult, and expensive.
Minidiscs for music were very popular before MP3 players had reasonable storage space, at least here in Denmark and AFAIK in most of Europe, and obviously in Japan.
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.
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.
> 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.
Holy crap, I had no idea that the screenwriter for Tron was connected to Alan Kay. Thanks for that tidbit. Sounds like she became romantically connected to him after meeting him while researching the movie. Neat.
I'd love to see her original script before it got ruined. Sounds like her and Kay were pretty bitter about it.
I’m not sure I’d like her take. I don’t like too much the movie either. I’d like the programs to be more alien, more funhouse mirror images of their creators, and be portrayed as AÍ semi-autonomous agents.
But that’d be a lot to demand on that age. They already had artificial life for their credits and that’s impressively prescient.
There were a few other possible tie-ins. The word TRON itself was a command in several MSFT Basic interpreters of the 8 bit era. It was short for TRACE ON and its companion for TRACE Off was TROFF. They shortened strings because space was limited in the 8K ROM.
What I like about old computers: creative solutions. These machines were severely limited by today standards, so to do anything useful, interesting workarounds had to be developed.
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.
IMHO older computers are more interesting because you can have much better relative understanding of what they consist of, how do they work and and much higher relative degree of control over them. They induce senses senses of curiosity, flexibility and security this way.
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.
I have been looking for a cheap fpga devboard for this sort of thing, but results have been somewhat disappointing. The tinyfpgas look great but have been sold out for a long time. I have seen some interesting ones on tindie but the selection is quite limited. Does anyone here have any good pointers? (Plus for one with a hand-solderable fpga)
The iCE40 from Lattice is pretty popular for its open source (reverse engineered) toolchain.
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.
the iCE40HX4K is available in TQFP-144, which can be reliably hand soldered after some youtube videos and practice.
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.
I love watching retro computing channels on YouTube, and many of them does such a great job of explaining CPUs like 6502, 6510, Z80 or Motorola 68000. Especially the 6502 is interesting, not because it's a marvel of technology, but because you can learn how it work in a reasonable time frame. I took university courses in computer architecture, but I can explain how a modern PowerPC or AMD64 CPU work. The 6510 is something I can easily follow when some guy on YouTube explains how a C64 works and how he goes about debugging and repairing a broken system.
Probably my favorite example of this is this guy's demonstration of an Altair 8800, one of the earliest PCs, back when they had physical switches on the front panel which you would use to manually enter machine code for the computer to run. Scroll down to the bottom for the earliest videos to see the introductory demonstrations. He builds on that to show how data was loaded from paper punch tape, then later audio cassettes and external disk storage: https://www.youtube.com/user/deramp5113/videos
I think it's all state-of-the-art vs grassroots-tech-tree
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.
My favorite old computer is the Mark I perceptron, which was a neural network hardware computer (single layer) with light-sensitive visual receptors, weights controlled by self-turning potentiometers, and maually wired full connectivity: https://en.wikipedia.org/wiki/File:Mark_I_perceptron.jpeg
There were 4 of the then state-of-the-art, fastest in the world, CDC-7600 and CDC-6600 computers installed at Lawrence Livermore Lab (LLL, now LLNL, Lawrence Livermore National Lab) when I worked there during the summer of 1972.
370 assembly language was interesting in so many ways. Applications were responsible for maintaining their own call stack and there were processor-level instructions for converting a number encoded in EBCDIC and converting it to a machine level int.
This is only just slightly related, but I am working on a project based on Algorand, and one of the interesting things about it is that the smart contracts are written in something somewhat like an assembly language. It actually is deliberately not Turing complete because it does not allow looping or recursion, but has a few interesting features and constraints.
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.
Whenever people talk about old computers I need to mention the C64 that really laid the foundation for PCs today, new releases are coming every day: http://csdb.dk
What is "interesting" obviously depends on the person. I always liked playing with old *nix workstations from the 90's. Something about tinkering on a box that would have cost over $50,000 new is interesting to me.
So, I guess video and network cards are the two most common remaining components that could be called "peripheral processors"?
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!
“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.
86 comments
[ 4.4 ms ] story [ 148 ms ] threadIn 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.
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 :-(
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.
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.
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.
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
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.
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.
Why is this sad? Is it sad when cab drivers buy new cars instead of kit 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.
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!
“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.