Hardware Expansion and Driver Handling

TomXP411 · Post by **TomXP411** » Tue Jan 12, 2021 10:22 am

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

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

https://gglabs.us/node/1933

Lorin Millsap · Post by **Lorin Millsap** » Tue Jan 12, 2021 10:27 am

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

The internal ROM is writable, with limitations. However you may have the routines you can put on slots, that doesn’t mean the KERNAL knows that they exist or how to use them, and patching the routines is actually easier and cleaner to do again through the SD card. Easier to implement and easier to fix if you screw up. Sent from my iPhone using Tapatalk

BruceMcF · Post by **BruceMcF** » Tue Jan 12, 2021 12:57 pm

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

When they went from 128K and 8 ROM banks to 512K and 32 ROM banks, I think that put paid to the assumption that they'd fill up every bank with essential system code.

But given the speed of the SD card, it you fill up a page of Golden RAM and a couple of High RAM segments with drivers, that would load fast enough you wouldn't really notice it.

m00dawg · Post by **m00dawg** » Tue Jan 12, 2021 2:47 pm

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.

BruceMcF · Post by **BruceMcF** » Tue Jan 12, 2021 6:33 pm

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.

I don't know about to/from RAM, but yes, loading the bulk of the drivers into a High RAM segment would by definition use more High RAM than using a ROM slot. They seem like they would be basically equivalent in terms of low RAM use, which would be mostly the routine called directly in the vector chain checking whether the device or file it is managing is being referred to, and if not calling the previous routine in the chain. If it is the one to call, that'd be a far jump and the end of the low RAM usage.

As far as resource conflicts, that comes with the territory of working within resource constraints. A game that maxes out its use of High RAM might need you to cold start the system and then rerun CONFIG when done with it.

It's not that they are stored in ROM that saves the High RAM, it's that they would execute in the ROM window, so they would only need to use a High RAM segment for data.

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.

TomXP411 · Post by **TomXP411** » Tue Jan 12, 2021 6:39 pm

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.

This is why I wanted to see a second slot for user ROMs. David explicitly said, at one point, that he does not want to install an In System Programmer for the KERNAL ROM, so if we want to re-flash the KERNAL, we will have to remove the chip, flash it with a programmer, and re-install it.

m00dawg · Post by **m00dawg** » Tue Jan 12, 2021 6:39 pm

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.

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.

JimmyDansbo · Post by **JimmyDansbo** » Tue Jan 12, 2021 6:43 pm

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.

As I did not previously know of these vectors, I went hunting and found this...

I believe that the Commodore 64 vectors are as follows (and Commander X16 seems to be the same):

$0314-$0315 788-789	Execution address of interrupt service routine. Default: $EA31.
$0316-$0317 790-791	Execution address of BRK service routine. Default: $FE66.
$0318-$0319 792-793	Execution address of non-maskable interrupt service routine. Default: $FE47.
$031A-$031B 794-795	Execution address of OPEN, routine opening files. Default: $F34A.
$031C-$031D 796-797	Execution address of CLOSE, routine closing files. Default: $F291.
$031E-$031F 798-799	Execution address of CHKIN, routine defining file as default input. Default: $F20E.
$0320-$0321 800-801	Execution address of CHKOUT, routine defining file as default output. Default: $F250.
$0322-$0323 802-803	Execution address of CLRCHN, routine initializating input/output. Default: $F333.
$0324-$0325 804-805	Execution address of CHRIN, data input routine, except for keyboard and RS232 input. Default: $F157.
$0326-$0327 806-807	Execution address of CHROUT, general purpose data output routine. Default: $F1CA.
$0328-$0329 808-809	Execution address of STOP, routine checking the status of Stop key indicator, at memory address $0091. Default: $F6ED.
$032A-$032B 810-811	Execution address of GETIN, general purpose data input routine. Default: $F13E.
$032C-$032D 812-813	Execution address of CLALL, routine initializing input/output and clearing all file assignment tables. Default: $F32F.
$032E-$032F 814-815	Unused. Default: $FE66.
$0330-$0331 816-817	Execution address of LOAD, routine loading files. Default: $F4A5.
$0332-$0333 818-819	Execution address of SAVE, routine saving files. Default: $F5ED.

Information taken from https://sta.c64.org/cbm64mem.html

BruceMcF · Post by **BruceMcF** » Tue Jan 12, 2021 6:46 pm

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

Note that if the config script file is opened in a known channel, you can have a program that does condition checking and optional execution by reading the test from the following text, reading the optionally performed action, but only stuffing it into the line buffer if the test was passed. Either way, the subsequent line is next to be read when control passes back to the configuration script routine.

BruceMcF · Post by **BruceMcF** » Tue Jan 12, 2021 6:48 pm

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.

Oh, I'm definitely having some tables and optimized multiply routines, the only open question is how many.