Commander X16

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

Exactly.  Flashing the ROM is not a thing casually done.  

 

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.

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.

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

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.

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.

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

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.

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.