Ancient bug in BASIC 2

Kilian Hekhuis · Post by **Kilian Hekhuis** » Thu Apr 01, 2021 1:51 pm

Just read this post detailing an ancient bug in BASIC 2. Would be nice if it were fixed in X16 BASIC :).

Elektron72 · Post by **Elektron72** » Thu Apr 01, 2021 2:17 pm

If you'd like to make sure that this bug gets fixed at some point, consider adding it to the X16 ROM issue tracker.

Kilian Hekhuis · Post by **Kilian Hekhuis** » Fri Apr 02, 2021 9:08 am

18 hours ago, Elektron72 said:

If you'd like to make sure that this bug gets fixed at some point, consider adding it to the X16 ROM issue tracker.

Thanks, I added it there.

mobluse · Post by **mobluse** » Fri Apr 02, 2021 10:27 am

It would be interesting if someone could make a BASIC v2 program that demonstrates the bug in the garbage collector.

BruceMcF · Post by **BruceMcF** » Fri Apr 02, 2021 2:03 pm

Even better would be if someone were to migrate the Basic V7 garbage collector to the CX16, as AFAIU, it is a more efficient garbage collector.

Confer, eg, http://retro64.altervista.org/blog/garbage-collection-commodore-64-basic-to-handle-it/

Snickers11001001 · Post by **Snickers11001001** » Fri Apr 02, 2021 5:10 pm

2 hours ago, BruceMcF said:

Even better would be if someone were to migrate the Basic V7 garbage collector to the CX16, as AFAIU, it is a more efficient garbage collector.

God, yes.. THIS.

The improved garbage collection was also on the Plus4 and, if memory serves, showed up as early as the last basic update that they stuck in the later PET computers. What they did was store back-pointers with the actual strings in the string-heap. I think it pointed back to the area just after Basic that had the variable and its descriptor, if the string was valid; otherwise it pointed to the next string location if its associated string had been "unused." The "8 Bit Show and Tell" youtube channel has an interesting video on how adding the pointers actually caused some faults in programs that "misused" string functions to fill memory (i.e., set pointer for string heap to a place you need to fill; then repeatedly set A$ to the contents for a range of that memory, then reset the string heap to its normal location). Without the GC update the set-reset of the same string just filled the memory area with the discarded contents, but the unintended consequence of the new behavior was that particular hacky-approach no longer worked because with the new pointers it was more than just the strings stored up there.

It wasn't perfect and garbage collection never is, hell its still debated even in modern platforms. On my old Plus4 there would still be garbage collection "stutters" if you did a ton of strings manipulations, but the situation like on the C64 where it would get tied up for minutes at a time was gone.

Reading the description of the 'bug' that is the subject of this thread, it occurs precisely because of the same shortfalls of the c64 collection mechanism that cause it to be slow and problematic. So putting in the better garbage collection from Plus4/C128 should both negate the bug and vastly improve GC in general. Focusing on fixing the 'long standing' bug alone while staying with the crappy C64 style GC would, in my view, be an exercise in esoterica rather than productive use of coding efforts.

BruceMcF · Post by **BruceMcF** » Sat Apr 03, 2021 2:40 am

9 hours ago, Snickers11001001 said:

God, yes.. THIS.

The improved garbage collection was also on the Plus4 and, if memory serves, showed up as early as the last basic update that they stuck in the later PET computers. ...

Yes, AFAIU, it is in CBM Basic v3.5 ... but my only other Commodore systems were 128's, so v7 is the other Commodore Basic I used. Its garbage collector doesn't bog down nearly as often or nearly as badly.

mobluse · Post by **mobluse** » Mon Apr 05, 2021 12:14 am

On 4/2/2021 at 7:10 PM, Snickers11001001 said:

Reading the description of the 'bug' that is the subject of this thread, it occurs precisely because of the same shortfalls of the c64 collection mechanism that cause it to be slow and problematic. So putting in the better garbage collection from Plus4/C128 should both negate the bug and vastly improve GC in general. Focusing on fixing the 'long standing' bug alone while staying with the crappy C64 style GC would, in my view, be an exercise in esoterica rather than productive use of coding efforts.

Putting in the better GC of C128 would not help since the bug is also in C128: "I found this bug in all versions of Commodore BASIC, that I investigated, VIC-20, C64, C128, C65, MEGA65." https://c65gs.blogspot.com/2021/03/guest-post-from-bitshifter-fixing.html

BruceMcF · Post by **BruceMcF** » Mon Apr 05, 2021 2:28 am

3 hours ago, mobluse said:

Putting in the better GC of C128 would not help since the bug is also in C128: "I found this bug in all versions of Commodore BASIC, that I investigated, VIC-20, C64, C128, C65, MEGA65." https://c65gs.blogspot.com/2021/03/guest-post-from-bitshifter-fixing.html

Thanks for that ... it still should be the 128 version of the GC with the bug fixed for the bug fix

If you are replacing the brake shoe in your car because the design of the old one was faulty, but the brake line design is also faulty, you'd want to replace that at the same time.

Snickers11001001 · Post by **Snickers11001001** » Mon Apr 05, 2021 3:30 am

1 hour ago, mobluse said:

Putting in the better GC of C128 would not help since the bug is also in C128: "I found this bug in all versions of Commodore BASIC, that I investigated, VIC-20, C64, C128, C65, MEGA65." https://c65gs.blogspot.com/2021/03/guest-post-from-bitshifter-fixing.html

OK, I read his post a few more times. On my initial readthrough, I thought he was saying the bug was in the garbage collection itself. On a few re-reads it seems he's saying that (a) on system initiation, basic zeros out the high byte of the "last temporary string" pointer but not the low one; and (b) the string operations themselves have a behavior that he claims in a corner case causes a fault, which he suggests is due to an optimization where the most recently used discarded string doesn't have its backpointer changed to include a garbage flag. But the more I reread his post the more confused I get. I'm not an expert on Commodore basic string management, but I don't think that there are back pointers in the VIC or C64 string heaps. On C64, which is what the CX16 BASIC is built off of, this statement in his post seems incorrect:

" This starts at top of screen memory and copies all strings, which do not carry the garbage flag, to adjacent addresses, skipping the garbage strings."

There aren't garbage flags or backpointers in Basic 2.0 along with the strings in the string heap. That's the reason GC on the C64 is not good: See: https://www.c64-wiki.com/wiki/Garbage_Collection#Garbage_collection_in_C64_BASIC.