Assistance with assembly code for 5160 ROM

[alejack12001]

Per [here], the 01/10/86 dated BIOS.
If you were to look at the contents of that U18, you would see "01/10/86" close to the end.

Yes, I see that from the website. Actually, the second set of pictures (https://minuszerodegrees.net/5160/bios/62X0852_62X0853_photos.htm) match exactly. Thank you for clarifying this inquiry.

 

[alejack12001]

I got the GLaBIOS to work. The result was not what I expected, however. The GLaBIOs ROM starts up the 5160 faster than I have ever seen any of these machines start up.

The information displayed following the startup, however, has me asking if GLaBIO’s binary received is a bit tailored to one specific machine. The first error encountered was an omission of the FPU, even though sw1 position 2 is set to off position. The FPU is an Intel D8087-1 co-processor. The next error relates to the total conventional memory on the motherboard. The SW1 positions 3 & 4 are off as well, which, according to the minuszerodress website, the system should be reading all banks. Motherboard for 256-640 is set up with banks 0 & 1 at 256-KB chips and banks 2 & 3 of 64-KB chips, resulting in 640-KB. GLaBIOS only saw a total of 256 KB of RAM.

So, what happened here? Is the binary received taken from a machine that has no FPU and 256 KB? It looks like it was tailored. I plan to try a different GLaBIOS binary. Could there be issues with the FPU and memory on the motherboard? That is possible as well.

 

[modem7]

So, what happened here? Is the binary received taken from a machine that has no FPU and 256 KB? It looks like it was tailored. I plan to try a different GLaBIOS binary. Could there be issues with the FPU and memory on the motherboard? That is possible as well.

For switch block SW1, are you confident about what position is OFF/ON for the switches? We have seen people get that incorrect. See the switch block examples at [here].

If confident/sure, what you could do, is to see what other software (other than GLaBIOS) is reporting.

For example, does Ruud's Diagnostic ROM (RDR) show:
- A top-of-RAM figure of 640 KB or 256 KB
- If 640 KB, a RAM problem somewhere
- In SW1, that switches 2, 3, and 4, are reported as OFF.

If RDR shows that switch 2 is reported as OFF, what CheckIt's test of the 8087 FPU/NPU reveals. Also, you could verify that the 8087 is inserted correctly (e.g. no pins are bent up under the chip).

 

[alejack12001]

Enclosed is a picture of the SW settings. When I bought the motherboard, settings 1-4 were off because the FPU and 640 KB RAM were already installed. Settings 5 & 6 were adjusted to "on" because I am using a VGA card. I have a CGA card; however, I don't have the CGA monitor. So, I am using a 16-bit VGA that was modified by jumpers to work in an 8-bit slot. I don't know enough about the Ruud diagnostic tool to determine if the tool is heavily dependent on CGA/MDA. Settings for 7 & 8 are for two floppies with 7 on and 8 off. The floppies are using a Tex Elec Quad controller that is externally configured with jumpers and switches. Internal settings have to be set to recognize my Tandon 360-KB floppy and my 1.44 MB GoTek. As you can see from the picture, the switch settings are not too clear. I am not a big fan of rocker switches.

I saw a tool used on a 5160 motherboard used by Necroware, who repaired memory on a similar board using a tool to highlight the bad chips. I don't know what tool was that he was using. I need a little time to study this Ruud tool before I get back with you to learn how the tool finds the defective chips. Then implement the tool on my system. Thank you for the suggestion. I think the tool will be quite helpful.

 

[modem7]

I don't know enough about the Ruud diagnostic tool to determine if the tool is heavily dependent on CGA/MDA.

It is.

I have a CGA card; however, I don't have the CGA monitor.

To stop having to bring my CGA monitor out of storage, I often use a {CGA + MDA/CGA-to-VGA converter + VGA monitor} combination when testing Ruud's Diagnostic ROM.

I saw a tool used on a 5160 motherboard used by Necroware, who repaired memory on a similar board using a tool to highlight the bad chips. I don't know what tool was that he was using. I need a little time to study this Ruud tool before I get back with you to learn how the tool finds the defective chips. Then implement the tool on my system. Thank you for the suggestion. I think the tool will be quite helpful.

Right now, you do not know if you have a RAM subsystem related problem, or a GLaBIOS build that is configured for 256 KB max.

I know that you have the 01/10/86 dated BIOS ROM's for this 256-640KB motherboard. If you fit those ROM's, does the POST count up to 640 KB or 256 KB ?

 

[alejack12001]

It is.


To stop having to bring my CGA monitor out of storage, I often use a {CGA + MDA/CGA-to-VGA converter + VGA monitor} combination when testing Ruud's Diagnostic ROM.


Right now, you do not know if you have a RAM subsystem related problem, or a GLaBIOS build that is configured for 256 KB max.

I know that you have the 01/10/86 dated BIOS ROM's for this 256-640KB motherboard. If you fit those ROM's, does the POST count up to 640 KB or 256 KB ?

I found on eBay the MDA/Herc/CGA/EGA to VGA converter box. My only problem is that it's a bit pricey at 115 USD plus 35 USD for shipping. I did find an RGB/CGA/EGA to VGA arcade converter board. However, I don't know if that would work with the Ruud tool.

As for my memory, I have been testing each 64/256 KB chip using a tester that I recently acquired. The tester is a DRAM tester. Please observe the link: https://multiretrodramtester.co.uk/index.html if interested. The tester uses different algorithms to test the chips. I have been using both March B- and C-. So far, the 256 KB chips have tested satisfactorily. I still have the 64 KB chips to test. If the 64 KB chips test successfully like the 256 KB chips, then I'll try the original ROM to see if I get the same error, namely the FPU and memory count.

 

[Ruud]

I did find an RGB/CGA/EGA to VGA arcade converter board. However, I don't know if that would work with the Ruud tool.

I don't see any reason why it should not work. The board converts CGA signals to VGA ones and there is no reason why this conversion would influence the RDR. The RDR just checks if the registers and RAM are on the right place. If so, it's a go. The RDR doesn't (and cannot) care for what happens after thos registers and RAM that's why RDR also works fine with Graphics Gremlin.

 

[Plasma]

Those "arcade" converters don't work out of the box because they require an analog RGB input (arcade CGA), not TTL (IBM CGA). You will need an additional adapter on the input side such as this or this.

EternalCRT is $15 less if you buy it directly from Monotech. Other options are RGBtoHDMI or MCE Blaster.

 

[alejack12001]

Those "arcade" converters don't work out of the box because they require an analog RGB input (arcade CGA), not TTL (IBM CGA). You will need an additional adapter on the input side such as this or this.

EternalCRT is $15 less if you buy it directly from Monotech. Other options are RGBtoHDMI or MCE Blaster.

Thank you, Plasma. I ordered the Monotech from their website, and yes, it was much lower than eBay. I finally can use my CGA card once the adapter comes.

 

[alejack12001]

Over the weekend, after testing the memory chips, I believe this 256-640 motherboard is a clone, not an IBM motherboard made for the 5160. The website minuszerodegrees shows a legitimate labeling for the 256-640 motherboard, which includes a barcode. My motherboard doesn’t have the barcode shown in the picture, Top View.jpg. Top View.jpg looks as it did when it was bought from eBay. Since purchase, I have replaced the CPU with V20 and installed FPU D8087-1. In addition, I replaced all the 64- and 256-KB chips to eliminate the possibility of chips being bad. During my inspection of the motherboard, I found botch wires as seen in the second picture labeled IMG_6109.jpg. The botch wires are strange, as it appears U18 and U19 Vcc and Vpp connect. I don’t know why. Pin 14 on both U18 and U19 is connected to pin 12 of SN74LS244N. This pin 12 appears to be an output port for the chip. This connectivity is confusing. Can someone explain what may be happening here? Would this configuration cause the errors seen and described?

 

[modem7]

Over the weekend, after testing the memory chips, I believe this 256-640 motherboard is a clone, not an IBM motherboard made for the 5160. The website minuszerodegrees shows a legitimate labeling for the 256-640 motherboard, which includes a barcode. My motherboard doesn’t have the barcode shown in the picture, Top View.jpg. Top View.jpg looks as it did when it was bought from eBay.

You have an IBM motherboard, not a clone. Periodically, during production, IBM made changes to various things. And that sometimes included labels.

That is why at [here], I have the heading of the first column in the table named, "Example markings". Yes, the "Example" is easy to miss.

During my inspection of the motherboard, I found botch wires as seen in the second picture labeled IMG_6109.jpg. The botch wires are strange, as it appears U18 and U19 Vcc and Vpp connect. I don’t know why. Pin 14 on both U18 and U19 is connected to pin 12 of SN74LS244N. This pin 12 appears to be an output port for the chip. This connectivity is confusing. Can someone explain what may be happening here?

Your motherboard is actually a 64-256KB motherboard that has been upgraded by IBM to a 256-640KB one.

Part of that upgrade was to rewire the ROM sockets. Prior to the rewiring, the circuitry was such that the sockets are for TMM23256/MK37000/MK38000 ROM's. The rewiring made the sockets suitable instead, for 27256/27C256 type ROM's. Even this ROM type rewiring was something that IBM changed: sometimes the wires are found on the component side of the PCB, and sometimes found on the solder side.

Would this configuration cause the errors seen and described?

No.

In addition, I replaced all the 64- and 256-KB chips to eliminate the possibility of chips being bad.

Earlier, I used "RAM subsystem". The RAM chips are only part of the RAM subsystem. I.e. There are other things on the motherboard that can result in only 256 KB on a 256-640K motherboard being presented.

But maybe 640 KB is being presented (the RAM subsystem is fully functional) and the issue is in the GLaBIOS build that you are using (for whatever reason, only looking for 256 KB). That is why at post #25, I asked the question of, "I know that you have the 01/10/86 dated BIOS ROM's for this 256-640KB motherboard. If you fit those ROM's, does the POST count up to 640 KB or 256 KB ?"
- If the count is up to 640 KB, the GLaBIOS build that you are using is the cause.
- If the count is up to 256 KB, there must be a problem on the motherboard, somewhere in the RAM subsystem.

Please do that test and report the result here. The result steers the diagnostic direction for us to take you in.

( To others with knowledge: Yes, obvious is that U84 is present and the jumper on E2 is present, but this kind of information to the OP at this time is unnecessary. Why? The test about to be done by the OP may reveal that the RAM subsystem to be fully functional. I think that things should be done efficiently, not wasting people's time. )

 

[alejack12001]

You have an IBM motherboard, not a clone. Periodically, during production, IBM made changes to various things. And that sometimes included labels.

That is why at [here], I have the heading of the first column in the table named, "Example markings". Yes, the "Example" is easy to miss.


Your motherboard is actually a 64-256KB motherboard that has been upgraded by IBM to a 256-640KB one.

Part of that upgrade was to rewire the ROM sockets. Prior to the rewiring, the circuitry was such that the sockets are for TMM23256/MK37000/MK38000 ROM's. The rewiring made the sockets suitable instead, for 27256/27C256 type ROM's. Even this ROM type rewiring was something that IBM changed: sometimes the wires are found on the component side of the PCB, and sometimes found on the solder side.


No.


Earlier, I used "RAM subsystem". The RAM chips are only part of the RAM subsystem. I.e. There are other things on the motherboard that can result in only 256 KB on a 256-640K motherboard being presented.

But maybe 640 KB is being presented (the RAM subsystem is fully functional) and the issue is in the GLaBIOS build that you are using (for whatever reason, only looking for 256 KB). That is why at post #25, I asked the question of, "I know that you have the 01/10/86 dated BIOS ROM's for this 256-640KB motherboard. If you fit those ROM's, does the POST count up to 640 KB or 256 KB ?"
- If the count is up to 640 KB, the GLaBIOS build that you are using is the cause.
- If the count is up to 256 KB, there must be a problem on the motherboard, somewhere in the RAM subsystem.

Please do that test and report the result here. The result steers the diagnostic direction for us to take you in.

( To others with knowledge: Yes, obvious is that U84 is present and the jumper on E2 is present, but this kind of information to the OP at this time is unnecessary. Why? The test about to be done by the OP may reveal that the RAM subsystem to be fully functional. I think that things should be done efficiently, not wasting people's time. )

Owners of the minuszerrodegrees website should consider a table showing possible labels, serial numbers, etc for these motherboards for retro builders, who can identify the IBM motherboards from the clones. In addition, the owners of the minuszerrodegrees website should feel free to use the motherboard I posted to add to the table.

I plan to insert the original ROM back into this 256-640 motherboard today to see what is displayed at boot. I'll see if I can make a picture and post results. In addition, I want to learn more about the RAM subsystem you mentioned.

 

[modem7]

Owners of the minuszerrodegrees website should consider a table showing possible labels, serial numbers, etc for these motherboards for retro builders, who can identify the IBM motherboards from the clones.

I have altered the web page at [here]. That should be enough. If they have to, people can always do an internet search to see what an IBM 5160 motherboard looks like.

In addition, the owners of the minuszerrodegrees website should feel free to use the motherboard I posted to add to the table.

Thanks. I added part of one photo to [here], a diagram that was used to show someone of various possible make-model replacements for their failed RAS delay line.

I plan to insert the original ROM back into this 256-640 motherboard today to see what is displayed at boot.

Let's see what happens.

In addition, I want to learn more about the RAM subsystem you mentioned.

1. RAM chips
2. Sockets hosting RAM chips
3. Certain traces and soldering on the motherboard
4. RAM addressing circuitry, shown at [here] for the 64-256KB motherboard, and [here] for the 256-640KB motherboard.
5. Circuitry that is involved in the generation of RAS and CAS, shown, with some overlap, at [here] and [here].
6. Switches 3 and 4 on switch bank SW1, which, on the IBM 5160, disable/enable RAM banks (via the U44 ROM shown at [here]).
7. Circuitry that is involved in RAM refresh, as shown at [here].

And some code in the POST is also part of the RAM subsystem, because that code sets up RAM refreshing.

 

[alejack12001]

I ran into some issues when I replaced the GLaBIOS with the standard ROM that came with the 256-640 motherboard. First, the RAM count was the same, 256 KB, so the error encountered with the GLaBIOS was not the fault of the ROM.

I had several other errors that were quite noticeable. The first was generating one long beep followed by two short beeps. According to the minuszerodegrees website, there is a conflict with my VGA card. I found my CGA card; however, I don’t recall where I bought the card. The bracket for the card is missing, and I believe it came from the seller that way. Is there a way that the MDA or Hercules bracket could be used as a mount for the CGA card? Of course, the CGA has a composite port.

I did receive the Monotech adapter. So, now I can use Ruud’s ROM to see what is going on. Lastly, I did encounter another problem: Position 1 of the SW1 is supposed to govern repeated POST testing. According to the minuszerodegrees website, the SW1 position 1 “off” is the normal setting, and if “on,” POST is cycled over and over. I have the SW1 position “off”; however, the motherboard kept cycling POST and memory count. In addition, the keyboard was locked out, so if I tried to strike F1 to jump to BASIC, nothing would happen other than continuing to cycle POST and memory. I didn’t get the Video issue or the cycling in GLaBIOS, but I was frozen out on my keyboard there as well. This motherboard may be in bad shape.

 

[modem7]

I ran into some issues when I replaced the GLaBIOS with the standard ROM that came with the 256-640 motherboard. First, the RAM count was the same, 256 KB, so the error encountered with the GLaBIOS was not the fault of the ROM.

Good. GLaBIOS quickly ruled out.

I had several other errors that were quite noticeable. The first was generating one long beep followed by two short beeps. According to the minuszerodegrees website, there is a conflict with my VGA card.

No. According to minuszerodegrees.net (specifically, the page at [here]), there is a video related problem. Many possible causes (including some cases of incorrect switch settings - more on that later).

Position 1 of the SW1 is supposed to govern repeated POST testing. According to the minuszerodegrees website, the SW1 position 1 “off” is the normal setting, and if “on,” POST is cycled over and over. I have the SW1 position “off”; however, the motherboard kept cycling POST and memory count.

Suggesting to me that the POST believes that switch 1 in SW1 is in the ON position. Various causes. More on that later.

I didn’t get the Video issue or the cycling in GLaBIOS, ...

It comes down to how the POST is written. For example, when I look at the source code for GLaBIOS, I see no code that 'loops' the POST if switch 1 in SW1 is read as ON.

In addition, the keyboard was locked out, ..

... in GLaBIOS, but I was frozen out on my keyboard there as well.

So we know that the keyboard related problem is a hardware one.

This motherboard may be in bad shape.

It is easy to think, "Lots of symptoms, and so there must be lots of problems", but that isn't always the case.

For example, on the 5160 motherboard, is an 8255 chip. That one chip is part of many functionalities:
- Sound to speaker
- Keyboard operation
- The reading of the switches in switch block SW1
- RAM parity error reporting

Of note is that the 8255 can partially fail, not completely fail, affecting only some of the above listed functionalities.

Based on the symptoms, I think that there has been partial failure, resulting in the POST getting wrong information about the OFF/ON state of the switches in switch block SW1, and affecting keyboard operation (assumption: good XT-class keyboard).

You now have Ruud's Diagnostic ROM (RDR) going. Part of RDR's screen output is a box that shows what software (POST, diagnostics, etc.) reads the switch states as.

Is that box correctly showing your SW1 settings ?

 

[alejack12001]

The keyboard I am using is the 84-key Model F that I had with the IBM 5150. I had a Model M keyboard with the keyboard adapter that Chuck(G) developed, which is sold by Tex Elect. I changed the keyboard to the Model F when I got 601 errors under the GLaBIOS test. The Model M adapter keyboard configuration works well with the 5150. I know the Model F works well with the 5150 and now with the 5160 because the 601 error went away.

If the chip 8255 or, in my case, 8255A-5 is defective, then I will have a real problem, as the chip is soldered to the motherboard. If the chip was programmed by burning it in rather than by software, then replacing it would be beyond my scope of repair. So, let's hope Ruud's diagnostic finds something else wrong rather than this chip being defective. Right now, I will have to let you know if Ruud’s ROM works. What I mean is shown below with the CGA to VGA adapter.

I have to see if either of the two CGA cards to work with in relation to the Monotech CGA to VGA adapter. The attached picture, IMG_6113.jpg (I am sorry the picture is dark.), shows the faceplate of the Monotech CGA/Hercules/MDA/EGA adapter to VGA. The writing on the case lists 4 or 8 sets of switch settings. Right now, the picture shows the switch settings for Hercules, which I need to set for CGA. There are two settings for CGA, one with scanlines and one without, and I assume the settings in the left column are separate from the amber, green, color, mono, etc settings in the right column, or are they tied together? No user manual comes with the adapter to explain the settings, only the webpage, which is not too descriptive. In addition, there is a menu button that deals with video card oddities, and the up/down buttons must scroll through different menu items. I inquired about the menu settings from a Monotech representative. Their representative told me that the menu settings are some sort of correction for odd video cards and promptly asked what card I would be using. My cards are CGA and are both made by IBM. The only difference is the PCB color, which is brown for one and green for the other. I don’t know if either one of these works.

I probably will not be able to address what I see from Ruud's ROM until I get this video issue resolved.

 

[Plasma]

For "regular" CGA output, set switches 1/2/3 down/off. Switch 4 doesn't matter.

 

[640KB]

The keyboard I am using is the 84-key Model F that I had with the IBM 5150. I had a Model M keyboard with the keyboard adapter that Chuck(G) developed, which is sold by Tex Elect. I changed the keyboard to the Model F when I got 601 errors under the GLaBIOS test. The Model M adapter keyboard configuration works well with the 5150. I know the Model F works well with the 5150 and now with the 5160 because the 601 error went away.

Hello! Just to clarify - with GLaBIOS are you getting a "Key" (2000) or "KB" (4000) error (I think 601 may be an IBM BIOS error code)? And does the keyboard actually work now with that model F or still does not work but the error is different?

 

[modem7]

My cards are CGA and are both made by IBM. The only difference is the PCB color, which is brown for one and green for the other. I don’t know if either one of these works.

I think that you would unlucky if both did not work.

Of note, Ruud's Diagnostic ROM (RDR) does not read the switches in SW1 in order to determine {MDA or CGA}. RDR will automatically detect the CGA card, then direct its screen output to the CGA card.

If the chip 8255 or, in my case, 8255A-5 is defective, then I will have a real problem, as the chip is soldered to the motherboard. If the chip was programmed by burning it in rather than by software, then replacing it would be beyond my scope of repair. So, let's hope Ruud's diagnostic finds something else wrong rather than this chip being defective.

Presently, in my opinion, the 8255A is the prime suspect. It is the type of chip that gets configured by software, after power is applied, according to what the programmer needs to the chip to do. One of the things that the IBM POST (and the POST in GLaBIOS) does, is to configure the chip. Any functional 8255A-5 (the -5 bit is important) that can be sourced will work; it gets soldered in, and that's that. Although, whenever I have replaced a faulty one, I have put in an IC socket between the chip and the motherboard. But yes, presently, we are 'jumping the gun'.

Right now, I will have to let you know if Ruud’s ROM works. What I mean is shown below with the CGA to VGA adapter.

Yes, I am interested to see whether or not the switches in SW1 are being read correctly.
Incorrect reading of switches 5 and 6 can explain the {1 long beep then 2 short beeps} issued by the IBM POST.

And interesting will be the 'Top of RAM' KB figure that RDR shows.

 

[alejack12001]

For "regular" CGA output, set switches 1/2/3 down/off. Switch 4 doesn't matter.

Thank you, Plasma. This is a big help to me to get the Ruud diagnostic to run on my current motherboard.