[Coco] (No subject)

[Allen Huffman]

On Jul 14, 2022, at 2:21 AM, lost via Coco <coco at maltedmedia.com> wrote:
> 
> Actually, the test is completely removed.That missing byte is needed so VAL can work on a string stored at the very top of string space. It needs to temporarily put a NUL byte after the string so the number parser knows when to stop. After executing, VAL restores the byte to its original value. Things would fail if the byte after the string data was ROM though.

I am going through the VAL routine, "assuming" it calls some generic parser that expects a 0.

VAL begins at B716. I see it does a call to LB686 which then calls LB654 to "get length and address of string". The length comes back in register B, if I am following it.

So X points to the string to parse, then B is the length, and it adds B to X, giving it the end, then I get it passes backwards.

I think it must be at B726 where it does a CLR ,X, so if the string started at 100 and was 3 bytes long, X would have become 1003 and clearing that would be one byte past the end of string storage.

I did a test to POKE 32767,255 then had a string there, and did a VAL, and it came back 255, which must be the STA ,X "replace string terminator" a few bytes later.

Intereresting. This means on the CoCo 3, it’s temporarily overwriting the first byte in "ROM" at $8000 (32768) and then fixes it back. That's the "EX" bytes you mentioned.

Interesting, since it already knows the length of the string, but uses LBD12 to "convert an ASCII string to floating point." Somewhere there is that NUL check, but I haven’t gotten that far yet.

Very interesting. I don’t think I’ve ever looked at the Super BASIC disassembly book. I scanned it for the first time last night and it has a wealth of interesting information at the start, including those POKES to fix several bugs in the ROM. 

Rabbit hole, rabbit hole…