One downside of working with the old Inmos Transputer devices is the rarity and cost of the original silicon. Obviously, you can’t sidestep the acquisition of the processor—unless you emulate—but what about replacing the IMS C011/C012 link chip? You need this (expensive) part to interface the transputer to the programming host, but as [Erturk Kocalar] discovered, it’s perfectly possible to coax a Teensy to do that job for you just as well.

Transputers work by utilizing an array of bit serial interfaces to connect a network of devices, allowing for cooperative computation on tasks too large to fit on a single device. This protocol is, at its link level, a simple asynchronous bit serial affair, with 11-bit data messages, and a raw two-bit frame for the acknowledge. The C011 device at its heart is just a specialized UART—it takes 8-bit parallel data from the host, dealing with handshaking, and pushes it out to the first transputer in the chain at 5, 10 or 20 Mbps, but inverted and with two start bits and a single stop bit. In parallel, it performs the same task in the reverse direction.

[Erturk] realized that the Teensy UART has an inverted mode and, crucially, a 9-bit data mode. This allows the second start bit to be generated as bit 0 of the word, with the remaining eight bits forming the payload. Simple stuff. Additionally, the Teensy UART is capable of the maximum transputer bitrate of 20 Mbps, without breaking a sweat.

There is a slight issue, however, in that there is no way to send or receive the two-cycle acknowledgement frame directly. Since the protocol stop bit is a low, it is possible to implement this by simply sending a dummy data word with all 9 data bits low (since the acknowledge is a ‘1’, ‘0’ pattern). In one specific corner case, that of a direct memory PEEK operation, the command is clocked into the transputer, which sends back a two-cycle ACK—almost immediately followed by the 11-cycle data packet with the result. But, since the Teensy UART is still busy ‘fake decoding’ the full 11-bit dummy ACK message, it will miss the data packet entirely.

It turns out that the easiest way to get around this is to speed up the link and run at the maximum 20 Mbps rate. That way, the Teensy will have fully received the overly-long ACK long before the transputer has completed the PEEK command and started to send over the result. Why you would voluntarily run the link slower escapes us, once you’d got the design dialled in and reliability was a given, anyway.

We like transputers, a cool technology that died too soon. Here’s a quick guide to these innovative devices. Some people are really into transputer hardware, like this person. Finally, with the genuine hardware finicky to work with, expensive and hard to find, you could play along with your trusty web browser, and tick it off your nerdy bucket list.

Indycar Racing 2 was a good game, back in 1995; in some ways, it was the Crysis of the Clinton years, in that most mortals could not run it to its full potential when it was new. Still, that potential was surely fairly limited, as we’re talking about a DOS game from 30 years ago. Sure, it was limited– but limits are meant to be broken, and games are made to be modded. [TedMeat] has made a video showing the updates. (Embedded below.)

It turns out there was a 3D-accelerated version sold with the short-lived Rendition graphics cards. That version is what let the community upscale everything to the absurd resolutions our modern monitors are capable of. Goodbye SVGA, hello HD. Specifically, [sharangad] has created a wrapper to translate the Rendition API to modern hardware. It doesn’t sound like higher-res textures have been modded in, in which case this looks spectacular for graphics designed in 1995. It’s not the latest Forza, but for what it is, it impresses.

The second hack [TedMeat] discusses is a mod by [GPLaps] that pulls physics values from game memory to throw to a modern force-feedback wheel, and it shows just how good the physics was in 1995. You really can feel what’s going on– stopping a skid before it starts, for example. That’s normal these days, but for the kids playing with a keyboard in 1995, it would have been totally mind-blowing.

As tipster [Keith Olson] put it: “What can I say? Fans gonna fan!” — and we’re just as grateful for that fact as we are for the tipoff. If you’re in a fandom that’s hacked its way to keep old favourites alive, we’d love to hear about it: submit a tip.

The idea of gamifying all the things might have died down now that the current hype is shoving AI into all the things — but you’ve probably never seen it quite like EmuDevz, a game in which you develop an 8-bit emulator by [Rodrigo Alfonso].

There’s a lot of learning you’ll have to do along the way, about programming and how retro systems work, including diving into 6502 assembly code. Why 6502? Well, the emulator you’re working on (it’s partially-written at the start of the game; you need only debug and finish the job) is for a fantasy system called the NEEES “an antique game console released in 1983”. It’s the NEEES and not NES for two reasons. One, Nintendo has lawyers and they really, really know how to use them. Two, by creating a fantasy console that is not-quite-a-Famicom, the goalposts for EmuDevz can be moved a bit closer in.

The in-game emulator will handle most NES behavior, assuming you do your part correctly. A selection of homebrew NES games is included with EmuDevz, and they all run fine. A neat touch is giving you the ROMs for offline use as rewards when you get them running correctly. If some edge cases and exotic behaviours get left behind in the interests of simplicity, just remember– it’s not a NES, it’s a NEEES, and who can say? Perhaps this simplified system is exactly how it worked in the alternate universe where this game is set.

Aside from the invaluable assembly code, the work is done in JavaScript, which might not be everybody’s cup of tea. On the other hand, the whole thing is open-source (MIT license for the code, CC for the content) so if you really, really hate JS but love the idea of a learning game like this, you could fork to the language of your choice and learn even more.

Regardless of the language used, we like this model and think the “game where you learn to make games” is a great educational model for programming skills that ought to be used more often. For an idea of what it looks like, check out the trailer below.

Thanks to [Rodrigo Alfonso] for the tip. If you’ve got a great gamified learning tool — or any other cool hack, for that matter — the tips line is fun and rewarding, even if we haven’t tried to gamify it.

