GSETUP regarding expanded memory for IBM 5170

[alejack12001]

Per [here], there are some VGA cards that have a BIOS ROM that extends up to address CA7F0, but, everything else being functional, that is not going to be a problem with your XT-CF-lite's ROM set to start at D8000.

Do you have another computer that you can try the XT-CF-lite card in?

I'll have to check with Checkit to determine the video and video ROM addresses used.

 

[modem7]

I'll have to check with Checkit to determine ...

Down the track, treat with some suspicion what you see CheckIt reporting, and that goes for other hardware reporting software tools as well.

For example, CheckIt (and other software) may inform you that the BIOS expansion ROM on your SCSI card is 4 KB sized, occupying D0000 to D1000. But you know from the card's manual that the ROM is 8 KB sized and that all 8 KB is mapped into the computer's memory space. In that situation, CheckIt (and other software) is assuming that the size byte in the BIOS expansion ROM represents the entire ROM, and in the case of your SCSI card, the size byte is set to a value that is less than the amount of space that is mapped into the computer's memory space.

I started a 'CheckIt - Wrong/Misleading Information' web page at [here].

 

[alejack12001]

I agree with your conclusions that Checkit 3.0 has some errors in the memory maps. The picture below is from my IBM 5170. Please feel free to use this in a IBM 5170 example. The video space is suppose to be 256-KB RAM but what is shown is 128-KB with 24-KB ROM. So according to Checkit the available space for the XT-CF is from C600h to F000h. This can't be right as the setting for C800h rejected by the system when the ROM is engaged and the port set at 300. Another thing is that the machine only has 512-KB memory so what is shown is based on a template that is not reflective of the actual memory space of the 5170 that I have.

I have tried all the available addressing spaces and ports provided by the ROM on the elecTECH XT-CF card. If I don't use the ROM on the card then I'd need driver and software to access the card. elecTECH doesn't offer software for their products. I have one of Sergey's cards for CF. It doesn't work any better than the elecTECH XT-CF cards. Same problem as the XT-CF card some sort of address error. It's probably the video card.

I have the CGA card with the composite video port on the card. I have an adapter that changes composite video to HDMI. I know the adapter works for CD/DVD players. I doubt if the adapter would work for the CGA card's composite signal. I am still seeking a composite TV/monitor. Most what is available is too large or too heavy to manage. I'll have to keep you informed when I can discover if the elecTECH XT-CF card works with the composite CGA card as opposed to my VGA card.

 

[modem7]

The picture below is from my IBM 5170.

I see CheckIt showing 512 KB of conventional memory (0000h through 8000h).

Even though your VGA card has 256 KB of RAM, surely not all of that would be mapped into the computer's memory space at any one time.

At a guess, the VGA card's BIOS expansion ROM ("Video ROM") is a 32 KB sized chip, such as a 27C256, with all 32 KB mapped into the computer's memory space, but because the size byte indicates 24 KB, that is what CheckIt goes on. But maybe the card only maps in 24 KB.

And ideally, CheckIt would, in some way, indicate that the E000 to F000 space is reserved for optional motherboard ROM. Any card set to use that space, will conflict with the 5170 motherboard.

I'll have to keep you informed when I can discover if the elecTECH XT-CF card works with the composite CGA card as opposed to my VGA card.

Yes, an interesting experiment.

And don't forget about RAYXTIDE.

 

[alejack12001]

Sorry for the delay in writing again. Illness and appointments for doctor were the reason. The use of the composite port on the CGA card that I have does work with the converter to HDMI adapter that was used to display the text from the IBM 5170. The picture though was jittery almost unstable. Signal must be pretty low. I was able to stabilize the picture long enough to see commands but not enough stability to run RAYXTIDE. My choices for detecting the RAM available were limited to InfoPlus and Checkit. The only RAM that was used for the video was 16-KB according to Checkit and InfoPlus.

