Undo NEW

You sir are a scholar and a genius. Hats off to you and your memory.

This version does not create a BASIC extension, but only a binary file that you need to run after NEW.

Brilliant! From my childhood, I remember it was possible, but I did not know the technique.

Here's my guess as to what's going on.

The default TXTTAB, where BASIC code starts, is $8001 on MSX. The first word (two bytes in LSB MSB format) is a pointer to the next line; if that pointer is $0000 it indicates the end of the program. So a NEW need merely put $0000 there to "erase" the current program, though that actually leaves the program (except for those bytes) intact but ignored by the BASIC interpreter.

When you POKE &h8002,128 this places a $80 at $8002, which makes the word at $8001 point to $8000. That's obviously not a valid address for the next line, but it is non-zero. When you do the first SAVE, the SAVE routine attempts to write this out to the file, successfully writing the initial $FF byte (indicating file type) followed by the $8000 pointer, and then quietly fails to write anything further. (If you hexdump the saved file, you'll see that it contains just 0000: ff 00 80.)

If youi then LOAD that file, the LOAD routine reads the first byte and confirms that it's $FF, throws it away, and then reads the remainder of the file data into memory starting at $8001. So now your BASIC text starting at $8001 in memory is an invalid next-line pointer $8000 followed by the remainder of your previous BASIC program, which has been in memory all along and never been touched.

But I believe that the next thing that LOAD does is start at the begining of the program, $8001, and does some sort of fixup on all of those next-line pointers (perhaps in case the file was saved from a different starting location). So it replaces that invalid $8000 pointer with a valid pointer to the next line, probably by reading forward through the line data until it gets to the $00 that terminates that line, and continues on with the rest of the program. Your program is now restored in memory and can be seen with LIST

However, this does not appear to have fixed the SAVE functionality, since another regular save of the program still saves just the header byte and first pointer and then stops (0000: ff 11 80). I'm guessing that this is due to some other pointers in the work area still being broken; it thinks from those pointers that the length of the program is still the length of the file it loaded, rather than tracing through the (now correct) line pointers in program text memory.

But the SAVE "...",A functionality does work for some reason, perhaps becuase it's using the same functionality as LIST rather than the "end of program" pointers in the work area. (Remember, SAVE copies memory directly to the disk file, but SAVE "...",A has to generate an ASCII listing of the program, rather than dumping the tokenised form in memory.) So that save does work.

And then when you reload that ASCII version of the file it also loads in a different way: rather than simply copying the data in the file into memory as it would do with a tokenised program, it detects that it's an ASCII save (no $FF byte at the start of the file) and reads each line into a line buffer elsewhere in memory and calls the tokeniser on it; the tokeniser is what generates the tokenised binary lines that it adds to the program text area starting at $8001. And, of course, it updates the program length pointers as it does this, so that the next time you do a binary save after that the SAVE command will work correctly again.

I think most users won’t have had the foresight to prepare and load an OLD extension TSR when they accidentally new a program, it’s not something that you would usually expect to do. And in that case, NYYRIKKI’s method is the perfect solution that can save you in a pinch.