Nothing wrong should happen if BR is delayed for a few cycles. If BR is delayed, then just the whole DMA transaction is delayed. GLUE (or GST in the STE) doesn't expect any specific timing between BR & BG. And as a matter of fact, the timing is normally not constant (the diagram you posted is a bit misleading in this regard). GLUE will wait for the CPU grating the bus as much as needed.exxos wrote: Mon May 22, 2023 11:57 am *should* yes. But something screws up with the CPU with the delay which can only be busgrant related as the CPU doesn't do much else. What I have done now is enter 32MHz on BGACK and its filled my 200MB partition up twice without tripping up once. Though I think BGACK is more complicated than one tends to think.
I guess BR comes too late, ends up tripping over to the next clock cycle, then everything is late after that.
Conceivably, if DMA is delayed too much and the device pushes data too fast, there is the possibility that the DMA will fail by overrun. But this can only happen when reading a sector, not when writing. Because when writing, the computer sets the DMA pace, not the device.
However be careful with manipulating the DMA signals without synchronization with the other bus control signals. For example, the meaning of BG depends on AS (and also DTACK to a lesser extent).
May be just for the record, but note this is not accurate. The CPU will continue processing as long as it doesn't need the bus. In theory, if the CPU happens to be processing an instruction that takes many internal cycles (such as DIV or MUL), it is perfectly possible that DMA will not produce any delay whatsoever. In practice this will rarely happen, if at all.
Now I will be busy for the next foreseeable forever in testing all 400 of them 
