pcbasic
pcbasic copied to clipboard
`SCREEN(x,y)` reported character value of empties such as `chr$(255)` differs by video mode
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
-
SCREEN 1
orSCREEN 2
-
CLS
-
? SCREEN(1,3)
PC-BASIC returns 255
whereas GW-BASIC returns 0
.
Notes
PC-BASIC version: 2.0.4 Operating system version: all
Also, per DOSBox, Tandy GW-BASIC has "Ok"+chr$(32)
in all screen modes.
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
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)
PCJr behaves like GW-BASIC (based on MAME)
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
andPUT
text in graphics mode to another character cell, does it get read correctly?
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
- 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.