UNIX text console on a 480x320x1 LCD? good or bad?

[DiTBho]

I was given a pair of very very thin, very light, 7" LCDs.

Nice LCDs, without neon or other backlighting, which use reflected light like in pocket graphing calculators.
I am so happy because they consume very little power.
The timing is also quite simple and the pixel clock is only 25Mhz, so even on the FPGA side ... you can use cheap FPGAs, at low frequency.

They only offer 480x320 pixels, with 1 bit color ...

... I wonder how good it would be as text console for LINUX and GNU/Linux.
Applications like Shell, text-editor { nano, vim, ... }, and the only things they do on the console.

What do you think?

[DiTBho]

with 8x16 font -> 480x320 -> it would be 60 colls x 20 rows

[abeyer]

People have done plenty of work on worse displays... it's certainly possible. Unless it happens to present a standard pc display interface, there's likely some software work to do to make your os treat it as a console, but it's not hard and there's plenty of existing examples for all the RPi lcd displays.

Not sure the low contrast and low resolution would be a display I'd personally want to spend much time on, though. I like good monochrome text screens, but would much rather have the high dpi and high contrast of something like eink.

[SiliconWizard]

Sure why not. I think less than 80 columns is a bit tough for any serious console use, but otherwise, why not.

[DiTBho]

Not sure the low contrast and low resolution would be a display I'd personally want to spend much time on, though. I like good monochrome text screens, but would much rather have the high dpi and high contrast of something like eink.

probably, like making good use of the eInk of an obsolete Kindle PaperWhite 

[DiTBho]

CGA debuted in 1981
8x16 font -> 320x200 -> 40x25
8x16 font -> 640x200 -> 80x25

[DiTBho]

I could spend hours on such a terminal, writing C code on tmux.
As I do now on my VT525, which supports { 25x80, 50x80, 50x132 }.
However, I usually only use it in 50x80 text mode.

[Nominal Animal]

They only offer 480x320 pixels, with 1 bit color

With a suitable controller/driver, I think that would work just absolutely fine.

The standard 8x8 font will give you a 60×40 console, which is plenty good for anything involving command line or writing scripts (using your preferred text-mode/curses-based editor; mine being nano for now).

For editing source code, I'd check if I could find or construct a nice 6×8 font (starting here).  Five horizontal pixels is sufficient for glyphs needed in programming (base ASCII set, Windows CP-437, ISO 8859 sets), but whether it is comfortable enough in practice considering it only increases the number of columns from 60 to 80, I'd need to test it in practice before deciding anything.

Depending on how much the display ghosts, you might wish to spend some time to see if you can support soft vertical scrolling (pixel-at-a-time, instead of full character line at a time) in the display controller, i.e. with zero host-side software support.  It can make a big difference in readability and usability, even though it sounds like a gimmick.  (This is because stable "rainfall" ghosting is preferable to the ghosting due to mixing two or more characters as happens when you scroll a full line at a time.)

That said, as you all well know I really like EastRising/BuyDisplay IPS modules, and one reason I've been looking at many microcontrollers with high-speed USB is to use them as portable consoles (with the help of a simple Linux userspace application or a kernel driver).  This 8" 800×1280 MIPI one, for example, would allow a 160×100 console, or 80×50 using 16×16 glyphs, and with fast enough update rate even X; and this 3.5" 640×480 parallel one would give tiny but "authentic" VGA vibes.  You see, I like my color emphasis when building stuff or looking at long logs (emphasizing important terms with ANSI color sequences), and the color-based syntax highlighting available in nano for a large number of syntaxes... but that's just me.

I once had a #9 (Number Nine) AGP graphics card that supported large Windows 95/98 desktops via hardware vertical scrolling.  (What the driver did, was provide a vertically extended frame buffer, and changed the start display address for each frame depending on the hardware cursor location, so that the cursor would "push" the viewed portion of the frame buffer with zero CPU load.)  Horizontal scrolling/panning was not useful for me.  Vertical scrolling/panning is very useful for command-line stuff (especially with pixel/soft scrolling), but not very useful with curses stuff, I think.  If you use a mouse or touchpad interface, in a GUI environment it works surprisingly well (as it requires zero software support), but I don't think it would work well with e.g. a touch interface.

