I got stuck trying to fix this 40 year old RAM card (AST MegaPlus II)

A man with one mem checker is always certain. A man with two mem checkers can never be certain.

A poem for you for 44:25 Tiger got to hunt, bird got to fly; Man got to sit and wonder 'why, why, why?' Tiger got to sleep, bird got to land; Man got to tell himself he understand. -Kurt Vonnegut, 1963

Your channel is awesome - your passion cannot be measured with enthusiasm off the charts. I was great you caught your mistake and took the time to admit it. Thanks for resurrecting older hardware for the current generation to see where we used to be with computers!

Hi Adrian -- I haven't watched this video in its entirety yet, so you may have discounted this already (or fixed the issue) but -- a few weeks ago I was trying to get an AST Advantage memory expansion card working on a 286 and had inconsistent memory check fails. My issue actually boiled down to a faulty resistor pack -- it had failed internally (looked fine) so that the resistance between the ram chips and the LS logic chips was wrong for one of the bits. It took a while to track down -- first time I've ever seen a bad resistor pack. I replaced the packs and card worked perfectly. ANYWAY, easy check might be to ohm out between the LS chips and the ram via the resistor packs and make sure all resistances are legit. Always love the content!! Cheers!

My money's on the addressing logic on the card. The output from debug (42:48) shows a marked difference between sections 5000:0000-5000:003F and 5000:0040 onwards. That's not at all what I'd expect to see when examining uninitialized RAM. Who knows what we're actually looking at (or where). The PROM is probably the most obvious suspect, so if it could be dumped and recreated that would be ideal, or even just dumped repeatedly to see if it's flaky. But besides that, my next step would probably be to probe the RAS/CAS and data lines on the various memory chips while accessing the RAM to see if the levels look OK, and if the right chips are even being selected. Then repeat that exercise but with the probe directly on the ISA bus. Addendum: Probing RAS should show whether or not the DRAM is being refreshed. It is my understanding that on the original PC/XT/AT, the refresh signal is provided by the motherboard via the ISA bus. Bits semi-randomly flipping could be the result of RAM not being refreshed.

1) try booting from floppy without XTIDE installed just to rule it out. 2) do you have anything 386+ that can employ this card? if so, try memtest86+ 4.1 or lower. 3) actually do you have any other system to test this card in? 4) it was you who taught us all to look at the scope before swapping chips around, please use your own advice! Look for: unstable voltages, unstable clock signals, strangle logical levels, the stuff you always check. If replacing S/LS/ALS changes the outcome you most definitely need to look at logic levels and voltages! 5) Can you dump the addressing ROM - the one you first suspected to be bad - and check it dumps the same every time?

Something I noticed which might be worth investigating: When checking the contents of RAM from a particular starting segment, like 5000: or 6000:, the initial 64 bytes read from each block of 128 bytes tended to be fine but then the following 64 bytes would be where most of the problems were, and this pattern continued as more of the RAM was read in chunks. So, 5000:0000~5000:003F would be mostly good but 5000:0040~5000:007F would be where most of the bad bits were, then 5000:0080~5000:00BF would be mostly good but 5000:00C0~5000:00FF would have a lot of bad bits. I'm curious if anything important could be learned about the problem by starting the 128-byte read 64 bytes forward, such as specifically reading out 5000:0040~5000:00BF. A part of me almost feels like that might reveal a refresh, voltage, or capacitor problem...?

Amazing in-depth repair without "throwing components at the board" as usual! I look forward to the next part, assuming there is one :) Thank you!

Hi Adrian, I checked the schematics as well. Something suspicious is that, like others have already mentioned, the first 64 bytes are always correct. You also mentioned that only the 74F245 makes a difference and that you suspect some timing issues. I would take a closer look at the CAS/RAS enable generator part of the circuit. This is U66. This IC is a logic delay module. My suspicion is, that this part of the circuit might be problematic and generate unstable timings for adress multiplexing. This might cause the memory ics to behave in a strange way. I'm not an expert. This is just a guess from my side. Probing RAS and CAS as well as the address bus might be worth a try to verify that this is not the issue. Another thing to verify is, that the refresh is actually working. Maybe the ram test passes because it checks the previous value before the data degrades too much due to the lack of a refresh. You should be able to probe this at U10 and check if U48 is passing A0-7 to the 4164 while U49 is tri-stated.

You always say “without further ado” and the cut to your opening montage, otherwise known as “ado” lol. You’re the best! Love your shows! Good thing we aren’t neighbors because id be at your house everyday!😂

Had almost exactly this problem years ago - a DMA transfer from the floppy disk failed because it was using a memory address that was also used by a peripheral card for IO. . So the IO select line had long gone after reading data from the disk, but was still enabled on the crap after market card due to decode delays. So as the PC attempted to DMA into its memory, the peripheral card said 'hey, that's me' and write two FF bytes on the bus. I would look closely at any IO address decodes on the card. Faster logic might improve it. Also try changing IO addresses on the card. It may not be the RAM that is then= issue anymore, it may be the I/O that is interfering and grabbing the bus as e.g. the lower memory addresses hit the sort of 200 hex area of the IO. In my case we did everything and the issue only appeared when reading from floppy using DMA. A file was read with two corrupted bytes. Once up and running the problem never appeared. Back then there were some very inexperienced digital designers cascading address decode chips resulting in very very long delays. But modern fast chips should fix it, also cooling the board might work

To me it looks like a DRAM refresh issue. Given the memcheck utility passed, it probably read back the values immediately after writing them, so the value likely persisted long enough for that to work. But on a human timescale, bit rot from incorrect refresh would look very much like what you’re seeing (random bit errors). Just a thought anyway. Love your content and debugging skills!

The fact that behavior changes, based on logic family, and is intermittent, suggests that some logic (or trace) on that RAM board is only MOSTLY dead. I suggest checking the select logic signals with a scope and look for suspect voltage levels or unusually slow transition times (see IC datasheet). One approach could be to pick a logic IC, like that LS245, and trigger the scope on output enables, while looking at data input. Measure timing between output enable, and data input transition. IC's datasheet will list minimum input hold time required before output-enable. If a signal looks healthy, but timing is too tight, that could indicate that the problem is farther up-stream. Excellent work so far! Your tenacity is inspiring!

That´s a headscratcher for sure! The 7643 PROM seems to be doing very straightforward address decoding. Outputs O1-O3 select one of 8 RAM banks (4 of which are on the optional MEGAPACK daughter card). Output O4 is a general enable signal for the whole card. O4 is gated through U64, what that does is making sure the card only tries to use the optional 4 RAM banks if the Megapack is installed. If there is a Mepapack it will pull signal "MP" low, which allows the card to be enabled when O3 is active (meaning one of banks 3-7 ia selected). This gated O4 output from the PROM is what enables the LS245 transceiver, it should be enabled whenever an address in the card's range appears on the bus. The fact that the card does anything at all makes me think that the 7643 PROM and U64 are fine... What I am wondering, could it be that the XT clone, when reading the RAM, needs the data to remain on the bus for a short while after MEMR goes high again at the end of the read cycle? As soon as MEMR goes high, the 245 latch will switch direction, removing the RAM data from the bus. The motherboard choking on that is the only reason I can think of why different speed grade 245s would show different behavior..

Ahh that Sony Trinitron in the background. I used to have 15 inch model. Such a nice monitor.

I'll add my 2 cents as well. Summarizing other's comments amongst my own. Change video card, perhaps to a hercules/mono one, do not use the XT IDE, us an actual floppy drive. Do ensure it's not running in turbo mode (BIOS says it's a turbo system). On that floppy, boot an earlier version of dos, I'd recommend something at least below 4.0. Then use older version of memtest (or later that supports it) under that for really good test of the memory. Lastly, try another PC or XT system entirely. Yes, this was long but I enjoyed all of it and would even enjoy a followup, trying the most likely scenarios proposed here already.

Awh, I love watching you go through the boxes.. I am a fan of long format videos though.. must my opinion.

[25:20] Notice that when the 5000:0 ram bank was supposed to be disabled, there were still some FD and FE bytes! [51:41] Again, disabled, but notice some text glitches. The important thing is that both sides are done with separate reads. The left side got all FF, but the right side got a few FD! ('}') [32:47] Actually, if you can get a good read of that Motorola PROM chip, it should be possible to program a GAL chip to do its function (thankfully the outputs are all on the high side of the chip!) Or it would be possible, if there was such a thing as an 18-pin GAL chip! But all is not lost. Pin 8 is ground, so you could use a 16-pin chip if you lose pin 10. Which is, uh, grounded. So it may be possible to program a GAL16V8 to fit into all but the bottom two pins (9, 10). Of course that chip probably wasn't the problem, but it would still be good to know what functions it is trying to generate so that another board could be repaired. And you still didn't try doing anything with that 74S00. And as others have pointed out, you didn't use an oscilloscope at all.

Why not try the card on a different board? I have no intention of working on the older boards, but this video, brought back memories of how crazy making the switch selection was, in terms of getting the cards functioning properly.

Thank you for all your work making your videos. You have a great way of showing trouble shooting techniques. I found during my career not many people have that ability. I sure wish I'd had some of the tools we have today like the infrared camera I recently bought. What an amazing tool. Thanks to your videos I now think I can try and fix an old IMASI 8080 computer I have.