XTIDE Universal BIOS - success with other cards?

[Megatron-uk]

Good! That should settle the matter of port assignments.

Next, have you used DEBUG to actually locate the copy of your new IDE BIOS PROM in memory? Is it all there?

With the eprom installed in the 3C509B the system does not POST, so I am unable to test it. I was going to try another 27c256 and a 27c128 to see if it was purely down to the individual eprom, but I ran out of time last night.
However, with the XT-IDE BIOS installed in the SCSI card the system boots (though as mentioned no XT-IDE BIOS messages are seen) - I'll try DEBUG tonight to see if it is actually getting loaded in memory.

 

[Chuck(G)]

Some SCSI cards appropriate a bit of the EPROM address space for local scratch RAM, so the entire EPROM image may not be present, so check for the whole image.

 

[Megatron-uk]

With the XT-IDE Universal BIOS installed in the AHA-1542 the following occurs:

DEBUG -g=DC00 = locks up
DEBUG -g=DC00:6 = locks up

When it locks up there's no further output and the cursor sits blinking away. I have to reboot at this point.

If I replace the Adaptec rom and run the same test again I get:

DEBUG -g=DC00 = locks up
DEBUG -g=DC00:6 = Adaptec SCSI BIOS configuration screen

I added the :6 as the Adaptec setup PDF indicates to add this on to the base address.

EDIT: Ok, scratch that. With the XT-IDE BIOS image in place it does appear that something is there....

I'm not too au fait with dos debug - how would I grab the full 32kbytes to a file?

EDIT 2: Ok, this is 32kbytes dumped from DC00.

 

[Chuck(G)]

Saying g=DC00 and g=DC00:6 are radically different things.

In the first, you're telling DEBUG to transfer to offset DC00 in the current code segment.

In the second, you're telling DEBUG to transfer to offset 6 in segment DC00.

Back to my original question. Is the whole content of the EPROM represented? If you're using an 8KB-sized image (regardless of whatever PROM you're using, here's how you retrieve the ROM image as it's in memory:

-rcx
CX 0000
:2000
-nfooie.bin
-mDC00:0 L2000 100
-w
Writing 02000 bytes
-q

That will leave you with an 8K file called FOOIE.BIN to compare with the original file image.

Remember that if an option ROM doesn't pass the checksum test during POST, it won't have its initialization entry point called (offset 3).

So let's first make sure that you have an intact image and your SCSI adapter isn't "borrowing" some address space.

 

[Megatron-uk]

Ok. The results are in (thank you for the debug instructions!):

elderthing:/tmp# diff dumped.txt ide_at.bin 
elderthing:/tmp# md5sum dumped.txt 
11a9cc95551db3e8c9fbc494d14001ae  dumped.txt
elderthing:/tmp# md5sum ide_at.bin
11a9cc95551db3e8c9fbc494d14001ae ide_at.bin

The 8kb segment appears to be identical to the original 8kb IDE_AT.BIN file.

 

[Megatron-uk]

I have another data point to add - the eprom I'm using above (one of the two [the other being a 16kb 27c128] I burned late last night before calling it a day) now appears to not cause the system to fail the POST when it is hosted in the 3C509B (which the first eprom I burned did). However, all other aspects remain the same; no XT-IDE BIOS menu. I have just performed the dos debug dump again, with the rom hosted in the NIC and the contents matches the same image hosted in the SCSI card, and the original IDE_AT.BIN file.

It appears as though the issue is not with either the NIC or SCSI card at this point (or, I guess, just as likely; it is both of them). The eprom I was using yesterday may well have been slightly out of spec for the NIC (it came from a jumbled up collection of second hand, wiped eproms).

 

[hargle]

The binary data flashed into the eeprom might not have a checksum byte.
try this one.View attachment XTIDEAT2.ZIP

 

[Megatron-uk]

The binary data flashed into the eeprom might not have a checksum byte.
try this one.View attachment 6841

Where did that rom image come from? It worked first time in my 3C509B!

 

[eeguru]

Hargle has many secrets.

 

[hargle]

I generated that image myself from the one you posted that you'd pulled off your card. One of the main reasons that an oprom won't load is that the mainboard has checked the checksum byte and it if doesn't 0-sum, it skips the rom. I checked yours and I didn't see a sum byte (typically it's the very last byte in the file).

tomi's flash program I believe writes the checksum into the image on the fly, but you said you've been using an eeprom burner, so there ya go...
I believe the flash program can be used to write the checksum and then save the file back out too, but I have my own utility to checksum a rom file.

glad it's working!!

 

[Megatron-uk]

Excellent!

Thanks for your help - that would seem like a really useful bit of info to add to the universal BIOS manual.

Having automatic configuration of modern disks makes it so much easier to swap cf drives in and out when testing/building, thanks to everyone in this thread who has offered help and advice!

 

[Dca2]

I have exactly the same experience. After spent hours & hours of experiement, I finally discovered that the file "die_at.bin" in the original download zip package has no checksum byte set at all (the checksum byte is 00h). I didn't realize this until I tried with another motherboard with MR BIOS which is able to show a warning on checksum failure of a Bios Extension on an adapter.

The solution is easy: use "idecfg.com", load the "die_at.bin" file, change any setting and change it back, save the file, flash into eprom, it worked for me.

My system:
486SX motherboard with relatively old AMI BIOS (not report checksum failure)
386dx motherboard with relatively new MR BIOS (able to report checksum failure)
NE2000 plus3 card with W27C512 EPROM in its 16kB 28-pin socket
AHA1520 card with W27C512 EPROM in its 16kB 28-pin socket
I wrote XTIDE at offset of 48kB of the 64kB EPROM chip so that I don't need to bend and ground the extra pins.

 

[Megatron-uk]

I thought I'd update on the results I've found with my XT-IDE BIOS and various drives.

So far I've tried the following combinations:

• Kingston Elite Pro 133x 4GB CF card with MSDOS 5 - Fast, boots, navigation quick. Norton sysinfo.exe hangs. MSDOS edit.com hangs when accessing menus.

• Kingston Elite Pro 133x 4GB CF card with MSDOS 6.22 - Quick, boots (slower than MSDOS5), navigation ok. Norton sysinfo.exe hangs. MSDOS edit.com hangs when accessing menus. MSDOS mem.com hangs.

• Transcend 8GB 133x CF card with MSDOS 5 - Quick, boots, navigation quick. Same issues as with MSDOS 5.

• Transcend 8GB 133x CF card with MSDOS 6.22 - Quick, boots, navigation quicker than with MSDOS6.22 on the Kingston. Same issues as with MSDOS 6.22.

• 10GB IBM Travelstar IC25N010ATDA04-0 with MSDOS 5 : Formats and installs OK. Would not boot.

• 320GB 2.5" Western Digital 3200BEVE with MSDOS 5 : Very fast. Installs ok. Boots ok. No issues loading any programmes.

I've run Norton sysinfo.exe to get some basic performance figures for the currently working combination (the 320GB WD drive):

This is with default BIOS options:

... And here is the difference turning on the BIOS options 'Fast ISA Bus' and '0 Wait State' makes:

Wow! An additional 1.2Mbytes/second from the 'Fast ISA Bus' option. I don't know what speed it runs the ISA bus at with that option set, but it lists "8Mhz - AT - Standard" as the alternative 'default' option.

A few issues with the CF cards means that I wasn't quite able to get the solution I wanted, but I'm quite happy with the performance and the ability to use a very modern notebook drive without any problems.