Hallo Spiro, > No, it does not point to the zero at the end of the line, it points to > the next line (more precisely, to the 2 byte that point to the next > line again). This is a little test program I wrote myself and then created the PRG using PETCAT: 1 rem BASIC file to be converted by PETCAT 10 print"ruud" 9999 end 01 08 2C 08 01 00 8F 20 C2 C1 D3 C9 C3 20 46 49 4C 45 20 54 4F 20 42 45 20 43 4F 4E 56 45 52 54 45 44 20 42 59 20 D0 C5 D4 C3 C1 D4 00 38 08 0A 00 99 22 52 55 55 44 22 00 3E 08 0F 27 80 00 00 00 The first word, $0801 is the address where to load the PRG into memory. The next word, $082C, should be pointing to the next line , according you, but I see a $00 there. The word $0838 points to another zero end byte, as does the word $083E. At $083F we find the zero word that marks the end of the program. <...very long pause...> I think I see my mistake. The above is how it looks in my hex viewer. But I forgot that this is not how it looks in RAM. There it would look like: ?? 2C 08 01 00 8F 20 C2 C1 D3 C9 C3 20 46 49 4C 45 20 54 4F 20 42 45 20 43 4F 4E 56 45 52 54 45 44 20 42 59 20 D0 C5 D4 C3 C1 D4 00 38 08 0A 00 99 22 52 55 55 44 22 00 3E 08 0F 27 80 00 00 00 And then things look different, very different. OK, one problem solved. Regarding the use for GOSUB and GOTO, I think you are right: it is faster in this way. Thank you for helping me! Met vriendelijke groet, Ruud BaltissenReceived on 2021-10-28 20:00:03
Archive generated by hypermail 2.3.0.