Previous thread: 8551 UART dissection //HMOS-II implementation of 6551

;---

First: thanks to all those who make these chip dissections possible.

This thread is about a transistor level dissection of the MOS 8364R7 Paula,
brought to you by Frank Wolf and ttlworks.

Frank had paid 2k€ to a lab for decapping Paula and for making the microscopic pictures.
Stitching the pictures together to one big picture and vectorizing it took him a year.
So if you want to have the big vectorized picture, you either need to negotiate with Frank,
or to wait until he eventually releases it to the public, sorry.

I tried to extract something like a schematic from the vectorized picture,
it took me about 800 hours of work (Paula is at least 4 times as big as your average 65xx peripheral chip),
and as usual my results are 'free as in free beer'.

Unfortunately I lack the capacity for interpreting some parts,
like the audio channel control PLAs and the floppy controller.

;---

Paula was designed by Glenn Keller, it was his first chip design,
but we haven't noticed that during the dissection.
He really did a nice job with Paula.

The Commodore Amiga (released in 1985) was a 68000 based machine,
what makes this thread somewhat off_topic in a 6502 forum.

//But if you happen to be out to build a 65816 + FPGA based gaming system,
//and "when you care enough to steal the very best", it might be an interesting read.

The Amiga contained a custom set of three chips:
Agnus: DMA, Blitter, Copper
Denise: video processor
Paula: four 8 Bit PCM Audio channels, interrupt controller, joysticks, UART, floppy controller

While there were different chip sets (with different capabilities) for different Amigas,
Paula always remained functionally identical across all Amiga models from Commodore.

Unfortunately, getting an original Paula chip working in a 65816 system might be too much fuss:
Paula data bus deliberately is 16 Bits wide, no 8 Bit transfers possible.
Paula lacks CS# and R/W# pins, that functionality is encoded into the register address.
Paula runs with a quadrature clock, that's two clock signals with a 90 degree phase offset.
Also, for the audio channels and the floppy controller, Paula needs help from a DMA chip,
an there is no DMA chip in the 65xx family of chips.

;---

Note:
When looking at the chipset, conceptually you could try to imagine
that Agnus, Denise and Paula together just form one single monolithic chip.
But because only a certain amount of transistors did fit on a single chip,
the designers were forced to break "the monolithic chip" into three parts.
//Some of the readers might know that situation "when your design doesn't fit into a single CPLD"...

For consistence with Frank's notation, low_active signals are named foo#, not /foo.

8364R7 cheat sheet:



A picture of the 8364R7 silicon, with the interesting areas marked.



Just as a reference, another picture of the 8364R7 silicon without the markings.



;---

The whole dissection as a ZIP,
including all of the intermediate steps for making the readers able to spot/fix errors.
//Note, that the whole set of schematics has 61 pages.
//Schematics still were made by using (dead bird) Eagle 6.4.0, because I lack the time for migrating to KiCAD.

1a) bias generator

An oscillator built from three interters,
plus drivers and a full_wave rectifier.

We have seen something (more or less) like that
in every MOS\CSG\Commodore HMOS-II chip, nothing fancy.

;---

1b) clock generator

That thing is a bit tricky, and not easy to understand.

CCK and CCKQ are the two external clock signals which go into Paula,
and there is a 90 degree phase shift between these two clocks.

The clock generator generates six (non_overlapping) clock signals
from CCK and CCKQ.

Since I did a lot of 65xx chip dissections,
I decided to stick with a 65xx like notation.
To me, it just feels confy if the register write signals
are gated with something labeled "PHI2", sorry.

Like in a 65xx peripheral chip, PHI1 and PHI2 are used
for most of the circuitry inside the chip.

2PHI1, 2PHI2, PHI10, PHI20 are exclusively used inside the floppy controller.

Note, that 2PHI1 and 2PHI2 are running at twice the speed
of PHI1, PHI2, PHI10, PHI20.

2a) RGA1..8 input

The RGA1..8 register select address signals are generated in Agnus.

Note, that Paula has no CS# and R/W# pin.
That functionality is encoded into RGA1..8.

Certain register addresses are read only,
certain register addresses are write only,
no register addresses are both read/write.

