Statement regarding programs in ROM

[BruceMcF]

7 hours ago, Stefan said:

Some thoughts on the design of a task switcher:

• 
  ... [a lot of excellent stuff snipped] ...
  


• 
  We need to think about what memory content to store, and where to store it
  
  
  
  • 
    If we are talking about complete executables and their data, the memory usage could easily become quite large.
    
  
  
  • 
    Example: 10 programs asking for backup of the whole low RAM would more or less fill banked RAM (512 kB).
    
  
  
  • 
    Is it necessary to backup executable code, or should code and data be well separated so that the executable could just be reloaded from SD Card. Then the backup would contain only data.
    
  
  
  • 
    Could it be left up to the user program to decide on how to store and restore its data when calling hide and show? To enable several programs to use banked RAM for that storage, we need memory management.
    
  
  
  
  


• 
  It's hard to see a solution not requiring the user program to call a register function. That means the task switcher will only work with user programs designed to work with it.
  


• 
  We should avoid adding a lot of features unless we want yet another operating system on our hand ?
  

There are two different scenarios. One is the "pop-up" scenario, the other is the full fledged task switcher. One, the other, or both could be supported.

For the pop-up, GIVEN that a pop-up wants to be able to pop-up over anything, and given that the pop-up HAS to play be the rules of the routine that pops it up, it can be more prescribed. For one thing, making a pop-up store in EXACTLY 8K for it's LowRAM usage is straightforward. You say that a pop-up program is assembled/compiled to load to and run from $8000 up to $9EFF, and it can have up to 256 bytes in the zero page and Golden RAM combined, at SPECIFIED PLACES, which is the size of the I/O page "cutout" from that 8K of RAM. The pop-up switcher has one segment to hold the "suspended" program RAM contents when the pop-up pops up.

How to handle video and audio when popping up is something I may have some ideas about, but am not so enamored of them that I don't want to hear other ideas first.

When a popup POPS UP OVER A POP UP, the task switcher knows because the first pop-up hasn't exited yet. It knows how to put a popup away, and does so, and now the second popup is popped up.

For the full fledged task switcher, it is a COOPERATIVE task switcher. You know you have a cooperating task because it has a "call next task" command. The program knows when it has to be in a state that can be shut down and restarted ... because it restarts as the return from the "call next task" command.

Full sized tasks that USE the tasl switcher can therefore be switched by it, and it has a directory on the SD card and that's where it stores dynamic data from and associated information about switched programs. For the register, it should in addition to telling the task switcher about its static and dynamic use of zero page and Golden RAM it should tell the task switcher about its STATIC use of other Low RAM by saying what file or files contains that static info and tell the switcher where it has dynamic RAM it uses. So the switcher preserves a zp block, a golden RAM block and a "program" low RAM dynamic RAM block, and REMEMBERS where to go reload the static RAM (code, static date, etc.).

In this context, maybe the "stack and heap" approach to HighRAM may make some more sense. You call the Switcher to load static data from disk into High RAM "starting from the first available HighRAM segment", and it does so, storing the file that the static data came from, and telling you the first data segment it was loaded to. And you call the Switcher to ask for a certain number of Heap segments you want for dynamic data. You can proceed to load stuff into those heap segments, but they are considered to be dynamic data. The Heap allocator is called with the address to put the base segment number. You know that if you have called the "next task" command, then the number in those base addresses may have changed.

When a task is switched, the code stack pointer is reset back to the beginning, and the code stack is loaded according to the new tasks static data. The heap is also a stack of block segments, of course. If a current heap request cannot be met from available HighRAM, heap data from the previous task is written out to the SD, and repeating if that does not make enough room. When there is enough room, ALL of the heap is copied down and the new data segment(s) allocated on top ... no deferred garbage collection ... and all of the current head item addresses updated. Probably Carry Set on the return if previously allocated Heap Data was moved.

Now, if one of the tasks in the cycle is greedy in its HighRAM usage ... sure, it will thrash when it hits that task. But the ones that are not greedy are the ones that will work together smoothly, taking a predictable amount of time to restart while it's static HighRAM pages reload. That's there is no deferred garbage collection on the heap ... the delay caused by the greedy program is not delayed until a less greedy program just happens to need a single segment when HighRAM is full, it happens when the greedy program is restarted. So the greedier programs will get a reputation for often being "slow to switch" and be less popular than the more frugal programs.

[Stefan]

Is it safe to say that creating a proper task switcher will be quite a feat?

[BruceMcF]

9 hours ago, Stefan said:

Is it safe to say that creating a proper task switcher will be quite a feat?

It is safe to say that creating a cooperative task switcher is best done by someone with a good debugging setup.

A preemptive general purpose task switcher without any hardware memory management? Yeah, that'd be quite a feat. I'd expect you need to be creating an OS if you want that.

This is similar to multi-tasking: cooperative multi-tasking is well within the capabilities of a C64. The only holdup for this kind of cooperative task switcher for a C64 would be the mass storage access speed.

So:

• 
  NO interrupt driven process required for the main task switcher.
  


• 
  "Registering" it starts with loading the program through the task loader. If its been loaded through the task loader, you have the option of loading the suspended task or starting it fresh. The rest of the "registry" is the call out to the task loader because the user has picked the programs "next task" function.
  


• 
  When you switch, you can go straight to the task loader, so there's no need for an "API" needed to pick the next one. When you do that call, you say what LowRAM you use, as begin/length of zp in two bytes, begin/length of GoldenRAM in four bytes, begin/length of "program" Low RAM in four bytes. That's in the 16byte "NewAPI" space in zero page.
  


• 
  So part of the API is a call address for next task, and a call address for end this task.
  


• 
  The third function is load static data to High RAM from SD, Task Switcher remembers name & parameters of file, that is part of the individual task control block in the task switcher segment.
  


• 
  The fourth function is NEW High RAM dynamic data segment(s)
  


• 
  The fifth function is RELEASE High RAM dynamic data segments(s).
  

[Travis Bryant moore]

is it possible to use a 1gb partition as rom and ram both at once on sd card?

[Scott Robison]

7 minutes ago, Travis Bryant moore said:

is it possible to use a 1gb partition as rom and ram both at once on sd card?

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.

[Travis Bryant moore]

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?

 

[BruceMcF]

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.

[m00dawg]

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).

[kliepatsch]

+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)

[TomXP411]

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.