Method for adding firmware to a Commodore 64 expansion card?

Question

The C64 expansion port can and does support multiple IO devices without conflicts. There is 0.5 KiB that is decoded for $DE00-$DFFF, using /IO1 and /IO2 on the expansion port. As long as the devices do not step on conflicting addresses, a multi-card expansion extender can be used to allow connection of multiple cards which could be active simultaneously. You just need to not exceed the ports power budget.

Firmware for such cards isn't as straightforward. The expansion port ROM is mapped to $8000-$BFFF, and there is no inbuilt way to arbitrate multiple IO expansion cards wanting to share that ROM space for firmware.

It's sort of like the Apple ][ bus where there's 256 bytes of potential firmware space for each IO expansion card, but without the sophisticated means to arbitrate access to additional firmware space.

Still, it seems that the 256 bytes of space for IO1 and IO2 on the C64 expansion "bus" could be used to bootstrap loading a device driver into the main system RAM. As far as I know, the C64 has nothing to prevent it from running code in the dedicated IO space $D000-$DFFF (when IO is banked in). So initializing an IO card could be done with a simple BASIC command like "SYS 56832".

Question: Is there either a "de facto" or "recommended" way of providing firmware on a C64 IO card so that it can be used alongside other IO cards? Are there any examples of cards that do this?

Answer 1

It sounds dumb but I think all the multi-module base plates had mechanical switches for the –ROML line of each individual slot. (And one for the –GAME line, of course.)

You needed this in any case, because almost no "standard" software was aware about the fact $8000 to $9fff could be anything else than RAM. No one bothered to set up the processor port correctly before accessing that area.

Answer 2

Simple answer: No, there isn't.

The long read:

The basic issue here isn't address space, but management thereof.

The Apple II not only defines a separeate 16+256 byte address space for each card, it also sets up a protocol to share the 2 KiB extended ROM space and equally important access and entry points to the 256 Byte Area.

On the C64 it's the missing support on the OS (Kernel) level. The only handler provided is detecting and starting an expansion ROM (aka Module). So any reasonably sufficient strategy would need an expansion ROM of it's own, which in turn installs a selector/handler to manage the hardware needed to switch between different modules at run time.

Missing an OS supported Standard also means that no expansion card is made to coexist on a general level. They all assume all of the I/O (and/or ROM) space to be theirs. Effectively requiring a strategy much like the 2KiB ROM selection on the Apple II, but switching all possible components. Eventually even the ROM, which may make cooperation even more complicated.

Further, unlike Münchhausen, even such a switcher needs some foothold in the address space to allow it's use. This will in itself collide with some cards.

As Janka already pointed out, only simple either/or switches, controlled by external input will be compatible with all possible extension. Everything else will be a case by case issue.

Bottom line, Commodore never really thought about extensibility of the C64 systems beside simple cartridge swap.