RGA1..8 = HIGH means '/dev/null'.

Basically, RGA1..8 input pads are sampled with transparent latches at PHI1=HIGH,
the outputs of said latches go into "3) address decoder".

;---

2b) D0..15 data bus

We just focus on D0.

On the read side, the internal data bus signal D0io goes into a buffer,
which drives the D0 external data bus line when DBR#=LOW.

On the write side, the D0 external data bus line goes through a delay
(which is build from some inverters), gets sampled by a transparent latch
when CCK#=HIGH, then goes into a driver which puts the output of the latch
on the internal data bus line D0io when DBW#=LOW.

Note, that in Paula the internal data bus D0io..D15io is bidirectional,
and without a precharge mechanism or such.

;---

2c) DB control

It generates signal DWR# for 2b).
DBW# is generated in "3) address decoder".

;---

2d) RES

The RES# input pad has a Schmitt trigger input.
Note the effort, that went into synchronizing external signals with
"the system clock".

3) address decoder

Basically a PLA with buffered outputs.
It decides from the register address what to do.
Note the absence of CS# and R/W.

Register write signals tend to be gated with PHI2.

The evil thing is, that the Paula address decoder also detects
register access to $03C STRHOR and $038 STREQU (which are no Paula registers)
for generating the vertical blanking interrupt.

4) interrupt controller

;---

4a) INT2

External low_active interrupt signals INT2#, INT4#, INT6#
are sampled in transparent (half_static) latches when CCK#=HIGH.
The latches emit the high_active signals INT2, INT4, INT6.

;---

4b) INT_2

INT2, INT4, INT6 are synchronized to "the system clock"
by creatively using some more transparent latches.
What gives us the high_active signals INT_2, INT_4, INT_6.
//Hey, I had to name them somehow.

;---

4g) interrupt flag register and interrupt enable register

Note, that there is no register Bit 15.

Interrupt flag registers are set by INT_2, INT_4, INT_6,
and by the Paula internal interrupt sources
(like audio channels, UART and floppy controller).
Note, that for Bit 2, Bit 4, and Bit 14 of the interrupt flag register
the "interrupt set inputs" are tied to GND.

When writing the interrupt flag register,
if a register Bit selected with D0..D14 is high,
the register Bit is set or cleared according to D15.
Same thing for the interrupt enable register.

When a Bit in the interrupt flag register is set,
and the Bit is enabled in the interrupt enable register,
an interrupt is active.

Note, that interrupt enable register Bit 14
globally enables/disables the "4d) interrupt priority" encoder.

Some of the "active interrupt" signals are ORed together,
what gives us IP1..IP6.

;---

4d) interrupt priority

IP1..6 go into a priority encoder,
which generates the low_active interrupt priority level signals
IPL_0#, IPL_1#, IPL_2#.

;---

4c) IPL0#

IPL_0#, IPL_1# IPL_2# are sampled with transparent latches,
first during PHI2, then during PHI1, before they go into
"open collector (7407)" drivers which tie the IPL0#, IPL1#, IPL2#
interrupt priority input pins of the 68k CPU LOW.

5) DMAL

Agnus handles the DMA.
//DMA reads/writes use 16 Bit words.

Paula tells Agnus over the DMAL output pad ("per telegram"),
which of the Paula DMA channels require DMA service.

The DMA request logic in Paula has 14 DMA slots in total:
three for floppy controller data read,
three for floppy controller data write,
and two for each of the 4 audio channels.

Basically, the DMAL output pad is fed by the serial output of a shift register,
which is loaded with the Paula internal DMA request signals.

DMA request signals from the audio channels are sampled by latches
which are cleared after the contents of said latches
went transferred into the shift register.

6ab) DMACON

The DMACON register enables/disables the Paula DMA requests,
Bit 0..3 are for the audio channels,
Bit 4 is for the floppy controller,
Bit 9 is a globally enables/disables the output of Bit 0..4.

Note, that the CPU can't read the DMACON register.

When writing the DMACON register,
if a register Bit selected with D0..D4 and D9 is high,
the register Bit is set or cleared according to D15.

;---

6c) ADKCON

