On 11/2/2021 at 8:31 AM, BruceMcF said:
Since the IO memory mapped "slot" design is eight slots of up to 32 addresses each, the CS is likely for the full $9F20-$9F3F range and A0-A4 as register addresses.
You are correct - I'm not sure why I thought each IO had 16 addresses. It might be because the VIAs share a single 32 address range.
On 11/2/2021 at 8:31 AM, BruceMcF said:
If the bus side interface is asynchronous to the Vera internal clock, then using PHI2 low when CS-IO1 is low would be a reliable state indicating A0-A4 lines valid, while doing a count from CS-IO1 dropping low might be less robust, since the delay from rising edge of PHI2 and A0-A4 being valid not be synchronous with the 50MHz clock.
So if there are enough 50MHz cycles within a single 8MHz /PHI2 phase to allow use of CS-101=PHI2=0 as a valid address line state, adding PHI2 as the eighth bus control line would be simplest. If not, then worst case from the earliest possible detection of the drop of CS-IO1 to the latest possible valid A0-A4 lines could be used with a counter of 50MHz cycles.
I believe that a problem here is that the state of the address bus is indeterminate from the end of tAH until the end of tADS. It's possible, and legal, for them to briefly have $9F2x/$943x during that time which would cause the address decoding logic to briefly toggle VERA's CS. For the SRAM and flash NAND components, a glitched CS isn't a big deal because they are completely asynchronous components. However for VERA, I don't think that's the case. One of negedge CS or posedge PHI2 is going to strobe the design to latch the address bus (and possibly the data bus) and respond to it. For this reason, I would suspect that CS and PHI2 must be ANDed together for VERA. This would match with what Adrian said in his X16 video (VIAs will not work if CS is ANDed with PHI2 because CS will not have propagated to the internal edge-sensitive flipflop in the VIA when the edge of PHI2 arrives and the access will get ignored)..
If so, VERA (or any similar IO device that cannot handle CS de-assertions mid-operation) would have from posedge PHI2 until start of tDSR to put valid data on the data bus. With a 62ns high pulse width, a 10ns tDSR, and 6ns x 2 crossing the bus transceivers, that's exactly 40ns or 2 cycles of a 50MHz clock left over. Because we can't be certain of the alignment between the VERA clock and the system clock, we can assume that if VERA's bus interface were synchronized with its system clock, it would have to be able to respond in a single 50MHz clock in order to stay within timing constraints. If it took 2 clocks (1 to latch the input and 1 to update the data bus), then it is possible that VERAs clock edge would hit just before CS is strobed and VERA would have to wait a minimum of half a clock (10ns) to check again (if not one full clock) meaning 2.5-3 clocks (50-60ns) to respond. Hence the reason I suspect the bus-facing logic may be completely asynchronous to the system clock or have single cycle latency.
I think this only hits read operations. Writes can be posted. This timing sensitivity would impact SD accesses (which are read intensive) far more than most graphics operations (which are write intensive).