Jump to content

Statement regarding programs in ROM


Recommended Posts

Posted (edited)
1 hour ago, Scott Robison said:

Not on the CX16, at the very least. The timing of chips is critical, and while the SDCARD is much faster than the older mass storage devices, it isn't going to be fast enough to respond in a timely fashion on the BUS.

Note: This is an educated opinion without having looked into actual timing diagrams.

I think three pins were left for ram or roms but could they be used to speed up the SD card instead? Or flash a usb with one gnd going to the power supply negative. The three extra pins was from this mod. Or just flash memory for a data bus expansion?

 

Edited by Travis Bryant moore
Link to comment
Share on other sites

4 hours ago, Scott Robison said:

Not on the CX16, at the very least. The timing of chips is critical, and while the SDCARD is much faster than the older mass storage devices, it isn't going to be fast enough to respond in a timely fashion on the BUS.

Note: This is an educated opinion without having looked into actual timing diagrams.

AFAIR, the maximum serial clock speed that must be supported in SPI mode according to the spec is 1 bit per cycle at 20MHz, which is a raw bandwidth of one byte per cycle at 2.5MHz.

And of course, it is a block access protocol.

There are native SD card protocols that can be faster, but I would presume they are also block access protocols.

  • Like 1
Link to comment
Share on other sites

Read through this and hope I didn't miss it, but going back to the original topic, one thing I'd really _really_ like to see get used with part of this ROM space is something of a standard library / standard tables. Things like VTUI or similar, but also perhaps some math routines and, notably, a collection of LUTs common for games (e.g. sine and multiplication tables and what not). Perhaps a note to frequency mapping as well for using the PSG since nearly any app that wants to make music will inevitably need a table like this and it's just a bunch of duplication otherwise.

A lot of these will be frequent additions to programs and games and, while they're not all big, having them right there and ready to go would be significant since soooo much of the ROM space would otherwise be unused if it was just for the kernel, GEOS, etc. I do think ROM should be a playground nor should app devs expect that end users will be flashing their ROMs just to use an app. But I do think having these nice to haves has a ton of benefits, among them is a core pillar of the X16 philosophy with making it an approachable computer to learn on.

Even if that's a concept that isn't embraced by the core team, I would advocate for a community solution to be considered, at least for those of us that plan on getting the full size X16 which is meant as a development platform (so having x16edit in ROM there to me makes a lot of sense).

Link to comment
Share on other sites

Posted (edited)

+1 on note to frequency table. Many apps will use it.

The numerical values will be pretty much the same everywhere. I would vote for having all the low frequency bytes in an array 0...127 and after that all the corresponding high frequency bytes at 128...255, so that you don't need to multiply the note value by 2 to get the correct index, but access both via LDA freq_lo, y and LDA freq_hi, y.

But that's a matter of taste. Either way, such a table would be nice. (I have to mention that Concerto uses more than 128 valid note values, so that the whole table requires more than 256 bytes and makes the aforementioned separation into low and high bytes strictly necessary to be able to access all entries)

Edited by kliepatsch
  • Like 3
Link to comment
Share on other sites

On 6/1/2021 at 12:10 PM, Stefan said:

Hi.

I've been involved in discussions on two use cases that are quite similar: Using the text editor I've developed to write source code for

  • Volksforth, and
  • a resident file based assembler

It is of coarse possible to

  • load the text editor from SD Card, and start it
  • load the source file from SD Card
  • edit the source file
  • save the source file to SD Card
  • load the assembler or Forth compiler from SD Card
  • assemble or compile
  • load the executable from SD Card
  • run the code for testing
  • repeat

However, all these steps will be tiresome to do over and over again.

The issue will be present for any setup that uses two or more programs in parallel.

One solution is to keep at least one of the programs in ROM, if that's supported by the platform. That's very convenient, much the same way as cartridge based utilities in the old days.

There might be other solutions, for instance dividing the RAM between programs. Unless there is a load function that may relocate code, programmers must agree in advance upon the division of RAM resources.

For any two programs that can easily be done if the programmers just talk to each other. But the complexity grows with the number of programs that are to be synchronized to each other.

But it is what it is. If the platform will not safely support ROM based user programs, we must use what resources are available. As evident from history, great ideas will often come to light to overcome limitations put upon us.

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.

 

  • Like 2
Link to comment
Share on other sites

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.

 

 

  • Like 1
Link to comment
Share on other sites

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.
 

Edited by codewar65
Link to comment
Share on other sites

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.

Edited by BruceMcF
Link to comment
Share on other sites

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. 

 

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use