I re-installed the VGA card and I was able to get the RAYXTIDE to run. Below is the result of the execution; see IMG_5386 and IMG_5387.jpeg. The second screen is the most concerning. The RAYXTIDE was executed with a minimum of cards on the machine meaning the WS1003-WA2 MFM/Floppy controller and VGA card. I don’t have the IBM HD/Floppy controller that works with this Type 3 motherboard. They are hard to get and fairly expensive. Unfortunately there is a conflict between the Western Digital WS1003-WA2 MFM/Floppy controller and the XT-CF card. Maybe the second screen makes sense to the forum. Do I need arguments or options for the RAYXTIDE?

I was able to get the CF card and IDE CF adapter to work in my IBM PC-XT/286. The key was to use the diagnostics of the motherboard to low level format the card. I did find a restriction in the configuration limiting the card to ~500 MB or exactly 472-MB formatted. This didn’t change whether the drive was 1, 2, or 4-GB the limit was set probably in the AMI ROM. I used MSDOS 6.22 using FDISK and format /s to get the machine to boot. I ran the RAYXTIDE on this machine using the same limited cards and got a similar response as was seen on the 5170 IMG_5387.jpeg; see IMG_5383 and IMG_5384.jpeg. The second screen seemed to match the 5170 unless I need arguments or options here too.

 

[modem7]

I re-installed the VGA card and I was able to get the RAYXTIDE to run. Below is the result of the execution; see IMG_5386 and IMG_5387.jpeg. The second screen is the most concerning. The RAYXTIDE was executed with a minimum of cards on the machine meaning the WS1003-WA2 MFM/Floppy controller and VGA card. I don’t have the IBM HD/Floppy controller that works with this Type 3 motherboard. They are hard to get and fairly expensive. Unfortunately there is a conflict between the Western Digital WS1003-WA2 MFM/Floppy controller and the XT-CF card. Maybe the second screen makes sense to the forum. Do I need arguments or options for the RAYXTIDE?

IBM 5170

No arguments/options.

RAYXTIDE is simply informing you that it cannot find the XTIDE Universal BIOS (XUB) in motherboard address space. Lots of possible causes.

If the 'Lo-tech XT-CF-lite rev.2' and the WD1003-WA2 are fully functional, then I cannot see how there could be a conflict there. The EEPROM circuitry on the Lo-tech XT-CF-lite rev.2 uses 'standard' addresses, and the WD1003-WA2 uses a range of I/O ports and a couple of hardware interrupts.

Disproving an address conflict between the 'Lo-tech XT-CF-lite rev.2' and the WD1003-WA2 is easy. Remove the WD1003-WA2. You will see the POST display some errors (601 being one), then press the F1 key to continue, then expecting the XUB to display its spash/banner text. I just now confirmed that observation on one of my IBM 5170's (IBM EGA and XT-IDE cards being the only cards present).

I was able to get the CF card and IDE CF adapter to work in my IBM PC-XT/286. The key was to use the diagnostics of the motherboard to low level format the card. ...

IBM 5162

What you wrote in the paragraph is not making sense to me yet.

Are you saying that even though RAYXTIDE cannot find the XUB (i.e. photo IMG_5384), that you are seeing the XUB display its spash/banner text, and then a boot from the CF attached to the Lo-tech XT-CF-lite rev.2 happens ?

CF on 'Lo-tech XT-CF-lite rev.2': Controlled by the XUB.
MFM drive on AT-class MFM controller: Controlled by the motherboard BIOS.
Diagram at [here].

 

[alejack12001]

On the IBM 5162, I am not using the LoTek XT-CF adapter. I am using a CF card adapter similar to the one in the picture, see CF Adapter.jpg. The adapter that was employed had male IDE connector instead of female shown, the LED's were chips on the board and there wasn't any jumpers. The AMI ROM on the motherboard houses diagnostic tools along with the CMOS setup. The diagnostic included tools to read, write and format a drive whether it was standard hard drive or CF card besides other hardware tests. One tool was this low level format capability afore mentioned. Unfortunately, there is a limit in the tool just to recognize 500-MB storage space and nothing beyond that to accommodate say a 1, 2, or 4-GB drive.

