@ijor the signals are all buffered.
Yeah I gave up with LAs as the software was always crashing and the hardware died to easily. Maybe a more expensive one be better but they cost a fortune
I'm not sure they be accurate enough for such things either.
But it seems to be a issue with the RW signal. I know I had a right time with ultrasatan when I developed my booster. The fix just seemed to be keeping in 8mhz on BR,BG,BGACK. it had to be all 3. I never figured out why back then.
So I think the timing of ultrasatan is slightly more consistent in that it seems to mostly issue DRQ around the falling edge of the 8mhz clock.
The pi drive is a lot more random on where it hits the 8mhz cycle.
I think when DRQ is loaded with X1 probe it shifts it from the clock edge more and causes more issues.
Similar when I use 220mhz pi clock it tends to work better and the timing of DRQ looks more like ultrasatan.
Timing of DRQ shouldn't matter of course. But whatever is going on inside the GST is causing a timing difference on the RW signal . Something is borderline somewhere.
For example, if DRQ arrives in the middle of the 8mhz cycle on a high or low, it seems to cause RW going high to be delayed enough to upset the booster, as it's synced to the 8mhz clock.
If DRQ arrives near the falling 8mhz clock edge, then the RW rise (I assume) is slightly quicker and doesn't upset the booster. This is why I think ultrasatan works as it's always near a clock falling edge, the pi drive is a lot more random.
From RW to BGACK , it looks like RW goes high exactly when BGACK goes high. That makes sense. Adding a pullup on RW speeds up the rise of RWna lot, but it doesn't solve the problems.
However, if I have a clause in my code to keep in 8mhz during a low on RW, then the booster runs a fraction slower, but the hard drive then works fine.
I tried keeping in 8mhz longer after BGACK goes high, I kept BGACK to the CPU low for about 60ns more, but the drive still failed.
At this point I get confused
I can only assume for whatever reason, the hard drive with DRQ timings, causes the RW signal to skew or have a longer rise time at some point after a dma cycle.
Note that the booster itself can run all day without issues. The issues only show up on a hard drive DMA cycles. But like I said earlier, speeding up RW high clearly shows a huge improvement in the rise time, but it has zero effect on the booster speed or reliability of the hard drive.
And yet if I use RW to delay 32mhz mode, it all works fine. As the booster shows a slight slowdown, it has to be seeing RW low , when nothing is accessing the bus even ( AS high).
Only thing I can do is try a even lower RW pullup value, the only idea which makes sense is RW is slower to go high after a dma cycle than anyother bus cycle. And it's linked to the timing of the DRQ signal somehow. Which doesn't make sense
EDIT:
Also just 6ns delay on the 8mhz clock ,even when the CPU is running at 8mhz only, can also cause the same problems. So it's not exactly limited to the booster either. Some CPUs behave that way, others don't. Some don't work then work later on. It seems to be down to borderline timings and tollerences again
plus the 001 "good DMA" agrivates what ever the problem is and works a lot worse than the -38 "bad DMA".
