8521 dissection

[rhialto]

Now we can compare with https://ist.uwaterloo.ca/~schepers/MJK/cia6526.html and see of the theories were correct :-)
Thanks!

[daniMolina]

rhialto wrote:

Now we can compare with https://ist.uwaterloo.ca/~schepers/MJK/cia6526.html and see of the theories were correct
Thanks!

From what I've learnt with the 74HCT6526 project, and now that I've managed to make a cycle exact replica of them, Wolfgang model is spot on, at least, regarding the timers.

[rhialto]

ttlworks wrote:

When the hour counter reaches 12, PM toggles.
Note, that the ML output carry doesn't go into the equation,
so writing decimal 12 into the hours if the hours already were not 12 this will toggle PM.
;...
PM flag:

We have sort of a comparator which checks if HH=1 and if HL=$2.
The rising edge of the comparator output toggles the PM flag.
Again, note that the MH output carry doesn't go into this.

The PM flag toggles when TOD reaches 12:00:00, that yes.

But a side effect is that when writing "HH=1 and HL=$2" to the TOD_HR register,
and the TOD_HR register previously was not "HH=1 and HL=$2", this toggles the PM flag.
In this case, you would have to write with the PM Bit _inverted_ into the TOD_HR register
to compensate for this.

This strongly implies (but reading carefully, it doesn't literally say it) that writing $12 to the Hours register when it already contains that value will *not* toggle PM.

But it seems that that is not the case. Even writing $12 when it was $12 already toggles PM, according to tests that have been reported to the VICE team: https://sourceforge.net/p/vice-emu/bugs/1988/

Was this how the above explanation was meant, or is this unexpected? If the latter, could this work out differently on different CIA models perhaps?

[ttlworks]

rhialto, sorry to say this:

It's been more than a year, meanwhile we dissected some other chips,
and since December 2023 the chip dissections are put on hold.

Me and Frank usually only had the capacity for dissecting the latest revision of a chip,
we simply can't cover all revision of a chip.

Also, 8521 "is supposed to be" "sort of a drop in replacement" for the 6526,
but we never found the time to take a closer look at the 6526.

PM flag is quite difficult stuff, and digging into it again would take me some time.

[fhw72]

rhialto wrote:

Was this how the above explanation was meant, or is this unexpected? If the latter, could this work out differently on different CIA models perhaps?

Maybe we will take a look at that as soon as the 6526 has been vectorized and dissected. But this may take some time... if not years until this happens. (If it will ever happen at all!)

[daglem]

Hi Frank and Dieter!

I have just finished a MOS 8521 FPGA implementation based on your excellent work - kudos to you!
See https://github.com/daglem/reDIP-CIA

Here are a few comments / corrections which you may want to incorporate.

8e) / 9e) TA_Q and TB_Q should be inverted (same polarity as TA_INT / TB_INT)
Both the 6526 datasheet (see Toggle/Pulse) and tests confirm this.

10a) A transparent latch is missing in the schematics. See image.

10b) A missing metal contact changes the circuit. See image and die photos.

10a) / 10b) Driving of ICR register outputs to 0 is delayed by a cycle. I'm
guessing this is caused by capacitance delay in rather long polysilicon gate
strips when these are driven by the positive output of weak inverters, but
this is above my pay grade

I've also had to look at previous steps of the demorganization for the TOD
counter in 5b) and the shift register counter in 11b) in order to get things
right.

Is there any chanche of a dissection of the MOS 6526 interrupt block?
This is different from both the 8520 and 8521, and it would be cool to get that exactly right as well.

Best regards,

Dag

[ttlworks]

Hi Dag,

Quote:

I have just finished a MOS 8521 FPGA implementation based on your excellent work - kudos to you!
See https://github.com/daglem/reDIP-CIA

Thanks for the kind words.
It's always nice for us to see somebody putting our work to good use.

Quote:

Here are a few comments / corrections which you may want to incorporate.

Thanks for the comments\corrections.

Quote:

8e) / 9e) TA_Q and TB_Q should be inverted (same polarity as TA_INT / TB_INT)
Both the 6526 datasheet (see Toggle/Pulse) and tests confirm this.

Yes, I made an error while demorganizing the logic in 8e) / 9e). Fixed this.

Quote:

10a) A transparent latch is missing in the schematics. See image.

Now how could this happen ? Fixed this.

Quote:

10b) A missing metal contact changes the circuit. See image and die photos.

Yes, didn't notice the missing via between pullup and VCC. Fixed this.

Quote:

10a) / 10b) Driving of ICR register outputs to 0 is delayed by a cycle. I'm
guessing this is caused by capacitance delay in rather long polysilicon gate
strips when these are driven by the positive output of weak inverters, but
this is above my pay grade

Hmm... no: for Timer A and Timer B, the polysilicon gate strips
(from circuitry to internal data bus drivers) have about the same length.

To clarify things:
IIRC IFR Bits are cleared during PHI1 with IFR_CLR in the cycle which _follows_ the IFR read.
//This asks for poking IRQ# and the data bus with an oscilloscope...
If you already did, and you are not referring to that IFR_CLR delay,
then sorry: it would be above my paygrade, too.

Quote:

I've also had to look at previous steps of the demorganization for the TOD
counter in 5b) and the shift register counter in 11b) in order to get things
right.

Thanks, I appreciate your effort (demorganization sometimes isn't easy).

Quote:

Is there any chanche of a dissection of the MOS 6526 interrupt block?
This is different from both the 8520 and 8521, and it would be cool to get that exactly right as well.

Sorry to say this:
This could take some time, because Frank currently seems to be unavailable,
and I have some difficulties with interpreting the diffusion layer of microscopic chip pictures on my own...

Best regards,
Dieter.

[daglem]

Hi Dieter,

Wow, that was fast!

ttlworks wrote:

Quote:

10a) / 10b) Driving of ICR register outputs to 0 is delayed by a cycle. I'm
guessing this is caused by capacitance delay in rather long polysilicon gate
strips when these are driven by the positive output of weak inverters, but
this is above my pay grade

Hmm... no: for Timer A and Timer B, the polysilicon gate strips
(from circuitry to internal data bus drivers) have about the same length.

To clarify things:
IIRC IFR Bits are cleared during PHI1 with IFR_CLR in the cycle which _follows_ the IFR read.
//This asks for poking IRQ# and the data bus with an oscilloscope...
If you already did, and you are not referring to that IFR_CLR delay,
then sorry: it would be above my paygrade, too.

ICR "1" bits are still read out in the cycle after the (first) read of the ICR, so something fishy is going on.
This issue is revealed by dd0dtest in the VICE testbench.

ttlworks wrote:

Quote:

Is there any chanche of a dissection of the MOS 6526 interrupt block?
This is different from both the 8520 and 8521, and it would be cool to get that exactly right as well.

Sorry to say this:
This could take some time, because Frank currently seems to be unavailable,
and I have some difficulties with interpreting the diffusion layer of microscopic chip pictures on my own...

I'm currently trying to decode what's going on in the only microscope image I've been able to find: http://siliconpr0n.org/archive/doku.php ... r:mos:6526
It's quite hard to see/guess what's going on under the metal layer, but so far it seems to me that 10a) (ICR 0..4) is functionally equivalent to the MOS 8521.
One issue is that according to tests, ICR 1 (timer B) should behave different from the rest, and I can't really see why
And unfortunately 10b) (ICR 7) is badly smudged in the image, so I doubt I can get that right

I'll patiently await your dissection of the MOS 6526, in the mean time I'll probably just do some guesswork based on available tests

Thanks again for your impressive work on the MOS chips!

Best regards,
Dag

[daglem]

Using the MOS 8521 vectorization as reference, and with a bit of guesswork, I think I managed to make sense of the MOS 6526 ICR block.

In short, 10a) (ICR bits 0 - 4) is functionally equivalent - it just omits two inverters in series in the W_IFR path.

On the other hand 10b) (ICR bit 7 and IRQ) is different - it adds a transparent latch to delay INT_ACT until PHI1.

This introduces races - the inputs of the SR latch for ICR bit 7 and IRQ can both be driven to zero at the same instance (tests show that IFR_CLR goes to zero last), and the same thing goes for the SR latches for ICR bits 0 - 4 (tests show that IFR_CLR goes to zero last for timer B only).

The MOS 6526 FPGA implementation is now finished!

[ttlworks]

Dang: 10b)
In the schematics, it's low_active INT_ACT#, and that's correct.
In the chip pictures, that signal is labeled INT_ACT, high_active, and that's not correct. Fixed this.

Just for you, a quick drawing made from your 6526 ICR guesswork:

