• Please review our updated Terms and Rules here

286 Phoenix bios & can I use it in an IBM 5170?

I am amazed that this all worked out. Sorry for bad advice. I was assuming that the 4 chips were all part of one BIOS image, turns out to be two separate BIOS images, which basically matches what the labels said they were. Like you said, it booted up the first time straight away. Now you have 2 working BIOS images to use on your 5170, horray.
 
jscipione said:
I was assuming that the 4 chips were all part of one BIOS image, turns out to be two separate BIOS images, which basically matches what the labels said they were.
Click to expand...
There was always the possibility that 'Phoenix Compatibility Software' may have turned out to be software that enhances the motherboard BIOS.
 
Edited this post for errors.

It seems even though my board has U131 printed above the socket, it still uses the configuration for the boards with the printing below the socket.

I found a picture of my board before I wrecked the U131 socket. It is a terrible picture, but I was not trying to take a picture of U131. By default, the top pins were not bridged, so when I put a solder bridge on the bottom pins, I didn't actually change out of 27256 mode, as it was the same configuration as default.

This must be why I could not boot with only two of the award/phoenix roms (but it did boot with three).

The third picture of U131 with the repaired socket and top two pairs of pins bridged was the mode where I actually was getting the correct address locations and where I did not get a parity error when dumping the ROMs. This was after I repaired the socket.

The last picture is after I destroyed the socket and solder bridged the bottom pair on pins, and was getting the bios address mismatches, with was the same as the default 27256 mode.

The picture of the IBM ROMs was a reference photo I took before I made any changes.
 

Attachments

  • 1000005382.png
    1000005382.png
    852.9 KB · Views: 4
  • 1000005279.png
    1000005279.png
    3.9 MB · Views: 4
  • 1000005378.png
    1000005378.png
    2.2 MB · Views: 4
  • 1000005379.png
    1000005379.png
    1.2 MB · Views: 4
  • 5170_u131.jpg
    5170_u131.jpg
    193.3 KB · Views: 4
Last edited:
modem7 said:
I wonder why on the clone motherboard, the source of the four ROM's, someone had added a second motherboard BIOS.
Click to expand...
This just occured to me. Perhaps the source of these ROMs, the clone board, only had a 27128 setting, and the board would not boot without all 4 sockets populated.
 
Also interesting is that my IBM ROMS are copyright 1981,-1983 considering the 5170 didn't come out until 1984. The ones on -0° show 1981,-1984.
 
offensive_Jerk said:
Also interesting is that my IBM ROMS are copyright 1981,-1983 considering the 5170 didn't come out until 1984. The ones on -0° show 1981,-1984.
Click to expand...
Some code may have been copied from the BIOS ROM's of the 5150 and 5160 (i.e. "Don't reinvent the wheel.")

Sometimes, it appears that IBM forgot to update the year of copyright when changing the ROM's code .
For example:
* IBM 5150 - 1501476 ROM - Internal date: 10/27/82 - Some contain "COPR. IBM 1981". In others, the only difference is that the "1981" is "1982". IBM spotted the 1981, then fixed it?
* IBM 5160 - 1501512 ROM - Internal date: 11/08/82 - Some contain "COPR. IBM 1981". In others, the only difference is that the "1981" is "1982". IBM spotted the 1981, then fixed it?
 
offensive_Jerk said:
It seems even though my board has U131 printed above the socket, it still uses the configuration for the boards with the printing below the socket.
Click to expand...
That would have to be proven via something like what I did in post #35.
ROM's with known content inserted into the four sockets, then using something like DEBUG to verify that the viewed content is per the diagram at [here].
 
offensive_Jerk said:
... and where I did not get a parity error when dumping the ROMs.
Click to expand...
That parity error is odd (pun unintended).
On a functional 5170 motherboard, the changing of the U131 setting is only changing how the four ROM sockets are addressed within the E0000-FFFFF address space.
Irrespective of the U131 setting, DEBUG is still reading all/part of a ROM.
Why would a parity error occur, which is a RAM thing.
I think that you should run a decent RAM test.
 
modem7 said:
Why would a parity error occur, which is a RAM thing.
I think that you should run a decent RAM test.
Click to expand...
Good point. I was taking a wild guess that it was because I was trying to dump an invalid address or something.

I did run a Checkit3 RAM test during this, but not the 'extended' test or whatever they call it and it passed 1 pass.

Is there a certain memory test you recommend?
 
If my calculations are correct, U16 is suspect.
Super soft error
027533
Bit 2
 

Attachments

  • PXL_20231018_032423053.MP.jpg
    PXL_20231018_032423053.MP.jpg
    4.4 MB · Views: 10
offensive_Jerk said:
If my calculations are correct, U16 is suspect.
Super soft error
027533
Bit 2
Click to expand...
027533 hex = 161075 dec = 157.3 KB
So, bit 2 in bank 0.
The circuit diagram of the type 1 motherboard shows that bit 2 on the memory data bus goes to RAM chip U13.

offensive_Jerk said:
Is there a certain memory test you recommend?
Click to expand...
No. I have not evaluated them.

Note that the SuperSoft/Landmark Diagnostic ROM (and early versions of Ruud's Diagnostic ROM) do not check for RAM addressing issues.
 
I just ran Checkit ram test on the full test on 10 passes and no errors. I also ran the IBM Advanced diagnostics and no errors.
Removed the expansion board too.
I put the super soft rom back in and it detects an error.

I'll try that chip, thanks.
 
Last edited:
modem7 said:
027533 hex = 161075 dec = 157.3 KB
So, bit 2 in bank 0.
The circuit diagram of the type 1 motherboard shows that bit 2 on the memory data bus goes to RAM chip U13.
Click to expand...
I got this wrong, because the SuperSoft/Landmark ROM is testing and reporting using bytes, not words.

That means that one needs to look at the reported failure address. Even address = low byte, odd address = high byte. Just like the ROM diagram at [here].

The failure address shown to you is odd, so the bit in error is not 2, but bit 10.
Per the diagram below, taken from the circuit diagram for the type 1 motherboard, bit 10 corresponds to U14.
On your type 1 motherboard, you will see that U14 is in the bank that the motherboard has 'BANK 0' marked against it, per the photo at [here].

1697678947099.png
 
offensive_Jerk said:
That's odd, the super soft manual told be completely different information.
Click to expand...
I looked at the user manual available at [here].
All I see on the subject is a section named, 'Interpretation of Memory Tests'.
As I expected, the section is very broad due to the many different motherboards that the diagnostic can be run on.
 
You must log in or register to reply here.
Back
Top