Jump to content
Stefan

Flash ROM from the X16

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Posted (edited)
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.

Edited by Scott Robison
  • Like 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
Posted (edited)
10 hours ago, Scott Robison said:

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

So the simple version would be a jumper to an EOR that inverts the high bit of the Flash ROM segment address, and a backup copy of system critical segments in segment 16 going up, so if you "brick" an update/mod, you move the jumper and the system boots?

Indeed, the "safe" update is to overwrite the backup copy, run the verify program, then switch the jumper and update the original updates. And the "safe" mod is to write the backups and switch the jumper and just don't mod the originals.

And if you got greedy and used those blocks for other thing, "oops, people shouldn't be greedy"?

Note that this assumes less than 16 segments of system critical segments, which I do indeed assume.

Edited by BruceMcF

Share this post


Link to post
Share on other sites
On 5/31/2021 at 6:06 AM, grommile said:

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.

Not so sure about wetware support. I worked in Microsoft Surface for several years and don't recall any of the flash firmware updates involving user interaction. If you have one of our devices, you've probably seen a few firmware updates go by without realizing it.

  • Like 1

Share this post


Link to post
Share on other sites
On 5/31/2021 at 10:18 AM, Scott Robison said:

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

True, true, and true. I believe the part number on the X16 prototype shown in one of those recent videos was a 4Mb / 512KB component (SST NOR flash I think, but I may be misremembering).

Share this post


Link to post
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.


×
×
  • Create New...

Important Information

Please review our Terms of Use