The BBC Microcomputer, launched in the early 1980s, holds a special place in computing history. Designed for educational purposes, it introduced a generation to programming and technology. With its robust architecture and community-driven modifications, the BBC Micro remains a beloved project for retro computing enthusiasts. [Neil] from Retro4U has been delving into this classic machine, showcasing the fascinating process of repairing and upgrading his BBC Micro with a 68008 CPU upgrade.

Last week, [Neil] shared his progress, unveiling advancements in his repairs and upgrades. After tackling a troublesome beep issue, he successfully managed to get the BBC running with 32 KB of functional memory, allowing him to boot into BASIC. But he wasn’t stopping there. With ambitions set on installing the 68008 CPU, [Neil]’s journey continued.

The 68008 board offers significant enhancements, including multitasking capabilities with OS-9 and its own hard drive and floppy disk controller. However, [Neil] quickly encountered challenges; the board’s condition revealed the usual broken capacitors and a few other faulty components. After addressing these issues, [Neil] turned his attention to programming the necessary ROM for OS-9.

Looking to get your hands dirty? [Neil] has shared a PDF of the upgrade circuit diagram. You can also join the discussion with fellow enthusiasts on his Discord channel, linked in the video description.

Long before we had internet newsfeeds or Twitter, Ceefax delivered up-to-the-minute news right to your television screen. Launched by the BBC in 1974, Ceefax was the world’s first teletext service, offering millions of viewers a mix of news, sports, weather, and entertainment on demand. Fast forward 50 years, and the iconic service is being honored with a special exhibition at the Centre for Computing History in Cambridge.

At its peak, Ceefax reached over 22 million users. [Ian Morton-Smith], one of Ceefax’s original journalists, remembers the thrill of breaking stories directly to viewers, bypassing scheduled TV bulletins. The teletext interface, with its limited 80-word entries, taught him to be concise, a skill crucial to news writing even today.

We’ve talked about Ceefax in the past, including in 2022 when we explored a project bringing Ceefax back to life using a Raspberry Pi. Prior to that, we delved into its broader influence on early text-based information systems in a 2021 article.

But Ceefax wasn’t just news—it was a global movement toward interactive media, preceding the internet age. Services like Viditel and the French Minitel carried forward the idea of interactive text and graphics on screen.

The truth is, our desktop computers today would have been classed as supercomputers only a few decades ago. There was a time when people who needed real desktop power looked down their noses at anyone with a Mac or a PC with any operating system on it. The workstation crowd used Sun computers. Sun used the Sparc processor, and the machine had specs that are laughable now but were enviable in their day. [RetroBytes] shows off Sun’s final entry in the category, the Ultra 45 from 2007.

Confusingly, the model numbers don’t necessarily increase. The Ultra 80, for example, is an older computer than the 45. Then there were machines like the Ultra 20, 24, 27, and 40 that all used x86 CPUs. A ’45 had one or two UltraSPARC III 64-bit CPUs running at 1.6 GHz and up to a whopping 16 GB of RAM (the one in the video has 8GB). Sure, we see less powerful computers today, but they are usually Chromebooks or very cheap PCs.

The Ultra line started back in 1995 but went underground for a few years with a re-branding. Sun brought the name back in 2005, and the Ultra 45 hit the streets in 2006, only to discontinue the machine in late 2008. According to [RetroBytes], the Sun team knew the Workstation days were numbered and wanted to produce a final awesome workstation. Partially, the reason for sparing few expenses was that anyone who was buying a SPARC workstation in 2006 probably had a reason not to move to cheaper hardware, so you have them over a proverbial barrel.

We liked the CPU cooler, which looked hefty. Honestly, except for the type of CPUs in it, the box could pass itself off as a mid-range desktop tower today with PCI express sockets. The operating system was Sun’s brand of Unix, Solaris, now owned by Oracle.

Sun’s big competitor for a while was Apollo. We’d point out that if all you want is to run Solaris, you don’t need to buy new old hardware.

Long before the advent of the Internet and the World Wide Web, there were other ways to go online, with Ohio-based CompuServe being the first to offer a consumer-oriented service on September 24, 1979. In an article by [Michael De Bonis] a listener-submitted question to WOSU’s Curious Cbus is answered, interspersed with recollections of former users of the service. So what was CompuServe’s contribution to society that was so important that the state of Ohio gave historical status to the building that once housed this company?

The history of CompuServe and the consumer-facing services which it would develop started in 1969, when it was a timesharing and remote access service for businesses who wanted to buy some time on the PDP-10s that Golden United Life Insurance as the company’s subsidiary used. CompuServe divested in 1975 to become its own, NASDAQ-listed company. As noted in the article, while selling timeshares to businesses went well, after business hours they would have these big computer systems sitting mostly idly. This was developed by 1979 into a plan to give consumers with their newfangled microcomputers like the TRS-80 access.

Originally called MicroNet and marketed by Radio Shack, the service offered the CompuServe menu to users when they logged in, giving access to features like email, weather, stock quotes, online shipping and booking of airline tickets, as well as online forums and interactive text games.

Later renamed to CompuServe Information Service (CIS), it remained competitive with competitors like AOL and Prodigy until the mid-90s, even buying one competitor called The Source. Ultimately it was the rise of Internet and the WWW that would close the door on this chapter of computing history, even as for CompuServe users this new Internet age would have felt very familiar, indeed.

As the Commodore 64 ages, it seems to be taking on a second life. Case in point: Vision BASIC is a customized, special version of the BASIC programming language with a ton of features to enable Commodore 64 programs to be written more easily and with all sorts of optimizations. We’ve tested out both the original 1.0 version of Vision BASIC, and now with version 1.1 being released there are a whole host of tweaks and updates to make the experience even better!

One of the only limitation of Vision BASIC is the requirement for expanded RAM. It will not run on an unexpanded C64 — but the compiled programs will, so you can easily distribute software made using Vision on any C64. A feature introduced in version 1.1 is support for GeoRAM, a different RAM expansion cartridge, and modern versions of GeoRAM like the NeoRAM which has battery-backed RAM. This allows almost instantaneous booting into the Vision BASIC development environment.

Some of the standout features include a doubling of compilation speed, which is huge for large programs that take up many REU segments in source form. There are new commands, including ALLMOBS for setting up all sprites with a single command; POLL to set up which joystick port is in use; CATCH to wait for a particular scanline; and plenty more! Many existing commands have been improved as well. As in the original version of Vision BASIC, you can freely mix 6510 assembly and BASIC wherever you want. You can use the built-in commands for bitmaps, including panning, collision detection, etc., or you can handle it in assembly if you want! And of course, it comes with a full manual — yes, a real, printed book!

One of the nice features of Vision BASIC is the customization of the development environment. On the first run, after agreeing to the software terms, you enter your name and it gets saved to the Vision BASIC disk. Then, every time you start the software up, it greets you by name! You can also set up a custom colour scheme, which also gets saved. It’s a very pleasant environment to work in. Depending on how much additional RAM you have, you can hold multiple program segments in different RAM banks. For example, you could have all your source code in one bank, all your bitmaps and sprites in another, and your SID tunes in yet another. The compiler handles all this for you when you go to compile the program to disk, so it’s easy to keep large programs organized and easy to follow.

If you’ve always wanted to write a game or application for the C64 but just didn’t know how to get started, or you felt daunted at having to learn assembly to do sprites and music, Vision BASIC is a great option. You will be blown away at the number of commands available, and as you become more experienced you can start to sprinkle in assembly to optimize certain parts of your code if desired.

If you are a retrocomputer person, at least in North America and Europe, you probably only have a hazy idea of what computers were in the Japanese market at the time we were all buying MSDOS-based computers. You may have heard of PC-98, but there were many Japanese-only computers out there, and a recent post by [Misty De Meo] asks the question: What happened to the Japanese computers?

To answer that question, you need a history lesson on PC-98 (NEC), FM Towns (Fujitsu), and the X68000 (Sharp). The PC-98 was originally a text-only MSDOS-based computer. But eventually, Microsoft and NEC ported Windows to the machine.

The FM Towns had its own GUI operating system. However, it too had a Windows port and the machine became just another Windows platform. The X68000, as you may well have guessed, used a 68000 CPU. Arguably, this was a great choice at the time. However, history shows that it didn’t work out, and when Sharp began making x86-based Windows machines — and, of course, they did — there was no migration path.

