We had to put chip dissections on hold for 5 months due to bad working conditions.
Working conditions haven't improved much, just our strategies of dealing with the situation have.
So expect to have a slight quality drop in our chip dissections. Thanks for your attention.
This thread is about a transistor level dissection of the MOS 6571 Amiga Keyboard controller
(which basically is just a MOS 6500/1 microcontroller), brought to by Frank Wolf and ttlworks.
Related forum thread: 6570 / 6571. What is it?
The 6500/1 microcontroller features:
a 6502 core //which is a redesign of the NMOS 6502, but it's supposed to be NMOS 6502 compatible including the "illegal instructions
2kB of ROM //mask programmed by the factory
64 Bytes of SRAM //SRAM has separate VRR power supply pin. Note that the SRAM shows up in pare 0 and in page 1 of memory, so use your stack carefully.
four 8 Bit I/O ports //"open collector" outputs with pullups, thus no "data direction registers" for the I/O ports.
a 16 Bit timer //with the related CNTR pad working as an input or an output, depending on the timer mode of operation.
Also, there is a falling edge detector (IRQ) attached to PA0,
and a rising edge detector (IRQ) attached to PA1.
The timer and the two edge detectors are able to generates a IRQ, but IRQ is not available outside the chip.
The chip has a NMI# pad.
Note, that (except for the 'Test Mode'), the CPU core is not meant to access external memory.
Because of that, there is no RDY pad, and the CPU core lacks the whole RDY related circuitry which we have in a NMOS 6502.
Now for the 'Test Mode': The 6500/1 was invented before there was JTAG,
so for (factory) testing of the chip the designers went for an unusual approach:
When pulling RES# from LOW to +10V (and keeping it at that voltage),
the CPU core runs in 'Test Mode', and reads Bytes from PORT C instead from the on_chip ROM.
Note:
For consistence with Frank's notation, low_active signals are named foo#, not /foo.
Orientation for all the chip pictures: VRR pad is North.
;---
MOS Datasheets:
6500/1 One-Chip Microcomputer (Preliminary, April 1981)
6500/1 One-Chip Microcomputer (Oct. 1986)
MOS 6571 Amiga keyboard controller dissection > 6500/1
Re: MOS 6571 Amiga keyboard controller dissection > 6500/1
Eagle 6.4 schematics for my schematic pictures in this thread,
just in case if somebody needs them.
Note: KiCad is supposed to be able to import these schematics,
unfortunately it doesn't seem to be possible to disable the layers 'name' and 'value' in KiCad schematics,
so making my schematics look nice and clean in KiCad will require some work, sorry.
Ok, so I'm still using the dead bird for drawing schematics,
but on the bright side, Eagle is more compatible to KiCad than KiCad is to KiCad...
just in case if somebody needs them.
Note: KiCad is supposed to be able to import these schematics,
unfortunately it doesn't seem to be possible to disable the layers 'name' and 'value' in KiCad schematics,
so making my schematics look nice and clean in KiCad will require some work, sorry.
Ok, so I'm still using the dead bird for drawing schematics,
but on the bright side, Eagle is more compatible to KiCad than KiCad is to KiCad...
Re: MOS 6571 Amiga keyboard controller dissection > 6500/1
A picture of the 6571R6 silicon, with the interesting areas marked.
Just as a reference, another picture of the 6571R6 silicon without the markings.
Re: MOS 6571 Amiga keyboard controller dissection > 6500/1
6571R6 cheat sheet:
Re: MOS 6571 Amiga keyboard controller dissection > 6500/1
1a) XTAL oscillator
6500/1 chip ordering options either were:
"crystal oscillator" or "RC oscillator".
6571 is meant to use a crystal,
the dead FETs in the oscillator section probably are remnants
related to the "6500/1 RC oscillator" option.
Nothing fancy in there.
The oscillator just generates the XTL clock signal for 1b) divider.
;---
1b) PHI1, PHI2
A :2 divider with two non_overlapping clock outputs PHI1, PHI2
clocked with the XTL clock signal which is generated by the 1a) oscillator.
Note: PHI2 is running at half the crystal frequency.
;---
6500/1 chip ordering options either were:
"crystal oscillator" or "RC oscillator".
6571 is meant to use a crystal,
the dead FETs in the oscillator section probably are remnants
related to the "6500/1 RC oscillator" option.
Nothing fancy in there.
The oscillator just generates the XTL clock signal for 1b) divider.
;---
1b) PHI1, PHI2
A :2 divider with two non_overlapping clock outputs PHI1, PHI2
clocked with the XTL clock signal which is generated by the 1a) oscillator.
Note: PHI2 is running at half the crystal frequency.
;---
Re: MOS 6571 Amiga keyboard controller dissection > 6500/1
2a) Bias driver
Two level charge pump which generates the negative VBB Bias voltage for the chip,
nothing fancy in there.
;---
2b) Bias oscillator
Ring oscillator, built from 5 inverters (4 of them have RC delay).
Nothing fancy in there, except that the oscillator output is disabled
when the VCC supply voltage is too low.
;---
Two level charge pump which generates the negative VBB Bias voltage for the chip,
nothing fancy in there.
;---
2b) Bias oscillator
Ring oscillator, built from 5 inverters (4 of them have RC delay).
Nothing fancy in there, except that the oscillator output is disabled
when the VCC supply voltage is too low.
;---
Re: MOS 6571 Amiga keyboard controller dissection > 6500/1
3a) NMI#
Signal from NMI# pad is synchronized with PHI2,
then goes to "11) CPU control circuitry" as NMI2#.
Note, that the NMI# pad has no pullup resistor inside the chip.
;---
3b) RES#
Signal from RES# pad (low_active) is sensed by a Schmitt Trigger,
synchronized with PHI2 (similar concept like we had with NMI#),
then sampled by a transparent latch at PHI1,
which gives out RES1 (high active) to "11) CPU control circuitry".
For the Test Mode, basically a voltage divider checks
if the voltage level at the RES# pad is at least 10V.
A driver then puts the result on data bus line D7 during PHI1:
D7 = 0: Test Mode inactive //normal operation
D7 = 1: Test Mode active //CPU core reads from PORT C instead of on_chip ROM.
Note, that the RES# pad has no pullup resistor inside the chip.
;---
Signal from NMI# pad is synchronized with PHI2,
then goes to "11) CPU control circuitry" as NMI2#.
Note, that the NMI# pad has no pullup resistor inside the chip.
;---
3b) RES#
Signal from RES# pad (low_active) is sensed by a Schmitt Trigger,
synchronized with PHI2 (similar concept like we had with NMI#),
then sampled by a transparent latch at PHI1,
which gives out RES1 (high active) to "11) CPU control circuitry".
For the Test Mode, basically a voltage divider checks
if the voltage level at the RES# pad is at least 10V.
A driver then puts the result on data bus line D7 during PHI1:
D7 = 0: Test Mode inactive //normal operation
D7 = 1: Test Mode active //CPU core reads from PORT C instead of on_chip ROM.
Note, that the RES# pad has no pullup resistor inside the chip.
;---
Re: MOS 6571 Amiga keyboard controller dissection > 6500/1
4) I/O ports and CNTR pad
We have four 8 Bit I/O ports with "open collector" outputs plus pullup resistors (FETs).
//When ordering a 6500/1 chip, there was the option to have individual pullup resistors removed.
On the input side of an I/O port, data from the pads is just read by the CPU at PHI2,
no latches in the port inputs, nothing fancy.
On the output side of an I/O port, data from the CPU is written into a half_static transparent latch during PHI2.
Output of the half_static transparent latch goes into a dynamic latch, which controls the FETs switching the pads to GND.
Thus, outputs of the I/O ports change at the falling edge of PHI2.
;
When writing '0' into an I/O port Bit, the related FET pulls the port pin to GND.
When writing '1' into an I/O port Bit, the pullup resistor (FET) tries pulling the port pin to VCC.
//Thou shalt be aware that it takes some time for an I/O pin with a capacitive load to reach logic HIGH level.
It's the simplest way of building an I/O port, no "data direction register" or such required.
;---
There is a falling edge detector attached to PA0,
and a rising edge detector attached to PA1.
The designers ran out of chip space when it came to the control lines for the I/O ports...
...so they used the data bus during PHI1 instead:
Output of the PA0 edge detector goes into D0. //sampled by "5e) Control Register" for generating an IRQ.
Output of the PA1 edge detector goes into D1. //sampled by "5e) Control Register" for generating an IRQ.
D2 = 1 means read, D2 = 0 means write. //generated in "11) CPU core control logic".
D3..D6 are the select signals for PORT A .. PORT D.
During a reset, D3..D6 are forced active for writing 0xff into the I/O port data registers,
see "6a) address decoder A0..A7 output".
Really, it's an interesting concept:
except for the PHI1 and PHI2 clock, control of the I/O ports is done during PHI1 over the data bus.
We are getting to the CNTR pad in "5) Timer and Control Register".
;---
;...
;...
;...
;...
We have four 8 Bit I/O ports with "open collector" outputs plus pullup resistors (FETs).
//When ordering a 6500/1 chip, there was the option to have individual pullup resistors removed.
On the input side of an I/O port, data from the pads is just read by the CPU at PHI2,
no latches in the port inputs, nothing fancy.
On the output side of an I/O port, data from the CPU is written into a half_static transparent latch during PHI2.
Output of the half_static transparent latch goes into a dynamic latch, which controls the FETs switching the pads to GND.
Thus, outputs of the I/O ports change at the falling edge of PHI2.
;
When writing '0' into an I/O port Bit, the related FET pulls the port pin to GND.
When writing '1' into an I/O port Bit, the pullup resistor (FET) tries pulling the port pin to VCC.
//Thou shalt be aware that it takes some time for an I/O pin with a capacitive load to reach logic HIGH level.
It's the simplest way of building an I/O port, no "data direction register" or such required.
;---
There is a falling edge detector attached to PA0,
and a rising edge detector attached to PA1.
The designers ran out of chip space when it came to the control lines for the I/O ports...
...so they used the data bus during PHI1 instead:
Output of the PA0 edge detector goes into D0. //sampled by "5e) Control Register" for generating an IRQ.
Output of the PA1 edge detector goes into D1. //sampled by "5e) Control Register" for generating an IRQ.
D2 = 1 means read, D2 = 0 means write. //generated in "11) CPU core control logic".
D3..D6 are the select signals for PORT A .. PORT D.
During a reset, D3..D6 are forced active for writing 0xff into the I/O port data registers,
see "6a) address decoder A0..A7 output".
Really, it's an interesting concept:
except for the PHI1 and PHI2 clock, control of the I/O ports is done during PHI1 over the data bus.
We are getting to the CNTR pad in "5) Timer and Control Register".
Re: MOS 6571 Amiga keyboard controller dissection > 6500/1
5) Timer plus Control Register
Timer is a 16 Bit down counter, featuring the usual inverted/non_inverted carry chain
plus 8 Bit carry lookahead mechanism, nothing fancy.
Bit 0 (CMC0) and Bit 1 (CMC1) in the Control Register are for selecting the Timer Mode:
00: "internal Timer": CNTR pad is not used, Timer is decrementing at PHI2 speed.
01: "Pulse Generator": CNTR pad is output, Timer underflow toggles CNTR pad.
10: "Event Counter": CNTR pad is input, Timer decrements one step after a falling edge is detected at the CNTR pad.
11 "Pulse Width Measurement": CNTR pad is input, timer decrements at PHI2 speed while CNTR pad is LOW.
After simplifying the Timer control circuitry, it looks quite simple.
Note, that there is a pullup resistor (FET) attached to the CNTR pad inside the chip.
;...
Besides CMC0 and CMC1, the Control Register also contains the interrupt flags
for Timer underflow, PA0 falling edge detector, PA1 rising edge detector,
plus the related interrupt enable Bits for generating an IRQ.
The designers ran out of chip space, so we only have _one_ line which I had labeled RESIRQ.
During PHI1, the periperals are sending IRQ (high_active) to the CPU through that line.
During PHI2, the CPU sends RES (high_active) to the peripherals through that line.
;---
;...
;...
;...
;...
Timer is a 16 Bit down counter, featuring the usual inverted/non_inverted carry chain
plus 8 Bit carry lookahead mechanism, nothing fancy.
Bit 0 (CMC0) and Bit 1 (CMC1) in the Control Register are for selecting the Timer Mode:
00: "internal Timer": CNTR pad is not used, Timer is decrementing at PHI2 speed.
01: "Pulse Generator": CNTR pad is output, Timer underflow toggles CNTR pad.
10: "Event Counter": CNTR pad is input, Timer decrements one step after a falling edge is detected at the CNTR pad.
11 "Pulse Width Measurement": CNTR pad is input, timer decrements at PHI2 speed while CNTR pad is LOW.
After simplifying the Timer control circuitry, it looks quite simple.
Note, that there is a pullup resistor (FET) attached to the CNTR pad inside the chip.
;...
Besides CMC0 and CMC1, the Control Register also contains the interrupt flags
for Timer underflow, PA0 falling edge detector, PA1 rising edge detector,
plus the related interrupt enable Bits for generating an IRQ.
The designers ran out of chip space, so we only have _one_ line which I had labeled RESIRQ.
During PHI1, the periperals are sending IRQ (high_active) to the CPU through that line.
During PHI2, the CPU sends RES (high_active) to the peripherals through that line.
Re: MOS 6571 Amiga keyboard controller dissection > 6500/1
6b) address decoder A0..A7
Not that complicated, it's just that the CPU gives out
A0#..A3# in low_active form, and A4..A7 in high_active form.
So we have 4 inverters for A0#..A3# at the address decoder inputs
(generating high_active A_0..A_3), and I think the designers
intentionally did this for reducing the capacitive load
to the CPU address line outputs.
//Sinde the decoding requires to have a lot of logic gates attached to A_0..A_3.
;---
6a) address decoder A0..A7 outputs to data bus
The designers ran out of chip space, so they had used the data bus
the select signals to the I/O ports during PHI1.
Note the trick circuitry, which writes 0xff into all I/O ports simultaneously during a Reset.
//Note: "11) CPU core control logic" is forced to do a write during a RESET.
;---
6c) address decoder A8..A11
There is no A12..A15 inside the chip.
There wasn't enough space in the CPU core for implementing the ADH latches
which sample the CPU internal ADH bus for generating A8..A11.
So the CPU internal ADH8..ADH11 bus is just buffered by inverters (or inverting super buffers)
in "10)f flags", generating ADH8#..ADH11# (low_active).
And because of this, the ADH latches were placed into the address decoder.
The A8..A11 decoder just generates the select signals for the ROM data output multiplexers,
and decides whether the lowest kiloByte of memroy is addressed or not.
;---
6d) RAM, ROM read/write control.
Controls ROM reads, and RAM reads/writes.
Note, that the read/write signal is on data bus D2 during PHI1,
because the designers ran out of chip space.
Nothing fancy, except that preventing RAM data from getting corrupted
when VCC is down and VRR (RAM power supply voltage) is up can be a bit tricky.
Not that complicated, it's just that the CPU gives out
A0#..A3# in low_active form, and A4..A7 in high_active form.
So we have 4 inverters for A0#..A3# at the address decoder inputs
(generating high_active A_0..A_3), and I think the designers
intentionally did this for reducing the capacitive load
to the CPU address line outputs.
//Sinde the decoding requires to have a lot of logic gates attached to A_0..A_3.
6a) address decoder A0..A7 outputs to data bus
The designers ran out of chip space, so they had used the data bus
the select signals to the I/O ports during PHI1.
Note the trick circuitry, which writes 0xff into all I/O ports simultaneously during a Reset.
//Note: "11) CPU core control logic" is forced to do a write during a RESET.
6c) address decoder A8..A11
There is no A12..A15 inside the chip.
There wasn't enough space in the CPU core for implementing the ADH latches
which sample the CPU internal ADH bus for generating A8..A11.
So the CPU internal ADH8..ADH11 bus is just buffered by inverters (or inverting super buffers)
in "10)f flags", generating ADH8#..ADH11# (low_active).
And because of this, the ADH latches were placed into the address decoder.
The A8..A11 decoder just generates the select signals for the ROM data output multiplexers,
and decides whether the lowest kiloByte of memroy is addressed or not.
6d) RAM, ROM read/write control.
Controls ROM reads, and RAM reads/writes.
Note, that the read/write signal is on data bus D2 during PHI1,
because the designers ran out of chip space.
Nothing fancy, except that preventing RAM data from getting corrupted
when VCC is down and VRR (RAM power supply voltage) is up can be a bit tricky.
Re: MOS 6571 Amiga keyboard controller dissection > 6500/1
7abc) RAM
Nothing fancy, one SRAM cell basically is a RS flipflop, but again:
preventing SRAM data from getting corrupted when VCC is down and VRR (RAM power supply voltage) is up can be a bit tricky.
Nothing fancy, one SRAM cell basically is a RS flipflop, but again:
preventing SRAM data from getting corrupted when VCC is down and VRR (RAM power supply voltage) is up can be a bit tricky.
Re: MOS 6571 Amiga keyboard controller dissection > 6500/1
8) ROM
ROM data cells basically are NOR gates.
Mask programming the ROM happens at diffusion layer, at an early step of the chip fabrication,
what implicates that one had to order a lot of chips for getting them with a custom mask programming.
Note:
A fet present in the ROM data cells translates to '1' at the data output.
ROM data cells basically are NOR gates.
Mask programming the ROM happens at diffusion layer, at an early step of the chip fabrication,
what implicates that one had to order a lot of chips for getting them with a custom mask programming.
Note:
A fet present in the ROM data cells translates to '1' at the data output.
Re: MOS 6571 Amiga keyboard controller dissection > 6500/1
9) memory row decoder
PLA, linear encoding.
RAM and ROM share the same row decoder for A0..A7.
Note the A6, A7 decoder which has low active outputs.
If we focus on the product terms for $80, $C0:
The A6, A7 decoder switches one of both terms to GND (or both of them).
Between the $80 and $C0 terms, we have FETs controlled by MA0..MA5.
;
For instance, if MA0 = 1, the related FET connects product term $80 and $C0.
Since (at least) one of them is LOW, this results in both of them being LOW (inactive).
Now that's a neat trick for saving some transistors...
;---
PLA, linear encoding.
RAM and ROM share the same row decoder for A0..A7.
Note the A6, A7 decoder which has low active outputs.
If we focus on the product terms for $80, $C0:
The A6, A7 decoder switches one of both terms to GND (or both of them).
Between the $80 and $C0 terms, we have FETs controlled by MA0..MA5.
;
For instance, if MA0 = 1, the related FET connects product term $80 and $C0.
Since (at least) one of them is LOW, this results in both of them being LOW (inactive).
Now that's a neat trick for saving some transistors...
Re: MOS 6571 Amiga keyboard controller dissection > 6500/1
10) the mill of the CPU core
It's a redesign of the NMOS 6502 mill.
There are some minor differences at gate level, and the layout is different.
We have weak pullups at the DB, SB, ADH bus. //I can't remember to heve seen them in the 6509.
The CPU gives out A0#..A3# (low_active) and A4..A7 (high_active), that's because of how the address decoder is built.
Unlike in the NMOS 6502, the flags are crammed into the mill (to make better use of chip space).
Also, there wasn't enough space in the mill for the ADH latches (which sample the ADH bus for generating A8..A15).
That's why we have inverters (or super buffers) which just buffer ADH8..ADH11, sending ADH8#..ADH11# to the address decoder.
//The address decoder then contains the ADH latches.
But on the logic level design of view, the 6500/1 CPU core should do exactly the same as the NMOS 6502 core.
//Whether the weak pullups and the different layout have an effect on the less stable "illegal instructions" or not would have to be tested.
Here we go, rolling out the mill from West to East:
;---
10a) ADL latches, registers Y, X, S
Not much difference to the NMOS 6502.
;---
10bc) ALU
Inverting/non_inverting carry chain, pretty much like in the NMOS 6502.
;---
10d) decimal correction plus accumulator and stuff
In decimal mode, 6500/1 ADC/SBC will give the same results like the NMOS 6502,
even for non_BCD numbers, I checked.
Decimal mode ADC/SBC incorrectly sets the flags like in the NMOS 6502.
;---
10e) PC, the program counter.
16 Bit up counter.
Inverting/non_inverting carry chain plus carry lookahead,
pretty much the same game like in the NMOS 6502.
;---
10f) flags
The flag section was crammed into the mill to make better use of chip space.
Note the inverters (or inverting super buffers) which buffer ADH8..ADH11,
sending ADH8#..ADH11# (low_active) to the address decoder.
;---
10g) data latch
What connects the CPU internal bus systems to the data bus,
and the game is pretty much similar to the NMOS 6502.
Except that the CPU only puts data on the bus during PHI2.
//Because during PHI1 the data bus is used for distributing control signals.
It's a redesign of the NMOS 6502 mill.
There are some minor differences at gate level, and the layout is different.
We have weak pullups at the DB, SB, ADH bus. //I can't remember to heve seen them in the 6509.
The CPU gives out A0#..A3# (low_active) and A4..A7 (high_active), that's because of how the address decoder is built.
Unlike in the NMOS 6502, the flags are crammed into the mill (to make better use of chip space).
Also, there wasn't enough space in the mill for the ADH latches (which sample the ADH bus for generating A8..A15).
That's why we have inverters (or super buffers) which just buffer ADH8..ADH11, sending ADH8#..ADH11# to the address decoder.
//The address decoder then contains the ADH latches.
But on the logic level design of view, the 6500/1 CPU core should do exactly the same as the NMOS 6502 core.
//Whether the weak pullups and the different layout have an effect on the less stable "illegal instructions" or not would have to be tested.
Here we go, rolling out the mill from West to East:
10a) ADL latches, registers Y, X, S
Not much difference to the NMOS 6502.
10bc) ALU
Inverting/non_inverting carry chain, pretty much like in the NMOS 6502.
- si6571r6_10c_alu_result.png (9.03 KiB) Viewed 1172 times
10d) decimal correction plus accumulator and stuff
In decimal mode, 6500/1 ADC/SBC will give the same results like the NMOS 6502,
even for non_BCD numbers, I checked.
Decimal mode ADC/SBC incorrectly sets the flags like in the NMOS 6502.
10e) PC, the program counter.
16 Bit up counter.
Inverting/non_inverting carry chain plus carry lookahead,
pretty much the same game like in the NMOS 6502.
10f) flags
The flag section was crammed into the mill to make better use of chip space.
Note the inverters (or inverting super buffers) which buffer ADH8..ADH11,
sending ADH8#..ADH11# (low_active) to the address decoder.
10g) data latch
What connects the CPU internal bus systems to the data bus,
and the game is pretty much similar to the NMOS 6502.
Except that the CPU only puts data on the bus during PHI2.
//Because during PHI1 the data bus is used for distributing control signals.
Re: MOS 6571 Amiga keyboard controller dissection > 6500/1
11) CPU core control circuitry
The designers ran out of chip space, so we have _one_ line which I had labeled RESIRQ.
During PHI1, the periperals are sending IRQ (high_active) to the CPU through that line.
During PHI2, the CPU sends RES (high_active) to the peripherals through that line.
The 6500/1 was not meant to make use of external memory,
and because of this there is no RDY pin.
Also, the whole RDY related circuitry we have in the NMOS 6502 is missing,
making the design a lot more simple.
The PLA was "folded" by the designers "somehow" to make better use of chip space,
but it isn't as wild as it looks at first sight:
We have all of the NMOS 6502 PLA product terms, they just are arranged differently.
//And checking/comparing/identifying the 6500/1 PLA product terms took me a lot of time.
Note, that the CPU core has no R/W# output.
The equivalent of R/W# is placed on the data bus D2 during PHI1,
because the designers ran out of chip space and couldn't afford having a R/W# trace.
Oh, and during a Reset a "write" is forced for initializing the I/O ports with 0xff.
Conceptually the 6500/1 control circuitry builds pretty much on the NMOS 6502
(except for the absence of RDY), it is supposed to do the same like in a NMOS 6502,
including the "illegal instructions".
Like in the NMOS 6502, we have a "step chain" when it comes to read/modify/write instructions.
And the last cycles of an interrupt sequence are handled by conventional logic like in the NMOS 6502.
;---
Now for my boring steps of turning the control circuitry into a simplified TTL equivalent,
just to give the advanced reader a chance of spotting/fixing bugs in case I'm not available:
;---
Complete CPU core (mill plus control circuitry):
The designers ran out of chip space, so we have _one_ line which I had labeled RESIRQ.
During PHI1, the periperals are sending IRQ (high_active) to the CPU through that line.
During PHI2, the CPU sends RES (high_active) to the peripherals through that line.
The 6500/1 was not meant to make use of external memory,
and because of this there is no RDY pin.
Also, the whole RDY related circuitry we have in the NMOS 6502 is missing,
making the design a lot more simple.
The PLA was "folded" by the designers "somehow" to make better use of chip space,
but it isn't as wild as it looks at first sight:
We have all of the NMOS 6502 PLA product terms, they just are arranged differently.
//And checking/comparing/identifying the 6500/1 PLA product terms took me a lot of time.
Note, that the CPU core has no R/W# output.
The equivalent of R/W# is placed on the data bus D2 during PHI1,
because the designers ran out of chip space and couldn't afford having a R/W# trace.
Oh, and during a Reset a "write" is forced for initializing the I/O ports with 0xff.
Conceptually the 6500/1 control circuitry builds pretty much on the NMOS 6502
(except for the absence of RDY), it is supposed to do the same like in a NMOS 6502,
including the "illegal instructions".
Like in the NMOS 6502, we have a "step chain" when it comes to read/modify/write instructions.
And the last cycles of an interrupt sequence are handled by conventional logic like in the NMOS 6502.
Now for my boring steps of turning the control circuitry into a simplified TTL equivalent,
just to give the advanced reader a chance of spotting/fixing bugs in case I'm not available:
Complete CPU core (mill plus control circuitry):