4 ms·

If you go to the source link - https://bbcmic.ro/?t=9ctpk https://bbcmic.ro/?t=9ctpk - then you can see the numbers with the lines. They increment in steps of 1

If you go to the source link - https://bbcmic.ro/?t=9ctpk https://bbcmic.ro/?t=9ctpk - then you can see the numbers with the lines. They increment in steps of 10 (which IIRC you could override manually with numbers in-between).

PlunderBunny 3y ago
If you're playing with this on a BBC micro emulator, the best way to get this code into the emulator is to download the disk image from the above link. The actual basic program is named "PROGRAM" on the disc. List the code by typing LIST20, (the computer will lock up if you try to list line 10). If you just want to see the result, type MODE 1 and then press return, then type *LOAD SCREEN and press return again.
kragen 3y ago
thanks! i didn't see that link. but i think the 432 bytes leaves the line numbers out, so it should actually be 448 bytes
- flohofwoe 3y ago
  I guess that's a philosophical question. In most home computer BASIC interpreters, the source code (including line numbers) never exists as text in memory or on tape/disk, only as binary tokens. The only place where the original input text exists is a small line buffer which gets translated into binary token form when pressing Enter/Return. The LIST command translates the token form back into human readable text. And if you use 'AUTO' you also never type any line numbers... so are they actually part of the source code? Is there even 'source code' when the original source is never stored as text anywhere? Is the 'source code size' then the size of the original text data (that actually never exists a whole), or the size of binary token representation in memory and on tape/disk? :)
  - kragen 3y ago
    sure, you might want to count the tokenized representation instead of the printed representation, so maybe the real number is something smaller than 432, but it contains the line numbers too. you definitely don't want to count the 432 bytes of printed representation and leave out the 16 bytes of line numbers because the program won't run without them
  - wang_li 3y ago
    How do you speculate GOTO works if the tokenized program doesn’t have line numbers? Or if I write 5 REM MY COOL PROGRAM 10 PRINT “HELLO” 20 GOTO 10 Then later I write 10 PRINT “DIE BART DIE” How does it know to replace the right line?
    - flohofwoe 3y ago
      The line number is stored in the program, just not as text. It's preparsed into a (usually 16-bit) integer as part of the 'tokenization' of the input line buffer.
    - kragen 3y ago
      i don't think that flohofwoe was claiming the line numbers weren't stored, just that the textual representation with line numbers maybe isn't the correct measure

PlunderBunny 3y ago

If you're playing with this on a BBC micro emulator, the best way to get this code into the emulator is to download the disk image from the above link. The actual basic program is named "PROGRAM" on the disc. List the code by typing LIST20, (the computer will lock up if you try to list line 10). If you just want to see the result, type MODE 1 and then press return, then type *LOAD SCREEN and press return again.

kragen 3y ago

thanks! i didn't see that link. but i think the 432 bytes leaves the line numbers out, so it should actually be 448 bytes

flohofwoe 3y ago
I guess that's a philosophical question. In most home computer BASIC interpreters, the source code (including line numbers) never exists as text in memory or on tape/disk, only as binary tokens. The only place where the original input text exists is a small line buffer which gets translated into binary token form when pressing Enter/Return. The LIST command translates the token form back into human readable text. And if you use 'AUTO' you also never type any line numbers... so are they actually part of the source code? Is there even 'source code' when the original source is never stored as text anywhere? Is the 'source code size' then the size of the original text data (that actually never exists a whole), or the size of binary token representation in memory and on tape/disk? :)
- kragen 3y ago
  sure, you might want to count the tokenized representation instead of the printed representation, so maybe the real number is something smaller than 432, but it contains the line numbers too. you definitely don't want to count the 432 bytes of printed representation and leave out the 16 bytes of line numbers because the program won't run without them
- wang_li 3y ago
  How do you speculate GOTO works if the tokenized program doesn’t have line numbers? Or if I write 5 REM MY COOL PROGRAM 10 PRINT “HELLO” 20 GOTO 10 Then later I write 10 PRINT “DIE BART DIE” How does it know to replace the right line?
  - flohofwoe 3y ago
    The line number is stored in the program, just not as text. It's preparsed into a (usually 16-bit) integer as part of the 'tokenization' of the input line buffer.
  - kragen 3y ago
    i don't think that flohofwoe was claiming the line numbers weren't stored, just that the textual representation with line numbers maybe isn't the correct measure