• Please review our updated Terms and Rules here

Zenith Z171 plus WDXT-GEN debug

Twospruces

Veteran Member
Joined
Dec 9, 2009
Messages
779
Location
Canada
Hi all
Trying to add an MFM controller to my Z171 so I can test a couple of MFM drives.

Only partially working.

To connect up the controller, I made an adapter board they extends the Z171 bus. Seems ok.

WDXT bios rom is readable and I can run the internal commands via DEBUG. So thats good.


The format program built in complains with error 20... bad controller. Oops!

CHECKIT reports the bios is present but it also reports that IRQ5 is unassigned. That seems bad since this controller needs IRQ5.

Z171 manuals state that irq5 is available on the bus and is used for external HDD.

Any suggestions as to where to look for issues?

Thanks!
 
Doing some reading....
I suppose that, in order to have "IRQ5" working, there would have to be some vector in the IRQ table...right?

So Checkit is probably just seeing that there is no vector in place, so it reports not assigned.

The WDXT-GEN card must have some IRQ entry address... anyone know what that would be? Is there a standard value that all HDD controller software interrupt routine runs from?

Guessing maybe all I need to do is write a vector into the irq table? Using debug...
 
Reading some more,
I guess that on boot up the Bios eventually jumps to c800 where the controller bios is. I can see that the z171 is doing something different during boot and I assume that is the WDXT GEN bios trying to find the disk. It eventually times out.

Maybe I have a hardware problem still, with the cabling or my adapter board...
 
I suppose that, in order to have "IRQ5" working, there would have to be some vector in the IRQ table...right?
So Checkit is probably just seeing that there is no vector in place, so it reports not assigned.
The WDXT-GEN card must have some IRQ entry address... anyone know what that would be? Is there a standard value that all HDD controller software interrupt routine runs from?
There is no standard offset within the ROM for that.
 
I have a WDXT-GEN. I put that into my IBM XT. The WDXT-GEN is not connected to a hard drive. When I power on the XT, I see the expected RAM count-up. The count-up finishes, then nothing until about 30 seconds later, when the BIOS expansion ROM on the WDXT-GEN puts the error of '1701' on the screen.

I then press F1, boot to DOS, and via a tool (RAYXTMFM), I see that the 0Dh vector (i.e. used by IRQ5) has been modified by the BIOS expansion ROM on the WDXT-GEN to point to a location in the BIOS expansion ROM.

So, when you have no drive connected to your WDXT-GEN, do you see the '1701' error ?
 
let me check, thanks. The Z171 has a funny boot up process that includes a world map and a set of functions that run out of Bios. When the controller times out it flips to world map. Makes it a bit hard to see what is displayed by the WDXT-GEN

so, I set the card in place with no drives or cables.
The machine boots in the same way, with a long delay and a blinking cursor at the top left corner.
Some of the resulting message gets overwritten, but eventually it say "xxxxxxxxxx rive not ready"
which I assume is something like "Error: Drive not ready" or something.

When I run the format utility via debug, it exits with error 80 = timeout. Which is a different exit error than when the drive is attached.

Interestingly the IRQ vector table contains what I think is a valid entry: the 0Dth entry is C800:04F8 (in order in memory F8 04 00 C8).
Checkit still says IRQ5 is available.. strange.

I may probe the IRQ line on the bus and see if the WDXT card is trying to get the processor to give it some attention.

thanks for the tip on RAYXTMFM. the tool quits at stage 3 because it finds a controller ROM but does not recognize it. Seems likely that it might not have this specific checksum. Unfortunately it fails before the interesting tests happen.

thanks for the help.
This tool looks like it would be very helpful if I could get past stage 3.
 
update;
I hacked RAYXTMFM to recognize my detected CRC, and carry on.
Now, I can see that the first test, RESET - fails. So, that's very useful. Let me find out why RESET isn't working. The signal is connected I think! Time to check.

well, after reading, this test can't pass with no drive connected. So, I should now connect the drive up and see what happens...
 
Last edited:
Interestingly the IRQ vector table contains what I think is a valid entry: the 0Dth entry is C800:04F8 (in order in memory F8 04 00 C8).
Informing us that the Z171 is executing the initialisation code within the ROM on the WDXT-GEN.

thanks for the tip on RAYXTMFM. the tool quits at stage 3 because it finds a controller ROM but does not recognize it. Seems likely that it might not have this specific checksum.
The latest version (1.9) has the CRC32 for the ROM on my WDXT-GEN card. The ROM on my card (designated U13) has 62-000128-000 printed on it (first line). Your ROM must be different.

