Early Macintosh home brew 4MB memory upgrade board development

[SuperSVGA]

Following the pinout in your simulation image, the system RAM is actually MCAS2F and MCAS3F, and the minimal RAM on the MacSnap is MCAS0F and MCAS1F.

You also seem to have pin 2 of RP6 shown as connected to ground rather than a pull-up for pin 1 on the 74LS253. I believe that pin is low when the card has 1.5MB of RAM.

 

[Builder68]

Following the pinout in your simulation image, the system RAM is actually MCAS2F and MCAS3F, and the minimal RAM on the MacSnap is MCAS0F and MCAS1F

That is correct, I tried to boot up with just the system Ram managed by MCAS2F and MCAS3F (With System CAS routes opened at RP3 on the LB)

You also seem to have pin 2 of RP6 shown as connected to ground rather than a pull-up for pin 1 on the 74LS253. I believe that pin is low when the card has 1.5MB of RAM.

Thank you very much SuperVGA! Finally, someone with insights about this expansion board!

Yes, you're absolutely right. I obtained the circuits from several pictures on the internet.

As you can see in the attached pictures, in this version of the expansion board (512KB), "JP1" is missing, so as you said, RP6 is pulling high on pin #1 of the 74LS253. I don't know why I included JP1 in the schematics. Maybe I mixed up schematics and versions at some point.

I believe that pin is low when the card has 1.5MB of RAM.

You're right again. I didn't notice before. I'm attaching a picture of a 1.5 MB board that just confirms it!

Also, perhaps you know the function of the 74LS259, which is implemented to control enable pin 15 on the 74LS253 in models with an 'E' at the end? Does it have something to do with a difference in the ROM of the 512KE?

 

[Golden Potato]

This is incorrect. I've simulated the MacSnap subcircuit and found that the system CAS signals are in sync with MCAS0F and MCAS1F signals. My apologies.

According to the simulation, it should work. There must be something wrong with my build.

View attachment 76421

This probably won’t change anything, but you could try connecting the unused inputs on the 7432 to ground or pull them high with pull up resistors. Someone reported to me that they did that once, and it actually fixed issues they had with a design I did to modify an arcade game. It worked fine for me with unused inputs/outputs floating, but they had lots of graphical glitches which went away after they tied the unused inputs low. Very strange!

You could also try disconnecting C2M from the 7432 and connect those two pins to ground to essentially pass through the system CAS lines. I’m sure the MacSnap was built the way it was for good reason, but I’d be curious to see if it works without it. I still don’t quite understand why it’s designed that way.

The A19 and A20 “look ahead” circuit is very clever, and I think I see why they implemented it. I think it has to do with making up for the long propagation time for “select to output” for the 74253. Getting A19 and A20 to the output of the 74253 before RAS goes low and latching them as it goes low makes sense. It allows the signal to propagate through the IC and onto the 74139, so it’s already got through that delay. If it weren’t for this, the output of the 74253 could still be changing when the 74139 becomes enabled, which would activate the wrong MCAS line for a moment.

 

[SuperSVGA]

Also, perhaps you know the function of the 74LS259, which is implemented to control enable pin 15 on the 74LS253 in models with an 'E' at the end? Does it have something to do with a difference in the ROM of the 512KE?

It looks like it brings pin 15 high/disabled for writes to 0x200000-0x300000. I don't know why off the top of my head though.

 

[Golden Potato]

One other thought: try to get 74xxxxx components which match the exact type as the ones on the MacSnap board. By that I mean 74LSxxx, 74Fxxx, and 74HCTxxx. Each of these will have different propagation delays, and since there seem to be a mix of types on the MacSnap board depending on the required logical function, it may have been a design requirement.

In some portions of the circuit, the designers likely wanted to decrease prop delay, and potentially in other portions, they may have wanted to slightly increase it.

The 74F139 is likely crucial. A modern replacement could be a 74AHCT139.

I’m not sure how critical is the 74HCT32. An LS part will likely have the same prop delay, just a higher power requirement.

 

[Golden Potato]

For a minimal configuration, I believe pin 1 (OEa) and pin 15 (OEb) must both be pulled high. That would only ever select MCAS0 and MCAS1.

This is what I worked out for all configuration options for that circuit (in terms of total memory including 512KB of logic board memory):
OEa HIGH; OEb HIGH: 512KB
MCAS0, MCAS1 -> 00000-7FFFF
mirrored through 1FFFFF; A19 & A20 = don't care
OEa HIGH; OEb LOW: 1MB
MCAS0, MCAS1 -> 00000-7FFFF
MCAS2, MCAS3 -> 80000-FFFFF
mirrored through 1FFFFF; A20 = don't care
OEa LOW; OEb LOW: 2MB
MCAS0, MCAS1 -> 00000-7FFFF
MCAS2, MCAS3 -> 80000-FFFFF
MCAS4, MCAS5 -> 100000-17FFFF
MCAS6, MCAS7 -> 180000-1FFFFF
OEa LOW; OEb HIGH: 1MB
MCAS4, MCAS5 -> 100000-17FFFF
MCAS6, MCAS7 -> 180000-1FFFFF
mirrored from 00000-FFFFF; A19 = don't care

