• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

original Mac interleaved memory controller details

bigmessowires

Well-known member
Hi! I'm seeking any and all details about the memory controller on the 128K, 512K, and Plus. This was some custom circuitry implemented in PALs that facilitated sharing of RAM between the 68000 and the video circuitry. I know the basic principle was that when the video circuitry was accessing RAM to fetch pixel data, the CPU was somehow made to wait. But that's about all I know.

How exactly was the CPU made to wait?

How exactly was time divided between the CPU and the video circuitry?

How were CPU bus cycles kept synchronized with the time division pattern?

How were the CPU address and data busses isolated from the RAM?

I've looked at the Mac 512K schematics, but they don't really answer my questions. For example, I see a pair of LS244's at locations 12E and 13E used to drive RAM data onto the CPU data bus, but nothing that drives data in the opposite direction, which would be necessary for CPU writes to RAM.

In the absence of details on the original memory controller, I've attempted to design my own for my Plus Too project (a hardware clone of the Mac 128K, 512K, and Plus). You can read about my memory controller design here. Any feedback you have on the design is very welcome!

 

Trash80toHP_Mini

NIGHT STALKER
The best info is probably in Guide to the Macintosh Family Hardware Second Edition or the First Edition, which might be a little more reasonable in price.

If you haven't got GttMFH2E, I'll check to see if there might be scans of the Memory Section available somewhere. ;)

 

PowerPup

Well-known member
Well it turns out our own member H3NRY made schematics back in 1984 with MacDraw.

JDW has made a PDF of the schematics for modern viewing.

We're all very excited about your "Plus Too" project. And I'm sure most of us will be watching your site frequently for updates. ;)

Edit: Oh, just found this topic discussing "128K Vs. 128k/512K Logicboards."

 
Last edited by a moderator:

Gorgonops

Moderator
Staff member
I don't know much about the 68000's bus cycle (it's considerably more complicated than the 8 bit CPUs I semi-understand), but looking at the 68000 data sheet and how the 68000 is wired up in the Mac if I had to take a wild guess it may be possible to pause the CPU for at *least* one cycle using the /DTACK signal. (There's a section in the manual explaining how the 68000 can operate in either "synchronous" or "asynchronous" modes.) One thing they're not doing is using the multi-busmaster arbitration support, as it looks like all those lines are tied off, and HALT shows as being tied to RESET.

