Access to banked memory by expansion cards

[Martin Schmalenbach]

Do expansion cards of any/all types, whether using the dedicated IO slots or accessing the full 64K address space seen by the CPU also get to 'see' the same banked ROM & RAM as the CPU does?

I'm working on an expansion card design that could really do with accessing at least one of the 8K RAM banks, if not more of them...

Is it possible for an Expansion card to change the RAM bank arbitrarily, and, assuming it puts it back to the bank that was selected prior to the expansion card doing its 'thing', operate without messing up the rest of the system?

For similar reasons can an expansion card access the VERA registers and internal memory space?

Thanks in advance.

[DragWx]

The exact same address lines and data lines which go to the CPU are also available on the expansion connectors, so an expansion card will be able to access literally everything the CPU can access, and each memory address will behave just like they would if you were writing a program.

To switch banks, you do it the same way a program would: your card needs to perform a "write" to address $0000 for RAM or $0001 for ROM, using similar signaling to what the CPU would do when it performs such a write.

The VERA's internal memory and internal registers are still only accessible from the usual VERA registers ($9F20..$9F24), there's unfortunately no direct access to them.

[Martin Schmalenbach]

The exact same address lines and data lines which go to the CPU are also available on the expansion connectors, so an expansion card will be able to access literally everything the CPU can access, and each memory address will behave just like they would if you were writing a program.

To switch banks, you do it the same way a program would: your card needs to perform a "write" to address $0000 for RAM or $0001 for ROM, using similar signaling to what the CPU would do when it performs such a write.

The VERA's internal memory and internal registers are still only accessible from the usual VERA registers ($9F20..$9F24), there's unfortunately no direct access to them.

Thanks for clarifying that. It's what I thought it might be, but I don't want to commit to building hardware and get it wrong. A core part of my design uses a part that has a 1 year lead time at the moment!

So, it looks like I can page an 8K bank in and out and that can be used as a buffer for transferring relatively large amounts of data between the motherboard and the expansion card.

I guess first thing is for the Expansion Card to read those 2 addresses and save the values in them, to be written back once the Expansion card has finished its thing.

[spargue]

The design could have been much improved by allowing the BANK pins to go high Z with the CPU pins and drive them via an expansion card for gull ROM / RAM access with little overhead, but as the BANK pins are tied directly to the latch they stay locked to the RAM ROM banks the CPU can see.
Be careful of doing bus access during an interrupt sequence as this will mess up the interrupt vectors on ISR exit. Currently, there's no easy way to detect if the CPU is in an ISR. So it may have to be a polled sequence with the CPU's go-ahead.

[Martin Schmalenbach]

The design could have been much improved by allowing the BANK pins to go high Z with the CPU pins and drive them via an expansion card for gull ROM / RAM access with little overhead, but as the BANK pins are tied directly to the latch they stay locked to the RAM ROM banks the CPU can see.
Be careful of doing bus access during an interrupt sequence as this will mess up the interrupt vectors on ISR exit. Currently, there's no easy way to detect if the CPU is in an ISR. So it may have to be a polled sequence with the CPU's go-ahead.

Thanks - that's good to know... my code for handling the relationship between the main system and the expansion card will need to take this in to account.

IRQs are easy enough in a sense, just disable until the expansion card is done... NMI not so much!

I'm sure a more expert perspective will be along soon to educate me (and I need it!!) on the dangers/undesired outcomes of disabling IRQs for a while. It's education I could really use.

[spargue]

From what's been made public of the design and the VPB latch mod I'm not sure if NMI can be accounted for without some HW rework of the main system. Ultimately several design choices have crippled some novel implementations of expansion and you have to do everything the slow way without any form of modern acceleration. I'm not really sure the VPB latch mod is 100% sound as it would change the latch before exiting the ISR. So ISR has to exit from a ram instruction rather than a form a ROM instruction.

[DragWx]

Based on photos, the vector pull mod just seems to be one wire that was added between VPB of the CPU to /MR of the 74ACT273 octal latch for the ROM bank number.

The reason for doing this is so when the CPU wants to read one of the vectors at $FFFA..FFFF, those vectors always come from $00:FFFA..00:FFFF.

When vector pull happens, the ROM bank latch is physically reset to bank 0, but the underlying RAM is not, so reading $0001 will still accurately give you what the current ROM bank is "supposed" to be. Both IRQ and NMI point to trampolines in RAM (i.e., ROM bank doesn't matter) and the very first thing they do is read $0001, push it, and set $0001 to zero, so now everything is consistent.

If you were to hypothetically pause the CPU right as it finishes its vector pull, then the CPU is finished "needing" the bank to be 0, and you're free to manipulate $0001 however you need, including reading what its current value is and saving it so you can restore it when you're done.

The only gotcha I can think of is, if it were possible to pause the CPU while it's in the middle of a vector pull, then the ROM bank latch would be locked to 0 with no way to change it. However, the CPU's SYNC pin is available at the expansion ports; if the CPU is currently fetching an opcode, then it isn't doing a vector pull.

I think the whole shebang is just fine, but there might still be something I haven't thought of.

[spargue]

Based on photos, the vector pull mod just seems to be one wire that was added between VPB of the CPU to /MR of the 74ACT273 octal latch for the ROM bank number.

The reason for doing this is so when the CPU wants to read one of the vectors at $FFFA..FFFF, those vectors always come from $00:FFFA..00:FFFF.

When vector pull happens, the ROM bank latch is physically reset to bank 0, but the underlying RAM is not, so reading $0001 will still accurately give you what the current ROM bank is "supposed" to be. Both IRQ and NMI point to trampolines in RAM (i.e., ROM bank doesn't matter) and the very first thing they do is read $0001, push it, and set $0001 to zero, so now everything is consistent.

If you were to hypothetically pause the CPU right as it finishes its vector pull, then the CPU is finished "needing" the bank to be 0, and you're free to manipulate $0001 however you need, including reading what its current value is and saving it so you can restore it when you're done.

The only gotcha I can think of is, if it were possible to pause the CPU while it's in the middle of a vector pull, then the ROM bank latch would be locked to 0 with no way to change it. However, the CPU's SYNC pin is available at the expansion ports; if the CPU is currently fetching an opcode, then it isn't doing a vector pull.

I think the whole shebang is just fine, but there might still be something I haven't thought of.

I feel this could have been done better with a 74xx688 configured to look for the RTI instruction so a VPB could set a signal on interrupt and the 688 with SYNC could clear it. This is what the DMA line did on the C64 / 128. It told HW that DMA was not a good idea right now.

[Wavicle]

Do expansion cards of any/all types, whether using the dedicated IO slots or accessing the full 64K address space seen by the CPU also get to 'see' the same banked ROM & RAM as the CPU does?

I'm working on an expansion card design that could really do with accessing at least one of the 8K RAM banks, if not more of them...

Is it possible for an Expansion card to change the RAM bank arbitrarily, and, assuming it puts it back to the bank that was selected prior to the expansion card doing its 'thing', operate without messing up the rest of the system?

For similar reasons can an expansion card access the VERA registers and internal memory space?

Thanks in advance.

Yes. Your card should *read* $00 to see what the current RAM bank is first, it can then write to $00 to do its thing and then should restore $00 when done.

You could also consider the ROM banks since banks 32-255 are nominally available and those address signals are at the card edge. That way the RAM you need access to could live on your card.

[Wavicle]

From what's been made public of the design and the VPB latch mod I'm not sure if NMI can be accounted for without some HW rework of the main system. Ultimately several design choices have crippled some novel implementations of expansion and you have to do everything the slow way without any form of modern acceleration. I'm not really sure the VPB latch mod is 100% sound as it would change the latch before exiting the ISR. So ISR has to exit from a ram instruction rather than a form a ROM instruction.

I'm the one that proposed using the VPB signal as an additional reset to the ROM bank latch and I looked at it fairly closely. Ultimately the decision was VPB as the only signal, which I disagree with but that's because I'd like an advanced debugger to insert itself after reset but before the CPU starts executing anything in a known state. For all other situations, VPB is adequate. VPB is always asserted on the negative phase of the first cycle of a vector pull. VPB does not glitch during non-vector pull operations and ISR does not initiate a vector pull hence I'm not sure what the concern is.