Edit: I suppose all of those are mirrored through the entire 4MB space in the memory map since A21 is a don’t care for the entire circuit. Not totally relevant for comparing the different jumper settings.

 

[Golden Potato]

For a minimal configuration, I believe pin 1 (OEa) and pin 15 (OEb) must both be pulled high. That would only ever select MCAS0 and MCAS1.

This is what I worked out for all configuration options for that circuit (in terms of total memory including 512KB of logic board memory):
OEa HIGH; OEb HIGH: 512KB
MCAS0, MCAS1 -> 00000-7FFFF
mirrored through 1FFFFF; A19 & A20 = don't care
OEa HIGH; OEb LOW: 1MB
MCAS0, MCAS1 -> 00000-7FFFF
MCAS2, MCAS3 -> 80000-FFFFF
mirrored through 1FFFFF; A20 = don't care
OEa LOW; OEb LOW: 2MB
MCAS0, MCAS1 -> 00000-7FFFF
MCAS2, MCAS3 -> 80000-FFFFF
MCAS4, MCAS5 -> 100000-17FFFF
MCAS6, MCAS7 -> 180000-1FFFFF
OEa LOW; OEb HIGH: 1MB
MCAS4, MCAS5 -> 100000-17FFFF
MCAS6, MCAS7 -> 180000-1FFFFF
mirrored from 00000-FFFFF; A19 = don't care

Edit: I suppose all of those are mirrored through the entire 4MB space in the memory map since A21 is a don’t care for the entire circuit. Not totally relevant for comparing the different jumper settings.

Edit 2: for the last case, the system may only recognize 512KB of memory? Only MCAS4, MCAS5 would be mirrored from 00000-FFFFF, and MCAS6,MCAS7 would only activate starting at 180000 since it is dependent solely on A20 with A19 having no bearing. It’s probably a “do not use” configuration.

 

[Golden Potato]

For a minimal configuration, I believe pin 1 (OEa) and pin 15 (OEb) must both be pulled high. That would only ever select MCAS0 and MCAS1.

This is what I worked out for all configuration options for that circuit (in terms of total memory including 512KB of logic board memory):
OEa HIGH; OEb HIGH: 512KB
MCAS0, MCAS1 -> 00000-7FFFF
mirrored through 1FFFFF; A19 & A20 = don't care
OEa HIGH; OEb LOW: 1MB
MCAS0, MCAS1 -> 00000-7FFFF
MCAS2, MCAS3 -> 80000-FFFFF
mirrored through 1FFFFF; A20 = don't care
OEa LOW; OEb LOW: 2MB
MCAS0, MCAS1 -> 00000-7FFFF
MCAS2, MCAS3 -> 80000-FFFFF
MCAS4, MCAS5 -> 100000-17FFFF
MCAS6, MCAS7 -> 180000-1FFFFF
OEa LOW; OEb HIGH: 1MB
MCAS4, MCAS5 -> 100000-17FFFF
MCAS6, MCAS7 -> 180000-1FFFFF
mirrored from 00000-FFFFF; A19 = don't care

Edit: I suppose all of those are mirrored through the entire 4MB space in the memory map since A21 is a don’t care for the entire circuit. Not totally relevant for comparing the different jumper settings.

Edit 3: The last case (OEa LOW; OEb HIGH) is actually MCAS0, MCAS1 or MCAS4, MCAS5 depending on A20. MCAS6, MCAS7 would never be selected in this case.

It's such a weird arrangement that there's no way this should be a valid case.

 

[Golden Potato]

I suspect this would work for 1024 refresh cycles, but this will need tested to know for sure:
View attachment 76187

Based on this table, the MacSnap ~CAS#F generation circuit reversed engineered by Builder68, and all the other stuff from this thread thus far, I've come up with the attached schematic for 1024 cycle refresh DRAM. It's untested, and there are probably mistakes. However, I wanted to transfer some of this stuff into a schematic--even if it will be replaced with a better one soon.

I don't plan on using these particular DRAM ICs in the final design, but they're what I've got for now. I do prefer this memory density, however.

 

[Builder68]

I have both great and not-so-great news...

Finally, as you can see in the attached pictures, my Mac 512K is reporting 1 MB of RAM! Here's how I achieved this:

