• Please review our updated Terms and Rules here

XT-IDE Bios at F200 - conflict

RWIndiana

Experienced Member
Joined
Dec 18, 2010
Messages
52
I just found an interesting problem. Backstory (Leading Edge Model D): I got a xt-ide deluxe with CF, and the bios address on the card would only go up to D(something or other), but it would not work at that address or anything lower due to a conflict with a SCSI card/ROM. There is an extra ROM socket on the motherboard, so I took the ROM out of the XT-IDE card and stuck it in there, half expecting to blow everything up, but it worked perfectly! But apparently the memory address (F200h) makes one game (Tank Wars) not work, coughing up various "bad file at F200" or "memory string corrupt" or something like that.

I'm not exactly sure what's even happening, but I wonder if there is a way it can be worked around. Can I unload the XT-IDE from F200 (I don't need it on all the time)? Can I force the game to use a different address? Is F200 simply not a safe address to use?

Any insights appreciated!
 
I just found an interesting problem. Backstory (Leading Edge Model D): I got a xt-ide deluxe with CF, and the bios address on the card would only go up to D(something or other), but it would not work at that address or anything lower due to a conflict with a SCSI card/ROM.
Whether that be the Monotech XT-IDE Deluxe or the Blue Lava Systems XT-IDE Deluxe, both cards can have their ROM set to one of 16 possible base addresses, ranging from C0000 to DE000.
The ROM on your SCSI card cannot possibly be occupying the vast majority of that range.

There is an extra ROM socket on the motherboard, so I took the ROM out of the XT-IDE card and stuck it in there, half expecting to blow everything up, but it worked perfectly!
I think your "worked perfectly" should be "appears to work".

But apparently the memory address (F200h)
A motherboard address of F2000.
Suspiciously, that is 8 KB past F0000, F0000 being more likely what the subject ROM socket is addressed to start at.

At [here] is a DOS program named RAYXTIDE.
Does it find the XT-IDE Deluxe's BIOS (the 'XTIDE Universal BIOS') at F0000 or F2000?
And does it report any problems ?
 
It may just be the game - it may be expecting BASIC in ROM? Or even IBM BIOS? Just to steal functions or it appears in this case, a string.
 
Thank you for that. Here is the output of rayxtide with the ROM in the motherboard:

"
*******************************************************
* RAYXTIDE version 3.1
* Executed: 12/10/2022 08:08:20 (dd/mm/yyyy hh:mm:ss)
*******************************************************

+--------------------------------------------------+
| Part 1 of 4 - Motherboard class |
+--------------------------------------------------+
CPU type = 8086/8088/80186/80188/V20/V30
Motherboard class = PC or XT class (based on CPU type)

+--------------------------------------------------+
| Part 2 of 4 - ID the motherboard's BIOS ROM |
+--------------------------------------------------+
Model byte at FFFFE = FE (XT)
Date at FFFF5 = 12/27/85 (in clones, do not trust this date)
Checksum of last 8 KB = 000EE100 (simple byte addition)
CRC32 of last 8 KB = AA1AB165
BIOS identified as = [UNABLE TO IDENTIFY]

+--------------------------------------------------+
| Part 3 of 4 - Look for XT-IDE card's BIOS ROM |
| (XTIDE Universal BIOS, a.k.a. XUB) |
+--------------------------------------------------+
Searching for the XUB .....................................................................................................

>>> Found



PROBLEM - The XTIDE Universal BIOS appears at multiple addresses.
A list of those addresses follows:
Address = F0000
Address = F2000
Address = F4000
Address = F6000

Some possibilities:
* Faulty XT-IDE card.
* On VCF XT-IDE Rev 2 card, jumpers K1/K2/K6/K7 are incorrectly set.
* On VCF XT-IDE Rev 3 card, the two '8K' switches are incorrectly set.
* On VCF XT-IDE Rev 4 card, the two '8K' switches are incorrectly set.

Aborting ...
"






Now, I just tried it with the rom back in the xt-ide deluxe, and rayxtide sees it at D0000 whether the scsi card is present or not and does not report any issues, but the computer does not seem to recognize it at all with the scsi present. So the real problem is getting around the scsi card? But as you said, it obviously can't be occupying all those addresses, so I'm not sure what's going on.

The scsi card is a seagate 20637-EC with st 01 / 02 rom chip.
 
PROBLEM - The XTIDE Universal BIOS appears at multiple addresses.
A list of those addresses follows:
Address = F0000
Address = F2000
Address = F4000
Address = F6000
That shows that putting the ROM onto your model of motherboard is invalid. The fact that the XUB code is repeated four times suggests that your motherboard takes 32 KB sized ROM's (e.g. 27C256 EPROM)

( I see in the Model D Operator's Guide that jumper J16 is set according to ROM size, but changing that would affect the fitted BIOS ROM.)

If you want to pursue the idea of putting the XUB into a motherboard ROM, then what I expect to work is getting a 27C256, and putting the 8 KB sized XUB code into the bottom of that, filling the remainder of the EPROM with zeroes.

But as you have acknowledged, putting the XUB into a motherboard ROM should not be required.

Now, I just tried it with the rom back in the xt-ide deluxe, and rayxtide sees it at D0000 whether the scsi card is present or not and does not report any issues, but the computer does not seem to recognize it at all with the scsi present. So the real problem is getting around the scsi card?
Are you saying that the XT-IDE Deluxe is fully operational when the SCSI card is removed ?
If not, what exactly are the symptoms?
If so, what exactly are the symptoms when the SCSI card is present?

(Note that RAYXTIDE only looks at the ROM component of the XT-CF, not the entire XT-CF.)

Two common symptoms we see reported on these forums are:
1. The XUB's splash screen does not appear; or
2. The XUB's splash screen appears, but the XUB does not show details of the attached CF - see [here].
 
That shows that putting the ROM onto your model of motherboard is invalid. The fact that the XUB code is repeated four times suggests that your motherboard takes 32 KB sized ROM's (e.g. 27C256 EPROM)

( I see in the Model D Operator's Guide that jumper J16 is set according to ROM size, but changing that would affect the fitted BIOS ROM.)

If you want to pursue the idea of putting the XUB into a motherboard ROM, then what I expect to work is getting a 27C256, and putting the 8 KB sized XUB code into the bottom of that, filling the remainder of the EPROM with zeroes.

But as you have acknowledged, putting the XUB into a motherboard ROM should not be required.


Are you saying that the XT-IDE Deluxe is fully operational when the SCSI card is removed ?
If not, what exactly are the symptoms?
If so, what exactly are the symptoms when the SCSI card is present?

(Note that RAYXTIDE only looks at the ROM component of the XT-CF, not the entire XT-CF.)

Two common symptoms we see reported on these forums are:
1. The XUB's splash screen does not appear; or
2. The XUB's splash screen appears, but the XUB does not show details of the attached CF - see [here].


XUB and attached drives are fully operational when the scsi card is removed, but seemingly non-existent when the scsi card is installed.

I don't know if it's helpful, but I used debug to locate the scsi bios at DC000 (continuing on to DE000 which is the highest my xt-ide deluxe can go).

With a normal XT-IDE rev. 1 card At DE000 or anything lower, the same symptoms present, but anything E0000 or higher works as expected. Is it possible that the scsi card nullifies or causes the computer to skip anything with a lower address? I have been unable so far to find a way to change the rom memory address on the Seagate scsi card. :(

If there would be a way to load the xt-ide bios after boot, that would be acceptable, as I mainly use it for backup and transfers.
 
Another clarification, I don't know that the bios address *can't* be changed on the scsi card, I just don't know how.
 
Is it possible that the scsi card nullifies or causes the computer to skip anything with a lower address?
Yes, possible. And a BIOS upgrade on the SCSI card may be a possible answer.

Another clarification, I don't know that the bios address *can't* be changed on the scsi card, I just don't know how.
It sounds like your card is a Seagate ST01 or ST02. Maybe post a photo.

If so, there is an installation guide at [here]. There are jumpers to control the ROM start address. "DC00H" appears in table 5.
 
Is it possible that the scsi card nullifies or causes the computer to skip anything with a lower address?
I don't write BIOS expansion code, and so I am unaware of intricacies, etc.

Sometimes I see unexpected behaviour that I intend to investigate later. "Why is it so?" For example, see 'example #1' at [here]. I would have thought that the XTIDE Universal BIOS (XUB), being at a lower address, would show its bannner/splash text first, but it doesn't.
 
Can I unload the XT-IDE from F200 (I don't need it on all the time)? Can I force the game to use a different address? Is F200 simply not a safe address to use?

Just out of curiosity here, what does the splash screen you see when you boot up say the location of the XTIDE BIOS is? (It should tell you its address @whatever.)

I concur that what's going on here is you stuck an 8K EPROM into a socket that covers 32K of address space, and as a result you're seeing the same ROM contents mirrored four times. Since I assume you're not seeing the XTIDE banner more than once and since your system actually works I assume the XTIDE BIOS code is smart enough to not try to run two copies of itself and is picking one of them to go with. (I would guess it's the F000 one, but I'm not sure how this situation would resolve itself in the wild.) While this isn't really "according to Hoyle" correct why this tank game you're trying to play (is this it?) should care even the slightest about it is utterly baffling to me.

On a real IBM PC the ROM BASIC code starts at... F600, I think? and the ROM sockets on the motherboard go down to F400. (IE, there's one unused.) PC XT BIOSes will thus usually be programmed to scan for BIOS extensions (which I believe can reside on 2K boundaries) up to F400. It's perfectly legit to put the XT BIOS up there, I do it on my own machine. (An extremely haxxored Tandy 1000HX where I did weird voodoo to make the F000 slot available.) In fact, if you *can* do it it's a great thing to do because it clears up more potential upper memory block space for UMB and EMS page frame cards. I do agree it'd probably be "better" if you were to get rid of the phantom extra copy of the BIOS code; the most straightforward solution would be to switch to a 32K EEPROM, burn the BIOS into the first 8K of it, and fill the rest with zeros... but, again, why does this dumb tank game care? That makes zero sense.
 
Yes, possible. And a BIOS upgrade on the SCSI card may be a possible answer.


It sounds like your card is a Seagate ST01 or ST02. Maybe post a photo.

If so, there is an installation guide at [here]. There are jumpers to control the ROM start address. "DC00H" appears in table 5.
That did it! Apparently it is indeed the ST01 8bit. Picture of identical care here: https://i.ebayimg.com/images/g/AEQAAOSwBw5XRHvX/s-l640.jpg

Changed the rom address to CE00, now the XUB seems to be working correctly on D000.

I am amazed that you were able to find all this information. Thank you.

Oddly, the game originally in question still doesn't work with XUB installed, giving me a "string space corrupt" error and and screen junk (random characters). Hmm. I guess my next step at this point is to find an easy way to disable/enable the XUB at will, which should be much more feasible since its back on the card again, or find a patched version of the game, which seems unlikely. ;)
 
Just out of curiosity here, what does the splash screen you see when you boot up say the location of the XTIDE BIOS is? (It should tell you its address @whatever.)

I concur that what's going on here is you stuck an 8K EPROM into a socket that covers 32K of address space, and as a result you're seeing the same ROM contents mirrored four times. Since I assume you're not seeing the XTIDE banner more than once and since your system actually works I assume the XTIDE BIOS code is smart enough to not try to run two copies of itself and is picking one of them to go with. (I would guess it's the F000 one, but I'm not sure how this situation would resolve itself in the wild.) While this isn't really "according to Hoyle" correct why this tank game you're trying to play (is this it?) should care even the slightest about it is utterly baffling to me.

On a real IBM PC the ROM BASIC code starts at... F600, I think? and the ROM sockets on the motherboard go down to F400. (IE, there's one unused.) PC XT BIOSes will thus usually be programmed to scan for BIOS extensions (which I believe can reside on 2K boundaries) up to F400. It's perfectly legit to put the XT BIOS up there, I do it on my own machine. (An extremely haxxored Tandy 1000HX where I did weird voodoo to make the F000 slot available.) In fact, if you *can* do it it's a great thing to do because it clears up more potential upper memory block space for UMB and EMS page frame cards. I do agree it'd probably be "better" if you were to get rid of the phantom extra copy of the BIOS code; the most straightforward solution would be to switch to a 32K EEPROM, burn the BIOS into the first 8K of it, and fill the rest with zeros... but, again, why does this dumb tank game care? That makes zero sense.

Great questions....
The splash screen said that the XUB was at F200h.

The tank game you referenced is identical in concept and probably in gameplay by the looks of it, however it is definitely not the same game. I'm guessing it's a later version of the same game by the same company? Here is what mine looks like https://www.myabandonware.com/media/screenshots/t/tank-wars-1y7/tank-wars_2.png
 
I would have thought that the XTIDE Universal BIOS (XUB), being at a lower address, would show its bannner/splash text first, but it doesn't.
At option ROM init, all XUB does is hook interrupt 19h. Everything visible (the banner/splash text, hotkey bar, boot menu and of course drive detection) happens later when the system BIOS invokes interrupt 19h to boot the operating system. This is the concept we call "late initialization" (as opposed to "early initialization" where drive detection etc is done at option ROM init - which was an option in earlier versions of XUB). We also have the "very late initialization" where drive detection etc happens the first time interrupt 13h is invoked - this is for machines where hooking interrupt 19h doesn't work for some reason.

Anyway, the reason XUB appears at segment F200h is probably because the option ROM scan stops before F400h, and because of how XUB hooks into interrupt 19h, only the last instance called will be installed. So it's not really as smart as you might think @Eudimorphodon.

If the SCSI BIOS also hooks interrupt 19h after XUB (which happens when XUB is at a lower segment address than the SCSI BIOS) then XUB will not appear at all for the same reason.

As for the weird errors from that Tank game - my only advice is to try enabling Full operating mode.
 
As for the weird errors from that Tank game - my only advice is to try enabling Full operating mode.
That did it! I guess I didn't realize what Full operating mode was. I suppose if I had read the instructions....
Apparently the tank game tries to use Rom basic for some reason, even though it doesn't actually need it. I should try running it on the IBM and see what it does.
 
Sometimes I see unexpected behaviour that I intend to investigate later. "Why is it so?" For example, see 'example #1' at [here]. I would have thought that the XTIDE Universal BIOS (XUB), being at a lower address, would show its bannner/splash text first, but it doesn't.
At option ROM init, all XUB does is hook interrupt 19h. Everything visible (the banner/splash text, hotkey bar, boot menu and of course drive detection) happens later when the system BIOS invokes interrupt 19h to boot the operating system. This is the concept we call "late initialization" (as opposed to "early initialization" where drive detection etc is done at option ROM init - which was an option in earlier versions of XUB). We also have the "very late initialization" where drive detection etc happens the first time interrupt 13h is invoked - this is for machines where hooking interrupt 19h doesn't work for some reason.
Thank you for the explanation.

(Diagnosis is made easier when one understands how stuff works.)
 
Back
Top