Skip to main content
Home Forums 68kMLA original Mac interleaved memory controller details — #13
Post #13 by trag
Source Forum68kMLA
CategoryTroubleshooting
Post DateMon, 29 Aug 2011 - 19:56
Original URLhttps://68kmla.org/bb/threads/original-mac-interleaved-memory-controller-details.23767/
Post
Wow, those schematics are fantastic, thanks! Even if it doesn't show what's inside the PAL's, the timing diagrams showing the relevant signals will be a huge help. Now I just need to digest this all.
I believe that the PAL info is available in one of the archived articles at MacTech magazine. I may be misremembering the source, but I know I found Macintosh PAL files on line somewhere. Hmmm. MacRescue maybe?

It appears that the DRAM in the original macintosh had separate Din and Dout pins. Since the CPU would be the only thing ever writing to RAM, that explains why I didn't see any buffer for the CPU writing to RAM: none was needed. So that's one mystery solved, at least. I'll be using SRAM that has a single bidirectional data bus though, so I'll need to buffer in both directions.
Yep, the one-bit DRAM chips have separate Q and D pins. The 30 pin SIMM ties them together into a single D/Q line, so it's (mostly) irrelevant on later machines with SIMMs.

But....

On the Mac IIfx, Apple built their own 64 pin SIMM, which has separate D and Q pins. And the memory subsystem in the IIfx has latches on the branch to the Write data bus. So, when the IIfx writes to RAM, the memory controller activates the latches, storing the write data and then signals the CPU that the write is complete, saving about four cycles over making the CPU wait while the data is actually written to the RAM.

While the CPU goes off to do other things, the memory controller uses the latched data to write it into the RAM using those distinct Q pins. Activity on the data bus doesn't impinge on this RAM write activity because they are separate data busses, provided that the CPU doesn't try to read from the RAM. But if the CPU attempts a RAM Read, the memory controller presumably just stalls it until the RAM is available.

When I built IIfx SIMMs, I wanted to use modern 4-bit wide DRAM chips, which do not have separate D and Q pins. I found that a pair of octal Bus Switches per SIMM controlled by the WE_ signal solved my problem nicely.

I don't have the part number handy at the moment -- ah found it on my Ebay image for the SIMMs...

http://www.prismnet.com/~trag/IIfx/IIfx_Rev2_Front.jpg

SN74CBT3244C The datasheet at TI:

http://www.ti.com/lit/ds/symlink/sn74cbt3244c.pdf

Bus switches are bi-directional. So, what you do is tie the B side pins together. 1B1 to 2B!, 1B2 to 2B2, 1B3 to 2B3, 1B4 to 2B4, or you can tie the A side together. Doesn't matter which.

Then use the OE_ signals to control whether 1A or 2A is getting the connection. It's sort of like a bi-directional MUX. You'll want to invert the control signal and give 1OE_ the positive (or negative) signal and 2OE_ the negative (or positive) signal. I just used a little SC-70 packaged inverter for that.

So, you hook the tied side of the switches to your SRAM data pins. Hook 1A to the video circuitry and hook 2A to the CPU bus. Then use whatever logic makes sense to control 1OE_ and 2OE_.

That should be a little simpler than using buffers in both directions -- or it may at least reduce your chip count.

The CPU can't write to the memory while the video circuitry is reading it anyway, so this doesn't cause any problems as long as you can find a good control signal for the two OE_s.

Very cool project by the way.

mp.ls