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.
You can leave the TI graphing calculator at home thanks to this web-based TI-83 and TI-84 emulator. As with pretty much all emulators, this depends on a ROM image from the actual hardware to work. But if you have one of the supported calculators (TI-83+, TI-83+ SE, TI-84+, or TI-84+SE) you can dump the image yourself and this should work like a charm.
We’ve seen some arguments online about the price of the TI line over the years. Prices haven’t dropped much over the decades even though they’re making pretty much the same hardware. It’s cool to see someone figure out how to emulate the hardware — and on a web interface to boot! But we’re left wondering why TI isn’t selling an equivalent app for iOS and Android or at least leveraging what must be millions in each production run for a lower retail price?
Continue reading “Web-based TI graphing calculator emulator”
We hope our readers are familiar with the vast number of ROM hacks for the original 1st-gen Pokemon games. With certain sequences of button presses, it’s possible to duplicate items in the player’s inventory, get infinite money, or even catch a glimpse of the elusive MissingNo. [bortreb] is familiar with all these hacks, but his efforts to program a Game Boy from inside Pokemon is by far the greatest Pokemon glitch ever created.
This ‘total control’ ROM hack was inspired by [p4wn3r]’s extremely impressive 1 minute and 36 second long speed run for Pokemon Yellow. The technique used in [p4wn3r]’s run relies on the fact the warp points in Pokemon Yellow are right after the item list in the Game Boy’s memory. By corrupting the item list, [p4wn3r] figured out how to make the front door of his house warp directly to the end of the game resulting in the fastest Pokemon speed run ever.
Realizing this ROM hack is able to control the CPU with only the player’s inventory, [bortreb] wanted to see how far he could push this hack. He ended up writing a bootstrapping program by depositing and discarding items from the in-game PC, and was then able to reprogram the Game Boy with a number of button presses on the D-pad, select, start, A and B buttons.
The resulting hack means [bortreb] can actually make Pong, Pacman, a MIDI player, or even a copy of Pokemon Blue. In the video after the break, you can see all of [bortreb]’s speed run along with the finale of playing a MIDI file of the My Little Pony theme song. [bortreb] has a really amazing hack on his hands here that really pushes the definition of what can be done by tinkering around with a Pokemon ROM.
Continue reading “Programming a Game Boy while playing Pokemon”
We’ve seen FPGAs used to recreate everything from classic arcade games to ancient computers, but with each of these builds a common problem arises. Once you’ve got the hardware emulated on an FPGA, you’ve also got to get the ROMs into the project as well. In a very interesting hack, [Mike] figured out that the serial Flash chip that stores the FPGA settings has a lot of space free, so why not store user data there?
[Mike] got the idea from seeing a recreation of the classic BombJack arcade game we featured last month. In that build, [Alex] needed to store 112Kb of game data stored in 16 ROM chips. Unfortunately, [Alex]’s FPGA only had space for 40Kb of data. After realizing his FPGA had a 512Kb SRAM chip, [Alex] decided to put all the sprites, sounds, and levels of BombJack in the SRAM.
Impressed with [Alex]’s build, [Mike] set to work generalizing the hack to work with other projects. [Mike] notes that only a few FPGA boards are capable of storing user data next to the configuration bitstream; the hack is impossible on the Digilent Basys2 board, but it works wonderfully on a Papilio One 250K.
As a very cool build that makes FPGA-related builds even easier, we’ve got to tip our hat to [Mike] for writing up a great tutorial.
[Blark] picked up a couple of Commodore 64 machines on Craig’s List so that he could play around with the SID chips inside. But there’s some other fun stuff in there and his attention was drawn to the PROM which stores the kernel. He thought it would be a fun adventure to build a ROM dumper capable of storing binary images.
In the video after the break you can see that when powered up the dumper immediately starts streaming hex values to the terminal. The system is set up to feed a Python script which packs the data stream into an image file. The reading is done by a PIC 18F4520, streaming the data in at 9600 baud with a generous delay between each address read to get the cleanest read possible. He had a bit of help from the AVR Freaks to get to this point.
We’d guess he’s going to pull the image off the chip several times and compare results to filter out any possible data corruption. From there we’re not sure what he’ll do with the files but there’s always the possibility of making is own emulator using this kernel image.
Continue reading “Dumping a C64 kernel”
The picture you see above is taken from the ROM of a Macintosh SE made in the late 1980s. This black and white image remained buried inside old Macs until [Adam] and [Trammell] at NYC Resistor reverse engineered these old Mac ROMs and found a few really cool Easter eggs.
[Adam] and [Trammell] have been dumping ROMs from old computers for a while now. Their modus operandi is finding old 27C-series EPROMs on old computers, prying the out of their comfortable home, slapping them in a breadboard, and wiring up an Arduino clone to dump the data to a computer.
Recently, the guys found an old Mac SE lying on the side of a road in Brooklyn and brought it over to NYC Resistor. They had known about images hidden in the SE ROM, but the guys wanted to know how and where these pictures were stored. After carefully inspecting the binary file generated from dumping the ROM, [Adam] was able to recover three images hidden in every Macintosh SE.
The folks at Apple – especially in the heady days of the Apple II and 68k Macs – hid quite a few Easter eggs in the ROMs of their computers. For instance, the Apple IIgs has audio data stored in the ROM, and the Macintosh Classic hid an entire operating system – System 6.0.3 – in the ROM of the machine.
[Pulko Mandy] doesn’t use his flash ROM programmer very often, but he does use it. When he tried to get support for a new chip and the manufacturer suggested he just buy a newer version he decided to hack the programmer and it’s software instead.
This device connects to the parallel port and was intended for use with MS-DOS systems (no wonder there’s no longer support from the company). The board uses logic chips to add read and write function. So the first step was to analyze how they connect together and come up with a set of commands. While at it he also made some changes to the board to bring the voltage more in spec and ensure the logic levels on the parallel port met the correct voltages.
His plan was to use the board with a Linux system so the parallel port interface can stay. He used what he learned from the hardware inspection to write his own interface in C++. It works with a chip he was able to use under the MS-DOS software, but he hasn’t gotten it to work with the chip that sparked this adventure. If you’re familiar with how the AT29C040A works please consider lending a hand.