[DiTBho]

The standard 8x8 font will give you a 60×40 console, which is plenty good for anything involving command line or writing scripts (using your preferred text-mode/curses-based editor; mine being nano for now)

I also use GNU/Nano, sometimes VIM 

I wrote my own text editor - namely "myEd" - which I would like to improve and use as the default editor, in the far future ...
It is written in myC, among the few interesting things, it really "understands" the myC syntax (so also C/89) and does the auto-formatting automatically.
What you have to do in C... with an external program, and then "re-load" your source.

The same "issue" exists with { nedit, geany, ... } all editors that use external programs for autoformatting.

myED has this function internally and automatically does the autorefresh
And I love this! You press CTRL+F+O, and it makes your source beautified, which is not only "aestetical", but also "functional" to better read your own code!

[DiTBho]

6x8 font

I wouldn't go below 8, because then it has to be implemented in VHDL, and if you use numbers that are not powers of two, you have to use real mul units rather than trivial shifts.

Aside from that, I wonder what the experience is like using a font smaller than 8x16 on a 7" LCD.

Depending on how much the display ghosts, you might wish to spend some time to see if you can support soft vertical scrolling (pixel-at-a-time, instead of full character line at a time) in the display controller, i.e. with zero host-side software support. 

I haven't powered up the two displays they gave me yet, they require a VEE of -22V and I still have to build the voltage pump.

The text editor I wrote, is made to support both vertical and horizontal scrolling, and since it is written in modules, every time there is a scroll event, it is possible to map it also in a specific hw request or serial protocol (like VT100/DEC extension).

I have already written a VDU for VGA. I think to re-use part of the VHDL code and adapt the PHY part, that is to replace the VGA module (and related timings), with an STN module (and related timings).

At the moment I have not implemented any scrolling yet.
works in this way:

• you send a "goHome()" command, and the cursor goes back to (row,col)=(1,1)
• you send a "go(irow,icol)" command, and the cursor moves to (row,col)=(irow,icol)
• you send a char/8bit
  if row<row_max, it writes it to the cell (row,col) and increments row++
  if col<col_max, it writes it to the cell (1,col+1)
  otherwise it writes it to the cell (1,1) /* yes, it's a bug */
  
• you send a triplet { char, row, col }, it writes it to the cell (col, row)

[DiTBho]

You see, I like my color emphasis when building stuff or looking at long logs (emphasizing important terms with ANSI color sequences), and the color-based syntax highlighting available in nano for a large number of syntaxes... but that's just me.

(Casio FX-9860GIII)

I don't tend to use color, and even on the Casio FX-9860GIII scientific calculator I prefer black and white LCD.
Supporting colors would require more memory (BRAM), and more code, as well as a different type of LCD.

But, we will see ... I could also use a laptop 1024x800 color 14" LCD if really needed, but I really don't want to have to use a speedgrade -1 FPGA, 70Mhz pixelclock and then ~500Mhz for the LVDS part or an external serializer.

It would add too much overall complexity to a project that I would like to be as simple as possible.

Of course, then... there are compromises.

[DiTBho]

meanwhile, I am using nano with different setups

Code: [Select]

stty columns 60 rows 20


Code: [Select]

stty columns 80 rows 25


[Nominal Animal]

At 7" and 480:320 ratio, the visible area should be about 148mm wide and 97mm tall, and the pixel pitch about 0.308mm ≃ 82 DPI.

I wouldn't go below 8, because then it has to be implemented in VHDL, and if you use numbers that are not powers of two, you have to use real mul units rather than trivial shifts.

Multipliers? Whatever for?  You should be using counters and additions in the display generator, not muls.  A state machine!

Consider using a framebuffer rotated 90 degrees, so that you have a 320×480 and 8×6 fonts instead.  It is quite possible that the native refresh order is that anyway – it is so in most EastRising/BuyDisplay displays, for example, although most controllers allow reprogramming it.  This fixes the character height at 8 pixels, and thus 40 rows.  However, the scanning is from left to right, so you could support both 6- and 8-pixel (wide) fonts, the same way other devices support multiple font heights.

