Hello all,
Long time annoyance, first time contributor.
As some of you may know, I have an early Apple III (128K; 12V RAM board) that has suffered at the teeny little hands of rodents. I've gotten the machine working but it appears that I have bad memory (quelle surprise.)
To test the memory, I used a 4116 tester from eBay and a little adapter board that I whipped up; you test the MK4332 as "one 4116," then flip the switch and test it as the "other 4116." If either fails, you know that half of the 4332 is bad.
It's terrible, and it barely fits in the socket, and switching banks is annoying, but it worked.
Based on this test, I've determined that 7 out of the 16 MK4332 RAM chips have packed it in, and an eighth is extremely marginal (it does not retain data for the maximum refresh interval.)
There's a couple options for replacing these, and I started burning my fingers by stacking two 4164s precariously, but I didn't want to use up 14 to 16 4164s for this project. Actually, it takes me about a half an hour to make one, and I decided I would rather use that time to learn something.
Despite not knowing anything about DRAM addressing, the Apple III's memory timing, or even how the Apple III memory map and page switching works, I figured I could do the same thing.
I built this module that latches in the row address using a '573 (when RAS is asserted) and then chip-selects the entire mess when CAS is asserted. To test this, I used Logisim Evolution. It seemed to work there, although I am fully willing to admit I don't know what I am doing in it.
As far as I know, this is the first design of its kind for the Apple III, but I would love to find out that someone else already solved this.
Everything I do is open-source; you can look at the entire project here on Codeberg. It's like GitHub for hippies, you'll love it.
At the moment, I have just now run this sucker in my Apple III, and I've had mixed success.
The initial "Diagnostic RAM" screen seems to be very happy about it (showing "all good,") but then the system quickly moves to a scrambled video screen and back to a "Diagnostic RAM" screen showing that all of the chips covered by this module are now "bad."
Please ignore the "A/D" complaint; that popped up at some point recently and I've not bothered to look into it because I'm not using a joystick or other analogue device yet. I suspect a socket has bonked out or something is just making bad contact. We'll cross that bridge in a future thread.
Similarly, the Confidence Program's RAM tester rejects the entire thing as "BAD MEMORY" almost immediately, without giving me any useful information.
Obviously, the high-rez video modes don't display properly, whereas before they were just really ugly with missing tiles.
Based on this behaviour, I am suspecting that I've screwed up the latching somehow and things "sort of work" the first time, but don't reset properly, and subsequent tests over the same cell then fail.
Getting deep knowledge of the Apple III out of the internet seems pretty difficult, so I'm hoping that someone will stumble upon this and give me some answers before I figure out what I wired up wrong here. It would be really nice to have an inexpensive open-source replacement to get more 12-volt Apple IIIs back on the road.
I don't have a lot of time to debug this for at least the next week or so, but it would be nice if someone who understands DRAM addressing a little better would give me a schematic review (you can see the PDF attached below) and see if I simply did something stupid.
It's not beyond me: I hooked up a 245's DIR pin backward the other day and tried to pan-fry a Raspberry Pi Pico on a different project.
Thanks for reading this ramble! I'll reply to this thread as soon as I make any progress (whether upwards or downwards.)
Long time annoyance, first time contributor.
As some of you may know, I have an early Apple III (128K; 12V RAM board) that has suffered at the teeny little hands of rodents. I've gotten the machine working but it appears that I have bad memory (quelle surprise.)
El Problema
As you may already know, the 32Kx1 MK4332 chips on the Apple III 128K RAM board are actually two 16Kx1 4116s on the same package. This means that testing them is difficult, and replacing them is challenging.To test the memory, I used a 4116 tester from eBay and a little adapter board that I whipped up; you test the MK4332 as "one 4116," then flip the switch and test it as the "other 4116." If either fails, you know that half of the 4332 is bad.
It's terrible, and it barely fits in the socket, and switching banks is annoying, but it worked.
Based on this test, I've determined that 7 out of the 16 MK4332 RAM chips have packed it in, and an eighth is extremely marginal (it does not retain data for the maximum refresh interval.)
There's a couple options for replacing these, and I started burning my fingers by stacking two 4164s precariously, but I didn't want to use up 14 to 16 4164s for this project. Actually, it takes me about a half an hour to make one, and I decided I would rather use that time to learn something.
La Solución
The Sinclair Spectrum 48K has a similar problem with its notoriously flaky banks of 4116s; triple-voltage RAMs appear to be long-term unreliable at the best of times, and Sinclair probably got them out of a dump or something. So a lot of folks "on the Spectrum" have been building these 8x4116 "modules" that replace a chunk of them in one shot, routing the whole mess to a larger static RAM chip like a 62256.Despite not knowing anything about DRAM addressing, the Apple III's memory timing, or even how the Apple III memory map and page switching works, I figured I could do the same thing.
I built this module that latches in the row address using a '573 (when RAS is asserted) and then chip-selects the entire mess when CAS is asserted. To test this, I used Logisim Evolution. It seemed to work there, although I am fully willing to admit I don't know what I am doing in it.
As far as I know, this is the first design of its kind for the Apple III, but I would love to find out that someone else already solved this.
Everything I do is open-source; you can look at the entire project here on Codeberg. It's like GitHub for hippies, you'll love it.
El Progreso
At the moment, I have just now run this sucker in my Apple III, and I've had mixed success.
The initial "Diagnostic RAM" screen seems to be very happy about it (showing "all good,") but then the system quickly moves to a scrambled video screen and back to a "Diagnostic RAM" screen showing that all of the chips covered by this module are now "bad."
Please ignore the "A/D" complaint; that popped up at some point recently and I've not bothered to look into it because I'm not using a joystick or other analogue device yet. I suspect a socket has bonked out or something is just making bad contact. We'll cross that bridge in a future thread.
Similarly, the Confidence Program's RAM tester rejects the entire thing as "BAD MEMORY" almost immediately, without giving me any useful information.
Obviously, the high-rez video modes don't display properly, whereas before they were just really ugly with missing tiles.
Based on this behaviour, I am suspecting that I've screwed up the latching somehow and things "sort of work" the first time, but don't reset properly, and subsequent tests over the same cell then fail.
Getting deep knowledge of the Apple III out of the internet seems pretty difficult, so I'm hoping that someone will stumble upon this and give me some answers before I figure out what I wired up wrong here. It would be really nice to have an inexpensive open-source replacement to get more 12-volt Apple IIIs back on the road.
Los Next Steps
I have quite a few leftover '04 gates so I'm hoping whatever I screwed up is just an inverted pin away.I don't have a lot of time to debug this for at least the next week or so, but it would be nice if someone who understands DRAM addressing a little better would give me a schematic review (you can see the PDF attached below) and see if I simply did something stupid.
It's not beyond me: I hooked up a 245's DIR pin backward the other day and tried to pan-fry a Raspberry Pi Pico on a different project.
Thanks for reading this ramble! I'll reply to this thread as soon as I make any progress (whether upwards or downwards.)
Last edited: