I've recently used Atmel's ATMega32u4 and I liked it a lot. 32 kilobytes of flash, USB transceiver and bootloader support are the most important features of this rather inexpensive device, which make it very easy to use for prototyping USB devices.
A nice addition is that the device comes preflashed with Atmel's DFU bootloader, which makes it possible to program the device over USB without connecting SPI or JTAG. It doesn't support any debugging, but it's good enough for simple projects.
I've been working on a project recently, where I assumed JTAG or SPI wouldn't be necessary and decided to rely on the stock bootloader. The problem is, I needed to change the contents of the flash memory in run-time. This is possible with the bootloader's ABI, but as it turned out, not that easy.
I read a lot of PDFs. In fact most of my time at the computer I spend reading PDFs. I read documentation, datasheets and lots of school stuff, so this definitely requires a good choice of a PDF reader.
Because I'm also a user of XMonad, just opening a PDF reader and reading a document is not what satisfies me. I need a sensible way to organize opened documents and a quick way of opening just downloaded files.
For the last couple of years I've been succesfully using xpdf - the reader which remained my favourite for a pretty long time. Unfortunately, recently gentoo dropped support for it, because of its bugginess and stalled development (or no development at all:D), so after some time of providing my own ebuilds, when it failed to start after a poppler upgrade, I decided to search for something else.
Back in the times when users and vendors actually cared for their input devices, there were some great keyboards in the market, which were not only designed to last, but actually made to withstand even very harsh conditions. Good quality plastics, mechanical switches, good electrical and mechanical design practices and lasting keycaps and their legends are just some of the great advantages of vintage keyboards.
This is part 2 of reverse-engineering the LCD driver inside a COB device on a cheap "9999 in 1" videogame. Make sure you also check out part 1 here: 9999 in 1 reloaded - part 1.
Driver analysis - part 2
Let's look at the last plots again. Yellow is common signal, cyan - segment signal, and magenta - difference across pixel. This time I measured them with the LCD disconnected, so they should look a bit nicer.
After a couple of years of not even remembering about this wonderful piece of high-end gaming equipment I got my hands on a 9999 in 1 brick game.
They come in various versions. The number of games may vary (though in fact there are just a few of them, the rest being merely a result of cross product with all possible levels). Colors vary too, but they're all ugly.
Anyway, the device features a whooping 10x20 pixel main screen and a handful additional indicators like play/pause, next element (tetris), etc., and a couple of 7-segment displays, and can get me to spend hours (well okay, minutes) rotating bricks or racing.
So I thought there must be a way to overcome the low contrast of the display and the hopeless feel of the buttons and I started investigating.
Reimplement the whole thing for a PC or a custom device? Nah, too much work, and you loose the best part of it, its vintage-ness. I'll never make it work exactly the same as the original device, so that's not an option.
But what if we just give the thing some new I/O...