15 March 2019, 21:56 | #1 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,349
|
A3000 SCSI DMA restrictions
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: Code:
; 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: Code:
**** 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. Last edited by mark_k; 15 March 2019 at 23:08. |
16 March 2019, 12:04 | #2 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,553
|
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. |
16 March 2019, 15:30 | #3 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,349
|
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. |
16 March 2019, 15:42 | #4 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,553
|
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. |
16 March 2019, 17:01 | #5 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,349
|
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. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
a3000 scsi lockups | stevereaver | support.Hardware | 19 | 23 May 2022 03:44 |
Need help with A3000 SCSI | ajk | support.Hardware | 13 | 04 October 2019 07:26 |
A3000 with SCSI CD-ROM | jeppea | support.Hardware | 5 | 08 February 2010 19:13 |
Need A3000 SCSI info | amiman99 | support.Hardware | 1 | 26 October 2009 18:17 |
Which A500 SCSI interfaces are DMA-based? | Photon | support.Hardware | 21 | 19 September 2009 19:32 |
|
|