robhagemans / pcbasic

PC-BASIC - A free, cross-platform emulator for the GW-BASIC family of interpreters
http://www.pc-basic.org
Other
393 stars 48 forks source link

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

Open robhagemans opened 2 years ago

robhagemans commented 2 years ago

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 commented 2 years ago

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

robhagemans commented 2 years ago

Upon further investigation:

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

robhagemans commented 2 years ago

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

gives

(based on DOSBox 0.74)

robhagemans commented 2 years ago

PCJr behaves like GW-BASIC (based on MAME)

robhagemans commented 2 years ago

More observations on reading text in graphics modes:

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:

robhagemans commented 2 years ago

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 commented 2 years ago

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.