As I've been looking into this (rev5) the past couple of weeks I thought I would post a progress report.
I have been running into DMA issues again. Though I now realise I had exactly the same problem with the SEC booster. but the problem seemed to "vanish" so I never thought anything of it again.
Basically this is a good and bad sector write to ultrasatan.
- 1.JPG (235.24 KiB) Viewed 1399 times
- 2.JPG (235.21 KiB) Viewed 1399 times
If you look at the second row down, you can see there is a "missing byte". Ironically this problem only surfaces with a -38 DMA. The problem does not show up with a IMP chip. Though I've generally suspected that those chips were marginally faster technology anyway.
When I was developing the SEC booster on a STFM. I attributed the problem due to noise on the longer A1 trace to the DMA. Adding some capacitance, or routing it through the PLD as I did at one point solved the problem.
I will make a wild speculation to what is going on. It is practically impossible to diagnose because I do not have a logic analyser for this work so I can only really continuously guess at it
I think as A1 selects command or data register within the DMA, it is not selecting the correct register and ultimately causing it to "skip a byte". On the SEC booster a very small delay on A1 solved that problem. It is like the DMA does not latch the data in its registers until ( presumably glue) has finished releasing DTACK.
I don't know how the DMA is programmed. But I assume several writes to its registers to set up the sector count etc are done from the CPU first. Then I assume the CPU gets a bus request from GLUE where the DMA can take control of the bus and do the actual sector read or write. I think the actual sector is being written but obviously something has got shifted at some point.
I did try delaying writes to the ST bus totally, but it did not seem to help. The assumption was the CPU was writing to the DMA registers to fast. But it is also possible that is still happening because the clock switching will inherently not immediately switch anyway.
The
current firmware on the website goes back to the original clock switching mythology. It only switches into high-speed on alt-ram access. This does cause a overall speed drop of around 50% on most tests, from 300% to 250% basically. If we ignore the DMA issue (use a IMP chip) then we can run at full speed with GB6 or FrontBench just fine. So likely this will just have to be the final code for a while.
I did try the IDE interface. But it is still not functioning and I really have no idea why. The interface is found but not the card. I double checked all the data lines were correct on the schematic and they seem so. But I really need to find the root cause of this DMA problem first..
Edit:
I have done a single 10ns delay on A1 to the DMA (reused the ACSI pin on the PLD and bodged wired to A1 on the DMA) and it now AutoBoot's from C: just fine. Though it is now looking up intermittently which I have to look into as well now