ADKCON controls the rest of the Paula functionality:
audio channel modulation,
UART control,
floppy controller write precompensation and such.

The CPU can read the ADKCON register.

When writing the ADKCON register,
if a register Bit selected with D0..D14 is high,
the register Bit is set or cleared according to D15.

7) audio channels

Paula has 4 PCM audio channels.

In the silicon, channel 0 is North, and channel 3 is South.

Channel 0 and 3 feed the AUDL output pad, //analog "audio left" output signal
channel 1 and 2 feed the AUDR output pad, //analog "audio right" output signal
and back then probably not all of the game coders were aware of that setting.

C64 SID had two DACs per audio channel:
one for volume control, and the other for the audio.
Paula uses a different concept:
only one DAC per channel,
and volume control is done by enabling/disabling the DAC output by a 6 Bit PWM counter.
//And because of the PWM, the analog outputs need to go through an external filter.

DAC is 8 Bit signed.
For positive values, "switches plus binary weighted resistors" pull the analog output to VCC.
For negative values, "switches plus binary weighted resistors" pull the analog output to GND.
Actually, for negative numbers the DAC driver (driving the switches) only does 1s complement,
and an additional "switch plus resistor" pulls the analog output to GND
causing a one LSB offset of the output which makes the analog signal a 2s complement.

Audio data is 16 Bit, means that either the upper or the lower 8 Bits of an audio data word
go into the DAC.

For reading the audio data words from memory by DMA,
we have a (decrementing) 16 Bit length counter which defines the amount of data words to be read.

And we have a (decrementing) 16 Bit period counter, which is responsible for the sample rate.

Period counter and volume of a channel can be modulated by another channel,
to be more specific:
channel 0 can't be modulated at all. //all of the related input signals are tied to GND.
channel 0 can modulate channel 1,
channel 1 can modulate channel 2,
channel 2 can modulate channel 3,
channel 3 can modulate nothing, //all od the modulation output signals are open traces.
nevertheless when a channel (including channel 3) is enabled as a modulation source,
the DAC of the channel which is the source is disabled/muted.

Every audio channel has a PLA which controls said channel,
including DMA request and interrupt request,
and unfortunately I lack the capacity for making sense of that PLA.
;
If you have success with trying to understand it,
please write some technical articles about it...

8) analog joysticks

Basically, what we have is a 4 channel 8 Bit A\D converter.

A write to POTGO register with Bit 0 = '1' clears/starts an 8 Bit counter.
The output of said counter goes into the data latches of every channel.

The 4 channels are: POT0X, POT0Y, POT1X, POT1Y.
Register POT0DAT has POT0X in Bit 0..7, and POT0Y in Bit 8..15.
Register POT1DAT has POT1X in Bit 0..7, and POT1Y in Bit 8..15.

;...

All of the channels are built pretty much in the same way,
so we now focus on POT0X.

At the POT0X pad, there is supposed to be attached:
a 47nF (+-10%) capacitor to GND, and a 470kOhm (+-10%) potentiometer to VCC.

Writing '1' to Bit 9 of the POTGO register configurates the POT0X pad as an output,
means the POT0X pad output driver is enabled,
and according to what is written into POTGO register Bit 8
said driver either switches the POT0X pad to GND or to VCC.

When '0' was written to Bit 9,
the POT0X pad is switched to GND when the counter is cleared/started,
what discharges the external capacitor.
After the counter is started, the capacitor is charged to VCC
through the potentiometer.

A Schmidt trigger senses the voltage at the POT0X pad.
Reading POTGO register Bit 8 gives you what logic level is at the POT0X pad.
As long as the logic level on the POT0X pad is low,
the counter value is loaded into the POT0X register,
and that's basically it.

9) UART

No handshake, just RxD input pad and TxD output pad.
It's a clever, minimalistic design... and _completely_ different from the 6551.
//A neat approach to building UARTs for the readers using CPLDs or FPGAs.

;---

TX (transmitter)

The CPU writes the Data to be transmitted into "9c) TX shift register",
which shifts right at baud rate,
by filling the empty Bits of the shift register with '0'.

The LSB of the shift register basically is what comes out of the TxD pad.
//There is another "hidden shift register Bit" between "9c)" and the TxD pad,
//else you would lose the Stop Bit.

