Jump to content

Statement regarding programs in ROM


Recommended Posts

I keep repeatedly seeing the idea of people using the ROM to store custom programs such as games. This is stemming perhaps because we have made it known that the ROM will be in system flashable.

 

However I just want to clarify this is not the intended function. From an official stance obviously you can do whatever you want with your system but we (the X16 team) are not encouraging this practice.

 

The ROM is primarily for the core OS, which is the KERNAL, BASIC, a few common support routines, the auto loader, the GEOS dependencies, BASIC extensions, and KERNAL extensions.

 

The ability to flash the ROM is intended for post deployment bug fixes, patches, and the installation of certain drivers.

 

Now maybe I’m missing something here, and if so discuss it. I always find it helpful to discuss the actual use cases rather than just hypothetical open ended functionality.

 

In practice we are going to have an auto booth feature in the X 16 and it will load based upon a configuration file on the SD card. From which it is possible to boot up to some kind of menu or to load a sequence of drivers or any number of things not entirely unlike how DOS system would function. The loading from the SD card is generally fast enough to make most ROM patches unnecessary. I say most because there are obviously still circumstances where a ROM patch might be needed or at least preferable.

 

Off the top of my head a few such use cases could be:

•A drive controller that is bootable. Envision something like a second SD card, a SATA controller, etc.

•A network interface that is bootable. Envision like an ethernet or wifi adapter that enables a NetBoot type feature.

•Second second display controller. Obviously a display especially if you want to use it instead of the integrated VERA needs to work from POST in order to provide meaningful use.

•A usb keyboard/mouse interface. This would need ROM integration as there are keyboard inputs that can be used for setup, diagnostic, and boot select features. If you used a USB adapter card and it wasn’t recognized at POST you wouldn’t be able to use those features.

 

In short part of what I’m proposing is that the ROM be reserved for the core OS and for routines and drivers that augment that especially for expansion card devices that you may want or even need to always be resident in ROM instead of loading from the SD card. This would especially be true of devices you either want or need to be bootable, or that you need to be active as part of instead of after POST.

 

 

Sent from my iPhone using Tapatalk

  • Like 2
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Can someone explain some of the details involved in designing an expansion card that maps itself into ROM based on the position of onboard DIP switches? Like... bus arbitration: how you would make sure the card is what gets accessed and not the empty slot in the ROM on the motherboard — or worse, both.

Link to comment
Share on other sites

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.

Number of programs loaded is a non-issue on a system that lacks multitasking. Hypothetically you can multitask, but the OS itself does not support it. So that’s largely a non issue. And locating one of those in ROM does not solve that issue.

You have up to 2 megs of RAM to play with, and most programs do not have to share with other programs.


Sent from my iPhone using Tapatalk
Link to comment
Share on other sites

3 hours ago, Lorin Millsap said:

The ROM is primarily for the core OS, which is the KERNAL, BASIC, a few common support routines, the auto loader, the GEOS dependencies, BASIC extensions, and KERNAL extensions.

Not to hijack the thread, but I'd like to ask some clarifying questions, if I may.

Will there be an actual version of GEOS that will be made available for the system?

If so...

Will it just be the deskTop and the desk accessories and preferences apps? The impression that I get is that you guys in the core team are trying to limit the workload, so refactoring geoPaint and geoWrite to work on the X16 seems to be unlikely.

And will it continue to default to using the alternative font that looks like University 9 instead of the BSW 9 that's hard-coded into so much of the system? Because that just seems like unnecessary adding to the workload too — bitmap fonts are not copyrightable under US law, and the X16's primary market seems to be the US. So rather than have to go through every part of it that is being ported and adjust anything where the text doesn't fit, why not just stick with the original? Or at least, tweak the modified font so that its horizontal spacing is the same as BSW 9.

Link to comment
Share on other sites

5 minutes ago, Lorin Millsap said:


Number of programs loaded is a non-issue on a system that lacks multitasking. Hypothetically you can multitask, but the OS itself does not support it. So that’s largely a non issue. And locating one of those in ROM does not solve that issue.

You have up to 2 megs of RAM to play with, and most programs do not have to share with other programs.


Sent from my iPhone using Tapatalk

But @Stefan is not really talking about multi--tasking, he is talking about task switching ... literally switching between tasks. For programming the system ON the system, whether Assembly or Forth or whatever ... perhaps Pascal-M ... you have two or three phases of the process that each use different software (when including for the compilers the software being written).

(1) You could have a task-switcher. For LowRAM-only files, this is not so hard if it's a cooperative system (that is, the participating systems know they are participating).  As a little Low RAM program, you go into a shutdown state and then call the task switcher, and the task switcher moves you out as you exist when you called it, and when the task restarts, you've been reloaded back into Low RAM and you restore from your shutdown state. You need anywhere from 1-5 segments of HighRAM to work with.

The simplest extension to programs that use High RAM is that it's your job before calling the task switcher to pack everything away neatly back in the SD card.

The task switcher program is something that seems like it has a really strong use case for being in ROM, because it shouldn't occupy any LowRAM and it is dedicated to moving things between LowRAM and HighRAM, but actually the routines that need to be in ROM are the block moves from Low RAM to High RAM ... the bulk of the Switcher could be in a single HighRAM segment, maintaining its circular list of switched tasks, and call bulk LowRAM to HighRAM or HighRAM to LowRAM routines in ROM somewhere and work OK.

(2) You could have a pop-up editor. You just suspend whatever program is using edited files, and edit them, and then let it go again. Anything remotely like this on a C64 had to be an a cartridge, because doing something like this with a pop-up editor program stored on a 1541 disk drive would test the patience of a saint. But with the same routines, it seems like it's a simpler version of the task switcher ... because basically the task switcher IS the editor, and it's the only program that needs to know the details of the task switching that is going on. It's core resides in a single HighRAM segment, and the dispatcher is a small routine in GoldenRAM.  It has a storage HighRAM segment to store the current data in the part of Vera it needs to use for its text display, and whatever part of LowRAM it needs for it's own purposes,

It's basically a Terminate-and-Stay-Resident program from DOS days except on a system where there IS not TSR call, so the program has to do the TSR-ing itself.

(3) The mooted Menu system could be designed in a way that makes the process smoother. After all, the reason we started with command line interfaces was because we started with teletypes. But the core of the classical CLI is specify a program, specify one or more files it works with, specify some options. There's no reason a a menu system can't do that without having any underlying command line interface underneath. So the menu system allows you to set up a "task" by picking a program, and picking or entering the file or files it works on. It lets you open an options file associated with the program (by a naming convention) and pick the option lines you want, and saves the options you want into a file for the task. You can attach the task to one of four task commands in the menu. Running the task copies the working file names and the options into a "this.task" file, after deleting any existing "this.task" file,  and any program that wants to be able to be attached to one of the four task commands on the menu knows it needs to offer a convenient way to use the current "this.task" file to get going.

It could let you name a task, and then since it's a menu system, you can go into the menu of named tasks to grab the tasks you want to attach to the four task commands in the menu, or just run the task from the named task menu.

So if you have the menu as your start-up program, any kind of repeated cycle just requires fiddling around the first time, and if you got it right the first time, the repetitions are just hitting

The required ROM footprint here is zero, since it could be a program loaded from the SD card that you have set as your autostart, but if more than a small cluster of demo programs are going to use the system, it would be ideal if it was part of the ROM Menu system.

Link to comment
Share on other sites

Can someone explain some of the details involved in designing an expansion card that maps itself into ROM based on the position of onboard DIP switches? Like... bus arbitration: how you would make sure the card is what gets accessed and not the empty slot in the ROM on the motherboard — or worse, both.

Expansion cards cannot map themselves into ROM. There is no exclusive arbitration there. The expansion slots do expose the entire bus so DMA techniques can be used, but ROM mapping is not a supported function. However this thread is not the right place to ask your question.