I triggered the RAYXTIDE prior to executing the application on the IBM 5170. I didn't quite know at the time of testing, what the item reference, XUB was prior to the error shown until you explained it in your post. I know that the LoTek XT-CF adapter has a ROM built on the adapter, which when triggered definds the available drives at the top of the screen and the drive booting.

On the IBM 5170, the best thing to do is to trace down the addressing conflict, since I have your recommended link. Thank you for that.

 

[alejack12001]

On the IBM 5162, I am not using the LoTek XT-CF adapter. I am using a CF card adapter similar to the one in the picture, see CF Adapter.jpg. The adapter that was employed had male IDE connector instead of female shown, the LED's were chips on the board and there wasn't any jumpers. The AMI ROM on the motherboard houses diagnostic tools along with the CMOS setup. The diagnostic included tools to read, write and format a drive whether it was standard hard drive or CF card besides other hardware tests. One tool was this low level format capability afore mentioned. Unfortunately, there is a limit in the tool just to recognize 500-MB storage space and nothing beyond that to accommodate say a 1, 2, or 4-GB drive.

I triggered the RAYXTIDE prior to executing the application on the IBM 5170. I didn't quite know at the time of testing, what the item reference, XUB was prior to the error shown until you explained it in your post. I know that the LoTek XT-CF adapter has a ROM built on the adapter, which when triggered definds the available drives at the top of the screen and the drive booting.

On the IBM 5170, the best thing to do is to trace down the addressing conflict, since I have your recommended link. Thank you for that.

Because the LoTek XT-CF adapter limits the addresses 300h and alternate 320h; the other two addresses C800h and D800h are not causing the difficulty with the card being seen by the IBM 5170. In fact the post of the Checkit earlier, shows the ROM address for the video card stopping a C600h. The two addresses 300h and 320h must have been used by the system either as protected memory or some offset redirected, I don't know. There doesn't appear to be away to determine this.

If I disable, the LoTek XT-CF adapter ROM, then I was going use GSETUP to see the XT-CF card. GSETUP version 3.0 doesn't seem to have a way to insert a Cylinders, Heads, and Sectors by means of the diagnostic that I used on my IBM 5162. In fact, the GSETUP version 3.0 diagnostic doesn't even work when I select it. I think the message was not installed. I think I have hit a dead end.

 

[modem7]

Because the LoTek XT-CF adapter limits the addresses 300h and alternate 320h; the other two addresses C800h and D800h are not causing the difficulty with the card being seen by the IBM 5170.

Some of the following you will know, but it is important that we are 'on the same page':

In your computer, there are what could be called 'standard' addresses, and there is another form of addressing called I/O ports. I/O ports are sometimes called I/O addresses. Both utilise the address bus.

* C800h and D800h are 'standard' addresses. The XT-IDE and XT-CF cards use 'standard' addresses for the ROM (EEPROM) circuitry.
* 300h and 320h are I/O ports. The XT-IDE and XT-CF cards use I/O ports for the circuitry that interfaces with the IDE device (hard drive or CF).

With respect to that, a diagram showing the XT-IDE/XT-CF is at [here]. They are different functionalities. In fact, the designers of the original XT-IDE card could have produced two cards, a ROM card, and a drive card. Instead, they did the logical thing, which was to put both functionalities onto one card.

The XT-IDE/XT-CF is somewhat unique, and that is why it needs the XTIDE Universal BIOS (XUB) to 'control' it. When the IBM 5170 starts, the POST will find and execute the initialisation code in the XUB. That initialisation code will do some things, including putting into place, INT13H support for the XT-IDE/XT-CF. DOS will use the INT13H support to interact with the IDE device.

The XUB does not use the hard drive number in the 5170's CMOS SETUP.

If, for whatever reason, the XUB is not executed at POST time, there is no INT13H support put in place for the XT-IDE/XT-CF.

You need to work out why the XUB is not getting executed during POST time. We know that it happens in an IBM 5170. So, is the ROM/EPROM functionality on your card faulty, or is there a motherboard fault, or is there an address conflict! Since the XUB is in the ROM/EEPROM, if an address conflict, it has to do with the 'standard' addresses.

In fact the post of the Checkit earlier, shows the ROM address for the video card stopping a C600h.

