Why not a Static RAM board for 128k Mac?

[JustDaveIII]

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.

 

[Builder68]

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.

 

[JustDaveIII]

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!

 

[Builder68]

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.

 

[JustDaveIII]

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.
...
The main hurdle you’ll run into is that the Macintosh Memory Manager is a strictly linear, single-block allocator.

I dissagree abit about that.

While the Memory Manager does indeed work on only a single continious block, it's actually a single Zone that it operates on, and that's a continious block. There is the System Zone and Application Zone. Even within each, there can be sub-Zones. There are traps to change what Zone the MM currently works on.

The trap of _SetAppBase allows the changing of the Application Heap Zone location. I presume that's done by MacMemory - see the diagrams in the artical I mentioned before. I'd like to find if there is an INIT for the MacMemory board or if it has altered ROM's.

I looked at the code for _SetAppBase and possibly see a bug. This is when, at the start of the code, it looks to see that the requested new starting location is below the start of the Application Zone and if so exits without changing it. It actually looks at the start of the System Zone. I saw this in System 6.x and earlyer. If this is indeed a bug, I think no one would care because no one would dare try to set it like that and if they did a crash very soon would happen.

My next chore (using the snowemu emulator - very nice!) will be to see what happens when I change the location of the AZ to a higher location and then ask the MM to increase the size of the System Zone and see if it expands into the previous lower portion of the AZ or not. For this I'll be looking at the _InitZone & _SetApplLimit traps and PROCEDURE MaxAppl Zone. I'll copy my code to the alternate screen buffer to execute it. I've downloaded and got runnning MacAsm - which I used in the late 1980's to write a MacDraw like CAD program, so I don't have to hand code assembly.

In my reading about boot block code, It looks like the System Zone is, no matter what O/S (1-6, maybe 7) and/or a 128k or 512k machine is always set to the same location & size, so I'm not so sure that it will expand. Gosh that would be nice!

Have you checked the logic of the Dove MacSnap board?

Yes, but not in detail. I'll look at it some more.

Probably that is no fun for you, though, since it completely avoids going deep into the rabbit hole with the ROMs !

But it would be! Gotta keep the old(er) brain active

One more thing: to avoid overloading the data bus on the ROM side ...

Thanks for the reminder about this!