Odd LIST bug/behaviour

Anything Sinclair ZX Basic related; history, development, tips - differences between BASIC on the ZX80 and ZX81
Post Reply
sboisvert
Posts: 12
Joined: Mon Nov 02, 2009 3:43 pm

Odd LIST bug/behaviour

Post by sboisvert » Tue Sep 17, 2019 5:43 am

So I've recently begun doing some work on a custom implementation for displaying listings of ZX81 programs (a macOS Quick Look plugin, for the curious), and wanted to figure out what the behaviour would be for REM statements that contained some of the control characters (118/newline and 126/number flag). The results I discovered were rather interesting...

(Note: the listings were produced by issuing a 'LIST'; simply typing newline can produce an endless loop)

Given the following program:
Listing.png
Normal listing
Listing.png (2.26 KiB) Viewed 444 times

If a POKE 16517,118 is issued, the following occurs:
Listing1.png
POKE 16517,118
Listing1.png (990 Bytes) Viewed 444 times
This is where the listing code thinks the end of line has been reached (the early 118), and treats the rest of the line as though it's the next line to print (up to the end of the original line)

If instead, a POKE 16517,126 is issued, the following happens:
Listing2.png
POKE 16517,126
Listing2.png (769 Bytes) Viewed 444 times
Code 126 is the flag for 'a number', which makes it skip the next 5 bytes (in this case, the rest of the REM, just before the terminating 118).

Now if we do a POKE 16520,126:
Listing3.png
POKE 16520,126
Listing3.png (704 Bytes) Viewed 444 times
Since skipping the next 5 bytes goes past the original line, the next line becomes part of the first in the listing. Line 20 is still editable however.

Things really get wacky if we do a POKE 16535,118:
Listing4.png
POKE 16535,118
Listing4.png (4.28 KiB) Viewed 444 times
In this case, the listing goes past the program, and starts reading into the display file.

Now I don't find it surprising that the LIST code didn't take into account that a REM statement would contain control characters that wouldn't be part of a normal BASIC line, as that would have taken up precious space in the ROM to try to avoid this behaviour. But I was a bit surprised that it doesn't use the length of the line to properly detect when to stop evaluating the line, given that the length of each line is encoded within the BASIC program - making sure not to go past the end of the line shouldn't have been too many more bytes of code, and if the length is not used otherwise then it seems like a waste of memory (though I think the length is used to determine where to put the editing cursor, which would explain why line 20 is still editable).

I guess this was likely considered a fringe case, which is also easily avoided by using a double 118 sequence to hide the entire REM contents.

User avatar
mrtinb
Posts: 1044
Joined: Fri Nov 06, 2015 5:44 pm
Location: Denmark
Contact:

Re: Odd LIST bug/behaviour

Post by mrtinb » Tue Sep 17, 2019 7:51 am

I think the length is used to quickly find the next line when finding a line number for GOTO or GOSUB.

Or as you found out yourself: Find the line to edit it. So anytime you have a line number, the ROM uses the length of the line to quickly skip down to the line searched for.
Last edited by mrtinb on Tue Sep 17, 2019 7:55 am, edited 1 time in total.
Martin
ZX81, Lambda 8300, Commodore 64, Mac G4 Cube

User avatar
XavSnap
Posts: 742
Joined: Sat May 10, 2008 4:23 pm

Re: Odd LIST bug/behaviour

Post by XavSnap » Tue Sep 17, 2019 1:44 pm

HI,

Yes, the basic header line length is use to target the line offset, and many REM lines was locked by two 128 tag at 16514,16515.
The Nxt_Line variable is update to the line lenght, and don't change while the Inside new/line characters.

But, the D_file can be moved in a line 1 REM {34x chars}{N/L}{34x chars}{N/L}{34x chars}{N/L}{34x chars}{N/L}…
The D_file will display 34 characters instead of 32.

The REM line will be protected from LIST function by the line length.

Post Reply