IBM PC XT 5160 BIOS versions

[modem7]

I wanted to be sure I could run the 5160ROMS file and screen capture it - the result is - YES the U18 and U19 ROMS are seen with the 11/08/82 ROMS installed in the 5155 (aka 5160) MB

Good. But not 100% conclusive to me because, per [here], IBM supplied an 8 KB sized ROM in socket U19.

So - I have also looked at the minuszero site to ensure I am using the correct ROM EEPROM's - I am NOT however using an adapter for each of the 27C256 ROMs that I am burning - they are ST chips and were UV erased prior to programming - I have ensured I have the U18 on one (and labeled) and U19 on the other (also labeled) I am burning the roms from the site without any modification to the memory space or "ROM IMAGE" duplication -

Per [here], on the early 5160 motherboards (i.e. wired for Mostek MK37000 series and MK38000 series ROM's, or equivalent), most 27256's will work. In the table there, I see that the ST Microelectronics produced 27C256 is known to work.

Some things to try:

* Using your TL-866, verify via electronic signature, that your ST Microelectronics 27C256 are in fact ST Microelectronics 27C256 (i.e. not re-labelled chips).

* Your IBM-supplied 11/08/82 ROM's are booting (to Cassette BASIC and DOS). Try programming a second 11/08/82 set on the ST Microelectronics 27C256's, seeing if that set works (including running 5160ROMS.EXE again). That would give you very good confidence in your EPROM programming process (and EPROM's).

* In the U18 socket, fit the IBM-supplied 11/08/82 ROM. In the U19 socket, fit the U19 ROM from a 05/09/86 set that you have programmed into your ST Microelectronics 27C25. Boot to DOS, then run 5160ROMS.EXE, expecting to see what is shown at [here], i.e. CRC of U19 is as expected for the U19 ROM of a 05/09/86 set.

 

[ricsne2010]

Good. But not 100% conclusive to me because, per [here], IBM supplied an 8 KB sized ROM in socket U19.


Per [here], on the early 5160 motherboards (i.e. wired for Mostek MK37000 series and MK38000 series ROM's, or equivalent), most 27256's will work. In the table there, I see that the ST Microelectronics produced 27C256 is known to work.

Some things to try:

* Using your TL-866, verify via electronic signature, that your ST Microelectronics 27C256 are in fact ST Microelectronics 27C256 (i.e. not re-labelled chips).

* Your IBM-supplied 11/08/82 ROM's are booting (to Cassette BASIC and DOS). Try programming a second 11/08/82 set on the ST Microelectronics 27C256's, seeing if that set works (including running 5160ROMS.EXE again). That would give you very good confidence in your EPROM programming process (and EPROM's).

* In the U18 socket, fit the IBM-supplied 11/08/82 ROM. In the U19 socket, fit the U19 ROM from a 05/09/86 set that you have programmed into your ST Microelectronics 27C25. Boot to DOS, then run 5160ROMS.EXE, expecting to see what is shown at [here], i.e. CRC of U19 is as expected for the U19 ROM of a 05/09/86 set.

OK - it might have to do with the way in which I am burning the EEPROMS -

1) The VL-866+ indicated the chips are indeed what they are branded as (I got them from a US Source and not China but it was worth the look to be sure)

2) When I removed the factory U19 but left the working factory U18 - this was the result (first image)





3) When I removed the factory U18 and installed my burned U18 (date coded 11/08/82) - the machine POST tested and booted - when I ran the 5160ROMS - it was unable to verify both roms as IBM roms....




So - I can only assume it is how the TL-866 software is burning the images to the EEPROMS - not sure about the settings for empty space but I usually fill with FF or 00.

The EEPROMS burn and verify without issue. (using xgPro v13.16 on my Windows 10 Machine)

These are the factory PROMS that I have for the 5155...


U18



U19


So I also realized that I am using the TI EEPROMS (not ST) but they do appear on the list of known working 27C256 chips for these boards....

So....... where to go from here?

again I truly appreciate the help!

Rich

 

[modem7]

2) When I removed the factory U19 but left the working factory U18 - this was the result (first image)

U18 socket: {IBM provided U18 of 11/08/82 set}
U19 socket: Empty

5160ROMS.EXE identified U18, as expected.
5160ROMS.EXE failed to identify U19, as expected for an empty socket.

BTW #1: Regarding the IBM provided U18 of 11/08/82 set, which is stamped with the IBM part number of 1501512, there were two versions. In the code, one version contains "1501512 COPR. IBM 1981", and the other, "1501512 COPR. IBM 1982". 5160ROMS.EXE caters for that.

BTW #2: The CRC calculated for an empty socket can vary from 5160 to 5160, and so, someone else doing this may see a different CRC for the empty U19 socket.

3) When I removed the factory U18 and installed my burned U18 (date coded 11/08/82) - the machine POST tested and booted - when I ran the 5160ROMS - it was unable to verify both roms as IBM roms....

U18 socket: {User created/programmed U18 of 11/08/82 set}
U19 socket: Empty

5160ROMS.EXE: Failed to identify {user created/programmed U18 of 11/08/82}

User created/programmed U18

For U18, you would have used the BIOS_5160_08NOV82_U18_1501512.BIN file from my web site. That is a 32KB sized file, and fits a 27256/27C256 perfectly (no padding, etc. required).

As you wrote, the TI version of 27C256 is in the list at [here]. Please provide a photo of the chip you have. With that information, I will see if I have the same chip, and if I do, do a test myself.

You can boot to DOS, and so we know that some of the U18 code is present. Would you visit [here] (noting that a page refresh in your browser may be required), perform the 'EXAMPLE: 32 KB sized ROM at address F8000', then attach the resulting MYF800.BIN file here. That file may give us a clue as to what is going on.

 

[ricsne2010]

U18 socket: {IBM provided U18 of 11/08/82 set}
U19 socket: Empty

5160ROMS.EXE identified U18, as expected.
5160ROMS.EXE failed to identify U19, as expected for an empty socket.

BTW #1: Regarding the IBM provided U18 of 11/08/82 set, which is stamped with the IBM part number of 1501512, there were two versions. In the code, one version contains "1501512 COPR. IBM 1981", and the other, "1501512 COPR. IBM 1982". 5160ROMS.EXE caters for that.

BTW #2: The CRC calculated for an empty socket can vary from 5160 to 5160, and so, someone else doing this may see a different CRC for the empty U19 socket.


U18 socket: {User created/programmed U18 of 11/08/82 set}
U19 socket: Empty

5160ROMS.EXE: Failed to identify {user created/programmed U18 of 11/08/82}

User created/programmed U18

For U18, you would have used the BIOS_5160_08NOV82_U18_1501512.BIN file from my web site. That is a 32KB sized file, and fits a 27256/27C256 perfectly (no padding, etc. required).

As you wrote, the TI version of 27C256 is in the list at [here]. Please provide a photo of the chip you have. With that information, I will see if I have the same chip, and if I do, do a test myself.

You can boot to DOS, and so we know that some of the U18 code is present. Would you visit [here] (noting that a page refresh in your browser may be required), perform the 'EXAMPLE: 32 KB sized ROM at address F8000', then attach the resulting MYF800.BIN file here. That file may give us a clue as to what is going on.

OOPS - my notes above were slightly incorrect - when I stated that I removed U19 - I removed the Factory U19 and installed the Burned EEPROM with the May 86 Code on it - and those were the results - the U19 socket was never empty- thats on me.....

Anyway I will see about the example you need and the MYF800.BIN file .......

 

[ricsne2010]

U18 socket: {IBM provided U18 of 11/08/82 set}
U19 socket: Empty

5160ROMS.EXE identified U18, as expected.
5160ROMS.EXE failed to identify U19, as expected for an empty socket.

BTW #1: Regarding the IBM provided U18 of 11/08/82 set, which is stamped with the IBM part number of 1501512, there were two versions. In the code, one version contains "1501512 COPR. IBM 1981", and the other, "1501512 COPR. IBM 1982". 5160ROMS.EXE caters for that.

BTW #2: The CRC calculated for an empty socket can vary from 5160 to 5160, and so, someone else doing this may see a different CRC for the empty U19 socket.


U18 socket: {User created/programmed U18 of 11/08/82 set}
U19 socket: Empty

5160ROMS.EXE: Failed to identify {user created/programmed U18 of 11/08/82}

User created/programmed U18

For U18, you would have used the BIOS_5160_08NOV82_U18_1501512.BIN file from my web site. That is a 32KB sized file, and fits a 27256/27C256 perfectly (no padding, etc. required).

As you wrote, the TI version of 27C256 is in the list at [here]. Please provide a photo of the chip you have. With that information, I will see if I have the same chip, and if I do, do a test myself.

You can boot to DOS, and so we know that some of the U18 code is present. Would you visit [here] (noting that a page refresh in your browser may be required), perform the 'EXAMPLE: 32 KB sized ROM at address F8000', then attach the resulting MYF800.BIN file here. That file may give us a clue as to what is going on.

Ok the MYF800.BIN file I cannot seem to attach to this post - I will need to see about my user forum settings -

Also - Note that I am using the burned 27C256 chips for this dump - I noticed an additional prompt on the screen (Sorry for the resolution as my video capture was not connected up this time) -

This prompt shows both ROM files at their respective memory spaces (I assume) in U18 and U19 (along with the 601 which is the floppy controller - I don't have my floppy drive hooked up as I am using a XTIDE SD Card board with the rom installed at C8000....)

I have also included the images of the EEPROMs that I am using

Cheers
Rich

 

[ricsne2010]

U18 socket: {IBM provided U18 of 11/08/82 set}
U19 socket: Empty

5160ROMS.EXE identified U18, as expected.
5160ROMS.EXE failed to identify U19, as expected for an empty socket.

BTW #1: Regarding the IBM provided U18 of 11/08/82 set, which is stamped with the IBM part number of 1501512, there were two versions. In the code, one version contains "1501512 COPR. IBM 1981", and the other, "1501512 COPR. IBM 1982". 5160ROMS.EXE caters for that.

BTW #2: The CRC calculated for an empty socket can vary from 5160 to 5160, and so, someone else doing this may see a different CRC for the empty U19 socket.


U18 socket: {User created/programmed U18 of 11/08/82 set}
U19 socket: Empty

5160ROMS.EXE: Failed to identify {user created/programmed U18 of 11/08/82}

User created/programmed U18

For U18, you would have used the BIOS_5160_08NOV82_U18_1501512.BIN file from my web site. That is a 32KB sized file, and fits a 27256/27C256 perfectly (no padding, etc. required).

As you wrote, the TI version of 27C256 is in the list at [here]. Please provide a photo of the chip you have. With that information, I will see if I have the same chip, and if I do, do a test myself.

You can boot to DOS, and so we know that some of the U18 code is present. Would you visit [here] (noting that a page refresh in your browser may be required), perform the 'EXAMPLE: 32 KB sized ROM at address F8000', then attach the resulting MYF800.BIN file here. That file may give us a clue as to what is going on.

MYF800.bin - the link to the file is in my dropbox account...

 

[modem7]

I noticed an additional prompt on the screen (Sorry for the resolution as my video capture was not connected up this time) -

This prompt shows both ROM files at their respective memory spaces (I assume) in U18 and U19 ...

That screen shot is unclear, but your "ROM" together with the screen shot suggests to me that you are seeing something like:
F0000 ROM
F8000 ROM

On an IBM 5160, when you see "ROM" like that, it is an error, the POST reporting that the 8-bit checksum of a particular area was expected to be 00, but the POST found otherwise. Corrupted ROM's is a common cause. Yes, it would have been good if IBM had included "Error" in the error description.

Ok the MYF800.BIN file I cannot seem to attach to this post - I will need to see about my user forum settings -

Sometimes, you may need to ZIP what it is to be attached.

MYF800.bin - the link to the file is in my dropbox account...

I took a look at that.

Comparing that to a good 1501512 image, I see:
- The first half is bad, and the second half is good;
- In the first half (bad), taking a look at some bytes, bits 5 and 7 are always one.

This 'first half is bad, and second half is good' is what we see for NEC's 27C256, the µPD27C256. A technical description of what is happening for the µPD27C256 is at [here].

Earlier, you wrote, "The VL-866+ indicated the chips are indeed what they are branded", and so we know that your TMS27C256 are not re-labelled µPD27C256.
And per the table at [here], the TMS27C256 is known to be suitable for an early 5160 motherboard.

Rhetorical: Did Texas Instruments change the design of the TMS27C256 at some point/s?

I probably have a TMS27C256 somewhere. I will see how it behaves for me on an early 5160 motherboard.

In the meanwhile:

1. Do you have any other brand of 27256/27C256, or have Winbond W27E257 ?

2. At the aforementioned web page ( [here] ), note the sentence starting with, "A good read was also obtained by". As an experiment, put in your TMS27C256 with pin 14 left out of the socket. Does that get things going?

 

[ricsne2010]

That screen shot is unclear, but your "ROM" together with the screen shot suggests to me that you are seeing something like:
F0000 ROM
F8000 ROM

On an IBM 5160, when you see "ROM" like that, it is an error, the POST reporting that the 8-bit checksum of a particular area was expected to be 00, but the POST found otherwise. Corrupted ROM's is a common cause. Yes, it would have been good if IBM had included "Error" in the error description.


Sometimes, you may need to ZIP what it is to be attached.


I took a look at that.

Comparing that to a good 1501512 image, I see:
- The first half is bad, and the second half is good;
- In the first half (bad), taking a look at some bytes, bits 5 and 7 are always one.

This 'first half is bad, and second half is good' is what we see for NEC's 27C256, the µPD27C256. A technical description of what is happening for the µPD27C256 is at [here].

Earlier, you wrote, "The VL-866+ indicated the chips are indeed what they are branded", and so we know that your TMS27C256 are not re-labelled µPD27C256.
And per the table at [here], the TMS27C256 is known to be suitable for an early 5160 motherboard.

Rhetorical: Did Texas Instruments change the design of the TMS27C256 at some point/s?

I probably have a TMS27C256 somewhere. I will see how it behaves for me on an early 5160 motherboard.

In the meanwhile:

1. Do you have any other brand of 27256/27C256, or have Winbond W27E257 ?

2. At the aforementioned web page ( [here] ), note the sentence starting with, "A good read was also obtained by". As an experiment, put in your TMS27C256 with pin 14 left out of the socket. Does that get things going?

Attached is a screen capture of the error screen on POST....(see below)




At the moment I do not have any other 256K EPROM's (I have smaller and larger lol) but I will try to lift the pin 14 as suggested and see what happens.... its entirely possible that these 150ns speed TI chips were changed at some point - I have on order some ST 200ns 27C256's on the way.....

Also wanted to mention that I have successfully burned and used both the Ruud Test tools and the XT RAM test (see pic) without issue (they start right up) - the XT Tools are in a TI 256 chip and the Ruud is on a Winbond 512K....

 

[modem7]

Attached is a screen capture of the error screen on POST....(see below)

Starting addresses of F8000 and FA000 makes sense. Per [here], those are the two 8 KB blocks in the low half (the problem half) of the U18 address space.

Just in case you are interested, the POST test that is producing those ROM errors is the 'ROM CHECKSUM TEST II' one in the 'BIOS Revision of 11/08/82' section of [here].

At the moment I do not have any other 256K EPROM's (I have smaller and larger lol) but I will try to lift the pin 14 as suggested and see what happens.... its entirely possible that these 150ns speed TI chips were changed at some point - I have on order some ST 200ns 27C256's on the way.....

These days, I use Winbond W27E257 in place of 27256/27C256.

Also wanted to mention that I have successfully burned and used both the Ruud Test tools and the XT RAM test (see pic) without issue (they start right up) - the XT Tools are in a TI 256 chip and the Ruud is on a Winbond 512K....

Ruuds Diagnostic ROM (RDR) is only 8 KB in size, and per the 5160 section of the diagram at [here], resides in the fourth quarter of the 32 KB sized ROM put into the U18 socket. That quarter is unaffected by the problem you are experiencing; first half is not working.

XTRAMTEST is 'in the same boat'.

What you may see, is RDR failing the 'Check ROM at F8000' and 'Check ROM at FA000' tests.

I probably have a TMS27C256 somewhere. I will see how it behaves for me on an early 5160 motherboard.

I probably won't be able to do that until Monday or Tuesday.

 

[ricsne2010]

Starting addresses of F8000 and FA000 makes sense. Per [here], those are the two 8 KB blocks in the low half (the problem half) of the U18 address space.

Just in case you are interested, the POST test that is producing those ROM errors is the 'ROM CHECKSUM TEST II' one in the 'BIOS Revision of 11/08/82' section of [here].


These days, I use Winbond W27E257 in place of 27256/27C256.


Ruuds Diagnostic ROM (RDR) is only 8 KB in size, and per the 5160 section of the diagram at [here], resides in the fourth quarter of the 32 KB sized ROM put into the U18 socket. That quarter is unaffected by the problem you are experiencing; first half is not working.

XTRAMTEST is 'in the same boat'.

What you may see, is RDR failing the 'Check ROM at F8000' and 'Check ROM at FA000' tests.


I probably won't be able to do that until Monday or Tuesday.

OK no worries on your testing - I appreciate your help on this!

Just a quick update -

I pulled PIN 1 from both 27C256's in U18 and U19 - I got a different POST test result.....



Notice how its only reporting an error on one of the 2 ROM's - I did this test with my pre-programmed 11-02-82 BIOS images ....

I also created another MYF800.BIN (it should be the zip file attached here)

My EEPROM UV Eraser Lamp bulb is dead and my replacement is on the way - I also went ahead and ordered some W27C257's (ebay specials from asia so we know how this might go)

When I can program the '86 year bios and test with the pulled pin 1 using the TI chips I will advise as to what I find also.

Thanks again for all the help!

Rich

 

[modem7]

I pulled PIN 1 ...

... with the pulled pin 1

Clearly, you meant pin 14.

Notice how its only reporting an error on one of the 2 ROM's - I did this test with my pre-programmed 11-02-82 BIOS images ....

F6000. Per [here], the last quarter of U19. The 8-bit checksum is not the 00 expected.

I also created another MYF800.BIN (it should be the zip file attached here)

That has a CRC32 of 79522C3D, which is a match for the 1981 copyrighted 1501512.

BIOS_08_16_82_U18 = '3C9B0AC3';
BIOS_08_16_82_U19 = 'FC982309';

BIOS_11_08_82_U18_1981 = '79522C3D'; { copyright 1981 }
BIOS_11_08_82_U18_1982 = '0AACA3B0'; { copyright 1982 }
BIOS_11_08_82_U19 = 'FC982309';

BIOS_01_10_86_U18 = '1054F7BD';
BIOS_01_10_86_U19 = 'B5FB0E83';

BIOS_05_09_86_U18 = '4F417635';
BIOS_05_09_86_U19 = '758FF036';

If you want to do your own CRC32 calculations, see the 'Free software' section of [here], noting that the menu bar navigation is instead: {Analysis} {Checksums} {CRC-32} {OK}

I also went ahead and ordered some W27C257's (ebay specials from asia so we know how this might go)

Over years, I have ordered lots of W27C257's from China, and so far, all good. I have had some fail-in-use on me.

 

[ricsne2010]

Clearly, you meant pin 14.

I thought the "14" per the post about the faulty ROMs were about "A14" Which reside on either Pin 1 or Pin 27 - but not Pin 14 (as that is the ground for the entire chip) - if I am mistaken for the website data please advise since I figured the issue was the routing of A14 and how that pin is addresses based on the rom installed....

F6000. Per [here], the last quarter of U19. The 8-bit checksum is not the 00 expected.


That has a CRC32 of 79522C3D, which is a match for the 1981 copyrighted 1501512.

BIOS_08_16_82_U18 = '3C9B0AC3';
BIOS_08_16_82_U19 = 'FC982309';

BIOS_11_08_82_U18_1981 = '79522C3D'; { copyright 1981 }
BIOS_11_08_82_U18_1982 = '0AACA3B0'; { copyright 1982 }
BIOS_11_08_82_U19 = 'FC982309';

BIOS_01_10_86_U18 = '1054F7BD';
BIOS_01_10_86_U19 = 'B5FB0E83';

BIOS_05_09_86_U18 = '4F417635';
BIOS_05_09_86_U19 = '758FF036';

If you want to do your own CRC32 calculations, see the 'Free software' section of [here], noting that the menu bar navigation is instead: {Analysis} {Checksums} {CRC-32} {OK}

Great data! Thank you ....

Over years, I have ordered lots of W27C257's from China, and so far, all good. I have had some fail-in-use on me.

OK cool - I know we have had the discussion about remarking and I have come across some in the past with other chips

 

[modem7]

I thought the "14" per the post about the faulty ROMs were about "A14" Which reside on either Pin 1 or Pin 27 - but not Pin 14 (as that is the ground for the entire chip) - if I am mistaken for the website data please advise since I figured the issue was the routing of A14 and how that pin is addresses based on the rom installed....

You are right. My mistake. I had "14" in my head.

OK cool - I know we have had the discussion about remarking and I have come across some in the past with other chips

None of my 30 or so W27C257's have turned out to be re-labelled something else.

( Of possible interest, per [here], I have re-labelling happening in the 'other direction'; a W27C257 re-labelled as an SST 27SF256. )

 

[ricsne2010]

You are right. My mistake. I had "14" in my head.


None of my 30 or so W27C257's have turned out to be re-labelled something else.

( Of possible interest, per [here], I have re-labelling happening in the 'other direction'; a W27C257 re-labelled as an SST 27SF256. )

Quick question - the Minus Zero link that was sent to do the .BIN dump has both 8K and 32K options - the instructions are very clear and easy to follow - but does this only look at U18 and not U19? How could I go about to get the data from U19 to see what the CPU is seeing from that ROM? (I am sure its a matter of adjusting the memory space that the DUMP.EXE is looking at but since I'm still on the learning curve with how the ROM's are addresses - I figured I'd ask)

Thank you!!!

 

[modem7]

Quick question - the Minus Zero link that was sent to do the .BIN dump has both 8K and 32K options - the instructions are very clear and easy to follow - but does this only look at U18 and not U19? How could I go about to get the data from U19 to see what the CPU is seeing from that ROM? (I am sure its a matter of adjusting the memory space that the DUMP.EXE is looking at but since I'm still on the learning curve with how the ROM's are addresses - I figured I'd ask)

Thank you!!!

Yes, that link contains examples, and the code is adjusted (base address and size) according to the requirement. U19 is 32KB sized starting at address F0000, and so use the 'EXAMPLE: 32 KB sized ROM at address F8000' code as the basis, substituting F000 in place of F800.

 

[twolazy]

I read the bios chip of one vga card and my willem corrupted the EPROM! The contents of the backup file and the eprom after reading it were different. I flashed the backup file to a 27C512 eprom and the vga card worked again.

Don't trust the willem readers, they are not the most reliable!

I've read 100s of eproms off my Willem without any problems. Sounds like either A, you used the wrong profile, or B, the chip somehow got zapped by ESD. Or perhaps C, and your Willem has issues...

 

[modem7]

I probably have a TMS27C256 somewhere. I will see how it behaves for me on an early 5160 motherboard.

I probably won't be able to do that until Monday or Tuesday.

I could not find any TMS27C256, but I did some find some make-models of 27256/27C56 that were not in the table, at [here]. I tested them, then added them to the table.

 

[ricsne2010]

I could not find any TMS27C256, but I did some find some make-models of 27256/27C56 that were not in the table, at [here]. I tested them, then added them to the table.

Well Sorry for the delay in the reply - the UV EEPROM Erasure required some "repairs" and I also obtained the W27E257 chips and I did program them each as a U18 and U19 with the May 86 Bios - All is well now with these EEPROM's - See Screen Shot -




Needless to say, Still not sure why the ST 256's were not working but if you want me to send you some of these chips to test with I'd be happy to do so.

Another 5155 saved - next is the repair of the CRT

Thank you again for your insight and help!

 

[modem7]

Needless to say, Still not sure why the ST 256's were not working but if you want me to send you some of these chips to test with I'd be happy to do so.

M27C256, by 'ST Microelectronics'. At post #57, I found one. My (repeat: my) one worked. I didn't put it into an early 5160 motherboard; instead, verifying that all of it read successfully when pin 1 was grounded (per note 2 at the bottom of [here]).

I now have some TMS27C256, and will get around to testing those later.