Lots of cards like that for 64kb pc 5150

https://forum.vcfed.org/index.php?threads/d-l … o-needed.71678/

The card likely sold with 256k but could support 512k, my guess is it was fully populated and installed in a mismatched system.
Rarely half bad ram was used in duplicate but that is very unlikely.

A RTC is very likely but I haven’t gone through the ICs to see which are what.

The battery is indeed likely to be for the RTC function of this card. I suppose the M3000 chip is the RTC, and it is accessed using I/O ports. The card has the IO write and IO read signal connected on the ISA bus. The backside photo shows that a 2-pin component seems to hide below the M3000 chip, which might be the 32.768kHz crystal required for a typical RTC IC.

OK, it seems you get E9 back if nothing responds to the read request, 55 if you hit RAM or a ROM that happens to start with 55, and FF if something responded actively with FF. You see both the 55 area and the FF area moving with the DIP switches, so it is sensible to assume that you get working RAM from one 256K bank, and just FF from the second 256K bank. Furthermore, it is reasonable to assume that the 74LS245 is a driver chip that forwards data from the ISA bus to the card unless a read to the memory on the card or the RTC happens. In that case, the direction of the buffer is reversed and data from the card is forwarded from the card to the ISA bus.

Switch #1 is likely to choose between 41256 chips (256K per bank) and 4164 chips (64K per bank), and you seem to have discovered the meaning of switches 2 to 8 correctly. There seems to be a defect on the card that makes the second bank not work, so it always returns FF on reads. As TTL inputs (for example on the 74LS245) read "high" if nothing is driving the input, you would get FF if the 74LS245 is enabled to forward data from the card to the bus, but no RAM chips are enabled. I assume the card drives RAS to the memory chips on every memory cycle (possibly even on cycles that do not decode to the card), and drives CAS only on the selected bank. Under this assumption, refresh implementation is easy because you want to refresh both banks at the same time, and you just need RAS for that. So if every cycle drives RAS on both banks, you automatically get refresh affecting both banks without further logic. Looking at the traces on the back side, I see a trace that connects to CAS of some chips on the bank farther away from the slot bracket, but does not connect to CAS of the chips closer to the slot bracket. This seems to confirm my theory that bank selection is handled using CAS. Your symptom thus looks like the second bank does not get a proper CAS signal, which might be due to a broken trace or a defective decoder (likely one of the PLAs). If you happen to have a continuity tester, you can check whether the CAS pins of each banks are connected to some pin of the PLAs, but possibly the 74LS125 is used to buffer a PLA output to drive that many RAM chips. a single 74LS125 is good to buffer a common RAS signal, two CAS signals and the common WE signal (I've seen traces that confirm that WE is common between both banks).

Assuming you have a multimeter: I recommend you to buzz out the logic that should generate CAS for either bank. If everything looks fine, try whether you can detect a slight drop in voltage of the CAS signal of the selected bank when you repeatedly read a byte using basic in that bank. Obviously, a scope would be preferrable, but I wouldn't assume you have one or get one for a one-off test. If you can detect a change in average DC voltage level between a selected and an unselected bank, you can use the multimeter to test where the CAS signal for the second bank disappears.

There's a lot of tantaulm caps as well. Might be worth checking if any have internal shorts.

Edit

I see a lot of corrosion under the leaky battery. Removal, alklyline reversal, then trace checking is indicated.

wierd_w wrote on 2025-11-05, 20:37:

There's a lot of tantaulm caps as well. Might be worth checking if any have internal shorts.

I don't think they are tantalums. They are 100nF multilayer ceramic caps. In those days, it was usual to have one 100nF decoupling capacitor next to every IC. Usually they are yellowish brown (as on this card) or blue.

It only takes a few seconds to check against shorts.

And, that corroded battery still needs to come off. (Blech)

wierd_w wrote on 2025-11-05, 20:37:

I see a lot of corrosion under the leaky battery. Removal, alklyline reversal, then trace checking is indicated.

Indeed. Especially if my guess is correct that the 74LS125 is used as RAS/CAS/WE driver. That chip is directly next to the leaky battery, so if the battery leakage damaged some traces or vias, it's quite likely that RAM control signals are affected. And, as I already stated, the broken second 256K look like a broken CAS trace.

mkarcher wrote on 2025-11-05, 20:18:

The backside photo shows that a 2-pin component seems to hide below the M3000 chip, which might be the 32.768kHz crystal required for a typical RTC IC.

Indeed! I removed the IC from its socket and there's what looks like a crystal oscillator below it, see attached photo. (There's still some corrosion on the diode next to where the battery was. I'll clean that up too.) Good to know! I'll try various clock programs for it and see if I find one that sees an RTC.

mkarcher wrote on 2025-11-05, 20:18:

55 if you hit [...] a ROM that happens to start with 55

Doh, of course, option ROMs start with 55AA, so I should have tested with a different value.

mkarcher wrote on 2025-11-05, 20:18:

[very helpful explanation and tips]

Assuming you have a multimeter: I recommend you to buzz out the logic that should generate CAS for either bank. If everything looks fine, try whether you can detect a slight drop in voltage of the CAS signal of the selected bank when you repeatedly read a byte using basic in that bank. Obviously, a scope would be preferrable, but I wouldn't assume you have one or get one for a one-off test. If you can detect a change in average DC voltage level between a selected and an unselected bank, you can use the multimeter to test where the CAS signal for the second bank disappears.

I'll do that and report back!

A little update: I don't just want to fix the board, I want to understand completely how it works and then fix it, hopefully including the RTC. I have started buzzing out the traces on the board and putting the results in a KiCAD file. I learned a lot from that already and could also confirms that the 74LS245 bus transceiver is always enabled and buffers the data on the bus for the card. It reverses direction on an AND of two signals, one from the first PAL, and one from the second PAL, so its role is likely as you suspected, @mkarcher.

I have also employed a logic analyzer to see:
- the top 4 bits of the address on the ISA bus from one of the inputs to the 74LS283 full 4-bit adder
- RAS0, CAS0, RAS1 and CAS1 and A8 at the DRAM chips
- CLK to get a feeling that the sample rate is good enough

I captured these signals while a program was running that repeatedly reads the whole 1M of memory space byte-wise. The loop of 64k iterations, the max on an 8088 afaics, starts and ends at x8000h so that after the access to xffffh the access to (x+1)0000h immediately follows without other memory access due to code execution at the end of the loop. IRQ0 is masked so that the BIOS and DOS timer code doesn't pollute the capture. I'll attach the code when I get it off the XT a bit later.

In the capture on the first screenshot are visible from left to right:
- the RAS-only refresh - on both banks simultaneously
- the read of address 7FFFFh, which is the last working address. RAS and then CAS go active low.
- another RAS-only refresh
- the read of address 8000h, which is the first non-working address. Indeed, RAS goes low, but CAS stays high all the time. What a life!

The second screenshot shows a time when the memory read does not decode to the card. BA16-19 are 0000, so we're somewhere in the first 64K. The card sits at start address 40000h - 256K. It is visible that RAS is quiet except for the RAS-only refresh. So RAS is driven only when the address decodes to the card.

Also, I found a broken trace directly after the crystal oscillator. Turns out it's visible on the photo attached to the first post as well, but in the top-down view it looks very much like a via. I attached a close-up.

The damage on the PCB that broke the trace does look kind-of deliberate to me. Maybe they intentionally disabled the RTC and 256K and sold the card as a 256K card? Wouldn't be the first time something like that was done.

mbertheau2 wrote on 2025-11-12, 00:44:

The damage on the PCB that broke the trace does look kind-of deliberate to me. Maybe they intentionally disabled the RTC and 256K and sold the card as a 256K card? Wouldn't be the first time something like that was done.

I don't agree with that. If they wanted to sell a stripped down card, why leave it fully populated with the battery?

I'd guess that the card is damaged by a leaking battery.

mbertheau2 wrote on 2025-11-12, 00:44:

Also, I found a broken trace directly after the crystal oscillator. Turns out it's visible on the photo attached to the first post as well, but in the top-down view it looks very much like a via. I attached a close-up.

Please check whether the broken trace connects the crystal to the unpopulated C1 position. This may be an optional varicap to fine-tune the RTC clock speed. As C1 is not populated on your card, routing the clock there makes no sense, and could degrade the signal integrity if that trace works as antenna.

mbertheau2 wrote on 2025-11-12, 00:44:

the read of address 8000h, which is the first non-working address. Indeed, RAS goes low, but CAS stays high all the time. What a life!

Which confirms a broken CAS1 signal, as I suspected. But I was lucky, as RAS1 and RAS0 are separate as well. The same symptom would be visible with missing RAS1.

A short update:

- The CAS1 trace on the front side of the PCB, coming from the resistor network below the 74LS32, a quad 2-input OR, and going up to a via in the battery area, is indeed broken. When I bridged that temporarily, the whole 512 KB worked. One of the next things for me is to decide how I'll try and permanently fix this. It's going to be my first trace repair.
- The other broken trace directly after the crystal indeed goes to the unpopulated C1 position. Good educated guess, I guess!

I'm now tracing out the rest of the board to fully understand how it works.

One thing I already don't understand is why there are resistors on the card-internal address lines. The ISA bus address lines go to two 74LS157 ICs, which are quad 2-to-1 multiplexers. Based on a signal they select the first or second 8 bits of the address bus and put those on the lower 8 address lines of the DRAM ICs. But before that, they go through a resistor. Why?

The same with the two RAS and CAS lines: they go through a resistor before they go to the DRAM ICs. Why is that?

Thanks!

mbertheau2 wrote on 2025-11-27, 22:50:

One thing I already don't understand is why there are resistors on the card-internal address lines. The ISA bus address lines go to two 74LS157 ICs, which are quad 2-to-1 multiplexers. Based on a signal they select the first or second 8 bits of the address bus and put those on the lower 8 address lines of the DRAM ICs. But before that, they go through a resistor. Why?

The same with the two RAS and CAS lines: they go through a resistor before they go to the DRAM ICs. Why is that?

It's called "series termination", this is a method to dampen reflections. This is especially important on fast edge-triggered signals like /RAS and /CAS, as extra edges generated by overshoot and ringing can generate funny faults. Maybe they terminated the address lines the same way to make sure the address lines don't transition "too fast", but at the same speed as the RAS and CAS lines. As the resistor slows down charging the input capacitances of the RAM chips, it will introduce a small delay.

It looks as if the two 74157 devices have been replaced at some time - the date code dates them to 1993, whereas the rest of the board has devices from 1984/1985.
As previously noted they are used to multiplex the address lines.
I reckon the original devices were 74LS157 and got replaced with whatever was to hand.
74LS series have a lower propagation delay compared to the original 74.
That could be causing timing issues.
Might be worth changing them for LS157 devices (or even HCT157).

In my experience most designs used the same 74 family across the board - the only variations usually being around oscillator circuits, and then it was normally a 74S04.

mdog69 wrote on 2025-12-01, 13:58:

74LS series have a lower propagation delay compared to the original 74.
That could be causing timing issues.

I don't think replacing 74157 by 74LS157 will cause timing issues. I just looked at the data sheets for the National Semiconductors (rebranded to Fairchild) DM74157 and DM74LS157. The original TTL DM74157 has progataion delay specified at a load resistance of 400 ohms and a capacitance of 15pF, while the LS one has a specification at 2kOhm and 15pF. The specified propagation delays are identical with the LS chip driving a lighter DC load.

Schottky TTL chips are more efficient, that is they consume less power to operate at the same speed compared to standard TTL chips. There are two main series of Shottky based TTL logic, the LS series which aims to be approximately as fast as standard TTL at a considerably lower power consumption ("low power Schottky"), while the S series aims for maximum speed. In case of the 74S157, that chip is nearly twice as fast as the 74LS157 or the original 74157, but consumes even more power: The S chip is specified at 50mA typical (outputs unloaded), the original one at 30mA typical, and the LS one at around 10mA typical. The lower consumption at the same speed explains why you are unlikely to see the original 74 series if used for their logic function. As the original 74 series operated at higher signal currents, they were used a lot longer in applications that are more focussed on the "output driving" aspect than the "logic" aspect.

A small update: If the jumper in JP1 is in the bottom position, the card drives the /CARD SLCTD signal on the ISA bus, so that it'll work in Slot 8 on the XT motherboard. However, with the card in Slot 8 and the jumper in the bottom position, the BIOS counts the memory correctly, but the system hangs when booting PC-DOS 3.3, so.. yeah.

mbertheau2 wrote on 2025-12-08, 11:22:

A small update: If the jumper in JP1 is in the bottom position, the card drives the /CARD SLCTD signal on the ISA bus, so that it'll work in Slot 8 on the XT motherboard. However, with the card in Slot 8 and the jumper in the bottom position, the BIOS counts the memory correctly, but the system hangs when booting PC-DOS 3.3, so.. yeah.

If you could get one of the post cards that has a full memory check you could at least isolate what memory region(s) are broken

I worked on my first broken trace and got to continuity, yay!

I'm almost through with the schematics, and will look at the signals of the M3000 and the bottom PAL IC. It receives at least the lowest 10 address bits, the IO Write and IO Read as well as the Address Enable lines from the ISA bus. Three lines to from that PAL to the M3000. My plan is to read a bunch of I/O addresses with the CPU and see when something lights up around the M3000. That will hopefully give me a range of I/O addresses that the RTC chip responds to. Then with some trial and error, and looking at how other RTC chips are implemented, maybe I can figure out how to talk to it. It's interesting that the RTC chip has only 4 data lines connected to the data bus.

I watched this video before repairing the trace and found it helpful: https://www.youtube.com/watch?v=ref9JHUf-uw