The Sinclair QL Forum

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!

Hi,

I built all the current Q68 boards without an Expansion header fitted.

I am in the process of fitting an expansion header onto the Q68 board.

My preference would be to have the Expansion ports fitted with a male header.

Does anyone have any objections to this.

No!

No! I used a female connector here on one of my boards, but that was not carefully considered. I can easily replace it.

By the way, the original QL extension bus connector also was male.

Hi Derek

I concur with the male-header approach - I have made such mods to my two Q68s in order to tap-off QLNET (as well as adding a 'debug' port during development of the ND-Q68 driver.)

M.

Hi Martyn,

this reminds me that I still need to draw the Q68 extension bus timing diagrams. My apologies for the delay.

Peter

That'd be great, Peter

IIRC, when I was still debugging the Q68-ND driver, I measured each access-cycle to the I/O area at around 1uS - in any case, I had to be cautious in writing the debug byte out to the port during time-critical parts of the ND driver code as it soon started to skew the delicate NET timing... It was very useful however to 'see' where in any given packet the driver lost comms, especially as I started to experiment with speeding-up the bit-rate between a pair of Q68s...

By the way, for realtime-debuging, you have further simple options:

- The I²C clock output at $1C1C0. As long as you don't toggle the data line also, the RTC won't respond. Easy to grab signal on pin 3 of the I²C connector.

- The high-active programmable LED at $1C100. Use the LED pin next to the audio connector, or watch the LED.

- The low-active chip select of the second SD card at $1C340, as long as no card is there.
Use the second pad of the card socket, counted from right (it is the first actually connected pad), or watch the LED.

The single through-hole pad above the SDRAM is GND.