Some comments and analysis, mostly for completeness. Because I agree that this is unlikely the problem since the H5 floppy interface seems to work for others. At least I can confirm it does work for me (although I tested it only with Gotek, not with a real drive).
exxos wrote: Wed Jun 11, 2025 9:34 am
My only thought / concern is I added a multiplexer between the DMA port and 1772. Atari had that as a clocked delay which never made sence.
The clocked delay is there to provide enough hold time. If the FDCS signal would have been connected directly to the LS74 enable input, then there is risk that, at least in theory, it could enable the ACSI port buffer too soon.
Note that FDCS is connected to both the LS74 DATA and async RESET inputs. This results in the delay being produced only when FDCS is deasserted. When FDCS is asserted, the buffer is disabled immediately.
But maybe there was a another DMA bug which didn't show up on original STs as they didn't have the buffers until the STE came along which Atari kept the data latched for longer.
I can't say I am 100% sure, but I think that Atari added the DMA buffer to protect FDC transactions and also, to actually buffer the ACSI port which is not a bad idea by itself at all. The buffer is not mandatory, we know the ST works without the buffer, and I believe some people tested removing the buffer on the STE and it works fine. But if it happens that some device on the external ACSI interface doesn't behave correctly, it could interfere with the FDC.
It is very possible that some ACSI devices don't tristate the port exactly as they should, or may be they inject noise, or too much capacitance, when they are turned off. I am guessing that Atari was aware about this and it tried to implement a quick solution without redesigning the DMA chip logic.
Whereas on the H4 boards onwards the buffers are there but not clocked delays so data would be isolated faster.
Yeah, and to be honest, I'm not sure that was a very good idea. From the hold timing point of view, I suspect it is ok(ish) at least as long as the LS245 buffer is slow enough. Using a faster modern buffer could be problematic in theory. But it can't be too slow either or otherwise it could reduce the setup time too much.
The timing is very different depending on being a read or write cycle. On writes, the STE LS74+LS245 delays are irrelevant because the buffer is at high impedance on the computer side anyway.
The FF clock is 8MHz. I just had to "guess" at the FDCS signal and called it 1MHz.
Not sure what you mean by that "guess". If you are wondering about the exact FDCS timing, I can provide some traces and also some simulations.
Basically the FF delays the signal by about 40ns. It actually "skews" the 1772 databus as well.
Not exactly. The 40ns delay is since the clock edge. That means that there is an additional full cycle (or half cycle, don't remember the details without checking) delay. Also note that this is only the delay added by the LS74 FF. In addition there is the delay produced by the LS245 buffer itself. So the delay is actually much longer.
Again, I'm not sure if anything of this is relevant to
@JezC problem. It might. But as
@exxos is saying, if this happens to him on multiple computers, and it doesn't happen to others, it sounds like there should be something common here that makes the difference.
