Hackaday Links: August 12, 2018

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.

VCF West: Adding A Front Panel To The 6502

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.

Find Your Level – Extracting NES Game Data Using Python

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.

VCF East: Cactus, Retro Because it Wants to Be

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.

Continue reading “VCF East: Cactus, Retro Because it Wants to Be”

A 6502 with a Custom Language

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.

Continue reading “A 6502 with a Custom Language”

34C3: Vintage Verification, Stop Nuclear War With A 6502

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.

The gamma ray energy spectrum of a cobalt-60 source as seen from an Apple II.
The gamma ray energy spectrum of a cobalt-60 source as seen from an Apple II.

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.

Espple: A Wireless Apple 1 on an ESP8266

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.

You’ll find Apple emulators aplenty around these parts, everything from an Apple ][ on an Arduino Uno to a tiny Mac on an ESP32. There hasn’t been much in the way of Apple 1 emulations, though, at least until now.

Continue reading “Espple: A Wireless Apple 1 on an ESP8266”