pcbasic icon indicating copy to clipboard operation
pcbasic copied to clipboard

`SCREEN(x,y)` reported character value of empties such as `chr$(255)` differs by video mode

Open robhagemans opened this issue 2 years ago • 7 comments

Third character of Ok prompt should not always be chr$(255)

Problem PC_BASIC's prompt is always "Ok"+chr$(255). In GW-BASIC, this is the case in SCREEN 0, 7 and 9; however in SCREEN 1 and SCREEN 2 the prompt is "Ok"+chr$(0)

Steps

  1. SCREEN 1 or SCREEN 2
  2. CLS
  3. ? SCREEN(1,3)

PC-BASIC returns 255 whereas GW-BASIC returns 0.

Notes

PC-BASIC version: 2.0.4 Operating system version: all

robhagemans avatar Jul 08 '22 18:07 robhagemans

Also, per DOSBox, Tandy GW-BASIC has "Ok"+chr$(32) in all screen modes.

robhagemans avatar Jul 08 '22 18:07 robhagemans

Upon further investigation:

  • GW-BASIC reports 0 in all graphical modes
  • It reports 0 on every blank cell, not just after the prompt

So this may not be prompt related but character-recognition in graphics mode

robhagemans avatar Jul 12 '22 18:07 robhagemans

Similarly, ?chr$(255) ?screen(3,1)

gives

  • 255 on GW-BASIC, SCREEN 0;
  • 0 on GW-BASIC, other screens;
  • 32 on Tandy, all screens

(based on DOSBox 0.74)

robhagemans avatar Jul 12 '22 19:07 robhagemans

PCJr behaves like GW-BASIC (based on MAME)

robhagemans avatar Jul 12 '22 20:07 robhagemans

More observations on reading text in graphics modes:

  • (GW-BASIC) if two different characters have the same shape, SCREEN reports the one with the lowest value. E.g. in DosBox using codepage 850, where character 0xF0==240 SHY has the same shape as 0x2d==45 -: SCREEN 1:CLS:? CHR$(240);"-":? SCREEN(1,1),SCREEN(1,2) reports 45, 45 not 240, 45
  • characters 255, 0 and 32 always show as blanks in CGA graphics mode - while the 8-pixel font can be redefined, that only covers the range 128-254.

Graphics modes so not actually store the text printed, as I recall reading somewhere GW-BASIC reads commands an dtext in graphics mode by recognising characters from the pixels.

To check:

  • Is this also the case in Tandy text mode, given that it sees the third prompt character as a space?
  • If I GET and PUT text in graphics mode to another character cell, does it get read correctly?

robhagemans avatar Jul 13 '22 07:07 robhagemans

Discussion of character recognition (done by the BIOS it seems): https://www.vogons.org/viewtopic.php?t=9304 Related: https://www.vogons.org/viewtopic.php?t=37502&start=20

robhagemans avatar Jul 13 '22 07:07 robhagemans

  • If I GET and PUT text in graphics mode to another character cell, does it get read correctly?

Yes, but we have to make sure the logical "end of line" is past the characters - looks like GW-BASIC stores the text line length separately.

E.g.

screen 1: cls
?1
dim b%(4)
get (0,8)-(16,16), b%
put (0, 20*8), b%

On line 20 the representation of ?1 should now have appeared. Move the cursor down to that row.

  • press Enter: nothing happens but the cursor moving down.
  • go back up to row 20, type a space on the third position, now press enter. The command gets executed and 1 appears on the line below.

robhagemans avatar Jul 13 '22 07:07 robhagemans