I hacked RAYXTMFM to recognize my detected CRC, and carry on.
Now, I can see that the first test, RESET - fails. So, that's very useful. Let me find out why RESET isn't working. The signal is connected I think! Time to check.

well, after reading, this test can't pass with no drive connected.
I ran RAYXTMFM again, with no drive connected to my WDXT-GEN, and the 'Hard disk controller - To reset itself' action failed. I was expecting it to pass, but it is up to Western Digital to decide what determines pass/fail.

The format program built in complains with error 20... bad controller.
That was earlier, with the hard drive connected. I see that in the WDXT-GEN User's Guide is a 'If you have a problem' section, and in that section is a reference to an error 20. The guide suggests "Cables revered, bad cables, or drive malfunction". Do you have pin1-to-pin1 correct per [here].
 
Doing lots of double checking of things
- cables all buzzed out
- controller seems well connected to the Z171 ISA bus.

One thing that has me a bit puzzled - what triggers an MFM drive to spin up? When I power up the drive, it spins up, does some seeks and then spins down.
From what I can tell, DRIVE READY signal never ever toggles low. ( I have 2 identical drives and they both act the same)

When I run the debug based built in format code, and monitor DRIVE SELECT, I can see that it does in fact toggle low for 500msec. I would have thought that this would have caused the drive to "wake up" and spin up again.

So that seems odd.

Anyhow, onwards.
Thanks for the tips. Yah my ROM must be different. But I agree that the BIOS seems to be getting set up.
I still can't tell if the IRQ5, /DACK3, DRQ3 lines are working but for now I will assume they are.

Now that I can for sure know that I have the right drive selected... I don't know why the drives are spun down and never wake up.
I can't see any signal on either connector, other than DRIVE SELECT that should wake up the disk.
 
One thing that has me a bit puzzled - what triggers an MFM drive to spin up?
Normally, application of power only.

When I power up the drive, it spins up, does some seeks and then spins down.
The spinning down is odd. MFM drives can take, say, 15 to 30 seconds to get up-to-speed. If they spun down after a period of inactivity, 15 to 30 seconds is a lot of time to wait before one can resume hard drive operations. Would the OS time-out waiting for the drive to spin back up!

I don't have any MFM drives here that spin down after a period of inactivity.

One of those MFM drives auto-parks after a period of inactivity. When that happens, the drive's LED turns red, but the drive continues to spin.

From what I can tell, DRIVE READY signal never ever toggles low. ( I have 2 identical drives and they both act the same)
When I run the debug based built in format code, and monitor DRIVE SELECT, I can see that it does in fact toggle low for 500msec.
Yes, part of the control cable is a bus, shared by up to two drives. Therefore, a drive only asserts a signal on the bus when it is selected. So, if a drive is 'ready', it will only drive the READY line low when it sees that it is selected via DRIVE SELECT.

But I am surprised that the drive indicated that it is ready when the platters are not spinning.

Now that I can for sure know that I have the right drive selected... I don't know why the drives are spun down and never wake up.
I can't see any signal on either connector, other than DRIVE SELECT that should wake up the disk.
There is no dedicated signal. If an MFM drive, by design, spins down after a period of inactivity, it will be up to the designers of the drive to choose what they monitor to trigger a spin-up.

You have two identical drives doing this. Maybe there is a jumper/switch that will stop the spinning down.

Power supply's +12V line is overloaded?
Power supply faulty in way that results in it not being able to provide adequate current for the drive on the +12V line ?

I hacked RAYXTMFM to recognize my detected CRC, and carry on.
Now, I can see that the first test, RESET - fails. So, that's very useful. Let me find out why RESET isn't working.
I did an experiment with an ST-412. I covered the READY contact on the drive, i.e, the ST-412 would not be able to signal to the WDXT-GEN that it was 'ready'. The 'Hard disk controller - To reset itself' test in RAYXTMFM failed.

I then uncovered the READY contact. The 'Hard disk controller - To reset itself' test was then successful.

( I may have got the same result if I used the INDEX line instead. )
 
I'm starting to suspect that the controller is working fine and it is the drives that are no good.
1. DRIVE READY, active low, never toggles low for either drive
2. one of the drives clearly has a stuck stepper. The other is spinning freely.
3. both drives spin up, make a bit of noise, and spin back down
4. on boot up, I can see that the LED on the drive momentarily lights up (same for each drive)

Problem with a set of parts that don't work together is that it is quite hard to say what is broken!
- could be the Z171
- could be the controller
- could be the drives!