Dead Bird Eagle 6.4 schematic file:

6526_icr_sch.zip

(37.13 KiB) Downloaded 10 times

[daglem]

ttlworks wrote:

Dang: 10b)
In the schematics, it's low_active INT_ACT#, and that's correct.
In the chip pictures, that signal is labeled INT_ACT, high_active, and that's not correct. Fixed this.

Just for you, a quick drawing made from your 6526 ICR guesswork:

Great! This covers the only part of the 6526 which is known to be functionally different from the 8521.
There may be other things, of course, but that would not be covered by any tests I'm aware of.

Just one small nitpick - R_IFR (not W_IFR) should be connected to the readout of D7io.

ttlworks wrote:

Dead Bird Eagle 6.4 schematic file:

This reminds me that KiCad probably still doesn't convert Eagle files perfectly.
I actually patched KiCad years ago in order to handle your SID schematic, but IIRC there may still be things to improve.

[ttlworks]

daglem wrote:

Just one small nitpick - R_IFR (not W_IFR) should be connected to the readout of D7io.

Dang. Fixed this.
In my defense, I have to say that my head is full of 6561, and that it's getting increasingly difficult for me to stay focused/concentrated.

daglem wrote:

This reminds me that KiCad probably still doesn't convert Eagle files perfectly.
I actually patched KiCad years ago in order to handle your SID schematic, but IIRC there may still be things to improve.

I still feel sorry/guilty for sticking with Dead Bird Eagle... after Autodesk shot the bird.
It's just that some KiCAD things still feel impractical to me, and that I can draw schematics at least twice as fast with Eagle.
After 20 years of drawing schematics and PCB layouts with Eagle for a living, I admit that I might be a little bit biased...

SID was our first chip dissection, Frank and me would have liked to eventually do a _proper_ SID dissection with the skills/experiences we have now,
but we never had the time.

;---

Hmm. About the chip dissections:

Imagine somebody salvaged a 50+ years old control cabinet from the dumpster.
It was planned/built by probably the best engineers in that time frame.

All you have is maybe a short/vague description,
plus the pinout for a 40 pin connector between the control cabinet and the "outerworld".

5000+ relays inside, and all of the wires have the same color.
Now you are trying to draw/interpret schematics from _photos_ of the innards of that control cabinet.

To me, that's what dissecting chips feels like.
Plus that "Indiana Jones factor", when you always expect to bump into traps and man eating bugs behind the next corner.
To quote a former coworker: "It is fun, but not everybody can take that much fun."

[BigDumbDinosaur]

ttlworks wrote:

5000+ relays inside, and all of the wires have the same color.

Sounds like some telephone switchboards I worked on in the early 1970s in between computer gigs.  They didn’t have 5000 relays, but it seemed like it at times.  The wire was all greyish-white and daintily laced together (no cable ties), but fortunately the wire itself was never the problem.

In any case, I can well appreciate what it takes to reverse-engineer a chip that was designed more than 40 years ago, knowing only the external connections, the device’s general function and how transistors are supposed to work.  You have a lot more patience in that regard, my friend, than I do. 

[ttlworks]

BDD, thanks for the appreciation/compassion and the kind words.
To me, it is helpful to keep going, times are not easy for me right now.

Greyish-white wire.
Remembers me back to that day during apprenticeship, when I had to do a cable harness.
It started with placing a drawing on a piece of wood, then pounded in some nails according to said drawing.
No cable ties, it was waxed thread. IIRC The insulation of the wires we had back then didn't like soldering much.
Dang, I'm getting old. //and off topic.

[BigDumbDinosaur]

ttlworks wrote:

Greyish-white wire.
Remembers me back to that day during apprenticeship, when I had to do a cable harness.
It started with placing a drawing on a piece of wood, then pounded in some nails according to said drawing.
No cable ties, it was waxed thread. IIRC The insulation of the wires we had back then didn't like soldering much.

Back in my railroad days, the board-with-nails (not real nails, though—no head) method was how car wiring harnesses were built.  Some of those boards were about 60 feet (18.2 meters) long and had hundreds of nails.  I think the smallest wire size used was 14 AWG, and a lot of it was 10 or 12 gauge.  By then, lacing with thread had given way to cable ties, which were installed with a pneumatic gun.

Quote:

Dang, I'm getting old...

I got you beat in that regard.