Commander X16

5 hours ago, BruceMcF said:

Though the easiest way altogether is just use one of the however many User available FlashROM banks, because the selection logic for that is already done.



It would be straightforward to program the kernel to do a Far call to a specific ROM bank entry point based on the startup code stored in the RTC. Indeed, that could be the autostart mechanism ... if nothing is selected, the utility stores the ROM bank entry point for Basic COLD start, if you select autostart, the utility stores the ROM bank entry point for the autostart routine in Kernel, and you can explicitly specify a Far call location to run start-up code stored in a User segment of FlashROM.



BTW, FlashROM segments are 16K.



A parsimonious way to support ROM on an expansion card would to put the bits of the ROM bank out on an eight pin block header, and a ROM expansion card simply has it's own matching pin block header and a ribbon cable, with the specification that bit7 should be high to select external ROM and then bit5&6 select which card is being addressed. That allows 128K ROM per card. Then the extension required to the prototype logic is simply that internal ROM is not selected when bit7 is high ...



... then it's up to the card to detect that the address is in the ROM range at the same time that the high bit of the ROM bank is high, but that's only ROMB7=A15=A14=1, and ROMB5:ROMB6 matches the value in the jumper block.



But I don't know if the game is worth the candle, since with a single User FlashROM segment you can easily have the program support to access 3-wire serial ROM, and if there are enough GPIO free on the Serial Port after supporting the bit banged serial port, you can bit bang one of the serial ROM interfaces and have thee select pins to allow a User port daughter-board with four sockets for 3 wire serial ROM. Ditto on an expansion card, except it includes the VIA ... but same programming, just different I/O space.



And just as easily, a User FlashROM segment can just load a set of RAM segments with code on the SD card, and you have the equivalent effect, with no additional hardware overhead. And the files from the SD card would likely load faster than data from a serial ROM if it uses base I2C or 3-wire Microwire.



 

I'm making the (perhaps unfounded) assumption that the system ROM banks will all be occupied. If not, then the obvious answer is to flash the system ROM... and hope you don't screw it up.  [emoji2] Maybe something like the GGLabs Flash ROM, which sits in a DIP carrier....   https://gglabs.us/node/1933  

2 hours ago, TomXP411 said:

I'm making the (perhaps unfounded) assumption that the system ROM banks will all be occupied. If not, then the obvious answer is to flash the system ROM... and hope you don't screw it up.  ?



Maybe something like the GGLabs Flash ROM, which sits in a DIP carrier....  



https://gglabs.us/node/1933



 

3 hours ago, m00dawg said:

The SD card bit still confuses me a little bit - is it correct to say that for heavierweight drivers this could require more RAM than if they were stored in ROM? I'm thinking say like some sort of network or serial API to various hardware cards where the driver might be hiding a lot of the low level details so programs just have to worry about reading or write bytes or some such. Here I could see lots of jumps over to driver routines to do things where ROM might be more efficient than having to shuffle RAM around or to/from the SD card? Thinking about a big program here (say a game with lots of music and graphics being loaded into banks and things).



I do agree, though, that updating drivers would be much easier (and safer) using the SD card for sure. I know folks are worried about blowing away the kernel on the main ROM but a jumper to the WE pin might suffice for that? Might be slightly annoying to open up the case on a driver update, but one would have to do that to initially install the card anyway and I suppose brave souls can leave WE enabled. I'd imagine folks that have a ROM reader can just back the chip up directly and, if the kernel did get blown away, can just reflash the chip. Of course not everyone will have the capability (or desire) to do that.

6 minutes ago, BruceMcF said:

I don't see that the WE for the flashROM would be left enabled ... filling in a User slot would be something done with a substantial amount of care, and I would very much prefer a card for which it is an option, but not the only option, so soft loading the driver into one or more High RAM segments is also an option. But once a ROM slot has been written, the WE can be bumpered out again to return to "less likely to brick your board" mode.

4 minutes ago, BruceMcF said:

I don't see that the WE for the flashROM would be left enabled ... filling in a User slot would be something done with a substantial amount of care, and I would very much prefer a card for which it is an option, but not the only option, so soft loading the driver into one or more High RAM segments is also an option. But once a ROM slot has been written, the WE can be bumpered out again to return to "less likely to brick your board" mode.

On 1/11/2021 at 6:59 AM, BruceMcF said:

On 1/10/2021 at 9:04 PM, Cyber said:

I thought KERNAL would be in ROM, and would run directly from there. So how do I change its vector entries in ROM?

There is a set of vectors that various I/O routines use, between the hardware stack at $01xx and the Golden RAM at $0400-$07FF.

20 hours ago, Lorin Millsap said:

On a lot of this it boils down to system side software support, much of which is not yet implemented.



An idea I advocate is that the config files are in plain text, and that some code in the KERNAL reads them one line at a time and then dumps them into the buffer in BASIC, so line numbers don’t matter so much, and a program getting overwritten is less of an issue as it’s just doing it all in immediate mode. There are some limitations to this, things like condition checks and branches often rely on line numbers. But it would work well enough for loading in subprograms, including assembly. If it calls an assembly program we just have to trust that it returns control, otherwise the rest of the “script” won’t get executed.





Sent from my iPhone using Tapatalk

7 minutes ago, m00dawg said:

That was more highlighting my preference since, in a pinch, I could just reflash the ROM. Unless it's some crazy part, I already have a ROM burner I used for other projects. In general though, I agree, the expectation should probably be to only enable said jumper during the installation process of a card or a driver upgrade?



These seems like rare events, relative to day to day use anyway, to the point that I think it would be a reasonable approach - if one that needed to be well documented. To eb it's just too tantalizing not to use all that available ROM space for something.