Comment by ChuckMcM | Hacker News Reader

Comment by ChuckMcM | Hacker News Reader

What is perhaps more interesting is the evolution and thinking about how it is done so easily on modern systems.

I think I've rewritten the basic 'cooked' mode probably a few times the latest being for a simulation of it on embedded systems[1]. The basic code is easy and it fails on the interesting edge cases (the most common one being if you auto CR/LF at the end of the screen few readline functions back up to the previous line.)

These days however if you have "lots" of memory and rendering a screen takes less time than rendering a single character did back in the day. You can just delete the character out of the buffer and re-render the entire screen. No need to count, your screen can do funky things like set your prompt different colors have tabs at an arbitrary number of spaces etc. Basically you can start at the top and render the entire 40 - 50 lines of text, poof in less an few mS. That was unthinkable when even at 9600 baud it took a couple of seconds to re-render the enter screen.

[1] https://github.com/ChuckM/stm32f469i/blob/master/demos/util/...

There was a Byte article around 1982 presenting a text editor in Z80 assembler that worked just that way: rerender the view on every keystroke. I was impressed -- "wow, it's that simple?" Of course, this was with memory-mapped textmode display, not a serial terminal, but it felt audacious to me to 'waste' that much computing for simplicity.

The article included the source code of the whole editor. That much assembly code in a magazine was unusual even then.

A lot of early text editors, particularly the tiny single-segment DOS ones, worked on the same principle. They didn't exhibit any flicker (most of the time --- anyone remember "CGA snow"?) because writing the same values to VRAM doesn't affect the screen display.

This one might've used a vertical-blank interrupt to time the refreshes -- it's what I think I remember, but I could easily be mixing it up with some other article around then, like Chris Crawford's series on Atari 800 graphics.

We once wrote a text editor as an exercise in FP, the key handler function had to return the area of the screen that needed repainting but also proof that this area was sufficient to catch all the changes, I think we were given some library to do the dirty work of actually drawing it to the screen so I don't know how nasty that was but our key handling code was quite simplistic!

Here's an example of an article that gives partial instructions to build a "TV Typewriter" from 1973:

http://www.swtpc.com/mholley/RadioElectronics/TV_Typewriter....

Jeez, after reading the articles today and yesterday, it was only after your comment that it dawned on me that you'd have to write a program to read keystrokes and, instead of moving a sprite in a game or something, it should show text.

It never clicked before this that terminals weren't just somehow "automatic". I now understand what terminal emulators do, thanks!

It took me a long time to realize that a VT100 was essentially a low-end microcomputer that just happened to have a "VT100 emulator" in ROM instead of having BASIC or a bootloader.

You can just delete the character out of the buffer and re-render the entire screen.

I've used apps which I suspect do this (not necessarily terminal emulators), and I'd strongly recommend against it; it may not be noticeable if your input rate isn't high, but if you lean on a key and let the keyboard auto-repeat, the rest of the screen/window, which hasn't changed, starts to noticeably flicker annoyingly.

These apps are getting more wrong than rendering too much on a single character change if there is visible flicker.

I wrote software that rendered its entire UI on any change into a DIB and blitted to the DC twenty years ago with no flicker

Maybe for some reason they clear the screen first before redrawing? That would certainly cause a flicker.

Not if they double buffer

In old school windows development, the mistake was normally to draw directly to the window's DC.

I could see that being especially troublesome in a system where you didn't have visibility into the repaint algorithm. Old skool UNIX used to start 'saving' damage events when they came in quickly so that it could dispatch them all at once. When your system did that you could lean on the delete (or backspace) key and it would start deleting characters and then just stop, and when you lifted the delete key it would suddenly have 15 - 20 whatever number of keys go away.

The other place it got annoying is when the system had a 'screen flash' when the input buffer was full. If your auto-repeat time was faster than the buffer drain time you would start getting flashes intentionally by the screen to tell you it was dropping input keys.

If you have one of the ST Micro 469i disco boards you can play with this using my 'term' demo in that repo. That implements a 25 x 80 "terminal" screen on the attached 800 x 480 screen. I've not yet connected it to micropython, but that is the intention.

> ... starts to noticeably flicker annoyingly

It's generally easy to solve problem with activating/implementing double buffering https://en.wikipedia.org/wiki/Multiple_buffering#Double_buff...

Reply on news.ycombinator.com