Q68 Extension bus questions...

Nagging hardware related question? Post here!
User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Q68 Extension bus questions...

Post by Dave »

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!


Derek_Stewart
Font of All Knowledge
Posts: 3929
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: Q68 Extension bus questions...

Post by Derek_Stewart »

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.


Regards,

Derek
User avatar
NormanDunbar
Forum Moderator
Posts: 2251
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: Q68 Extension bus questions...

Post by NormanDunbar »

No! ;)


Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts

No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: Q68 Extension bus questions...

Post by Peter »

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.


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: Q68 Extension bus questions...

Post by martyn_hill »

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.


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: Q68 Extension bus questions...

Post by Peter »

Hi Martyn,

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

Peter


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: Q68 Extension bus questions...

Post by martyn_hill »

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


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: Q68 Extension bus questions...

Post by Peter »

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.


Post Reply