Why not a Static RAM board for 128k Mac?

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 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.
 
Last edited:
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!
 
Back
Top