VT100/ANSI terminal emulation via OSWRCH

discussion of beeb/electron applications, languages, utils and educational s/w
SteveF
Posts: 438
Joined: Fri Aug 28, 2015 8:34 pm

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Wed Aug 23, 2017 9:36 pm

So here's a rather hacky prototype of an idea I had for supporting ANSI background colour codes, not just the foreground colour codes. I'd be interested to hear what you (Elminster, when he's back from holiday, and anyone else who's following along) have to say about it.

Up until now, I've been treating the VideoNuLA extended attribute text mode as though it supports one background colour and 8 foreground colours. VideoNuLA is actually more capable than that; we can have 8 pairs of (foreground, background) colours, and any character can use any one of those 8 colour pairs. So we can have, say:
  • Pair 0 - white on black
  • Pair 1 - red on yellow
  • Pair 2 - yellow on black
  • Pair 3 - magenta on red
  • Pair 4 - magenta on blue
  • Pair 5 - black on magenta
  • Pair 6 - yellow on blue
  • Pair 7 - cyan on magenta
and display characters using all those colour pairs simultaneously. (I'm assuming we're looking to induce eyestrain and headaches. :-) )

The basic ANSI colour codes allow the running program to choose from the foreground and background independently from the 8 primary colours, so there are 64 pairs possible and the 8 pairs we have available aren't sufficient to handle this.

What I've tried to implement is a scheme where we dynamically change our 8 colour pairs to match what the running program has requested. So we start off with a blank screen and the default foreground of white and background of black. The program prints an 'A' character. STEM says to itself "I need a colour pair for 'white on black' - OK, let me redefine pair 0 as that, and use colour pair 0 to print this A".

The program then selects red foreground and yellow background and prints a 'B'. STEM says "OK, this is different. I need a colour pair for 'red on yellow'. Pair 0 is in use, let me redefine pair 1 as red-on-yellow, and use colour pair 1 to print this B.

We remember the pairs we've already allocated, so if the program then switches back to white-on-black text and prints a "C", we will use pair 0 for it rather than redefining pair 2 to be white-on-black. [1]

Everything's peachy until the program uses its ninth unique colour pair - let's say this is white-on-blue. At that point, STEM needs to allocate one of the 8 pairs to it, and they're all used. So it has no choice but to re-use one pair as white-on-blue - it will choose pair 0 (the oldest pair), causing the white-on-black text printed earlier using pair 0 to suddenly turn white-on-blue. We re-use the oldest pair as in an ideal world, all the text written using it has already disappeared fro the screen and the redefinitions isn't noticeable, but this isn't guaranteed, of course. We are also hoping that the program is showing some restraint in its use of foreground/background colour combinations and doesn't need more than 8 different unique pairs on the screen simultaneously. (I could imagine this being the case if using Elminster's telnet to connect to a Linux machine and doing things like ls --color, for example.)

I've attached a copy of the prototype and there's a new test program T.VNULA2 which prints text in random combinations of foreground and background colours, pausing for you to press RETURN after each one. Ignoring lucky cases where the same colour pair occurs multiple times in relatively close succession, you can see that after the first eight lines, colours get redefined and so the older lines suddenly appear using different colours. Here's a screenshot of a sample run (courtesy of Kieran's b-em VideoNuLA emulation):
stem-videonula-background-colour.png

You can see that the last eight lines (16-23) appear in the correct colours, whereas the previous lines don't match their own descriptions (e.g. line 0 says it's white on black, but it's actually red on white; it was white on black when it was first displayed).

A side issue here is that this prototype doesn't do anything to avoid the not-yet-written-to character cells on the screen (which are using colour pair 0) from changing when colour pair 0 gets redefined. I can think of various possibilities here (perhaps colour pair 0 is permanently reserved for white-on-black), but I think this is less important than deciding if this basic approach is desirable.