The prototype build utilizes SYSTEM RA0 and RA8. CAS lines are generated using a reverse-engineered MacSnap subcircuit, without the 150-ohm resistors (I opened System CAS at RP3). As with the MacSnap board 524, expansion RAM is the first bank (~MCAS0F, ~MCAS1F), and System RAM is the second (~MCAS2F, ~MCAS3F). I also implemented the 74259 and added a jumper selector to choose between ground and pin 11 as input to pin 15 of the 74253. Selecting ground allows the system to boot and report 1 MB, while selecting pin 11 also boots the system but only recognizes the first bank regardless of whether system RAM or expansion RAM is swapped.

It took extensive testing to identify a significant issue. The Mac hangs during OS startup (at the "Welcome to Macintosh" screen) when my ROM-INATOR board is installed (pin 15 of 74253 to ground). Using pin 11 of the 74259 allows booting but prevents recognition of the second memory bank.

The ROM-INATOR board uses A17, A18, and A19 as inputs. I suspect the conflict arises from A19.







There are some important takeaways to mention:

This RAM IC probably would be a great candidate to replace all system RAM at once on 128/512K Macs. To be 100% sure, it needs to be mounted on a future PCB and thoroughly tested beforehand.

The fact that the MacSnap design is not compatible with the ROM-INATOR is a setback.

The added output buffers seem to work flawlessly, and there appear to be no timing conflicts with the system RAM...

 

[Builder68]

It looks like it brings pin 15 high/disabled for writes to 0x200000-0x300000. I don't know why off the top of my head though.

I read somewhere that on the Mac 512Ke, $020000-$03FFFF maps to a copy of the ROM. Could the 74259 subcircuit be used to avoid writing to that address range?

 

[Builder68]

What if the 128 KB ROM somehow gets "confused" by detecting 1 MB of RAM and then uses the memory map for a Mac Plus instead?

 

[SuperSVGA]

I read somewhere that on the Mac 512Ke, $020000-$03FFFF maps to a copy of the ROM. Could the 74259 subcircuit be used to avoid writing to that address range?

I think the ROM overlay is usually 0x000000-0x1FFFFF, so I'm not sure why it would ever end up at that range. That part of RAM should only be a repeated image of the RAM, especially since video and sound memory is at the end of the RAM space.

What if the 128 KB ROM somehow gets "confused" by detecting 1 MB of RAM and then uses the memory map for a Mac Plus instead?

The stock Mac Plus ROM checks if the ROM is mirrored to determine whether it is a 512ke or a Plus, at least as far as SCSI is concerned. Though I'm not sure what the ROM-INATOR does in this scenario, since it uses the whole address space.

 

[Builder68]

I think the ROM overlay is usually 0x000000-0x1FFFFF, so I'm not sure why it would ever end up at that range. That part of RAM should only be a repeated image of the RAM, especially since video and sound memory is at the end of the RAM space.


The stock Mac Plus ROM checks if the ROM is mirrored to determine whether it is a 512ke or a Plus, at least as far as SCSI is concerned. Though I'm not sure what the ROM-INATOR does in this scenario, since it uses the whole address space.

Well, the only extra feature I had with the ROM-INATOR was the ability to boot from ROM. Luckily for me, this 512K came with Mac Plus ROM, so the FloppyEmu can work in HD mode without problems.

I played 'Apache Strike' for more than half an hour without any crashes at all!

The stability shown by the prototype build is encouraging. I'm done with the prototype stage! It's time to start working on PCB layout proposals. I'm thinking one option is to use the same connection points as the MacSnap board does, but since those 'Snap-In' sockets are no longer available, it will be necessary to solder sockets onto the LB ICs, and the expansion board will connect through pin headers, just as I did with the prototype build. Maybe someone could come up with a better approach... It's far easier to solder piggyback sockets than remove ICs from the board.

 

[Golden Potato]

I have both great and not-so-great news...

Finally, as you can see in the attached pictures, my Mac 512K is reporting 1 MB of RAM! Here's how I achieved this:

The prototype build utilizes SYSTEM RA0 and RA8. CAS lines are generated using a reverse-engineered MacSnap subcircuit, without the 150-ohm resistors (I opened System CAS at RP3). As with the MacSnap board 524, expansion RAM is the first bank (~MCAS0F, ~MCAS1F), and System RAM is the second (~MCAS2F, ~MCAS3F). I also implemented the 74259 and added a jumper selector to choose between ground and pin 11 as input to pin 15 of the 74253. Selecting ground allows the system to boot and report 1 MB, while selecting pin 11 also boots the system but only recognizes the first bank regardless of whether system RAM or expansion RAM is swapped.

It took extensive testing to identify a significant issue. The Mac hangs during OS startup (at the "Welcome to Macintosh" screen) when my ROM-INATOR board is installed (pin 15 of 74253 to ground). Using pin 11 of the 74259 allows booting but prevents recognition of the second memory bank.

