Early Macintosh home brew 4MB memory upgrade board development

[Builder68]

Agreed, that’s a great sign that it should work for this project!

Thanks for sharing this. I saw a blurb in the schematic in the linked GitHub repository talking about using an AND gate to control the ~OE line to the RAM ICs based on either the upper or lower ~CAS lines being asserted rather than just tying ~OE low like I had originally. The purpose for this allowing the use of EDO type RAM if FPM type becomes unavailable.

One more criterion to add to the list for the schematic redraw!

Good Catch! Linking that schematic was worth it!

I have to say, I find the way you use chat very enjoyable, like a kind of log of the thoughts, reflections, and decisions you make for the development of your project; it's much better than the stickers on the corkboard, isn't it?

 

[Golden Potato]

Good Catch! Linking that schematic was worth it!

I have to say, I find the way you use chat very enjoyable, like a kind of log of the thoughts, reflections, and decisions you make for the development of your project; it's much better than the stickers on the corkboard, isn't it?

Thanks! It can be a little meandering at time, but I find talking (or typing) my thoughts out loud helps me understand them better. Hopefully, it helps others too.

 

[Golden Potato]

I'm working on the schematic redraw, and I have an idea for connecting the ~OE pins on the DRAM ICs like the Mac Classic RAM expansion card without adding any new ICs. I'd like to hear opinions from others as the approach splits memory across the two DRAM ICs in a funny way.

The Mac Classic RAM expansion card Builder68 linked in a previous reply uses an AND gate on the two ~CAS lines (upper and lower bytes) for each DRAM, and the output of the AND gate is used to control the ~OE pins on each DRAM. To summarize the function: For each DRAM IC, if either the upper or lower ~CAS line is asserted, the ~OE pin is asserted on the IC. Only the corresponding upper or lower byte will actually output data. Apparently, this allows for EDO style DRAM ICs to be used in place of FPM.



On my schematic, ~MCAS0F and ~MCAS1F could be connected to an AND gate to feed the ~OE pin for the DRAM IC which will receive those two ~CAS lines. The same could be done for ~MCAS2F and ~MCAS3F to the other DRAM IC. Scroll to the bottom of this reply to see it drawn on a schematic.



After some further thought, it occurred to me that in this design those four ~MCAS#F are derived from the 512K system's ~CAS0 and ~CAS1 lines. If the purpose of the AND gate is to combine two of the ~MCAS#F lines, why not skip it and drive the ~OE pins on the DRAM ICs with the 512K system's ~CAS0 and ~CAS1 for each of the two DRAM ICs directly? The downside to this is I wouldn't be able to take ~MCAS0F & ~MCAS1F to one DRAM IC and ~MCAS2F & MCAS3F to the other DRAM IC.

Take a look at the truth table for the 74LS138 which generates the ~MCAS#F signals. When ~CAS0 is asserted, either ~MCAS0F or ~MCAS2F will be asserted depending on the state of A21 or if the video hardware is accessing memory. Similarly, ~CAS1 drives either ~MCAS1F or ~MCAS3F. Thus, to drive the ~OE line for a DRAM IC from ~CAS0, that DRAM IC should be receiving ~MCAS0F and ~MCAS2F.


This means the DRAM IC containing the lower byte of the first 2MB of memory will also contain the lower byte for the second 2MB of memory. The other DRAM IC will contain the upper bytes for both the first and second 2MBs of memory. To summarize, instead of one 2MB 16-bit DRAM IC containing the first 2MB of memory (both upper and lower bytes) and another IC containing the second 2MB, one DRAM IC contains the lower bytes for all 4MB and the other IC contains the upper bytes for all 4MB. This doesn't seem so bad, except that it almost defeats the purpose for 16-bit DRAM ICs. Fortunately, the Mac 512K's RAM hardware only accesses one byte at a time, meaning either an upper or a lower byte, and never all 16-bits at once.

