I'm not sure about the changing the slot order part; first simplify the system as much as possible by removing all adapters except those required (CGA, FDD and XTIDE specifically). Presuming the error remains, try disabling the XTIDE BIOS then boot from a floppy. Re-enable the BIOS (with the system running) then re-write the ROM (i.e. run the xtidecfg utility and write out the BIOS again). Reboot and with a bit of luck all will be good.
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
XTIDE tech support thread
- Thread starter hargle
- Start date
Thanks for the quick reply. There aren't any other cards to remove, since the SP2FD takes the place of serial, parallel, and floppy controller cards. I don't know how to disable the XTIDE BIOS and re-enable it, but I recall that there's info on such matters at the beginning of this thread, so I'll review that.
Hargle mentioned that the card has the latest BIOS, so maybe I shouldn't use links to earlier versions at the beginning of the thread. Do you have a link to the latest BIOS?
Thanks again!
modem7
10k Member
The corrupt EEPROM is not halting the boot process - you can still boot from floppy with the XT-IDE fitted. Therefore, you should not need to temporarily disable the EEPROM (jumper JP1 enables/disables)
modem7
10k Member
hargle
Veteran Member
has anyone else put an XTIDE in a 5155? Considering all the machines that we know it does work in, even a bunch of oddball clones, putting one in a 5155 should be a home run.
Here's what we're up against:
The card worked fine for me (although not as heavily tested as what gib has done lately) in my zenith 8088. I verified it had the latest non-beta universal BIOS on it, and that the ROM was in software write protect mode.
Gib received the card, put it in and is able to boot to it, but everything, including typing on the keyboard, and executing programs off CF, was significantly slower when the XTIDE was installed.
Moving the card into a different slot made the machine operate at a normal/correct speed.
3 days later, the mainboard bios has now detected a ROM error- a corrupt image on the XTIDE.
I'm beyond stumped how the XTIDE could impact things so drastically speed related, how moving the card into a different slot would change anything, or how the software write protect has somehow been bypassed. I think this is why I've retired from XTIDEs.
Here's what we're up against:
The card worked fine for me (although not as heavily tested as what gib has done lately) in my zenith 8088. I verified it had the latest non-beta universal BIOS on it, and that the ROM was in software write protect mode.
Gib received the card, put it in and is able to boot to it, but everything, including typing on the keyboard, and executing programs off CF, was significantly slower when the XTIDE was installed.
Moving the card into a different slot made the machine operate at a normal/correct speed.
3 days later, the mainboard bios has now detected a ROM error- a corrupt image on the XTIDE.
I'm beyond stumped how the XTIDE could impact things so drastically speed related, how moving the card into a different slot would change anything, or how the software write protect has somehow been bypassed. I think this is why I've retired from XTIDEs.
evildragon
Veteran Member
My XT-IDE rev2 card died.. When it's in the computer it causes random Parity Check 1's, and sometimes memory errors at POST in the RAM range. I have removed it and put the rev 1 card back in..
Parity check errors are caused by bad address decoding (card driving data bus when it's not selected). I don't understand how an XTIDEv1 could impact the speed of a machine since it doesn't drive IORDY so either it responds or it doesn't.
But XTIDEv1 does work just fine in 5155; it's only an XT afterall.
But XTIDEv1 does work just fine in 5155; it's only an XT afterall.
I wonder if my use of Fdisk the night before may be the reason the ROM subsequently failed.
My main CF is a Samsung, which works fine on the XTIDE. But my intended backup CF is a Kingston that I had tried partitioning, formatting, and making a bootable disk on another PC. It refused to boot on the 5155, so, I thought I might get it to work by deleting the partition and repartitioning it on the 5155. I finally gave up and went to bed. I didn't think using Fdisk could affect the XTIDE card, but apparently it did. If that's the case, then I should be able to re-write the ROM and then just never use Fdisk on the 5155 again. (?)
On the other hand, might pearce_jj's CF card be less picky about CFs, i.e., accept the Kingston card that the XTIDE rejected?
About the slot order, all I can say is that the first and ONLY thing I did in response to the drastic slowdown in computer keyboarding and program execution was to move the XTIDE card from a slot after the multifunction card to the slot before it. All the problems disappeared...
until I ran into the ROM error a couple of days later.
My main CF is a Samsung, which works fine on the XTIDE. But my intended backup CF is a Kingston that I had tried partitioning, formatting, and making a bootable disk on another PC. It refused to boot on the 5155, so, I thought I might get it to work by deleting the partition and repartitioning it on the 5155. I finally gave up and went to bed. I didn't think using Fdisk could affect the XTIDE card, but apparently it did. If that's the case, then I should be able to re-write the ROM and then just never use Fdisk on the 5155 again. (?)
On the other hand, might pearce_jj's CF card be less picky about CFs, i.e., accept the Kingston card that the XTIDE rejected?
About the slot order, all I can say is that the first and ONLY thing I did in response to the drastic slowdown in computer keyboarding and program execution was to move the XTIDE card from a slot after the multifunction card to the slot before it. All the problems disappeared...
until I ran into the ROM error a couple of days later.
Out of interest, try something else in that suspect slot and see what happens.
Re the corrupt ROM and parity issues, it could just be a bad ROM. Indeed someone posting similar symptoms only a couple of weeks ago.
Re CF compatibility, I've had timing related issues with a Kingston card in particular (which identifies itself as Hitachi); this has been resolved by using 8-bit mode. So I would expect better compatibility.
Re the corrupt ROM and parity issues, it could just be a bad ROM. Indeed someone posting similar symptoms only a couple of weeks ago.
Re CF compatibility, I've had timing related issues with a Kingston card in particular (which identifies itself as Hitachi); this has been resolved by using 8-bit mode. So I would expect better compatibility.
hargle
Veteran Member
absolutely not. there should be absolutely no reason for FDISK to attempt to write into the D000 range where your card is installed. Even then, the card has software write protect enabled (which I verified before it shipped). The only way to unlock the write protect in the rom is to write a magic sequence of values to a specific address, and fdisk doesn't know or need to know how to do such a thing.
The only thing I can think of is weird power or a failing chip on the card (or a failing chip caused by weird power).
Okay, so the ROM error following use of Fdisk was just a coincidence. If we're left with unexplained (or unexplainable, at least for now) power and/or chip problems, then perhaps I should give pearce_jj's CF card a try. Maybe it will find my 5155 more welcoming than the XTIDE did.
modem7
10k Member
NobodyIsHere
Veteran Member
- Joined
- Dec 21, 2006
- Messages
- 2,410
Hi
I'd recommend using an EPROM. That rules out quirky ISA bus behavior that may cause inadvertent writes to the EEPROM. Also you may have a flakey EEPROM.
27C64 is very reliable.
Thanks and have a nice day!
Andrew Lynch
I'd recommend using an EPROM. That rules out quirky ISA bus behavior that may cause inadvertent writes to the EEPROM. Also you may have a flakey EEPROM.
27C64 is very reliable.
Thanks and have a nice day!
Andrew Lynch
Chuck(G)
25k Member
Okay, I finally got to put an XTIDE (original) into my AT&T PC6300. Note that this is the one that has the so-called "Chuck Mod" (whoever that is).
The 6300 is running an 8MHz V30 (NEC V-series equivalent of the 8086) and 1.43 BIOS, the 16-bit "bus correction" mod and all.
A very odd thing happens.
Bytes obtained via a word input or output (e.g. IN AX,DX/OUT DX,AX) come out in reverse order from that of a standard 8088 PC! In other words, instead of, for example, "Hitachi ", I see "iHathc i"--and of course, it won't boot. Apparently, the bus converter board runs two I/O cycles for word I/O all right, but in the wrong order!
The XT-CFV2 also plays dumb, but I don't know if it's for the same reason.
Does anyone have the XTIDE with the "Chuck Mod" and a PC6300 without the bus converter mod to try things out on? This is very strange. I could clearly fix this by retreating to single-byte I/O, but I'd like to know if it's just my system before I burn a new BIOS image.
@James, please note re: XT-CFV2!
The 6300 is running an 8MHz V30 (NEC V-series equivalent of the 8086) and 1.43 BIOS, the 16-bit "bus correction" mod and all.
A very odd thing happens.
Bytes obtained via a word input or output (e.g. IN AX,DX/OUT DX,AX) come out in reverse order from that of a standard 8088 PC! In other words, instead of, for example, "Hitachi ", I see "iHathc i"--and of course, it won't boot. Apparently, the bus converter board runs two I/O cycles for word I/O all right, but in the wrong order!
The XT-CFV2 also plays dumb, but I don't know if it's for the same reason.
Does anyone have the XTIDE with the "Chuck Mod" and a PC6300 without the bus converter mod to try things out on? This is very strange. I could clearly fix this by retreating to single-byte I/O, but I'd like to know if it's just my system before I burn a new BIOS image.
@James, please note re: XT-CFV2!
Chuck(G)
25k Member
As far as I can tell. The XTIDE w/Chuck mod just gets as far as reading the response from the IDENTIFY command, determines that it's all messed up and refuses to go any further. In other words, if the XTIDE executes an IN AX,DX instruction on an 8088, the BIU says that it's equivalent to
IN AL,DX
INC DX
MOV AH,AL
IN AL,DX
XCHG AL,AH
But the 6300 leaves off the "exchange"; that is, the bus converter on the 6300 gets the order wrong. My 6300 has all of the ECOs installed on it. I wonder if itś just my 6300/M24 or itś a universal thing. Anyone with an M24 or 6300 want to conduct a little test--you don't need an XTIDE?
Let me know and I'll concoct a little test. The BIOS rev doesn't matter.
IN AL,DX
INC DX
MOV AH,AL
IN AL,DX
XCHG AL,AH
But the 6300 leaves off the "exchange"; that is, the bus converter on the 6300 gets the order wrong. My 6300 has all of the ECOs installed on it. I wonder if itś just my 6300/M24 or itś a universal thing. Anyone with an M24 or 6300 want to conduct a little test--you don't need an XTIDE?
Let me know and I'll concoct a little test. The BIOS rev doesn't matter.
Chuck(G)
25k Member
The byte I/O BIOS works in the 6300, but it's not impressive. With an 8MHz V30 CPU, Norton SI gives a 3.7X XT rating for the CPU, but only a 1.2X for the disk.
Has anyone tried this on other 16-bit bus "super XT" PCs, such as the Tandy 1000 TL, Stearns Desktop, etc.? I'm wondering if the glitch in the bus converter logic is just a fluke.
Has anyone tried this on other 16-bit bus "super XT" PCs, such as the Tandy 1000 TL, Stearns Desktop, etc.? I'm wondering if the glitch in the bus converter logic is just a fluke.
Trixter
Veteran Member
I tested Pearce's XTCFv2 in a Tandy 1000 TL and also a TX in "port" mode and they worked just fine. I also tested in a 6300 WGS, which is also a "super XT" PC; it worked with both the native 8086 and the NEC V30 you threw me.
I have not yet tested it in my 6300, but it sounds like that day is coming very soon (like, tonight). My 6300 does NOT have the bus mod -- it's a stock 8MHz 8086 with 1.43 BIOS and the stock video and hard disk. I will report back results.
I have not yet tested it in my 6300, but it sounds like that day is coming very soon (like, tonight). My 6300 does NOT have the bus mod -- it's a stock 8MHz 8086 with 1.43 BIOS and the stock video and hard disk. I will report back results.