A Simple Commodore 64 Cart Dumper

July 9, 2014 by Brian Benchoff 23 Comments

c64

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.

The Meaning Of Being A Hard-core Hacker From A 1985 Recollection

May 4, 2013 by Mike Szczys 91 Comments

6502-hand-assembling-and-programming

Gather ’round children, we’re about to hear a story about the good old days. Except that this is really more of a horror story of what it used to be like as a code monkey. [John Graham-Cumming] shares his experience programming a 6502-based KIM-1 machine back in 1985. Simple, right? The caveat being that there was no assembler or hardware for loading the finished code!

The machine in question was a label application tool for a production line. You know, product goes in bottle, label gets slapped on the side. But the slapping needed to be perfect because consumers shy away from packaging that looks shoddy. Computer control would end up being far superior than the mechanical means the factory had been using because it simplifies the ability to adjust calibration and other parameters. [John] started from square one by interfacing the KIM-1 with the existing hardware. It has a hex keyboard which is how the program was entered into the device. But first he wrote the software on sheets of notebook paper like the one seen above. It includes his hand assembled code, which was then typed in on the keypad. Kind of makes you appreciate all the tools you take for granted (like Eclipse), huh?

[via Reddit]

HEX Out Reveals The Secrets Your Data Bus Holds

November 7, 2011 by Mike Szczys 5 Comments

[Quinn Dunki] is looking to augment the tools she has available at her electronics bench and built the HEX Out as a mock-logic sniffer. The device reads 8 or 16-bit inputs, showing the current state of those connections on a 7-segment display. This requires that you’re comfortable reading Hex codes, but if you’re not it’s almost like studying flash cards; before long you’ll be able to read them without thinking about it.

She’s blogging about the design and build process in three parts. The link above is the first installment where she shares the development process for the top layer which hosts the display hardware. The other two parts should be up for your enjoyment in the next couple of weeks.

You’ll notice her design on this portion of the project still requires a lot of point-to-point soldering, even though she etched her own circuit boards. We didn’t look too closely, but it seems this would be worth going to the trouble of etching a double-sided board if you can.

UPDATE: Part Two is now available

Hexacopter

February 15, 2010 by Caleb Kraft 70 Comments

[vimeo=http://vimeo.com/6194911]
Quad copters have been pretty popular for the last few years, but this one is new to us. Take the same basic layout, but bump it to 6 rotors. Then you’ll have the hexacopter (google translated). With 6 rotors, built in GPS and stabilization and a camera mounted on the bottom, this thing is pretty well equipped. You can see how agile and stable it is in the video above. We know it isn’t necessarily new, but it is new to us. Of course, you don’t have to stop at 6 rotors. You could always just continue on to 8.

Recover Borked HDD After Xbox 360 Ban

November 25, 2009 by Mike Szczys 33 Comments

[Incudie] tipped us off about a method to fix a borked HDD in your Xbox 360. Many of the one million consoles banned earlier in the month also had the hard disks scrambled making off-line gaming impossible as well. It turns out that this is caused by having a ban flag in the NAND chip on the motherboard. It has been discovered that because of wear levelling, the NAND will have two copies of the “secdata.bin” file which stores the ban flag. Please note, this will NOT allow the console to use Xbox Live, it just re-enables the HDD.

The quick and dirty of the fix is as follows: First the NAND is dumped from your Xbox 360 to a computer. After verifying the file, it can be opened in a HEX editor and the two copies of “secdata.bin” located. Once identified by date, the older version is injected on top of the newer to overwrite the ban flag.

Looks like this is not for the faint of heart, but if you got banned for modding in the first place this should be easy to pull off.

Update: Looks like xbox-scene now has a collection of apps to help you with this process. [Thanks CollinstheClown]

Manual Protocol Analysis

January 24, 2009 by Eliot 2 Comments

packetfu

As a followup to last week’s post on automated protocol analysis, [Tod Beardsley] has written up how to start analyzing a protocol manually. He walks through several examples to show how to pull out the interesting bits in binary protocols. His first step was sending 10 identical select statements and capturing the outbound packets. He used the Ruby library PacketFu to help with the identification. It compared the ten packets and highlighted one byte that was incrementing by four with each packet, probably a counter. Looking at the response indicated a few other bytes that were also incrementing at the same rate, but at different values. Running the same query on two different days turned up what could be a timestamp. Using two different queries helped identify which byte was responsible for the statement length. While you may not find yourself buried in HEX on a daily basis, the post provides good coverage of how to think critically about it.