The Macintosh Classic – a small all-in-one computer with a 9″ monochrome screen – was one of the more interesting machines ever released by Apple. It was the company’s first venture into a cost-reduced computer, and the first Macintosh to sell for less than $1000. Released in 1990, its list of features were nearly identical to the Macintosh Plus, released four years earlier. The Classic also had an interesting feature not found in any other Mac. It could boot a full OS, in this case System 6.0.3, by holding down a series of keys during boot. This made it an exceptional diskless workstation. It was cheap, and all you really needed was a word processor or spreadsheet program on a 1.44 MB floppy to do real work.
[Steve] over at Big Mess O’ Wires had the same idea as the Apple engineers back in the late 80s. Take a Macintosh Plus, give it a bit more ROM, and put an OS in there. [Steve] is going a bit farther than those Apple engineers could have dreamed. He’s built a rewritable ROM disk for the Mac Plus, turning this ancient computer into a completely configurable diskless workstation.
The build replaces the two stock ROM chips with an adapter board filled with 29F040B Flash chips. They’re exactly what you would expect – huge, old PDIPs loaded up with Flash instead of the slightly more difficult to reprogram EEPROM. Because of the additional space, two additional wires needed to connected to the CPU. The result is a full Megabyte of Flash available to the Macintosh at boot, in a computer where the normal removable disk drive capacity was only 800kB.
The hardware adapter for stuffing these flash chips inside a Mac Plus was made by [Rob Braun], while the software part of this build came from [Rob] and [Doug Brown]. They studied how the Macintosh Classic’s ROM disk driver worked, and [Rob Braun] developed a stand-alone ROM disk driver with a new pirate-themed startup icon. [Steve] then dug in and created an old-school Mac app in Metrowerks Codewarrior to write new values to the ROM. Anything from Shufflepuck to Glider, to a copy of System 7.1 can be placed on this ROM disk.
This isn’t the first time we’ve seen ROM boot disks for old Macs. There was a lot of spare address space floating around in the old Mac II-series computers, and [Doug Brown] found a good use for it. Some of these old computers had optional ROM SIMM. You can put up to 8 Megabytes in the address space reserved for the ROM, and using a similar ROM disk driver, [Doug] can put an entire system in ROM, or make the startup chime exceptionally long.
[nitro2k01] got his hands on a Game Fighter, a clone of the original Game Boy. While there’s a ton of information about the boot ROM and operation of the original Game Boy, not much is known about these clones. [nitro2k01] wanted to learn more, so he used a clock-glitching technique to dump the device’s ROM and made some interesting discoveries about its copyright protection and boot process along the way.
Reading the contents of the Game Boy ROM is a bit challenging. The ROM is readable while booting, but afterwards the address space of the ROM is remapped for interrupt vectors and other uses. There are a couple of methods to get around this, but the simplest method involves glitching the crystal by grounding one of its leads. This causes the CPU to jump to random locations in memory. Eventually the CPU will jump to a location where the boot ROM is accessible (if you’re lucky!).
Although [nitro2k01]’s clone can run the same games as the Game Boy, it has a different boot ROM and also has some significant hardware differences. [nitro2k01] managed to use a modified version of the crystal-grounding technique to glitch his clock and dump the clone’s boot ROM. He found that the clone uses an unusual variation on the Game Boy’s copyright-checking technique, along with some other oddities. [nitro2k01] also posted a disassembly of the boot ROM, which he explains in detail.
Thanks for the tip, [Ove].
Once upon a time, arcades were all the rage. You could head down to your local arcade with a pocket full of quarters and try many different games. These days, video arcades are less popular. As a result, many old arcade games are becoming increasingly difficult to find. They are almost like the artifacts of an ancient age. They are slowly left to rot and are often lost or forgotten with time. Enter, MAME.
MAME (Multiple Arcade Machine Emulator) is a software project, the goal of which is to protect gaming history by preventing these arcade machines from being lost or forgotten. The MAME emulator currently supports over 7000 titles, but there are still more out there that require preservation. The hackers who work on preserving these games are like the digital Indiana Jones of the world. They learn about lost games and seek them out for preservation. In some cases, they must circumvent security measures in order to accurately preserve content. Nothing as scary as giant rolling boulders or poison darts, but security nonetheless.
Many of the arcade cabinets produced by a publisher called NMK used a particular sound processor labeled, “NMK004”. This chip contains both a protected internal code ROM and an unprotected external ROM that controls the sound hardware. The actual music data is stored on a separate unprotected EEPROM and is different for each game. The system reads the music data from the EEPROM and then processes it using the secret data inside the NMK004.
The security in place around the internal ROM has prevented hackers from dumping its contents for all this time. The result is that NMK games using this chip have poorly emulated sound when played using MAME, since no one knows exactly how the original chip processed audio. [trap15] found it ridiculous that after 20 years, no one had attempted to circumvent the security and dump the ROM. He took matters into his own hands.
The full story is a bit long and contains several twists and turns, but its well worth the read. The condensed version is that after a lot of trial and error and after writing many custom tools, [trap15] was able to finally dump the ROM. He was able to accomplish this using a very clever trick, speculated by others but never before attempted on this hardware. [trap15] exploited a vulnerability found in the unprotected external ROM in order to trick the system into playing back the protected internal ROM as though it were the sound data stored on the EEPROM. The system would read through the internal ROM as though it were a song and play it out through the speakers. [trap15] recorded the resulting audio back into his PC as a WAV file. He then had to write a custom tool to decode the WAV file back into usable data.
[trap15] has released all of his tools with documentation so other hackers can use them for their own adventures into hardware hacking. The project was a long time in the making and it’s a great example of reverse engineering and perseverance.
While [Rob] was digging around in his garage one day, he ran across an old Commodore 64 cartridge. With no ROM to be found online, he started wondering what was stored in this ancient device. Taking a peek at the bits stored in this cartridge would require dumping the entire thing to a modern computer, and armed with an Arduino, he created a simple cart dumper, capable of reading standard 8k cartridges without issue.
The expansion port for the C64 has a lot of pins corresponding to the control logic inside these old computers, but the only ones [Rob] were really interested in were the eight data lines and the sixteen address lines. With a little bit of code, [Rob] got an Arduino Mega to step through all the address pins and read the corresponding data at that location in memory. This data is then sent over USB to a C app that dumps everything in HEX and text.
While the ROM for just about every C64 game can be found online, [Rob] was unlucky enough to find one that wasn’t. It doesn’t really matter, though, as we don’t know if [Rob] has the 1541 disk drive that makes this cart useful. Still, it’s a good reminder of how useful an Arduino can be when used as an electronic swiss army knife.
Diode matrices were one of the first methods of implementing some sort of read only memory for the very first electronic computers, and even today they can be found buried deep in the IPs of ASICs and other devices that need some form of write-once memory. For the longest time, [Rick] has wanted to build a ROM out of a few hundred diodes, and he’s finally accomplished his goal. Even better, his diode matrix circuit is actually functional: it’s a 64-byte ROM for an Atari 2600 containing an extremely simple demo program.
[Rick] connected a ton of 1N60 diodes along a grid, corresponding to the data and address lines to the 2600’s CPU. At each intersection, the data lines were either unconnected, or tied together with a diode. Pulling an address line high or low ([Rick] hasn’t posted a schematic) pulls the data line to the same voltage if a diode is connected. Repeat this eight times for each byte, and you have possibly the most primitive form of read only memory.
As for the demo [Rick] coded up with diodes? It displays a rainbow of colors with a black rectangle that can be moved across the screen with the joystick. Video below.
Continue reading “Homebrew Programming With Diodes”
The Bus Pirate is a cheap, simple, Swiss army knife of electronic prototyping, capable of programming FPGAs, and writing to Flash memory. The uISP is possibly the most minimal way of programming Atmel chips over USB, using less than $5 in components. Although the uISP is using a slower chip and bit-banging the USB protocol, it turns out it’s actually faster when operating as a programmer for SPI Flash memories.
Most of [Necromancer]’s work involves flashing routers and the like, and he found the Bus Pirate was far too slow for his liking – he was spending the better part of four minutes to write a 2 MiB SPI Flash. Figuring he couldn’t do much worse, he wrote two firmwares for the uISP to put some data on a Flash chip, one a serial programmer, the other a much more optimized version.
Although the ATMega in the uISP is running at about half the speed as the PIC in the Bus Pirate, [Necromancer] found the optimized firmware takes nearly half the time to write to an 8 MiB Flash chip than the Bus Pirate.
It’s an impressive accomplishment, considering the Bus Pirate has a dedicated USB to serial chip, the uISP is bitbanging its USB connection, and the BP is running with a much faster clock. [Necro] thinks the problem with the Bus Pirate is the fact the bandwidth is capped to 115200 bps, or a maximum throughput of 14 kiB/s. Getting rid of this handicap and optimizing the delay loop makes the cheaper device faster.
[Pong] has joined an elite club of people who have designed and built their own computer – including a CPU created from discrete 7400 series logic. His computer is the Almost Simple As Possible Computer 3 (ASAP-3). ASAP-3 is not a completely new design. The architecture is based upon the SAP series of computers from Albert Malvino’s book, Digital Computer Electronics. [Pong] looked at quite a few of the “modern retro” computers such as Magic-1, Big Mess o’ Wires 1, and the Duo. These computers were beyond his skill levels back then, so he began to build his own system. His primary design goal was to be able to run a 4 function calculator program.
One thing that can’t be stressed enough is the fact that [Pong] made his design work much easier by using lots of simulation. His tool of choice was Proteus Design Suite. While simulation can’t solve every problem, it can often help in verifying that a given design is sound. The ASAP-3’s instruction set is microcode, based upon the 8085 series instruction set. The microcode itself is stored on Flash ROMS. Using microcode makes ASAP-3 very flexible. Don’t have a machine instruction you need? No problem – just write one up. When all was said and done, [Pong] had over 100 instructions spread over 3 Flash ROM chips.
The hardware was only half the battle – [Pong] found writing the software just as challenging. He wrote all the software by hand in his own machine code. This is where the simulation mentioned above really saved him some time. Even with simulation he still ran into some problems. The ASAP-1 is limited to a clock speed of around 500kHz. Above that, glitches from the ROM chips start triggering the asynchronous inputs in some of the registers. [Pong] doesn’t have a logic analyzer on hand, so he wasn’t able to track this one down further. He also found a (update simulation only) issue with the carry bit on the 74LS181 bit slice ALU. In certain circumstances the carry bit would not propagate correctly. [Pong] corrected this by using a ROM as a look up table replacement for certain ‘181 functions. Even with these limitations, this is still a great hack!
Continue reading “ASAP 3 – The Almost Simple As Possible Computer”