The plausibility of an E-Ink Display

[Failbert]

Very interesting and in a way, inspiring bit of info there!

Or would just plain text be good?

As for that, I think all us roguelike enthusiasts agree that 'yes'

 

[levi]

Yes, he does seem to be storing character entries in SRAM then mapping them into a series out output bytes via an LUT, but VGA itself is still very much an analogue interface. It takes to top line of all of the characters in the top row before moving down to the second row and so on. I don't know off the top of my head what interfaces e-paper screens take, but I suspect they're digital, but probably expect a bitmap to display. Otherwise they'd need to support something like postscript (which we used to use to make printers layout pages like we wanted, using ASCII plus control sequences), and I might be behind the times, but I still class a postscript implementation as being quite a heavyweight kind of a thing (but then I remember having to upgrade printers with whopping - count 'em - 4MB RAM sticks to make them work better).

The thing you're thinking of is serial comms to old terminals like DECs VT220 series - that's ASCII+ANSI control codes, and kind of depends on a monospaced font, which you don't want on an e-paper screen normally.

 

[JustSimon]

@Grench Sadly, those displays don't speak VT220 or anything of the sort.

I've looked at > 20 datasheets of different eInk displays and almost all of thrm have one chip that speaks SPI or I2C and one chip that controls the pixels on the screen.
So when you write to it, the first chip translates your I2C instruction into a pixel modification and the second chip then toggles that pixel. Some have one chip that does both.
There are different ranges of commands you can execute. I have seen a display that allowed you to send multiple pixels in one I2C 'command' and some basic shapes...
But there are tons of displays out there and most of them only speak SPI natively, so thats another issue.
There are I2C-to-SPI translator boards, but I' prefer not to have any extra components.

My current plan is to just attatch the screen to the I2C bus on the circuit board of the screen and then write a program that keeps the state of the screen in mind and does a little optimisation (not setting pixels to white that are already white and grouping shapes where possible)

 

[klapse]

Otherwise they'd need to support something like postscript (which we used to use to make printers layout pages like we wanted, using ASCII plus control sequences)...

I once did some postscript programming for scientific publications, and also wrote display postscript screensavers on the NeXTstation.

Remember the melting screen from Doom? I did that before iD, on the NeXT.

[ON-TOPIC]
Surprised nobody mentioned 'Memory-TFT' from Sharp. Very competitive to e-ink iirc: Low power, cheap mfgr, faster switching, colors possible, sunlight readability.

 

[Kev2442]

the screen was handed a line number, position and the letter/character to populate there

If I'm correct, this is close to the typical dot-matrix LCD display territory there. Here :

 

[spud42]

Utilizes the extremely common HD44780 parallel interface chipset. Interface code is freely available.

common as mud those displays. i remember back in 1998/99 we in the car MP3 scene used these to display what winamp was doing. very easily driven from a paralell port. 3 years or more before ipods came about. site got bought by a company who use the name to sell their products now and have shut down the forums last year... so much history and information lost..