Q68 Extension bus questions...

[Dave]

On the Q68 extension bus, can the /DS data strobe be used as a reliable clock, for example as a timer or to clock data into/out of an external device? I know this seems obvious, but there's some subtleties to it I don't understand. If a byte is placed at $1D800, for example, does the /DS cycle one time then latch, or continuously?

Does /DS operate continuously, or only during decoded accesses (ie: where /CS is asserted)? Is it = CLKCPU?

Can the Q68 be powered from 3V3 supplied through the extension bus port, if an external supply is not fitted?

Having a bit of difficulty getting a little something talking reliably.... Yes, I have got the logic analyser out. Yes I have sort-of answers. I just really need "the final word" so I know what to do next.

[ql_freak]

Having a bit of difficulty getting a little something talking reliably.... :D Yes, I have got the logic analyser out. Yes I have sort-of answers. I just really need "the final word" so I know what to do next.

Wow! I know a bit of QL-Hardware!

But here ... I'm out of order...

[Derek_Stewart]

Wow! I know a bit of QL-Hardware!

But here ... I'm out of order...

I have Q68 computers available.

[Dave]

Good that the Q68 continues to be available.

I'm mainly looking for some specific answers because the manual is short on in depth notes and there are cases where the state of the lines could be ambiguous depending on how I interpret "data strobe". My difficulty comes from getting the logic analyser on it and seeing it not behave specifically in one manner or the other. I'll have to export the captures from it and import them here so I can upload them.

[tofro]

I would expect the /DS signal to be roughly the same as UDS/LDS combination on a "real" 68000 - Thus asserted when the address bus and R/W lines are valid - Opposed to /CS, which I would expect to be nearly the same thing, but address-decoded to the expansion bus address range.

Tobias

[Peter]

On the Q68 extension bus, can the /DS data strobe be used as a reliable clock, for example as a timer or to clock data into/out of an external device? I know this seems obvious, but there's some subtleties to it I don't understand.

Sorry Dave, it is my shortcoming not to have documented the timings in the Q68 manual yet. I hardly expected actual use of the Q68 extension bus, like nobody designed an extension for the Q40/Q60. The timings are suited for "typical" classic components with parallel bus, like the CP2200 ethernet controller. But I'm aware this is a very "fuzzy" statement.

Could you allow me one or two more weeks of time? Better documentation is due, I'm simply too busy.

Can the Q68 be powered from 3V3 supplied through the extension bus port, if an external supply is not fitted?

Definitely not, as that would feed back into the voltage regulator. And it would not provide the 5V which is required by several units.

Peter

[Dave]

Specifically, I am trying to get a PCA9502 working. This is a parallel to SPI controller. I have it working on a QL with SGC, using a Q32X245 level shifter.

I have also failed previously with a DP8473V, level shifted by an IDTQ32X245. I built a "generic" quickswitch 3v3 level shifter out of this so I could have a safe, buffered 5V version of the extension bus, just delayed about 2.5us. I hacked the driver to use your addressing scheme. The only problem was my not understanding /DS and how it relates to R/W.

I'm mainly getting hung up with some undocumented behavior with /DS. It doesn't behave 100% like a proper clock, but it doesn't behave 100% like a data strobe either.

When I failed once, I figured it was a me problem. Now I'm seeing if it is a general problem with my understanding of the behavior of /DS.

Yes, a couple of weeks is fine. I only posted here because I figured the answer would be of general interest.

[Nasta]

I'd say /DS can't be used as a clock in any system as it signifies 'some' data to be available or requested by the CPU, which is entirely driven by what the CPU is doing, which instructions it's executing, etc. Not sure why a /CS was supplied extra, I'm guessing it goes low whenever the expansion bus addresses are referenced.
How the signals are used, depends on the device that needs to be interfaced. In general it depends if the device has /RD and /WR in addition to /CS or has R/W and /CS. This is because it depends on what signal tells it that addresses and data are stable.
For the case of /CS, /RD, /WR: /CS is usually treated as an address and /RD or /WR are active when the other signals are stable. So /CS is generated directly from address lines, and /RD and /WR from R/W and /DS. FOr some devices that are interfaced like this (eg. SRAM) /CS /OE /WR are internally gated so whichever signal goes active last and inactive first will determine when the data is/should be stable.
For the case of R/W and /CS: If there is no explicit /DS, then R/W is considered an 'address' of sorts in that it must be stable before /CS goes low. Then /CS must be generated by gating it with /DS. If there is a /DS then /CS is treated as an address and is generated from address lines like in the first case, and /DS then qualifies the signals, and may or may not (depending on application) be gated with a decoder (some devices have automatic power dowm states when DS is inactive).

DP8473V - only pins that drive the Q68 signals need to be converted to 3V3 as the pins that the Q68 drives will be fine with a 3V3 signal. As far as I remember only the data lines need to get the 3V3 treatment. That being said, the driver will have to be hacked extensively as the address lines on the Q68 address words, not bytes, so looking from the Q68, the addresses of the registers inside the DP8473V look spread apart 2:1, only even addresses used (instead of 0,1,2,3... on the (S)GC, it would be 0,2,4,8... on the Q68). The same will hold for any byte wide peripheral connected to the Q68 expansion bus.

