hex

[Yann]’s DYPLED entry into this year’s Hackaday Prize isn’t very useful to most people. It’s a tiny module that connects to a 16-bit parallel bus, and displays a hexadecimal number on a few LEDs. It’s useful if you’re diagnosing a problem on a computer from 1982, but just barely. The real wonder here is how [Yann] is doing this cheaply and easily using some weird techniques and strange parts.

The display for this tiny device is an array of 36 LEDs, arranged into a set of five seven-segment displays. Homebrew seven-segment displays are cool, but how is he driving it? Not with a microcontroller, that’s for sure. Instead, [Yann] is using an old trick of using parallel memory to store the patterns of the seven-segment displays. This parallel memory comes in the form of a two megabit Flash chip, with the data inputs tied to the 16-bit input on the board and the data outputs connected directly to the LEDs. It’s a brute force approach, but it works.

There are a few additional features for this tiny board, including a switch to display a 16-bit bus in hexadecimal or decimal, signed or unsigned, and a pot to change how bright the LEDs are. The most amazing part is how [Yann] managed to fit all of this on a very, very small PCB. Most of that trick is due to using a thin, small TSSOP package for the Flash memory, but fitting this circuit onto a two layer board is amazing work, and a great entry for the Hackaday Prize.

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.

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?

[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.

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.

[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.

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.