As I mentioned earlier, you need to take CheckIt 'with a grain of salt'.

If I disable, the LoTek XT-CF adapter ROM, then I was going use GSETUP to see the XT-CF card. GSETUP version 3.0 doesn't seem to have a way to insert a Cylinders, Heads, and Sectors by means of the diagnostic that I used on my IBM 5162. In fact, the GSETUP version 3.0 diagnostic doesn't even work when I select it. I think the message was not installed. I think I have hit a dead end.

When you use GSETUP (or whatever) to set the hard drive type in CMOS SETUP to a non-zero setting, you are informing the motherboard BIOS that a 'standard' AT-class MFM controller, or 'standard' AT-class IDE controller, is fitted, and that the motherboard BIOS is to provide INT13H support for it and its attached hard drive.

Certain hard drive controllers are not in that category. E.g. SCSI card. E.g. XT-IDE/XT-CF card.

You need to work out why the XUB is not getting executed during POST time.

 

[alejack12001]

Some of the following you will know, but it is important that we are 'on the same page':

In your computer, there are what could be called 'standard' addresses, and there is another form of addressing called I/O ports. I/O ports are sometimes called I/O addresses. Both utilise the address bus.

* C800h and D800h are 'standard' addresses. The XT-IDE and XT-CF cards use 'standard' addresses for the ROM (EEPROM) circuitry.
* 300h and 320h are I/O ports. The XT-IDE and XT-CF cards use I/O ports for the circuitry that interfaces with the IDE device (hard drive or CF).

With respect to that, a diagram showing the XT-IDE/XT-CF is at [here]. They are different functionalities. In fact, the designers of the original XT-IDE card could have produced two cards, a ROM card, and a drive card. Instead, they did the logical thing, which was to put both functionalities onto one card.

The XT-IDE/XT-CF is somewhat unique, and that is why it needs the XTIDE Universal BIOS (XUB) to 'control' it. When the IBM 5170 starts, the POST will find and execute the initialisation code in the XUB. That initialisation code will do some things, including putting into place, INT13H support for the XT-IDE/XT-CF. DOS will use the INT13H support to interact with the IDE device.

The XUB does not use the hard drive number in the 5170's CMOS SETUP.

If, for whatever reason, the XUB is not executed at POST time, there is no INT13H support put in place for the XT-IDE/XT-CF.

You need to work out why the XUB is not getting executed during POST time. We know that it happens in an IBM 5170. So, is the ROM/EPROM functionality on your card faulty, or is there a motherboard fault, or is there an address conflict! Since the XUB is in the ROM/EEPROM, if an address conflict, it has to do with the 'standard' addresses.


As I mentioned earlier, you need to take CheckIt 'with a grain of salt'.


When you use GSETUP (or whatever) to set the hard drive type in CMOS SETUP to a non-zero setting, you are informing the motherboard BIOS that a 'standard' AT-class MFM controller, or 'standard' AT-class IDE controller, is fitted, and that the motherboard BIOS is to provide INT13H support for it and its attached hard drive.

Certain hard drive controllers are not in that category. E.g. SCSI card. E.g. XT-IDE/XT-CF card.

You need to work out why the XUB is not getting executed during POST time.

How can the XTIDE Universal BIOS (XUB) be tested or determined as to why it's not triggering?

 

[modem7]

I have re-read the thread.

You have both a {Lo-tech XT-CF-lite rev.2} and a {Sergey's XT-CF-Lite V4.1}. The {Sergey's XT-CF-Lite V4.1} is in your IBM 5150. Neither card 'work' in your 5170 (as the 5170 was configured/fitted at the time).