The ROM-INATOR board uses A17, A18, and A19 as inputs. I suspect the conflict arises from A19.

View attachment 76624

View attachment 76625
View attachment 76626


There are some important takeaways to mention:

This RAM IC probably would be a great candidate to replace all system RAM at once on 128/512K Macs. To be 100% sure, it needs to be mounted on a future PCB and thoroughly tested beforehand.

The fact that the MacSnap design is not compatible with the ROM-INATOR is a setback.

The added output buffers seem to work flawlessly, and there appear to be no timing conflicts with the system RAM...

This is fantastic news!

Just to clarify, your expansion RAM requires 512 cycle refresh, but you are using the system’s unmodified RA0 and RA8 signals? I’m surprised it’s so stable! I’m glad the added input buffers seem to work okay; I suppose I probably didn’t need to order that Mac Plus logic board, but I’m still curious to prove those signals and document the differences/similarities.

I’m not sure why the ROMinator would struggle with this setup, unless perhaps whatever crazy coincidental thing occurring in the stock system which seems to be keeping your memory refreshed isn’t happening the same way when the ROMinator is in control? If you have the time and motivation, it would be nice to test swapping around those signals for the RA0 and RA8 generation to create 512 cycle refresh and test that with your ROMinator. I wouldn’t worry about swapping things to fix distorted audio for that test.

This IC does seem to be a great candidate! My only reservation would be the quantity required to reach the full 4MB being 7 of these ICs (8 if you exclude onboard RAM). I would still like to experiment with higher density ICs, generate an RA9, and utilize only 4 CAS lines. But that’s just my preference

 

[Golden Potato]

Well, the only extra feature I had with the ROM-INATOR was the ability to boot from ROM. Luckily for me, this 512K came with Mac Plus ROM, so the FloppyEmu can work in HD mode without problems.

I played 'Apache Strike' for more than half an hour without any crashes at all!

The stability shown by the prototype build is encouraging. I'm done with the prototype stage! It's time to start working on PCB layout proposals. I'm thinking one option is to use the same connection points as the MacSnap board does, but since those 'Snap-In' sockets are no longer available, it will be necessary to solder sockets onto the LB ICs, and the expansion board will connect through pin headers, just as I did with the prototype build. Maybe someone could come up with a better approach... It's far easier to solder piggyback sockets than remove ICs from the board.

I searched high and low for those type of connectors and came up short. The path I was thinking would be to desolder ICs and a resistor pack and replaced with sockets to which pin headers would mate, but only the standard 74 series logic stuff. No PALs to be desoldered. Then solder jumper leads to tap other signals and use female DuPont style ends to connect to pin headers on the expansion board. It sucks to desolder those ICs, but since they are standard parts, they could be cut off and the pins removed individually.

If someone could instead create some kind of 3D printed version of those connectors the MacSnap has, that would be much better.

 

[Builder68]

This is fantastic news!

Just to clarify, your expansion RAM requires 512 cycle refresh, but you are using the system’s unmodified RA0 and RA8 signals?

Yes!

 

[Builder68]

I’m not sure why the ROMinator would struggle with this setup, unless perhaps whatever crazy coincidental thing occurring in the stock system which seems to be keeping your memory refreshed happening the same way when the ROMinator is in control?

This does not seem related to a problem with refresh cycles. The Mac always hangs at the same point, regardless of the OS version. It appears that the CPU is writing to a 'reserved' RAM space used by a ROM mirror, perhaps. The ROM-INATOR uses the entire address space, so an address conflict is more likely.

 

[Builder68]

This IC does seem to be a great candidate! My only reservation would be the quantity required to reach the full 4MB being 7 of these ICs (8 if you exclude onboard RAM). I would still like to experiment with higher density ICs, generate an RA9, and utilize only 4 CAS lines. But that’s just my preference

We have a proven CAS generation sub circuit design that certainly works (taken from the MacSnap Board), but it can only handle four banks of 512KB, and also we probably have a RAM IC that seems to be compatible with the Mac 512K's memory refreshing mechanism.

Of course, the ultimate goal is to reach 4MB. This first PCB with the simplest possible design will be a great accomplishment along the way.

 

[Builder68]

This IC does seem to be a great candidate! My only reservation would be the quantity required to reach the full 4MB being 7 of these ICs (8 if you exclude onboard RAM). I would still like to experiment with higher density ICs, generate an RA9, and utilize only 4 CAS lines. But that’s just my preference

Maybe I'm wrong, but using 4 CAS lines wouldn't mean the 512K Mac would read in banks of 1 MB instead of 512KB?. You would need to devise some circuitry to replicate certain tasks performed by the CAS IC on the Mac Plus to generate RAS/CAS signal cycles (and probably others) for banks of 1 MB.