This is what it would look like:


Compare that to how I would have expected or wanted the schematic to be:


It seems like a minor difference, and I think either way would work just fine. Does saving one IC (and more propagation delay) justify complicating the schematic? The method without the AND gate would certainly make troubleshooting a faulty DRAM IC difficult since either IC is responsible for the entire 4MB memory (upper or lower bytes, of course). Granted there are only two DRAM ICs, so it's a 50/50 shot at which one could be the hypothetical problem.

 

[Golden Potato]

My mind wandered back to this project while I was at work today, and I couldn't help but think about how the technique I'm borrowing from "Classic Mac Tech Docs v1.1" to generate additional ~CAS lines only allows for upper or lower byte of RAM to be accessed at one time. That didn't sit right with me. There's no way the classic Macs are limited to only accessing upper or lower bytes at a time, and I'm unaware of any tricks going on such as data for each byte held in latches to present both bytes at once.

To confirm my suspicion, I reconnected my Mac 512K to stock configuration and probed the CAS0 and CAS1 lines, which correspond to lower and upper bytes of RAM, and found that the Mac does indeed access both banks at once for a full 16-bit word. Although sometimes only the upper or lower bytes are accessed.







I haven't personally laid eyes on a Mac with the 1MB memory mod as described in that document, but I would be willing to bet that there isn't such a Mac in existence since it wouldn't work! The truth table for the 74LS138 (see previous reply) indicates that both CAS0 and CAS1 asserted (logic 0s) would select either output Y0 or Y1, depending on the state of A19 (A21 in my case), and both of those outputs are not connected to anything. Any 16-bit word accesses to RAM would not select any memory.

I wouldn't post this here without a solution in mind; adding a quad AND gate IC and making connections to those first two unused outputs on the 74LS138 takes care of cases where both ~CAS0 & ~CAS1 or ~CAS2 & ~CAS3 need asserted at once.



I'm really counting on the new DRAM's faster speed making up for any added propagation delay from the logic ICs here.

For my previous reply: I've decided to just go ahead and add the AND gates for EDO DRAM compatibility since I'm already adding another IC here. I'd prefer a readable schematic over some tricks to save one small IC since this is just a hobby project.

 

[Golden Potato]

The truth table for the 74LS138 (see previous reply) indicates that both CAS0 and CAS1 asserted (logic 0s) would select either output Y0 or Y1, depending on the state of A19 (A21 in my case), and both of those outputs are not connected to anything. Any 16-bit word accesses to RAM would not select any memory.

This has got to be one major reason why my breadboard prototype didn’t work. I know I should just finalize the next schematic and lay out a PCB, but it’s very tempting to modify the breadboard circuit, reconnect it to the Mac, and see if it works…

 

[Builder68]

This has got to be one major reason why my breadboard prototype didn’t work. I know I should just finalize the next schematic and lay out a PCB, but it’s very tempting to modify the breadboard circuit, reconnect it to the Mac, and see if it works…

Well... If I were you, I would not resist the urge to tinker!

 

[Builder68]

This has got to be one major reason why my breadboard prototype didn’t work. I know I should just finalize the next schematic and lay out a PCB, but it’s very tempting to modify the breadboard circuit, reconnect it to the Mac, and see if it works…

I'm sharing the core CAS/RAF9 generation subcircuit of the MacSnap 548E board. I think it might be helpful for Golden Potato with his own homebrew RAM expansion design.

Notably, the MacSnap series stands out for being the only RAM expansion board using just TTL logic instead of programmable GAL equations.

From what I can interpret, this circuit seems to handle RAM address allocation for the screen memory and CAS signals generation in a more robust way.

Also, like other similar boards for these early Macs, it takes control of and manages the RAM ICs on the motherboard. Still pending to identify where are at those 74LS139 ~CASF lines.

 

[Builder68]

