XTIDE Universal BIOS

[boggit]

More information required:

Explain "doesn't work". What is the error message?

If the following is not the exact sequence used to see the error, then what is? The exact sequence is required for others to be able to reproduce the symptom.

1. Run XTIDECFG.EXE
2. Arrow down to {Load BIOS from file}.
3. {ENTER} key.
4. Navigate to the desired BIN file then press the {ENTER} key.
5. {ESC} key.
6. Arrow down to {Flash EEPROM}.
7. {ENTER} key.
8. Arrow down to {Start flashing}.
9. {ENTER} key.

( Observation: The 2864 is the default value for EEPROM type, and therefore, 2864 does not need to be specifically chosen. )

Yes, that exact sequence brings about the error.

"Doesn't work" in this context means the following:

Either right away or a few percent into the flashing (sometimes as high as 60-70 %), I get the error message "Error! EEPROM did not return the same byte that was written. EEPROM was not flashed properly!"

After first getting that error message when I go for the default one (2864), I then pick another EEPROM type from the list of available ones, each one of them giving me the same error message* (except for the smallest option, which the configuration software says is too small). Eventually, I've cycled options back to 2864 and this time it works. The last time I did this (a couple of hours ago), 2864 didn't work on the second try either, but 2864mode did work and the EEPROM was adequately flashed.

* I do think that I've seen one other error message as well, but I don't remember it off hand and I don't want to try my luck right now

For simply a configuration change, the only disadvantage that I can see to {load BIOS from file} is that you may have forgotten that say, six months ago, you changed some other setting.

I'm not well versed in these matters, but perhaps I should have asked "what is best when it comes to how to *save* the BIOS configurations that you've just made."

If I save them to file, rather than flashing them to the EEPROM, they seem to be in effect the next time I boot up my computer. Does that mean that the computer loads the BIOS from the .bin file on my hard drive rather than from the EEPROM?

 

[modem7]

"Doesn't work" in this context means the following: ...

... 2864 didn't work on the second try either ...

This really does sound like a hardware issue. I think that if you were to do enough trials, you would find that the sequence that I gave in my earlier POST does, every so often, result in a successful flash.

I have experienced EEPROM's that have gone 'flakey'. Do you have spare AT28C64B's ?

For all socketed chips on your XT-CF-Lite V4.1, verify that there are no pins bent up under the chip. Sometimes when that happens, the bent pin is only just making contact with the IC socket, causing intermittent problems.

Does that mean that the computer loads the BIOS from the .bin file on my hard drive rather than from the EEPROM?

No.

I'm not well versed in these matters, but perhaps I should have asked "what is best when it comes to how to *save* the BIOS configurations that you've just made."
If I save them to file, rather than flashing them to the EEPROM, they seem to be in effect the next time I boot up my computer.

You used the word "seem". Surely they either are or they are not.

So, is it the case?:
1. At power-up, the XUB on your XT-CF-Lite V4.1 looks for both master and slave.
2. You run XTIDECFG.EXE
3. [XTIDECFG.EXE] Change the configuration so that a search for the slave does not occur.
4. [XTIDECFG.EXE] Save to file.
5. [XTIDECFG.EXE] Exit.
6. At next restart, you no longer see the XUB looking for a slave.

If the answer is affirmative, what version of the XUB are you using ?

 

[boggit]

I think that if you were to do enough trials, you would find that the sequence that I gave in my earlier POST does, every so often, result in a successful flash.

That sounds plausible, yes.

Do you have spare AT28C64B's ?

For all socketed chips on your XT-CF-Lite V4.1, verify that there are no pins bent up under the chip. Sometimes when that happens, the bent pin is only just making contact with the IC socket, causing intermittent problems.

I did not make it myself. I bought this build via Ebay. I lack the proper tools to inspect the chips properly, I'm afraid. Perhaps I should ask for a replacement card.

You used the word "seem". Surely they either are or they are not.

So, is it the case?:
1. At power-up, the XUB on your XT-CF-Lite V4.1 looks for both master and slave.
2. You run XTIDECFG.EXE
3. [XTIDECFG.EXE] Change the configuration so that a search for the slave does not occur.
4. [XTIDECFG.EXE] Save to file.
5. [XTIDECFG.EXE] Exit.
6. At next restart, you no longer see the XUB looking for a slave.

If the answer is affirmative, what version of the XUB are you using ?

No, that does not happen now.

Or rather, I previously set it so that a search for the slave would not occur, so I what I did for testing it was enabling it again.

I was convinced that that is how I disabled search for slave in the first place (by running xtidecfg, opening the .bin file, disabling search for slave and then saving back to file), but maybe I am mistaken about that. I am using r625.

 

[modem7]

I did not make it myself. I bought this build via Ebay. I lack the proper tools to inspect the chips properly, I'm afraid. Perhaps I should ask for a replacement card.

What computer do you have this card in? I have the same card, and it works great in my IBM 5150's and IBM 5160's.

 

[boggit]

What computer do you have this card in? I have the same card, and it works great in my IBM 5150's and IBM 5160's.

IBM 5160.

Hardware specials:

• Using this to upgrade to 640k (though I experienced the same error back when running with just the 256k on the motherboard).
• This VGA card (again, I experienced the same error when using the IBM CGA card that came with the computer).
• A NEC v20 (which I installed just this day, and once more, the EEPROM issue was still there before, when I used the 8080).
• An 8087 FPU (see above).

EDIT: Other than the weird issues when flashing it, the card seems to work perfectly fine for using a CF as a hard drive (I've tried two different CF cards), with only a couple of odd issues here and there (Norton System Information always hangs when testing the speed on the hard drive, sometimes EDIT.COM hangs (when that happens I can see program UI, but not the content of the file that I'm trying to edit, and a _ cursor ticking in the bottom of the screen), and I cannot get the XT-CF-Lite to show up in the memory map when running checkit 3.0 (though that might very well just be because I'm not sure how to read/comprehend memory addresses)).

 

[modem7]

EDIT: Other than the weird issues when flashing it, the card seems to work perfectly fine for using a CF as a hard drive (I've tried two different CF cards), with only a couple of odd issues here and there (Norton System Information always hangs when testing the speed on the hard drive, sometimes EDIT.COM hangs (when that happens I can see program UI, but not the content of the file that I'm trying to edit, and a _ cursor ticking in the bottom of the screen), and I cannot get the XT-CF-Lite to show up in the memory map when running checkit 3.0 (though that might very well just be because I'm not sure how to read/comprehend memory addresses)).

On these old computers, we do expect some incompatibilities/problems. That's how it was back then. I'm reminded of the impossibilities/problems just by looking at some of the entries in AST's list at [here].

... and I cannot get the XT-CF-Lite to show up in the memory map when running checkit 3.0

I see the same. And InfoSpotter software as well.
Not with just my XT-CF-Lite V4.1, but with my 'Glitch Works XT-IDE Rev 4' as well.
My RAYXTIDE tool will detect the XUB and display some details (and look for some problems).

Six months to a year ago, I added an entry about that to [here]. I have yet to further investigate.

Do you have spare AT28C64B's ?

I recommend that you get some spares of those, just in case.

 

[Krille]

[*]A NEC v20 (which I installed just this day, and once more, the EEPROM issue was still there before, when I used the 8080).

You might want to reflash the ROM with ide_xtp.bin to maximize the performance with that NEC V20 CPU. Note that you can't use the 8088 CPU after doing that without downgrading the BIOS back to ide_xt.bin first.

EDIT: Other than the weird issues when flashing it, the card seems to work perfectly fine for using a CF as a hard drive (I've tried two different CF cards), with only a couple of odd issues here and there (Norton System Information always hangs when testing the speed on the hard drive,

That's a known problem with Norton SI.

sometimes EDIT.COM hangs (when that happens I can see program UI, but not the content of the file that I'm trying to edit, and a _ cursor ticking in the bottom of the screen

Reconfigure XUB to use 'Full operating mode'.

 

[boggit]

On these old computers, we do expect some incompatibilities/problems. That's how it was back then. I'm reminded of the impossibilities/problems just by looking at some of the entries in AST's list at [here].

Fair enough! I'm not too worried or bothered by those minor issues that I described.

As long as the inability-to-flash-the-EEPROM-at-first-try thing isn't an indication of a bigger problem that I should be worried about, I'm perfectly happy with the current state of affairs and just retry/reboot when an error occurs.

EDIT: Just to be clear, 2864 is the correct EEPROM type for AT28C64B, right? And the other options in that sub-menu should be set to the default values?

I see the same. And InfoSpotter software as well.
Not with just my XT-CF-Lite V4.1, but with my 'Glitch Works XT-IDE Rev 4' as well.
My RAYXTIDE tool will detect the XUB and display some details (and look for some problems).

Six months to a year ago, I added an entry about that to [here]. I have yet to further investigate.

Good to know! I skimmed through that list earlier, but must have missed that particular entry.

I really must say that your website has been invaluable to me as I've put my XT system together, both hardware and software-wise.

I recommend that you get some spares of those, just in case.

I will do that. Thank you for the advice!

You might want to reflash the ROM with ide_xtp.bin to maximize the performance with that NEC V20 CPU. Note that you can't use the 8088 CPU after doing that without downgrading the BIOS back to ide_xt.bin first.

Duly noted. Stort tack!

That's a known problem with Norton SI.

Ah. Good to know!

Reconfigure XUB to use 'Full operating mode'.

I will do that. Thank you!

Just out of curiousity, would you mind elaborating on the implications of that configuration, and how it relates to the issues I described?

 

[boggit]

EDIT: Just to be clear, 2864 is the correct EEPROM type for AT28C64B, right? And the other options in that sub-menu should be set to the default values?

And the Device type for my XT-CF-Lite 4.1+AT28C64B is XTCF PI0, correct?

"Doesn't work" in this context means the following:

Either right away or a few percent into the flashing (sometimes as high as 60-70 %), I get the error message "Error! EEPROM did not return the same byte that was written. EEPROM was not flashed properly!"

EDIT: I just now encountered the other error message (besides "did not return the same byte that was written") that I sometimes get when flashing the EEPROM: "Timeout when polling EEPROM. EEPROM was not flashed properly!"

EDIT 2: The routine that I have found that seems to be the quickest way to successfully flash my EEPROM is to first try to flash it with 28256 set as the EEPROM type, whereupon the flashing process starts, reaches a few percent and then returns the "timeout" error message. After that, I can set the type back to 2864 and flash the EEPROM error-free.

 

[boggit]

Reconfigure XUB to use 'Full operating mode'.

Same problem occurs occasionaly (perhaps 20-25 % of the time) when running EDIT.COM, even though I have reconfigured XUB to "Full operating mode".

Not the end of the world by any means, as I can easily reboot when this happens and try again, as long as this isn't an indication of some sort of bigger malfunction or error with my XT-CF-Lite 4.1 card (or, for that matter, due to some erroneous configuration on my part).

 

[modem7]

EDIT: Just to be clear, 2864 is the correct EEPROM type for AT28C64B, right? And the other options in that sub-menu should be set to the default values?

I have the same card as you, one with an AT28C64B, with the EEPROM's set to start at D0000h. I have taken my card through about five upgrades, and I have never had to change anything on that page.

 

[modem7]

And the Device type for my XT-CF-Lite 4.1+AT28C64B is XTCF PI0, correct?

I an packing for a flight, and so I can't spend to much time here presently.
See what I have recorded at [here]. Having a quick look at R625, is must be 'XT-CF PIO8 (BIU offload)' ('BIU 8' being the shortened form of that)'
Note that on the previous page is an 'Auto Configure' option.

 

[modem7]

Re EPROM programming issues.
Could there be another card in your computer that has something start at address D0000h ?

 

[boggit]

Re EPROM programming issues.
Could there be another card in your computer that has something start at address D0000h ?

I don't think so, but again, I'm not 100 % confident in my ability to read memory addresses. This is all rather new territory for me.

From my CheckIt log:

A | 69E5h to A000h 216K Available

V | A000h to C000h 128K VGA Video RAM
| A000h to B000h 64.0K VGA Graphics
| B000h to B800h 32.0K MDA Text
| B800h to C000h 32.0K CGA Text/Graphics

R | C000h to C600h 24K Video ROM
| Copyright (C) 1984-1990 Phoenix Technologies Ltd.

- | C600h to F000h 168K <nothing>

R | F000h to 0000h 64K System ROM
| ROM BIOS: IBM
| BIOS Date: 11/08/82

 

[modem7]

See what I have recorded at [here]. Having a quick look at R625, is must be 'XT-CF PIO8 (BIU offload)' ('BIU 8' being the shortened form of that)'
Note that on the previous page is an 'Auto Configure' option.

EEPROM programming instability

In case you are unaware, the controller setting does not impact on the ability to program the EEPROM.
According to the circuit diagram, your card is like the top half of the diagram at [here], two circuits on one card.
The EEPROM related circuitry is only four components on your card: SW2, RR2, U1 (the EEPROM itself), and U2.
Only those four components are needed to program and use the EEPROM.

1. Try re-seating chips U1 (the EEPROM itself), and U2. The video at [here] should assist you. I use a small blade screwdriver (with a thin end).

2. Re the CheckIt log. One has to take those with a 'grain of salt'. But the C8000 area appears to be free. Try setting SW2 to the C8000 (a.k.a. C800) setting. In the EEPROM programming page, you would need to change the 'EEPROM address' setting. If that action doesn't change anything, then I suggest you move back to D0000.

 

[boggit]

EEPROM programming instability

In case you are unaware, the controller setting does not impact on the ability to program the EEPROM.
According to the circuit diagram, your card is like the top half of the diagram at [here], two circuits on one card.
The EEPROM related circuitry is only four components on your card: SW2, RR2, U1 (the EEPROM itself), and U2.
Only those four components are needed to program and use the EEPROM.

1. Try re-seating chips U1 (the EEPROM itself), and U2. The video at [here] should assist you. I use a small blade screwdriver (with a thin end).

2. Re the CheckIt log. One has to take those with a 'grain of salt'. But the C8000 area appears to be free. Try setting SW2 to the C8000 (a.k.a. C800) setting. In the EEPROM programming page, you would need to change the 'EEPROM address' setting. If that action doesn't change anything, then I suggest you move back to D0000.

Thank you for your advice! I will do those things and report back here when I've done so.

 

[Krille]

Just out of curiousity, would you mind elaborating on the implications of that configuration, and how it relates to the issues I described?

Regarding Full operating mode/Lite mode; it's just a configuration option to decide where the XUB should locate its working space (Drive Parameter Tables and other variables, sometimes even its stack, needs to be stored somewhere).

I remembered reading somewhere that someone was having problems with EDIT, just like you, and it was apparently because of XUB. EDIT, at least in some versions, is just QBASIC with another UI, so I figured it could be within the realm of possibilities that it is using the memory area at segment 30h like a few other BASIC implementations. This is the segment used by XUB when configured for Lite mode, by the way. Configuring XUB to use Full operating mode will instead make it use the top of conventional memory or an UMB (depending on configuration). Since your problems with EDIT didn't go away despite configuring it to use Full operating mode, it's safe to say that my hunch was incorrect.

The problem with Norton SI has been reported on this forum a few times. This post is the result of my latest attempt at finding the cause.

 

[boggit]

Regarding Full operating mode/Lite mode; it's just a configuration option to decide where the XUB should locate its working space (Drive Parameter Tables and other variables, sometimes even its stack, needs to be stored somewhere).

Ah. Got it.

I remembered reading somewhere that someone was having problems with EDIT, just like you, and it was apparently because of XUB. EDIT, at least in some versions, is just QBASIC with another UI, so I figured it could be within the realm of possibilities that it is using the memory area at segment 30h like a few other BASIC implementations. This is the segment used by XUB when configured for Lite mode, by the way. Configuring XUB to use Full operating mode will instead make it use the top of conventional memory or an UMB (depending on configuration). Since your problems with EDIT didn't go away despite configuring it to use Full operating mode, it's safe to say that my hunch was incorrect.

I see. Seems like a wise choice for me to go with full operating mode, then, regardless of whether or not this makes any difference regarding my occasional issues with EDIT.COM (problems that, again, aren't the end of the world for me).

Thanks again for taking the time to answer mty questions.

 

[boggit]

1. Try re-seating chips U1 (the EEPROM itself), and U2. The video at [here] should assist you. I use a small blade screwdriver (with a thin end).

2. Re the CheckIt log. One has to take those with a 'grain of salt'. But the C8000 area appears to be free. Try setting SW2 to the C8000 (a.k.a. C800) setting. In the EEPROM programming page, you would need to change the 'EEPROM address' setting. If that action doesn't change anything, then I suggest you move back to D0000.

I reseated the ICs and changed the address. The C800 address change did work and made me able to flash the EEPROM on the first try. Good call! D0000 still has the same issues, No difference when it comes to occasional EDIT.COM hanging though.

 

[boggit]

2. Re the CheckIt log. One has to take those with a 'grain of salt'. But the C8000 area appears to be free. Try setting SW2 to the C8000 (a.k.a. C800) setting.

Another question: Where does the XT-CF-Lite EEPROM address end, so to speak? Ie. from which address can I assign other things (assuming I go with C800h as its starting point)?

I'm asking because I acquired a new floppy disk controller with the following possible jumper settings for its firmware: