voidstar wrote: ↑Tue Oct 15, 2024 3:35 pm
So.... by "plain text" that is generally meaning "standard ASCII." But for example, suppose your code has the PI symbol in it, which CBM supports. I think that's $FF (or maybe $DE?), or in any case it's different than the IBM extended ASCII PI of 227. So really in this context, "plain text" is more the CBM character set convention (which just luckily has a lot of overlap with ASCII, just with a few exceptions that typically don't get in the way of things-- until you want to do CBM-style things like moving the cursor around or changing text color using PETSCII codes, or use the PI symbol shortcut).
And you're right, the tech ref here might be a tad incomplete. BLOAD is just going to load that "plain text" straight into BANK'd RAM (each bank being 8KB, it will use multiple banks as necessary). BLOAD itself doesn't know or care if it is plain text, it's just a raw data sequence to it. It also does say this "across bank" behavior is only when a high-ram address is used (so if you know it is a small file, some other address could be used- but if it's a "larger than 8KB" file, then $a000 is good unless you're using bank RAM for something else at the time).
So in the case of using high RAM, I *think* BLOAD is going to return the address offset into the last bank used (not a total linear offset) -- with 8KB bank, that offset can certainly be longer than 255 bytes, so yes two bytes is needed. The BANK will be set to where BLOAD left off (I don't think it auto-returns to the bank you were on when you invoked BLOAD), though generally (unless you have a ton of comments) the plain-text BASIC won't be over 8KB. That means the example of writing the end-null should work as intended. For purposes of "tokenizing" it is always going to look for that ending null (0x00, $00). If you remove that line 20, it could still coincidentally still work by tokenizing some trash and running into some other null.
I've not looked through the ROM code behind EXEC, but effectively: when your program ends, I think it checks some flag on if any content was buffered by EXEC. If so, that triggers processing the address used by EXEC to start "typing the plain text content" (maybe piping it to the keyboard input, which is why you SEE the code being typed, similar to how it would appear if you had pasted the code using the emulator). It is during that moment that the code is being tokenized (At $801, or maybe $80D?). It's not so much EXEC itself doing the tokenizing, but it is inducing the tokenization by virtue of "forcing the typing of buffered plain-text content." This is also why "piping to null" might not work at hiding this text (TBD based on Mark's notes).
So the plain text "FOR I = 1 TO BLAH" stored somewhere around $A000, then gets tokenized into whatever BASIC's code for FOR is, and the other operands of that instruction (over into the $801 region that BASIC uses to hold tokenized code). That tokenization doesn't happen immediately during the call to EXEC - it happens "after the fact" when the program halts (from STOP or END or running out of line numbers).
EXEC keeps going until it runs into a $00 in RAM, since (luckily) $00 is not a valid plain-text entry into BASIC.
There's no real "official" standard of filename conventions. A tokenized BASIC could be .BAS or .PRG
On the SD card I tried to have the following convention:
.BASL.TXT plain-text BASIC without line numbers, intended for BASLOAD (I use .TXT since that makes it easier to just double-click and start editing it under Windows, since .txt is associated with Notepad by default; but some folks will just use .BASL)
.BAS tokenized CBM BASIC
.PRG BASIC SYS header, but otherwise a 6502 compatible instruction sequence
Hopefully I haven't grossly misspoken here, but that's my understanding of things so far.
