Statement regarding programs in ROM

Wavicle · Post by **Wavicle** » Wed Jun 02, 2021 3:11 am

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.

Ed Minchau · Post by **Ed Minchau** » Wed Jun 02, 2021 3:52 am

I would much rather the core ROM chip only be changed for bug fixes. If people want to add ROMs of their own, fine, but leave the core alone.

BruceMcF · Post by **BruceMcF** » Wed Jun 02, 2021 3:54 am

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.

Stefan · Post by **Stefan** » Wed Jun 02, 2021 4:02 am

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.

Stefan · Post by **Stefan** » Wed Jun 02, 2021 4:44 am

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.

Lorin Millsap · Post by **Lorin Millsap** » Wed Jun 02, 2021 4:48 am

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

Scott Robison · Post by **Scott Robison** » Wed Jun 02, 2021 6:26 am

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.

BruceMcF · Post by **BruceMcF** » Wed Jun 02, 2021 8:55 am

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

Lorin Millsap · Post by **Lorin Millsap** » Wed Jun 02, 2021 12:07 pm

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

Stefan · Post by **Stefan** » Thu Jun 03, 2021 6:30 am

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 ?