Commander X16

On 10/14/2021 at 3:33 PM, TomXP411 said:

If I recall, the system clock is also driven by VERA. ...

I had once been under that impression, but AFAIU, no, the system clock is on the board, and the bus interface is not synchronized with the internal Vera clock.

I believe that driving the system clock from a countdown from the internal FPGA clock may have been one idea for handling the problems with interference between bus interface they added to the Gameduino and the actions of the J1 coprocessor that the Gameduino included, but that since Vera doesn't have an embedded processor core, it doesn't have the same problem.

On 10/14/2021 at 1:33 PM, TomXP411 said:

If I recall, the system clock is also driven by VERA. In that case, there would be firmware changes needed for VERA to live on an 8080 style system. Either VERA would need to generate the clock, or you'd have to drive the I/O side independently from the GPU side of the core. In either event, you might as well modify the bus sequencing to account for 8080 style I/O while you're at it. 



 



 

This is incorrect. The VERA is designed so that it’s buss interface is independent of the host clock because we want it to work on other systems. It does not generate the system clock. 

On 10/19/2021 at 1:41 PM, Lorin Millsap said:

This is incorrect. The VERA is designed so that it’s buss interface is independent of the host clock because we want it to work on other systems. It does not generate the system clock. 

Thanks. I know I remembered some  conversation about that, but it might have been one of those passing "this is what we're thinking of doing" things. 

 

On 10/19/2021 at 5:31 PM, TomXP411 said:

Thanks. I know I remembered some  conversation about that, but it might have been one of those passing "this is what we're thinking of doing" things.

As I mentioned, it may have been a proposal ... and quite possibly not from the design team ... to deal with a Gameduino problem that simply doesn't exist with Vera, as Vera has no embedded co-processor core. That would have been almost near the end of the "Gameduino video display era".

That discussion would have been long before this site was built, so it would be lost in the morass that is the FB discussion system.

h/t @Lorin Millsap for confirming that the Vera "register" access is not synchronous with the Vera VGA dot clock.

On 10/19/2021 at 3:12 PM, BruceMcF said:

h/t @Lorin Millsap for confirming that the Vera "register" access is not synchronous with the Vera VGA dot clock.

I think what was said is that VERA register access is async to the host system clock. It likely is synchronous to either the PLL-derived dot clock or the system clock. My guess would be it has a 48MHz clock, like the x8, giving it a 21ns cycle time which would make VERA accesses look very similar to the 40ns SRAM.

 

On 10/13/2021 at 5:16 PM, BruceMcF said:

From what they've said before, exactly ... 8 I/O pins connect to the data bus, 5 I/O pins connect to A0-A4, and from that I would guess three more pins allocated for chip select, R/W and PHI2, with all the lines from the 6502 level shifted to 3.3V.

PHI2 isn't needed, so the "obvious" 8th pin would be IRQB, however unlike the data bus which is bidirectional or A0-A4, CS, and RW which are input only (to VERA), IRQB is output only. The 65C02 datasheet says Vih must be Vcc * 0.7 (3.5V) which is close to 3.3V, but 3.5V isn't an approximate value, it is an absolute minimum so while driving IRQB directly from VERA at 3.3V will work most of the time, it isn't guaranteed to trigger reliably. (Oh man was that embarrassing, IRQB is active low, it says it right in the signal name. It shouldn't be a problem driving it from VERA as long as there wasn't an issue with the pin normally pulled up to 5V.)

On 10/27/2021 at 10:07 PM, Wavicle said:

I think what was said is that VERA register access is async to the host system clock. It likely is synchronous to either the PLL-derived dot clock or the system clock. My guess would be it has a 48MHz clock, like the x8, giving it a 21ns cycle time which would make VERA accesses look very similar to the 40ns SRAM.



 



PHI2 isn't needed, so the "obvious" 8th pin would be IRQB, however unlike the data bus which is bidirectional or A0-A4, CS, and RW which are input only (to VERA), IRQB is output only. The 65C02 datasheet says Vih must be Vcc * 0.7 (3.5V) which is close to 3.3V, but 3.5V isn't an approximate value, it is an absolute minimum so while driving IRQB directly from VERA at 3.3V will work most of the time, it isn't guaranteed to trigger reliably. (Oh man was that embarrassing, IRQB is active low, it says it right in the signal name. It shouldn't be a problem driving it from VERA as long as there wasn't an issue with the pin normally pulled up to 5V.)

VERA has a 50Mhz clock.

On 10/27/2021 at 9:07 PM, Wavicle said:

PHI2 isn't needed, so the "obvious" 8th pin would be IRQB

Looking at screen caps again, I'm going to amend my guess and say that I think VERA probably has two CS# pins. There's a CD74ACT138E that I assume is being used to generate the IO CS# signals and I don't see anything to combine the $9F2x and $9F3x range signals.

I can also see VERA has two SN74LVC4245A bus transceivers, which makes me think maybe VERA IO reads are fully asynchronous. Synchronizing to the 50MHz clock and having the ability to respond on the same clock cycle the bus is sampled still means a worst case of say 39ns (if CS# was asserted 1ns after the clock edge VERA samples on) and adding to that the delays crossing two bus transceivers (2 * 6ns), the mux (10ns), and the read hold time (10ns), the result exceeds the 62ns pulse width. This would probably hit SD card access the hardest since graphics operations tend to be write heavy.

On 10/29/2021 at 6:51 PM, Wavicle said:

Looking at screen caps again, I'm going to amend my guess and say that I think VERA probably has two CS# pins. There's a CD74ACT138E that I assume is being used to generate the IO CS# signals and I don't see anything to combine the $9F2x and $9F3x range signals.



I can also see VERA has two SN74LVC4245A bus transceivers, which makes me think maybe VERA IO reads are fully asynchronous. Synchronizing to the 50MHz clock and having the ability to respond on the same clock cycle the bus is sampled still means a worst case of say 39ns (if CS# was asserted 1ns after the clock edge VERA samples on) and adding to that the delays crossing two bus transceivers (2 * 6ns), the mux (10ns), and the read hold time (10ns), the result exceeds the 62ns pulse width. This would probably hit SD card access the hardest since graphics operations tend to be write heavy.

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.

It seems like one 74x424 can be used for the eight data lines, with Data Direction tied to R/W and output enable tied to CS-IO1, and the other one tied 5v->3.3v only for the address lines and passing through the CS-IO1, A0-A4, R/W and possibly one more to Vera.

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.

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

On 11/3/2021 at 5:48 AM, Wavicle said:

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

Yes, although if it is on CS alone, it in any event requires a countdown from /CS to A0-A4 assured valid, and so that countdown requiring /CS at each tick would cover that.

However, it is simpler to .AND. CS & PHI2, since address lines are valid throughout /PHI2. It might be faster if CS and PHI2 are driven through the transceiver and then the AND takes place inside Vera, but it is more parsimonious of pins to AND CS and PHI2 externally and drive that /VeraSEL through the transceiver.  And a single /VeraSEL is more flexible in interfacing to a variety of buses.

SD should not be an issue reading in a single clock, since the access to the SPI data port can be organized to be entirely parallel to the Vera pipeline generating the next display row using SPRAM data. The possible contention is when there is a read of port A or port B. If the pipeline is organized to access the SPRAM in alternate clock cycles, then the non-contenting approach is to use the other clock cycle for system bus to SPRAM operations, which may require two Vera internal clocks. If the pipeline is organized to access the SPRAM in every clock cycle and is simply paused when there is a system bus to SPRAM operation, then perhaps the internal read can be accomplished in a single internal Vera cycle.