Flash ROM from the X16

[Stefan]

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?

Edited May 9, 2021 by Stefan

[Lorin Millsap]

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

[Scott Robison]

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.

[Stefan]

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.

[BruceMcF]

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

[Lorin Millsap]

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

[Scott Robison]

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

[Stefan]

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.

[Scott Robison]

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)

[ZeroByte]

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.

[Scott Robison]

2 hours ago, ZeroByte said:

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.

While my BASIC-like peer project isn't going to be an assembler per se, I was planning to allow some sort of "inline assembly" first class feature so that those portions that would benefit could use it.

[Stefan]

Considering what Lorin said above in this thread I will probably remove my PR for a START command.

I now have a much simpler implementation for a FARSYS command.

Example: FARSYS $C000,7 will jump to address $C000 in ROM bank 7.

It seems to work, but I will look at the code a bit more before pushing that.

Even if flashing the ROM will be somewhat complicated/risky, it's reasonable to believe quite a few will try that anyway. The FARSYS command would be useful for those.

Do you think the name of the command should be shortened to FAR?

[desertfish]

just FAR is too confusing IMO , it's a SYS call you're doing after all, just to another Rom bank.   Perhaps FSYS?   (in the spirit of VPOKE/VLOAD) 

[Stefan]

I made the pull request now. As suggested by @desertfish, I'm calling it FSYS.

https://github.com/commanderx16/x16-rom/pull/213

[Scott Robison]

I think "BOB" would be a good command for a far sys...  Or not...

[Scott Robison]

In all seriousness, C128 had an extended SYS command: SYS address,a,x,y,s

Where a,x,y,s were optional and were used as values for the given registers if given.

I would think a better solution for X16 BASIC is to just extend the SYS command to be "SYS addr,bank,a,x,y,s" where bank can be ROM or RAM based on the address provided. That way it allows setting of register values and SYSing into either ROM or RAM banks depending on the context, just like JSRFAR does.

 

[Stefan]

5 hours ago, Scott Robison said:

In all seriousness, C128 had an extended SYS command: SYS address,a,x,y,s

Where a,x,y,s were optional and were used as values for the given registers if given.

I would think a better solution for X16 BASIC is to just extend the SYS command to be "SYS addr,bank,a,x,y,s" where bank can be ROM or RAM based on the address provided. That way it allows setting of register values and SYSing into either ROM or RAM banks depending on the context, just like JSRFAR does.

 

Are there any vararg functions in the current BASIC implementation? I'm not aware. A vararg SYS command could be a lot of work. I don't know if it's worth it.

There is much less need for a FAR SYS command that lets you jump to banked RAM. The RAM bank can easily be switched from BASIC with a POKE 0,[RAM BANK] before using the standard SYS command.

My implementation of FSYS does only switch ROM banks.

[Cyber]

I agree with Lorin's approach, that certain requirements have to be met like jumper and so on. And I don't see how this interferes with adding custom file browsers, viewers, editors or even making a completely custom ROM. This really should not be casual. Why would one need a BASIC command that could be executead at any time?

[Scott Robison]

1 hour ago, Stefan said:

Are there any vararg functions in the current BASIC implementation? I'm not aware. A vararg SYS command could be a lot of work. I don't know if it's worth it.

There is much less need for a FAR SYS command that lets you jump to banked RAM. The RAM bank can easily be switched from BASIC with a POKE 0,[RAM BANK] before using the standard SYS command.

My implementation of FSYS does only switch ROM banks.

That's a good point. Twas just an idea.

[Stefan]

8 hours ago, Cyber said:

I agree with Lorin's approach, that certain requirements have to be met like jumper and so on. And I don't see how this interferes with adding custom file browsers, viewers, editors or even making a completely custom ROM. This really should not be casual. Why would one need a BASIC command that could be executead at any time?

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. Typing for instance POKE 1,[ANY ROM BANK BUT 4 WHERE BASIC IS STORED] will typically crash the BASIC environment.

Without a FAR SYS command, you would need to type in a machine code startup stub in RAM with the MONITOR each time the computer is started. That is not very practical. Or load the startup stub from the SD card, which is also a bit cumbersome.

[Cyber]

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.

[Ed Minchau]

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.

[Stefan]

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

[Scott Robison]

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.

[BruceMcF]

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.

Edited May 15, 2021 by BruceMcF