Sent from my iPhone using Tapatalk
Link to comment
Share on other sites

1 hour ago, Lorin Millsap said:

However this thread is not the right place to ask your question.

Sorry... I was just thinking of possible alternative ways of running ROM-based code and wedging it into the system that wouldn't require flashing the motherboard ROMs. Sorry if that isn't relevant to a thread about why flashing things into the motherboard ROM is a bad idea.

  • Like 1
Link to comment
Share on other sites

My desire to add to ROM is a "improved" BASIC-like interpreted language. One that supports multiple tasks and provides an almost GEOS like interface, but all in a text / tile based interface (think along the lines of the TEOS project; https://www.youtube.com/channel/UCrELuExo6T_USEqELq1xVHQ for videos).

In my case, it would not be designed primarily for native code (though it would ideally support native apps if they wanted to use it not unlike BASIC / KERNAL routines). The utility of it in my mind is by making the interpreted code position independent (even more so that BASIC) it could support multiple simultaneous tasks and even crude multitasking without having to play with IRQ task switching. I think it would provide a "linear" address space to gloss over bank switching and other hardware abstraction layers to support sharing the single VERA or other hardware resources more easily.

This could all be done without ROM, of course. With as much RAM as is available, it would not be a huge pain point to sacrifice RAM to the run time. But it would be nice if those static unchanging parts of the system that multiple applications depend on are in ROM so as to keep as much RAM free as possible.

Link to comment
Share on other sites

Having once owned a Plus/4, the idea of productivity apps in the same ROM as the base OS firmware fills me with terror. Even though bugs in those apps could be fixed with an in-field update to the flash, those parts don't have bad sector detection and remapping. Once you have a bit that is worn out, it is forever stuck and may leave you bricked until you get can get a new flash part. Unless you have a flash programmer and the chops to burn your own parts, it's best to minimize write cycles just in case. I've seen a part with an endurance of 100K cycles develop a corrupt bit after less than 20 writes. A rare occurrence to be sure, but it happens.

  • Like 1
Link to comment
Share on other sites

Posted (edited)
43 minutes ago, Wavicle said:

Having once owned a Plus/4, the idea of productivity apps in the same ROM as the base OS firmware fills me with terror. Even though bugs in those apps could be fixed with an in-field update to the flash, those parts don't have bad sector detection and remapping. Once you have a bit that is worn out, it is forever stuck and may leave you bricked until you get can get a new flash part. Unless you have a flash programmer and the chops to burn your own parts, it's best to minimize write cycles just in case. I've seen a part with an endurance of 100K cycles develop a corrupt bit after less than 20 writes. A rare occurrence to be sure, but it happens.

This goes to my question about whether it would be useful to have a jumper that can invert the high address of the ROM Bank, so that the system ROM segments can be mirrored, once starting at $00 and once starting at $10. Doing a flash upgrade (of firmware bugs etc.), would involve using one set while writing the other bank, then verifying the match, then changing the jumper.

Of course, this assumes that there are fewer than 16 base system ROM Banks. And reduced the number of "free" ROM Banks by the number of base system ROM banks.

It's not a "wetware failure friendly" as automatically detected and remapped bad sectors, but it might be something.

This is another area where the experience of working with 21st century cheap gadgets hides the complexity of what is going on under the hood.

Edited by BruceMcF
Link to comment
Share on other sites

Posted (edited)

It was interesting reading @BruceMcF's post about, amongst other, TSRs in MS DOS. It's a really relevant comparison to task switching in another OS not supporting multitasking. 

TSR required memory handling, though.

TSR like functionality on the X16 will be challenging due to the lack of memory handling. One benefit of storing utilities in ROM is that we would not need to think about that.

 

Edited by Stefan
Link to comment
Share on other sites

Some further thoughts on this.

Unless the X16 KERNAL supports and enforces a standard for switching between programs that are simultaneously stored in RAM, each utility program must find its own solutions to the problem, for instance by

  • creating different versions of the program that is loaded to different parts of low RAM
  • hiding the program code in banked RAM while inactive
  • having a restore routine copying back the program code to low RAM when called upon again

It will not be as good as a ROM based solution, but it might work sufficiently.

Link to comment
Share on other sites

My desire to add to ROM is a "improved" BASIC-like interpreted language. One that supports multiple tasks and provides an almost GEOS like interface, but all in a text / tile based interface (think along the lines of the TEOS project; https://www.youtube.com/channel/UCrELuExo6T_USEqELq1xVHQ for videos).

In my case, it would not be designed primarily for native code (though it would ideally support native apps if they wanted to use it not unlike BASIC / KERNAL routines). The utility of it in my mind is by making the interpreted code position independent (even more so that BASIC) it could support multiple simultaneous tasks and even crude multitasking without having to play with IRQ task switching. I think it would provide a "linear" address space to gloss over bank switching and other hardware abstraction layers to support sharing the single VERA or other hardware resources more easily.

This could all be done without ROM, of course. With as much RAM as is available, it would not be a huge pain point to sacrifice RAM to the run time. But it would be nice if those static unchanging parts of the system that multiple applications depend on are in ROM so as to keep as much RAM free as possible.

Things like that could be fine though again they would function just as well from RAM.

 

But I do like the comments about a proper task switcher, it would provide a nice way to exit programs in general.

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

Posted (edited)
1 hour ago, Lorin Millsap said:

Things like that could be fine though again they would function just as well from RAM.

But I do like the comments about a proper task switcher, it would provide a nice way to exit programs in general.

Most things can be done in RAM. A very minimalist 6502 ROM could be limited to the top 1 to 4 KB of RAM that did nothing more than allow loading of a binary file and run it. You want BASIC? Poof! You want a stand alone text editor. Done!

In the case of the X16, IMO (not that anyone really cares what I think, as it isn't my dream machine) the decision has been made to have a 16 KB bankable ROM that will never be available as RAM. Thus "immutable code" fits in that place really well. Kernal, BASIC, GEOS to name a few. Or Xenon (the name of my present vapor ware concept).

I agree that the speed of SDCARD vs the old IEC interface means that loading isn't nearly the PITA it was back in the day. However, providing an environment that allows high level interpreter code that can escape to ML just seems perfect for ROM banking, especially when it allows multiple tasks to be loaded and running at once. Using an example others have given, I'd love to see a text mode windows UI that allowed one to load both a text editor and an assembler or compiler. Alt TAB (or some magic key) between the two windows to work just as you do in any modern multiprocessing system. If the environment supported shared memory blocks so that the text editor could share the current source file with an assembler, even better (potentially). It doesn't replace highly optimized ML / native programs, it's just a different interface.

That being said, it's not like I'm ready to burn something to ROM.

Edited by Scott Robison
Link to comment
Share on other sites

1 hour ago, Stefan said:

It was interesting reading @BruceMcF's post about, amongst other, TSRs in MS DOS. It's a really relevant comparison to task switching in another OS not supporting multitasking. 

TSR required memory handling, though.

TSR like functionality on the X16 will be challenging due to the lack of memory handling. One benefit of storing utilities in ROM is that we would not need to think about that.

Levels:

Simple level: You tell the task switcher the range you use in the Zero page, and the range you use in Low RAM, it writes a file to the SD card that stores the current values of those when called. It does nothing to HighRAM ... if you have HighRAM data to store, that's up to you. It also tells the task switcher it's name. The task switcher resides entirely within a single HighRAM segment except for the small stub in Golden RAM which is used to call it.

The only difference here to having "something" in ROM is that the task switcher HighRAM bank is a System allocated bank and there is no need for the stub in GoldenRAM.

Middle level: this is the one I blathered on about above.

Higher level: for cooperating programs, there is an allocator of HighRAM, on a simple "stack & heap" model, executables and mixed data and executables allocated from the bottom up a segment at a time, data segments allocated in groups as needed from the top down. A two bit BAM for "System / Stack Allocated / Free / Heap Allocated" is 2bits x up to 256 segments for 512 bits or 64bytes. The task switcher would be able to check what the allocation was when it starts, and keep track of how much each one uses. Maybe programs that DON'T use the allocater ought to exit by rebooting, so the task manager only has "retained" data from programs "popped up", which is just the state that a pop-up popped up into, and "saved" data from data that was in a chain of tasks done in a cycle. So when you exit the pop-up, instead of freeing the last task program and data segments and grabbing the next one, it just frees and you go ahead with the data that is sitting "underneath".

  • Like 1
Link to comment
Share on other sites

Levels:
Simple level: You tell the task switcher the range you use in the Zero page, and the range you use in Low RAM, it writes a file to the SD card that stores the current values of those when called. It does nothing to HighRAM ... if you have HighRAM data to store, that's up to you. It also tells the task switcher it's name. The task switcher resides entirely within a single HighRAM segment except for the small stub in Golden RAM which is used to call it.
The only difference here to having "something" in ROM is that the task switcher HighRAM bank is a System allocated bank and there is no need for the stub in GoldenRAM.
Middle level: this is the one I blathered on about above.
Higher level: for cooperating programs, there is an allocator of HighRAM, on a simple "stack & heap" model, executables and mixed data and executables allocated from the bottom up a segment at a time, data segments allocated in groups as needed from the top down. A two bit BAM for "System / Stack Allocated / Free / Heap Allocated" is 2bits x up to 256 segments for 512 bits or 64bytes. The task switcher would be able to check what the allocation was when it starts, and keep track of how much each one uses. Maybe programs that DON'T use the allocater ought to exit by rebooting, so the task manager only has "retained" data from programs "popped up", which is just the state that a pop-up popped up into, and "saved" data from data that was in a chain of tasks done in a cycle. So when you exit the pop-up, instead of freeing the last task program and data segments and grabbing the next one, it just frees and you go ahead with the data that is sitting "underneath".

I like the lower level the best. Except I wouldn’t make an SD file. I would prefer to use a portion of highram which is KERNAL reserved for that purpose.

The task switcher should be part of the menu integration. When a task switches, it just goes to a menu which will display any resident integrated programs, so BASIC and EDITOR, and the integrated monitor for example, and any other ROM resident programs, followed by current RAM resident programs. Then the menu will also have quick items which are things stored on the SD that you use frequently. And it would have a browse option so you can go find anything by browsing the SD contents.

The integrated file browser needs to be part of the KERNAL load and save functions, as well as error handling. The C64 left most error handling to the programs, which was rarely actually implemented the way commodore suggested. For example if you load abs a file not found error is returned, I argue it should use an integrated error handling routine that should tell you the nature of the error and give you options about what to do. This would greatly enhance basic as well as end user programs.


Sent from my iPhone using Tapatalk
Link to comment
Share on other sites

Posted (edited)

Some thoughts on the design of a task switcher:

  • It must be interrupt driven.
    • It cannot use the vector 0314-0315, as these are typically set by user programs.
    • A minimal requirement is that a new vector to be used by the task switcher is added to the KERNAL interrupt main loop. The rest of the task switcher could be RAM based and loaded from SD card.
  • The task switcher API core functions could be
    • register, called by a user program that wants to be added to the task switcher
    • show, called by the switcher to show a registered program
    • hide, called by the switcher to hide a registered program
    • close, called by the switcher to close and remove a registered program
  • Possible input to the task switcher when calling register
    • Program name
    • Memory usage: zero page, golden RAM, low RAM
    • Call address for show function (within the user program)
    • Call address for hide function
    • Call address for close function
  • 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 🙂
Edited by Stefan
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

Posted (edited)
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).
Edited by BruceMcF
Link to comment
Share on other sites

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.

  • Like 1
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