Skip to content
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

Open
robhagemans opened this issue Jul 8, 2022 · 7 comments
Assignees

Comments

@robhagemans
Copy link
Owner

robhagemans commented Jul 8, 2022

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 robhagemans added the bug label Jul 8, 2022
@robhagemans robhagemans self-assigned this Jul 8, 2022
@robhagemans
Copy link
Owner Author

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

@robhagemans
Copy link
Owner Author

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
Copy link
Owner Author

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
Copy link
Owner Author

PCJr behaves like GW-BASIC (based on MAME)

@robhagemans robhagemans changed the title Third character of Ok prompt should not always be chr$(255) SCREEN(x,y) reported character value of empties such as chr$(255) differs by video mode Jul 12, 2022
@robhagemans
Copy link
Owner Author

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
Copy link
Owner Author

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
Copy link
Owner Author

  • 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant