• Please review our updated Terms and Rules here

XTIDE V4 troubleshooting IBM 5155

mykrowyre

Experienced Member
Joined
Jan 28, 2019
Messages
171
Location
Saint Augustine, FL
I recently built an XT-IDE kit V4 from glitchworks... the EPROM did not appear to be programmed so I burned v 1.1.5 of the Universal XT-IDE bios (XT version).

I've tried various dip switch combinations and the closest I've gotten is I see the following when I boot with no harddrives attached:

ROM D000
ERROR PRESS [F1] TO CONTINUE

I figured I should see some sort of Bios message from the XT-IDE telling me no drives are attached.

Anyone have any ideas? I can't seem to find any instructions for the board, or the dip switch positions.


Thanks
 
I recently built an XT-IDE kit V4 from glitchworks... the EPROM did not appear to be programmed so I burned v 1.1.5 of the Universal XT-IDE bios (XT version).

I've tried various dip switch combinations and the closest I've gotten is I see the following when I boot with no harddrives attached:

ROM D000
ERROR PRESS [F1] TO CONTINUE
I think Glitch pre-programs the EEPROM with XUB v1.1.5 for the Kits, When you flashed the EEPROM did you configure the XUB first before flashing ?, If you didn't i would expect to see that error, You must configure first and then flash.

I figured I should see some sort of Bios message from the XT-IDE telling me no drives are attached.
A fully working and properly configured XT-IDE / XUB will show " Not Found ", for later revisions of the XUB but can't remember if it's the same for v1.1.5 However you must have drives attached when Auto configuring when using the newer XUB & XTIDECFG.COM.

Anyone have any ideas? I can't seem to find any instructions for the board, or the dip switch positions.
Modem7 has info on Jumper / Switch settings on his website http://minuszerodegrees.net/xtide/rev_4/XT-IDE Rev 4 - general.htm
 
Code:
ROM D000
ERROR PRESS [F1] TO CONTINUE

This usually means you didn't generate the checksum byte at the end of the ROM. The BIN images of the XUB don't have a checksum byte at the end by default (not sure why this is). The XTIDECFG program will generate it for you.

I think Glitch pre-programs the EEPROM with XUB v1.1.5 for the Kits, When you flashed the EEPROM did you configure the XUB first before flashing ?, If you didn't i would expect to see that error, You must configure first and then flash.

That's correct, they all get pre-programmed in an old prototype rev 3 board with a ZIF socket, to ensure they meet spec on the actual ISA bus. I was having problems with defective EEPROMs from a previous supplier so I started pre-programming all of them. The current supplier (Mouser) hasn't given a single defective EEPROM, but people seem to like having them pre-programmed, so that's what I do!
 
Code:
ROM D000
ERROR PRESS [F1] TO CONTINUE

This usually means you didn't generate the checksum byte at the end of the ROM. The BIN images of the XUB don't have a checksum byte at the end by default (not sure why this is). The XTIDECFG program will generate it for you.



That's correct, they all get pre-programmed in an old prototype rev 3 board with a ZIF socket, to ensure they meet spec on the actual ISA bus. I was having problems with defective EEPROMs from a previous supplier so I started pre-programming all of them. The current supplier (Mouser) hasn't given a single defective EEPROM, but people seem to like having them pre-programmed, so that's what I do!

Thanks yeah I was the one on ebay who had the defective TL866 wipe my eprom. I purchased a new one and it works but I didnt know about the checksum when i reprogrammed the eprom.. Problem is, I dont have a way to get the XTIDECFG program to the PC short of typing the hex manually and unhexing it with a basic program.

Any chance you could send me the 1.1.5 rom image with checksum, or tell me the checksum value assuming rom version is the same? I guess I could also look at the code and see how the checksum is calculated and add it manually but that is less fun.

Thanks
Tom
electronictreasure
 
I can get you a ROM image if necessary; however, you can run XTIDECFG on any DOS PC, it should even run in DOSBOX on Linux/Mac/Windows/whatever.
 
I'd use a more recent revision and jumper the XT-IDE for Hi Speed mode, r591 works fine on my r4 cards as does the new r601. I often use my XP PC to configure the XUB and burn to Eproms.
 
Last edited:
Yeah, you can certainly use a newer XUB revision -- I ship v1.15 simply because, in my experience, it's easier for folks to figure out if their kit-built board is working. We've had several cases where v1.15 worked fine but newer revisions had issues.
 
Thanks guys! I used the XTIDECFG on a 486 laptop, and saved the modified bios. That generated the correct checksum, which worked once burned to the eprom.

Cool!
 
Excellent, glad you got it going! I need to actually finish writing up a proper manual covering all of this...!
 
Yeah, you can certainly use a newer XUB revision -- I ship v1.15 simply because, in my experience, it's easier for folks to figure out if their kit-built board is working. We've had several cases where v1.15 worked fine but newer revisions had issues.

Yep i understand why, I used v1.1.5 for a long time and found it very stable, IIRC around early beta 2 or 3 it got a bit buggy but improved and has come a long way since v1.1.5 (r70). I suspect a lot of people are using an older revision as it does the job and works for them, " If it ain't broke don't fix it " sort of thing.
 
It does seem that a fair number of people upgrade to 2.x for high-speed mode, though. It does make a *significant* difference in speed. Of course, even COMPAT mode with v1.15 is faster than my old MFM drive setup :)

It would probably help if there were binary images available for 2.x that are 8K *and* have the full boot menu instead of the hotkeys menu.
 
...It would probably help if there were binary images available for 2.x that are 8K *and* have the full boot menu instead of the hotkeys menu.
I've no idea what that would involve setting it up server side, Though you can always build from source which is what i do, There's really little difference between the HotKey Bar and Boot Menu except of course the Boot Menu display's more info and more recently more colour schemes have been added which requires the BootMenu Module. I can see the attraction to the BootMenu though.
 
The BIN images of the XUB don't have a checksum byte at the end by default (not sure why this is).
Probably because it's an extra step in the build process that wasn't even possible until GregLi added an option to the makefile that invokes a perl script to calculate the checksum. NASM can't do it on its own.

So the only other option would be to use the configurator (XTIDECFG) and create the checksum manually but that would almost certainly be a waste of time since 99 times out of 100 the user need to configure the BIOS for his or her machine anyway. I'm actually amazed that the concept of a ROM that needs to be configured is so strange to people. I have on more than one occasion seen videos on youtube (or images elsewhere) where people boot their vintage machines and something like this is clearly visible;
Code:
Master at 1F0h: Generic 1234
Slave  at 1F0h: not found
Master at 0h: not found
Slave  at 0h: not found
 
Yeah, I need to finish writing a manual, complete with screenshots of the XUB configuration/flashing process...

I wrote a little C program to calculate the checksum and print it, or optionally stick it in the last byte of the ROM. This was back when Hargle's BIOS was the thing to hack on.

I'd think a "default options with checksum" build for the base XUB images would be equally sensible, but it's not my project :) I'll probably start building my own 8K ROM images at some point, with the full menu included. Another project for another day, though.
 
Back
Top