Commander X16 Petscii control codes question...

codewar65

New Member
Sep 25, 2019
26
13
3
I haven't seen anything about accessing background text colors via Petscii. Are there planned codes for setting character background colors?

I suggest opting one character code (maybe $8F) to set background as the current foreground color, something like they do with Teletext colors (new background 0x89), with another code to reset the background to the screen background color (maybe $0F), something like they do with ANSI escape sequences (CSI '0' 'm').

I am currently reworking a HTML5/JS websocketed telnet client of mine for BBS's that supports petscii, ansi-bbs, atascii, teletext and would like to support background colors for Commander X16 themed boards.
 
Last edited:
  • Like
Reactions: BruceMcF
May 22, 2019
486
250
43
The ability to set background colors with control codes doesn't exist yet, as far as I know. An escape code is one way to do it, but maybe getting an actual COLOR command makes more sense.

For now, we can use a POKE command to change the color attribute.
 

codewar65

New Member
Sep 25, 2019
26
13
3
I'd love to see fewer PETSCII ctrl myself but the standard has been set with the Pet/VIC20/C64/128.

ASCII control codes are 0-31 (C0), 128-159 (C1); and PETSCII follows them in some aspects (in that they are control charactes), allowing a new code on the C0/C1 control space that sets/resets background color fits existing Commodore atmosphere.

I do see that ESC ($1B) is open in PETSCII, maybe adopting ANSI sequences for character attributes would be easier? LOL

 
Last edited:
  • Like
Reactions: Panda

codewar65

New Member
Sep 25, 2019
26
13
3
The ability to set background colors with control codes doesn't exist yet, as far as I know. An escape code is one way to do it, but maybe getting an actual COLOR command makes more sense.

For now, we can use a POKE command to change the color attribute.
Poke does not translate over telecom lines. We'll need a new PETSCII code.
 
Last edited:

mobluse

Member
Sep 20, 2019
35
15
8
I agree that one should have the possibility to change background colors using control codes. $0F and $8F are already taken to switch to ISO-mode (ISO8859-15), and back to PETSCII-UC, see Commander X16 Programmer's Reference Guide.

One idea I had was to use one control character as a prefix to tell that the next control character sets the background color, but your method of having a control character for setting the current background color to the current foreground color also works. I don't think there exists a screen background color, but one can change the background color back to anything with your scheme anyway, since one can change the current foreground color. There is a current background color, that is set by using e.g. POKE $0286, $BF, but that also sets the foreground color (in this case to $0F). Another idea is to indicate background color by sending two color characters, first the background color, then the foreground color, since no sane programmer would want send two color codes directly after each other. This has the advantage that no extra control codes are used

I don't think you can send CSI (i.e. ESC [) to the screen with print since it will ignore Escape, but print the [ and the following characters. You could change Escape so that the screen ignored the next character after an Esc, but ignored one more if the next character is b or c, and two more if the next character is Y (that would support VT52 with Atari extensions). That would mean you could POKE and then send any VT52 Escape sequence without destroying the screen.

I have a similar program already: https://github.com/mobluse/x16-petscii2utf8 and it is possible to type in x16emu and it shows on both the screen and the terminal, and with a hacked version of x16emu, you can type in the terminal and it shows on the screen, but that hack made the emulator very slow because it had to poll stdin.
 
Last edited:
  • Like
Reactions: codewar65

Panda

New Member
I haven't seen anything about accessing background text colors via Petscii. Are there planned codes for setting character background colors?

I suggest opting one character code (maybe $8F) to set background as the current foreground color, something like they do with Teletext colors (new background 0x89), with another code to reset the background to the screen background color (maybe $0F), something like they do with ANSI escape sequences (CSI '0' 'm').

I am currently reworking a HTML5/JS websocketed telnet client of mine for BBS's that supports petscii, ansi-bbs, atascii, teletext and would like to support background colors for Commander X16 themed boards.
What do other systems do? What does an ASCII based system do to send background colours? What control chracters and escape characters are used?
 

mobluse

Member
Sep 20, 2019
35
15
8
I think most CP/M programs assume a VT52 terminal, or they hack directly to the screen memory (but that was not standardized). MS-DOS programs used a (slightly buggy) subset of VT100 called ANSI.sys, or hacked the screen memory (CGA). Commodore used the PETSCII control codes, or hacked the screen memory. CX16 programs so far uses PETSCII control codes, or hack the video RAM, but it would be good if VT52 Escape sequences with Atari extensions were at least ignored, or even better, supported. One could begin by supporting the VT52 codes that are not already supported by PETSCII control codes. I believe VT100 terminals have a VT52 compatibility mode, so if you want full VT100/xterm support you still have to support VT52, I believe. I have tested, and xterm & PuTTY have VT52 modes, but I could only get colors to work in PuTTY, since it seems to have Atari extensions.
 
Last edited:
  • Like
Reactions: codewar65

mobluse

Member
Sep 20, 2019
35
15
8
There is an old CP/M computer, Amstrad CPC 6128, that supported VT52 Escape sequences with Amstrad extensions, see chapter 7 page 48 in AMSTRAD CPC6128 USER INSTRUCTIONS (page 359/520 in the pdf). A problem with both Atari and Amstrad extensions is that at least one Escape code collide with VT102: ESC c. On Atari and Amstrad it changes the background color, but on VT102/Xterm it resets the terminal.
 
  • Like
Reactions: codewar65

codewar65

New Member
Sep 25, 2019
26
13
3
I agree that one should have the possibility to change background colors using control codes. $0F and $8F are already taken to switch to ISO-mode (ISO8859-15), and back to PETSCII-UC, see Commander X16 Programmer's Reference Guide.
Well $02 and $82 are available. Maybe $02 to set background color from current foreground color, and $82 to reset? Not sure if a reset would even be needed as there is no reset for foreground color, so just a single code would be helpful.

I wouldn't worry too much about setting screen background or border colors via petscii, as this normally handled by the software displaying the petscii (in my case, a terminal, which is typically black for both), but X16 petscii art would benefit greatly with a text background code.

The code would just read the value at $0286, and shift the lower nibble to the high nibble. The reset could just set the high nibble back to $0. Assuming $0286 is still the location for the current color for output, and this is how text color will be handled in the KERNAL.

update: Just looked in the KERNAL and there is a place for character color. Only the lower nibble is used currently. line 105 in declare.s. Maybe this could be expanded to use the full byte for color. Could also work in 256 color mode by shift low nibble to high, with a handy look up chart for developers to get the desired color.

Another problem is a mechanism to determine black background color from transparent in 16 color text mode (show screen background through; which is currently default).

Also noticed that the 256 color palette has some repeat colors. $00 = $10 and $01 = $1F. Maybe spread the grays out more in the $10-$1F range...

 
Last edited:

mobluse

Member
Sep 20, 2019
35
15
8
I don't believe the screen has an inherent background color that you can reset to. When you clear the screen or scroll it fills with spaces and they have the current background color. There is also no frame color yet, but I think they should have because on some screens there will be borders that are now black, but could have color. In order to change background color by copying foreground color using a control character one would typically have to send three characters, since one doesn't want to have the same bgcolor and fgcolor:
<bgcolor> <copy-fgcolor-to-bgcolor> <old-fgcolor>

If one use a prefix, usually only two characters are needed, since one usually want to keep the foreground color:
<prefix> <bgcolor>

There are only 16 colors, and that means that the same prefix could be used for switching other things using control characters, e.g. set 40 och 80 column mode, e.g.:
<prefix> <40-columns>
 
  • Like
Reactions: codewar65

codewar65

New Member
Sep 25, 2019
26
13
3
I don't believe the screen has an inherent background color that you can reset to. When you clear the screen or scroll it fills with spaces and they have the current background color. There is also no frame color yet, but I think they should have because on some screens there will be borders that are now black, but could have color. In order to change background color by copying foreground color using a control character one would typically have to send three characters, since one doesn't want to have the same bgcolor and fgcolor:
<bgcolor> <copy-fgcolor-to-bgcolor> <old-fgcolor>
I was only trying to suggest a code, yet be kind to the KERNAL ROM space needed. Set bgcolor could be nothing more then a shift left 4 of current color variable in the $0200 bank and reset could be set the high nibble back to original. Not sure if original is saved anyplace looking at the ROM source. I see it hard coded #blue in the editor.

If one use a prefix, usually only two characters are needed, since one usually want to keep the foreground color:
<prefix> <bgcolor>

There are only 16 colors, and that means that the same prefix could be used for switching other things using control characters, e.g. set 40 och 80 column mode, e.g.:
<prefix> <40-columns>
This would work too, but to implement multibyte petscii involves a state machine of sorts and would gobble up more ROM. I'd love to see expanded petscii control codes to set modes, screen colors, move cursor to x,y, delete line, etc, but space is very limited. Especially after adding PS/2, VERA, game controller, audio, etc.

Maybe a more advanced screen editor (stdin/stdout) could be moved off to another ROM bank. A mini ANSI X3.64 display driver might fit in a single bank.
 
Last edited:

mobluse

Member
Sep 20, 2019
35
15
8
Yes, the advantage with you method is that it is stateless. I found this in a manual:
To change the background colour requires 3 control codes. Suppose that you want blue letters on a yellow background then you must use the following sequence of control codes

131 yellow alphanumeric

157 new background

132 blue alphanumeric

10 MODE 7

20 PRINT CHR$(131);CHR$(157);CHR$

(132);"BLUE LETTERS ON YELLOW"

As you will gather to change the background colour you must first select letters of the desired colour, then declare a new background and then reselect the colour of the letter. Note that you cannot have a flashing background, so the following sequence.

136 flash

131 yellow alphanumeric

137 new background

132 blue alphanumeric

will produce flashing blue letters on a steady yellow background.

10 MODE 7

20 PRINT CHR$(136);CHR$(131);CHR$

(157);CHR$(132);"BLUE LETTERS ON YELLOW"

Flash is turned off with control code 137.
http://central.kaserver5.org/Kasoft/Typeset/BBC/Ch28.html

I agree to that this is a sensible method and it's similar to my method of sending two colors codes after each other: first the background and then the foreground, but here there is an extra character between background and foreground. One doesn't have any reset for foreground colors and shouldn't need it for background colors. CHR$($02) is a good candidate for "new background", because it can be typed on the keyboard using Ctrl+B, and is shown as an inverted B in a string literal. Ctrl+B is also easy to remember because Background starts with a B.
 
Last edited:
  • Like
Reactions: codewar65
May 22, 2019
486
250
43
See my post #7 :)
Yeah, I saw that right after I replied. :)

I actually had a much longer post, but cut out all the stuff about incompatible terminals and mainframes, because it was just too much for the context of the conversation... so I ended up with - what you said.

I could go on all day about IBM vs DEC vs Data General terminals, and how they all use different terminal sequences (and IBM mainframes often didn't even use ASCII) - but I don't think anyone really wants to read that. :)
 
  • Like
Reactions: Schlowski

mobluse

Member
Sep 20, 2019
35
15
8
ASCII does not cover color changes or arbitrary cursor movement. That's where the ANSI escape codes come in:

PETSCII control codes cover color changes. In order to use ANSI/VT102/xterm Escape sequences on the CX16 they would at least have to be ignored when printing them, but they are not now. To ignore all codes requires rather much code. It is much easier to ignore VT52 codes with exensions.
 

codewar65

New Member
Sep 25, 2019
26
13
3
If you are doing text over telephone lines, the most correct way to handle this is ANSI terminal codes. The ANSI standard was devices specifically to be universal. :)
Many classic Commodore BBS's transmit PETSCII controls, as did many old Atari boards with ATASCII codes. There are many in operation today via telnet.
 
  • Like
Reactions: mobluse

BruceMcF

Active Member
May 19, 2019
139
42
28
... I suggest opting one character code (maybe $8F) to set background as the current foreground color, something like they do with Teletext colors (new background 0x89), with another code to reset the background to the screen background color (maybe $0F), something like they do with ANSI escape sequences (CSI '0' 'm'). ...
Of the three alternatives ... two color codes in a row means the first one was background, a prefix that means the NEXT one is background, and the current foreground is now background ... I like yours the best, since from the side of programming support for it, it's an atomic action, not a result of "just received a color" state waiting for a second color or a "just received a background prefix" state, waiting for a color.

For one thing, that means there's no error condition, as in, "that isn't a color code" when a background prefix precedes a code that is not a color code.

When reversing colors, it's even as compact as the "two color codes in a row" system, since that is just [SetBG=FG][NewFG(=OldBG)].
 
  • Like
Reactions: mobluse