Commander X16

The FAQ says this about the ROM: "TBD: May be able to be flashed from the X16".

I think this would be very usable, as not everyone has got an EEPROM programmer. And some may not be comfortable pulling out the ROM IC.

Has anyone seen more on this subject?

I have never built anything that writes to an EEPROM. As far as I understand, you would typically need to control three ROM lines (apart from address and data):

• 
  Chip Enable
  


• 
  Output Enable
  


• 
  Write Enable
  

Is it reasonable to believe that these lines would be connected to one of the VIAs, if it's decided to include this feature?

You read or write it like RAM but certain requirements have to be met to do so since accidentally writing to ROM would be disastrous. We will document the process once it has been tested since so far we have only ever flashed to ROMs externally.  In summary though, you need to have a jumper on the board set, then you need to write a specific sequence enable writing, and during the process timing requirement have to be met.  Because of the stakes, it is not something you can casually do. Failures can corrupt the ROM and essentially brick the device. You would need a replacement ROM or a programmer to fix it.   Sent from my iPhone using Tapatalk

18 minutes ago, Lorin Millsap said:

Because of the stakes, it is not something you can casually do. Failures can corrupt the ROM and essentially brick the device. You would need a replacement ROM or a programmer to fix it.

I sense an aftermarket opportunity to reflash bricked ROMs. ?

Great news, @Lorin Millsap!

If it's becoming practical for end users to add custom programs to the ROM, it would also be very practical if there was a BASIC command to start such programs. Otherwise the user would need to enter a startup stub in the Monitor or load a startup program from the SD card, which sort of takes away the meaning of ROM based programs.

A couple of weeks ago, I made a draft PR that implements a START command: https://github.com/commanderx16/x16-rom/pull/208

It's based on the discussion on a standard ROM format here: https://www.commanderx16.com/forum/index.php?/topic/956-signature-for-rom-based-programs/

The command makes it possible to enter for instance: START "MYAPP"

The command searches through the ROM banks, and if found, starts the program.

Even though the PR code works as advertised, it's a bit rough. Therefore the draft state.

If a start-up menu is one option for how the system boots up ... then an ability to run ROM based programs could be included in the MENU system, which would make a Basic MENU keyword a reasonable entry point

The ability to reflash the ROM is not intended for adding user programs. Sure you could, but it’s akin to adding custom programs to your BIOS. It’s intended for the KERNAL and useful extensions.  The risk of corrupting the ROM is fairly high.  The SD card or other storage device is where you locate your programs.  Sent from my iPhone using Tapatalk

6 minutes ago, Lorin Millsap said:

The ability to reflash the ROM is not intended for adding user programs. Sure you could, but it’s akin to adding custom programs to your BIOS. It’s intended for the KERNAL and useful extensions.



The risk of corrupting the ROM is fairly high.



The SD card or other storage device is where you locate your programs.

I appreciate that response and the reasons for it, but given the intended audience of these computers, it seems they are going to be far more likely to want to customize their ROMs not unlike the addition of JiffyDOS back in the day.

It would be nice if BASIC just had a simple extended SYS command that performed a JSRFAR to a particular address in a given ROM bank, at least.

I guess the nice thing about the ability to write to the ROM will be the ability to patch BASIC at the same time one adds a program to an otherwise empty ROM bank if such a feature is never added. Actually, it could be "fun" to create a completely custom ROM if one wanted to play with the hardware without needing any backward compatibility, necessarily (though that's an extreme fringe case).

A project I've been wanting to do (who knows if the day job will allow the time to complete it) fairly begs to be used instead of BASIC which would be best enabled by updating the ROM. In that scenario, I imagine adding a new language "ROM" bank and patching the Kernal to hand off control to it instead of BASIC (after sufficient development and testing to provide confidence that it works of course).

Just spitballing along the lines I think Stefan is describing. By putting something in the ROM, you open up potentially 16 K of RAM for data, which is not insignificant on a 16 bit address space, plus saving time of re-loading. Not that re-loading will be as significant as it was on a 1541...

If it's going to be complicated and/or risky to add programs to the ROM, that of coarse reduces the interest in a START or FARSYS command.

I haven't thought a lot about what programs you would typically want to store in ROM. I guess it's mostly utility programs that you use in parallel to other programs loaded from the SD card.

7 hours ago, Stefan said:

If it's going to be complicated and/or risky to add programs to the ROM, that of coarse reduces the interest in a START or FARSYS command.



I haven't thought a lot about what programs you would typically want to store in ROM. I guess it's mostly utility programs that you use in parallel to other programs loaded from the SD card.

Or a better dev environment than BASIC. Not unlike what one would have access via a cartridge on the C64 with Simon's BASIC (and many others ... https://www.c64-wiki.com/wiki/Cartridge#Overview)

Me, I’d put a file browser or a command shell in ROM, along with a file viewer/editor that displays in PETSCII, ASCII, or hexdump formats. 

After that, I’d say an assembler.