So I double checked to see if the scope was fast enough to trigger and display activity on DACK2 using the test board and yes I can see it pull low on floppy boot (and I just discovered that the vertical adjustment on channel 1 has stopped working so I'm only able to watch one pin at a time using channel 2), drive query and using IMG to image a disk.
The problem board however does pull DACK2 high like the other board when powered up, but it never pulls it low for the above tests. It doesn't even try. So chances are this is the problem unless there's a qualifier for DACK2 I'm not aware of.

Edited: Reading the 85C460 datasheet pin 191 (DACK2) run over to U24 pin 3 (C; Input Select) which is the same chip we saw before because ISA DACK2 connects to pin 13 (Y2; Data Output). No breaks were found in either connection. I'm not entirely sure how DACK2 gets pulled down. Is this line entirely a feedback for the chipset and thus the pulldown is created somewhere upstream or is this pulled down by the chipset itself? I'm lost here.

CelGen wrote on 2021-05-01, 17:59:

I'm not entirely sure how DACK2 gets pulled down. Is this line entirely a feedback for the chipset and thus the pulldown is created somewhere upstream or is this pulled down by the chipset itself? I'm lost here.

maybe this will help http://wearcam.org/ece385/lecture6/isa.htm search for DACK or DRQ, about halfway on the page.

Also... what chip is U24 ?

U24 is a 74LS138N 3-line to 8-line decoder.

Okay so if I'm reading that right, DRQ2 is the floppy controller sending a DMA request to the chipset ("Mr 85C461 can I plz use DMA channel #2?"). The chipset responds back with DACK2 ("Yes device, you can use DMA channel #2 until I say stop.") If I'm wrong, please correct me.

ISA pin 26 always stays high. Chipset pin 191 also always stays high.

CelGen wrote on 2021-05-01, 16:44:

All I said was that one of the input lines for the glue that DACK2 was connected to was not directly going to the chipset. It's a pin that is connected in a middle board layer and isn't visibly traceable from either side, so either it's broken OR it's going through some other logic and that's the reason why I don't see a direct connection to the chipset. I didn't chase this because it's going to take a while to track it down.

What kine of glue logic is there? I'd expect the chipset to drive the DACK lines directly, or perhaps through some simple 74-series buffer like '244. It's a pity this mobo is not using the 82C206 - it would've made things a bit easier. Anyway, DACK1, 2 and 3 (and perhaps 0 as well) should be all driven in the same way. See if you can find connections between chipset and that glue for the other lines, if so you'd know there should be one for DACK2 as well. And maybe those are nearby pins on the chipset so you'd know where to look for any cracked solder joints or something like that.

CelGen wrote on 2021-05-01, 19:33:

Okay so if I'm reading that right, DRQ2 is the floppy controller sending a DMA request to the chipset ("Mr 85C461 can I plz use DMA channel #2?"). The chipset responds back with DACK2 ("Yes device, you can use DMA channel #2 until I say stop.") If I'm wrong, please correct me.

I'm not sure, I think the device pulses the TC signal after the dma transfer is done, which makes the chipset release the dack signal.

ISA pin 26 always stays high. Chipset pin 191 also always stays high.

That's not good, that would imply that the chipset never sees the DRQ or that the chipset drq2 or dack2 signal is broken.

Since the problem definitely seems dma related... check where the DRQ <- signals go to. Do they go directly to the chipset or do they go to a buffer chip that might be broken.
ISA pin B06 DRQ2

CelGen wrote on 2021-05-01, 17:59:

Edited: Reading the 85C460 datasheet pin 191 (DACK2) run over to U24 pin 3 (C; Input Select) which is the same chip we saw before because ISA DACK2 connects to pin 13 (Y2; Data Output). No breaks were found in either connection. I'm not entirely sure how DACK2 gets pulled down. Is this line entirely a feedback for the chipset and thus the pulldown is created somewhere upstream or is this pulled down by the chipset itself? I'm lost here.

OK, forget my last post, I somehow missed this edit. If there is '138 between chipset and ISA then DMA channel is selected as 1-of-8, not directly. Even though the chipset does have direct outputs for all 8. So you can't expect DACK2 on pin 191 to be actually a signal for DACK2 on ISA if it is connected to input C of the '138. Rather, it is a value of 2^2=4. So it should be high. What should be toggling then is pin 192, DACK1. And also pins 187-190 (DACK3 and above) should be unconnected.

Or in other words, for the '138 to pull output Y2 low it needs to see ABC as 101, and the enable gates (pins 4-6) driven properly. Chances are only one of the 4-6 pins is connected to chipset, rest is tied permanently up/down. And by the way since the chipset does have all 8 outputs but use a '138 there must a mode register set by BIOS to enable this. But then if the BIOS programmed the chipset for direct operation you would actually see pin 191 toggling, so that's not the case here - I just figured I'd mention it for completeness.

QUICK EDIT: Wait, no, I forgot how '138 works. The code for Y2 should be 010, not 101. So now I'm kinda puzzled why you see pin 191 high...

I gave it a thought and so long the enable gate on '138 is not active the ABC pins can be whatever. But there should be a toggle at some point to select the 010 code to assert DACK2. If pin C is always high, it's not correct.
So the question now is, what is going on pins A and B of the '138? And the gate pins (4,5,6), as I stated above at least one of them must be tied to chipset as well, and toggling.

This reading can be useful

Intro to the ISA bus by Mark Sokos
https://gist.github.com/PhirePhly/2209518#file-isa-txt-L805

21.3.1. A Sample DMA transfer
https://ftp.utcluj.ro/pub/docs/diverse/freeBS … ook247.html#428

That I can tell, A B and C never go low A connects to 183, B connects to 182 and C connects to 181. pins 4 and 6 remain high while 5 remains low.
One thing also I have not checked yet is if DRQ2 is actually reaching the chipset. I've only probed from the ISA bus. That would go to pin 149 in one way or another?

this is what happen at signal

B26: *DAK2 (yellow)
B6: DRQ2 (blue)

on a working machine at command A: DIR

dataino.it wrote on 2021-05-01, 21:56:

this is what happen at signal […]
Show full quote

this is what happen at signal

B26: *DAK2 (yellow)
B6: DRQ2 (blue)

on a working machine at command A: DIR

Nice ! The floppy controller sent the +DRQ and the DMA controller imediately responded with a -DACK signal.

CelGen wrote on 2021-05-01, 21:40:

That I can tell, A B and C never go low A connects to 183, B connects to 182 and C connects to 181. pins 4 and 6 remain high while 5 remains low.
One thing also I have not checked yet is if DRQ2 is actually reaching the chipset. I've only probed from the ISA bus. That would go to pin 149 in one way or another?

To enable '138 the 4,5,6 pins should be L,L,H, and you got H,L,H. This would suggest that pin 4 is the active one and should connect to the chipset, and the other two are tied to GND/VCC (possibly through resistors). But if A and B are never toggling then yes, the assumption would be the chipset is never getting a DRQ for DMA2, so it's not responding with DACK. If you have a SoundBlaster type of card you can check if it's DMA is working correctly, by trying to play some samples. A MOD player or maybe a game like Doom would be a simple and easy test to try. That would tell you if the problem is only with DMA 2 or not.

The DRQ lines should be connected to the chipset directly but then there might be some buffering there (mostly to protect the chipset from ESD during card installation). To rule out a single broken trace see if any other DRQ than for DMA2 is connected directly.

DRQ0, 1, 2 and 3 all run to the same chip (U8) and not to the chipset directly. U8 is a SN74F151BN 8-Input Multiplexer:

-DRQ0 to pin 15
-DRQ1 to pin 14
-DRQ2 to pin 13
-DRQ3 to pin 12
I pretty quickly had a Sound Blaster Pro 2 available so I threw that in and ran TEST-SBP. The digitized sound test uses DMA and it had no issues on any of the three channels you could jumper (0, 1 and 3)
I have not poked at anything yet with the scope but now I'm baffled because three other DMA channels go through the same chip and they work fine.

CelGen wrote on 2021-05-02, 00:02:

DRQ0, 1, 2 and 3 all run to the same chip (U8) and not to the chipset directly. U8 is a SN74F151BN 8-Input Multiplexer: […]
Show full quote

DRQ0, 1, 2 and 3 all run to the same chip (U8) and not to the chipset directly. U8 is a SN74F151BN 8-Input Multiplexer:

-DRQ0 to pin 15
-DRQ1 to pin 14
-DRQ2 to pin 13
-DRQ3 to pin 12
I pretty quickly had a Sound Blaster Pro 2 available so I threw that in and ran TEST-SBP. The digitized sound test uses DMA and it had no issues on any of the three channels you could jumper (0, 1 and 3)
I have not poked at anything yet with the scope but now I'm baffled because three other DMA channels go through the same chip and they work fine.

did you also try recording ?

What a weird setup. I guess they wanted to save some pins on the main chip, since this is one-chip solution. But now the chipset has to scan all the DRQ lines in sequence.

Oh well. Let's dig deeper into this. See if /E input of the '151 (pin 7) is connected to chipset or tied to GND permanently. Just so we know, it is working because SB test went fine. Then test inputs S0,S1,S2 (pins 11,10,9), you should see them toggling. All the time actually to properly scan all inputs, unless this chipset is "smart" and only scans the enabled DMA channels. But even in that case the S1 line should be toggling during floppy R/W attempts. Actually the combination should be LHL but you said low DRQ lines are connected to pins 12-15, which map to inputs 4 to 7. So possibly the S2 is permanently high and only S0 and S1 toggle? Again, weird setup. So the input for DRQ2 would be S0:L, S1:H, S2:H - you could maybe try a second scope channel to see if that is indeed what's on S0 and S2 when S1 goes high. In general S1 should toggle properly if DMA0 is working but better be sure.

Now, assuming S-inputs do toggle, then check if pins 5/6 (same output but negated on 6 and I'm not sure which one is connected to chipset, probably 6) toggle. Typically with no DMA activity the Z output should stay at the same level (Z=H, /Z=L because DRQ lines are all H) but then it should start toggling L during floppy access. It's not impossible that somehow only the DRQ2 input on this '151 chip is faulty (killed by ESD for example) and doesn't go through, but other DMA channels work. In fact if you don't see the Z output change you can retry this test with SoundBlaster again but monitor for it's DMA to see how this should be working.

Frankly if other DMA channels work (especially if you tested 0, 1 and 3), the '151 is driven properly, and passes correct signal to the output, and that line goes to chipset as it should. So the way I see it the only faults possible are:
- the '151 is partially damaged and only DRQ2 line is busted
- the chipset is "smart" and is not even scanning DMA channel 2 beause it's not enabled (but why would it not be for floppy transfer? wrong BIOS?)

Perhaps the DRQ2 connection to the '151 chip is so marginal it doesn't work properly (mobo damage somewhere) but then again I would exepct the signal to get trough eventually if you can trace the connection, and because this is request-acknowledge type of protocol it would make is slower in random ways, not stop it completly.

Wow, looks like good progress.

I had another read back, and this was the test you posted that I had missed and thought it suggested there was a problem with DACK2, even if the test card said DMA2 was ok (I guess it must only monitor the DRQ?):

dataino.it wrote on 2021-04-29, 07:01:

I have checked all the connections of the isa connector and they are OK.
When i i try to read the floppy
I have this type of signal on a working card, in the NOT working one the DAK02 / has no activity,

I'm just trying to keep up now as I learn a bit more about DMA stuff. Does the following sound right? From what I understand, this board has the DRQ lines come in to an 8-way switch (U8 74F151). That's switched by something (do we know what? unused DACK outputs from the '461?) and the single output goes to the chipset (do we know where? DRQ0?). The chipset then communicates with the CPU to release the bus (HOLD) and when it gets back an ok (HLDA) it signals the appropriate DACK out on three of the DACK outputs to a 3-8 decoder (U24 74LS138), which then drives the actual bus DACK lines.

Have I got that wrong? Would that mean that the output from U8 (pin 5 or 6) should look similar to the bus DRQ2 if nothing else is making any bus requests? And if it doesn't then it'd mean the DMA controller never sees the request?

Is this all an effort to avoid having the chipset sharing the cache control pins (KCE0..3) with the DRQ pins?

Incidentally, and it's not important now, but seems odd that the last couple of IMD results had the correct track and sectors numbers, when the first time through the results were so wild. Also, if the fault is DMA then maybe that explains why IMD could read the status correctly, assuming that it's only the continuous track data that gets sent via DMA?

On page 41 of the SIS 85C471 datasheet (an improved 460/461 with just slightly diff pinout <off by one or two pins for nearly everything and also a 208 pin PQFP>) it shows using 74f138 and 74f151 logic.
Might help explain the board layout a bit better. or not...am still looking for the real 85c461 datasheet

Oh well. Let's dig deeper into this. See if /E input of the '151 (pin 7) is connected to chipset or tied to GND permanently.

It is tied to ground.

est inputs S0,S1,S2 (pins 11,10,9), you should see them toggling. All the time actually to properly scan all inputs, unless this chipset is "smart" and only scans the enabled DMA channels. But even in that case the S1 line should be toggling during floppy R/W attempts. Actually the combination should be LHL but you said low DRQ lines are connected to pins 12-15, which map to inputs 4 to 7. So possibly the S2 is permanently high and only S0 and S1 toggle?

All three toggle. Well, I assume they toggle. The signal on all three pins is far faster than my scope can handle so I only see a thick green bar of several volts high/low across the display.

Z does the same thing but Z̅ is weird. Both are too fast for my scope but Z̅ has a logic low of -0.8v (yes it's dropping below my 0v mark on the scale) and a high of 2.7v. That's not really an acceptable logic high/low unless it's specifically using a different 0v ground.

Z goes to chipset pin 182 but I can't find where Z̅ goes. It connects to a trace within the board layers and I have yet to find where it surfaces again.

but seems odd that the last couple of IMD results had the correct track and sectors numbers, when the first time through the results were so wild.

That was my fault. I was not testing with a properly formatted disk.

Edited:

Horun wrote on 2021-05-02, 16:16:

On page 41 of the SIS 85C471 datasheet (an improved 460/461 with just slightly diff pinout <off by one or two pins for nearly everything and also a 208 pin PQFP>) it shows using 74f138 and 74f151 logic.
Might help explain the board layout a bit better. or not...am still looking for the real 85c461 datasheet

Horun wrote on 2021-05-02, 16:16:

On page 41 of the SIS 85C471 datasheet (an improved 460/461 with just slightly diff pinout <off by one or two pins for nearly everything and also a 208 pin PQFP>) it shows using 74f138 and 74f151 logic.
Might help explain the board layout a bit better. or not...am still looking for the real 85c461 datasheet

Thanks, that looks like it explains a lot. I noticed in the 460 datasheet it mentions that "The implementation to support full VESA VL-Bus specification will be provided in the future version of silicon."

For the '471 in VL-Bus Master mode it looks like they alter the DACK outputs to put the DACK out via the 74LS138 (so only needing 4 pins for 3 select and 1 GN/enable?), freeing up DACK5..7 for VLB signals, and the DRQ is selected on the 74F151 by MPXS0..2 and comes in via the MPXI0 pin. The '460 already multiplexes the IRQ lines, so (based on CelGen's work tracing the tracks) it looks like the '461 then adds the DRQ lines as well, since it also adds VLB support.

Does that sound like I'm reading that right?

It's even weirder than I thought. They scan all the IRQ, DRQ and some other lines via three '151. So it can't be "smart" as all the input combinations must be cycled through - and pretty fast too, in order to keep IRQ latencylow. That explains why they needed 74F series parts for that (because if it was just for DRQ/DACK the latency is not really an issue).

CelGen wrote on 2021-05-02, 17:15:

All three toggle. Well, I assume they toggle. The signal on all three pins is far faster than my scope can handle so I only see a thick green bar of several volts high/low across the display.

Yeah, with 74F being there it's quite possible the ABC signals change well above 10MHz frequency. Maybe even close to 100MHz, depends how serious the mobo makers were with the latency problem. ISA is clocked at some 8MHz but in that time the chip needs to scan all 8 inputs (preferably anyway).

CelGen wrote on 2021-05-02, 17:15:

Z does the same thing but Z̅ is weird. Both are too fast for my scope but Z̅ has a logic low of -0.8v (yes it's dropping below my 0v mark on the scale) and a high of 2.7v. That's not really an acceptable logic high/low unless it's specifically using a different 0v ground.

In the datasheet the same chip that does DRQ 0-3 also scans other signals so monitoring the '151 output is not really useful unless you can also hook up the inputs and the ABC signals. Which would require a logic analyzer (and a fast one too). Best you can do with that scope is to make sure the DRQ2 line is indeed toggling directly at the '151 pin 13.

So let me ask about IMD, because I see some clarification above about it working now? Or did I misunderstand? If IMD does recognize disk format when you enter the alignment option, and more importantly can read the sectors without timing out or freezing when you press D, and it's only DOS commands that fail on the floppy drive - then the issue might not be a HW problem at all. Because IMD does it's own low-level stuff, bypassing BIOS, it takes over the interrupt handler and programs the DMA channel 2 directly.

In other words, if IMD can read the floppy (either using read or alignment + D button) but DOS cannot then I would say there is a problem with the BIOS code somehow.
If IMD fails to read, try writing to the floppy. It occured to me the problem with DACK2 is it can be very fast and you not seeing it on the scope can be instrumentation limits, not actually missing signal. If write works (or at least doesn't hang before it even writes one sector) then the problem might be with another ISA signal.
Or, if IMD fails to read and write, maybe that particulare '151 is faulty after all. I really dislike desoldering stuff from mobos, because sometimes the old traces/vias get damaged and there's even more stuff to fix, but with no other tools and ideas I would try to desolder this '151, and the other one that has IRQ12 connected to it. Put sockets on mobo and swap those two. If the DRQ2 input is busted then you'd loose IRQ12 instead by swapping the chips, but that IRQ is not used much so it's a preferable quick fix. And then you can start the hunt for a 74F151 (or maybe more modern 74ACT).