If all of the Bits in the TX shift register are '0',
the UART sees the transmission as completed.

The baud rate is generated by "9d)", a 15 Bit down counter.

It's all nice and simple...
...except that when the CPU writes data to the TX shift register,
the Start Bit and the Stop Bit have to be included,
and the data has to be alligned accordingly.

Which means you have to write more than 8 Bits into the TX shift register at once.
But in the Amiga this isn't a problem,
because all of the Paula register writes deliberately are 16 Bit words.

Note:
If you want to include a parity Bit to the transmission,
you have to calculate/handle it by software.

;---

RX (receiver) side.

Signal from the RxD pad goes though a Schmidt trigger,
is neatly synchronized with "the system clock",
and goes through a little digital filter
(which is supposed to cut down glitches).
An edge detector then scans for a falling edge
(which indicates the start of a Start Bit).

When there is a falling edge while the RX part of the UART is sharp,
all of the Bits in the RX shift register are set to '1'.
Also, the RX baud rate generator "9f" (15 Bit down counter)
is loaded just once with 'the value divided by 2',
making sure that the UART scans the RxD pad in the middle of a Bit.

The Bits are shiftet right into the "9h" RX shift register,
the length of said shift register can be switched
to 9 or to 10 Bits.
//Means, when reading data from the RX shift register,
//you need to truncate the Stop Bit.

When the Start Bit comes out of the shift register
(there is another "hidden shift register Bit" for that),
the UART sees the received frame as completed.

Again:
If/when using a parity check,
that's supposed to be handled by software.

10) floppy controller

It's big, it's complex, and I lack the capacity for understanding that thing.
Clear text: it could be that there are errors in this part of my schematic.

The floppy controller is designed to read/write an entire track as a "raw Bit sequence" in one shot by DMA.

There are two PLAs in the flopply controller:
The bigger PLA "10j)" belongs to the read data separator.
The smaller PLA "10i)" enables disk write and does the interrupts.

The length of the data transfer is controlled by "10m)", a 14 Bit down counter.

The output of the read data separator goes into "10r)" which is a 16 Bit shift register (shifting left).
Attached to the shift register, there is a 16 Bit comparator, which scans for the sync word.
The 8 lower outputs of said shift register I had labeled FDC0..FDC7,
and that's what you get when reading the DSKBYT register.

FDC0..7 go into an 8 Bit latch, which gives out FDC8..FDC15.

FDC0..FDC15 then go into the "10l)" 16 Bit data register.
Signal DISKWRITE can write said register with the data bus.
Signal DSKDR# can read said register into the data bus.
Three DMA slots for floppy controller reads (and three for writes),
so it isn't surprising to see something like "a 3 level pipeline" in that register.
Attached to said data register, we have another 16 Bit shift register (shifting left),
which gives out the serial data to be written to the floppy.

The serial write data goes through "10v)", which seems to do the write precompensation.

If you eventually figure out how the floppy controller actually works in detail,
please write a set of technical articles about it...

That's all for now.

Now to take a break, because that Paula dissection was pretty intense.

Rockwell R6545 is next.

While 'ttlworks' takes his much deserved break I'll proceed vectorizing the R6545.

In order to give a short glimpse about the current state:



I've been drawing every free hour since November 2022... Metal layer (blue) 100% finished. Diffusion/Active layer (green) ~75%.
So there's still the polysilicon layer to go before we can finally(!!!!) delve into another dissection.

A splendid and monumental effort - thanks for sharing the results!

Do we now know the process technology, die size, and approx transistor count?

Very interesting that the sound engine is half the die. The floppy controller is I think minimally complex, putting the software into play for most of the work.

It shouldn't be too hard to decode a PLA: it should resolve to a bunch of NOR gates feeding into a bunch of NOR gates. (Have you read Mead & Conway? It's a classic textbook, is available online (legitimately!), and influenced a large proportion of design engineers. The PLA is explained there, from logic to layout.)

(Just to note, the 6545 (aka 6845) is a CRT controller. Versions also from Hitachi and UMC, and from VTI aka VLSI. Seen in the BBC Micro and others.)