I forgot to mention that the circuit diagram I obtained was purely generated by analyzing several images available online of both sides of board models 524, 548, and 548E. I haven't had physical access to any of these boards yet, so obviously it needs to be thoroughly checked and interpreted by someone with in-depth knowledge of how the Motorola 68000 CPU operates in early Macintosh computers. I'm attaching the images I've been using to reproduce the circuit mentioned in my previous post. To simplify the circuit diagram and improve readability, I replaced the symbols for resistor packs RP4,RP5, and RP6 with single resistor symbols.

Here's what I understand about the differences between board models 548 and 548E:

• Model 548E likely implements a 74LS259 hardware component to discard any RAM address exceeding 4 MB. This model was likely designed specifically for the Macintosh 512KE and omits socket H2.

I'm unsure if model 548, intended for the Macintosh 512K, requires 128K ROM ICs to be installed. It would be great if someone with access to the manuals for these boards could share them.

I must admit, some traces were challenging to decipher, but I believe the final result is an accurate replica, excluding decoupling capacitors. However, the reference number labels of ICs and resistors do not match the original board.

 

[Golden Potato]

I'm sharing the core CAS/RAF9 generation subcircuit of the MacSnap 548E board. I think it might be helpful for Golden Potato with his own homebrew RAM expansion design.

Notably, the MacSnap series stands out for being the only RAM expansion board using just TTL logic instead of programmable GAL equations.

From what I can interpret, this circuit seems to handle RAM address allocation for the screen memory and CAS signals generation in a more robust way.

Also, like other similar boards for these early Macs, it takes control of and manages the RAM ICs on the motherboard. Still pending to identify where are at those 74LS139 ~CASF lines.

Thank you for putting in the effort to trace this out! I’ll look into this soon and try to noodle out how it works. I’d like to know for sure what the Mac’s C2M signal does. A while ago, I thought maybe it was some recreation of the A0 signal which is not present on the 68000, but I don’t think that’s right. I don’t even remember why I thought it could be.

I just received a couple of 20 pin DIP clips to make wiring the breadboards up to the logic board a little easier. I’ve been holding off until they arrived. I’m still planning on wiring up the changes I previously mentioned and testing it all out.

…but I am very intrigued by the ~CAS lines generation method used by the MacSnap.

If only we could get those sweet reverse IC sockets today. We could make a straight up clone! I’d still opt for larger density memory ICs, however.

 

[Builder68]

D1 and D2 are likely Zener diodes, not 1N4148 general-purpose diodes.

Sockets named J9 and J5 on the MacSnap Board share traces for the same two signals: J9 receives them directly from CPU pins, while J5 gets them from resistor pack RP1. This configuration only makes sense if those signals are A19 and A20. However, the LB schematic for the MAC 512K doesn't show any connections to RP1 for these address lines (A19 and A20). Despite the missing schematic information, the chosen signals are likely correct since they're used only as inputs of U4 (74LS253) to generate RAF9. The other set of A19 and A20 signals used in the circuit likely comes from TSG and U4D IC Snap sockets and have their own 2.2k ohm pull-up resistors.

I think I remember reading or hearing that the attached schematic has some differences with some MAC 128K/152 LB production models. Perhaps someone could shed some light on this issue?

 

[Golden Potato]

D1 and D2 are likely Zener diodes, not 1N4148 general-purpose diodes.

That would make sense

 

[Golden Potato]

I’d like to know for sure what the Mac’s C2M signal does.

It’s got to be a timing signal which is used to multiplex addresses for CAS and RAS.

 

[Builder68]

It’s got to be a timing signal which is used to multiplex addresses for CAS and RAS.

Did you find the GAL equations (unverified) from TSM on the Mac Plus?. Yes, it seems to be a 2 MHz clock signal. Check this out!

 

[Golden Potato]

Did you find the GAL equations (unverified) from TSM on the Mac Plus?. Yes, it seems to be a 2 MHz clock signal. Check this out!

