68kMLA Classic Interface

This is a version of the 68kMLA forums for viewing on your favorite old mac. Visitors on modern platforms may prefer the main site.

Click here to select a new forum.
Why not a Static RAM board for 128k Mac?
Posted by: JustDaveIII on 2026-04-04 17:33:59 I have a silly question. But first, I am grateful for all the work put into the memory expansion board detailed here in another thread. Thank You! I have been designing logic circuits since the RTL / ECL days, modifying motherboards and also do assembly language on multiple platforms. So I know the effort that was needed here. Now for the silly question. Why not a static ram memory expansion that uses the ROM sockets for address & data lines? 4mb (256kx16) static ram chips are cheap. Not like in the old days when I was buying 1k x 4 2114's for $5 each. Is it not possible to map some static memory from 128k - 512k by grabbing the address (and extra ones that are not to the ROM sockets) and R/W lines ? Like the Rominator? Static memory has like, 10ns access time vs the 450ns of the ROM and the 200ns access (335ns cycle time) of the 4864 chips. So I don't see that as a hurdle. So please point me in the right directions so I don’t go down the rabbit hole on my next project. What am I missing? Why do I want to do this? I have an original Mac128k board. It's been sitting around since late last century. I've added the PiPico vga adapter, my own PS/2 mouse & keyboard adapter, Floppy EMU and more. But I don't want to alter the board as there are very few untouched original 128k boards left. Yet I need more memory for System 6/7 and to play Dark Castle II. ETA: I've written a lot of 68xxx code for Mac and was Mac / Newton Developer a long time ago.
Posted by: Builder68 on 2026-04-05 17:42:34 I have a silly question. But first, I am grateful for all the work put into the memory expansion board detailed here in another thread. Thank You! I have been designing logic circuits since the RTL / ECL days, modifying motherboards and also do assembly language on multiple platforms. So I know the effort that was needed here. Now for the silly question. Why not a static ram memory expansion that uses the ROM sockets for address & data lines? 4mb (256kx16) static ram chips are cheap. Not like in the old days when I was buying 1k x 4 2114's for $5 each. Is it not possible to map some static memory from 128k - 512k by grabbing the address (and extra ones that are not to the ROM sockets) and R/W lines ? Like the Rominator? Static memory has like, 10ns access time vs the 450ns of the ROM and the 200ns access (335ns cycle time) of the 4864 chips. So I don't see that as a hurdle. So please point me in the right directions so I don’t go down the rabbit hole on my next project. What am I missing? Why do I want to do this? I have an original Mac128k board. It's been sitting around since late last century. I've added the PiPico vga adapter, my own PS/2 mouse & keyboard adapter, Floppy EMU and more. But I don't want to alter the board as there are very few untouched original 128k boards left. Yet I need more memory for System 6/7 and to play Dark Castle II. ETA: I've written a lot of 68xxx code for Mac and was Mac / Newton Developer a long time ago. I think IMHO the major hurdle is that mapping continuous system RAM through the ROM sockets is essentially impossible because you cannot isolate the bus or change the address decoding without altering that beautiful, untouched 128K motherboard. The Mac 128K doesn’t have a dedicated video controller with its own VRAM. Instead, the 68000 CPU and the video/sound hardware share the exact same physical DRAM. The bus timing is strictly interleaved: One cycle goes to the video/sound circuits to fetch data for the screen, and the next cycle goes to the CPU. Since the video circuits are hardwired to pull data directly from the onboard DRAM space, any memory you map elsewhere (like the ROM sockets) is invisible to the video hardware. You couldn't really use that SRAM for the frame buffer since the ROM pins the video address to the top 32 KB of whatever RAM it detects. To make it work, your expansion would have to 'bank-switch' back to the onboard DRAM for video (which is how most old-school accelerators handled it), or you'd have to replicate the Mac's internal decoding so the CPU can find the video buffer at the top of your new SRAM, much like a MacSnap does.
Posted by: JustDaveIII on 2026-04-07 14:28:21 Thanks for you insights. Yup, I’m well aware of the video circuitry and how it functions. I don’t intend to replace the 128k existing memory so the screen / audio / etc. buffers stay where they are. My initial thought is to map the new ram at $500000 (or other free area). I’d use the ROM data and A1-A16 address lines. The stock roms use A21 to their CE input to select them at $400000 & shadow areas. Rominator grabs the A17-19 lines via clips to use it’s entire rom area. To map the ram at $500000 I’d grab the A17-23 address lines and do the same with the CE / OE new ram inputs, with probe clip(s) to the cpu along with the R/W, AS lines. I do need to scope out the DTACK line & maybe the AS for timing. I’d hope DTACK has the same timing via BMU1 / TMS when my new memory is addressed. I think it must generate a signal no matter what address is accessed or the cpu will hang when a non-memory area is accessed? I’ll look at the datasheet timing diagrams & specs. Reading an artical at BMOW leads me to think the DTACK line timing is fixed, no matter what the memory address is. I don’t have much concern about the R/W line timing for writing but will scope it out. Ok, now I’ve got memory I can read / write to I need to do some patch work. Ideally, I’d like to just move the Application Zone to the new memory. The AZ in initialized (but not defined) when the Finder launches a program so I need look at where it’s setup and perhaps patching the InitApplZone trap (A02C) & others and a few system globals. I think an INIT ought to be able to do this. Another way might be to relocate the entire heap (System & Application Zones) to the new memory. That may be the simplest way as from what I see is that the start of the Application Zone is end of the System Zone and I don’t see a way to mark / define the end of the System Zone independently. I know where the low memory global addresses for the heap / zones are, now to find where they are setup. From a quick check in the disassembled rom file I see many of them accessed but not where they are set so that means they are set via the O/S. Upon further discovery, I find them set in the boot block code of the disk. Either way, I’ll first try them out in an emulator / debugger. Or maybe I map 384k of memory at the 128k point. See this: https://macgui.com/news/article.php?t=470 and scroll to the “Donald North of Apple Computer” part where it talks about the screen placement hardware. This would involve grabbing the actual address & control lines of the dram banks & demuxing them. But if I do that, might as well see if I can do the whole 1MB address space. Other parts of that article talk about relocating the Application Zone (maybe the entire Heap?) to above the screen/sound/disk speed area. I just may have to get a 512k board and & use the 128k/512k switcher board to test out my static ram modifications. So much fun to do!
Posted by: Builder68 on 2026-04-07 18:40:43 Thanks for you insights. Yup, I’m well aware of the video circuitry and how it functions. I don’t intend to replace the 128k existing memory so the screen / audio / etc. buffers stay where they are. That’s the heart of the challenge! While leaving the 128K DRAM alone for the video hardware seems logical, it creates a non-contiguous memory map that the ROMs just weren't designed to handle. Unlike a generic 68000 machine, these Macs require a single, unbroken block of RAM starting from $000000 to function correctly. A ROM patching approach is particularly difficult because you’d have to fight both the software's expectations and the hardwired memory management logic inside the PAL chips. I'd definitely recommend checking out the "Total System Mercury" 68030 accelerator and its companion RAM expansion board. Both are currently being reverse-engineered as open-source projects. These boards use some clever logic to fool the ROM during the boot stage when the system probes for RAM size; they essentially re-route buffer accesses back to the motherboard DRAM while sending the rest of the memory traffic to the expansion's high-speed 32-bit RAM—all without ever needing to patch the ROMs. My initial thought is to map the new ram at $500000 (or other free area). I’d use the ROM data and A1-A16 address lines. The stock roms use A21 to their CE input to select them at $400000 & shadow areas. Rominator grabs the A17-19 lines via clips to use it’s entire rom area. To map the ram at $500000 I’d grab the A17-23 address lines and do the same with the CE / OE new ram inputs, with probe clip(s) to the cpu along with the R/W, AS lines. I do need to scope out the DTACK line & maybe the AS for timing. I’d hope DTACK has the same timing via BMU1 / TMS when my new memory is addressed. I think it must generate a signal no matter what address is accessed or the cpu will hang when a non-memory area is accessed? I’ll look at the datasheet timing diagrams & specs. Reading an artical at BMOW leads me to think the DTACK line timing is fixed, no matter what the memory address is. I don’t have much concern about the R/W line timing for writing but will scope it out. Ok, now I’ve got memory I can read / write to I need to do some patch work. Ideally, I’d like to just move the Application Zone to the new memory. The AZ in initialized (but not defined) when the Finder launches a program so I need look at where it’s setup and perhaps patching the InitApplZone trap (A02C) & others and a few system globals. I think an INIT ought to be able to do this. Another way might be to relocate the entire heap (System & Application Zones) to the new memory. That may be the simplest way as from what I see is that the start of the Application Zone is end of the System Zone and I don’t see a way to mark / define the end of the System Zone independently. I know where the low memory global addresses for the heap / zones are, now to find where they are setup. From a quick check in the disassembled rom file I see many of them accessed but not where they are set so that means they are set via the O/S. Upon further discovery, I find them set in the boot block code of the disk. Either way, I’ll first try them out in an emulator / debugger. Or maybe I map 384k of memory at the 128k point. See this: https://macgui.com/news/article.php?t=470 and scroll to the “Donald North of Apple Computer” part where it talks about the screen placement hardware. This would involve grabbing the actual address & control lines of the dram banks & demuxing them. But if I do that, might as well see if I can do the whole 1MB address space. Other parts of that article talk about relocating the Application Zone (maybe the entire Heap?) to above the screen/sound/disk speed area. I just may have to get a 512k board and & use the 128k/512k switcher board to test out my static ram modifications. So much fun to do! That’s an ambitious workaround! The main hurdle you’ll run into is that the Macintosh Memory Manager is a strictly linear, single-block allocator. Because this architecture is pre-MMU, the manager is essentially blind to hardware gaps. The real challenge is how you would fool the Memory Manager during heap compaction or the moment the Stack grows down. By the time the boot code executes, the ROM has already sized the machine and initialized the Trap Table and Interrupt Vectors in the 128K DRAM. Trying to patch around that is a massive challenge because the OS core and the Application Zone end up stranded on different islands. Moving to a 512K board is a really smart move for testing. It’ll give you the perfect sandbox. It’s definitely a deep rabbit hole, but it could easily be one of the most rewarding puzzles to solve for someone with your background! Have you checked the logic of the Dove MacSnap board? It has also been reverse-engineered and is open-source. The CAS generation logic is exactly what you need for your SRAM OE (Output Enable) inputs. It already solves the problems with CPU/Video interleaving since you would actually be using the original hardwired memory manager logic, and the buffers would be allocated in your new SRAM. You would need to tap fewer address bits and wouldn't have to deal with complex timings. Certainly, it would not require any intervention on the 128K board. The MacSnap logic uses a clever trick to tap the CAS signals that keeps the onboard DRAM functional while your SRAM fills the rest of the RAM space (at least for the 512K models—I haven't checked what changes when the jumpers are set for the 128K). Probably that is no fun for you, though, since it completely avoids going deep into the rabbit hole with the ROMs 😉! One more thing: to avoid overloading the data bus on the ROM side and running into nasty signal integrity issues, I would tap the data bus from the data output buffers and forcibly add input buffers to isolate the SRAM.
1