JezC H5 C5B Build - one STep beyond...?

[exxos]

Been looking at the 7474 STE FF. Didn't help as the first 7474 datasheet had a different pinout to the one in the STE schematics :roll:

Anyway...

The FF clock is 8MHz. I just had to "guess" at the FDCS signal and called it 1MHz.

Capture.PNG

Basically the FF delays the signal by about 40ns. It actually "skews" the 1772 databus as well. To tired to look into it all right now. But what I did was have a multiplexer to switch between the DMA and 1772 and have done with any conflicts in that respect.

Though because FDCS ties directly to the CS on the 1772.. The 1772 actually has the data still on the bus for "some time" still. With my multiplex buffer isolating in FDCS, that extra data delay is no longer there.

Of course this is all assumptions and speculation to what the problem might be for @JezC currently.

My test would hardwire the DMA buffers OFF, and hardwire the 1772 buffers to ON all the time. So if the delay is the problem, then the floppy drive would start working again..

[JezC]

Ran out of time tonight to do anything other than grab a few photos of the H4 board as it currently runs (but note that this now has the YM2149 and AJAX fitted & working as those were swapped with the H5CB parts as part of the troubleshooting.

Which means that the H4 worked with either set of chips fitted while the H5CB failed to work with any of them.

I can't remember if I also tried swapping the DMA chips so that will be something quick to try tomorrow night.

Here are the photos...

IMG_20250611_205753796_HDR.jpg

IMG_20250611_205745352_HDR.jpg

IMG_20250611_205740355_HDR.jpg

IMG_20250611_205735594_HDR.jpg

[exxos]

I think FDCS went directly to the 1772 buffer on the H4 as well as the H5 Though the H4 would actually have the same problem as the H5 in that respect. The only difference would be moving from DIP to SOIC buffers. Maybe DIP was a couple ns slower so it worked :shrug:

[exxos]

This would be the proposed "final" mod... This will extend the FDCS pulse low by about 100ns. Or you can likely get away with 1K for about 50ns.

Cut the track where the yellow line is..

Capture.PNG

Solder a 4148 diode between the 2 points of the now broken track with a 2.2K resistor (R88) in parallel with the diode.

Then a 100pF cap (C12) from the buffer pin to GND .

2.PNG

Its all GND fill around that area. So the cap GND , just scratch a bit of resist off and solder GND to that..

gnd.PNG

Hard wiring the legs as I mentioned in this post viewtopic.php?p=129689#p129689 likely be easier to test first ... Its only a guess to what the problem is at this point, so doing the "final" mod might be pointless until the issue has been proven..


EDIT: The left side buffer would still need its enable tied to 5V at this point either way.. So the "final mod" still needs updating yet..

[JezC]

I'm following the thought process with interest here @exxos but won't get time to mod the board until the weekend at the earliest (and even then it's a hope rather than an expectation).

I might have a 'cunning plan' (which relies on me exploiting the generosity of other forum members) that could get one of the boards down to you before the end of the month if that might help?

I'll say no more here but move to PMs to see if that is actually an option or not.

[exxos]

I'd give the mod a try first... If it still doesn't work then sending me a board is likely the only option left.

[JezC]

Ok, will see if I can get time to do it over the weekend.

I might have more questions when I look at the board as I get ready to start - you have been warned! :D

[exxos]

Ok, will see if I can get time to do it over the weekend.

I might have more questions when I look at the board as I get ready to start - you have been warned! :D

Best to ask now as I am at my girlfriends on weekends so not on the forum much.

[ijor]

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).

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.

[exxos]

@ijor Thanks for your thoughts. I do suspect it's a data hold issue. But until @JezC tries it out we all just guessing at this point.

The multiplexer was added to prevent DMA port and 1772 conflicts. That's another load of issues. But it's possible I've solved one problem then created another. But why this only happens on @JezC boards is a mystery. Maybe just dumb luck of tolerances on his DMA chips or something.

The test is just to disable the DMA port buffer totally then hardwire the 1772 buffer ON. This way the DMA gets the 1772 data for as long as the 1772 is outputting data. It will prove the idea either way. I jumped ahead and designed a fix for the H4/H5 but again it needs @JezC to verify thats the actual problem before I can do anything else.