A3000 SCSI DMA restrictions

[mark_k]

Apparently in the A3000 earlier(?) revisions of DMAC and/or Ramsey can only perform DMA to longword-aligned addresses (and length a multiple of 4). Does WinUAE emulate that?

From a post by Rico Tudor of CBM in this comp.unix.amiga thread in July 1991:
"In response to Frank Edwards, note that Amiga DMA must be a multiple of 4
for the A3000, and 2 for the A2090/A2091. Any residual bytes will be
swallowed silently by the hardware."

Also see this thread in de.comp.sys.amiga.misc from 1998.

I wonder which chip revs need longword-aligned pointer and length? The A3000 SCSI driver source has a clue:

; we need to detect if we are using a Boyer DMA chip (which can only DMA to
; longword aligned addresses) or a new DMA chip.  The new chip doesn't
; support word transfer count so we can use this to determine which chip
		bclr.b	#STB_FixBoyer,st_Flags(a5) assume not Boyer chip
		move.w	d0,WTCL(a4)		not using word xfer count
		cmp.w	WTCL(a4),d0
		bne.s	NotBoyer
		subq.w	#1,d0
		move.w	d0,WTCL(a4)
		cmp.w	WTCL(a4),d0
		bne.s	NotBoyer
		move.w	#$5555,d0
		move.w	d0,WTCL(a4)
		cmp.w	WTCL(a4),d0
		bne.s	NotBoyer
		bset.b	#STB_FixBoyer,st_Flags(a5)	got a boyer chip
NotBoyer:

and later:

**** software fix for hardware bug.  If WTCH is writeable then we have the
**** A3000 Boyer DMA chip which can't DMA to word aligned addresses, it has to
**** be longword aligned.  If we are doing a transfer to an odd word address
**** then we have to use programmed I/O.

[Toni Wilen]

