-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SCREEN(x,y)
reported character value of empties such as chr$(255)
differs by video mode
#195
Comments
Also, per DOSBox, Tandy GW-BASIC has |
Upon further investigation:
So this may not be prompt related but character-recognition in graphics mode |
Similarly, gives
(based on DOSBox 0.74) |
PCJr behaves like GW-BASIC (based on MAME) |
Ok
prompt should not always be chr$(255)
SCREEN(x,y)
reported character value of empties such as chr$(255)
differs by video mode
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:
|
Discussion of character recognition (done by the BIOS it seems): https://www.vogons.org/viewtopic.php?t=9304 |
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.
On line 20 the representation of
|
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
The text was updated successfully, but these errors were encountered: