Problems using EDIT

[dvanaria]

Maybe I'm not understanding how the EDIT program works, need some assistance.

Just using it to write a simple BASIC program:

10 FOR I = 1 to 10
20 PRINT I
30 NEXT I
40 END

If I type this program in the following way:
1. EDIT "TEST.BAS"
2. Type in above program
3. Ctrl-O to save (same filename)
4. Ctrl-X to exit EDIT

Now back at the commandline, I type LIST and nothing comes up. i guess the "currently loaded BASIC program" memory is separate from EDIT's memory, but i was expecting whatever I was editing inside EDIT to still be there at the commandline, but that's ok i can get used to the way this works.

But when I try:
LOAD "TEST.BAS"
and type RUN
nothing happens. It doesn't load the program into BASIC's program space.

Trying again (after some research) I hit Ctrl-F inside EDIT and select the BASLOAD compiler. This seems to save it into BASIC's program space, but it also adds its own line numbers:
1 10 FOR I = 1 to 10
2 20 PRINT I
3 30 NEXT I
4 40 END

So I guess EDIT, if it's being used to create a BASIC program, should be used without line numbers? Then I would type in a BASIC program, hit Ctrl-F and select BASLOAD, then exit EDIT to run my program. I guess I would also SAVE it from the commandline as well, SAVE "TEST.BAS"

But once it's saved that way (as a runnable BASIC program), if I try to open it again using EDIT, it seems to have been converted to it's tokenized (binary) format so isn't editable as a plain-text file anymore.

I must be missing something...

[mortarm]

Edit is basically just a text editor. It doesn't care what you put into the file, whether it be a program listing or letter to Grandma. It's all the same to Edit. It's what you do with the file after you leave Edit that counts.

[dvanaria]

Ok but can it edit BASIC programs? I guess that's the part I'm not understading. Once you use BASLOAD to tokenize a plain-text BASIC program, is there a way to "un-tokenize" it back into plain-text form to work on some more?

[Stefan]

Hi,

The intended workflow:

- Edit and save the source file as PROGRAM.BAS
- Either press Ctrl+F or exit the editor and type BASLOAD ”PROGRAM.BAS”
- Type RUN to start the program
- If you want to save the tokenized version, don’t overwrite the .BAS file. Better to SAVE ”PROGRAM.PRG”
- Type EDIT ”PROGRAM.BAS” to continue editing

[TomXP411]

Ok but can it edit BASIC programs? I guess that's the part I'm not understading. Once you use BASLOAD to tokenize a plain-text BASIC program, is there a way to "un-tokenize" it back into plain-text form to work on some more?

Not really. The BASLOAD process permanently removes some information, such as comments and long variable names. So you need to maintain your .BAS/.BASL source file separately from your tokenized .PRG file.

Yes, you can LIST to a file, but you will have lost all of the details that make BASLOAD useful.

It's just like any compiled language: there's no way to go from an executable program back to the original C/C++ code. Even with .Net languages, like C#, the "de-compilers" are making educated guesses about keywords and variable names.

[dvanaria]

Thank you!

I've got it now, it makes much more sense to me to think of BASLOAD as a compiler, one that takes a plain-text file (a BASIC program) as input and compiles it into tokenized BASIC, output to RAM only. If you want to further save that program onto disk, in it's compiled state, it's best practice to use a different extension (.PRG instead of .BAS for example) to identify it. That way additional work can be done using the .BAS plain-text file.

This means that using EDIT, it's best practice to not use line numbers, since BASLOAD adds its own line numbers.

I've been planning on typing in some old BASIC games which have numbered listings and lots of spegetti code with GOTO statements. And this could be typed in by making each line number a label in the source code (though it must start with a letter, so for example L120: might go above the code for line 120 in the source code), and then BASLOAD converts all those labels, converting any reference to them to actual line numbers in the BASLOAD tokenized version.

[TomXP411]

Yeah, the way to handle stuff like type-ins is either to just type it in to the immediate mode screen, exactly as God intended, or create labels for the the lines pointed to by a GOTO or GOSUB.

You certainly don't need to (and should not) label every line. You can just do a text search for GOTO, GOSUB, and maybe THEN keywords to find all of the destination line numbers.

[ahenry3068]

Thank you!

I've got it now, it makes much more sense to me to think of BASLOAD as a compiler, one that takes a plain-text file (a BASIC program) as input and compiles it into tokenized BASIC, output to RAM only. If you want to further save that program onto disk, in it's compiled state, it's best practice to use a different extension (.PRG instead of .BAS for example) to identify it. That way additional work can be done using the .BAS plain-text file.

This means that using EDIT, it's best practice to not use line numbers, since BASLOAD adds its own line numbers.

I've been planning on typing in some old BASIC games which have numbered listings and lots of spegetti code with GOTO statements. And this could be typed in by making each line number a label in the source code (though it must start with a letter, so for example L120: might go above the code for line 120 in the source code), and then BASLOAD converts all those labels, converting any reference to them to actual line numbers in the BASLOAD tokenized version.

Here's a tool to help get you started REMLINE.BAS (REM(ove)LINE(s).BAS) is a QBasic program included with MS-Dos 5.0. It strips a GWBASIC program of all Line Numbers that are not a target of another statement(GOTO, GOSUB, ON, THEN, RESTORE). It compiles nicely in QB64. I changed CONST MAXLINES from 400 to 4000 and here's an archive containing both Linux & Windows Executables and the modified QB Source. If you happen to be a MAC user then QB64PE is also available for MACINTOSH and the source will compile there as well.

Though designed for GWBASIC it pretty much works on any ASCII BASIC source with line numbers.

The resulting OUTPUT file is NOT immediately usable by BASLOAD but it's very far on it's way, and is MUCH easier than stripping line numbers by Hand.

[voidstar]

I like to use .BASL as the extension for BASLOAD files, just for me helps remind it is a regular ASCII text file. Then can "save as" to either .BAS or .PRG. You could save .BASL with .TXT extension, just since most systems will associate .TXT with an ASCII-style editor program. But again, the .BASL extension has help avoid mistakes (like I won't accidentally LOAD on a .BASL file, or accidentally save a tokenized BASIC listing back to .BASL, whereas I might do that if I had used just .BAS)

And yea, easier to think of BASLOAD as "compiling to an executable" even though that's not quite accurate (other than it is a result that you can RUN). You never really need to look at the tokenized BASIC result from BASLOAD, you'll always make updates using the original text file. We might dig into the tokenized BASIC result for some critical debugging sometimes. Or if the .BASL text gets extensive/long, to avoid the time to re-process it in BASLOAD, you might experiment with some changes in the .PRG itself temporarily.

That said, there are options in BASLOAD to have it output a cross-reference between the variables used in the tokenized result and your original long variables.
EDIT: See SAMPLE3 here https://www.youtube.com/watch?v=BC8ccp8HrIM

[Edmond D]

If you happen to be a MAC user then QB64PE is also available for MACINTOSH and the source will compile there as well.

Just a note I briefly attempted to get QB64PE going on a MAC, but it didn't work for me. Unfortunately I don't have the time to dive on why it failed on my system just yet. I would hope to get at it in 2025, since I've got a lot of things on hold, such as actually assembling my X16 which came back in March!