PCA9502 - not parallel -> SPI/I2C but SPI/I2C -> parallel, or more precisely 8-bit GPIO. Not the same thing, the arrow does not go both ways (but would be nice if it did!)

[Dave]

I'd say /DS can't be used as a clock in any system as it signifies 'some' data to be available or requested by the CPU, which is entirely driven by what the CPU is doing, which instructions it's executing, etc. Not sure why a /CS was supplied extra, I'm guessing it goes low whenever the expansion bus addresses are referenced.

/CS works as advertised. It functions like a 'global' /AS on a 68000.
R/W behaves as expected.

I'm just unsure what /DS is working from.

How the signals are used, depends on the device that needs to be interfaced. In general it depends if the device has /RD and /WR in addition to /CS or has R/W and /CS. This is because it depends on what signal tells it that addresses and data are stable.

It has R/W where read is high, write asserts low, and I need to check if it is high, undefined or Hi-Z otherwise.

For the case of /CS, /RD, /WR: /CS is usually treated as an address and /RD or /WR are active when the other signals are stable. So /CS is generated directly from address lines, and /RD and /WR from R/W and /DS. For some devices that are interfaced like this (eg. SRAM) /CS /OE /WR are internally gated so whichever signal goes active last and inactive first will determine when the data is/should be stable.
For the case of R/W and /CS: If there is no explicit /DS, then R/W is considered an 'address' of sorts in that it must be stable before /CS goes low. Then /CS must be generated by gating it with /DS. If there is a /DS then /CS is treated as an address and is generated from address lines like in the first case, and /DS then qualifies the signals, and may or may not (depending on application) be gated with a decoder (some devices have automatic power down states when DS is inactive).

I'm kinda looking for documentation so I can answer these very points and know exactly what is needed. It's probably ridiculously obvious and I'm just missing it because it looks a little different on the scope than I am used to, is all.

DP8473V - only pins that drive the Q68 signals need to be converted to 3V3 as the pins that the Q68 drives will be fine with a 3V3 signal. As far as I remember only the data lines need to get the 3V3 treatment. That being said, the driver will have to be hacked extensively as the address lines on the Q68 address words, not bytes, so looking from the Q68, the addresses of the registers inside the DP8473V look spread apart 2:1, only even addresses used (instead of 0,1,2,3... on the (S)GC, it would be 0,2,4,8... on the Q68). The same will hold for any byte wide peripheral connected to the Q68 expansion bus.

I made up a little level converter board for all lines so I didn't have to "be careful". It's just there for anything I want to spontaneously throw at it. In a production design, I would use better economy of design.

I think I have the driver right. I just edited the register and R/W addresses to be double spaced to match the Q68 addresses. The data seemed to be latched ok. I made /RD by inverting /WR. /CS was 1:1 match. I didn't get into it too much - was just seeing if it was going to be "straightforward" as people might like being able to chuck their Q68 underneath a single floppy in a double floppy case, internal PSU, etc (Yeah, I might have a nice design for it. Maaaybe.)

PCA9502 - not parallel -> SPI/I2C but SPI/I2C -> parallel, or more precisely 8-bit GPIO. Not the same thing, the arrow does not go both ways (but would be nice if it did!)

Yeah. But.

Was using it from an AVR chip to try to query the Q68 for data. It does kinda work 2-way if you configure it so the /IRQ pin asserts if there's IO activity on either side. It then switches direction by the AVR setting bit 7 of IODir at +$0A - so the Q68 is a slave, but can prompt the AVR to fetch. That was all part of figuring out and understand configuring parallel ports on the AVR - just a learning exercise. That way, the AVR just has to keep track of if it caused its own interrupt request, or if it was externally triggered. It's half working, and the bit that isn't is not the direction switching. It's the Q68 sending bytes at irregular enough intervals that it's being flagged as a timeout, I think. It's not a big deal - it's just a learning platform.

If you're seeing the flaw in what I am doing, the missing piece of info is that I wanted to get it working with an external device, then I was going to fold it back to the AVR and have it talk to itself, like an external loopback mode. That way I could develop and test both sides of library code I want, and really shake them down in an environment where something else is happening on the AVR; ie: it is transmitting and receiving simultaneously and handling both sides without error. If it can do that, it can listen to QLNET and pay attention to register accesses from the QL too

[Nasta]

I can only make educated guesses here, based on how things generally work or how I'd implement it.
Normally, R/W would be a copy of the internal R/W of the CPU. On 68k R/W is set up even a bit before the address lines are.
/CS would then be generated from the invisible address lines (high order) to decode the IO area address range. This means valid /CS would appear a bit after valid addresses and hang on about the same time after the address lines are no longer valid. Since the FPGA is quite fast, this delay is very short (few ns), so we can say it's more or less valid together with the address lines.

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.

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.