- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
Five Festive 5150 Boards (BOARD #1 Thread)
- Thread starter VeryVon
- Start date
Worth a try. Tried all the slots with the MDA card, no video.
Output to the LPT device is chaotic. I'm trying to figure out the best way to document.
Often it will get to checkpoint 1A or 1B, freeze or start outputting garbage. Doesn't seem to hang up on 8A or 8D. Cruises through reporting "0B"
Oh nice! I've been using the "TEST5066-Custom-With-Beep" ROM you made for me as I had it here. I'm honing in on the issue, I think it's going to be a 2-chip repair, maybe more. I'm starting to wish this board had been the "donor board"! haha
Speaker is fixed after replacing U26 (wasn't supplying CLK's to U34) and U63 which wasn't passing the pulses along to U95. Never been so delighted to hear a beep 
Ran a bunch more parallel/LPT monitoring runs, writing down the results. Most of the time it will hang at checkpoint 1A. Before I fixed the speaker, I see in my notes there was a 9A sent after 1A, but I don't get that now. It just hangs.
However once or twice it got as far as 2A, and reported the "AA" error.
However once or twice it got as far as 2A, and reported the "AA" error.
I took some readings down the ISA slot while RDR should be outputing video. I noticed that these signals are silent (neither HIGH nor LOW) on the logic probe:
OSC
DRQ1
DRQ3
D0-D7
OSC
DRQ1
DRQ3
D0-D7
modem7
10k Member
I'm sure that the vast majority of CGA cards use the OSC signal (14.318 MHz) . The IBM CGA card certainly does. OSC is generated by the 8284A chip.
DRQ1 is DMA request 1. There will only be activity on that if a card is using DMA channel 1.
DRQ3 is DMA request 3. There will only be activity on that if a card is using DMA channel 3.
Refer to the diagram at [here] D0 to D7 is the data bus. Whilst RDR is executing, bytes are going from the RDR ROM to the CPU. So there must be activity on the data bus whilst you are observing RDR executing via the parallel/LPT reader device.
modem7
10k Member
Instability. Based on my previous post, you may be replacing the 8284A chip, and that replacement may also remove the instability.
I put OSC on the scope, and it looks good on U11-12 and the ISA slot - 14.3 MHz. Not sure why my logic probe doesn't pick that up.
PCLK is 2.39 MHz, CLK's on the 8253 check out at 1.19 MHz. All signals look steady.
Do you think the 8253 might be the unstable one?
modem7
10k Member
All test equipment has limitations. For example, your particular make-model of logic probe may have an upper frequency limit of 5 MHz. I should have thought about that earlier.
No, not without some evidence. Any one of lots of chips could be the problem cause.
You have a logic analyser (LA). What you could do is try TEST5060, i.e. simple code that runs in a loop, monitoring the continual execution via your LA, looking for when execution goes 'pear shaped'. The misbehavior that you observe (e.g. corrupt address, e.g. corrupt data) then guides you to where probe next, etc.
This could be karma for something really nasty that you did in a former life.
Sounds good, thanks for path forward. I just checked all the voltages on the ISA bus, IOW, IOR, CLK, ALE, a few others vs a working board. Can't find anything obviously out of whack.
Love it yes. Or (inadvertently of course ) in this one!!
modem7
10k Member
Something else. Consider the possibility that the EEPROM containing RDR has gone 'flakey'. That has happened to me.
Good to know, I dropped one of the EEPROM's in the eraser so I can burn a new one.
I did some more legwork on ISA slot - think I may have found an issue - RESET DRV doesn't appear to be giving a proper reset signal to the MDA card. Going to have a look at the schematic and trace that one back...
Replaced U51, we have video now, phew!
I ran TEST5065, confirmed A0 to A19 are toggling/pulsing, XA0 to XA12 are toggling/pulsing.
I also tried some chip piggy back on U62 and U79, no change in RDR.
I also tried some chip piggy back on U62 and U79, no change in RDR.
Last edited:
I wired up the board with the LA. Data and Address buses look reasonable, but WE is nowhere to be found. I double checked it's connected to the correct probe by grounding it, and confirming it dropped LOW.
Going to trace back Write Enable, i'm guessing the signal crosses through the "Lightening Strike Zone" somewhere ... which is the lower right quarter of the board and some other patches near the cpu and south of the peripheral slots
Going to trace back Write Enable, i'm guessing the signal crosses through the "Lightening Strike Zone" somewhere ... which is the lower right quarter of the board and some other patches near the cpu and south of the peripheral slots
Last edited:
Ran another capture using TEST5060 and i'm seeing something odd, everything looks good except the first write Address out of each series of four operations is "BF" instead of "FF." Consistent, and happens every time:
modem7
10k Member
A problem on MA6.
You verified the address bus.
So, a supply (multiplexer) problem, or good supply but bad loading?
I was testing for a short between MA6 and a data line when I found one of the grabbers was creating a short between MA6 & D7. I'm not sure how that short was only in half the previous capture, but I was able to get a clean capture after I fixed that.
I'm going to run some more tests, because RDR is still failing on the first 2KB RAM test. I think the timer may have finally given up as well.