Your test above does seem to suggest that DRIVE READY is a part of the RESET command.
Which does align with my observations.
 
Your test above does seem to suggest that DRIVE READY is a part of the RESET command.
Well, for the WDXT-GEN.

I repeated the 'cover READY contact' experiment, but instead of the WDXT-GEN controller, I used the stock hard drive controller supplied in the IBM 5160, the IBM Fixed Disk Adapter. When I then ran RAYXTMFM, all of the controller tests passed, then the {Hard drive 0 - Reporting as 'ready' ?} check failed, with 'time-out' as the failure reason returned by the controller.

So, the IBM Fixed Disk Adapter behaves as I expect: The controller tests, in my opinion, should not be impacted by the cabling or drive (lack of a drive, or drive good/bad status). A problem with cabling, drive, termination, LLF, etc. should be picked up by the drive tests, not the controller tests.

Because of the WDXT-GEN's behaviour (which other controllers may also do), I will probably now modify RAYXTMFM. For now, assuming a good WDXT-GEN, you could try the 'Function 10h' test at [here].
 
4. on boot up, I can see that the LED on the drive momentarily lights up (same for each drive)
Probably the initialisation code in the WDXT-GEN looking to see if the drive is 'ready', combined with the drive being configured to light its LED when the drive is selected (via the drive-select lines).
 
I am thinking about trying to get at least one of my drives to report ready. The one with the stuck stepper seems like the one to open up. Is opening a 20MB hdd survivable?
 
I am thinking about trying to get at least one of my drives to report ready.
Helping to prove that the drives are not becoming 'ready':

You have only one drive on the control cable. Because the drive-select lines are open-collector driven, to facilitate measurement of the READY line, you can tie the appropriate drive-select line to ground. I expect that the drive's LED will turn on.

I just did that now using my IBM Fixed Disk Adapter and ST-412. At the drive, I tied the appropriate drive-select line to ground. I hooked up my multimeter to the READY line (pin 22).
At power-on:
- The ST-412's LED came on and stayed on.
- The READY line measured about +3V

Almost exactly 15 seconds later (i.e. ST-412's self tests complete, including platters up-to-speed), I observed the ST-412 drive the READY line to about 0V.

Is opening a 20MB hdd survivable?
It is, but kind of a 'last resort' thing. The subject has been discussed on these forums many times over the years. Perhaps do a search.
 
So,
I tried running commands directly, using your tips.

The controller passed ram test (function 12h)
The controller passed self test (function 14h)

Thanks for those tips!
Encouraging that possibly my controller and bus extender are working.

I understand your comment- by grounding the DRIVE SELECT line at the drive , you were able to observe a 15 second time before DRIVE READY was asserted low. seems safe enough to do so. the controller end of DRIVE SELECT should be high impedance.

increasingly, I think there must be some reason why each of my drives is unable to achieve DRIVE READY.

(I think now one aspect of boot up is a bit clearer - in general the controller would have to wait for the drive to become ready before proceeding to boot. That's why I get the error message after time out - Drive not ready. The controller is just waiting for the disk to become ready.. which it never does. sounds obvious now.)
 
update - tested manual drive select grounding
- first power up drive, with cables disconnected
- next ground the drive select jumper
- LED begins to flash on/off while drive select is grounded.
- no difference in the spin up / spin down - the drive spins down in the same manner, and does not re-spin up at all.

both drives behaved the same.

I guess that means each drive is failing the internal self check and shutting down.
 
(I think now one aspect of boot up is a bit clearer - in general the controller would have to wait for the drive to become ready before proceeding to boot. That's why I get the error message after time out - Drive not ready. The controller is just waiting for the disk to become ready.. which it never does. sounds obvious now.)
For the ROM on the IBM Fixed Disk Adapter, that waiting for the drive to become ready, is step 5 at [here].

- LED begins to flash on/off while drive select is grounded.
I guess that the engineers decided to flash the LED rather than simply light it.
 
I added a copy of the '62-000128-000' labelled BIOS ROM on my WDXT-GEN to [here].

I would also like to add a copy of the BIOS ROM on your WDXT-GEN. If you are willing, please use the following DEBUG commands the copy the content of that ROM to a file named MYC800.BIN, and then post that file here. I also need the 62-xxxxxx-xxx number printed on the ROM.

A:\> DEBUG
-N MYC800.BIN
-R BX
BX 0000
:0
-R CX
CX 0000
:2000
-M C800:0 L2000 0100
-W 0100
Writing 2000 bytes
-Q
 
Back
Top