BIOS upgrade in IBM 5160 doesn't work. Help needed!

[mrmanse]

Hi!

I have an IBM 5160 with the 64-256k motherboard and the 11/08/82 BIOS.
Original BIOS ROMs are labeled U18=1501512, U19=6359116.

I wish to upgrade BIOS to the 05/09/86 version, but I don't own a programmer so I asked for help in a facebook group and a kind person helped me out.

So I got the files in BIOS_5160_09MAY86.zip from minuszerodegrees programmed into 2 identical Nec D27C256D-25 EPROMS, but unfortunately they don't work With them installed the motherboard is dead, no beeps, monitor is powered down (LCD on VGA-card), and no blinking lights on the keyboard (i use a model M with AT/XT protocol support that blinks while detecting the XT protocol).

So I asked the guy if he's sure about the programming, if he verified the writes, and such, and he is sure they are correct. I have no reason to doubt him, but if course, I can't verify the EPROMS myself.

* Could it be a problem with the C in choosing 27c256? I read that they need 6V, do I have that? Should I check anything with multimeter?
* Or are they to slow? -25 ? I read somewhere that -20 is required.
* Could it be that the 16-bit VGA-card I'm using only accepts the 11/08/82 BIOS?
* I also read on one site that shorting pin 1 and 28 is needed, but that was not for the IBM XT.

I can return the EPROMS and ask for them to be verified again, but I'd like that to be my last resort, and I want to exclude if there's anything else I'm doing wrong first.

Any help greatly appreciated!
/Måns

 

[Malc]

* Could it be a problem with the C in choosing 27c256?

No, 27C256 chips will be fine

* Or are they to slow? -25 ? I read somewhere that -20 is required.

No, 250ns or faster will be fine.

* Could it be that the 16-bit VGA-card I'm using only accepts the 11/08/82 BIOS?

No, If the 16-bit vga card is working with the 11/08/82 bios it should work with the latest bios.

I can return the EPROMS and ask for them to be verified again, but I'd like that to be my last resort, and I want to exclude if there's anything else I'm doing wrong first.

Pull the new bios roms and make sure no pins are bent under (easy done)and you got the right chip in the right socket, If all OK, Put the original roms back in and make sure the the machine boots and works as it should.

If the machine boots fine with the original roms back in then it looks like the new roms haven't been programmed properly or you got faulty ROM/'s ( I assume the guy didn't test the roms in an XT before he sent them to you ?).

 

[mrmanse]

Pull the new bios roms and make sure no pins are bent under (easy done)and you got the right chip in the right socket, If all OK, Put the original roms back in and make sure the the machine boots and works as it should.

If the machine boots fine with the original roms back in then it looks like the new roms haven't been programmed properly or you got faulty ROM/'s ( I assume the guy didn't test the roms in an XT before he sent them to you ?).

Thanks for the reply!

Check the pins - check!
Right chip in the right socket - check! (I actually also tried a switch, but it didn't work either)
Chips correctly oriented - check!
Original chips back and computer works - check!

Ok, I'll talk to him about a return. And you assume correctly, to my knowledge didn't test them on a 5160.

/Måns

 

[modem7]

* Or are they to slow? -25 ? I read somewhere that -20 is required.

As Malc wrote, -25 is okay for the IBM 5160. From the'Revised Edition (April 1983)' and 'Revised Edition (March 1986)' editions of the technical reference: "The ROM is packaged in 28-pin modules and has an access time and a cycle time of 250 ns each."

* Could it be that the 16-bit VGA-card I'm using only accepts the 11/08/82 BIOS?

Try the Minimum Diagnostic Configuration procedure at [here]. If you hear the beeps, the BIOS is running.

* I also read on one site that shorting pin 1 and 28 is needed, but that was not for the IBM XT.

No pin shorting required. If pin shorting was required, I would have added a note to that effect in BIOS_5160_09MAY86.zip

 

[SomeGuy]

Here is a wacky thought:

According to http://www.minuszerodegrees.net/5160/bios/5160_bios_revisions.htm

In the 11/08/82 BIOS revision, chip U19 contains part of cassette BASIC and thus is not critical to operation of the computer (only cassette BASIC is lost).
For that reason, if the POST discovers that U19 has failed, the POST will display "F6000 ROM" and allow booting to continue.

This is not the case for the later BIOS revisions, because in those, U19 also contains part of the BIOS. If U19 fails in those, the motherboard will appear 'dead'.

Soooo, perhaps try putting the original U18 back in place with either of the burned eproms in U19. If that is correct, and the eproms aren't physically defective, then you should be able to boot, and then dump the contents of the ROM with debug.

 

[modem7]

I downloaded BIOS_5160_09MAY86.zip from www.minuszerodegrees.net, then burned the included ROM images to a couple of 27C256 chips. As expected, using those chips to upgrade the factory-fitted ROMs on my 5160 motherboard of type 64-256KB was successful.

 

[Malvineous]

@mrmanse: If you want to verify the ROMs yourself before you send them back, and you have a network card with a boot ROM socket, you can always put one of the chips into that, boot it up in the same or another PC, then dump the contents of the boot ROM to check it yourself.

 

[mrmanse]

...then you should be able to boot, and then dump the contents of the ROM with debug.

@mrmanse: If you want to verify the ROMs yourself before you send them back, and you have a network card with a boot ROM socket, you can always put one of the chips into that, boot it up in the same or another PC, then dump the contents of the boot ROM to check it yourself.

Thanks everybody for responses! The above is something I thought of it myself but couldn't figure out how to do it, nor google it. I do have a network card that is verified working on the very same computer, an 3com Etherlink II (3c503). So I could put each of the BIOS ROMS in the boot rom socket and read it? that would be great! How?

 

[SomeGuy]

There is a guide on how to dump bios ROMs here: http://www.mess.org/dumping/dump_bios_using_debug
Unless I am horribly mistaken, the U19 rom is from F0000 to F7FFF.

But the hard part for most people is getting the files to a different computer for comparison. If that is a problem for you, then you probably just want to view the output on you screen.

For example, plop your original U18 in place with one of the burned eproms in U19, and in DEBUG type:
d f000:0000
and keep entering "d" until you reach f000:8000 (where the other ROM begins).

You don't need to compare every byte, but look at the start, middle, end, etc. If the ROMs are damaged or improperly programmed you may see all "00"s or "ff"s.

 

[mrmanse]

Thanks for the link, it worked great! It didn't work with the etherlink II card, but to put each of the ROMS in the U19 socket was a great idea that worked very well!

I successfully read both of the ROMs a couple of times, while placed in U19 socket, using 2 different programs, and I got some really interesting results. Using the Etherlink II and that absolutely wonderful mtcp program suite I easily transferred them to my main computer

Both of the ROMs read correctly in the file area of 0x4000-7FFF, but are empty from 0x0000-0x3FFF. Yes, half of the ROM is correct, for both of them, the other half isn't. The first half of the U18 chip repeatedly read blank, but the U19 chip was unstable, and I got slightly different reads each time, although mostly zeroes. Does this behavior mean anything to you guys? Bad EPROM? Bad programmer? Bad eraser? Am i correct assuming that the problem isn't with my computer since one ROM read zeroes, and the other was unstable, which are different behaviors?

 

[SomeGuy]

Instability in the data read usually means a pin is not making contact with the socket. But if the pins look good, and it is firmly in the socket then it is probably a damaged chip.

The lack of data in the first half probably means it was incorrectly burned. For example, perhaps a 27128 type was selected during the burn process. In other cases it could also mean an incompatibility between a chip and motherboard, but in this case that 27c256 chip should work perfectly with no changes to the motherboard.

 

[mrmanse]

The lack of data in the first half probably means it was incorrectly burned. For example, perhaps a 27128 type was selected during the burn process.

Sounds very resonable. I'll be getting new ROMs in a few days and I keep my fingers crossed!

 

[mrmanse]

I have news!

I got two new ROMS from the same guy and learned something really interesting. By keeping the original U18 (1982 version) in it's socket, I was able to boot the computer and read other ROMS from the U19 socket.

I have 2 x 2 ROMS with the 09/05/86 BIOS
U18: NEC D27C2560-25 and National NMC27C2560 200
U19: two NEC D27C2560-25

The NEC's read correctly only from 0x4000h and above, the lower half of the ROM reading blank (or nearly blank), the NMC27C2560 read correctly. Could this be a faulty U19 socket on my mobo? Not likely, since one of the ROMs actually work fine.

So, I got a Minipro TL866A programmer to really find out what was going on, and I can now confirm that all the ROMs verify perfectly to the BIN files. So I conclude that the NEC D27C2560-25 aren't compatible with (at least mine) 5160 motherboard of the 64-256KB type.

Has anyone else encountered this?

 

[Malc]

Are you sure that 0 on the end is correct, shouldn't it be the letter D ie: NEC D27C256D-25 ?
The NEC D27C256 is pin compatible with 27256 so should work, Unless the Eproms are faulty in some way.

Can you erase the non working eproms and reprogram them in your new programmer, Also see if your programmer software has an ID function to ID the eprom, I don't know about the Minipro so it may or may not have that option. Another thing is the NEC D27C256 requires 21V VPP and that might be a problem on some USB programmers.

 

[mrmanse]

Are you sure that 0 on the end is correct, shouldn't it be the letter D ie: NEC D27C256D-25 ?

Sorry, you are absolutely correct! The parts are all D27C256D-25.

The NEC D27C256 is pin compatible with 27256 so should work, Unless the Eproms are faulty in some way.

Can they be faulty in a way that the eprom programmer reads them correctly, but the computer doesn´t? That's really strange.

Can you erase the non working eproms and reprogram them in your new programmer, Also see if your programmer software has an ID function to ID the eprom, I don't know about the Minipro so it may or may not have that option. Another thing is the NEC D27C256 requires 21V VPP and that might be a problem on some USB programmers.

I believe the programmer does 21V, but I don't have an eraser. I did order some new eproms on ebay, hopefully the'll get here soon.

 

[Malc]

Can they be faulty in a way that the eprom programmer reads them correctly, but the computer doesn´t? That's really strange.

Yes, I've had a few NOS Eproms that were faulty over the years, Faulty in a way that they can't be programmed and faulty in a way that they can be programmed / read and verified perfectly but not work when fitted in the board.

I believe the programmer does 21V, but I don't have an eraser. I did order some new eproms on ebay, hopefully the'll get here soon.

Erasers are pretty cheap, Don't know what the chinese ones are like though, I bought mine used years ago for £5 and it's still going strong.

 

[SomeGuy]

Yes, I've had a few NOS Eproms that were faulty over the years, Faulty in a way that they can't be programmed and faulty in a way that they can be programmed / read and verified perfectly but not work when fitted in the board

Quite possible if the fault makes the chip extra speed sensitive. Most EPROM programmers read/verify EPROMs at a speed much slower than they would normally operate.

 

[modem7]

So, I got a Minipro TL866A programmer to really find out what was going on, and I can now confirm that all the ROMs verify perfectly to the BIN files.

So, a problem when some of these are placed in socket U19 and then read. And the pattern is always half the ROM.

I looked at the 5160 motherboard's schematic diagram, and noticed something odd.

First, I saw that pin 1 on the U18/U19 sockets had been incorrectly labelled as 'A14' instead of 'Vpp'. From that, I thought that the shown connection of Vpp and A14 together must also be an error, but I was very suprised to discover that my 64-256KB motherboard does have those pins tied.

I looked at my later 256-640KB motherboard, and observed that IBM have fixed this error via a wiring modification:
1. U14: On component side, trace to pin 12 (XA14) has been cut.
2. U18/U19: On component side, trace to pin 1 has been cut.
3. U18/U19: On solder side, pin 1 (Vpp) wired to pin 28 (Vcc).
4. On solder side, pin 27 (A14) of U18/U18 wired to pin 12 (XA14) on U14.

So that means that on a 5160 motherboard of type 64-256KB, the Vpp pin (on both sockets) is low when the first half of the ROM is addressed, and high for the second half. I bet that this is a problem for some make/models of EPROM.

 

[per]

First, I saw that pin 1 on the U18/U19 sockets had been incorrectly labelled as 'A14' instead of 'Vpp'. From that, I thought that the shown connection of Vpp and A14 together must also be an error, but I was very suprised to discover that my 64-256KB motherboard does have those pins tied.

I looked at my later 256-640KB motherboard, and observed that IBM have fixed this error via a wiring modification:
1. U14: On component side, trace to pin 12 (XA14) has been cut.
2. U18/U19: On component side, trace to pin 1 has been cut.
3. U18/U19: On solder side, pin 1 (Vpp) wired to pin 28 (Vcc).
4. On solder side, pin 27 (A14) of U18/U18 wired to pin 12 (XA14) on U14.

[---]

So that means that on a 5160 motherboard of type 64-256KB, the Vpp pin (on both sockets) is low when the first half of the ROM is addressed, and high for the second half. I bet that this is a problem for some make/models of EPROM.

Looks like a possible cause. Have you tested on a breadboard test cirquit if you can read your particular EPROM chip with VPP at +5V?

The 64-256K board with A14 on both pin 1 and 27 is problably for compatiblility with certain variations of the 27 series EPROM pinout. I can't say for certain what chips were available when the XT launched in 1982-83, but the 28256 EEPROM does indeed have A14 on pin 1 and not 27.

 

[modem7]

The 64-256K board with A14 on both pin 1 and 27 is problably for compatiblility with certain variations of the 27 series EPROM pinout. I can't say for certain what chips were available when the XT launched in 1982-83, but the 28256 EEPROM does indeed have A14 on pin 1 and not 27.

You led me to look farther.

The original U18 and U19 ROMs in the 5160 were sized 32 KB and 8 KB respectively. The 32 KB one was of the Mostek MK38000 series. An example photo is [here]. According to the MK38000 data sheet, the MK38000 could be supplied in two different pin configurations; A14 on on 1, or A14 on pin 27.

So it appears that:

64-256KB motherboard

* IBM have wired the U18/U19 sockets for a MK38000, catering for either pin configuration of the MK38000.
* If a 27256 EPROM is substituted, the Vpp pin (27) of the 27256 will be low when the first half of the ROM is addressed, and high for the second half. This may be a problem for some make/models of 27256.

256-640KB motherboard

* IBM have wired the U18/U19 sockets for ROMs with a 27256 pinout. [example]