I stumbled upon a version of this on Bitsavers. There are also some other GAL reversing stuff there as well. What you linked is very interesting! I like seeing handwritten notes and k-maps. Haha

Looking at the Mac 128/512K logic board schematic, its apparent that the '253s that create the RAM address lines are using C2M to multiplex the address bus for RAM Row addresses and Column addresses. Here's what the stock 512K looks like:

I assume that when the CPU accesses RAM, VID/~u would go low as well as C2M, the memory address placed onto the bus, then ~RAS would go low latching in A9-A17 into the DRAM row address registers. Then C2M would go low, then ~CAS lines would go low, which would latch A1-A8 + A18 into the DRAM column address registers. The data on the data bus would then be valid (either reading from or writing to RAM). I can confirm the exact sequence of C2M, ~RAS, and ~CAS by probing my logic board sometime soon.

Understanding the behavior of this signal should help figure out how the MacSnap board works!

 

[Golden Potato]

Sockets named J9 and J5 on the MacSnap Board share traces for the same two signals: J9 receives them directly from CPU pins, while J5 gets them from resistor pack RP1. This configuration only makes sense if those signals are A19 and A20. However, the LB schematic for the MAC 512K doesn't show any connections to RP1 for these address lines (A19 and A20). Despite the missing schematic information, the chosen signals are likely correct since they're used only as inputs of U4 (74LS253) to generate RAF9. The other set of A19 and A20 signals used in the circuit likely comes from TSG and U4D IC Snap sockets and have their own 2.2k ohm pull-up resistors.

They are probably A17 and A18 to generate RA8F. On the Mac 512K, this is already done on the board at U13G, but the Mac 128K doesn't have this. The 128K->512K mod outlined here takes signals from RP1 to do so. You can see it here on the part labeled "512K only". The '253 is incorrectly labeled U13F. Maybe they did this so their board can work on either 128K or 512K Macs?

FYI, I found the pinout for RP1 on the schematics (and thus on the Mac 128K) vary greatly from that of the 512K. RP1 is a SIP for the 128K and a DIP for the 512K.

 

[Golden Potato]

I like the way the MacSnap creates the CASF lines better than the approach I was taking. Using separate '139s for each CAS pair, rather than a single '138, and feeding them the same select signals allows one, the other, or both CASF lines for a pair to be asserted. C2M is ORed with the logic board's CAS lines to turn off the CASF lines when C2M is high. This is good, because I believe the CASF lines should be unasserted while C2M is high to allow the RAS line to do its thing.

 

[Golden Potato]

I stumbled upon a version of this on Bitsavers. There are also some other GAL reversing stuff there as well. What you linked is very interesting! I like seeing handwritten notes and k-maps. Haha

Looking at the Mac 128/512K logic board schematic, its apparent that the '253s that create the RAM address lines are using C2M to multiplex the address bus for RAM Row addresses and Column addresses. Here's what the stock 512K looks like:
View attachment 74098
I assume that when the CPU accesses RAM, VID/~u would go low as well as C2M, the memory address placed onto the bus, then ~RAS would go low latching in A9-A17 into the DRAM row address registers. Then C2M would go low, then ~CAS lines would go low, which would latch A1-A8 + A18 into the DRAM column address registers. The data on the data bus would then be valid (either reading from or writing to RAM). I can confirm the exact sequence of C2M, ~RAS, and ~CAS by probing my logic board sometime soon.

Understanding the behavior of this signal should help figure out how the MacSnap board works!

I guess this is too old to edit, but based on my thoughts from looking over the MacSnap board, I think it should read:

I assume that when the CPU accesses RAM, VID/~u would be low as well as C2M, C2M would then go high, then the memory address placed onto the bus, then ~RAS would go low latching in A1-A8 + A18 into the DRAM row address registers. Then C2M would go low, then ~CAS lines would go low, which would latch A9-A17 into the DRAM column address registers. The data on the data bus would then be valid (either reading from or writing to RAM).

