Fixing Five Festive 5150 Boards over the Holidays (BOARD #3 Thread)

[Malc]

But, the GQ- 4x works perfectly for good quality "normal " eproms for programming and reading.

Just not the 'OLD' Eproms

The trouble is that there are a lot of fake, refurbished, re-labelled eproms flooding the market and this is where all the troubles reside, not in the programmers.

I'm well aware of that and in my experience since owning / using my GQ-4x since 2010, For newer Eproms / EEproms it's been fine for what i have needed it for But for the older Eproms etc one could do a lot better than the GQ-4x which is why i own several old programmers.

 

[VeryVon]

Thanks for the sidebar and explanation for why an eprom may validate on the burner, but fail in-circuit. I'm still scratching my head how one image can work, and another fails, but I think i'll just call it a day move on to more reliable proms!

EDIT LATER on 1/14/2024: Eventually I found out that the MDM video card I was using was compatible with the old RDR, but not the new. This probably explains why one rom "worked" and the other didn't. In retrospect I should have kept the speaker connected or LPT reader to see activity without video (at this time I didn't have the LPT)

 

[modem7]

I'm still scratching my head how one image can work, and another fails, but I think i'll just call it a day move on to more reliable proms!

I wonder if the 'ruuds_diagnostic_rom_v4.3_8kb.bin' file got damaged on its way from my web site to your PC.
The MD5 hash expected for it is 9C056A45A7FEC06E14DBAAD2B039E842

And, obviously, when you move to the 32K size ROM's, you will need to switch to using the 32K sized BIN file.

 

[VeryVon]

Checks out ok. Ran this on the machine I have the burner hooked up to:

 

[modem7]

I know that you are waiting for a new type of ROM to arrive, and for a parallel/LPT monitoring device to arrive.

And you have RDR version 2022-12-12 operational. Had you have version 4.3 operational, I am sure that it will have shown all RAM bits in error, i.e. failure of the motherboard RAM subsystem. What you could do is, for now, proceed on the assumption that there is a failure of the motherboard RAM subsystem. Does that sound logical?

Even with RDR version 2022-12-12, what I expect is that when the 'first 2K RAM' check fails, that the RAM refresh mechanism is still operating in the background. Therefore, after the check fails, expected on the RAM chips in bank 0 is activity on the RAS pins and all address pins.

 

[modem7]

Even with RDR version 2022-12-12, what I expect is that when the 'first 2K RAM' check fails, that the RAM refresh mechanism is still operating in the background. Therefore, after the check fails, expected on the RAM chips in bank 0 is activity on the RAS pins and all address pins.

With the RAM refresh mechanism is still operating in the background, you can check some of the circuitry that generates CAS. Reference diagram at [here]. You could look for /CAS on pin 8 of U81. There will be no /CAS out of U47 because U47 is disabled during RAM refresh. Another signal to look for is the 'ADDR SEL' out of the delay line.

Beyond that, I could write some code-for-a-ROM that, in a loop, writes/reads address 00000. That will result in a signal on the CAS pin of the bank 0 RAM chips.

 

[VeryVon]

Sounds logical and thanks for the nudge, yes totally agree. I'll start looking at that circuitry. /CAS is indeed high:

 

[modem7]

Beyond that, I could write some code-for-a-ROM that, in a loop, writes/reads address 00000. That will result in a signal on the CAS pin of the bank 0 RAM chips.

It turns out that I have already done that. See TEST5060 at [here].

 

[VeryVon]

Ok, with TEST5060 I see activity on Din, Dout, /CAS and /WRITE, no change on the other pins or /CAS appearing where it shouldn't. I could put the logic analyzer on there to confirm timings.

 

[modem7]

Check also for the presence of the 'ADDR SEL' signal out of the delay line.

 

[modem7]

I could put the logic analyzer on there to confirm timings.

And also to verify the data.

Reference diagram at [here].
1. During the writes, verifying that 55 and AA are successfully going through U12 to the RAM chips.
2. During the reads, verifying that 55 and AA are read back from the RAM chips and successfully going through U12 to the data bus.

Regarding U12. A deeper level diagram is at [here]. During a motherboard RAM operation (read or write), expect the /G pin to go LOW (enabling U12), and the DIR pin to control the data direction (HIGH for a write, LOW for a read).

 

[VeryVon]

Check also for the presence of the 'ADDR SEL' signal out of the delay line.

Tap 3 is indeed active (as are all the others.) I'll check on the data.

 

[VeryVon]

After we debugged that first 5150 back when, I put a search on eBay and found a used Intronix Logic Analyzer which has come in handy on a few projects. Unfortunately that's the only good news I have.

I've setup a capture, but now I have no activity on the data bus (verified with the logic probe) and seemly random data on the address bus. I'm puzzled why it's gone silent. I disconnected the logic analyzer and re-tested with the logic probe, still no data there. Guess I'll have to backtrack now on the data bus?

 

[modem7]

I've setup a capture, but now I have no activity on the data bus (verified with the logic probe) and seemly random data on the address bus. I'm puzzled why it's gone silent. I disconnected the logic analyzer and re-tested with the logic probe, still no data there. Guess I'll have to backtrack now on the data bus?

Your capture shows that you are trying to mimic the logic analyser capture that I have in TEST5060.
In TEST5060.ZIP is a file named {TEST5060 - logic analyser capture - pins used.txt} which details the pins that I used.
And so when you write "address bus", you must mean 'memory address bus'. (MA0 through MA7)
And so when you write "data bus", you must mean 'memory data bus'. (MD0 through MD7)

 

[VeryVon]

Correct, I'm using the pins as defined in "TEST5060 - logic analyser capture - pins used.txt" I'll study those diagrams.

p.s. was there a theory of operation "bible" (other than the technical reference) written for the 5150/5160 line of computers? Analogous to something like the “Bunyard Manual” for TI-99.

I'm going to re-focus on U12

 

[VeryVon]

This morning with a fresh look I realized I hadn't populated bank 0 with DRAM chips during my logic capture. I put 9 known good 4164 chips in there and tried my old Ruud's version and this is what I have (see below.)

I think I didn't arrive at this result in the beginning because I was trying to use the board & diagnostic to find a good set of RAM from a bunch of extra RAM the previous collector gave me (presumably pulled from the five boards.) A bit of laziness on my part, and mislaid trust in software testing. Lesson learned, I should have gone for the good RAM in my existing 5150 multifunction card from the get-go!

And luckily we're doing more than one board, so hopefully ground covered here will carry over to the next board...

UPDATE: I've tried at least 3 different ROM sets and they all fail (the "Passed" ROMS in the screenshot below are interesting, because I'm pretty sure they were unpopulated on that run) So I'm going to peek around the external bus.

 

[VeryVon]

ROMS From the various boards. Board #4 was unpopulated.

 

[modem7]

I put a search on eBay and found a used Intronix Logic Analyzer which has come in handy on a few projects.

Sometimes, after seeing nothing or something unexpected on a trace, I discover that I had used the wrong wire, e.g. green with white tip instead of white with green tip.

p.s. was there a theory of operation "bible" (other than the technical reference) written for the 5150/5160 line of computers?

Many years ago, someone posted some pages from a book. A Zip file containing those pages is at [here]. From what I could see online, the book appeared to be named, 'Sams IBM PC Advanced Troubleshooting And Repair'.

... and tried my old Ruud's version and this is what I have (see below.)

Progress.

UPDATE: I've tried at least 3 different ROM sets and they all fail (the "Passed" ROMS in the screenshot below are interesting, because I'm pretty sure they were unpopulated on that run) So I'm going to peek around the external bus.

One of the problems with running old versions of software, is that the software can contain bugs that were fixed in later versions.
I think you can see where I am going with that.
Prior to a particular version (I cannot quickly find the version number), there was a bug that resulted in 'Check ROM at xxxxx' tests failing.
However, I see that some of yours are passing.
I will see if I can find some detail about the bug.

NOTE: If a ROM socket is unpopulated, the associated test might pass, it might fail.

( Even after the bug fix, on a 5150, the 'Check ROM at F4000' test is not expected to pass, because there is no ROM in socket U28. )

 

[modem7]

I will see if I can find some detail about the bug.

I put version 2022-12-12 onto my good 64KB-256KB 5150 motherboard. All of the 'Check ROM at xxxxx' tests failed.
I then upgraded to the next version, version V3.0, and with that, of the 'Check ROM at xxxxx' tests, only the F4000 one failed (expected because there is no ROM in the U28 socket.)

Another bug: The 'Check floppy controller' test will pass if there is no floppy controller fitted. That one didn't get fixed until version V3.2

Version V3.3 and later are mostly about adding improvements, e.g. detection of RAM addressing issues, RAM refresh test, slow RAM refresh test, etc.

 

[modem7]

ROMS From the various boards. Board #4 was unpopulated.

I see that the IBM part numbers on your various Cassette BASIC ROM's match with the numbered sets that I have in the 'Part numbers' section of [here].