Original A590/A2091 was "Boyer" variant (DMAC-01)
DMAC-02 fixed it also changed few registers (=not 100% old software compatible, it wasn't just a bug fix). This is optional in WinUAE.

Having 2 A3000 DMAC variants too sounds too strange and at least A3000 "1.4" ROM won't do any WTC accesses.

"Any residual bytes" sounds more like the DMAC does not transfer all bytes if length is not 4 byte divisible but supports word address alignment. "Boyer" DMAC = DMA address must be long word aligned.

[mark_k]

I should probably have written SDMAC not DMAC. The Super DMAC (SDMAC) chip in the A3000 is different from the DMAC in A590/A2091.

After some more searching on Google Groups (I'll post some links to the threads later) it seems the situation is this:
- The earliest A3000s came with SDMAC-01. That was unreliable and quickly replaced with the -02 rev.
- SDMAC and Ramsey versions are related. Valid combinations are SDMAC-01/02 with Ramsey-04, and SDMAC-04 with Ramsey-07.
- Mismatching chip versions (e.g. SDMAC-04 with Ramsey-04) causes problems because scsi.device thinks odd-word-aligned DMA is OK, but the older Ramsey can't do that. Mask=0x7FFFFFFC is needed as a workaround otherwise you see data corruption.

SDMAC-02 with Ramsey-04 can't do odd-word-aligned DMA. The 1.4 ROM was probably built before SDMAC-04 was designed, so it probably (I didn't check) only uses DMA to/from longword-aligned addresses. Of course that will also work with SDMAC-04/Ramsey-07. Or perhaps A3000s shipped with Mask=0x7FFFFFFC for all partitions on the HD?

Anyway, I can think of at least one reason why emulating the two behaviours (not talking about mismatched chip revs here) could be helpful: Someone working on AROS/NetBSD/Linux/otherOS SCSI driver could check it works on both old and new A3000s. If emulating SDMAC-02/Ramsey-04, you could log attempted non-longword-aligned DMA.

[Toni Wilen]

It isn't that simple that emulate..

How does it behave? SDMAC obviously does have address bit 1. RAMSEY ignores it? Ignores it in some specific circumstances? For example if transfer length is not long aligned but word aligned, does it drop the last word.

[mark_k]

At a guess, just rounding DMA pointer and length down to a multiple of 4 might replicate what happens with non-longword-aligned transfers on SDMAC-02/Ramsey-04. But maybe on real hardware there are other effects. E.g. last word of transfer is left in FIFO, so it gets written to memory at start of the next DMA transfer? Real-A3000 testing would help. But for emulation usefulness, just emulating old-SDMAC such that the 3.1 scsi.device think's it's present (WTCL register writeable), and logging any non-aligned transfers would be enough I think.

Some newsgroup links...

Post from Roger Nordin:
Well, I have had some very detailed explanations and suggestions sent to me by
Dave Haynie (thanks Dave!). Using a rev 3.0 board in an A3000 is definatly not
a good idea, although the problem with DMA devices (such as the on-board SCSI
host adaptor in the A3000!) apparently occurs only in rather special
situations...

However, my problem was related to using SDMAC-04 with RAMSEY-04, which is an
incorrect combination. The SDMAC-04 thinks the RAMSEY can do non-longword
aligned DMA transfers (RAMSEY-07 can, and SDMAC-04 was designed for use with
that RAMSEY rev) and RAMSEY-04 then generates an incorrect address count for
such operations, resulting in data corruption.

Dave suggested that setting Mask=0x7ffffffc for the SCSI partitions might help
in trying to restrict SCSI DMA transfers to longword aligned buffers. However,
I never tried that, because I managed to go back to SDMAC-02 and RAMSEY-04 (a
correct combination, the configuration the machine was shipped with originally)
by experimenting a bit more with the jumper settings. Now everything seems to
work fine, and the wierd SCSI problems has disappeared.


Post by Jeff Walkup:
"That's strange... I have an A3000, and when I put in a new drive
(couple days ago), HDToolBox set the default mask at 0x7FFFFFFE.

Well, I only got about 500k/sec, which is too slow since I've
seen xfer rates in excess of 850k/sec with my other drives. So
I changed the mask to 0xFFFFFFFC, which is what my other drives
are set to, and now get ~880k/sec. I got that 0xFFFFFFFC value
from someone on the net last time I asked.

So HDToolBox's default Mask gives sub-optimal performance with some A3000s, at least which whatever benchmark/test he used.



Post by Jon Sheehy:
Well, if that works for you, you shouldn't have to change the mask. I had
the problem on an A3000 with SCSI drives (all three of them, AAMOF) when
I added an 040 and a new DMAC chip. Certain files would always corrupt
themselves _EXACTLY_ the same way, anytime a particular program loaded
them using DMA into the memory on the 040 card. After months of avoiding
using that ram, I read a post on BIX that made me think about changing the
mask value to 7FFFFFFC, which I understood would cause longword-aligned
transfers. You see, I found that the corruption was always the repetition
or ommission of shortword (two byte) pairs. In my case, changing the
'maxtransfer' didn't solve the problem, it just changed the way the problem
would manifest itself (as in which pairs of bytes would be duplicated or
ommitted).

It sounds like he updated SDMAC without updating Ramsey.

Dave Haynie:
Well, that could be part of the problem. The DMAC and the RAMSEY are a
matched set. If you have Rev 1/2 DMAC, you should have Rev 4 RAMSEY,
and if you have Rev 4 DMAC, you need Rev 7 RAMSEY.

I don't know all the details, but it all stems from the fact that
RAMSEY is the address generator during DMA transfers (that's how you
get 32 address/32 data, plus I/O and control connections, using 84-pin
chips). The DMAC starts to run a transfer, RAMSEY counts, without
being told what to count, it's implicit in the transfer. Only, the
older chipset only supported longword-aligned transfers (usually, but
not always, what you get), the new chipset supports word aligned
transfers.


"Is SDMAC rev 04 buggy?" posting by rno describes disk errors with SDMAC-04/Ramsey-04 which were "solved" by using DynamiCache. Presumably his partition Mask values were not 0x7FFFFFFC hence the errors, and DynamiCache's buffers happened to be longword-aligned so hiding the problem.
I had a newer set of SDMAC and RAMSEY chips available. The A3000 was originally
shipped with SDMAC-02 and RAMSEY-04, and I had SDMAC-04 and RAMSEY-07
available. Now, this was a year ago, and I am not sure I remember exactly what
I tried and what happened. But I know the only combination I could use that
worked with the A3640 installed was SDMAC-04 with RAMSEY-04. Otherwise I only
got the yellow screen, or another cute problem: In one configuration, the
system started, but failed to read the battmem bits, and system time & date
alike. Certain bits were always zeroed when being read, giving very funny
results when the system attempted reading and setting the Real Time Clock for
instance.

However, using the SDMAC-04 and RAMSEY-04 combination proved to be not entirely
successful in the long run. I have had the system running like this for a year,
but there was two problems I noticed: The shareware program TrapDoor was unable
to read its keyfile ('keyfile fatally damaged') and IPrefs claiming it couldn't
find the background picture I had selected in WBPattern. Upon running LoadWB
the picture always loads fine anyways. The problem with reading the keyfile was
solved, amazingly enough, by using "DynamiCache" on the disk partition where
the keyfile resides. No other cache program had this effect. It does something
with disk access that 'bypasses' this hardware related problem.