Would this circuit work on a 65xx?

[Dr Jefyll]

Chromatix wrote:

Actually the 68K is very much big-endian.

Yup. On 68K it's the most-significant byte that appears at the lowest address. Our beloved 65xx processors (and the 53xx9x SCSI series) are Little-Endian, expecting the least-significant byte to appear at the lowest address.

Luckily, interfacing 68K with a 53xx9x wouldn't be difficult. The latter has only one word-size register, and it's mapped to byte addresses $00 and $01. The simplest "fix" would be to invert the A0 address input on the 53xx9x, causing all odd-numbered registers to respond to even addresses from the CPU, and vice versa.

[Dr Jefyll]

BigDumbDinosaur wrote:

My code was treating those registers as being in little-endian order and my mention of the XBA instruction was erroneous. So the 16-bit write to registers $00 and $01 should have worked.

Hmm, alright... without the XBA the byte order of the 16-bit write would be correct.

Instead it could be something about the 16-bit write itself that's problematic -- I mean the fact that there are two consecutive accesses to the device. Time to look at the datasheet!

Somewhat unexpectedly, it's seemingly not OK for /CS to remain low throughout two consecutive accesses. tPWH is supposed to be at least 30 ns, but I suspect POC's decoding is such that /CS simply remains low. That's something that could be changed, but probably the payoff is too small to make it worthwhile, given that it's a low-priority issue.

Edited to add: tS and tH (below) make it clear that the address gets clocked in by the falling edge of /CS. We recently encountered the same thing in this topic: Using FM1808 as RAM

-- Jeff

[BigDumbDinosaur]

Chromatix wrote:

Actually the 68K is very much big-endian.

Man! I'm losing it! Dunno what I was thinking when I typed that. Quick! Call the guys with the white coats!

[BigDumbDinosaur]

Dr Jefyll wrote:

BigDumbDinosaur wrote:

My code was treating those registers as being in little-endian order and my mention of the XBA instruction was erroneous. So the 16-bit write to registers $00 and $01 should have worked.

Hmm, alright... without the XBA the byte order of the 16-bit write would be correct.

Instead it could be something about the 16-bit write itself that's problematic -- I mean the fact that there are two consecutive accesses to the device...it's seemingly not OK for /CS to remain low throughout two consecutive accesses. tPWH is supposed to be at least 30 ns, but I suspect POC's decoding is such that /CS simply remains low.

I/O decoding in POC is fully qualified by VDA and VPA. So in theory, a chip select should not occur during the early part of Ø2 low and hence the CF94's /CS should be released for a brief time. I don't know that that is actually happening. At the time I was looking at this problem I didn't have the means to watch all the relevant signals to see exactly what was going on with /CS. I do now, so at some point I will revisit this as a matter of "professional curiosity."

As noted, it's a low-priority thing. Being able to configure the DMA transfer count with a single write makes for aesthetically-pleasing code, but has virtually no effect on performance—the setup is done only once per SCSI bus transaction.

[Chromatix]

Surely if you were latching the pair of accesses to coalesce them into a single word-sized write, /CS staying asserted during that time wouldn't matter?

[Dr Jefyll]

The SCSI controller needs to accept an 8-bit write to address $00 followed by another 8-bit write to address $01. By my reading, the datasheet says we'll need /CS to have one falling edge that clocks in the $00 and another falling edge that clocks in the $01. That implies it must go high in between (and the diagram shows that). Am I missing something? Or is there confusion between BDD's project and tokafondo's?

[Chromatix]

Well, the thread is all about interfacing to an obligate 16-bit device. If we're talking about two different SCSI chips…

[Dr Jefyll]

( I apologize if there's confusion. I believe BDD's SCSI controller is attached in a way that uses only 8 of its pins as a data bus to accept register reads and register writes from the '816. Thus the coalescing of two byte writes into a single word is entirely internal to the controller. tokofondo's proposed project also involves the coalescing of two byte writes into a single word, but using added, external logic. Hopefully BDD and I aren't too grievously off-topic... ... yet! )

BigDumbDinosaur wrote:

At the time I was looking at this problem I didn't have the means to watch all the relevant signals to see exactly what was going on with /CS.

Fair enough. Since you found a way to get the device working it totally made sense to move on. Worth noting, BTW, that that SCSI controller is *quite* an intricate beast! (as a quick skim through the datasheet will reveal).

BigDumbDinosaur wrote:

I/O decoding in POC is fully qualified by VDA and VPA. So in theory, a chip select should not occur during the early part of Ø2 low and hence the CF94's /CS should be released for a brief time.

Hang on, can we unpack that? You seem to imply that VDA and VPA are known to be low during the early part of Ø2 low.

During the period marked by the red arrow, VDA and VPA may indeed be unstable or in flux. But they're no more predictable than the address lines. By that I mean there's no guarantee whether they'll be high or low.

Your scope will show that, during the non-guaranteed period, address lines may glitch but they usually begin with the not-yet-updated value from the previous cycle, then sometime before tADS expires they assume the new value. I think you'll find the same is true for VDA and VPA. Certainly I'm not aware of anything in the datasheet that guarantees they'll go low prior to assuming their new values when tADS has elapsed. (IMO WDC often uses English in a way that's subtley or even wildly ambiguous. I'd much rather listen to what my scope has to say!)

If we need to follow up, BDD, can you suggest which of your POC threads would be most appropriate? Thanks,

Jeff

[Chromatix]

I mentally divide the 65xx signals into "address group" and "data group" with some miscellaneous ones to treat separately.

As the diagram above shows, they all have similar timing specifications within their group. Hence we can expect SYNC, R/W, /VP, VPA, VDA, Axx, and any signals decoded solely from them, to change approximately once - as a group - during Phi1 and be valid-stable at the rising edge of Phi2. But if they don't need to change state between cycles, we should not expect them to.

Hence if we need a particular /CS line to go low between cycles even if that device is accessed on consecutive cycles, then it needs to be qualified with Phi2 - even though that is not needed for normal memory or I/O devices. I suspect such a requirement in these SCSI chips is a result of being designed to interface directly to a multiplexed address/data bus.

[Dr Jefyll]

Trifling quibbles aside, yes. I particularly endorse this (although it's pretty obvious there was a typo): "If we need a particular /CS line to go high (inactive) between cycles even if that device is accessed on consecutive cycles, then it needs to be qualified with Phi2."

[tokafondo]

Chromatix wrote:

A circuit which commits writes on the low address would work for 16-bit RMW instructions but fail on plain 16-bit stores.

It seems to me that the MLB output could be used to differentiate when the CPU is doint plain 16-bit stores or RMW instructions.