The video display controller character buffer I'd make 64×64, and use 8×8 "font" storage, for a total of 4096 + 2048 = 6144 bytes of RAM for the two.  Your display generator should be a state machine, where your character lookup is some dozen cycles ahead of the font data lookup, which is three or four cycles ahead of the output pixel scanner.  If you use 8×8 font storage, even the character buffer to font storage lookup is just multiplying by 8 either way.  The two extra bytes could be used for character set type information for example.

If you have plenty of RAM, I'd warmly suggest considering more bits per the character, and thus larger character set.  Unused bits in the character buffer might come in handy; for example, if the character buffer is 64×64 with 16-bit entries, but you only support 256/512/1024/2048/4096 distinct fonts (by only using 8/9/10/11/12 low bits of the character buffer values).  Then, the two "extra" bytes in the 8×8 storage for 6×8 fonts could be used for unicode glyph type mask, and you could support UTF-8 (especially with a bit of help from userspace, reprogramming say the upper half of the character set depending on the glyphs (not just characters, but character combinations) needed to display at any point in time).  If there is any ghosting, smooth scrolling (a pixel per frame) will yield more readable results than displaying a static frame for eight frames and then moving by an entire character, because the way the two characters mix in the latter case.  (But ghosting is nasty, and I suspect will be the deciding factor with your displays.)

I wonder what the experience is like using a font smaller than 8x16 on a 7" LCD.

That's why I included the link to a starting point: it includes several bitmap fonts on a web page where you can test how they look.  You can screengrab bitmap images to be displayed on your LCD as soon as you get a picture generated.

To make a good decision, you have to look at the real-world display displaying real-world contents.

As to the ANSI escape code parser, having display buffer width be 64 (characters) means you need only one shift and one add to obtain the character buffer address for any screen coordinates... Row down is adding 64, and row up is substracting 64 from the current character buffer offset.  If you use only 12 character buffer address bits, you get a very useful rollover at the boundaries, too: if you ever decide to make character-mode games (with custom character set), you can make very smooth endless horizontal and vertical scrolling with almost no "CPU" overhead – you need to replace less than 11 characters on average per pixel scrolled.  Even so, I'd fix the character buffer to a fixed 64×64 size.

If the FPGA has the grunt, or it only does the display generation, and you have enough memory for a 19200-byte framebuffer, I'd definitely use a two-plane approach, where you have a character buffer on top and a graphics buffer at the bottom, with the actual displayed value looked up from a 2×2-bit configuration register.  That way, enabling only one or the other is just manipulating that 2×2-bit config register; with AND/OR/XOR/NAND/etc. modes corresponding to different register values.

I am firmly of the opinion that this kind of device should have a (re)programmable part; I wouldn't implement it all in hard FPGA.  Actually, I'd probably only implement the display scanning/generator part in FPGA, and leave the display buffer manipulation to something written in a higher-level programming language.  C would be optimal, but assembly would be okay too.  I personally would not want to write an ANSI escape code parser in VHDL or similar languages.  Perhaps a small softcore?

[ealex]

I saw an interesting project some time ago:


The code is over here: https://github.com/zephray/ELTerm

He's using the RP2040 PIO's to generate the HSYNC / VSYNC / DATA (2 bits in his case) / CLK.
I'll try adapting his code to run on a 320x256 panel - lower CLK speed and just 1 data lane - it might also work for a bare LCD ( had one around, but broke it .... )

[SiliconWizard]

Well, as a side project, I have this on my list - implementing a terminal on a RP2040, generating video with the PIO. It has been done numerous times. My challenge was to make it output Full HD VGA video, and nice fonts.
While generating Full HD video is possible on a RP2040, there wouldn't be enough processing time to generate the characters in real-time, even overclocking it, and not enough RAM to implement a full framebuffer. So, that doesn't look feasible either way. But 1280x1024 should be. Would still require pretty optimized code. Fun stuff though.