Because the extended attribute mode always displays the rightmost column of each character cell using the background colour of cell 0, changing the background colour doesn't give a contiguous horizontal background colour - you can see in the screenshot that there's a white vertical line between each character cell on every line. This can't be avoided (although the colour of that line doesn't have to be white; that's just how it happens to be in the example) in the 8 colour mode; the 4 colour mode wouldn't suffer from this (but STEM doesn't currently support setting background colours at all in 4 colour mode). [Edited to add: does a real VideoNuLA behave like this, or is this an emulation bug? I have no reason to believe it's a bug but I thought I'd ask. I could see this alternatively using the background colour of the pair for the character cell itself rather than the background colour for colour pair 0.]

Note that if the program running under STEM doesn't use any background colour codes, this approach is more-or-less equivalent to how STEM behaved before, as the 8 colour pairs we have are always enough without any redefinition being needed. (However, foreground colour 0 was previously treated as red, whereas it's now black and therefore is not very useful if you aren't changing the background colour.)

[1] There is a flaw in the implementation of this in the prototype, as I don't have a proper least-recently-used list, but it does more or less work. The effect of this is that sometimes a colour pair which was used quite recently will be redefined earlier than it should be.
Attachments
stem-0.03x.06.zip
(84.57 KiB) Downloaded 5 times

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: VT100/ANSI terminal emulation via OSWRCH

Postby Elminster » Tue Sep 05, 2017 9:55 am

I am not sure I can cope with an message that long and complex when back from holiday. I may have to soak my brain in rocket fuel for a few days first.

SteveF
Posts: 438
Joined: Fri Aug 28, 2015 8:34 pm

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Tue Sep 05, 2017 10:31 am

Welcome back! :-)

RobC
Posts: 1774
Joined: Sat Sep 01, 2007 9:41 pm

Re: VT100/ANSI terminal emulation via OSWRCH

Postby RobC » Wed Sep 06, 2017 6:36 am

SteveF wrote:Because the extended attribute mode always displays the rightmost column of each character cell using the background colour of cell 0, changing the background colour doesn't give a contiguous horizontal background colour - you can see in the screenshot that there's a white vertical line between each character cell on every line. This can't be avoided (although the colour of that line doesn't have to be white; that's just how it happens to be in the example) in the 8 colour mode; the 4 colour mode wouldn't suffer from this (but STEM doesn't currently support setting background colours at all in 4 colour mode). [Edited to add: does a real VideoNuLA behave like this, or is this an emulation bug? I have no reason to believe it's a bug but I thought I'd ask. I could see this alternatively using the background colour of the pair for the character cell itself rather than the background colour for colour pair 0.]

Sorry for missing this Steve - I've been working on a new demo and haven't kept up with the threads.

The emulation is correct and matches what a real board does. The video ULA has no real context to the data it is seeing: in the 3-bit attribute modes, it simply gets 5 bits of pixel data and doesn't know how the foreground and background colours have been set by the OS. So, for example, it doesn't know whether "11100" is 3 bits of foreground and 2 bits of background or 3 bits of background and two bits of foreground. So, I set the rightmost bit to a constant value and chose '0'.

SteveF
Posts: 438
Joined: Fri Aug 28, 2015 8:34 pm

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Wed Sep 06, 2017 6:52 pm

Thanks Rob, good to know the emulator's right here.

I'm afraid I don't understand your explanation, so just for my general education can I ask for some more details? I know nothing about hardware, but I would have imagined that for each 8-bit byte %abcdefgh of video data in 3-bit attribute mode, VideoNuLA would do something like this:
  • Use %fgh to determine the physical colour numbers F and B for the foreground and background of this byte (entries %fgh0 and %fgh1 in the 16-entry palette table)
  • Display six pixels %abcde0 - if a bit is 1 that pixel is in physical colour F, if 0 that pixel is in physical colour B
That doesn't seem to be the case, however - the always-0 bit is not shown using the byte's background colour B, but using physical colour 0. So in fact one 8-bit byte can generate up to three physical colours on the display in 3-bit attribute mode. Is that right?

(Incidentally, I see an error in what I wrote that you quoted. I should have written "Because the extended attribute mode always displays the rightmost column of each character cell using the background colour of cell colour pair 0". Sorry for any confusion.)

RobC
Posts: 1774
Joined: Sat Sep 01, 2007 9:41 pm

Re: VT100/ANSI terminal emulation via OSWRCH

Postby RobC » Fri Sep 08, 2017 8:22 am

Hi Steve,

Sorry for the late reply - things have been a bit manic and I've only just seen your post. (The start of a new school term is never a good time in our house! :( )

I have to apologise as I completely misunderstood your earlier post and now understand what you were saying. I've just compared a short test program on my machine and on B-Em. In short, the emulator implementation is wrong as the rightmost bit should be set to the background colour for the current pair (as chosen by the attribute bits) and not to the background colour for pair 0.

The 3 attribute bits select which pair of logical colours to use. These are then converted to physical colours by the standard palette at FE21 (written to in the same way as you would for mode 2). The physical colours are then converted to analogue/RGB colours by the extended palette at FE23.

Sorry again for any confusion caused and for the lateness of my reply.

SteveF
Posts: 438
Joined: Fri Aug 28, 2015 8:34 pm

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Fri Sep 08, 2017 12:10 pm

Thanks Rob - I get a tiny glimpse of the associated chaos from watching my niece start school :-), so I appreciate you coming back to me at all...

