For many of us, being given a big old DIP ROM from nearly thirty years ago and being told to retrieve its contents would be a straightforward enough task. We’d simply do what we would have done in the 1980s, and hook up its address lines to a set of ports, pull its chip select line high, and harvest what came out of the data lines for each address.
But imagine for a minute that an old-fashioned parallel ROM is a component you aren’t familiar with, as [Brad Dettmer] did with the ROM from a SNES Zelda cartridge. We’ve seen plenty of reverse engineering stories with ancient computing gear as their subject, but perhaps it’s time to accept that some of the formerly ubiquitous devices are edging towards that sort of status.
So [Brad] takes us through the process of using the Saleae logic analyser to interrogate the chip while an Arduino stepped through its address lines, and the lesson is probably that while it seems like a sledgehammer to crack a nut it is important to factor in that unfamilarity. If you’d never worked with a 1980s ROM, it would make sense to use the tool you are familiar with, wouldn’t it?
There’s something powerful about reliving the experience of using a game console from our personal good old days, especially the tactile memories stored up from hundreds of hours handling a chintzy joystick or the sound and feel of inserting a game cartridge. Emulators have their place, but they fall far short of period-correct hardware in the nostalgia department.
That’s not to say that the retro gear can’t use a little help in terms of usability, which is why [Scott M. Baker] built this Raspberry Pi multi-cartridge for his Atari 5200. The idea is to maintain the experience of the cartridge interface without having to keep stacks of cartridges around for all the games he wants to play. [Scott] leveraged the approach he used when he built a virtual floppy drive for a homebrew PC/XT: dual-port memory. The IDT7007 is a 32k chip that lives between the Atari 5200 and a Raspberry Pi Zero and can be addressed by both systems; the Pi to write ROM images to the memory, and the console to read them. He had to deal with some fussy details like chip select logic and dealing with the cartridge interlock signals, not to mention the difference in voltage between the memory chip’s logic levels and that of the Pi. Retro game-play occupies the first part of the video below; skip to 6:45 for build details.
The one quibble we have is trying to jam everything into an old cartridge. It’s critical to replicating the tactile experience, and while we don’t think we’d have gone so far as to injection mold a custom cartridge to house everything without any protrusions, we might have 3D-printed a custom cartridge instead. In the end it doesn’t detract much from the finished project, though, and we appreciate the mix of old and new tech.
There are many ways of storing data in a computer’s memory, and not all of them allow the computer to write to it. For older equipment, this was often a physical limitation to the hardware itself. It’s easier and cheaper for some memory to be read-only, but if you go back really far you reach a time before even ROMs were widespread. One fascinating memory scheme is this example using a vacuum tube that stores the characters needed for a display.
[eric] over at TubeTime recently came across a Raytheon monoscope from days of yore and started figuring out how it works. The device is essentially a character display in an oscilloscope-like CRT package, but the way that it displays the characters is an interesting walk through history. The monoscope has two circuits, one which selects the character and the other determines the position on the screen. Each circuit is fed a delightfully analog sine wave, which allows the device to create essentially a scanning pattern on the screen for refreshing the display.
[eric] goes into a lot of detail on how this c.1967 device works, and it’s interesting to see how engineers were able to get working memory with their relatively limited toolset. One of the nice things about working in the analog world, though, is that it’s relatively easy to figure out how things work and start using them for all kinds of other purposes, like old analog UHF TV tuners.
We don’t know about you, but when our friends ask us if we want to help them fix something, they’re usually talking about their computer, phone, or car. So far it’s never been about helping them rebuild an old electron microscope. But that’s exactly the request [Benjamin Blundell] got when a friend from a local hackerspace asked if he could take a look at a vintage Cambridge Stereoscan 200 they had found abandoned in a shed. Clearly we’re hanging out with the wrong group of people.
As you might imagine, the microscope was in desperate need of some love after spending time in considerably less than ideal conditions. While some of the hackerspace members started tackling the hardware side of the machine, [Benjamin] was tasked with finding a way to recover the contents of the scope’s ROM. While he’s still working on verification, the dumps he’s made so far of the various ROMs living inside the Stereoscan 200 have been promising and he believes he’s on the right track.
The microscope uses a mix of Texas Instruments 25L32 and 2516 chips, which [Benjamin] had to carefully pry out after making sure to document everything so he knew what went where. A few of the chips weren’t keen on being pulled from their home of 30-odd years, so there were a few broken pins, but on the whole the operation was a success.
Each chip was placed in a breadboard and wired up to an Arduino Mega, as it has enough digital pins to connect without needing a shift register. With the wiring fairly straightforward, [Benjamin] just needed to write up some code to read the contents of the chip, which he has graciously provided anyone else who might be working on a similar project. At this point he hasn’t found anything identifiable in his ROM dumps to prove that they’ve been made successfully, all he really knows right now is that he has something. At least it’s a start.
Polyglots, in computing terms, are files have multiple valid meanings. We’ve seen some amazing examples of polyglot files in releases of The International Journal of PoC||GTFO. One example: a PDF that is also a ZIP, HTML file, and BPG image.
[Vi Grey] was inspired by PoC||GTFO’s release of a PDF/ZIP/NES ROM hybrid file for issue 0x14. Using a different method, [Vi] created a file which is both an NES ROM and ZIP, where the full contents of the ZIP are stored in the NES ROM.
When PoC||GTFO created their NES ROM polyglot, they stuck most the information outside the bounds of the NES ROM. While the file is valid, you’d lose the ZIP archive if it was burnt to a cartridge.
[Vi]’s polyglot is different. Rip it from a real NES cartridge and you get a ZIP file. Unzip it, and you get the source. Compile that source, and you get a valid ZIP file containing the source. Burn that to a cartridge and… hopefully you grok the recursion at this point.
The source and scripts to mangle the polyglot together are up on Github.
The Casio SK-1 keyboard is fairly well-known in the “circuit bending” scene, where its simple internals lend themselves to modifications and tweaks to adjust the device’s output in all sorts of interesting ways. But creating music via circuit bending the SK-1 can be tedious, as it boils down to fiddling with the internals blindly until it sounds cool. [Nick Price] wanted to do something a bit more scientific, and decided to try replacing his SK-1’s ROM with an Arduino so he could take complete control it.
That’s the idea, anyway. Right now he’s gotten as far as dumping the ROM and getting the Arduino hooked up in place of it. Unfortunately the resulting sound conjures up mental images of a 56K modem being cooked in a microwave. Clearly [Nick] still has some work ahead of him.
For now though, the progress is fascinating enough. He was able to pull the original NEC 23C256 chip out of the keyboard and read its contents using an Arduino and some code he cooked up, and he’s even put the dump online for any other SK-1 hackers out there. He then wrote some new code for the Arduino to spit data from the ROM dump back to the keyboard when requested. In theory, it should sound the same as before, but with the added ability to “forge” the data going back to the keyboard to make new sounds.
The result is what you hear in the video linked after the break. Not exactly what [Nick] had in mind. After some snooping with the logic analyzer, he believes the issue is that the Arduino can’t respond as fast as the original NEC chip did. He’s now got an NVRAM chip on order to replace the original NEC chip; the idea is that he can still use the Arduino to reprogram the NVRAM chip when he wants to play around with the sound.
There is a huge variety of hardware out there with a font of some form or other baked into the ROM. If it’s got a display it needs a font, and invariably that font is stored as a raster. Finding these fonts is trivial – dump the ROM, render it as a bitmap, and voilà – there’s your font. However, what if you’re trying to dump the font from a vintage Apple 410 Color Plotter? It’s stored in a vector format, and your job just got a whole lot harder.
The problem with a vector font is that the letters aren’t stored as individual images, but as a series of instructions that, when parsed correctly, draw the character. This has many benefits for generating characters in all manner of different sizes, but makes the font itself much harder to find in a ROM dump. You’re looking for both the instructions that generate the characters, as well as the code used to draw them, if you want a full representation of the font.
The project begins by looking at what’s known about the plotter. The first part of any such job is always knowing where to look, of course. It’s quickly determined that the font is definitely stored in the main ROM, and that there is no other special vector drawing chip or ROMs on board. The article then steps through the search process, beginning with plaintext searches of the binary dump, before progressing to a full disassembly of the plotter firmware. After testing out various assumptions and working methodically, the vector data is found and eventually converted into a modern TrueType font.