I'll double check this when I can get back to my bench and probe the running system.

 

[Builder68]

They are probably A17 and A18 to generate RA8F. On the Mac 512K, this is already done on the board at U13G, but the Mac 128K doesn't have this. The 128K->512K mod outlined here takes signals from RP1 to do so. You can see it here on the part labeled "512K only". The '253 is incorrectly labeled U13F. Maybe they did this so their board can work on either 128K or 512K Macs?

FYI, I found the pinout for RP1 on the schematics (and thus on the Mac 128K) vary greatly from that of the 512K. RP1 is a SIP for the 128K and a DIP for the 512K.

They are probably A17 and A18 to generate RA8F. On the Mac 512K, this is already done on the board at U13G, but the Mac 128K doesn't have this. The 128K->512K mod outlined here takes signals from RP1 to do so. You can see it here on the part labeled "512K only". The '253 is incorrectly labeled U13F. Maybe they did this so their board can work on either 128K or 512K Macs?

FYI, I found the pinout for RP1 on the schematics (and thus on the Mac 128K) vary greatly from that of the 512K. RP1 is a SIP for the 128K and a DIP for the 512K.

Yes, you're absolutely right. Depending on the motherboard configuration, only one connection should be made. If you have a MacSnap Board installed on top of a Mac 128K Board, use the appropriate connection. Otherwise, for Mac 512K/KE boards, use the other connection. This selection determines whether the generated signal is RAF8 or RAF9.These connections are the only changes needed for generating the RAS8F/RAS9F signals. It seems so obvious now! I feel a little ashamed for not figuring it out myself before.

 

[Golden Potato]

Okay, I've got some evidence to back up my thinking. Indeed beginning with C2M high, an address would be placed onto the bus (thus to the '253s). With C2M high, the '253s present A1-A8 + A18 to DRAM which is latched in as a row address when ~RAS goes low. After ~20-35ns, C2M goes low which switches the '253s to present A9-A17 to DRAM which is latched in as a column address when ~CAS goes low. It fits perfectly with the expected pattern illustrated in the figure below:


(From HM50256 DRAM IC datasheet)

I'm feeling a lot better about my understand of how early Mac memory works. I hope I'll have time tomorrow to wire up that crazy breadboard setup to the logic board. If all goes well, I'll modify it to instead use '139s for ~CAS generation.

 

[Builder68]

View attachment 74113
Okay, I've got some evidence to back up my thinking. Indeed beginning with C2M high, an address would be placed onto the bus (thus to the '253s). With C2M high, the '253s present A1-A8 + A18 to DRAM which is latched in as a row address when ~RAS goes low. After ~20-35ns, C2M goes low which switches the '253s to present A9-A17 to DRAM which is latched in as a column address when ~CAS goes low. It fits perfectly with the expected pattern illustrated in the figure below:

View attachment 74114
(From HM50256 DRAM IC datasheet)

I'm feeling a lot better about my understand of how early Mac memory works. I hope I'll have time tomorrow to wire up that crazy breadboard setup to the logic board. If all goes well, I'll modify it to instead use '139s for ~CAS generation.

Great news!.

BTW, I'm taking a closer look at those 150 ohm resistors. The MacSnap likely adds to the mainboard memory, so its function might be a kind of trick to override the original signals. Maybe I'm talking gibberish, but as far as I understand, a low value resistor in this configuration is more likely used to prioritize / reinforce the 74LS139's output by weakening any opposing signals rather than acting as a traditional pull-up resistor... Meaning if that 74LS139 goes high (unasserted), an opposite low CAS (asserted) signal coming from the mainboard circuitry will have a difficult time to be "seen". Perhaps both signals will always be in sync, and the purpose of the resistor is to provide enough current for the corresponding lower / upper 8 ICs on the mainboard... It puzzled me why use those resistors only with the CAS signals that go to the mainboard...