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?
This simple circuitry makes up the hardware for [Andrew’s] AVR-based VGA generator. He managed to get an ATmega1284 to output a stable VGA signal. Anyone who’s looked into the VGA standard will know that this is quite an accomplishment. That’s because VGA is all about timing, and that presented him with a problem almost immediately.
The chip is meant to run at a top speed of 20 MHz. [Andrew] did manage to get code written that implemented the horizontal and vertical sync at this speed. But there weren’t enough clock cycles left to deal with frame buffering. His solution was to overclock the chip to 25 MHz. We assume he chose that because he had a crystal on hand, because we think it would have been easier to use a 25.174 MHz crystal which is one of the speeds listed in the specification.
Red, green, and blue each get their own two-bit range selected via a set of resistors for a total of 64 colors. As you can see in the video after the break, the 128×96 pixel video is up and running. [Andrew] plans to enlarge the scope of the project from here to make it more versatile than just showing standard images. The code (written in assembly) is available at his GitHub repository.
Continue reading “AVR VGA generator”
We love seeing hard-core firmware reverse engineering projects, but the number of hackers who can pull those off is relatively small. It’s possible to grow the ranks of the hacker elite though. A hackerspace is a great place to have a little challenge like this one. [Nicolas Oberli] put together a capture the flag game that requires the contestants to reverse engineer Teensy 3.0 firmware.
He developed this piece of hardware for the Insomni’hack 2013 event. It uses the Teensy 3.0 capacitive touch capabilities to form a nine-digit keypad with a character LCD screen for feedback. When the correct code is entered the screen will display instructions on how to retrieve the ‘flag’.
To the right you can see the disassembly of the .elf file generated by the Arduino IDE. This is what [Nicolas] gave to the contestants, which gets them past the barrier of figuring out how to dump the code from the chip itself. But it does get them thinking in assembly and eventually leads to figuring out what the secret code is for the device. This may be just enough of a shove in the right direction that one needs to get elbow deep into picking apart embedded hardware as a hobby.
Continue reading “Reverse engineering challenge starts off simple”
The 6502 was in a lot of early equipment. In addition to the previously mentioned Atari they can be found in the Commodore 64, Apple II, and the original NES. You can even find folks building their own computers around the chip these days (most notable to us is the Veronica project). The guide starts off slowly, providing a working program and challenging the reader to play with to code in order to alter the outcomes. It moves on to an overview of registers and instructions, operators and branching, and culminates in the creation of a simple game.
Here’s an interesting tip that can help improve your ability to write assembly code. In an effort to remove the complexity of assembly code for an AVR project [Quinn Dunki] figured out how to use macros when writing AVR code with the GNU toolchain. Anyone using AVR-GCC should keep this in mind if they ever want or need to pound out a project in assembly language.
If you look at the code snippet above you’ll see two commands that are obviously not assembly; PulseVRAMWrite and DisableVRAMWrite. These are macros that direct the assembler to roll in a hunk of code. But avr-as, the assembler used with this toolchain, lacks the ability to handle macros. That’s too bad because we agree with [Quinn] that these macros make the code easier to read and greatly reduce the probability of error from a typo since the code in the macro will be used repeatedly.
The answer is to alter the makefile to use GNU M4. We hadn’t heard of it, but sure enough it’s already installed on our Linux Mint system (“man m4″ for more info). It’s a robust macro processor that swaps out all of her macros based on a separate file which defines them. The result is an assembly file that will play nicely with avr-as.
Her implementation is to help in development of the GPU for her Veronica computer project.
It can be really hard to warm up to coding in Assembly. But this tutorial looks to make it understandable and (almost) easy. It focuses on programming a game for the ZX Spectrum. But you won’t need the hardware on hand as you can just use the ZX Spin emulator as you work your way through the code.
Ostensibly this is a 30-minute tutorial but that’s a gross underestimate. We finished a cursory read of the tutorial and the building blocks are certainly clear and easy to understand. But we like to make sure we understand every line of code and plan to spread that out over the coming weekend.
The first chapter eases us into machine code by combining it with a bit of BASIC. You’ll see how to manipulate the ZX Spectrum memory and then pluck that value back out into the BASIC program. But once chapter 2 hits it’s pretty much all assembly from there on out. The nice thing is that as you go along you learn how the hardware works and there are quite a few references to pages in the manual so you can do some extra learning along the way.
We’ve been living a life of luxury, writing our microcontroller code in a text editor and using — of all things — a compiler to turn it into something the chip can use. [Dan Amlund Thomsen] shows us a different way of doing things. He’s actually crafting the operation codes for a PIC microcontroller by hand. We’re glad he’s explained this in-depth because right now we feel way over our heads.
His program is pretty simple, it blinks a single LED and he’s chosen t work with a PIC 12F1840. The first order of business is to issues the words that configure the chip using 14-bit binary values from the datasheet. From there he goes on to write the program in assembly code. At this point he could pretty much just run this through the assembler, but he’s really just getting started now. He walks through the format necessary to package the configuration words, then goes on to illustrate the translation of assembly commands to binary op codes. We’re not sure we’ll ever get around to trying this ourselves, but it was certainly fun to read about it.