Statement regarding programs in ROM

[BruceMcF]

4 hours ago, TomXP411 said:

This is no different than the CP/M or DOS days. 



For example, if I want to write an assembly program for CP/M, I have to: 



1. Load the CP/M text editor and write my code file.



2. exit to the command prompt and run the assembler to generate the object code



3. Test the program



4. Rinse and repeat.



The only problem is that the CX16 doesn't have a way to set up batch files, since we don't have a way to set up command line parameters. So you can't do something like "CXEDIT MYGAME.ASM"



My thinking is we need two things:

1. 
   A batch processor of some sort 
   


2. 
   An API for passing command line parameters into programs
   

Neither of those things is hard. We'd just need to come to a consensus as a community where to store command line arguments and to design our programs to work with them. Ideally, the KERNAL would support it, but even without that, we can still designate a memory space for command-line parameters and let our programs communicate using that area.



 

This is part of the thinking in having file selection functions FOR a program being an option in the Menu system. Then whatever channels the Menu system uses and wherever they store the file name and other data, in whatever format they do it, becomes the standard, because any program that does it the same way as the Menu will be usable by any program that takes advantage of the Menu system.

One thing about having a (relative to an 8bit system) fast and roomy mass storage option is that we don't actually need to store it in Memory. There could be a standard file, or standard channel that is opened before loading and running a program, with the information in a standard format. And with a file based system, we don't have to fuss about saving RAM space for the system: [input]="filename"[\return]output="filename"[\return], etc. Just parameter_name=string and carriage return, the first parameter by default the name of an input file ... you know it's the default when the first character of the first line is "=". With channel #15 being the command channel, I'd nominate channel #14 being the "commands data" channel.

 

 

[codewar65]

We'd need to be able to be able to pass parameters to a new process, pipe input and output, and spawn/fork processes. Clearly, outside of the scope of a Commodore style BASIC, but maybe handled to some extent by an extended BASIC add-on.



Maybe disk commands could be prefixed with a '>' (i.e.: >dir, >app24.prg, etc), parameters captured by system variables AN (number of args), and AV$() (values), a simple batch scripting interface that returns control to the script loaded into high banked RAM once a process is finished, or something.

 

[Lorin Millsap]

What makes you think parameter passing is beyond the scope of BASIC?


Sent from my iPhone using Tapatalk

[BruceMcF]

2 hours ago, codewar65 said:

We'd need to be able to be able to pass parameters to a new process, pipe input and output, and spawn/fork processes. Clearly, outside of the scope of a Commodore style BASIC, but maybe handled to some extent by an extended BASIC add-on.



Maybe disk commands could be prefixed with a '>' (i.e.: >dir, >app24.prg, etc), parameters captured by system variables AN (number of args), and AV$() (values), a simple batch scripting interface that returns control to the script loaded into high banked RAM once a process is finished, or something.

 

You seem to be familiar with one particular approach to passing parameters.

I already gave a way to pass parameters: write the parameters into a sequential file, a line per parameter, and have a channel open when the program is launched. Then INPUT# is your friend.

That has a second version, where there is a standard name for the parameters, and the program tries to opens that file.

Then you have a Kernel call. That could return the address in AY format of a list of arguments. Each argument starts with the number of characters, so the address+1 is the first character in the first argument, which is (address) bytes long, and address+1+(address) is the address of the second argument, until you get to the 0 that signals it's the end of the list of arguments. Then a Basic Keyword that can parse that into a string array and you're good to go.

For any of these, a Menu system can have an argument option system built in to pick input and output files and set various settings ... for instance, you might have a standard program description file that the Menu program is able to read might have a simple system for specifying arguments are accepted and what options they have.

Arguments were passed to the CP/M and PC-DOC microcomputer single tasking operating systems long before it involved spawning and forking processes. Because the command lines systems were designed for paper teletype first and then glass teletype and menu systems were only designed later, the menu systems were often a kludge on top of the command line interface, but it's perfectly possible to do that the other way around, have an argument system that works using a menu file explorer. Then if people want a command line, someone can write a shell that uses the same argument passing system.

[TomXP411]

13 hours ago, BruceMcF said:

You seem to be familiar with one particular approach to passing parameters.



I already gave a way to pass parameters: write the parameters into a sequential file, a line per parameter, and have a channel open when the program is launched. Then INPUT# is your friend.

I'd avoid using the SD card for that kind of temporary data usage... being flash memory, the card will have a finite number of write cycles, and it would be easy to eat up several hundred write cycles every time you get into the kind of workflow we're talking about. 

 

[BruceMcF]

1 hour ago, TomXP411 said:

I'd avoid using the SD card for that kind of temporary data usage... being flash memory, the card will have a finite number of write cycles, and it would be easy to eat up several hundred write cycles every time you get into the kind of workflow we're talking about.

There's an issue to be aware of ... the question here is designing the task files so that they are NOT heavily used as temporary data storage when in the middle of this kind of workflow. Write one, use many times should be the watchword.

Of course, the big advantage of having the command arguments in a file is the ability to reuse them, which is why I'd favor the standard channel over the standard filename approach, even before you brought the write cycles issue up. Cycling through a particular argument for text editor, compiler/assembler and then running program would only require a write when you need new arguments. The Menu system would definitely have to be setup so that it is easier to reuse the last set of arguments than to write new ones.

But as far as storing the name of the task file that has been opened on the command arguments channel, to enable it to be closed and reopened, if the program wishes, the write cycles issue would suggest that task file name has to be kept in system RAM somewhere, available on request. That is something that would be on a rotation as you work through a project made of the sequence of tasks.

One way to organize the task file with the command arguments for a program is to have the task file have the program file to be loaded and run as the first line, and then the arguments on following line. Then the program is run with its command arguments by selecting the task file itself, the Menu opens the file on the command arguments channel, gets the first line, and loads and runs the program ... which then means that the command arguments channel is open on whatever channel it used.

So in the Menu, you can re-use an existing task or go through the process of selecting a program and creating it's task. Then a project file is just a list of task files you have selected from the "these are your task files" display, and if you have the menu as your autostart option, when you exit from one project, the Menu program knows you were doing a project file, so it comes up with the next task in the project ready for you to hit return.