Command Line Arguments for BASIC

[voidstar]

Attached is a BASLOAD example of how to support passing "command line arguments" over to BASIC programs.

PEEK/POKE and VPEEK are used. This should work across different text screen modes (SCREEN 11, SCREEN 7, SCREEN 0, etc). Even SCREEN $80.

This is based off an approach used by cc65, where you pass arguments to your PRG via the RUN command like this:
RUN:REM <arg1> <arg2> <arg3> ... <arg9>

All the arguments must fit on the same row as the RUN statement itself. You can use quote (") to pass argument that contain spaces (but I didn't make a way to pass double-quote within an argument). This is perfect for passing filenames into a BASIC program.

Some limitations:
- Must use single space between the command line arguments
- Must have single space after the "RUN:REM"
- Only up to 9 arguments max

Video of usage in action:
https://www.youtube.com/watch?v=f3lbhVCGQUU

[voidstar]

Updated version that doesn't require REM.

Putting in separate attachment, in case anyone wants to compare with the prior to study the change.

[yock1960]

I'll have to look at this code later...for curiosity. I found how to do the previous method a while back, seeing it referenced somewhere on the CC65 website. I imagine I must've seen this in one or more magazine articles, back in the day, but I really didn't do much programming back then...mainly typed in games and other stuff, the other stuff, not games, my then, little boys, called 'programs'!

[voidstar]

It just occurred to me while driving home recently that this could be done. The only thing I didn't anticipate was dealing with screen codes back to PETSCII. So, it cost some memory to do this (for LUT; look up table), if someone were to make an equivalent machine code version.

[TomXP411]

We actually have space in Bank 0 specifically designated for command line arguments or parameter transfer. In fact, there's a whole page for it at $BF00.

The thing is, I don't think this has clearly been explained in the Programmer's Reference, so it's not really utilized.

Still, it's there, and $BF00-BFFF are reserved explicitly for passing parameters between programs.

[voidstar]

Ah in the XINFO Tech Manual (in LAUNCHER of SD card), I have a MEMORY MAP page for info like this.


Though, this CMDLINE is to help pass arguments directly from using CMDR-DOS. So I can just do:
RUN:PARAM1 PARAM2 1234 PARAM4


The reserved $BF00 would be good for transferring from one runtime asm. blob to another? Unless you're saying the RUN command does this, writes to $BF00 ? hmm, no, tried it out, doesn't look like it. Although, perhaps this isn't a bad idea? Of course it means the region being a "raw string" rather than binary encoded values.

[TomXP411]

Ah in the XINFO Tech Manual (in LAUNCHER of SD card), I have a MEMORY MAP page for info like this.


Though, this CMDLINE is to help pass arguments directly from using CMDR-DOS. So I can just do:
RUN:PARAM1 PARAM2 1234 PARAM4


The reserved $BF00 would be good for transferring from one runtime asm. blob to another? Unless you're saying the RUN command does this, writes to $BF00 ? hmm, no, tried it out, doesn't look like it. Although, perhaps this isn't a bad idea? Of course it means the region being a "raw string" rather than binary encoded values.

Ah, no, the RUN command does not do that. I'm just saying there are 256 bytes of memory reserved specifically for you to pass parameters between two different programs running at different times. Use it how you want; we left that section of memory undefined for whatever people want to do with it.

I was planning on using it to tie together my file manager and menu launcher. So the workflow would be something like this:

• Computer boots to menu.
• User wants to add a menu item: They press F1 to edit menu, then "A" to add an item.
• Menu sets $BF00 to something that means "Select a File."
• X-Commander comes up and reads the parameter area.
• It sees "Pick file" and changes the "Run" command to "*SELECT:ADD" (*SELECT means "select a file", and "ADD" is the command the caller expects back)
• User selects a file.
• X-Commander sets $BF)) to "*ADD:<filename>"
• X-Commander launches menu
• Menu program sees that a file was picked and adds that to the menu.
• Menu program sets the parameter area to zeroes. (so parameter aware programs don't come back and try to run something else)

Having said all that... I do like your approach. It's easier to use by hand, and it's only marginally more expensive to implement (the executed program has to scan the rows, looking for RUN:). That's an approach I think I might adopt and use. More importantly, I think that's an approach that should be incorporated into the C libraries for the various compilers.

[voidstar]

Yeah, it's just using the VRAM as the buffer, than just a little code to parse it. But on top of that:
- a decision has to be made on where to store the parsed parameters (for when after the screen has likely been CLS'd)
- and the screen code to PETSCII translation

In the BASIC case I just picked an array. But when adapted to assembler, one won't have that luxury. I guess in that case, we could use the $BF00 region as the buffer with a standard structure (like $BF00 itself might store the number of arguments, followed by N bytes giving the starting offset of each argument).

For the screen code to PETSCII table - maybe such a table already exists in a ROM? I imagine BASIC needs such a table to go the other way anyway. But the only reason for this table was so that the resulting strings in the array could be processed by BASIC keywords (MID$, etc).. In the assembler case, one could just work natively with screen codes I suppose.