There is a high probability that the device on which you are reading this comes somehow loosely under the broad definition of a PC. The familiar x86 architecture with peripheral standards has trounced all its competitors over the years, to the extent that it is only in the mobile and tablet space of personal computing that it has not become dominant.
The modern PC with its multi-core processor and 64-bit instruction set is a world away from its 16-bit ancestor from the early 1980s. Those early PCs were computers in the manner of the day, in which there were relatively few peripherals, and the microprocessor bus was exposed almost directly rather than through the abstractions and gatekeepers we’d expect to see today. The 8088 processor with an 8-bit external bus though is the primordial PC processor, and within reason you will find software written for DOS on those earliest IBM machines will often still run on your multiprocessor behemoth over a DOS-like layer on your present-day operating system. This 35-year-plus chain of mostly unbroken compatibility is both a remarkable feat of engineering and a millstone round the necks of modern PC hardware and OS developers.
Those early PCs have captured the attention of [esot.eric], who has come up with the interesting project of interfacing an AVR microcontroller to the 8088 system bus of one of those early PCs. Thus all those PC peripherals could be made to run under the control of something a little more up-to-date. When you consider that the 8088 ran at a modest 300KIPS and that the AVR is capable of running at a by comparison blisteringly fast 22MIPS, the idea was that it should be able to emulate an 8088 at the same speed as an original, if not faster. His progress makes for a long and fascinating read, so far he has accessed the PC’s 640KB of RAM reliably, talked to an ISA-bus parallel port, and made a CGA card produce colours and characters. Interestingly the AVR has the potential for speed enhancements not possible with an 8088, for example it can use its own internal UART with many fewer instructions than it would use to access the PC UART, and its internal Flash memory can contain the PC BIOS and read it a huge amount faster than a real BIOS ROM could be on real PC hardware.
It is funny how almost everything has its own set of problems. Rich people complain about taxes. Famous people complain about their lack of privacy. It probably won’t happen us, but some Kickstarter campaigners find they are too successful and have to scale up production, fast. We’d love to have any of those problems.
[Limpkin] found himself in just that situation. He had to program several thousand Atmel chips. It is true that you can get them programmed by major distributors, but in this case, he wanted unique serial numbers, cryptographic keys, and other per-chip data programmed in. So he decided to build his own mass programming workbench.
Turning an Arduino of virtually any sort into a simple AVR 6-pin ISP programmer is old hat. But when Atmel came out with a series of really tiny AVR chips, the ATtiny10 and friends with only six pins total, they needed a new programming standard. Enter TPI (tiny programming interface), and exit all of your previously useful DIY AVR programmers.
[Kimio Kosaka] wrote a dual-purpose TPI and ISP firmware for the ATmegaxxUn chips that are used as a USB-serial bridge on the Unos, and constitute the only chip on board a Leonardo or Micro. The catch? You’re going to have to do a little bit of fine-pitch soldering. Specifically, [Kosaka-san] wants you to get access to an otherwise obscured signal by drilling out a via. We’d do it just for that alone.
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.
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.
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.
It’s not just an LED-blinker, though. He added in a light-detection function so that it only switches on at night. It uses the Forest Mims trick of reverse-biasing the LED and waiting for it to discharge its internal capacitance. The point is, however, that it gives the chip something to do instead of simply sleeping.
Although he’s an AVR user by habit, [Thierry] finds in favor of the PIC because it’s got a lower power draw both when idling and when awake and doing some computation. This is largely because the PIC has an onboard low-power oscillator that lets it limp along at 32 kHz, but also because the chip has a lower power consumption in general. In the end, it’s probably a 10% advantage to the PIC on power.
If you’re competent with one of the two chips, but not the other, his two versions of the same code would be a great way to start familiarizing yourself with the other. We really like his isDarkerThan() function which makes extensive use of sleep modes on both chips during the LED’s discharge period. And honestly, at this level the code for the two is more similar than different.
(Oh, and did you notice [Thierry]’s use of a paper clip as a coin-cell holder? It’s a hack!)
Surprisingly, we’ve managed to avoid taking a stray bullet from the crossfire that occasionally breaks out between the PIC and AVR fans. We have covered a “shootout” before, and PIC won that round too, although it was similarly close. Will the Microchip purchase of Atmel calm the flames? Let’s find out in the comment section. We have our popcorn ready!