Ok, you caught us. It certainly isn’t going to be the year of Algol. When you think of “old” programming languages, you usually think of FORTRAN and COBOL. You should also think of LISP. But only a few people will come up with Algol. While not a household name, it was highly influential, and now, GCC is on the verge of supporting it just like it supports other languages besides C and C++ these days.

Why bring an old language up to the forefront? We don’t know, but we still find it interesting. We doubt there’s a bunch of Algol code waiting to be ported, but you never know.

Algol first appeared in 1958 and was the lingua franca of academic computer discussions for decades. It was made to “fix” the problems with Fortran, and its influence is still felt today.

For example, Algol was the origin of “blocks of code,” which Algol set between begin/end pairs. The second version of Algol was where Backus-Naur form, or BNF, originated, something still of interest to language designers today.

Interestingly, the new compiler will do Algol 68, which was the final and not terribly popular version. It was sort of the “New Coke” of early computer languages, with many people asserting that Algol 60 was the last “real Algol.” Algol was known for sometimes using funny characters like ≡ and ⊂, but, like APL, had to adapt to more conventional character sets. Most of the Algol specifications didn’t define I/O, either, so it wasn’t enough to know Algol. You had to know which Algol so you could understand how the I/O worked.

If you want to learn Algol, there’s a tutorial on GitHub (use the compiler online, if you like). While [Niklaus Wirth] didn’t create Algol, he was a major player in some of its later development.

Those of us ancient enough to remember the time, or even having grown up during the heyday of the 8-bit home computer, may recall the pain of trying to make your latest creation work on another brand of computer. They all spoke some variant of BASIC, yet were wildly incompatible with each other regardless. BASICODE was a neat solution to this, acting as an early compatibility standard and abstraction layer. It was essentially a standardized BASIC subset with a few extra routines specialized per platform.

But that’s only part of the story. The BASICODE standard program was invented by Dutch radio engineer Hessel de Vries, who worked for the Dutch national radio broadcaster Nederlandse Omroep Stichting (NOS). It was designed to be broadcast over FM radio! The idea of standardization and free national deployment was brilliant and lasted until 1992, when corporate changes and technological advancements ultimately led to its decline.

The way this was achieved was to firstly use only the hardware instructions that were common among all the computers, which meant BASICODE applications couldn’t utilize graphics, sound, or even local storage. This may seem very limiting, but there’s still a lot you can do with that, especially if you don’t have to write it yourself, pay for it, or even leave the room! First, the BASICODE program needed to be loaded from local storage, which, when started, allowed the import of the BASICODE application that you previously recorded off the radio. It’s kind of like a manually loaded bootloader, except it includes an additional software library that the application can use.

Later versions of the standard included storage handling (or an emulation of it), basic monochrome graphics, and eventually sound support. The linked Wikipedia article mentions a list of about 23 BASICODE platforms; however, since there is a standard, you could easily create your own with some effort. In addition to allowing users to send application programs, BASICODE also enabled the reading of FM-broadcast ‘journals,’ which were transmissions of news, programming tutorials, and other documents that might interest BASICODE users. It was an interesting concept that this writer had never encountered at the time, but that’s not surprising since only one country adopted it.

If this has got you hankering for the good old days, before the internet, when it was just you, your trusty machine and your own imagination, then we think the ten-line BASIC competition might be of interest. Don’t have such a machine, but have a web browser? (we know you do), then check this out. Finally, if you want to see something really crazy (for a BASIC program), then we’ve got that covered as well.

Thanks to [Suren Y] for sending this in!

Anyone into retro Macintosh machines has probably heard of BlueSCSI: an RP2040-based adapter that lets solid state flash memory sit on the SCSI bus and pretend to contain hard drives. You might have seen it on an Amiga or an Atari as well, but what about a PC? Once upon a time, higher end PCs did use SCSI, and [TME Retro] happened to have one such. Not a fan of spinning platters of rust, he takes us through using BlueSCSI with a big-blue-based-box.

Naturally if you wish to replicate this, you should check the BlueSCSI docs to see if the SCSI controller in your PC is on their supported hardware list; otherwise, your life is going to be a lot more difficult than what is depicted on [TME Retro]. As is, it’s pretty much the same drop-in experience anyone who has used BlueSCSI on a vintage Macintosh might expect. Since the retro-PC world might not be as familiar with that, [TME Retro] gives a great step-by-step, showing how to set up hard disk image files and an iso to emulate a SCSI CD drive on the SD card that goes into the BlueSCSIv2.

This may not be news to some of you, but as the title of this video suggests, not everyone knows that BlueSCSI works with PCs now, even if it has been in the docs for a while. Of course PCs owners are more likely to be replacing an IDE drive; if you’d rather use a true SSD on that bus, we’ve got you covered.

Back when the IBM PC was new, laying out an ISA board was a daunting task. You probably didn’t have a very fast ‘scope, if you had one at all. Board layout was almost certainly done on a drafting table with big pieces of tape. It was hard for small companies, much less hobbyists, to make a new card. You could buy a prototype board and wirewrap or otherwise put together something, but that was also not for the faint of heart. But with modern tools, something like that is a very doable project and [profdc9] has, in fact, done it. The card uses an ATMega328P and provides two SD cards for use as mass storage on an old computer.

The design tries to use parts that won’t be hard to get in the future. At least for a while, yet. There’s capacity for expansion, too, as there is an interface for a Wiznet 5500 Ethernet adapter.

Can you imagine if you could transport this card back to the days when the ISA bus was what you had? Just having a computer fast enough to manipulate the bus would have been sorcery in those days.

We don’t know if you need an ISA mass storage card, but if you do, [profdc9] has you covered. Then again, you do have options. Or, if you’d rather take a deep dive into the technology, we can help there, too.