Open robhagemans opened 2 years ago
Also, per DOSBox, Tandy GW-BASIC has "Ok"+chr$(32)
in all screen modes.
Upon further investigation:
So this may not be prompt related but character-recognition in graphics mode
Similarly,
?chr$(255)
?screen(3,1)
gives
(based on DOSBox 0.74)
PCJr behaves like GW-BASIC (based on MAME)
More observations on reading text in graphics modes:
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, 45Graphics 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:
GET
and PUT
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
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.
1
appears on the line below.
Third character of
Ok
prompt should not always bechr$(255)
Problem PC_BASIC's prompt is always
"Ok"+chr$(255)
. In GW-BASIC, this is the case inSCREEN 0
,7
and9
; however inSCREEN 1
andSCREEN 2
the prompt is"Ok"+chr$(0)
Steps
SCREEN 1
orSCREEN 2
CLS
? SCREEN(1,3)
PC-BASIC returns
255
whereas GW-BASIC returns0
.Notes
PC-BASIC version: 2.0.4 Operating system version: all