[DiTBho]

implementing a terminal on a RP2040

I think similar approaches are quite masochistic, they only make sense because RP2040 is cheap (<5 USD) and offers two cores, but it stands on it own two feet like a dead man walking on tiptoe on the edge of collapse... touch a single user-flag, pragma, or usual C-shit, and you risk the project exploding into something that will then be a serious pain to debug, as it's highly dependent on how optimized the code is.

[DiTBho]

Multipliers? Whatever for?
You should be using counters and additions in the display generator, not muls.  A state machine!

for screen rotation { 0 90 180 270 }:D

The current VHDL code works, and it doesn't use any mul, only shifts, but only as long as the font is { 8x8, 8x16, ... }
I think it can be simplified, as you suggested, but it's a step i still have to do ...

[DiTBho]

He's using the RP2040 PIO's to generate the HSYNC / VSYNC / DATA (2 bits in his case) / CLK.
I'll try adapting his code to run on a 320x256 panel - lower CLK speed and just 1 data lane - it might also work for a bare LCD ( had one around, but broke it .... )

VGA needs pixelclock ~ 25Mhz
STN timings needs less, so STN LCDs should work.

I think it's also the practical limit, without having to strictly depend on optimization...
try to imagine if you had to generate pixel clocks of 60Mhz... X___X

[DiTBho]

I started writing C code on a laptop with a resolution of 1024x800 pixels, so 128x50 text terminal

Code: [Select]

stty columns 60 rows 20
Yesterday I tried to edit some code using the 60x20 configuration and I have to say it's a bit narrow for what I'm used to.

myEd knows where a myC function starts and can show a pop-up menu to let you jump to its body-definition.

I mean, instead of having to show a list of C-functions on the left, like Geany does.
Which is great and nice, but only when you have a large screen (>1024 pixels).

tmux is also problematic if you try to split as I usually do.

ummm, I have uncomfortable feelings, but I'll have to get used to it for a while and see how it goes in the long run 

[DiTBho]

I am firmly of the opinion that this kind of device should have a (re)programmable part; I wouldn't implement it all in hard FPGA.  Actually, I'd probably only implement the display scanning/generator part in FPGA, and leave the display buffer manipulation to something written in a higher-level programming language.  C would be optimal, but assembly would be okay too.  I personally would not want to write an ANSI escape code parser in VHDL or similar languages.  Perhaps a small softcore?

In the current VHDL code there is a state machine that manages a very simple serial protocol.

Code: [Select]

                                    VDU protocol

_ascii8_  __________ input __________  _____ reply _____
76543210  params  byte1  byte2  byte3  byte0 byte1 byte2    meaning
--------------------------------------------------------------------------------------
0xxxxxxx      0     _      _      _      _     _     _      char_put_imm(char)
00001010      0     _      _      _      _     _     _      cursor_set_to_line_next()
00001101      0     _      _      _      _     _     _      cursor_set_to_line_begin()
--------------------------------------------------------------------------------------
10000001      0     _      _      _      _     _     _      cursor_home()
10000010      2    col    row     _      _     _     _      cursor_set(col,row)
10000011      3    col    row    char    _     _     _      char_put(col,row,char)
10000100      1     n      _      _      _     _     _      scroll_v_inc(n)
10000101      1     n      _      _      _     _     _      scroll_v_dec(n)
10000110      1     n      _      _      _     _     _      scroll_h_inc(n)
10000111      1     n      _      _      _     _     _      scroll_h_dec(n)
10001000      0     _      _      _      _     _     _      scroll_reset()
---------------------------------------------------------------------------------------
10010001      0     _      _      _     cols  rows   _      info_cols_rows_get()
10010010      0     _      _      _     ver   rev    _      info_ver_get()
10010011      0     _      _      _     col   row    _      cursor_get()

I plan to use a very small FPGA and to completely exhaust the BRAM for the text-area buffer.

You cannot change the font-rom at the moment. It's built-in only, but I think I will add this possibility.

