[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”
Here is a nice project that allows youngsters (but also adults!) to actually see the data stored in a Read Only Memory (ROM). The memory shown in the picture above is made of diodes. [Scott] made it as a part of his Barcamp Fall 2013 presentation about visualizing ROMs. He starts his write-up by stating the obvious: this memory is not practical. Nonetheless, it still was a fun exercise to do. [Scott] then greatly described all the different kinds of read only memories that you can find out there, with a few words explaining how they work. In his diode ROM, bits are ‘programmed’ by adding (or not) a diode between a given data line (anode) and an address line (cathode). When pulling low a given address line, the corresponding data line will only be pulled low if a diode is present. [Scott] finally checked his circuit by using a very old device programmer which could only be run in DOS.
We’ve seen marriage proposals via modified Nintendo games before, but most of these put the proposal just after the first level. It’s one thing to have the old man in Zelda present your SO with a ring, but it’s another thing entirely to beat the game before getting on one knee. That’s what [Quinn] forced [Amy] to do when he proposed by modifying the ROM for Contra to display a proposal right before the end credits.
By tearing open a few cartridges, [Quinn] found himself with a bunch of EPROMs and NES cartridge PCBs. After grabbing the Contra ROM off the Internet, [Quinn] edited the game’s end screen to his proposal. This was then burned onto a 1 Megabit EPROM, soldered onto a cartridge, and put into the NES for his now-fiance to play. Once [Amy] and [Quinn] finished the game (without cheating, by the way), [Amy] saw her proposal and [Quinn] pulled out the ring.
This low-resolution memory device packs in just a few bytes of data. But it’s enough to spell out [Michael Kohn’s] name. He’s been experimenting with using paper discs for data storage.
His technique becomes immediately clear when you view the demo video below. The disc spins multiple times with the sensor arm reading one track. This gives the system the chance to measure the black band in order to get the data timing figured out. Once the outer track has been read the servo controlling the read head swings it to the next until all of the data is captured.
An Arduino is monitoring the QTR-1RC reflectance sensor which makes up the reading head. It uses the black band width in order to establish the size of an individual byte. Interestingly enough, the white parts of the disc do not contain data. Digital 0 is a black area 1/4 the width of the large black strip, and digital 1 is half as wide.
[Michael’s] set up the generator which makes the discs so that he can easily increase the resolution. The limiting factor is what the reading hardware is able to detect.
Continue reading “Paper ROM”
Often the true key to success is persistence and that holds true for this project which dumped the ROM from the current generation of Tamagotchi toys. If you’re a fan of learning the secrets built into consumer electronics — and you know we are — you’ll want to go back and watch the 24-minute lecture on Tamagotchi hacking which [Natalie Silvanovich] gave a 29C3 last year. She had made quite a bit of headway hacking the playable pods, but wasn’t able to get her hands on a full ROM dump from the General Plus chip on board processor. This update heralds her success and shares the details of how it was done.
As we learned form the video lecture it was a huge chore just to figure out what processor this uses. It turned out to be a 6502 core with a few other things built in. After prowling the manufacturer’s website she found example code for writing to Port A. She was then able to execute her own code which was designed to dump one byte of ROM at a time using the SPI protocol.
[Natalie] posted her code dump if you’re interested in digging through it. But as usual we think the journey is the most interesting part.
After seeing a Game Boy emulator for the first time, [Thijs] was amazed. A small box with just a handful of electronics that turns a Game Boy cartridge into a file able to be run on an emulator is simply magical. [Thijs] has learned a lot about GB and GBC cartridges in the mean time, but still thinks the only way to really learn something is to roll up your sleeves and get your hands dirty. Thus was born [Thijs]’ Game Boy cartridge dumper, powered by a pair of I2C port expanders and a Raspberry Pi.
Inspired by a build to dump ROMs off Super Nintendo games with the help of a Raspberry Pi, [Thijs] grabbed all the hardware necessary to create his own GB cart dumper. A DS Lite cartridge adapter provided the physical connection and a pair of MCP23017 I/O expanders – one soldered to a Slice of PI/O board – provided the electrical connections.
In the end, [Thijs] managed to dump the ROMs off the Japanese editions of Pokemon Yellow and Gold in about 13 minutes. This is a much slower transfer rate of 26 minutes per SNES cart in the post that gave [Thijs] the inspiration for this build. Still, [Thijs] will probably be the first to say he’s learned a lot from this build, especially after some problems with dumping the right banks from the cartridge.
One day, [Adam] was asked if he would like to take part in a little project. A mad scientist come engineer at [Adam]’s job had just removed the plastic casing from a IC, and wanted a little help decoding the information on a masked ROM. These ROMs are basically just data etched directly into silicon, so the only way to actually read the data is with some nitric acid and a microscope. [Adam] was more than up for the challenge, but not wanting to count out thousands of 1s and 0s etched into a chip, he figured out a way to let a computer do it with some clever programming and computer vision.
[Adam] has used OpenCV before, but the macro image of the masked ROM had a lot of extraneous information; there were gaps in the columns of bits, and letting a computer do all the work would result in crap data. His solution was to semi-automate the process of counting 1s and 0s by selecting a grid by hand and letting image processing software do the rest of the work.
This work resulted in rompar, a tool to decode the data on de-packaged ROMs. It works very well – [Adam] was able to successfully decode the ROM and netted the machine codes for the object of his reverse engineering.