• Please review our updated Terms and Rules here

XTIDE tech support thread

Well, I'm afraid we have our answer:

09130001.jpg

For bonus points, try to figure out what the brand name of my CF card is.

I wonder what the ramifications of this is. If this happens, then what specifically is at fault? If the 6300, then why didn't most cards die a similarly horrible death?
 
Hmm...

I think the ramification is that IN AX,DX is out, but maybe DMA access is still good. The IDENTIFY information from my Hitachi CF card was so messed up that the XTCFV2 simply refused to recognize it. I had to use an original XTIDE to get the scrambled output on the 6300.

I suspect that most cards work because they limit their INs and OUTs to 8-bit mode. The bus converter board in the 6300 is a rather ugly state machine and it seems that they got things wrong with I/O, but not memory.

Ah well, more grist for James' mill, I suspect. Let me know if I can help.
 
Excellent finds! I guess an answer to this is to include port-mapped 8-bit transfer mode in the BIOS, and have the ability to set the card config register in the xtidecfg utility so that the card can be initialised by default to then one of four modes (16-bit port- or memory-mapped, DMA (8 bit BTW) or 8-bit port-mapped). Or just change port-mapped IO (which is the default) to 8-bit anyway.

Actually I'm prefering the latter - as DMA uses 8-bit transfers, so users of this machine could still boot and switch to DMA mode for higher throughput.
 
Would the BIOS not showing up at all be indicative of a physically bad card?

I have a v1 set to the default 300, D000h settings and JP1 and JP2 are also jumpered on the card. My IBM Model 25 reports an error in ROM when it boots up and IDECFG cannot flash the card, indicating a timeout error. Also, no BIOS is ever booted, but ROM error at boot up makes that rather expected. D000h is completely zeroed out in Debug with the card disabled, as is C000h, but either address gets the error in ROM message at boot. Debug at either D000h or C000h with the card enabled shows a full and correct BIOS in that region of memory.

I have an IDE->CF adapter plugged into the card with a 32MB Cisco flash card installed. I've been trying to get this to work on an IBM Model 25, 8086 version, with IBM DOS 3.3. The Model 25, lacking a molex connector, cannot power the CF adapter (planning on modding the XTIDE if I can get it to work), so I was thinking the card may not be showing due to not having something installed on it, though that makes little sense.

So I plugged it into a much newer Gateway system and booted via the IBM's boot disk. Same issue, cannot flash the card with the timeout error on multiple memory addresses, debug shows the correct XTIDE BIOS in memory at each attempt.

I have read through this entire thread and it seems my issue is going to turn up to be a solder somewhere, but I wanted to get an opinion, since I'll have to send the card to someone to redo the soldering if so.
 
raifield said:
no BIOS is ever booted, but ROM error at boot up makes that rather expected. D000h is completely zeroed out in Debug with the card disabled, as is C000h, but either address gets the error in ROM message at boot. Debug at either D000h or C000h with the card enabled shows a full and correct BIOS in that region of memory.
Click to expand...
The only way to determine "full and correct" is a byte by byte comparison with the source data file. Your "My IBM Model 25 reports an error in ROM" (which usually means that the ROM checksum is incorrect) suggests to me that a byte by byte comparison will reveal some differences.
 
raifield said:
Debug at either D000h or C000h with the card enabled shows a full and correct BIOS in that region of memory.
Click to expand...
This makes me think it is not a solder issue, but a corrupt ROM. Unless the data is *changing* when you read D000 out, i would say the electrical path is fine and you will not need to resolder anything. A single corrupt byte toward the end of the 8k ROM image would prevent it from loading, and you'd likely never be able to detect that visually.

I was thinking the card may not be showing due to not having something installed on it, though that makes little sense.
Click to expand...
Even if the card has no IDE devices attached to it, it will always sign on with a banner+boot menu, so that's not it.

you can dump out the ROM to a file and then post that file for comparison back to the original bios image by doing this little script in debug:

With the card installed, boot to floppy with debug.exe on it:
A:\>debug
-rcs
>CS xxxx
:d000
-rcx
>CX 0000
:2000
-n test.bin
-w cs:0
>Writing 2000 bytes
-q

that should create a file on your floppy called test.bin which should be 8k in size. We can then compare that file against what was flashed in and see if there is an error somewhere.
 
I looked at the BIOS in memory again before I ran those commands and it is definitely corrupt now, FF's randomly dotted across the memory segment. ".IOS" might be proper in an Apple, but not here. I read D000 twelve times, each time exactly the same, but I'm not sure what caused the BIOS to start zeroing out.

Unfortunately, this still means I need to reflash the ROM, but each attempt leads to a timeout error in idecfg using xt_ide.bin

The output of the commands provided above simply resulted in an 8k test.bin which is blank when viewed in DOS and full of garbage when viewed in Windows.
 
check the write-enable jumper is set, and that CDP mode is set in xtidecfg. But most likely the EEPROM just needs replacing.
 
also play with the SDP (software data protect) options in xtidecfg. WIth certain ROMs (SEEQ for example) have problems with SDP on occasion. My trick is to turn off SDP completely, flash the ROM and then flash it again with it turned on. If you can get it flashed but cannot turn SDP on, then you have a vulnerable ROM which is subject to corruption, which is what I suspect got you here now. The jumper to write protect/enable the ROM will help with that. :)

If you still can't get the eeprom flashed, send me a PM. I have a burner and can try getting it reprogrammed. If you originally bought the card/kit from me, and if you've got a faulty eeprom, I will replace it.
 
Ordered a new Atmel EEPROM, hopefully that clears things up. I wasn't aware the XT IDE card would flash a blank chip.
 
raifield said:
Ordered a new Atmel EEPROM, hopefully that clears things up. I wasn't aware the XT IDE card would flash a blank chip.
Click to expand...
Yes - using the flash utility that comes with the BIOS, you can essentially use the XT-IDE as a bare-bones eeprom burner for the one chip-type. Albeit a cumbersome one :)
 
Eh, got the new Atmel chip, made sure the orientation was correct, but still the same issue. I either get a message that the polling timed out and the ROM was not flashed. The address in the xtidecfg program matches the one jumpered on the card and the Read/Write protect jumper is "in", so I should be able to write to the chip. I guess I have a bad card, maybe the solder. Bummer.
 
probably fixable simply by just re-hitting all the solder joints with an iron to get them flowing again. it could just be one slightly cold solder joint that is causing all your headaches.
 
I'll buy a soldering iron and see what happens. Parts Express has a Stahl Tools SSVT iron for $15. I have no experience with soldering, but I doubt I can make the inoperable card less operable unless I stab the PCB with the iron.
 
I just finished assembling a recently acquired Version 2 board. I am getting ready to try it out, but am getting just a bit confused on the jumper settings (I have previous experience with version 1 boards X 2) even after looking at the pictures, wiki, help thread, and schematic. I understand the IO and memory addresses OK, as well as the ROM and write enable. But I am getting confused on the other settings. What really through me off was when I looked at the picture on the wiki, it looks as though the jumpers are configured for a 256 ROM rather that a 64 (and the board pictured has a 64). Can someone help?
Thanks, BT
 
I've done a bit more research on my own, using a meter to trace to ground to identify the orientation of the pins to jumper.
I think K6 and K7 now make sense. But still a bit confused on K1(which appears to be set to 256 ROM in the picture) and K2.
 
that very well may have been my mistake with the eeprom size jumper. i doubt it matters since the eeprom itself isn't that big it can't possibly steal any addresses off the bus that it doesn't have.
 
please do help edit the wiki with any updates you have, including a better picture of the finished card.
glad you got it running!
 
I would just like to say thanks to everyone who helped get the XTIDE project up and running.
After an evening and a morning I worked out the settings for my Sega TeraDrive and am now up and running on both my Model 2 and Model 3 units.
Below is a video of the unit in action - a TeraDrive with a less prone to failure hard drive sure makes my weekend! So thank you all! :D

 
You must log in or register to reply here.
Back
Top