Clearly, your {Sergey's XT-CF-Lite V4.1} is working in the 5150, at start-up time, the XUB displaying its splash/banner text. I did not read that you tried the {Lo-tech XT-CF-lite rev.2} in the 5150 (5150, not 5170).

So for now, I consider the {Lo-tech XT-CF-lite rev.2} to be of unknown/unproven working status.

From this point on, we need to work with a proven XT-CF card. That is {Sergey's XT-CF-Lite V4.1}.


IBM 5150

STEP 1: If the {Sergey's XT-CF-Lite V4.1}'s switches are not set for a ROM starting address of D0000 (the default for that card), then change them to the D0000 (D000) setting.

STEP 2: Start the 5150, verify that the XUB displays its splash/banner text, AND, that the text indicates that the ROM starts at address D0000 (D000). In the partial screen shot at [here], the D0000 start is indicated by the "@ D000h".


IBM 5170

STEP 3: Remove all cards from the 5170, except for the VGA video card.

STEP 4: Fit the {Sergey's XT-CF-Lite V4.1} card. The D0000 ROM setting will not conflict with a functional 5170 motherboard, and is not expected to conflict with a VGA card.

STEP 5: Start the 5170. Ignore the errors (601, etc.) then press F1 to continue.

Does the XUB splash/banner text appear ? <------------------

If not, we are left with the possibilities of:
- Partially faulty 5170 motherboard.
- Conflict with the VGA video card.

It would be great to quickly rule out the VGA video card. My reading of post #23 is that you have a CGA card, but not a CGA compatible monitor. To use the composite video connector on the CGA card, you are, "I am still seeking a composite TV/monitor." An MCE2HDMI is a possible alternative, converting IBM CGA to HDMI.

But maybe you are about to post that, in the 5170, the XUB on {Sergey's XT-CF-Lite V4.1} is displaying its splash/banner text.

 

[alejack12001]

I have re-read the thread.

You have both a {Lo-tech XT-CF-lite rev.2} and a {Sergey's XT-CF-Lite V4.1}. The {Sergey's XT-CF-Lite V4.1} is in your IBM 5150. Neither card 'work' in your 5170 (as the 5170 was configured/fitted at the time).

Clearly, your {Sergey's XT-CF-Lite V4.1} is working in the 5150, at start-up time, the XUB displaying its splash/banner text. I did not read that you tried the {Lo-tech XT-CF-lite rev.2} in the 5150 (5150, not 5170).

So for now, I consider the {Lo-tech XT-CF-lite rev.2} to be of unknown/unproven working status.

From this point on, we need to work with a proven XT-CF card. That is {Sergey's XT-CF-Lite V4.1}.


IBM 5150

STEP 1: If the {Sergey's XT-CF-Lite V4.1}'s switches are not set for a ROM starting address of D0000 (the default for that card), then change them to the D0000 (D000) setting.

STEP 2: Start the 5150, verify that the XUB displays its splash/banner text, AND, that the text indicates that the ROM starts at address D0000 (D000). In the partial screen shot at [here], the D0000 start is indicated by the "@ D000h".


IBM 5170

STEP 3: Remove all cards from the 5170, except for the VGA video card.

STEP 4: Fit the {Sergey's XT-CF-Lite V4.1} card. The D0000 ROM setting will not conflict with a functional 5170 motherboard, and is not expected to conflict with a VGA card.

STEP 5: Start the 5170. Ignore the errors (601, etc.) then press F1 to continue.

Does the XUB splash/banner text appear ? <------------------

If not, we are left with the possibilities of:
- Partially faulty 5170 motherboard.
- Conflict with the VGA video card.

It would be great to quickly rule out the VGA video card. My reading of post #23 is that you have a CGA card, but not a CGA compatible monitor. To use the composite video connector on the CGA card, you are, "I am still seeking a composite TV/monitor." An MCE2HDMI is a possible alternative, converting IBM CGA to HDMI.

But maybe you are about to post that, in the 5170, the XUB on {Sergey's XT-CF-Lite V4.1} is displaying its splash/banner text.

I have Sergey's card but it doesn't work. I tried it on a number of different boards and machines with no response. I wrote the seller who never responded by repair or replacement.

No, all my XT platforms AT&T 6300, 6300 plus, and IBM PC. used the Lo-tech XT-CF-lite rev.2 card. In the 6300's, the address D800 was used with I/O address 300. The IBM PC, because it doesn't have the 5160's hard drive, is using the Lo Tek as C drive with it's address C800 and 300 for I/O. Both the IBM 5162 and the 5170 reject the Lo-tech XT-CF-lite rev.2 with the ROM enabled.

I watched a YouTube video series (URL:

) yesterday on the XUB where the author downloaded a binary for an XUB from the following website: https://xtideuniversalbios.org/ . That author of the video installed the XUB binary onto a 128-KB ROM where he then either used a jumper adjusted Ethernet card or Sound Card with an open ROM socket. He placed the XUB binary ROM into the socket and was able to trigger the Lo Tek card. It's apparent that the XUB for the 5162 and 5170 is not incorporated into the ROM programming. I could update the ROM's from these machines to accomidate the CF card implementation. Right now, I have work arounds for both using Brutman's NetDrive, which acts as a source E drive for teh 5162 and D drive for the 5170. Programs seem to load and execute from the NetDrrive as if the drive was internal to the machine. My hat's off to Mr. Brutman for his developed drive.

 

[modem7]

) yesterday on the XUB where the author downloaded a binary for an XUB from the following website: https://xtideuniversalbios.org/ . That author of the video installed the XUB binary onto a 128-KB ROM where he then either used a jumper adjusted Ethernet card or Sound Card with an open ROM socket. He placed the XUB binary ROM into the socket and was able to trigger the Lo Tek card.

Whether the XUB is in the XT-IDE/XT-CF's ROM, or in the ROM of a network card, or in the ROM on a dedicated ROM card, or other, it doesn't matter. The end result is the same. The XUB appears in an appropriate area of the computer's memory space (ROM addresses not conflicting with anything else), and at power-on time, the computer's POST finds the ROM (in the appropriate area), then the POST executes the initialisation code in the ROM.

The RAYXTIDE tool, as a diagnostic aid, is designed specifically to search for the XUB in memory space.

It's apparent that the XUB for the 5162 and 5170 is not incorporated into the ROM programming.

There is no setting/programming that has to be made in the XUB to make it suitable for the IBM 5162 or 5170.

I use the XT version of the XUB on all of my various XT-IDE/XT-CF cards. I can move those cards between my 5150's, my 5160's, and 5170's, without problem.

The only known incompatibility with the 5170, is if the 5170 has the first revision of motherboard BIOS, and even then, the nature of the incompatibility does not stop the XUB displaying its banner/splash text.
There is no known incompatibility with the 5162.

I have Sergey's card but it doesn't work. I tried it on a number of different boards and machines with no response. I wrote the seller who never responded by repair or replacement.

So the problem with the {Sergey's XT-CF-Lite V4.1} is a separate problem, and is best dealt with in a separate thread.

No, all my XT platforms AT&T 6300, 6300 plus, and IBM PC. used the Lo-tech XT-CF-lite rev.2 card. In the 6300's, the address D800 was used with I/O address 300. The IBM PC, because it doesn't have the 5160's hard drive, is using the Lo Tek as C drive with it's address C800 and 300 for I/O.

Q1. If you perform the steps in post #31, but using the {Lo-tech XT-CF-lite rev.2} instead, what is the result ? Either D0000 or D8000 is expected to work in that scenario.

Q2. Regarding the particular (and still-under-suspicion) VGA card that you are fitting to the 5162 and 5170. Is that the card that you use in the 5150, i.e. in the 5150, the VGA card works okay with the {Lo-tech XT-CF-lite rev.2} set to D8000/300 ?

 

[alejack12001]

I think the optimum solution is to replace the BIOS ROM’s with something modern to address the CF issue and other problems encountered on this machine. Adrian from Arian’s Digital Basement videos on the 5170 used Quadtel BIOS on his 5170. There is a webpage on this BIOS on Minuszerodegrees.org website that I plan to use to see if the problems encountered are cleared up.

 

[alejack12001]

Well, I created U27 and U47 ROM's with the Quadtel BIOS installed. The XT-CF card that I have been using wasn't recognized again. At this point, I don't know if the XUB software is embedded in the Quadtel version 3.0.5 BIOS. I use the RAYIDEXT tool and got the same response that I posted earlier that the XUB is not found. If assuming that the XUB is not part of the Quadtel BIOS, is there a way to add the XUB into U17 and U37 as a BIOS helper or would there be a conflict if these ROM sockets were used?

 

[modem7]

Well, I created U27 and U47 ROM's with the Quadtel BIOS installed. The XT-CF card that I have been using wasn't recognized again. At this point, I don't know if the XUB software is embedded in the Quadtel version 3.0.5 BIOS.

No, unless someone hacked the 1990 dated Quadtel BIOS that you sourced. The one at [here] is not hacked.

If assuming that the XUB is not part of the Quadtel BIOS, is there a way to add the XUB into U17 and U37 ...

Yes, sockets U17 and U37 can be used to host the XUB.

Because this subject will come up again, I am in the process of creating a draft procedure on my website for XUB-in-U17-U37. That draft (but functionally good enough now) procedure is at [here].

... or would there be a conflict if these ROM sockets were used?

Conflict with those sockets only happens if either:
- You put the XUB into those sockets, and, you then add a card that uses some/all of the same address space (E0000 to EFFFF), or
- Nothing is in the U17+U37 sockets, and, you add a card that uses some/all of the same memory space (E0000 to EFFFF).

Re the latter. An example of that is an XT-IDE/XT-CF card set to start its EEPROM at address E0000. The U17+U37 sockets, empty or not, 'own' the address space of E0000 to EFFFF.

 

[alejack12001]

Thank you for the links and information. Regarding The Quadtel, I made a mistake on the version number mine read version 3.05.01, which matches the link you sent. I don’t believe it was hacked.

I think the procedure for the U17/U37 is complicated since I am afraid of bricking the machine with a mistake. As example was the version that I got incorrect regarding the Quadtel BIOS. Your right, the website is not complete and there were many questions that I would have to implement in the procedure shown on the website for the U17/U37 that I most likely would get wrong. For example:

• The process wants 8 –> 8-KB (i.e., 64-KB) of the XUB merged into a binary along with a binary of all zeros to either achieve a zero checksum or add the bytes to achieve the zero checksum. So how does one merge binaries? I don’t have an assembler/disassembler tool to re-engineer these binaries. In addition, I don’t have the knowledge to do this type of action item.
• The process speaks of splitting the combined binary into 32-KB for an odd or even ROM BIOS. How to split a combined binary and yet maintain the zero checksum?
• I have some 64-KB PROMS on order. In the sequence of starting, which BIOS ROM’s start first the U27, U47 or the U17, U37. Is there a possibility of the machine hanging for adding those U17 and U37 BIOS?

Right now, I have implemented a parallel port zip drive that gives alternative storage that could be quickly accessed if I trash files or a drive. Like the netdrive, the Zip Drive doesn’t boot, however, a modified boot floppy can be used to access the system and the Zip drive to rebuild any files that were trashed. The current files have been backup’ed to the Zip drive. The current boot drive is the 33-MB Micropollis hard drive with a western digital MFM controller for hard drive and floppy.

The plan now is to switch gears and get one of three extended memory cards to work with this machine to satisfy the “not enough” memory error. With Cheetah and AST cards, I’ve tried to configure 128-KB to be added to the Base memory to acquire 640-KB.

You mentioned the E0000 addressing space being used. In my XT machines that have an Extended memory card such as the Boca, the addressing space E0000 was used. I have three different Extended memory cards. An IBM extended card which is 512-KB in size, a Cheetah Combo card that has 1.5-MB of memory along with serial and parallel ports (the ports are disabled) and an AST 286 Rampage Plus card with 2-MB of RAM.

Each time using either the IBM BIOS or Quadtel BIOS to configure the CMOS to accommodate the added 128-KB additional memory; the BIOS would display a 201 and 164 memory error until the card was removed and reconfigured to reset to 512-KB for Base and 0 for any Extended memory settings. In addition, I tried to change the J18 jumper to pins 2 and 3 on the IBM motherboard to allow added memory cards to be recognized. Same results occurred with a twist in that the Base memory dropped to 256-KB, which of course required the AST or Cheetah cards to have 384-KB to equal 640-KB. I have as yet haven’t tried to configure these cards to just Extended memory only not bothering the Base memory. Both cards require switches on the cards to be set. The switch settings for the Cheetah is by executing a CHSETUP application included with the board. The AST has the switch settings configured from the manual included with the board. Drivers are then installed to be recognized from the config.sys.

The IBM card that I have is only configurable to Extended memory beginning at address 100000. I haven’t as yet tried that solution. Apparently, the Extended memory addressing is driven by switches on the card and configured by the BIOS of the motherboard.

 

[modem7]

I think the procedure for the U17/U37 is complicated since I am afraid of bricking the machine with a mistake.

I can't see how a mistake would brick the 5170, but I will create U17+U37 images (configured for your XT-CF-lite rev.2, sitting at I/O 300) then DM them to you.

The process speaks of splitting the combined binary into 32-KB for an odd or even ROM BIOS. How to split a combined binary and yet maintain the zero checksum?

Had you gone down that path:
It is of no concern. When the U17+U37 ROM's are fitted, the motherboard sees the combined result, and it is only that combined result that needs to have an 8-bit checksum of 00.

I have some 64-KB PROMS on order. In the sequence of starting, which BIOS ROM’s start first the U27, U47 or the U17, U37.

U27+U47, the motherboard BIOS.

As part of the POST within that (a BIOS ROM for the IBM 5170), a process will search for BIOS expansion ROM's, with the search including address E0000, which is where U17+U37 start at.

Is there a possibility of the machine hanging for adding those U17 and U37 BIOS?

There is always a possibility. But I will be testing the U17+U37 images that I will be DM'ing to you, so if there is any hanging, it won't be due to content in the ROM.

You mentioned the E0000 addressing space being used. In my XT machines that have an Extended memory card such as the Boca, the addressing space E0000 was used. ...

Yes, E0000-EFFFF is used by the IBM 5170 motherboard, the subject computer. Your "my XT machines" are different computers.

And on AT clone motherboards, some use E0000-EFFFF, some don't.

Even if we compare XT clones, there are differences between those. For example, some of the DTK/ERSO designs can be configured (via jumpers) for different sized ROM's. So you can have two identical {DTK/ERSO motherboard + BIOS}, but they have different memory maps. For example, one with eight ROM sockets. Put that into 'I am using 32 KB sized ROMs' mode, and from what I understand, you will end up with what is shown on the right side of the diagram at [here].

This all comes down to knowing your particular motherboard and cards, and what they all use. There was no 'plain sailing' back in the day.

 

[modem7]

In addition, I tried to change the J18 jumper to pins 2 and 3 on the IBM motherboard to allow added memory cards to be recognized.

No. J18 is not there to allow the use of memory cards. It is not that simple.

The 5170-068 model of IBM 5170 was supplied with only 256 MB of motherboard RAM. Looking at the diagram at [here], only bank 0 was populated. J18 was in the '256 KB' position. Let's say that an owner wanted to put another 256 KB into the 5170 (not necessarily on the motherboard), to bring conventional memory up to 512 KB. The owner had two possible routes:

1. Leave J18 in the '256 KB' position, and add a card that provides RAM in the 256 KB to 512 KB address space; or
2. Move J18 in the '512 KB' position, and populate motherboard bank 1.

Think of J18 as 'motherboard RAM size'.

 

[modem7]

The IBM card that I have is only configurable to Extended memory beginning at address 100000. I haven’t as yet tried that solution. Apparently, the Extended memory addressing is driven by switches on the card and configured by the BIOS of the motherboard.

To make sure that we are 'on the same page':

The 'CMOS SETUP' in an IBM 5170 does not 'configure' the card. In the CMOS SETUP of the 5170, you are informing the POST of, 'There is XX amount of conventional memory (base) and YY amount of extended memory (expansion) in the 5170. Expect in your memory search to find that amount. If you do not find those amounts, something has gone wrong; report an error. Test those amounts, and report an error if the testing fails.'

EDIT: The DOS utility at [here] will tell you what the POST found (not the settings in CMOS SETUP).