We again are able to enjoy another guest-post from Bitshifter, as he fixes and enhances the C65 ROMs for use on the MEGA65:
The probably oldest and nastiest bug in Commodore BASIC
huge part of working on the ROM for the MEGA65, which contains the
resident part of the operating system and BASIC interpreter, is
Debugging. Not counting the character sets, the source code, written
in 45GS02 assembler, has about 30000 lines, separated into the
modules kernel, editor, DOS, BASIC and graphics.
The debugging is necessary mainly for two reasons:
1) Programmers, developers, software engineers are humans.
2) A source code, that is not your own, is full of traps, side effects and assumptions, that one is not aware of.
Of course my own code is full of traps and side effects too, but I know them (at least for the next few months).
working on the ROM, fixing Commodore bugs, optimising code to get
free space for extensions and introducing new features (and sometimes
new bugs), I write often some hundred lines of assembly code and make
changes on existing code. Sometimes these changes seem to work
perfectly, some result in crashes and freezes, because of errors and
some only seem to work fine in my own test, but fail if a developer
named „ubik“ demonstrates situations, which the code cannot
Well, I’ll not tell a long story, how I debug, but come directly to the bug mentioned in the title. I tracked his existence down to BASIC 2.0 as used in the VIC-20, C64 and the early PET/CBM series and it seems, that it was never detected, documented or fixed.
It is related to temporary strings, the stack of descriptors for temporary strings, that has a size of 3, and the so called „garbage collection“, which in reality doesn’t collect garbage, but does a defragmentation of string storage.
look at an example:
10 V1 = 12345: V2 = 6789
20 A$ = RIGHT$(MID$(STR$(V1),2)) + RIGHT$(MID$(STR$(V2),2))
and let’s look into string memory, after the execution of these two statements: