Early Macintosh home brew 4MB memory upgrade board development

[Builder68]

Since the prototype build has worked so well (not even one crash or hang in all these days), I'm currently in the process of developing multiple PCB design proposals for the prototype build (3.5MB Memory expansion plus 512KB onboard memory, using system RA0 & RA8 only to simplify the circuitry as much as possible). To optimize costs, I'm requesting quotes from several PCB manufacturers to determine the most economical option. Any advice on this matter would be greatly appreciated. I'm using only modern components (SMD 0805 for capacitors and resistors, and SOIC 1.27 mm package for 74XX ICs).

One of the proposals I like best is splitting the board into two parts. Due to the challenging placement of the connection points to the 74LS244 buffers, a single board design would result in significant wasted space. By separating the layout into a small board over the TSM IC and another board for the 74LS244s and the rightmost 41256 ICs, I believe it can achieve a more efficient and cost-effective design. I believe the only wires that would travel from one board to the other would be the CAS lines. I'd like to hear other perspectives on this as well.

A clear advantage of splitting the memory expansion is that the small TSM/BMU board would be dedicated to CAS signal generation. Any improvements would only require a new version of this board. The board with the 7 512KB RAM ICs and input buffers wouldn't need further revisions.

 

[Golden Potato]

One of the proposals I like best is splitting the board into two parts. Due to the challenging placement of the connection points to the 74LS244 buffers, a single board design would result in significant wasted space. By separating the layout into a small board over the TSM IC and another board for the 74LS244s and the rightmost 41256 ICs, I believe it can achieve a more efficient and cost-effective design. I believe the only wires that would travel from one board to the other would be the CAS lines. I'd like to hear other perspectives on this as well.

I concur! Two smaller boards would be advantageous for all the reasons you mentioned.

I’m excited to see how they turn out!

 

[Builder68]

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

I've completed the PCB layout for 512-cycle memory ICs (system RA0 and RA8).

The total cost for five PCBs from JLPCP is approximately $8 plus shipping.

I'm currently designing a tiny auxiliary board for intervene system CAS at RP3 (to implement system memory bank without using the "voltage divider" circuit from the MacSnap design), and also to implement your 512 refresh cycles mod (RA0&RA8 generated like in the MacPlus).

I ´m thinking to incorporate your proposed mod for 1024 refresh cycles, so it can provide flexibility to implement either 512 or 1024 refresh cycles selectively. Have you had a chance to test your 1024 cycles mod?




Of course, a different PCB would be needed for 1024 cycles, but modifications to achieve a 1024 RC version by replacing those seven DRAM ICs with just two 1024 RC DRAM ICs and changing a couple of things in the CAS multiplexing subcircuit are very straightforward.

 

[Builder68]

Here is the first version of the auxiliary board (512 cycles mod).

It connects to a socket mounted on top of U4F (Piggy Back) and to strip pin sockets that replace the RP2 and RP3 resistor arrays.

JP1 & JP2 select between system RA0 & RA8 (proven to work with the selected RAM ICs for the expansion board), and modded RA0 & RA8, which are generated like in the Mac Plus. Golden Potato figured out how to generate the missing RA8 (DMA active) that comes from BMU2 on the MacPlus.

I'm about to start a work trip that will keep me away from this project at least for a couple of weeks. Any feedback in the meantime is greatly appreciated.

It is important to stress out that the prototype build only had worked on a Mac 512K with MacPlus ROMs. If ROM-INATOR is installed the Mac will hang at "Welcome to Macintosh" screen. (JoopMac confirmed the same behavior with an original MacSnap 524 board and the ROM-INATOR. He found a workaround to make it boot mixing a different version of the Finder with System 5.1)

No tests have been conducted, to my knowledge, on Mac 512KE models, but just in case someone wants to try, the expansion board design includes a soldered jumper (JP5) to activate an additional functionality implemented in MacSnap board models intended for Mac 512KE (524E, 548E).

Also, so far no one has shown interest in making a version for the Mac 128K for testing. I guess those Macs are more valuable kept in their original state.

Although my PCBs are designed to minimize heavy rework on the logic board, I only had to solder some bodger cables to pick up signals and 5 sockets on top of non-proprietary, easily replaceable ICs. I really miss those snap-in DIP sockets now. They seem to be gone forever!

I don't feel I'm quite ready to release the fabrication files yet. I want to order and assemble a first batch of these initial versions of both boards and conduct more extensive tests before proceeding. Also, this design requires the use of no fewer than seven 256KB x 16-bit FP DRAM chips. Perhaps we're still in the middle of development, and someone could find a way to implement higher-density DRAM ICs (1024 refresh cycles) for the early Macs...

 

[Golden Potato]

Great work laying out these PCBs!

One thing I spotted is pin 1 on the aux board’s ‘253 should be connected to DMA instead of ~DMA. I think the ~DMA signal is also accidentally connected to a signal used as a pull up for a bunch of other inputs. Other than that, it looks good to me!

I haven’t had a chance to try out the 1024 cycle mod yet. I ordered those AS4C1M16F5 DRAM ICs mentioned previously and a couple breakout boards which should take up less space on a soldered prototype compared to the 8 ICs on DIP breakout boards I’ve been working with. I just don’t see how I could solder in all 8 breakout boards onto a prototype and still have room for anything else! Hopefully it’ll all get here by the end of the month.

The 1024 cycle mod only benefits DRAM ICs which have 10 address lines (RA0-RA9). The CAS generation for that density of DRAM must create only 4 CAS lines by multiplexing the 2 system CAS lines with A21. I’m on vacation right now, so I can’t dive in too deep, but I’m betting some jumpers could be added to modify the 16 CAS line generation circuit to only output 4 CAS lines by ignoring A19 & A20 right at the demux ICs, and the other CAS lines would never become selected.

If you were trying to make one aux board flexible for either DRAM density: in addition to the CAS generation changes, you would also need to generate both RA9 signals (one driven by DMA, the other driven by ~DMA) as well as mess with RA1 generation.

 

[Builder68]

Great work laying out these PCBs!

One thing I spotted is pin 1 on the aux board’s ‘253 should be connected to DMA instead of ~DMA. I think the ~DMA signal is also accidentally connected to a signal used as a pull up for a bunch of other inputs. Other than that, it looks good to me!

Thank you so much for catching that! I really appreciate your keen eye. The pin 1 connection has been corrected to DMA. It looks like we had a bit of a mix-up there. Your feedback is invaluable.

 

[Builder68]

Here is the multi-purpose aux board that gives the flexibility to choose the RAM refresh mode. ("Magic" Refresh, Mac Plus Refresh, or 1024 cycles Refresh Mode). For "Magic Refresh (SYSTEM RA0 & RA8)", don't need to populate any of the 74253s, 74257, inputs from J3, or any associated components. I just ordered the PCBs for this aux board and the 3.5 RAM expansion board for 512 refresh cycles. I will post the results when I test everything

Also, please note when selecting Magic or MacPlus refresh modes, the onboard system RAM is used and controlled by ~{MCAS2F} / ~{MCAS3F}, which are generated on the 512 RC Memory Board.

 

[Golden Potato]

Here is the multi-purpose aux board that gives the flexibility to choose the RAM refresh mode. ("Magic" Refresh, Mac Plus Refresh, or 1024 cycles Refresh Mode). For "Magic Refresh (SYSTEM RA0 & RA8)", don't need to populate any of the 74253s, 74257, inputs from J3, or any associated components. I just ordered the PCBs for this aux board and the 3.5 RAM expansion board for 512 refresh cycles. I will post the results when I test everything

Also, please note when selecting Magic or MacPlus refresh modes, the onboard system RAM is used and controlled by ~{MCAS2F} / ~{MCAS3F}, which are generated on the 512 RC Memory Board.

Excellent! Looking forward to seeing your results.

In the mean time, I’ve been slowly wiring up a soldered prototype for using two AS4C1M16F5 ICs for 4MB (disabling system 512K). I received them as well as the DIP breakout boards last week. We’re both working off very similar designs at this point, so I’m hoping to see both of ours work!

I’m definitely going to want one of those aux boards when it’s been tested. Since the aux board can work with other amounts of memory for memory upgrade mods, I think there could be a better suited thing to put on the silk screen besides “3.5 MB RAM For Macintosh 512K”, but I’m not sure what it is. I would use it for a full 4MB upgrade to bypass the onboard memory. Someone could also use it for only 2MB for example, but I’m not sure why one would go through the effort and not max out their memory

 

[demik]

I think all SCSI upgrade boards for the early Macs use Plus ROMS?

Someone successfully reverse engineered the MacSnap SCSI board:
https://68kmla.org/bb/index.php?threads/reverse-engineering-the-macsnap-scsi.37901/

It isn't successful, as unfortunately it still doesn't work, but that's off-topic

For the three different upgrades I have had my hands on, yes they all do use Mac Plus ROMs. The difference were on how they patched the ROM to make the SCSI contraption to work. They are not checking the RAM size at all, they are trying to read the ROM from the SCSI address range. If the data is the same than the ROM space, then there is no SCSI. If it's different, then SCSI is assumed to be present

By the way, I'm lurking this thread since the start, you guys are doing some incredible work. Dealing with DRAM is way above my skill levels.
This motivated me to try to finish my own stupid 1MB upgrade

 

[Golden Potato]

It isn't successful, as unfortunately it still doesn't work, but that's off-topic

For the three different upgrades I have had my hands on, yes they all do use Mac Plus ROMs. The difference were on how they patched the ROM to make the SCSI contraption to work. They are not checking the RAM size at all, they are trying to read the ROM from the SCSI address range. If the data is the same than the ROM space, then there is no SCSI. If it's different, then SCSI is assumed to be present

By the way, I'm lurking this thread since the start, you guys are doing some incredible work. Dealing with DRAM is way above my skill levels.
This motivated me to try to finish my own stupid 1MB upgrade

Interesting! So it’s essentially checking for ROM mirroring at the address at which the SCSI IC would reside. Getting back ROM data indicates ROM mirroring, thus no SCSI. Getting back something other than ROM data indicates no ROM mirroring, thus SCSI is present. Very clever!

I wish the creator of the ROMinator could revise their technique for determining whether the system is a Plus or not by using this approach rather than just checking the amount of RAM present.

We’re all learning here! I knew very little about DRAM circuits before diving into this. It’s kind of funny looking back at my first draft design just cramming together two other old memory mods documented online using the logic of “if this one worked, and this one worked, then putting them together this way should work” without really understanding how the Mac’s memory logic circuits really worked. One of the mods from which I was borrowing which is in the well distributed “early Macintosh tech info” PDF never could have worked. I’m a little bitter about that one! Also at the time I lacked understanding of required refresh cycles for various DRAMs as well as what the Mac was providing as refresh. This was the other major hurdle for me.

Working with Builder68 on this has been great for synergistic brainstorming, fault finding, and problem solving!

 

[SuperSVGA]

It wouldn't be too difficult to patch the ROM yourself, assuming you have some easy way of writing the changes to the ROM, either by programming the chips externally or with software on the Mac.

 

[Golden Potato]

It wouldn't be too difficult to patch the ROM yourself, assuming you have some easy way of writing the changes to the ROM, either by programming the chips externally or with software on the Mac.

The trick would be trying to fit this routine within the same number of bytes which the ROMinator uses for its routine. Or branch to some location in ROM which has enough unused space to fit this routine, making sure to return at the end of it. Also be sure to not destroy register data if that’s a concern with 68k code when branching (I don’t recall off the top of my head).

 

[SuperSVGA]

The trick would be trying to fit this routine within the same number of bytes which the ROMinator uses for its routine. Or branch to some location in ROM which has enough unused space to fit this routine, making sure to return at the end of it. Also be sure to not destroy register data if that’s a concern with 68k code when branching (I don’t recall off the top of my head).

There are around 24 bytes in just that space, or more if you get creative. Depends on what you want to do with it. You could patch the check out entirely and just hard code it, or find some reliable method of detecting what hardware you're on.

 

[Builder68]

I think there could be a better suited thing to put on the silk screen besides “3.5 MB RAM For Macintosh 512K”, but I’m not sure what it is. I would use it for a full 4MB upgrade to bypass the onboard memory. Someone could also use it for only 2MB for example, but I’m not sure why one would go through the effort and not max out their memory

How about this name instead?



I'm fixing some simple routing mistakes and a few minor improvements for the next batch.

First version of both boards fits nicely. I'm just starting with the testing, so far "Magic Refresh Mod" is working as expected.

 

[Builder68]

There are around 24 bytes in just that space, or more if you get creative. Depends on what you want to do with it. You could patch the check out entirely and just hard code it, or find some reliable method of detecting what hardware you're on.

I've actually got some experience programming Intel microcontrollers in assembler from the 80s, but I'm a bit lost when it comes to Mac ROMs.

I'd love to learn more about the specific software and tools needed to decode a Mac ROM and make the necessary changes. Could you point me in the right direction, or perhaps recommend some resources that could help me get started?

Since the ROM-INATOR came with two sets of ROM ICs, I think I could give it a try.

I think it would be sufficient to simply hardcode it to work on any 512K/800 Mac.

 

[Golden Potato]

How about this name instead?

View attachment 78343

I'm fixing some simple routing mistakes and a few minor improvements for the next batch.

First version of both boards fits nicely. I'm just starting with the testing, so far "Magic Refresh Mod" is working as expected.

Looks great! Can you test out the 512 and 1024 refresh modes? I understand your particular DRAM will not make use of the 1024 refresh mode since it doesn't have the extra address pin, but I'm curious to know if it all still functions okay.

I finally finished soldering up a prototype with my DRAM, and of course it doesn't work. Nothing on the screen, and no bong sound. Only a faint click from the speaker on reset. The power supply is getting a little strained as the voltage drops down to 4.6V. After some adjustment, I can get it to 4.75ish volts. Much above that, and the power supply goes into protect and the infamous "flubbing" occurs. There aren't any direct shorts, and my bench top power supply indicates it draws a little under 2 amps at 5 volts. I'm sure I made a mistake or two, but it will take a long time going through the schematic and checking it over with a DMM. I have so little time to dedicate to this lately, so I'm wishing I had just put together a PCB layout with which to prototype instead.

When you're ready for a beta tester for the DRAM Refresh Rate Tweaker, I would happily accept that role!

 

[Golden Potato]

I downloaded the ROM-inator patch and dissembled it and it seems it checks to see if there's more than 512KB of RAM unfortunately...

    clr.w   HwCfgFlags
    nop
    nop
    nop
    cmpi.w  #$8,MemTop
    ble.b   .noSCSI
    move.b  #1<<hwSCSI|1<<hwClock,HwCfgFlags
.noSCSI:

Where did you find the ROM-inator patch? I can only find fully patched ROMs. Is that what you meant?
I wish the source code for that project was made available.

In either case, for those who have a 512K/128K with greater than 512KB of RAM and want to use the ROM-inator, it should be trivial to patch the patched ROM to hard code it to always branch to .noSCSI instead of doing so based on the condition of greater than 512KB of RAM.

This might work:

    clr.w   HwCfgFlags
    nop
    nop
    nop
    cmpi.w  #$8,MemTop
    bra.b   .noSCSI
    move.b  #1<<hwSCSI|1<<hwClock,HwCfgFlags
.noSCSI:

Based on your disassembly, can you provide the address for the byte which must be changed from 0x6F (BLE.b instruction) to 0x60 (BRA.b instruction). I think the byte following the BLE.b instruction containing the offset should remain the same?

In the end, I think two versions of the ROM-inator should exist regardless of the amount of RAM: one for systems with SCSI, and one for systems without SCSI. That is unless the work of implementing a more elegant check for SCSI hardware is done (such as a ROM mirroring check).

https://web.njit.edu/~rosensta/classes/architecture/252software/code.pdf

https://www.nxp.com/docs/en/reference-manual/M68000PRM.pdf

 

[Joopmac]

Wow that would be awesome

 

[SuperSVGA]

I'd love to learn more about the specific software and tools needed to decode a Mac ROM and make the necessary changes. Could you point me in the right direction, or perhaps recommend some resources that could help me get started?

For disassembling the ROM I would recommend using Ghidra, it nearly works out of the box, though you will need to deal with Line A instructions in some way. There are a few different patches around online that you can add to the disassembler, or you can do it by hand just setting each one as a word data type when you encounter them.
Disassembling Mac ROMs is probably deserving of a much more in depth tutorial, but if you have any questions feel free to ask.

Where did you find the ROM-inator patch? I can only find fully patched ROMs. Is that what you meant?

I just used the fully patched ROM that's available from the website.

Based on your disassembly, can you provide the address for the byte which must be changed from 0x6F (BLE.b instruction) to 0x60 (BRA.b instruction). I think the byte following the BLE.b instruction containing the offset should remain the same?

That should be at 0x4003F0 from the system's point of view, or if you are reading the ROM file itself it is just 0x0003F0.

 

[Builder68]

This might work:

    clr.w   HwCfgFlags
    nop
    nop
    nop
    cmpi.w  #$8,MemTop
    bra.b   .noSCSI
    move.b  #1<<hwSCSI|1<<hwClock,HwCfgFlags
.noSCSI:

Golden Potato, I've tried your proposed ROM patch and can confirm that it works as intended! Now my Mac 512K boots with a 1.5MB RAM expansion and the ROM-INATOR. Once again, you nailed it!

Joopmac, here is the patched ROM image and its full disassembly. I burn it with Flash Tool 1.5 directly on the Mac. Use it at your own risk!

SuperSVGA, thank you very much to dig into the ROMINATOR ROM and directly point out where the problem was, thanks also for your recommendation. Later I step up with FDSIMAN and love the fact it runs on the Mini vMac.