Nasta wrote:The important point here is that addresses, /CS, R/W and in case it's a write, the data MUST be valid BEFORE /DS goes low, and stay valid for a while AFTER /DS goes back high again. This is because any device needs data to be set-up before it writes it internally as well as held after that for a while, to account for all the internal logic delays. In some cases it will be just one of the edges (usually rising as this leaves the maximum time for the internal logic of the device to figure out where the data is supposed to go) where the device latches the data it gets from the data bus.
In case of a read, the device again has to have address and /CS and R/W stable so it knows what to do, i.e. which internal address to present on the data bus, which will take some time (similar to access time on RAM) after /DS goes low, the falling edge being the 'trigger' to 'do the read'.
What this means is, it should be easy to check with a scope if /DS is low for a shorter time than /CS.
That does pretty much match what I was seeing.
There's a couple of aspects of this extension bus that frustrate me. They are no reflection on Peter's work - he did not expect anyone to use it.
The first is that there is only one ground pin and it is at the end of the connector, not in the middle. It carries quite high speed signals with very fast transitions, so noise control is important. Two extra pins would have allowed two more ground points in the connector; which I would have considered a nice gesture towards usability.
The second is the absence of any kind of clock (CLKCPU). This forces any extension to operate asynchronously, or to have very tight design considerations.
If I had my druthers, I would make the bitbang I2C port (which I suspect is an I2C port in name only, it really is a universal bit-bang port, as are any of the controlled LEDs - and any of these could be used as QLNET or I2C or a relay control signal, etc.) into the QLNET port and turn the extension but QLNET port into CPUCLK or the high speed timer or something synchronous with something.
[quote="Nasta"Regarding the I2C/SPI bridge - the above should tell you what signal you should use to 'trigger' the interrupt. If you only use the data, it is ONLY stable when /CS and /DS are low, which may well be too short for the device to see, and especially far to short for the AVR to process the interrupt and still properly read the data. In order to do that correctly, the data has to be latched using /CS and /DS and the relevant address (otherwise any IO address will trigger the interrupt).
Unlike the real 68k, there is no /DTACK so the timing, i.e. how long /DS is low, is fixed, no way to extend it.[/quote]
Yeah, it's short. I was capturing the whole thing so my sample rate was too short, but I intend to go back and redo my capture a bit at a time to build a much clearer picture. 85 ns +/- 15 ns? In a "real" 68000 I would expect UDS/LDS to assert for around 4.5 ticks. On this Q68, assuming(!) 40 MHz master clock, that should be around 100 - 110 ns?
What I really need to do is sample fewer channels at a higher rate. To get any kind of honesty out of the logic analyzer the sample rate needs to be at least 200MHz, which limits me to 8 channels.
Anyhow, the big thing I am getting out of this is logic /AS OR /DS = time to go!