8-bit touchscreen ebook reader | Hacker News Reader

8-bit touchscreen ebook reader

rossum.posterous.com

131 pointsmicampe17 comments

My jaw just dropped upon seeing what can be achieved considering the amount of resource that was used.

If you're used to program only with modern hardware (PC/Mac/iPhone/Android/whatever) you'll never understand how insanely fast 2.5k RAM can be consumed. For example, declaring a fixed char[] of 255 chars would consume 10% of the entire amount of physical memory you have (you can, however, have "swap" on the Microsd card but that's another problem.)

Previous projects of him include Zork for his same hardware platform ( http://rossum.posterous.com/zork-for-the-microtouch ) , the Atari Microsd drive ( http://rossum.posterous.com/a-little-atari-810-disk-drive ). Other parts that come with the microtouch kit (microtouch simulator on Windows, the shell, pacmac, 3d maze, paint) are mind blowing too.

Microtouch is an amazing kit. I had a chance to work on the Microtouch for a while and it was incredibly fun. I currently have my microtouch kit hanging outside of my office as an interactive picture frame ( http://tnhh.net/pancake/2011/09/lolz-pic-frame.html ), but because of this I might want to take it back some time :-)

> My jaw just dropped upon seeing what can be achieved considering the amount of resource that was used.

He's kind of cheating: even though the microcontroller contains only 2.5KiB of RAM, he's using an LCD controller with 172800 bytes of video RAM. The microcontroller costs US$3.79 in small quantities; the LCD controller plus some LCD (maybe not the same one) costs US$36 from Adafruit https://www.adafruit.com/products/335 or US$22 from Mouser http://www.mouser.com/ProductDetail/Microtips-Technology/MTF....

Very, very impressive.

But... I don't see the advantage of having a touch screen for ebooks. I only ever want the next or previous page. Yes, a touch screen is perhaps more natural _when compared to a paper book_, but hitting a button for the next page means I don't obscure the screen with my fingers, and it's more comfortable to press (less movement).

Here are some use cases:

- go to the table of contents

- click a hyperlink to another chapter

- open a search panel to search for text

Most will be used more when reading reference works then when reading literature, but a search can be useful in literature, too:

- if you want to make a quotation, it makes it easier to find the exact text to quote.

- if, on page 400 of the lord of the rings, you encounter a name that you vaguely remember, searching makes it easier to find out where the person or place was introduced.

I don't see the link between a touchscreen and what you've written (or are these use cases for a keyboard?)

I think in your first comment you appear to be advocating just having a forward/back button instead of anything else.

Well there is more to an ebook reader than just reading. The more popular ones have stores for buying books, for example.

Of course the UI can be designed for hardware buttons but at a certain point you're going to have to strike a balance between device size and user friendliness. For example, you could either: not allow text input, have a hardware keyboard, have a software keyboard navigated with minimal hardware buttons, or have a software keyboard with a touch screen. Of those I prefer a touch screen - the device will be smaller and/or have a larger screen and still be user friendly.

I'd still like to see an eReader that also allows me to use a stylus to write notes in the margins or open up a notepad like app for full page notes.

This looks like the hardware kit that is used: http://www.adafruit.com/category/51

Actually, this kit is linked from the post: https://www.adafruit.com/products/330

Yes - but just to clarify, the Microtouch is the hardware kit that he designed. He's not just slapping code on someone else's device.

I have programmed 8-bit microcontrollers some time ago, specifically AVR Atmega's. It's a fine microarchitecture http://en.wikipedia.org/wiki/Atmel_AVR ("the first new 8 bit architecture for the last 20 years", they used to say) But don't low-end ARM chips displace 8-bit microcontrollers by now?

Meta: is there any site that one can read to get up to speed with the recent developments in the embedded CPU world?

I don't think ARM can displace AVR, mainly because ARM is expensive and weekend projects often doesn't require that much power for computation. ARM fits in neither the simple projects category (AVR would do it more cheaply) nor complicated projects category (x86 would do it faster and more cheaply) for independent hackers. Plus, AVR now has a very friendly Arduino kit which is an important factor because of the sheer amount of support and community around it. Also, ARM is not standardlized, and is not very well supported with free software, which is another limitation which AVR doesn't have.

I often follow hackaday.com -- it has tons of links to amazing projects and resources for the curious.

I'm not doing AVR programming that much other than the microtouch kit, but I'm doing a little bit more on the TI's msp430 platform, mainly because I'm a student and thus, I'm cheap. Plus, TI's msp430 is insanely efficient, you can go very very low power and its language is C which is 'nicer' than the popular arduino pseudo-C code.

For msp430 I often visit 43oh and refer to TI datasheet, they are often very very good.

The Microtouch is using an ATMega32u4, which I think is this one: http://search.digikey.com/us/en/products/ATMEGA32U4-AU/ATMEG..., which Digi-Key lists for US$3.79 each in quantity 25. An ARM alternative would be the LPC2103, such as http://search.digikey.com/us/en/products/LPC2103FBD48,151/56..., US$4.95 in quantity 25.

That's a real difference, but the Adafruit retail price of this device is US$70. But the ARM chip is, at least on paper, dramatically more capable:

The AVR has an 8-bit ALU and runs up to 16MIPS (12MIPS in this case) and has 32K of Flash and 2.5K of RAM. The ARM has a 32-bit ALU, runs up to 70MIPS, has 32K of Flash, and 8K of RAM.

So for boosting the price from US$70 to US$71 or US$72, it would seem that you get three times the RAM and six times the compute cycles.

Newer ARM chips like the LPC1114 http://search.digikey.com/us/en/products/LPC1114FHN33%2F302:... are US$2.25, 50MHz (and I assume 50MIPS), 32K/8K, Cortex-M0.

So there must be something I'm missing. What am I missing? Are the LPC2103 and LPC1114 a lot harder to integrate into existing designs? Is it that much harder to get ARM machine code out of GCC? Is the LPC very power-hungry? Does the LPC need some kind of expensive and complicated support circuitry? I'm out of my depth here. Help me out.

I've been reading more of his blog. He's been doing some amazing things with the LPC111x family, like this offline Wikipedia reader http://rossum.posterous.com/wikipedia-homebrew-device-featur... and this video game console that generates composite video signals in software http://rossum.posterous.com/20131601. So I wonder if maybe he used the AVR instead of the ARM just because it was an earlier design.

This is incredible. It doesn't make any sense. How can you do that kind of display with 2½KiB of RAM? 320×240×8 bits for the framebuffer alone would be 75KiB. Is he re-decoding the images from the SD card with every screen redraw? At 12MIPS with an 8-bit ALU? Is there a couple hundred K of RAM hiding somewhere? I can't find the BOM.

There are a lot of details on his blog. http://rossum.posterous.com/zork-for-the-microtouch explains that for the Zork Z-machine, he pages to the MicroSD card:

> Because the microtouch only has 2.5k of memory, all Z-machine memory is virtual, including its stack. 3 layers of caching of different granularities were required to get reasonable performance. A page file on the microSD card ("p.pge") acts as its backing store. By default the app loads "game.z5" game but will play most non v6 games: just change their name and copy to the microSD.

Doesn't explain how the hell he gets a high-resolution proportional font to draw on the display, though.

Upon further digging, it looks like the LCD controller must contain a framebuffer, with 16-bit TrueColor, so 150KiB of RAM. Take a look at https://github.com/rossumur/microtouch/blob/master/src/hardw.... From http://www.adafruit.com/datasheets/ILI9325.pdf, "ILI9325 is a 262,144-color one-chip SoC driver for a-TFT liquid crystal display with resolution of 240RGBx320 dots, comprising a 720-channel source driver, a 320-channel gate driver, 172,800 bytes RAM for graphic data of 240RGBx320 dots, and power supply circuit."

I wonder why he didn't page onto the framebuffer instead of the MicroSD card. It seems like kind of a waste to have 168¾KiB of RAM in a computer and only 2½KiB of it used by the CPU. The LCD driver actually uses 18-bit TrueColor; if you just used the low-order bit in the blue channel, you'd have an extra 9600 bytes. ☺

With that mystery resolved, the font is straightforward: it's a bunch of bitmaps in the program Flash which get blitted into graphics RAM to draw characters.

Reply on news.ycombinator.com