This is good news, as it means that text with multiple background colours won't have to have that stripy appearance on real hardware. That doesn't mean the approach I've proposed is necessarily a good one for STEM, but it's one less drawback.

Cheers.

Steve

PS No rush, but do still you have that short test program? If so could you please post it over in the thread about emulator support for b-em (viewtopic.php?f=4&t=13464) before you lose it?

RobC
Posts: 1774
Joined: Sat Sep 01, 2007 9:41 pm

Re: VT100/ANSI terminal emulation via OSWRCH

Postby RobC » Fri Sep 08, 2017 4:40 pm

Done.

SteveF
Posts: 438
Joined: Fri Aug 28, 2015 8:34 pm

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Fri Sep 08, 2017 5:46 pm

Great, thanks!

User avatar
kieranhj
Posts: 503
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: VT100/ANSI terminal emulation via OSWRCH

Postby kieranhj » Wed Sep 13, 2017 1:26 pm

SteveF wrote:PS No rush, but do still you have that short test program? If so could you please post it over in the thread about emulator support for b-em (viewtopic.php?f=4&t=13464) before you lose it?

I've posted a fix to the b-em implementation over on the thread, if you'd like to try it?

SteveF
Posts: 438
Joined: Fri Aug 28, 2015 8:34 pm

Re: VT100/ANSI terminal emulation via OSWRCH

Postby SteveF » Wed Sep 13, 2017 9:16 pm

Thanks Kieran, that works a treat. Here's a screenshot of my test program running under the new emulator - there are no longer ugly background-coloured gaps between the characters.
stem-videonula-background-colour-2.png

It's still the case that only the last few lines on that screenshot are "truthful" about their foreground/background colours, because that's down to the fundamental limit of only 8 colour pairs being available as described at length (if not necessarily clearly :-) ) in my post above - this is not an emulator bug, just to be completely clear.

User avatar
kieranhj
Posts: 503
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: VT100/ANSI terminal emulation via OSWRCH

Postby kieranhj » Thu Sep 14, 2017 9:51 am

SteveF wrote:It's still the case that only the last few lines on that screenshot are "truthful" about their foreground/background colours, because that's down to the fundamental limit of only 8 colour pairs being available as described at length (if not necessarily clearly :-) ) in my post above - this is not an emulator bug, just to be completely clear.

Good to hear this is working for you now. I was wondering about the mismatch of text vs colours in the screenshot - you had me worried for a moment!!


Return to “software: other”

Who is online

Users browsing this forum: No registered users and 5 guests