How is the new zero page banking supposed to work?

[LRFLEW]

I had checked out the project back in late 2019 (after the part 2 video was posted), but stopped paying attention as I got busy with real life. I recently thought about the project and decided to see how it was going. I had done some programming using the emulator back in 2019, so I checked out what changed. I saw that the memory banking changed from being in the VIA IO range to the zero page. When I saw it, I thought it was a cool change, but the more I think about it, the more confused I get.

I don't have much understanding about hardware design (I'm more of a software person), and most of my understanding comes from the Ben Eater videos. What I do understand is that RAM/ROM banking requires something to hold the current banking value and set the address pins on the RAM/ROM chips high or low as needed. I understood how this worked before.; the VIA has the functionality to set and hold output values, which would be used to set the address pins. With the "Proto2" design, the goal was to free up the VIA outputs for other use, but I don't get what's replacing it for banking. Is there another IO chip being added to perform the banking? If so, why wouldn't the banking controls be put in the IO address range? It seems that checking if the address is $0000-$0001 would require a ton of logic gates to make work.

My confusion is compounded by the responses to questions about putting VERA IO in the zero page. There have been discussions about it that have been dismissed without discussion (such as this thread). I feel like I get why putting VERA IO on the zero page is impractical (if not impossible), but the same reasoning I have would also apply to the banking controls. What makes banking different from the VERA interface?

The only answer that makes sense to me is that writing to the banking addresses just sets the value in Low ROM, and the address pins of the RAM/ROM chips are being set by the Low RAM chip when accessing High RAM/ROM. This would also explain why it wouldn't work for VERA IO, as that technique wouldn't work there. However, I can't imagine how you'd get the Low RAM to do that without interfering with the CPU's Data Bus.

I don't need or even want a massively technical answer, as I understand the design is being kept somewhat private for now, and I probably won't understand all of it anyways. I'm just wondering how this is supposed to even be reasonably possible.

[Lorin Millsap]

Those are fair questions and I’ll answer as clearly as I can.

I’ll start with why IO devices of the normal type like the VERA are impractical to put there.

So to begin its good to clarify that it’s important that most of ZP be reserved for the intended ZP usage using a couple registers is fine because it leaves the bulk of the space free. Two registers which were also reserved on the 6510 is not a big deal. But tying up lots of registers is.

I won’t disagree that having the VERA there wouldn’t be very useful, the main reason is you need to create a logic exclusion case where a 32 byte range are read or written from the VERA instead of RAM. This requires a fair amount of logic and that introduces timing delays which can cause lots of problems especially on reads. And creating an exclusion case for VERA (a 32 byte range) is more costly from a component/complexity than turning the entire ZP into IO. But turning the whole range into IO is too costly from a software/overall functionality standpoint to be considered either.

So how then do we do an exclusion for two registers in ZP? The simple answer? We don’t. The bank registers are in fact RAM and latches. We don’t disable the RAM on reads or writes. The RAM at those locations is always active. However what we do implement is a shadow technique where on a write event to those locations a pair of latches (one for each address) will capture the contents of the data bus on the falling edge of the clock. This does not disable the RAM from also latching those same values, and in fact when you read those locations what you are reading back is the RAM, not the latches themselves, since they can’t actually be read. This isn’t a problem since the RAM will always (with one small exception) contain the last written value. The exception is on a hard reset. On a reset the latches always return to zero whereas RAM does not. So in theory after a reset the value stored in RAM and the value in the latch will mismatch. In practice this isn’t a problem since the reset routine will write to those locations which corrects the mismatch.

So the trick we are doing while it does add a few parts, has no impact on the timing of the system. It’s very simple and it’s inexpensive. The parts used cost much less than devoting a relatively costly 65c22 to do the same task. And we aren’t eliminating the 65c22 gets freed up to do more important things. End result is the X16 has more free IO for the user than the Commodore machines did.


Sent from my iPhone using Tapatalk

[LRFLEW]

That makes a lot of sense.

I wouldn't suggest making all the ZP be IO, and wouldn't even suggest placing the entire 32 byte VERA IO in the ZP, as I understand how useful the ZP is. The furthest I'd consider doing is suggesting mirroring the two data ports (VERA_DATA0 and VERA_DATA1) in the ZP, but the complexity for that would be even worse, and the mirroring would be very challenging due to how unnatural it would be, so even I'm not taking that idea seriously.

I had suspected the Low RAM was used when reading the banking state, in part because of how the high bits of address $0001 are undefined. That was how I got the idea that Low RAM might be used to set the address pins of High RAM/ROM. Using latches to hold the banking state makes more sense, though. I still feel that the complexity required to determine if the latches should update would be farily high (having to test 15 address lines and the write enable, plus one address line to determine which latch to change), but it works if you have a cost-effective way of doing that.

The TLDR I got from your explanation about why it works for banking but not VERA IO is basically this: Adding the banking controls to the ZP here doesn't affect whether any of the other components are enabled or not, so it doesn't affect system timings. I'd assume the enable pins on the RAM and ROM (chip enable, output enable, write enable) are the biggest challenges with the system timings. Putting the VERA IO in the ZP would require disabling the Low ROM and enable VERA IO for a narrow address range, which would affect timings.

Thanks for your very detailed response @Lorin Millsap

[Stefan]

Hi @LRFLEW

I think the technique described by @Lorin Millsap would not work for VERA D0 & D1, because it is write only communication to the connected I/O.