[Misty] makes an interesting point. While we often think of software like Microsoft Office as driving Windows adoption, that wasn’t the case in Japan. It turns out that multitasking was the key feature since Office, at the time, wasn’t very friendly to the native language.

So where did the Japanese computers go? The answer for two of them is: nowhere. They just morphed into commodity Windows computers. The 68000 was the exception — it just withered away.

Japanese pocket computers were common at one time and have an interesting backstory. Japanese can be a challenge for input but, of course, hackers are up to the challenge.

It’s not uncommon for a new distro version to come out, and a grudging admission that maybe a faster laptop is on the cards. Perhaps after seeing this project though, you’ll never again complain about that two-generations-ago 64-bit multi-core behemoth, because [Dimitri Grinberg] — who else! — has succeeded in booting an up-to-date Linux on the real most basic of processors. We’re not talking about 386s, ATmegas, or 6502s, instead he’s gone right back to the beginning. The Intel 4004 was the first commercially available microprocessor back in 1971, and now it can run Linux.

So, given the 4004’s very limited architecture and 4-bit bus, how can it perform this impossible feat? As you might expect, the kernel isn’t being compiled to run natively on such ancient hardware. Instead he’s achieved the equally impossible-sounding task of writing a MIPS emulator for the venerable silicon, and paring back the emulated hardware to the extent that it remains capable given the limitations of the 1970s support chips in interfacing to the more recent parts such as RAM for the MIPS, an SD card, and a VFD display. The result is shown in the video below the break, and even though it’s sped up it’s clear that this is not a quick machine by any means.

We’d recommend the article as a good read even if you’ll never put Linux on a 4004, because of its detailed description of the architecture. Meanwhile we’ve had a few 4004 stories over the years, and this one’s not even the first time we’ve seen it emulate something else.

Earlier this year Zilog stopped production of the classic 40-pin DIP Z80 microprocessor, a move that brought a tear to the eye of retro computing enthusiasts everywhere. This chip had a huge influence on both desktop and embedded computing that lingers to this day, but it’s fair to say that the market for it has dwindled. If you have a retrocomputer then, what’s to be done? If you’re [Dean Netherton], you create a processor card for the popular RC2014 retrocomputer backplane, carrying the eZ80, a successor chip that’s still in production.

The eZ80 can be thought of as a Z80 system-on-chip, with microcontroller-style peripherals, RAM, and Flash memory on board. It’s much faster than the original and can address a relatively huge 16MB of memory. For this board, he’s put the chip on a processor daughterboard that plugs into a CPU card with a set of latches to drive the slower RC2014 bus. We can’t help drawing analogies with some of the 16-bit upgrades to 8-bit platforms back in the day, which used similar tactics.

So this won’t save the Z80, but it might well give a new dimension to Z80 hacking. Meanwhile, we’re sure there remain enough of the 40-pin chips out there to keep hackers going for many years to come if you prefer the original. Meanwhile, read our coverage of the end-of-life announcement, even roll your own silicon if you want., or learn about the man who started it all, Federico Faggin.

After previously working out a suitable approach to create a period-correct paper tape reader for his tube-based, MC14500B processor-inspired computer, [David Lovett] over at the Usagi Electric farm is back with a video on how he made a working tape reader.

The tape reader’s purpose is to feed data into the tube-based computer, which for this computer system with its lack of storage memory means that the instructions are fed into the system directly, with the tape also providing the clock signal with a constant row of holes in the tape.

Starting the tape reader build, [David] opted to mill the structural part out of aluminum, which is where a lot of machining relearning takes place. Ultimately he got the parts machined to the paper design specs, with v-grooves for the photodiodes to fit into and a piece to clamp them down. On top of this is placed a part with holes that line up with the photodiodes.

Another alignment piece is added to hold the tape down on the reader while letting light through onto the tape via a slot. After a test assembly [David] was dismayed that due to tolerance issues he cracked two photodiodes within the v-groove clamp, which was a hard lesson with these expensive (and rare) photodiodes.

Although tolerances were somewhat off, [David] is confident that this aluminum machined reader will work once he has it mounted up. Feeding the tape is a problem that is still to be solved.  [David] is looking for ideas and suggestions for a good approach within the limitations that he’s working with. At the video’s end, he mentions learning FreeCAD and 3D printing parts in the future.  That would probably not be period-correct in this situation, but might be something he could get away with for some applications within the retrocomputing space.

We covered the first video and the thought process behind picking small (1.8 mm diameter) photodiodes as a period-correct tape hole sensor for a 1950s-era computing system, like the 1950s Bendix G-15 that [David] is currently restoring.

[Ken] from the YouTube channel What’s Ken Making is back with another MiSTer video detailing the TapTo project and its integration into MiSTer. MiSTer, as some may recall, is a set of FPGA images and a supporting ecosystem for the Terasic DE10-Nano FPGA board, which hosts the very capable Altera Cyclone V FPGA.

The concept behind TapTo is to use NFC cards, stickers, and other such objects to launch games and particular key sequences. This allows an NFC card to be programmed with the required FPGA core and game image. The TapTo service runs on the MiSTer, waiting for NFC events and launching the appropriate actions when it reads a card. [Ken] demonstrates many such usage scenarios, from launching games quickly and easily with a physical ‘game card’ to adding arcade credits and even activating cheat codes.

As [Ken] points out, this opens some exciting possibilities concerning physical interactivity and would be a real bonus for people less able-bodied to access these gaming systems. It was fun to see how the Nintendo Amiibo figures and some neat integration projects like the dummy floppy disk drive could be used.

TapTo is a software project primarily for the MiSTer system, but ports are underway for Windows, the MiSTex, and there’s a working Commodore 64 game loader using the TeensyROM, which supports TapTo. For more information, check out the TapTo project GitHub page.

We’ve covered the MiSTer a few times before, but boy, do we have a lot of NFC hacks. Here’s an NFC ring and a DIY NFC tag, just for starters.

Thanks to [Stephen Walters] for the tip!

For many of us of a particular vintage, the internet blossomed in the ’90s with the invention of the Web and just a few years of development. Back then, we had the convenience of expression on the WWW and the backup of mature services such as IRC for all that other stuff we used to get up to. Some of us still hang out there. Then something happened. Something terrible. Big-commerce took over, and it ballooned into this enormously complex mess with people tracking you every few seconds and constantly trying to bombard you with marketing messages. Enough now. Many people have had enough and have come together to create the Tildeverse, a minimalist community-driven internet experience.

Tilde, literally ‘ ~ ‘, is your home on the internet. You can work on your ideas on a shared server or run your own. Tilde emphasises the retro aesthetic by being minimal and text-orientated. Those unfamiliar with a command line may start getting uncomfortable, but don’t worry—help is at hand. The number of activities is too many to list, but there are a few projects, such as a collaborative Sci-Fi story, a radio station, and even a private VoIP server. Gamers are catered for as long as you like Minecraft, but we think that’s how it should go.

The Tildeverse also supports Gopher and the new Gemini protocol,  giving some people a few more options with which to tinker. The usual method to gain access is to first sign up on a server, then SSH into it; you’re then taken to your little piece of the internet, ready to start your minimalist journey into the Tildeverse.

A couple of videos after the break go into much more detail about the whys and hows of the Tildeverse and are worth a chunk of your time.

We’ve talked about the ‘small web’ before. Here’s our guide to Gemini.

Thanks to [Andrew] for the tip!

IBM got their PCs and PS/2 computers into schools in the 1980s and 1990s. We fondly remember educational games like Super Solvers: Treasure Mountain. However, IBM had been trying to get into the educational market long before the PC. In 1969, the IBM Schools Computer System Unit was developed. Though it never reached commercial release, ten were made, and they were deployed to pilot schools. One remained in use for almost a decade! And now, there’s a new one — well, a replica of IBM’s experimental school computer by [Menadue], at least. You can check it out in the video below.

The internals were based somewhat on the IBM System/360’s technology. Interestingly, it used a touch-sensitive keypad instead of a traditional keyboard. From what we’ve read, it seems this system had a lot of firsts: the first system to use a domestic TV as an output device, the first system to use a cassette deck as a storage medium, and the first purpose-built educational computer. It was developed at IBM Hursley in the UK and used magnetic core memory. It used BCD for numerical display instead of hexadecimal or octal, with floating point numbers as a basic type. It also used 32-bit registers, though they stored BCD digits and not binary. In short, this thing was way ahead of its time.

