Some electronics gear is built for the roughest conditions. With rugged steel cases, weatherproof gaskets, and cables passing through sealed glands, these machines are built to take the worst that Mother Nature can throw at them, shrugging off dust, mud, rain, and ice. Consumer-grade computers from the start of the home PC era, however, are decidedly not such machines.
Built to a price point and liable to succumb to a spilled Mountain Dew, few machines from that era that received any kind of abuse lived to tell the tale. Not so this plucky Commodore 64C, which survived decades exposed to the elements. As [Adrian Black] relates in the video below, this machine was on a scrap heap in an Oregon field, piled there along with other goodies by one of those “pickers” that reality TV loves so much. The machine was a disaster. It hadn’t been soaked in oil, but it was loaded with pine needles and an ant colony. The worst part, though, was the rust. The RF shielding had corroded into powder in some places, leaving reddish rust stains all over the place. Undeterred, [Adrian] gave the machine a good bath, first in water, then in isopropanol. Liberal applications of Deoxit helped with header connections, enough to see that the machine miraculously booted. It took some finagling, especially with the 6526 I/O controller, but [Adrian] was eventually able to get everything on the motherboard working, even the sound chip.
Whether this machine survived due to good engineering or good luck is debatable, but it’s a treat to see it come back to life. We hope a full restoration is in the works, not least as a way to make up for the decades of neglect.
Falling into the marvelous space between, ‘I really want to do that’ and ‘but that’s a lot of work and I’m lazy’ comes this reproduction of the motherboard from the original IBM 5150. This is a complete reproduction of the first PC, being sold as a kit. Yes, chips are included, although I highly doubt they’ve gone through the trouble of finding chips with contemporaneous date codes. We’re dying for a writeup on this one.
Someone has found the source code for the first Furby. [Mark Boldyrev] was talking with a few fellows on the MAME forum to see if anyone had the source for the Furby. He was looking into contacting the USPTO for the original source but the red tape involed was a bit too intense. Luckily, that research turned up some info from [Sean Riddle] who somehow already found the original source listing. After [Mark] got in contact, [Sean] posted it as a PDF. Yes, it’s 6502 source, although the microcontroller is technically a SPC81A, with the rest of the hardware consisting of TI50C04 speech chip. (you would not believe how many toys are still shipping with a 6502-ish core somewhere inside). The files are up in the archive, and we’re probably going to have a Furby MAME sometime soon.
The Bitfi hardware wallet is a cryptocurrency storage device being bandied about by [John McAffee], and there’s a quarter million dollar bug bounty on it. It’s ‘unhackable’, and ‘it has no memory’. I’m serious, those are direct quotes from [McAffee]. Both of those claims are nonsense and now it can play Doom.
Oh noes, a new hardware backdoor in x86 CPUs! [xoreaxeaxeax] has published a demo that allows userland code to read and write kernel data (that’s very bad). The exploit comes in the form of the ‘rosenbridge backdoor’, a small embedded processor tightly coupled to the CPU that is similar to, but entirely different from, Intel’s ME. This processor has access to all the CPU’s memory, registers, and pipeline. The good news, and why this isn’t big news, is that this exploit only affects Via C3 CPUs. Yes, the other company besides Intel and AMD that makes x86 CPUs. These are commonly found in industrial equipment and ATMs.
When you think about vintage computers from the 1970s, the first thing that should spring to mind are front panels loaded up with switches, LEDs, and if you’re really lucky, a lock with a key. Across all families of CPUs from the ’70s, you’ll find front panel setups for Z80s and 8080s, but strangely not the 6502. That’s not to say blinkenlights and panel switches for 6502-based computers didn’t exist, but they were astonishingly rare.
If something hasn’t been done, that means someone has to do it. [Alexander Pierson] built The Cactus, a 6502-based computer that can be controlled entirely through toggle switches and LEDs.
If you’re wondering why something like this hasn’t been built before, you only have to look at the circuitry of the 6502 CPU. The first versions of this chip were built with an NMOS process, and these first chips included bugs, undefined behavior, and could not be run with a stopped clock signal. These problems were fixed with the next chip spin using a CMOS process (which introduced new bugs), but the CMOS version of the 6502 would retain the contents of its registers with a stopped clock signal.
The specs for the Cactus computer are what you would expect from a homebrew 6502 system. The chip is a WDC 65C02S running at 1MHz, there’s 32k of RAM and a 16k EPROM, dual 6551s give serial access at various baud rates, and there are 16 bits of parallel I/O from a 65C22 VIA. The ROM is loaded up with OSI Basic. The real trick here is the front panel, though. Sixteen toggle switches allow the front panel operator to toggle through the entire address space, and eight flip switches can set any bit in the computer. Other controls include Run, Halt, Step, Examine, and Deposit, as you would expect with any front panel computer.
It’s a fantastic piece of work which I missed seeing at VCF East so I’m really glad [Alexander] made the trip between coasts. Cactus is truly something that hasn’t been done before. Not because it’s impossible, but simply because the state of the art technology from when the 6502 was new didn’t allow it. Now we have the chips, and the only limitation is finding someone willing to put in the work.
Just this summer, the Nintendo Entertainment System had its 35th release anniversary, and even after years of discontinuation, it is still going strong in the hacker community. Exhibit A: [Matthew Earl]. For one of his upcoming projects, [Matthew] needed to get his hands on the background images of the NES classic Super Mario Bros. Instead of just getting some ready-rendered images and stitching them together, he decided to take care of the rendering himself, once he extracts the raw game data.
Since there is no official source code available for Super Mario Bros, [Matthew] used a disassembled version to get started looking for the image data. To avoid reading through thousands of lines of assembly code, and to also see what actually happens during execution, he wrapped the game’s ROM data into py65emu, a Python library emulating the 6502, the CPU that drives the NES. By adding a simple wrapper around the emulator’s memory handler that tracks reads on uninitialized data, [Matthew] managed to find out which parameters he needs to feed to the parser routine in order to get the image tile data. After an excursion into the Picture Processing Unit (PPU) and its memory arrangements, [Matthew] had everything he needed to create the Python script that will render the game background straight from its ROM data.
Even if extracting NES game data is not your thing, the emulator concept [Matthew] uses might be still worth a read. On the other hand, if you want to dig deeper into the NES, you should definitely have a look at emulating an SNES game on a NES, presented on the NES itself.
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.
By using our website and services, you expressly agree to the placement of our performance, functionality and advertising cookies. Learn more