SCREEN 2, etc. Overflow Error in variable.

[Ronald Herrera]

I can't understand what's the problem of an Overflow error for a string variable that account in an unprper behaviour. Any how here is a piece of program for a simple graphic SCREEN tester:

10 'SCREEN READER - COPYMADE DIVISION (AöC) VER. 20131116; qb20131130.
20 'SAVE "SCREEN1.BAS", A
30 KEY OFF: CLEAR : SCREEN 1: SN = 1: ON ERROR GOTO 160
40 CLS : CIRCLE (40, 35), 10, 3: PAINT (40, 35), 3, 3
50 LINE (65, 25)-(85, 45), 2, BF
60 LINE (100, 45)-(110, 25), 1: LINE (110, 25)-(120, 45), 1
70 LINE (120, 45)-(100, 45), 1: PAINT (110, 30), 1, 1
80 PRINT " SCREEN READER... ": PRINT " Ver. 20131130."
90 LOCATE 9, 2: PRINT "SCREEN #"; SN
100 IF SN = 1 THEN GOTO 130
110 PRINT : PRINT " Press Any Key.";
120 A$ = INKEY$: IF A$ = "" THEN GOTO 120 ELSE GOTO 30
130 LOCATE 11, 2: INPUT "Enter SCREEN number (1-15): ", SN
140 IF SN < 1 THEN CLEAR : SCREEN 0: WIDTH 80: END
150 IF SN > 15 THEN ERN = 1: GOTO 160 ELSE SCREEN SN: GOTO 40
160 REM ERROR MESSAGES
170 SOUND 800, 5: PRINT : PRINT
180 IF ERN = 1 THEN PRINT " Numbers should be 1 to 15.": GOTO 110
190 IF ERR = 5 THEN PRINT " Unsupported SCREEN mode.": GOTO 110
200 PRINT : PRINT "*** Err"; ERR ; "in line"; ERL: GOTO 110

[Rob Hagemans]

Hi Ronald, thanks for sending this!

1) I can't get an Overflow error with this code, when do you get one?

2) The code runs into a problem the second time you type in an unsupported screen number. The reason for that is that the error-handling routine does not have a RESUME statement; as a consequence the program never exits the error-handling mode. When an error happens during error-handling mode, the program stops with an error message, in this case Illegal function call.

I thought this was expected behaviour but on trying this in GW-BASIC it seems to work differently. This is interesting - I will need to study how GW-BASIC handles this exactly.

Rob

[Rob Hagemans]

In issue (2), it turns out an ON ERROR GOTO instruction is executed after the error trap, which should reset the trapping but failed to do so in PC-BASIC. I have fixed this now.

Rob

[Ronald Herrera]

Yeah! I have observed again. And I can't understand why I'm not getting the same error again. I swear that the error was caused by the string variable (A$) in the INKEY$ getting the overflow error when changing to screens. I’m so sorry for this, but definitely I’ll try to back up my steps and verify what cause this error. Please, stand by until I report back. If I’m successful I’ll study the situation and the steps to reproduce this error to see if the bug is something else. Again, thank you!

Ronald

[Ronald Herrera]

Now I know, for Tandy or PCJr with GWBASIC use the CLEAR,,,32768! statement for SCREEN 5. Which I make the mistake CLEAR , , 32768! (NOTICE THE TWO COMMAS). And, since PC-BASIC doesn’t need the CLEAR,,,32768! statement I couldn't reset the screen with CLEAR (enter) or NEW (enter) and a fresh RUN program of SCREEN didn't work correctly with the environment causing the overflow error.

Ronald.

[Rob Hagemans]

I just reproduced an Overflow on CLEAR,,32768!:A$=INKEY$ (with two commas). That still shouldn't happen, even though that statement isn't something you would usually use...

[Rob Hagemans]

This has now also been fixed - no more Overflow here.
Of course you do need the three commas for the Tandy video memory.

[Ronald Herrera]

Thanks. The CLEAR ,,32768! was a mistake or mistype which cause the error. And yes in GWBASIC TANDY the statement CLEAR,,,32678! is needed, but I have notice that I don't really need it with PC-BASIC (e.g. 3 voice sound and SCREEN 5 & 6). But that's great news. Thank you!