[Menadue] saw the machine at the IBM Hursley museum and liked it so much that he proceeded to build a prototype machine based partially on a document shown at the museum that showed the instructions. Further research revealed a complete document explaining the instruction set. The initial prototype was made on a small PCB with a Raspberry Pi Pico W, an OLED display, and key switches, which proved that he understood the system enough to replicate it.

After that prototype, work began on the replica. It’s a half-scale model, but it does use a touch keyboard like the original. The attention to detail is nice, with the colours of the case matching and even a small IBM logo replica on the front! It’s made from a metal chassis, with the keyboard surround being plastic (as on the original) so as not to interfere with the touch keyboard. It’s programmed using the same set of instructions as the original — a combination of low-level commands, similar to assembly for microprocessors, but with an extra set of slightly higher-level instructions that IBM called Extra Codes. For a more in-depth explanation, check out the video going over the original system and the prototype replica!

Photos courtesy of IBM Hursley Museum

Many have sought the holy grail of making commercial media both readable and copy-proof, especially once everyone began to copy those floppies. One of these attempts to make floppies copy-proof was Softguard’s Superlok. This in-depth look at this copy protection system by [GloriousCow] comes on the heels of a part 1 that covers Formaster’s Copy-Lock. Interestingly, Sierra switched from Copy-Lock to Superlok for their DOS version of games like King’s Quest, following the industry’s quest in search of this holy grail.

The way that Superlok works is that it loads a (hidden) executable called CPC.COM which proceeds to read the 128 byte key that is stored on a special track 6. With this key the game’s executable is decoded and fun can commence. Without a valid ‘Play’ disk containing the special track and CPC.COM executable all one is instead left with is a request by the game to ‘insert your ORIGINAL disk 1’.

As one can see in the Norton Commander screenshot of a Sierra game disk, the hidden file is easily uncovered in any application that supports showing hidden files. However, CPC.COM couldn’t be executed directly; it needs to be executed from a memory buffer and passed the correct stack parameters. Sierra likely put in very little effort when implementing Softguard’s solution in their products, as Superlok supports changing the encryption key offset and other ways to make life hard for crackers.

Sierra was using version 2.3 of Superlok, but Softguard would also make a version 3.0. This is quite similar to 2.x, but has a gotcha in that it reads across the track index for the outer sector. This requires track wrapping to be implemented. Far from this kind of copy protection cracking being a recent thing, there was a thriving market for products that would circumvent these protections, all the way up to Central Point’s Copy II PC Option Board that would man-in-the-middle between the floppy disk drive and the CPU, intercepting data and render those copy protections pointless.

As for the fate of Softguard, by the end of the 1980s many of its customers were tiring of the cat-and-mouse game between crackers and Softguard, along with issues reported by legitimate users. Customers like Infographics Inc. dropped the Superlok protection by 1987 and by 1992 Softguard was out of business.

Ever been working on a project and get stuck on one of those last little details?  That’s what happened to [Empire of Scrap].  He’s building an Ohio Scientific (OSI) superboard II replica. He wants it to be accurate down to the dates on the chips. It is quite an impressive build.  The problem is the crystal. OSI used large crystals, even by early 1980s standards. The crystal is in a large can with thick pins, like something you’d expect to find in old radio equipment. The problem is that this crystal package isn’t made anymore. 

The crystal had to be exactly 3.932160 MHz, and while [Empire] has a huge collection of vintage crystals, he didn’t have the right one from the 70s. He did, however, have that value in a modern crystal.  

The solution? Hide the new crystal in the can of an older one. The only problem is that crystals are sealed. The bottom appeared to be some sort of plastic or resin.  Gong after it with a side cutter, [Empire] realized it was glass!  Thankfully, none of it got in his eyes, though his hands may have taken a bit of a beating. 

With the old crystal’s shell hollowed out, [Empire] installed the modern device and potted everything in resin. The transplant worked. Now, all that’s left is to fire up the OSI and start hacking. 

Want to build a replica computer but don’t want to hunt down the parts? Check out [Taylor] and [Amy’s] build of this minipet. Regardless of the size of the case, crystals all work in the same way.

[Mike] from Leaded Solder has a soft spot for old computers, and a chance encounter with a friend sent them deep down the deep hole that is the world of 80s and 90s-era Japanese home computers.  Many people playing with these machines have all kinds of issues to deal with, such as rotting cartridges, failing components, and just dirt and mank in critical places. [Mike] decided that working on an MSX-standard custom programmable cartridge would be sensible, but then got stuck on how the MSX cartridge mapping works.

You may recall that the MSX platform is not a single computer but a standard to which many (mainly Japanese) manufacturers designed their products. This disconnected the software writers from the hardware makers and is essentially a mirror of the IBM-PC clone scene.

The MSX is based around the Z80, which has a 16-bit address bus, restricting it to 64K of ROM or RAM. The MSX has two cartridge slots, an ‘internal’ slot for the BIOS and RAM and a fourth for ‘misc’ use. Each of these is mapped internally into the physical address space. The cartridge slots have 64K of addressable space mapped into the Z80 physical space.

If this was not complicated enough, many MSX games and applications exceeded this restriction and added a layer of mapping inside the cartridge using bank switching. A register in the cartridge could change the upper bits of the address allowing ROMs larger than 64K.

[Mike] wanted to replicate the method Konami used for their games. Their first target was The Maze of Galious, which requires a 128K ROM. Their scheme requires additional hardware to map each of the four 16K slots in the cartridge interface to four of the eight 16K slots of the ROM chip. The game selects which bits of the ROM it needs as the game progresses. The implementation uses an old 74LS670, which can still be bought from old stock as a 4×4 bit register file and a two-way dip selector switch. This allowed [Mike] to fit four games into a single SST39SF040 4MBit parallel flash chip. After a few false starts with the details of address bit selection, they were rewarded by Galious booting up without any additional work needed. If you own an MSX-compatible machine and want to build one for yourself, the full KiCAD project is available on the project GitHub page.

The MSX isn’t a well-known platform in the West, and MSX hacks are a rarity here, but in the spirit of retro, here’s a hack to add support for a retro gamepad to the MSX. Also, if you can’t find a period MSX, you can always build one.

Unlike the today’s consumer computer market, the 1980s were the wild west in comparison. There were all kinds of different, incompatible operating systems, hardware, and programs, all competing against one another, and with essentially no networking to tie everything together. Some of these products were incredibly niche as well, only running one program or having a limited use case to keep costs down. Such was the Convergent WorkSlate, a computer that ran only a spreadsheet with any programs also needing to be built into a spreadsheet.

Upon booting the device, the user is presented with a fairly recognizable blank spreadsheet, albeit with a now-dated LCD display (lacking a backlight) and a bespoke keyboard and cursor that wouldn’t have allowed for easy touch typing. The spreadsheet itself is quite usable though, complete with formatting tools and the capability to use formulas like a modern spreadsheet program would. It also hosted a tape deck for audio and data storage, a modem for communicating with other devices, and an optional plotter-style printer. The modem port is how [Old VCR] eventually interfaces with the machine, although as one can imagine is quite a task for a piece of small-batch technology from the 80s like this. After learning how to send and receive information, a small game is programmed into the machine and then a Gopher interface is built to give the device limited Internet connectivity.

The investigation that [Old VCR] goes into on this project to get this obsolete yet unique piece of hardware running and programmed to do other tasks is impressive, and worth taking a look at especially because spreadsheets like this aren’t Turing-complete, leading to a few interesting phenomenon that most of us wouldn’t come across in the modern computing world. Since only around 60,000 units were ever made it’s difficult to come across these machines, but if you want to take a look at the spreadsheet world of the 80s without original hardware you can still run Lotus 1-2-3 natively in Linux today.

Thanks to [Cameron] for the tip!

The 8-bit home computers of yore that we all know and love, without exception as far as we are aware, had an off the shelf microprocessor at heart. In 1983 you were either in the Z80 camp or the 6502 camp, with only a relatively few outliers using processors with other architectures.

But what if you could have both at once, without resorting to a machine such as the Commodore 128 with both on board? How about a machine with retargetable microcode? No, not the DEC Alpha, but the Isetta from [RoelH]— a novel and extremely clever machine based upon 74-series logic, than can not only be a 6502 or a Z80, but can also run both ZX Spectrum games, and Apple 1 BASIC. We would have done anything to own one of these back in 1983.

