• Please review our updated Terms and Rules here

XT-IDE-equipped PC XT will not boot or recognize MFM drive

Nevets01

Experienced Member
Joined
Aug 29, 2018
Messages
133
Location
United States
So. My XT-IDE works now, with a CF card and all.
Except when I've got my ST-225 in there at the same time. At which point it doesn't. At all. Boot menu pops up, and looks like this:
View attachment 53457
If I boot from the first "foreign hard disk" entry we get this:
View attachment 53458
...aaaaand nothing. The hard drive shows about a second of activity, round about how much it'd use to boot to DOS, then stops, and never resumes and the screen never does anything else
I have to flip the switch off and back on to get the PC responsive again.
If I select the second, it gives this:
P1130557.jpg

And of course the compactFlash doesn't boot, because it's not a bootable disk. No surprise there.
Booting from floppy and ROM bios both work fine, but I cannot access EITHER disk (CF nor MFM) through DOS.
 
Have you plugged the XT-IDE together with the MFM-Controller+ST225 in the same machine?

This doesn't work without setting the XT-IDE as a secondary controller.
 
Have you plugged the XT-IDE together with the MFM-Controller+ST225 in the same machine?

This doesn't work without setting the XT-IDE as a secondary controller.

I have. It only doesn't work when both are installed at once.

And how would one set the XT-IDE as a secondary controller?
 
I have an XT-IDE card coexisting with an MFM controller in one of my XT clones. As an experiment, I tried the same thing in my IBM 5150 and 5160, and as expected, it worked.

Details in the 'Coexistence with MFM hard drive controller card' section of [here].
In that section, pay attention to the two "IMPORTANT:" notes.

This doesn't work without setting the XT-IDE as a secondary controller.
And how would one set the XT-IDE as a secondary controller?

In my setup, I did not need to change the configuration of anything. My bog-standard MFM controller and VCF XT-IDE controller do not resource conflict. At power-on of the computer, the motherboard's POST executes the BIOS ROM (at the default address of C8000) on the MFM controller, then executes the BIOS ROM (at the default address of D0000) on the VCF XT-IDE controller.

I did nothing special. First, without the VCF XT-IDE controller fitted, I had the machine booting from the MFM controller/drive combination. Then, I removed the MFM controller, added the VCF XT-IDE controller and CF, and got the machine booting from the VCF XT-IDE controller and CF. Then, I added the MFM controller back into the computer.
 
I did nothing special. First, without the VCF XT-IDE controller fitted, I had the machine booting from the MFM controller/drive combination. Then, I removed the MFM controller, added the VCF XT-IDE controller and CF, and got the machine booting from the VCF XT-IDE controller and CF. Then, I added the MFM controller back into the computer.

So, I did this. Took me a bit for various un-computer-related reasons, but the problem persists. Both drives are bootable, and each will boot when the other is not installed, but neither drive will not boot if the XT-IDE is installed, even with nothing plugged into the IDE slot.

I think it may be a problem with my MFM controller or drive; I uninstalled it, and installed my HardCard 20 instead. Both the (bootable) HardCard and the CompactFlash booted completely fine, and both were entirely accessible:
View attachment 53555 View attachment 53556 View attachment 53557

I could just migrate to the HardCard, but I'd rather use that one in my Compaq Portable, and I quite like the look of the ST-225 faceplate and the sound of it spooling up and down

I've also taken out all other cards, besides the two drive controllers and the floppy and one video/RAM card.
 
On face value, it sounds like there is a [resource conflict] between the MFM controller and XT-IDE card.

I think I agree. After some experimentation, it appears to be a ROM conflict: when I disable the ROM BIOS of the MFM controller, the XT-IDE gains functionality, and when I disable the ROM BIOS of the XT-IDE, the MFM controller gains functionality. When I hooked up the HardCard and the MFM together, it gave me a "ROM conflict C800" error. However, no such error occurs with the XT-IDE and the MFM. Does this mean no address conflict? How would I go about de-bugging such an issue?
 
