UNIX text console on a 480x320x1 LCD? good or bad? - Page 1
Forum section: electronics / general

author: DiTBho
author_rank: Super Contributor
timestamp: July 28, 2024, 12:44:16 pm
content: 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?

author: DiTBho
author_rank: Super Contributor
timestamp: July 28, 2024, 03:45:30 pm
content: with 8x16 font -> 480x320 -> it would be 60 colls x 20 rows

author: abeyer
author_rank: Frequent Contributor
timestamp: July 28, 2024, 10:20:20 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 28, 2024, 10:26:50 pm
content: Sure why not. I think less than 80 columns is a bit tough for any serious console use, but otherwise, why not.

author: DiTBho
author_rank: Super Contributor
timestamp: July 29, 2024, 03:53:10 am
content: Quote from: abeyer on July 28, 2024, 10:20:20 pmprobably, like making good use of the eInk of an obsolete Kindle PaperWhite

author: DiTBho
author_rank: Super Contributor
timestamp: July 29, 2024, 04:22:55 am
content: CGA debuted in 19818x16 font -> 320x200 -> 40x258x16 font -> 640x200 -> 80x25

author: DiTBho
author_rank: Super Contributor
timestamp: July 29, 2024, 04:23:43 am
content: 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.

author: Nominal Animal
author_rank: Super Contributor
timestamp: July 29, 2024, 07:08:10 am
content: Quote from: DiTBho on July 28, 2024, 12:44:16 pmWith 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 beingnanofor now).For editing source code, I'd check if I could find or construct a nice 6×8 font (startinghere). 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 itsoundslike 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 MIPIone, for example, would allow a 160×100 console, or 80×50 using 16×16 glyphs, and with fast enough update rate even X; andthis 3.5" 640×480 parallelone 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 innanofor 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.

author: DiTBho
author_rank: Super Contributor
timestamp: July 29, 2024, 11:10:53 am
content: Quote from: Nominal AnimalI also use GNU/Nano, sometimes VIMI 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 autorefreshAnd 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!

author: DiTBho
author_rank: Super Contributor
timestamp: July 29, 2024, 11:11:44 am
content: Quote from: Nominal AnimalI 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.Quote from: Nominal Animal on July 29, 2024, 07:08:10 amI 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/8bitif 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)

author: DiTBho
author_rank: Super Contributor
timestamp: July 29, 2024, 11:19:29 am
content: Quote from: Nominal Animal(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.

author: DiTBho
author_rank: Super Contributor
timestamp: July 29, 2024, 01:29:39 pm
content: meanwhile, I am using nano with different setupsCode:stty columns 60 rows 20Code:stty columns 80 rows 25

author: Nominal Animal
author_rank: Super Contributor
timestamp: July 29, 2024, 02:52:28 pm
content: 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.Quote from: DiTBho on July 29, 2024, 11:11:44 amMultipliers? 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.)Quote from: DiTBho on July 29, 2024, 11:11:44 amThat's why I included thelink 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?

author: ealex
author_rank: Frequent Contributor
timestamp: July 30, 2024, 05:28:40 am
content: I saw an interesting project some time ago:The code is over here:https://github.com/zephray/ELTermHe'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 .... )

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 30, 2024, 05:53:48 am
content: 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.

author: DiTBho
author_rank: Super Contributor
timestamp: July 30, 2024, 07:54:55 am
content: Quote from: SiliconWizard on July 30, 2024, 05:53:48 amI 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.

author: DiTBho
author_rank: Super Contributor
timestamp: July 30, 2024, 08:06:57 am
content: Quote from: Nominal Animal on July 29, 2024, 02:52:28 pmfor screen rotation { 0 90 180 270 }:DThe 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 ...

author: DiTBho
author_rank: Super Contributor
timestamp: July 30, 2024, 08:10:54 am
content: Quote from: ealex on July 30, 2024, 05:28:40 amVGA needs pixelclock ~ 25MhzSTN 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

author: DiTBho
author_rank: Super Contributor
timestamp: July 30, 2024, 08:23:54 am
content: I started writing C code on a laptop with a resolution of 1024x800 pixels, so 128x50 text terminalCode:stty columns 60 rows 20Yesterday 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.myEdknows 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).tmuxis 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

author: DiTBho
author_rank: Super Contributor
timestamp: July 30, 2024, 08:42:38 am
content: Quote from: Nominal Animal on July 29, 2024, 02:52:28 pmIn the current VHDL code there is a state machine that manages a very simple serial protocol.Code: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.

author: abeyer
author_rank: Frequent Contributor
timestamp: July 30, 2024, 05:53:29 pm
content: Quote from: DiTBho on July 30, 2024, 08:23:54 amThe luxury!40x24ish was pretty common on a lot of 8-bit machines, and was a common default even if better was available.Quote from: DiTBho on July 30, 2024, 08:23:54 amConsider 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.

author: DiTBho
author_rank: Super Contributor
timestamp: July 30, 2024, 09:55:54 pm
content: Quote from: abeyer on July 30, 2024, 05:53:29 pmI 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.

author: DiTBho
author_rank: Super Contributor
timestamp: July 30, 2024, 10:19:31 pm
content: Quote from: abeyer on July 30, 2024, 05:53:29 pmyup, it needs a different confI usually usetmuxto 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

author: Nominal Animal
author_rank: Super Contributor
timestamp: July 31, 2024, 01:27:54 pm
content: Quote from: DiTBho on July 30, 2024, 09:55:54 pmI 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...

author: DiTBho
author_rank: Super Contributor
timestamp: July 31, 2024, 01:37:41 pm
content: Quote from: Nominal Animal on July 31, 2024, 01:27:54 pmThe 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

author: Nominal Animal
author_rank: Super Contributor
timestamp: July 31, 2024, 02:41:09 pm
content: Quote from: DiTBho on July 31, 2024, 01:37:41 pmExactly, even on a 14" CRT display (with something like 274mm × 206mm active area).On a 17" MultiSync CRT (>85 Hz refresh rate, something like 335mm × 251mm active area) I could comfortably use 132×56; 160×60 was okay but refresh rates tended to be limited back when I used CRTs. Those correspond to 2.5mm × 4.5mm and 2.1mm × 4.2mm fonts. With utterly crisp LCDs and TFTs, much smaller fonts are readable –– I'd guess 2.0mm×2.7mm? ––, but at least I need to move them closer to my eyes for comfortable viewing.With 2.0mm×2.7mm fonts, 80×45 is 160mm × 120mm, for a diagonal size of 200mm ≃ 7.8". Thus, in theory, I think 7" - 8" displays with a resolution of 640×360 or higher, should work for terminal use. 420×320 is borderline.(Compare to e.g.BuyDisplay 7" IPS 800×480 ER-TFT070IPS-4, which takes 8 red data lines, 8 green data lines, 8 blue data lines, and HSYNC and VSYNC –– continuous refresh, that is –– and 3S9P backlight (max. about 9.3V at 180mA), currently priced at USD $17.40 or $25.10 with capacitive touch. Native 8×8 font would give 100×60, a nice 8×10 font 100×48, a nicer 8×12 font 100×40. With the FPC folded, the dimensions are 165mm × 100mm × 3.3mm. Note that the pixel pitch is 0.192mm × 0.178mm, or 96:89 ≃ 1.0787; non-square pixels, and thus not suitable for e.g. VGA emulation.)