Commander X16

14 hours ago, Stefan said:

The purpose of the command is not to program the ROM, but to start a program that resides in ROM.



The command is needed as you cannot change ROM bank in BASIC.

I misunderstood. Thank you for clarifying. This makes sense, and I agree this would be very convinient.

If people are intent on adding their own ROM to the board, then an extra socket and a few jumpers could be used to address that ROM separately from the one on board. It's probably way too late to add that to the X16, but maybe a breakout with the address, data, and control lines is possible? Then a ROM or multiple can be on a daughter board and only a few jumpers need to be set on the main board.  It would act like a cartridge port.

37 minutes ago, Ed Minchau said:

If people are intent on adding their own ROM to the board, then an extra socket and a few jumpers could be used to address that ROM separately from the one on board. It's probably way too late to add that to the X16, but maybe a breakout with the address, data, and control lines is possible? Then a ROM or multiple can be on a daughter board and only a few jumpers need to be set on the main board.  It would act like a cartridge port.

Yes, I would also guess it's too late for that kind of change.

The next best thing might be a robust KERNAL function for writing to the ROM banks. We'll just have to wait and see what the team comes up with...

1 hour ago, Stefan said:

The next best thing might be a robust KERNAL function for writing to the ROM banks. We'll just have to wait and see what the team comes up with...

A robust pair of "KERNAL" functions. One in the formal kernal that allows writing to any bank other than the kernal itself. Another that allows overwriting the kernal, probably in another bank I would imagine to avoid the problem of the kernal changing in the middle of the update.

On 5/13/2021 at 3:17 PM, Ed Minchau said:

If people are intent on adding their own ROM to the board, then an extra socket and a few jumpers could be used to address that ROM separately from the one on board. It's probably way too late to add that to the X16, but maybe a breakout with the address, data, and control lines is possible? Then a ROM or multiple can be on a daughter board and only a few jumpers need to be set on the main board.  It would act like a cartridge port.

If they have a 512K Flash ROM, which is 32 ROM segments, and there clearly isn't going to be 32 segments worth of essential system code included, it is hard to see why adding ANOTHER ROM to populate would attract more attention than populating the Flash ROM that is already there.

______________________

On 5/13/2021 at 5:44 PM, Scott Robison said:

A robust pair of "KERNAL" functions. One in the formal kernal that allows writing to any bank other than the kernal itself. Another that allows overwriting the kernal, probably in another bank I would imagine to avoid the problem of the kernal changing in the middle of the update.

You have pretty much hit the underlying point for the argument that a Kernel upgrade ... or any core system ROM bank upgrade ... should NOT be done by a ROM routine, but instead should be a program loaded into low RAM that contains the writing routines AND the information intended for the target Bank. A Kernel routine for writing a bank could indeed be designed to ONLY accept ROM Bank targets that do NOT contain the core CX16 functionality: the Kernel, the SD card manager, Boot BASIC, the GEOS Kernel, the Assembler Environment and the Menu system.

While over-writing the base platform cannot be "forbidden" if there is a jumper setting that enables writing the Flash ROM, it should be very much an activity where "this is not recommended: you are on your own if you do this." Part of what allowed these 8bit system to be pushed to the limits of the platform was the stability of the target for programming.

Given an ability to have an autostart statement stored in non-volatile RAM in the RTC, setting up the system to autostart into USING an ENTIRELY DIFFERENT set-up ALL in "User ROM Banks" ought to be quite easy, so there shouldn't be any urgent reason to have to overwrite the standard default system banks.

22 hours ago, BruceMcF said:

If they have a 512K Flash ROM, which is 32 ROM segments, and there clearly isn't going to be 32 segments worth of essential system code included, it is hard to see why adding ANOTHER ROM to populate would attract more attention than populating the Flash ROM that is already there.

That said ... the KINDS of things that people want to put in there really are the KINDS of things that would tempt you to spring for a multi-cart adapter for a C64 ... from my own background, I had a floppy based Forth on my C64 back in the 80s, and you can be sure I was jealous of the people with cartridge Forth's, who got "all of that" extra RAM to use for their code. Similarly a Pascal or Small C runtime would be an appealing addition to a system for reducing the low RAM footprint of compiled code, and if someone makes an Integer Basic for faster execution of Basic games, the version of the Basic in ROM would allow for larger programs than the "soft" version of the Basic that loads into RAM.

The MAJORITY of programs wouldn't get that kind of bonus. Plus, even when there is an appeal for that, not EVERYONE will have a high enough priority to flash the ROM version, so you'd want to develop the "soft" version in RAM first, and then consider whether any advantage of having a ROM version is worth the extra effort ... on both the development side and the user side.

For something like an editor ... if it edits text buffered in High RAM, then given the speed that the program would load from the SD card, it's hard to see the bonus big enough to warrant doing it.

On 5/13/2021 at 4:04 AM, BruceMcF said:

You have pretty much hit the underlying point for the argument that a Kernel upgrade ... or any core system ROM bank upgrade ... should NOT be done by a ROM routine, but instead should be a program loaded into low RAM that contains the writing routines AND the information intended for the target Bank. A Kernel routine for writing a bank could indeed be designed to ONLY accept ROM Bank targets that do NOT contain the core CX16 functionality: the Kernel, the SD card manager, Boot BASIC, the GEOS Kernel, the Assembler Environment and the Menu system.

What's more, doing a ROM update should probably be done on a UPS to avoid the scenario of a half updated ROM (particularly in the case of trying to update system ROM banks) in the event of a power interruption.

On 5/15/2021 at 10:23 AM, Scott Robison said:

What's more, doing a ROM update should probably be done on a UPS to avoid the scenario of a half updated ROM (particularly in the case of trying to update system ROM banks) in the event of a power interruption.

This is a problem that affects most modern systems with in-field updates to the BIOS/ROM and no guarantee of a stable power supply. While the update tool usually warns you not to reset or turn off your computer during the update process, the window of opportunity to brick your device is incredibly tiny. A power failure in the middle of flashing a new BIOS image generally will not leave you booting a corrupted image. This capability would require a few additional hardware components or maybe a bunch of additional software complexity. (I'm not certain it could be done in software only; I've only worked on this in a hardware context.) Since the hardware design is finished though, it's probably too late to add fault tolerance for ROM updates.

7 hours ago, Wavicle said:

This capability would require a few additional hardware components or maybe a bunch of additional software complexity. (I'm not certain it could be done in software only; I've only worked on this in a hardware context.)

I am confident, as someone who wrote device drivers and continuous background testing software at a single board computer manufacturer, that getting fully safe in-field updates to Flash ROMs requires software, hardware, and wetware support ?

Good hardware and software design can mitigate, but not remove, the need for wetware support; as we all know, Nature is very good at producing better idiots.

11 hours ago, Wavicle said:

This is a problem that affects most modern systems with in-field updates to the BIOS/ROM and no guarantee of a stable power supply. While the update tool usually warns you not to reset or turn off your computer during the update process, the window of opportunity to brick your device is incredibly tiny. A power failure in the middle of flashing a new BIOS image generally will not leave you booting a corrupted image. This capability would require a few additional hardware components or maybe a bunch of additional software complexity. (I'm not certain it could be done in software only; I've only worked on this in a hardware context.) Since the hardware design is finished though, it's probably too late to add fault tolerance for ROM updates.

Modern systems have in large part (I think) migrated to more complicated hardware schemes so that there is room for multiple BIOS/ROM images in a single chip, so that in the event of an incomplete update, there is still a failsafe/unmodified version sitting next to the failed update. In the early days of field updatable chips, this was not the case. If you were only able to partially update the chip due to a power failure or some such, you very much would brick the device because you would have half of one BIOS and half of another (perhaps).