If retargetable microcode is new to you, imagine the instruction set of a microprocessor. If you take a look at the die you’ll find what is in effect a ROM on board, a look-up table defining what each instruction does. A machine with said capability can change this ROM, and not merely emulate a different instruction set, but be that instruction set. This is the Isetta’s trick, it’s not a machine with a novel RISC architecture like the Gigatron, but a fairy conventional one for the day with the ability to select different microcode ROMs.

It’s a beautifully designed circuit if you’re a lover of 74 logic, and it’s implemented in all surface mount on a surprisingly compact PCB. The interfaces are relatively modern too, with VGA and a PS/2 keyboard. The write-up is comprehensive and easy to understand, and we certainly enjoyed digging through it to understand this remarkable machine. We were lucky enough to see an Isetta prototype in the flesh over the summer, and we really hope he thinks about making a product from it, we know a lot of you would be interested.

[GloriousCow] has started working on a series of investigations into the various historical floppy disk copy protection schemes used in the early days of the IBM PC and is here with the first of these results, specifically Formaster’s Copy-Lock.

The game in question is King’s Quest by Sierra Entertainment, which used a ‘booter disk’ with the Copy-Lock protection scheme. Instead of having to boot DOS separately, you could just insert this disk and the game would launch automatically. Early copy protections often used simple methods, like adding sectors with non-standard sizes or tampering with sector CRC values to create disk errors. Copy-Lock employed several such tricks together, making it challenging for standard floppy disk hardware to replicate. In the case of Copy-Lock, Sector 1 on track 6 was intentionally written as only 256 bytes, with a 256-byte blank section to fill the gap. Additionally, the CRC was also altered to add another layer of protection.

When attempting to read the disk, the PC BIOS interrupt routine assumes it’s looking for a standard 512-byte sector, so when a “read sector” command is issued to locate the sector, it never finds it. To detect a dodgy copy, the game bypasses the BIOS and talks directly to the floppy disk controller using some custom code. The first part of the code uses the standard INT 13h routine to seek to track 6, sector 1, where it expects a fail since there is no valid sector there. Next, the floppy controller sends the “read track” command to perform a raw dump of all 512 bytes at this address and looks for a magic number, 0xF7, sitting in the final byte. That empty second half of the short sector is indeed not empty and is the check the game makes to determine if it was written with the Copy-Lock capable hardware. That last point is pertinent; you can’t create this disk structure with a standard IBM PC floppy disk controller; you need specialised hardware that can write different-sized sectors and incorrect CRCs, and that costs money to acquire.

We recently covered the copy protection scheme used for Dungeon Master on the Atari ST and the Amiga. If you’re thinking less about how a floppy got cracked and copied and more about how to preserve these digital relics, check this out!

When we think of programmable hardware, we think of FPGAs. But they’re not the only option. [Oliver Schmidt] has been exploring how the Raspberry Pi Pico can serve in such a role for the classic Apple II. The talk was presented at the KansasFest event this year, and it’s well worth diving into!

[Oliver] has developed A2Pico. It’s a series of Apple II peripheral cards that are based around the Raspberry Pi Pico, as you might have guessed. [Oliver] has been working in the area since 2021 with one [Glenn Jones], with the duo experimenting with connecting the versatile microcontroller directly to the slot bus of the Apple II. [Ralle Palaveev] then chimed in, developing the A2Pico hardware with solely through-hole components for ease of assembly.

A number of cards have been developed based on A2Pico, including a storage device, a Z80 CP/M card, and a specialized card to play Bad Apple on the IIGS. It’s all thanks to the versatility of the programmable I/O (PIO) peripheral inside the Raspberry Pi Pico. This device enables the Pico to be reprogrammed to handle all sorts of complicated tasks at great speed. This is particularly useful when using it to bit-bang a protocol or talk with another machine, and it serves perfectly well in this role. Basically, by reprogramming the Pico and its PIO, the A2Pico design can become any one of a number of different add-on cards.

It’s well worth diving into this stuff if you’ve ever contemplated building your own peripheral cards for 8-bit and 16-bit machines. We’ve seen some other great add-on cards for vintage machines before, too.