I have a MIPS32r2 softcore ready(1), it doesn't take up too many resources and the performance is not too bad @ 25Mhz (multi-cycle approach, it is not pipelined), but ... it needs an FPGA with more resources than the small one (SpartanII gen) I would like to use.

well, we'll see ... 



(1)
RTL: tested and verified VHDL code.
toolchain: myC can generate machine-code for it.
firmware: working MIPS-mon, able to load and execute SREC stuff from the serial.

[abeyer]

I started writing C code on a laptop with a resolution of 1024x800 pixels, so 128x50 text terminal

The luxury!  40x24ish was pretty common on a lot of 8-bit machines, and was a common default even if better was available.

tmux is also problematic if you try to split as I usually do.

Consider using tmux windows more than panes on small screens. I used to have a separate tmux.conf specifically for non-pane use that had more/optimized keybindings for quickly swapping and managing windows, though haven't used it in a while. Also worth turning the status bar off by default and adding a keybinding to display it when desired.

[DiTBho]

The luxury! 40x24ish was pretty common on a lot of 8-bit machines, and was a common default even if better was available.

I started C-programming in 2001 on GNU/Linux 2.4.*, installed on a second hand thinkpad PentiumII laptop.
Gentoo didn't exist yet, I had Corel Linux in front of me.
I was a student at university, and I had to take some computer science exams which also required me to work on personal projects.
The laptop wasn't even mine but belonged to a friend who lent it to me.

Before that, in the 90s, I programmed in Turbo Pascal on a amd386-DX2@40Mhz DOS-v5.0 PC. I remember it was VGA, 640x480.

But, in my first paid job, in 2004, I remember I used a DEC VT525, which I recently purchased.
It supports { 80x25, 80x50, 132x50 }. Mine was operating in 132x50 on a big an heavy CRT.

[DiTBho]

Consider using tmux windows more than panes on small screens. I used to have a separate tmux.conf specifically for non-pane use that had more/optimized keybindings for quickly swapping and managing windows, though haven't used it in a while. Also worth turning the status bar off by default and adding a keybinding to display it when desired.

yup, it needs a different conf 

I usually use tmux to have two panes, one on top of the other, edit a file with myED on the bottom, compile it, run it, and debug it roughly with printf
(serius debugging need gdb/ddd + ICE, which is x11 job, because ddd works better on X11 with a mouse)

or, I use two panes, one on the right, one on the left.

myED has the ability to communicate with a "CodeViewer", a piece of the same "myED" project that recognizes the functions defined in the currently open source file, and shows an ordered list, which you can scroll with the arrow keys. If you press "B" on a function name, "CodeViewer" sends, over the network, a "goto line" command to myEd, and so on the left you see the body of the function, which you can inspect, and edit.

If you press "D", it opens a pop-up and shows only the prototype instead. Press enter, and it closes it.

This thing of having one pane next to the other, does NOT work well with less than 100 columns.

So I implemented inside myEd a pop up menu that shows a reduced, but still scrollable, list and does the same thing: if you press "B" on an item, it takes you to its body, and if you press "D", it shows you the prototype.

It somehow works still, but it's less efficient and less comfortable 

[Nominal Animal]

Before that, in the 90s, I programmed in Turbo Pascal on a amd386-DX2@40Mhz DOS-v5.0 PC. I remember it was VGA, 640x480.

I used Turbo Pascal on a Hyundai 286 (with a horribly loud fan) and MS-DOS 3.21 with an ATi EGA Wonder graphics card in late 80s to early 90s, with a 14" NEC MultiSync monitor...

[DiTBho]

Before that, in the 90s, I programmed in Turbo Pascal on a amd386-DX2@40Mhz DOS-v5.0 PC. I remember it was VGA, 640x480.

I used Turbo Pascal on a Hyundai 286 (with a horribly loud fan) and MS-DOS 3.21 with an ATi EGA Wonder graphics card in late 80s to early 90s, with a 14" NEC MultiSync monitor...

The IDE made by Borland C and Pascal, and even the one made for Turbo Vision, were not that bad on a VGA screen, but with 80 columns.
That was/is the point