Among the rows of digital dinosaurs, one blinking front panel stood out. It certainly looked the part of a retro computer; with banks of blinking LEDs and multicolored paddle switches. But upon closer inspection, the laser cut wooden front panel betrays the fact that this machine is an impostor. It may have the appearance of a machine from the heady days where home computers looked like they could have doubled as a prop on the bridge of Kirk’s Enterprise, but it’s actually a product of much more modern provenance.
It’s called the Cactus, a love letter to the homebrew microcomputers of the 1970’s, designed and built by somebody at least 20 years too young to have experienced them the first time around. Alexander Pierson created the Cactus not because he had fond memories of putting together an Altair 8800 in 1975, but because he’s fascinated with the retro computer experience: the look of the front panel, the satisfying clunk of era-appropriate switches, and the idea that the computer’s inner workings aren’t an abstract black box but rather something you can interact with and study. Judging by all the attention the Cactus got at VCF East XIII, he’s not the only one.
Let’s take a look at everything Alexander poured into this retrocomputer build.
The 6502 has a long history with hackers. The Apple computer (the one with no keyboard or even case) had a 6502. So did the Kim-1. [Dolo’s] version is a bit more refined, though. He started it a few years ago in response to one of our contests, but he’s been making improvements to it ever since. In particular, the custom programming language, Dflat, has many improvements lately, including true functions and high-resolution drawing.
The hardware has a CPU running at over 2.5 MHz, 44K of RAM, 16K of PROM, and 16K of video RAM. There’s plenty of I/O, including a keyboard, sound, and joysticks. An SD card provides mass storage and it all goes in a hacked BBC Micro case. You can see an overview video, below.
Our better-traveled colleagues having provided ample coverage of the 34C3 event in Leipzig just after Christmas, it is left to the rest of us to pick over the carcass as though it was the last remnant of a once-magnificent Christmas turkey. There are plenty of talks to sit and watch online, and of course the odd gem that passed the others by.
It probably doesn’t get much worse than nuclear conflagration, when it comes to risks facing the planet. Countries nervously peering at each other, each jealously guarding their stocks of warheads. It seems an unlikely place to find a 34C3 talk about 6502 microprocessors, but that’s what [Moritz Kütt] and [Alex Glaser] managed to deliver.
Policing any peace treaty is a tricky business, and one involving nuclear disarmament is especially so. There is a problem of trust, with so much at stake no party is anxious to reveal all but the most basic information about their arsenals and neither do they trust verification instruments manufactured by a state agency from another player. Thus the instruments used by the inspectors are unable to harvest too much information on what they are inspecting and can only store something analogous to a hash of the data they do acquire, and they must be of a design open enough to be verified. This last point becomes especially difficult when the hardware in question is a modern high-performance microprocessor board, an object of such complexity could easily have been compromised by a nuclear player attempting to game the system.
We are taken through the design of a nuclear weapon verification instrument in detail, with some examples and the design problems they highlight. Something as innocuous as an ATtiny microcontroller seeing to the timing of an analogue board takes on a sinister possibility, as it becomes evident that with compromised code it could store unauthorised information or try to fool the inspectors. They show us their first model of detector using a Red Pitaya FPGA board, but make the point that this has a level of complexity that makes it unverifiable.
Then comes the radical idea, if the technology used in this field is too complex for its integrity to be verified, what technology exists at a level that can be verified? Their answer brings us to the 6502, a processor in continuous production for over 40 years and whose internal structures are so well understood as to be de facto in the public domain. In particular they settle upon the Apple II home computer as a 6502 platform, because of its ready availability and the expandability of [Steve Wozniak]’s original design. All parties can both source and inspect the instruments involved.
If you’ve never examined a nuclear warhead verification device, the details of the system are fascinating. We’re shown the scintillation detector for measuring the energies present in the incident radiation, and the custom Apple II ADC board which uses only op-amps, an Analog Devices flash ADC chip, and easily verifiable 74-series logic. It’s not intentional but pleasing from a retro computing perspective that everything except perhaps the blue LED indicator could well have been bought for an Apple II peripheral back in the 1980s. They then wrap up the talk with an examination of ways a genuine 6502 system could be made verifiable through non-destructive means.
It is not likely that nuclear inspectors will turn up to the silos with an Apple II in hand, but this does show a solution to some of the problems facing them in their work and might provide pointers towards future instruments. You can read more about their work on their web site.
The Apple 1 was one of the three big hobbyist computers that burst onto the scene in 1977. Unlike the PET 2001 and the TRS-80, only a couple hundred Apple 1s were ever produced, and with only a handful in existence today, you’ll have to fork out some serious money to get a Wozniak original for yourself.
The Apple 1 experience is easily emulated, of course, but this ESP8266 emulates the Apple 1 on hard mode. Dubbed the Espple by its creator [Hrvoje Cavrak], it emulates the 6502-based original in all its 1-MHz glory, while providing 20-kB of RAM, a considerable upgrade over the 4-kB standard. The complete original character set is provided for that old-timey feel, and there’s a BASIC interpreter ready to go. The kicker here, though, is that the emulator is completely wireless. You telnet into the 8266 rather than connecting a keyboard directly, and video is transmitted over-the-air using a GPIO pin as a 60-MHz PAL transmitter. A short length of wire is all you need to transmit to an analog PAL TV on channel 4; the video below shows a little BASIC code running and a low-res version of Woz himself.
The Before Times were full of fancy logic analyzers. Connect the leads on these analyzers to a system, find that super special ROM cartridge, and you could look at the bus of a computer system in real time. We’ve come a long way since then. Now we have fast, cheap bits of hardware that can look at multiple inputs simultaneously, and there are Open Source solutions for displaying and interpreting the ones and zeros on a data bus. [hoglet] has built a very clever 6502 protocol decoder using Sigrok and a cheap 16-channel logic analyzer.
This protocol decoder is capable of looking at the ones and zeros on the data bus of a 6502-based computer. Right now, [hoglet] able to stream two million 6502 cycles directly to memory, so he’s able to capture the entire startup sequence of a BBC Micro. The hardware for this build was at first an Open Bench Logic Sniffer on a Papilio One FPGA board. This hardware was changed to an impressively inexpensive Cypress FX2 development board that was reconfigured to a 16 channel logic analyzer.
The software stack is where this really shines, and here [hoglet] documented most of the build over on the stardot forums. The basic capture is done with Sigrok, the Open Source signal analysis toolchain. This project goes a bit further than simply logging ones and zeros to a file. [hoglet] designed an entire 6502 protocol decoder with Python. Here’s something fantastic: this was [hoglet]’s first major Python project.
To capture the ones and zeros coming out of a 6502, the only connections are the eight pins on the data bus, RnW, Sync, Rdy, and Phy2. That’s only twelve pins, and no connections to the address bus, but the protocol decoder quickly starts to predict what the current program counter should be. This is a really fantastic piece of work, enabling an entire stack trace on any 6502 computer for less than $20 in parts.
If you were a home constructor in the 8-bit era, the chances are that if you built a microcomputer system you would have ended up with a bare printed circuit board and a terminal. If you were on a budget you might have had a piece of stripboard as well, or maybe even wire-wrap. Beautiful cases were out of reach, they came with expensive commercial computers that were not the preserve of impoverished hobbyists.
Constructing an 8-bit machine in 2017 is a much easier process, there are many more options at your disposal. There is no need to make a bare PCB when you have a 3D printer, and this is demonstrated perfectly by [Dirk Grappendorf]’s 6502 computer project. He’s built from scratch an entire 6502 system, with a text LCD display, and housed it in a case with a keyboard that would put to shame all but the most expensive commercial machines from back in the day.
But this is more than just a hobby project thrown together that just happens to have a nice case, he’s gone the extra mile to the extent that this is professional enough that it could have been a product. If you’d been offered [Dirk]’s machine in 1980 alongside the competitors from Apple and Commodore, you’d certainly have given it some consideration.
We’ve seen retrocomputers too numerous to mention on these pages over the years, so if they are your thing perhaps it’s time to draw your attention to our VCF West reports, and to our reviews of computer museums in Germany, and Cambridge or Bletchley, UK.
In what may be the strangest retrocomputing project we’ve seen lately, you can now access a virtual 6502 via Amazon’s Lambda computing service. We don’t mean there’s a web page with a simulated CPU on it. That’s old hat. This is a web service that takes a block of memory, executes 6502 code that it finds in it, and then returns a block of memory after a BRK opcode or a time out.
You format your request as a JSON-formatted POST request, so anything that can do an HTTP post can probably access it. If you aren’t feeling like writing your own client, the main page has a form you can fill out with some sample values. Just be aware that the memory going in and out is base 64 encoded, so you aren’t going to see instantly gratifying results.