Memory Map of the very first (128k) Macintosh, Byte, February 1984
The Compact Mac is getting close to thirty years old. In these thirty years, nobody seems to have completely reverse engineered the PALs. Or rather, of course people must have, but that information is not on the net. The closest is Jecel's information, solicited by Grant and Kryten -- Kryten's website has since disappeared, but I kept a copy. I also have a copy of Jecel's pages from the Wayback machine.
Firstly, the easy ones. BMU1 and CAS are non-registered devices. They have no memory, and can be reverse-engineered quite easily.
But first, some background info.
Memory Map of the very first (128k) Macintosh, Byte, February 1984
The 128k and 512k Macs have BMU0 and BMU1 PALs, with BMU0 being a registered PAL responsible for wait states etc. In the Mac Plus this becomes BMU1 (with the same pinout / pin assignment as the 128k Mac) and BMU2. The Mac Plus also adds a CAS PAL which controls the four SIMMs.
| /AS | I | 11 | 10 | GND | ||
| /IWM | O | 12 | 9 | I | A21 | |
| /SCCRD | O | 13 | 8 | I | A22 | |
| /SCCEN | O | 14 | 7 | I | A23 | |
| /VPA | O | 15 | 6 | I | OVERLAY | |
| /ROM | O | 16 | 5 | I | L13 | |
| /RAM | O | 17 | 4 | I | /VCA | |
| VC0 | O | 18 | 3 | I | VA6 | |
| VC1 | O | 19 | 2 | I | VA7 | |
| Vcc | 20 | 1 | I | VA8 |
OVERLAY is a signal from PA4 on the 6522. It's used to map the ROM to address zero after reset, once the code starts executing it jumps to $40 0000 (128k Mac) and then RAM is mapped into 0.
L13 comes from the video circuitry, as does VA6..VA8.
/VCA comes from BMU2 (BMU0 on the 128k Mac).
From Jecel's notes,
/IWM := A23 * A22 * /A21 * /AS ; 0xC0 0000 - 0xDF FFFF (0xDF E1FF)
/SCCRD := A23 * /A22 * /A21 * /AS ; 0x80 0000 - 0x9F FFFF (0x9F FFF8)
/SCCEN := A23 * /A22 * /AS ; 0x80 0000 - 0xBF FFFF (0x9F FFF8 - RD, 0xBF FFF9 - WR)
/VPA := A23 * A22 * A21 * /AS ; Synchronous I/O (6800 style) 0xE0 0000 - 0xFF FFFF
/ROM := /A23 * A22 * /A21 * /AS ; 0x40 0000 - 0x5F FFFF
+ /A23 * /A22 * /A21 * /AS * OVERLAY ; 0x00 0000 - 0x1F FFFF when OVERLAY enabled
+ A23 * /A22 * /AS ; 0x80 0000 - 0xBF FFFF
+ A23 * /A21 * /AS ; 0x80 0000 - 0x9F FFFF and 0xC0 0000 - 0xDF FFFF
/RAM := /A23 * /A22 * /A21 * /AS * /OVERLAY ; 0x00 0000 - 0x1F FFFF
+ /A23 * A22 * A21 * /AS * OVERLAY ; 0x60 0000 - 0x7F FFFF when OVERLAY is enabled
VC0 :=
VC1 :=
| TSEN2 | I | 13 | 12 | GND | ||
| RAMSIZE | I | 14 | 11 | I | ROWS | |
| /ROMCE | O | 15 | 10 | I | /CASH | |
| OVERLAY | I | 16 | 9 | I | /CASL | |
| /CAS0L | O | 17 | 8 | I | VID/u* | |
| /CAS0H | O | 18 | 7 | I | C2M | |
| /CAS1L | O | 19 | 6 | I | A23 | |
| /CAS1H | O | 20 | 5 | I | A22 | |
| /SCSI | O | 21 | 4 | I | A21 | |
| /DACK | O | 22 | 3 | I | A20 | |
| /AS | I | 23 | 2 | I | A19 | |
| Vcc | 24 | 1 | I | A9 |
On the 24 pin (20x8) PALs pin 13 is TSEN / TSEN2 / TSEN3. These are all just pulled low via a 150 ohm resistor.
RAMSIZE and ROWS come from two jumpers, R8 and R9 if fitted will drive these pins low.
/ROMCE is the ROM /CE line (/ROM is something else). On the Plus, A17 is connected to the ROM /OE so take that into consideration when computing memory maps.
/SCSI and /DACK go to the 5380 SCSI controller.
/CASL and /CASH are from the TSM, and /CAS0L|H|1L|H are the CAS signals for the four SIMMs.
OK, so one Saturday morning I sat down with my Expro 80 EPROM programmer and the source code to ALL03, and modified the pic16x8y file to apply the 1024 possible combinations to the input pins of a 16L8 and to read the one byte output.
Of course I didn't want to risk my Mac PALs so I started with the PAL from an Archimedes 310, which incidentally doesn't have the security fuse blown like the Mac PALs. That looked OK, so I swapped in the BMU1 PAL.
bmu1.txt : inputs are pins 1-9, 11 and outputs are pins 12-19.
Right now my code is a complete kludge, it starts by applying all the inputs and reading all the outputs, which is fair enough. It then does a search to check which outputs change in response to which inputs -- or rather, which outputs don't change in response to a changing input. After that I construct vectors using only the bits that matter for a particular output. Even though the code is klunky, the result is quite usable, telling us that (in this case, i.e. Mac Plus)
One thing to keep in mind here is that on the Plus, /ROM and /RAM are not the actual chip selects, some further logic happens in the TSM. As a matter of fact, /ROMCE comes from the CAS, which doesn't even use /ROM as an input. Go figure.
Next up, the CAS 20L8. More inputs, and less outputs -- one of the possible outputs is used as an input. I tried to change my code in such a way that it supports both the 16L8 and 20L8 PALs, i.e. have a #define section assigning the power pin, defining the number of input and output pins and the pin mapping, etc.
This is what I got: cas.txt. There's some strange stuff here, I'm not too sure my code is working right. Time will tell.
| /TSEN0 | /OE | 13 | 12 | GND | ||
| /TSEN0 | I | 14 | 11 | I | /DMA | |
| RA8 | O | 15 | 10 | I | C2M | |
| /245OE | O | 16 | 9 | I | R/W | |
| VA13 | R | 17 | 8 | I | L13 | |
| VA12 | R | 18 | 7 | I | L12 | |
| /VCA | R | 19 | 6 | I | VA11 | |
| /VIDOUT | R | 20 | 5 | I | VA10 | |
| RAM R/W | O | 21 | 4 | I | VA9 | |
| SERVID | I | 22 | 3 | I | /ROM | |
| /DTACK | I | 23 | 2 | I | /RAM | |
| Vcc | 24 | 1 | CLK | C16M |
SERVID from the dual LS166 video shifters and VIDOUT to the monitor.
The LAG can probably be described as the heart of the Macintosh.
LAG is a 16R8 device which performs the majority of the video control functions. It has as inputs most of the video address counter outputs, which are decoded to create output signals which load the video shift register, provide the CRT sweep circuitry with horizontal and vertical syncs, increment and reset the video address counters, and switch the RAM address multilplexers between CPU, video, and sound addresses. Source
| /TSEN | /OE | 11 | 10 | GND | ||
| /LDPS | R | 12 | 9 | I | VA0 | |
| /NSYNC | R | 13 | 8 | I | VA1 | |
| /HSYNC | R | 14 | 7 | I | VA2 | |
| VID/u* | R | 15 | 6 | I | TC | |
| H4 | R | 16 | 5 | I | C1M | |
| /DMA | R | 17 | 4 | I | VA3 | |
| RESLYN | R | 18 | 3 | I | VC1 | |
| RESNYB | R | 19 | 2 | I | VC0 | |
| Vcc | 20 | 1 | CLK | C16M |
A 16R8 has eight (+ a clock) inputs and eight outputs.
Clock: C16M
Inputs: VC0, VC1, VA0, VA1, VA2, VA3, TC, C1M
Outputs: /LDPS, /VSYNC, /HSYNC, VID/u*, H4, /DMA, RESLYN, RESNYB
TSM is a 16R4 device whose major function is control of the dynamic RAM. For inputs, it has the decoded RAM enable signal, along with the address and data strobes from the processor which signify whether the data transfer will be low byte, hi byte, or word. From these the RAS and CAS strobes are generated, and the row/column address multiplexer is controlled. Until there were PALs, this type of dynamic RAM control function required either about 10-20 discrete TTL packages, or a 40 pin LSI dynamic RAM controller which usually didn't do what you wanted anyway. Source
| /TSEN0 | /CS | 11 | 10 | GND | ||
| /CASL | O | 12 | 9 | I | /LDS | |
| /CASR | O | 13 | 8 | I | /UDS | |
| /RAS | R | 14 | 7 | I | /AS | |
| TC | R | 15 | 6 | I | /ROM | |
| C1M | R | 16 | 5 | I | /RAM | |
| C4M | R | 17 | 4 | I | VID/u* | |
| C2M | O | 18 | 3 | I | C8M | |
| /DTACK | O | 19 | 2 | I | C16M | |
| Vcc | 20 | 1 | CLK | C16M |
From Kryten's (now gone) page:
Apple Mac Timing State Machine, PAL16R8
NB: Not verified yet!
PAL16R8 PAL DESIGN SPECIFICATIONS 16MBUF C16M 8M MU RAMEN ROMEN AS UDS LDS GND TSEN CAS0 CAS1 RAS TC 1M 4M 2M DTACK VCCRAS is the DRAM Row Address Strobe.
RAS: = /4M * /RAS
+ 8M * 4M * /RAS +
+ /8M * 4M * /2M * /RAS
+ 8M * /4M * 1M * RAS
+ 8M * /4M * /1M * 2M * RAS
+ /8M * 4M * /1M * RAS * LDS
+ /8M * 4M * /1M * RAS * UDS
+ /8M * 4M * /1M * RAS * /LDS * /UDS * /CAS0
+
TC goes to the LAG and to the video counter (U1F)
TC:= 8M + /4M + 2M + /1M + RAS
1M: = /8M * 4M * /2M * 1M * /RAS +
/1M * 8M * /4M * /RAS +
/1M * /8M * 4M * 2M * /RAS +
/1M * RAS +
/1M * /8M * /4M * /RAS +
/1M * 8M * 4M * /RAS
4M: = 1M * RAS +
8M * 4M * 2M * /1M * RAS +
/8M * /4M * /1M * RAS +
8M * /4M * 2M * /1M * RAS +
/8M * 4M * /2M * /RAS +
there may be a line missing here.....
2M: = /C16M * /8M * /4M * /RAS
+ /2M + /8M + /4M
+ /2M + /1M + * /TC
+ C16M * /2M
+ /C16M * /8M * /4M * /1M * RAS * /ROMEN * /RAMEN * /AS
+ /2M * 4M
+ /2M * 8M * /4M *1M * MU
DTACK := /C16M * /8M * /4M * /RAS * /AS * /ROMEN * RAMEN
+ /C16M * /8M * /4M * /1M * /RAS * /AS * /RAMEN * ROMEN
+ /C16M * /8M * /4M * 1M * /RAS * /AS * /RAMEN * ROMEN * /MU
+ /C16M * /8M * 4M * /1M * RAS * /AS * /RAMEN * /ROMEN
+ /DTACK * /UDS
+ /DATACK * /LDS
+ /DATACK * /RAS
This is probably not right for the Mac Plus...
CAS0: = 4M * /2M * /RAS * /DTACK * /RAMEN * ROMEN * /LDS * MU
+ 4M * /2M * 1M * /RAS * MU
+ /CAS0
+ /RAS
+ 8M + 4M + /2M * /1M * RAS * /DTACK
+ /CAS0 * /2M + /1M
CAS1: = 4M * /2M * /RAS * /DTACK * /RAMEN * ROMEN * /UDS * MU
+ 4M * /2M * 1M * /RAS * MU
+ /CAS1 + /RAS
This one is my favorite. The TSG is a 16R6 device which illustrates the power of programmable logic. It serves a couple of mundane functions concerning interrupts and the keyboard clock, but by far it's most interesting job is as a clock generator for the SCC serial chip.The master oscillator frequency in the Macintosh is 15.667 MHz. This is divided by 2 in the TSG to get the 7.834 MHz processor clock. In order for the SCC to be able to operate at a baud rate of 230.4 KBaud, which is what AppleTalk requires, it needs an input clock frequency of 3.686 MHz.
If you pull down your calculator desk accessory, you'll find that 15.667 ÷ 3.686 = 4.25. This means that the TSG needs to divide the 15.667 MHz master oscillator by 4.25 in order to get a 3.686 MHz clock. How is this done, since 4.25 is not even an integer, let alone a binary number?
Let's call the 15.667 MHz clock the MO_clk and the 3.686 MHz clock the SCC_clk. For every 17 MO_clk periods there are 4 SCC_clk periods (17 ÷ 4 = 4.25). The way the TSG generates the SCC_clk is count to 4 three times and then count to 5 once (4 + 4 + 4 + 5 = 17). See Figure 11 for a graphical description. Try that using a single TTL counter chip! Source
| /TSEN2 | /OE | 11 | 10 | GND | ||
| D0 | O | 12 | 9 | I | /VIAIRQ | |
| N/C | R | 13 | 8 | I | /IPL1 | |
| C3.7MF | R | 14 | 7 | I | KBD.ACLK | |
| N/C | R | 15 | 6 | I | Eu | |
| N/C | R | 16 | 5 | I | 4M | |
| KBD.SCLK | R | 17 | 4 | I | TC | |
| C8M | R | 18 | 3 | I | A19 | |
| IPL0 | O | 19 | 2 | I | /VPA | |
| Vcc | 20 | 1 | CLK | C16M |
C8M :=
Sound generator
As usual, Burrell's new design was very clever. The Macintosh was already continuously fetching data from memory to drive the video display, interleaving memory bandwidth between the display and processor in a similar fashion to the Apple II. But every 44 microseconds, there was a "horizontal blanking interval" where no video data was needed, so Burrell used that time to fetch data for the sound. That gave us a sample rate of 22kHz, which would allow us to do frequencies up to 11kHz, which isn't too bad. -- Source
| /TSEN2 | /OE | 11 | 10 | GND | ||
| /DMALD | R | 12 | 9 | I | TC | |
| PWM | R | 13 | 8 | I | /DMA | |
| N/C | R | 14 | 7 | I | RDQ5 | |
| N/C | R | 15 | 6 | I | RDQ4 | |
| N/C | R | 16 | 5 | I | RDQ3 | |
| N/C | R | 17 | 4 | I | RDQ2 | |
| N/C | R | 18 | 3 | I | RDQ1 | |
| N/C | R | 19 | 2 | I | RDQ0 | |
| Vcc | 20 | 1 | CLK | C16MF |
|
|
Back to Wouter's Macintosh Page | (This page last modified 2011-11-14) |