(That "schematic" really is pretty useless in some respects. It might help with troubleshooting a unit, but what you want to see is the *details* of the DRAM controller and any details on that are completely absent. Undoubtedly it's all tied up in the PALs.)

And... I just loaded the URL to your independently cooked-up design. I'm sort of an idiot but it looks good to me. ;^)

(I assume you're planning to simplify things and just use SRAM in your replica instead of bothering with DRAM?)

 

bigmessowires

Well-known member
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.

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.

Never heard of Guide to the Macintosh Family Hardware before, but it sounds like I should pick up a copy. Are there any important differences between the first and second editions?

 

PowerPup

Well-known member
After doing some more googling all I could come up with was this: http://retro.co.za/ccc/mac/index.html

He mentions someone called "Kryten Droid" who made some info on the PALs, but the link to Kryten's website is dead. And web.archive.org only has the homepage and directory of the files. Not the actual .htm files themselves.

 

Gorgonops

Moderator
Staff member
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.
Wait, where did you see that? The pinout on the hand-drawn psuedo-schematic matches that of a standard 4164. (And actually it appears to match up on the CAD one as well.)

I'm a little puzzled why you'd need a buffer with your SRAM. If the CPU has the ability to wait by manipulating the /DTACK line and holds the contents of its data bus constant until it receives acknowledgement of a successful data transfer then it seems all you'd need to do is tell the CPU to hold its horses whenever the RAM is occupied loading the video shift register. You will of course need a MUX on the address lines so you can timeshare the RAM's address pins between the CPU bus and the video address generator. (I'd *guess* the '253s in the lower left of the PDF schematic might serve that purpose on the original.)

EDIT: No, wait, I was thinking something else when you said "buffer". It does seem like you'll need a selector to keep the CPU from seeing data destined to the shift register, wouldn't you? The only thing I can think of is perhaps in the Mac's design it doesn't *matter* if it sees it? That could be the case if the CPU ignores the state of the data lines until it gets a valid data transfer acknowledgement.

 

bigmessowires

Well-known member
Sorry, by "buffer" I meant a bus driver, like a 74LS244 or '245.

As far as the seprate Din and Dout pins, I could be wrong here. I just googled the 4164 DRAM datasheet and looked at the pin configuration: http://www.speccy.org/hardware/datasheet/4164.pdf

You need a bus driver to isolate the CPU data bus from RAM output, so the CPU can read/write to peripherals or ROM without interference even while the RAM is outputting pixel data for the video circuitry. It should drive data from the RAM output to the CPU data bus only when the CPU is reading from RAM.

If RAM input and output are physically separate lines, as the above datasheet shows, then that's all you need. But if RAM has just a single "data" line that's used for both input and output, which is the case for all the SRAM I'm familiar with, then you'll also need a second bus driver working in the opposite direction, driving data from the CPU data bus to the RAM data lines. Without a bus driver working in that direction, when using SRAM and its single data line, there would be no way to to get data from the CPU into RAM.

A '245 bidirectional bus driver could meet both needs, but the Mac schematic shows it uses the unidirectional '244 instead, which is what leads me to believe the DRAM has separate data input and output lines.

EDIT: Looking at http://www.digibarn.com/collections/diagrams/mac-512klogicboard/mac-logic-schematic.jpg again, you can see the DRAMs at the bottom center, and they do in fact have separate D inputs and Q outputs.

 

Gorgonops

Moderator
Staff member
Oh, you're right about the 4164. I'm just blind.

It still seems like a somewhat strange design. I've been repairing a broken Commodore PET 2001-N for the last few months (yes, it has a *lot* wrong with it), and I recalled it used a pair of 74LS244s in front of the DRAM bank wired so they're bi-directional. (The data pins on both sides are tied to a pair of opposite-facing bus drivers and the enable lines for the two sets are tied to "READ" and "WRITE" signals respectively. See:

http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/2001N/320349-5.gif

The PET has a number of sets of 244's wired like this. There's a "main set" in front of the 6502 which are always-on drivers, and then there are sets tied to read/write and chip select circuitry in front of main RAM and the video subsystem.)

I guess what I also half-remembered was... looking at the schematics again, the DI and DO lines of its DRAMs (4116's, but very similar to 4164s) are *also* tied together and share a single bi-directional line from the DRAM sockets. Thus I remembered a "single line" but failed to remember that it originated from two pins, leading me to faultily assume that DRAMs "breathed in and out" the same line like SRAM. My bad.

Now the fact that there's two sets of "busses" above and below the DRAM chips on the Mac schematic makes a lot more sense to me. Durrr! Sorry about that. :^/ I'll put my pointy hat back on.

 

Trash80toHP_Mini

NIGHT STALKER
GttMFH2E only covers Plus -> IIfx, you'll need the first edition of GttMFH for info 0n 128-512ke . . .

. . . I KNEW I should have bought it off eBay!
vent.gif


 

dougg3

Well-known member
Correct me if I'm wrong, but I believe the first edition of Guide to the Macintosh Family Hardware is actually called "Macintosh Family Hardware Reference". Am I right? These recently ended eBay listings seem like it:

http://www.ebay.com/itm/1988-Macintosh-Family-Hardware-Reference-128K-Mac-II-SE-/280724408410

http://www.ebay.com/itm/1988-Macintosh-Family-Hardware-Reference-Mac-SE-128K-/370534665458

They didn't sell, so maybe the sellers still have them? Also, it looks like Amazon has several reasonably-priced used copies of it. That may be the way to go to get it...

 

trag

Well-known member
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.

 

bigmessowires

Well-known member
When I built IIfx SIMMs
What?!? :)

Wow, you built your own SIMMs? That is pretty amazing, but why? Just for the heck of it, or was it more economical than purchasing commercial ones at the time?

 

trag

Well-known member
When I built IIfx SIMMs
What?!? :)

Wow, you built your own SIMMs? That is pretty amazing, but why? Just for the heck of it, or was it more economical than purchasing commercial ones at the time?
Macintosh IIFX SIMMs are odd birds used only in the IIfx and in one of the LaserWriter printers. So they are not commonly available. Even the 1 MB SIMMs are rather hard to find.

Their maximum capacity is 16MB per SIMM, just like a 30 pin SIMM, but DRAM chips to build that capacity were not available when the IIfx was a current model computer.

So, I built 16 MB SIMMs for the IIfx to take the machine to its maximum of 128 MB of RAM.

BTW, email me if you want what I have on the PALs. I suspect it's incomplete, but it's better than nothing. Now I wonder where I got it, as I can't find it on-line again.

 

wrm

New member
After doing some more googling all I could come up with was this: http://retro.co.za/ccc/mac/index.html
He mentions someone called "Kryten Droid" who made some info on the PALs, but the link to Kryten's website is dead. And web.archive.org only has the homepage and directory of the files. Not the actual .htm files themselves.
That would be me :)

I have Kryten's pages as well as Jecel (the fellow in Brazil who gave the info to Kryten) mirrored. The thread that started it all is here

http://www.fpgarelated.com/usenet/fpga/show/18121-1.php

I'm reverse engineering the PALs on my Mac Plus, just for fun. Either I have a bad connection on the Expro ZIF socket, or half of the BMU1 PAL is unused. Once I have the correct equations for BMU1 and CAS I'll move on to the registered PALs -- that's bound to be fun.

My web page on this is a bit immature for release, but I'll link it in when there's something useful there.

 
Top