Hmm. Can you still boot from floppy ? If so, I'd run CheckIt! and have a look at the memory overview.
Perhaps the XT-IDE Universal BIOS and the MFM Controller's ROM occupy the same load address..
 
When I hooked up the HardCard and the MFM together, it gave me a "ROM conflict C800" error.
A conflict is exected.
Your 'MFM controller' and HardCard are sure to be standard type MFM controllers, using the resources shown in the top row of [here].
Put them together in the same system, and you will have more than just the ROM's (both at C8000) conflicting.

The XT-IDE is a 'different animal', in that in its default configuration, the BIOS ROM starts at D0000, and the I/O ports start at 300. It does not use an interrupt nor DMA.

However, no such error occurs with the XT-IDE and the MFM. Does this mean no address conflict?
In most cases, you will not be told of an address conflict. I was surprised to hear that you saw a "ROM conflict C800" error. If an error message is presented at all, it is usually something like, "C8000 ROM ERROR", due to part of one ROM 'overwriting' the other in memory space, resulting in what the computer's POST sees as a corrupted ROM.

How would I go about de-bugging such an issue?
One by one, for the three cards, confirm that their respective [BIOS ROM's] are where you expect:
'MFM controller': starting at C8000
HardCard: starting at C8000
XT-IDE: starting at D000

One way of confirming the address where a BIOS ROM starts at is to use DOS' DEBUG program. For example, I have a Western Digital WD1002-27X controller. I expect that its Western Digital BIOS ROM starts at C8000. Via the DEBUG command shown below, I can see that the BIOS ROM is indeed at C8000 (C800:0)

WD1002-27X_debug.jpg
 
Following on from my previous post, BIOS ROM overlapping sometimes needs to be considered. So, BIOS ROM's starting at different addresses, but one ROM extends into the address space of the other. An example of a VGA card's BIOS ROM overlapping with the BIOS ROM on an XT-class computer, is at [here].

But it seems unlikely to me that the BIOS ROM in your 'MFM controller' extends all the way up into the address space starting at D0000. With only the 'MFM controller' fitted, what does DEBUG show at D0000 ?

What is the make/model of this 'MFM controller' ?

BTW: When I click on any of your attachments (e.g. "Attachment 53557"), I see an, "Invalid Attachment specified" error.
 
The MFM controller is a Western Digital WD1002A-WX.
According to the board "jumpers" (the ones in question are connected with a PCB trace) and stason, it has a 32K ROM. However, CheckIt tells me the Disk ROM is only 8K. (C800h to CA00h). However a 32K ROM would extend past D000h. Should I reconfigure my XT-IDE for somewhere higher? I've got free all the way up to F000h, according to CheckIt.
DEBUG.COM shows all FF past CA00

Also, I set a jumper on the hard disk that stason said might change the IRQ to 2, since CheckIt had "Hard Disk" in IRQ 5 for both of them. This seemed to have no effect, and the IRQ appeared to remain at 5.

According to stason, the IRQ of this controller is 320, so no conflict there.

Also of note: both CheckIt and the XT-IDE ROM see the MFM drive as two identical drives. Could this be related to my problem?
 
The MFM controller is a Western Digital WD1002A-WX.
There is normally a digit after the 'WX' part, e.g. 'WD1002A-WX1'.
What is the digit on yours ?

According to the board "jumpers" (the ones in question are connected with a PCB trace) and stason, it has a 32K ROM. However, CheckIt tells me the Disk ROM is only 8K. (C800h to CA00h).
Refer to [here]. I expect that CheckIt is determining ROM size by looking at the third byte. In your case, if DEBUG use shows you 10h, then I think that you can be confident that the 'ROM size' byte is what CheckIt is using.

For some cards, the card designer may be only mapping part of the fitted ROM into the motherboard's address space. (And that part reflected in the 'ROM size' byte.)

DEBUG.COM shows all FF past CA00
But maybe those FF's are in the ROM. Putting the ROM chip into a ROM reader would be a way to disprove that.

However a 32K ROM would extend past D000h.
If the start address is C8000, and all of the 32 KB sized ROM is mapped into the motherboard's address space, then the final ROM address will be CFFFF.

Presumably, this 32K ROM that you write of is a 27256. Based on what I see in the Western Digital section of [here], for an 8 KB sized BIOS, expected is a 2764 to be fitted. Do you see "27256" or "27C256" on the ROM chip ?

Should I reconfigure my XT-IDE for somewhere higher?
No hurt in trying.

I've got free all the way up to F000h, according to CheckIt.
On early PC class machines, CheckIt, and other reporting software, cannot interrogate cards for resource information. So, for example, they may not show you that a particular fitted network card has a RAM buffer (a buffer that the particular card only activates when the card's driver is loaded).

Also, I set a jumper on the hard disk ...
I am sure that you meant 'controller'. MFM drives do not generate interrupts - the controller does.

... that stason said might change the IRQ to 2, since CheckIt had "Hard Disk" in IRQ 5 for both of them. This seemed to have no effect, and the IRQ appeared to remain at 5.
Sometimes, CheckIt, and other reporting software, make bad assumptions. Assumptions like, 'Any serial port at 3F8 will be configured to use IRQ4, so report IRQ4.'

Also of note: both CheckIt and the XT-IDE ROM see the MFM drive as two identical drives. Could this be related to my problem?
Possibly.

Check your ST-225 drive. Only one of the four drive-select options is to have a jumper on it.
 
There is normally a digit after the 'WX' part, e.g. 'WD1002A-WX1'.
What is the digit on yours ?

Typo on my part. It is a 1.


Refer to [here]. I expect that CheckIt is determining ROM size by looking at the third byte. In your case, if DEBUG use shows you 10h, then I think that you can be confident that the 'ROM size' byte is what CheckIt is using.

For some cards, the card designer may be only mapping part of the fitted ROM into the motherboard's address space. (And that part reflected in the 'ROM size' byte.)


But maybe those FF's are in the ROM. Putting the ROM chip into a ROM reader would be a way to disprove that.


If the start address is C8000, and all of the 32 KB sized ROM is mapped into the motherboard's address space, then the final ROM address will be CFFFF.

Presumably, this 32K ROM that you write of is a 27256. Based on what I see in the Western Digital section of [here], for an 8 KB sized BIOS, expected is a 2764 to be fitted. Do you see "27256" or "27C256" on the ROM chip ?

No. What I presume is the ROM chip is marked:

62-000094-002
(c)WDC-86
609-2355003
M473252 8716A

I am sure that you meant 'controller'. MFM drives do not generate interrupts - the controller does.

Yes, I did. Another mistake.


Sometimes, CheckIt, and other reporting software, make bad assumptions. Assumptions like, 'Any serial port at 3F8 will be configured to use IRQ4, so report IRQ4.'


Possibly.

Check your ST-225 drive. Only one of the four drive-select options is to have a jumper on it.

I checked, and only pin 15-16 are jumpered
 
Typo on my part. It is a 1.
According to the few WD1002A-WX1 information sources at [here], the ROM could be either be 16K, 32K, or 64K sized.

If jumper pad W5 has pins 2 and 3 jumpered/wired, then you know the ROM is 16K sized.

If the ROM is socketed, and you have an EPROM reader, the ROM may return a make&model ID.

Check your ST-225 drive. Only one of the four drive-select options is to have a jumper on it.
I checked, and only pin 15-16 are jumpered
15-16 on an ST-225 is the first drive-select option.
( Which, incidentally, means that you must be using a flat control cable. )

And the 'radial' jumper off.
 
Back
Top