5150 Rescue and Repair

[Oddsocks]

I can see why you are pleased with that.

So, what's going on with "however when I insert the MDA card in and power on, all I get is a very short high pitched and sometimes low pitched beep and nothing else so I'm not really sure what to make of that."
To me, it is now sounding like a situation of 'multiple variables were changed, and a resulting symptom attributed to the wrong changed variable'.

The first time I plugged in the MDA, was for use with the RDR - assuming that it's onboard RAM might be needed for things like serial access. This is when that occurred and before I stopped trusting the breadboard adapter. The RDR appeared to be executing as expected at the time (ie I got tones and relay click) as did the landmark ROM. I've since tried the MDA with the original 5150 ROM in the socket and I do not get the high or low pitched tone. However as expected still, the display doesn't work so the POST is failing somewhere - likely the RAM stil I guess

Agreed. Re the continuous beep. See my hypothesis at [here]. It sounds like you have one of the subject motherboards - with no U33, or a compromised U33, a continuous (or intermittent) tone is heard.

The symptoms sound exactly like what you describe in that article and potentially adding the MDA card while I was using the ROM adapter was preventing the ROM from being read, leading to that continuous tone also

 

[Oddsocks]

The BIOS chip on the DTC5150, a card designed for PC's and XT's, will not be inspecting the AT's CMOS configuration settings. I think it likely that the DTC5150's BIOS chip is discovering that on its control cable, there is a drive at 0 reporting as 'ready, and no drive at 1 reporting as ready, i.e. one drive is attached, and the BIOS consequently displays "1 HardDisk". If you disconnect the control cable, you may see "1701" instead (the DTC5150 expecting at least one drive connected to it).

The DTC5150 manuals do not indicate AT compatibility. There may be stability issues when the card is in an AT-class machine.

I shall try with the control cable removed and see if I see "1701" appear, I have the "2" variant of the card with BXD06. I did lower the AT bus frequency in the BIOS just in case, but as you say it may not be entirely compatible but it suggests to me it's not totally dead at least. The ST213 spins up and sounds OK at least and appears to be detected so that's a good sign also. Doesn't me the platters are good, but there doesn't seem to be any mechanical issues.

 

[Oddsocks]

So for the hard disk controller, I see no strings in the BIOS which says "PRESS A KEY TO REBOOT", so I suspect on my 486 it is actually booting from the ST213 and the message is coming from the MBR - maybe everything has been erased. So I'm 99% sure the HD controller works. The MDA card definately does. I also tried the piggyback method on the RAM chips in bank 0. No change. I know it doesn't prove too much as the chip I was using, I had no idea if it was working or not, so it was a bit of a hail mary. I've ordered a PCB for a ROM adapter which should help with the diagnostics

 

[Oddsocks]

Just an update on the current state. I've built a proper ROM adapter so I can now use an M27C64 for the BIOS and I've installed RDR 4.7 in it.

Finally with a serial card installed I see: 33 0 2 3 4 6 8 9 A t8A
Output to the terminal, which tells me it's executing all the way up to step 18 and then halts because it can't find an MDA card (makes sense). Note, it prints "t8A" rather than "8A" every time. Is this normal behaviour or could it indicative of a problem somewhere?

When I insert the MDA card, I get this: 33 0
This tells me it's trying to initialise the MDA card and just fails. Now, initially I'd be thinking the MDA card is fautly, however it works in my 486 with the 5151 so the card itself can't be that faulty. I don't have any actual CGA or EGA cards to try instead, although I have a couple of 16bit VGA cards which I'll try, I doubt they will work to provide the memory for RDR. To note, I've cleaned the MDA edge connector with both IPA and contact cleaner and I've tried every slot on the motherboard so it's probably not a contact issue with the slot.

 

[Oddsocks]

Swapped the ROM out to the Supersoft ROM and the MDA card and the 5151 fired up - this is repeatable with the SuperSoft ROM, but I never get any display with RDR or the original BIOS. One thing that is confusing me though, is it seems to be testing memory up to 640K but I don't know if that's because it's failing the memory refresh test. The second thing is it complains of a memory error at 00000 but claims the 16K critical region passed.

 

[Oddsocks]

• OK, for some reason SuperSoft was trying to detect up to 640K when the serial card was plugged in. Once I removed that it stopped trying to test beyond 64K which seems more normal
• After that the RAM tests looked a bit more reliable and I confirmed that Bit 7 in Bank 3 was faulty and indeed the fault moved wherever the chip did
• Second, it was saying bits 1 and 7 on bank 0 were faulty. I piggy-backed a chip from Bank 3 onto bit 7 and it fault disappeared
• I repeated the same on bit 1 and that fault disapppeared but now showed a fault on bit 0
• Piggy backed bit 0 with yet another chip and the test progressed much further now.
• So in short 3 faulty DRAM chips in bank 0 and 1 faulty one in bank 3

 

[Oddsocks]

And yet still nothing from the RDR or native BIOS which is really confusing...

 

[modem7]

Finally with a serial card installed I see: 33 0 2 3 4 6 8 9 A t8A
Output to the terminal, which tells me it's executing all the way up to step 18 and then halts because it can't find an MDA card (makes sense). Note, it prints "t8A" rather than "8A" every time. Is this normal behaviour or could it indicative of a problem somewhere?

At some point, I saw some strange 'extra' characters with one of my RS232-to-USB adapters, and adjusted the RDR code slightly to get rid of them. It may be connected with timing/latency of those adapters. Along those lines, I can see some comments that I added to the RDR source code. I would not be concerned about the 't'.

When I insert the MDA card, I get this: 33 0
This tells me it's trying to initialise the MDA card and just fails. Now, initially I'd be thinking the MDA card is fautly, however it works in my 486 with the 5151 so the card itself can't be that faulty.

That block of code simply assumes that either an MDA or CGA card is present, and outputs a bunch of bytes to various I/O addresses associated with both MDA and CGA cards. Those bytes initialise the MDA/CGA card, then "Set the correct video mode, and make the cursor invisible." The code does not read anything back from the MDA/CGA card.

That code was not causing your 5150 to 'fall over' when the MDA card was absent. So it appears that certain bytes/commands received by your MDA card are causing a problem. Partially faulty MDA card?

Note that the Supersoft/Landmark Diagnostic ROM (SLDR) maybe doing the video setup slightly differently. For example, it may test one byte in the address range of MDA video RAM, see the test pass, and from that do the video setup for MDA only.

As an experiment, via DM, I could send you a modified RDR, one that requires MDA only (i.e. does not sent bytes to CGA card ports).

The MDA card is the only card fitted to the motherboard ?

Out of curiosity, it this an IBM MDA card? I can see in earlier posts that I am referring to it as an IBM MDA card, but on reflection, I don't see you use "IBM" in regard to the MDA.

And yet still nothing from the RDR or native BIOS which is really confusing...

The SLDR is not known to detect RAM addressing problems (RAM chips, or related motherboard circuitry). For a while, we were seeing the occasional report of SLDR completely passing, but the known good IBM 5150 BIOS ROM 'appears dead'. Later, it was discovered that the POST in the IBM 5150 BIOS was failing the BASE 16KB RAM test because of a RAM addressing problem, and the POST simply halting the CPU (no video nor audible output of the failure).

And so it is a pity that you do not have RDR up and running, because the later versions will detect most RAM addressing problems.

But what you could try is TEST5099 at [here].

 

[modem7]

OK, for some reason SuperSoft was trying to detect up to 640K when the serial card was plugged in. Once I removed that it stopped trying to test beyond 64K which seems more normal

I have seen something similar, but it was adding/moving the IBM floppy controller card that changed the behaviour.

 

[Oddsocks]

At some point, I saw some strange 'extra' characters with one of my RS232-to-USB adapters, and adjusted the RDR code slightly to get rid of them. It may be connected with timing/latency of those adapters. Along those lines, I can see some comments that I added to the RDR source code. I would not be concerned about the 't'.


That block of code simply assumes that either an MDA or CGA card is present, and outputs a bunch of bytes to various I/O addresses associated with both MDA and CGA cards. Those bytes initialise the MDA/CGA card, then "Set the correct video mode, and make the cursor invisible." The code does not read anything back from the MDA/CGA card.

That code was not causing your 5150 to 'fall over' when the MDA card was absent. So it appears that certain bytes/commands received by your MDA card are causing a problem. Partially faulty MDA card?

It may be partially faulty as you say, all I can state is that it works in the 486 I have when using Monochrome in the BIOS and appears to work with the Supersoft ROM, yet not the original BIOS or RDR. Of course those won't be exhaustive tests at all. Do you know if the SuperSoft and RDR ROM both make use of the character ROM on the card? I suspect they both totally would.

Note that the Supersoft/Landmark Diagnostic ROM (SLDR) maybe doing the video setup slightly differently. For example, it may test one byte in the address range of MDA video RAM, see the test pass, and from that do the video setup for MDA only.

As an experiment, via DM, I could send you a modified RDR, one that requires MDA only (i.e. does not sent bytes to CGA card ports).

That would be fantastic if you could. I feel I am so close to having a working system - once the DRAM chips are replaced of course which I'm the process of removing and adding sockets.

The MDA card is the only card fitted to the motherboard ?

Yes correct, it's the only card fitted now - once I removed the serial card which was making SuperSoft attempt 640K RAM tests.

Out of curiosity, it this an IBM MDA card? I can see in earlier posts that I am referring to it as an IBM MDA card, but on reflection, I don't see you use "IBM" in regard to the MDA.

Oh I've no doubt it's an original IBM MDA card, it certainly looks like every picture of an original IBM MDA card I've seen, except the PCB colour can vary it seems, but I'm more than happy to post a photo if you'd like?

The SLDR is not known to detect RAM addressing problems (RAM chips, or related motherboard circuitry). For a while, we were seeing the occasional report of SLDR completely passing, but the known good IBM 5150 BIOS ROM 'appears dead'. Later, it was discovered that the POST in the IBM 5150 BIOS was failing the BASE 16KB RAM test because of a RAM addressing problem, and the POST simply halting the CPU (no video nor audible output of the failure).

And so it is a pity that you do not have RDR up and running, because the later versions will detect most RAM addressing problems.

Yes I did notice your documentation was very specific about RDR being able to detect RAM addressing issues, which is another reason I'd love to get it up and running

But what you could try is TEST5099 at [here].

Thank you, I will try that out once I've removed the faulty chips in bank 0 and add sockets.

 

[Oddsocks]

I should also add, that the U28 test fails sometimes and passes other times, which considering it's empty is also confusing, but perhaps alludes to an addressing issue

 

[modem7]

I should also add, that the U28 test fails sometimes and passes other times, which considering it's empty is also confusing, but perhaps alludes to an addressing issue

I have seen that behaviour myself. With no U28 in place, when a read of a motherboard address corresponding to U28 is done, there is nothing driving a voltage onto the external address bus. The byte read can vary from motherboard to motherboard. More on the situation follows (comments that I have put into the RDR source code). But what is also sometimes seen, is that for a particular motherboard, the byte read back can vary, and if that happens when RDR reads all of the address range of U28, the 8-bit checksum will be non-zero and accordingly, the U28 test ("Check ROM at F4000") will fail.

; ****************************************************************************
; Check the passed 8 KB sized ROM.
;
; Primarily, we are looking for the 8-bit checksum being 00.
;
; However, if that is the only thing we did, empty ROM sockets could pass.
; E.g. Motherboard #1 returns FF reading an empty ROM socket. 8 KB of FF has an 8-bit checksum of 00.
; E.g. Motherboard #1 returns FE reading an empty ROM socket. 8 KB of FE has an 8-bit checksum of 00.
; E.g. Motherboard #1 returns FC reading an empty ROM socket. 8 KB of FC has an 8-bit checksum of 00.
;
; BTW. I have IBM 51xx motherboards that read FC, FE, and FF. Who knows what other variations there are.
;
; Ideally, we want empty ROM sockets to show as FAILED.
;
; Note that identifying an empty ROM socket cannot always be determined by seeing if ALL bytes of the ROM are the same.
; An example is the IBM 62X0819 motherboard ROM (32 KB) for the IBM 5160.
; The second and third 8 KB blocks of that 32 KB ROM contain nothing but CC (also having an 8-bit checksum of 00).
;
; SUMMARY: There is no foolproof way of determining an empty ROM socket.
;
; But a compromise is possible.
;
; Fail the test if either of the following are true:
; Failure criterion #1: The 8-bit checksum is not 00; or
; Failure criterion #2: All bytes are identical, AND, the byte is in [FC to FF].
;
; INPUTS: - DI = start of 8 KB range (e.g. for F400:0000, passed is F400).
;
; OUTPUTS: Carry flag, clear (NC) = SUCCESS, set (C) = ERROR
;
; DESTROYS: AX, CX, DX
;
; ****************************************************************************

 

[modem7]

Do you know if the SuperSoft and RDR ROM both make use of the character ROM on the card? I suspect they both totally would.

Both SLDR and RDR display characters on screen by writing bytes directly to video RAM.
For example, on an MDA card, to put a '3' in the top-left corner, the ASCII byte for '3' is written to address B0000, and the attribute byte of 7 is written to the following address.

 

[modem7]

It may be partially faulty as you say, all I can state is that it works in the 486 I have when using Monochrome in the BIOS and appears to work with the Supersoft ROM, yet not the original BIOS or RDR. Of course those won't be exhaustive tests at all.

Some kind of 5150 motherboard problem is also a possibility.

Oh I've no doubt it's an original IBM MDA card, it certainly looks like every picture of an original IBM MDA card I've seen, except the PCB colour can vary it seems, but I'm more than happy to post a photo if you'd like?

I trust you.

Back at post #9, in regard to the use of the SLDR, you wrote, "If I plug in the MDA card, it immediately fails on the first test, 1 Hi/Lo and actually a long beep I would call it." I normally do not have a speaker connected when I run SLDR. I will try the {5150 motherboard + IBM MDA + SLDR + speaker} combination, seeing if I hear the beep pattern that you do.

That would be fantastic if you could.

I will get onto that.

 

[modem7]

Back at post #9, in regard to the use of the SLDR, you wrote, "If I plug in the MDA card, it immediately fails on the first test, 1 Hi/Lo and actually a long beep I would call it." I normally do not have a speaker connected when I run SLDR. I will try the {5150 motherboard + IBM MDA + SLDR + speaker} combination, seeing if I hear the beep pattern that you do.

I brought out a 5150 motherboard of type 16KB-64KB. I plugged in an IBM MDA card, and PSU. I attached a speaker. I put in the SLDR. Nothing extra.

I removed a RAM chip from bank 0, in order to verify speaker operation.

At power-on, SLDR screen output appeared, but no speaker beeps. Later, beeps happened when the SLDR failed the 16K CRITICAL MEMORY REGION test.

I put the RAM chip back in, then executed SLDR again. And again, no beeps at the start-up of SLDR. Beeps happened later at the keyboard test (because no keyboard present).

 

[modem7]

To my astonishment, I experienced what you do.

SLDR with IBM MDA = Works
RDR with IBM MDA = Something wrong during checkpoint 0 <----------- Why ???

Using a third party MDA card instead:

SLDR with third party MDA = Works
RDR with third party MDA = Works <----------- So what is special about the IBM MDA !!

It has been quite a while since I tested RDR using an IBM MDA. These days, I use a third party MDA. So, at some point, I had made a change to RDR that caused a problem if the IBM MDA was used.

I disassembled SLDR to see what it was doing differently to RDR in regard to MDA initialisation. I could see a difference. I could see that SLDR, before sending the initialisation table to the 6845's index register, was sending 1 to the 'CRT control port'. I looked at IBM's document for their MDA card and found:

QUOTE:


So I modified RDR to output a 1 to the 'CRT control port', before the sending of the initialisation table to the 6845's index register. But to my surprise, that didn't fix the problem.

Then it dawned on me that RDR was actually interacting with the IBM MDA before RDR was sending 1 to the 'CRT control port'. Earlier, RDR sends bytes to the parallel port on the IBM MDA.

I moved the 'send 1 to the CRT control port' code to before the code that sends bytes to the IBM MDA's parallel port, and that resolved the problem.

And so I need to release a new version of RDR. But for now, I will DM to you a modified RDR 4.7

 

[Oddsocks]

To my astonishment, I experienced what you do.

SLDR with IBM MDA = Works
RDR with IBM MDA = Something wrong during checkpoint 0 <----------- Why ???

Well that's absolutely fascinating and helps swing in the direction of the MDA not being faulty at least

Then it dawned on me that RDR was actually interacting with the IBM MDA before RDR was sending 1 to the 'CRT control port'. Earlier, RDR sends bytes to the parallel port on the IBM MDA.

I moved the 'send 1 to the CRT control port' code to before the code that sends bytes to the IBM MDA's parallel port, and that resolved the problem.

And so I need to release a new version of RDR. But for now, I will DM to you a modified RDR 4.7

That is truly astonishing and an awesome find. I'm very much looking forward to testing it out.

I spent the entire day removing the 3 faulty DRAM chips in bank 0 which was absolutely painful to say the least. Put sockets in their place and added the memory to them that I used for piggy-packing. Rather annoyingly now I get a failure at 5040 (all bits) and it simply loops on address 4000 saying all bits have failed. I've triple double checked my work and don't see anything which stands out as a problem.

Thank you very much, I will try the updated RDR and let you know the outcome.

 

[Oddsocks]

MZD - check this out. What a sight for sore eyes.

 

[modem7]

I spent the entire day removing the 3 faulty DRAM chips in bank 0 which was absolutely painful to say the least.

Which hints to me your level of soldering skill.

Rather annoyingly now I get a failure at 5040 (all bits) and it simply loops on address 4000 saying all bits have failed. I've triple double checked my work and don't see anything which stands out as a problem.

An incorrect failure address of 5040 being reported by the SLDR is known of.

MZD - check this out. What a sight for sore eyes.

Excellent.

Considerations:
- Faulty RAM chips.
- Partially faulty U12 (see diagram at [here]).
- Bad soldering / damaged PCB,

 

[Oddsocks]

Which hints to me your level of soldering skill.


An incorrect failure address of 5040 being reported by the SLDR is known of.


Excellent.

Considerations:
- Faulty RAM chips.
- Partially faulty U12 (see diagram at [here]).
- Bad soldering / damaged PCB,

Just an update as I won't have much time to work on it now for a couple of weeks but this thread is serving as a bit of a handy journal too . I've built a DRAM tester and it's confirmed that the 3 x 4116 chips I pulled from bank 0 and the one from bank 3 are faulty. I've also tested the remaining socketed chips and they report as good - including the 3 socketed replacements borrowed from bank 3 and placed bank 0 - (which RDR is now saying are faulty). I did have to install some bodge wires sadly but all the continuity checks out with regards to the other RAM banks but of course there's always the possibility of I've either made a mistake or inadvertently damaged something else. U12 I can actually test externally and even have a replacement, but of course would require desoldering from the board which I'm not in a hurry to do at this point. But if anyone is aware of a specific technique for desoldering the DRAM chips on the 5150 I'd love to hear it, as trying everything from fresh solder, to braid and flux to using the desoldering gun I did struggle to find a technique that worked consistently on every pin