Here’s a slick-looking VGA demo written in assembly by [Yianni Kostaris]; it’s VGA output from an otherwise stock ATmega2560 at 16MHz with no external chips involved. If you’re getting some Super Mario Kart vibes from how it looks, there’s a good reason for that. The demo implements a form of the Super Nintendo’s Mode 7 graphics, which allowed for a background to be efficiently texture-mapped, rotated, and scaled for a 3D effect. It was used in racing games (such as Super Mario Kart) but also in many others. A video of the demo is embedded below.
[Yianni] posted the original demo a year earlier, but just recently added detailed technical information on how it was all accomplished. The AVR outputs VGA signals directly, resulting in 100×120 resolution with 256 colors, zipping along at 60 fps. The AVR itself is not modified or overclocked in any way — it runs at an entirely normal 16MHz and spends 93% of its time handling interrupts. Despite sharing details for how this is done, [Yianni] hasn’t released any code, but told us this demo is an offshoot from another project that is still in progress. It’s worth staying tuned because it’s clear [Yianni] knows his stuff.
The Apple II was one of the first home computers. Designed by Steve “Woz” Wozniak, it used the MOS technologies 6502 processor, an 8-bit processor running at about 1 MHz. [Maxstaunch] wrote his bachelor thesis about emulating the 6502 in software on an AVR1284 and came up with a handheld prototype Apple II with screen and keyboard.
Originally, [maxstrauch] wanted to build an NES, which uses the same 6502 processor, but he calculated the NES’s Picture Processing Unit would be too complicated for the AVR, so he started on emulating the Apple II instead. It’s not quite there – it can only reference 12K of memory instead of the 64K on the original, so hi-res graphic mode, and therefore, many games, won’t work, but lo-res mode works as well as BASIC (both Integer BASIC and Applesoft BASIC.)
[Maxstrauch] details the 6502 in his thesis and, in a separate document, he gives an overview of the project. A third document has the schematic he used to build his emulator. His thesis goes into great detail about the 6502 and how he maps it to the AVR microcontroller. The build itself is pretty impressive, too. Done on veroboard, the build has a display, keyboard and a small speaker as well as a micro SD card for reading and storing data. For more 6502 projects, check out the Dis-Integrated 6502 and also, this guide to building a homebrew 6502.
Lisp is a supremely elegant programming language, but you won’t find it around much today. That’s a shame; in the 80s and 90s, all the cool kids were using Lisp machines, computers dedicated to the creation and interpretation of Lisp. While the AI renaissance of the 80s is dead, replaced with the machine learning fad of today, Lisp machines have gotten much smaller. Now, they’ll fit in your pocket, and they have parenthesis matching, to boot.
If this build looks familiar, you’re not wrong. A while back, we saw a similar pocket Lisp computer based around the ATMega328 microcontroller with 32k of Flash and 2k of RAM. That’s not a lot by any measure, and a much more suitable processor for an AVR-based pocket Lisp machine would be the big boys of the ATMega family.
The new and improved version of the Tiny Lisp Computer is built around the ATMega1284. If it’s capable enough to run a 3D printer, it should run Lisp very well. With more program space and more RAM come more features including matching parens when entering code, a serial monitor interface, and a program editor – basically a text editor on the chip.
Apart from the larger chip, the circuit remains relatively unchanged. The display is still an OLED that can be had for a few dollars from the usual online retailers, and the other bits of circuitry are still just a handful of resistors, caps, and wire. An off-the-shelf FTDI module (or whatever serial chip you desire) can be added to connect to a serial terminal, and support for a PS/2 keyboard rounds out the board.
We’ve seen tiny microcontroller-based computers before, but nothing like this. Where the usual AVR + display + serial connection features BASIC, Forth, or another forgotten language from the annals of computer history, this project turns an AVR into a Lisp machine.
The μλ project is the product of several decades of playing with Lisp on the university mainframe, finding a Lisp interpreter for the 6800 in Byte, and writing a few lisp applications using the Macintosh Toolbox. While this experience gave the author a handle on Lisp running on memory-constrained systems, MicroLisp is running on an ATMega328 with 32k of Flash and 2k of RAM. In that tiny space, this tiny computer can blink a few boards, write to an OLED display, and read a PS/2 keyboard.
The circuit is simple enough to fit on a breadboard, but the real trick here is the firmware. A large subset of Lisp is supported, as is analog and digitalRead, analog and digitalWrite, I2C, SPI, and a serial interface. It’s an amazing piece of work that’s just begging to be slapped together on a piece of perfboard, if only to have a pocket-sized Lisp machine.
Sometimes there’s just no substitute for the right diagnostic tool. [Ankit] was trying to port some I2C code from an Arduino platform to an ARM chip. When the latter code wasn’t working, he got clever and wrote a small sketch for the Arduino which would echo each byte that came across I2C out to the serial line. The bytes all looked right, yet the OLED still wasn’t working.
Time to bring out the right tool for the job: a logic analyzer or oscilloscope. Once he did that, the problem was obvious (see banner image — Arduino on top, ARM on bottom): he misunderstood what the ARM code was doing and was accidentally sending an I2C stop/start signal between two bytes. With that figured, he was on the right track in no time.
We just ran an epic post on troubleshooting I2C, and we’ll absolutely attest to the utility of having a scope or logic analyzer on hand when debugging communications. If you suspect that the bits aren’t going where they’re supposed to, there’s one way to find out. It’s conceivable that [Ankit] could have dug his way through the AVR’s hardware I2C peripheral documentation and managed to find the status codes that would have also given him the same insight, but it’s often the case that putting a scope on it is the quick and easy way out.
It probably doesn’t matter much for the hacker who sleeps with a bag of various microcontroller flash programmers under the pillow, but for an end-user to apply a firmware upgrade, convenience is king. These days that means using USB, and there are a few good AVR USB bootloaders out there.
But [Dmitry Grinberg] wanted more: the ability to encrypt the ROM images and verify that they haven’t been tampered with or otherwise messed up in transit. Combined with the USB requirement, that meant writing his own bootloader and PC-side tools. His bootloader will take unencrypted uploads if it doesn’t have a password, but if it’s compiled with a key, it will only accept (correctly) encrypted hex files.
Since the bootloader, including the USB firmware, is on the hefty side at 3.3 kB, [Dmitry] included hooks to re-use the bootloader’s USB code from within the target application. So if you were going to use V-USB in your program anyway, it doesn’t actually take up that much extra space. It’s a cute trick, but it ties the bootloader and user program together in a way that gives us the willies, without specifically knowing why. Perhaps we can debate this in the comments.
If you need an AVR USB bootloader, but you don’t need the encryption, we like Micronucleus. But if you need to deliver updates to users without them being able to modify (or screw up) the code in the middle, give [Dmitry]’s setup a try.
Last time on Embed with Elliot, I began my celebration of the make command’s 40th birthday next month. We discussed using the default rules and how to augment them with your own variables defined in a makefile. Next, I’ll walk you through some makefiles that can be used for real-world microcontroller code development. This week, we’ll focus on one for the AVR platform, and later on, I’ll run through a slightly more complicated version for the ST32M series of ARM Cortex micros.
Along the way, we’ll pick up a couple of tricks, but the aim is to keep the makefiles minimal, readable, and easily extensible. Once you get a little taste of the power of writing your own makefiles, you probably won’t be able to stop adding bells and whistles — custom routines for flashing, checking the size of binaries, generating assembly listings, etc. I’ll leave the extras up to you, but you’ll eventually find that anything you do can be automated with a makefile.