MOS 6522 dissection //NMOS
Re: MOS 6522 dissection //NMOS
Just to document the points I'd like to understand after having a deeper look:
- the 6522 requires the address lines stable when phi2 rises. That is a problem on the C64 where the first half of the phi2 cycle is dedicated to the VIC-II (and how does that compare to 6532 and 6526)
- one point I have to look up. You write both ports read the actual voltage levels on PA and PB. I don't remember if it was the 6522 or 6526 datasheet that states for one register the output register value is returned on read no matter if the output is pulled low e.g. from excessive load
- the shift register bug of course
- the 6522 requires the address lines stable when phi2 rises. That is a problem on the C64 where the first half of the phi2 cycle is dedicated to the VIC-II (and how does that compare to 6532 and 6526)
- one point I have to look up. You write both ports read the actual voltage levels on PA and PB. I don't remember if it was the 6522 or 6526 datasheet that states for one register the output register value is returned on read no matter if the output is pulled low e.g. from excessive load
- the shift register bug of course
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/
Re: MOS 6522 dissection //NMOS
Ed and fachat, thanks for the kind workd.
//6532 is a variation of the 6530.
Our dissections showed that 6522 and 6530 sample address lines, R/W# and chip selects during PHI1=1.
Means that the 6502 address\control bus needs to be valid/stable before the rising edge of PHI2.
In a C64 where the VIC-II owns the bus during the first half of the PHI2 cycle (during PHI1=1),
6510 address\control bus becomes stable _after_ the rising edge of PHI2,
and IIRC when using a 6522 on the C64 bus the workaround\trick was delaying the rising edge of the 6522 PHI2 input clock
to compensate for this.
From the 6526 datasheets, 6526 is supposed not to be offended if the address\control bus becomes stable
after the rising edge of PHI2.
So we could assume that the 6526 bus interface and address decoder is built in a different way than in the 6522 and 6530,
but we'll be smarter after the 6526 dissection is finished.
Maybe I should have phrased this better:
If PA\PB are configurated as inputs, and if PA\PB latching is disabled, the 6502 "directly" reads what's on the PA\PB pads.
In this case: if there is a spike on the PA\PB inputs during PHI2 while the 6502 is reading the PA\PB data input registers,
said spike is supposed to show up on the 6502 data bus during PHI2, and that's not good for signal integrity.
Spending thoughts on the shift register bug would be speculative now,
maybe it has something to do with the edge detector which generates SR_CB1_DET#
in "20) CB1" for generating the shift register and Bit counter clock signals.
We will be smarter after the 6526 dissection,
when comparing the shift register related circuitry of 6522 and 6526...
...because it is said that the shift register bug was fixed in the 6526.
fachat wrote:
- the 6522 requires the address lines stable when phi2 rises. That is a problem on the C64 where the first half of the phi2 cycle is dedicated to the VIC-II (and how does that compare to 6532 and 6526)
Our dissections showed that 6522 and 6530 sample address lines, R/W# and chip selects during PHI1=1.
Means that the 6502 address\control bus needs to be valid/stable before the rising edge of PHI2.
In a C64 where the VIC-II owns the bus during the first half of the PHI2 cycle (during PHI1=1),
6510 address\control bus becomes stable _after_ the rising edge of PHI2,
and IIRC when using a 6522 on the C64 bus the workaround\trick was delaying the rising edge of the 6522 PHI2 input clock
to compensate for this.
From the 6526 datasheets, 6526 is supposed not to be offended if the address\control bus becomes stable
after the rising edge of PHI2.
So we could assume that the 6526 bus interface and address decoder is built in a different way than in the 6522 and 6530,
but we'll be smarter after the 6526 dissection is finished.
fachat wrote:
- one point I have to look up. You write both ports read the actual voltage levels on PA and PB. I don't remember if it was the 6522 or 6526 datasheet that states for one register the output register value is returned on read no matter if the output is pulled low e.g. from excessive load
If PA\PB are configurated as inputs, and if PA\PB latching is disabled, the 6502 "directly" reads what's on the PA\PB pads.
In this case: if there is a spike on the PA\PB inputs during PHI2 while the 6502 is reading the PA\PB data input registers,
said spike is supposed to show up on the 6502 data bus during PHI2, and that's not good for signal integrity.
fachat wrote:
- the shift register bug of course
maybe it has something to do with the edge detector which generates SR_CB1_DET#
in "20) CB1" for generating the shift register and Bit counter clock signals.
We will be smarter after the 6526 dissection,
when comparing the shift register related circuitry of 6522 and 6526...
...because it is said that the shift register bug was fixed in the 6526.
Re: MOS 6522 dissection //NMOS
ttlworks wrote:
And that's all for now.
6526 is supposed to be next, and 6520 decapping is in progress.
6526 is supposed to be next, and 6520 decapping is in progress.
And I have to save some money for the lab costs.
Re: MOS 6522 dissection //NMOS
Thanks for the hard work!
From the context of emulating the VIA in VICE, I will have to try to remember what questions I had a few months ago when I was actively looking the the VIA emulation code. Two things I remember right now:
- When the timer toggles Port B pin 7 (PB7), you write in 16b:
For this we have actual test cases in VICE, and we model setting this flipflop as "set it when the ACR is written into, and ACR7 changes from 0 to 1".
The test cases we have, pass with this emulation.
Thinking about it for a few seconds, I realise that the emulation isn't even really wrong (just possibly slightly more complicated than needed). If we set the flipflop under this condition, ACR7 WAS 0. But as long as it is 0, it has no visible effect on PB7 yet; that only happens after it gets set to 1. So in practice, the result is correct.
*some time passes while I experiment with a change in VICE*
Unfortunately, the changed VICE does not pass the test in VICE's "testprogs/VIC20/via_pb7" any more.
I'll need to think a bit on this, I guess.
The other thing is about the shift register while shifting IN. I don't think we have any test cases here, so our emulation is a bit uncertain.
For example, I'm unclear about the following scenario:
- the SR is shifting in under external clock (CB1) control
- 8 bits have been shifted in and the SR flag in the IFR is set
- CB1 keeps toggling, trying to clock in more bits, before the CPU reads from the shift register (which would clear the IFR bit).
Does the shift register shift in more data, if the IFR bit is still set?
There are two possibilities but both lead to data loss (which isn't unexpected, if the cpu is too slow).
- yes, more bits shift in, and the first byte is lost
- no, there is no more shifting, and the next byte is lost.
In VICE the shift counter is implemented as a counter from 0 to 16, where 0-15 are "shifting is active" (and even and odd states correspond to different levels of the clock, i.e. for a bit to shift, the counter changes by 2). And 16 is the state where shifting is finished, inactive, etc. And in several cases, there is the matter, "under which conditions do we change from 'finished' (16) to 'shifting' (0)". I'm sure the emulation is wrong in some cases, but with lack of test cases this is hard to check.
That were my musings so far...
Edit: ah, another one: writing to (or reading from) the shift register starts the shift counter. But what if that is done while there is a byte in/output still going on? Does it reset the shift counter to the start again, or not?
Current emulation code mostly wants the shifting to be finished before resetting the counter; but there are some suggestions here and there that this is wrong. But the few tests pass, so maybe they aren't good enough.
From the context of emulating the VIA in VICE, I will have to try to remember what questions I had a few months ago when I was actively looking the the VIA emulation code. Two things I remember right now:
- When the timer toggles Port B pin 7 (PB7), you write in 16b:
Quote:
PB7_T1 is the signal which goes into the PB7 output driver when Timer 1 emits a pulse
or a square wave on PB7. //In this case, PB7 = PB7_T1.
It is generated by a toggle flipflop, which is cleared runing a T1H counter write,
set when ACR7=0 (when Timer 1 does not use PB7),
and it toggles during PHI2 after a Timer 1 underflow when the "Timer 1 active" RS flipflop is set.
or a square wave on PB7. //In this case, PB7 = PB7_T1.
It is generated by a toggle flipflop, which is cleared runing a T1H counter write,
set when ACR7=0 (when Timer 1 does not use PB7),
and it toggles during PHI2 after a Timer 1 underflow when the "Timer 1 active" RS flipflop is set.
The test cases we have, pass with this emulation.
Thinking about it for a few seconds, I realise that the emulation isn't even really wrong (just possibly slightly more complicated than needed). If we set the flipflop under this condition, ACR7 WAS 0. But as long as it is 0, it has no visible effect on PB7 yet; that only happens after it gets set to 1. So in practice, the result is correct.
*some time passes while I experiment with a change in VICE*
Unfortunately, the changed VICE does not pass the test in VICE's "testprogs/VIC20/via_pb7" any more.
I'll need to think a bit on this, I guess.
The other thing is about the shift register while shifting IN. I don't think we have any test cases here, so our emulation is a bit uncertain.
For example, I'm unclear about the following scenario:
- the SR is shifting in under external clock (CB1) control
- 8 bits have been shifted in and the SR flag in the IFR is set
- CB1 keeps toggling, trying to clock in more bits, before the CPU reads from the shift register (which would clear the IFR bit).
Does the shift register shift in more data, if the IFR bit is still set?
There are two possibilities but both lead to data loss (which isn't unexpected, if the cpu is too slow).
- yes, more bits shift in, and the first byte is lost
- no, there is no more shifting, and the next byte is lost.
In VICE the shift counter is implemented as a counter from 0 to 16, where 0-15 are "shifting is active" (and even and odd states correspond to different levels of the clock, i.e. for a bit to shift, the counter changes by 2). And 16 is the state where shifting is finished, inactive, etc. And in several cases, there is the matter, "under which conditions do we change from 'finished' (16) to 'shifting' (0)". I'm sure the emulation is wrong in some cases, but with lack of test cases this is hard to check.
That were my musings so far...
Edit: ah, another one: writing to (or reading from) the shift register starts the shift counter. But what if that is done while there is a byte in/output still going on? Does it reset the shift counter to the start again, or not?
Current emulation code mostly wants the shifting to be finished before resetting the counter; but there are some suggestions here and there that this is wrong. But the few tests pass, so maybe they aren't good enough.
Last edited by rhialto on Mon Jul 11, 2022 9:14 pm, edited 1 time in total.
-
daniMolina
- Posts: 214
- Joined: 25 Jan 2019
- Location: Madrid, Spain
Re: MOS 6522 dissection //NMOS
Did I hear 6526 is next?
Amazing work, as always. Too bad, it stills a few steps out of reach for my brain. Will keep trying to understand, though.
Amazing work, as always. Too bad, it stills a few steps out of reach for my brain. Will keep trying to understand, though.
Re: MOS 6522 dissection //NMOS
rhialto wrote:
Thanks for the hard work!
It sure isn't easy trying to figure out what actually happens inside a chip
by just tracing the signals and the register Bits,
also it sure isn't easy to think of all the possible/impossible combinations
of conditions\events that might be going to happen when putting a chip to practical use.
In my opinion, the VICE team did a very good job there over the years,
making VICE the best emulator out there...
...and I'm happy to know that somebody will be making good use of our chip dissections.
//My problem is, that I'm not much of a coder. VHDL and C don't seem to be my sort of thing...
Dissecting MOS chips isn't easy, because they tend to be compact and somewhat tricky.
SID went covered, C64 clock generator went covered, the custom MOS CPUs went covered.
With a bit luck, we have the 6526 and the 6520 in dry bags until the end of 2022,
and then (more or less) everything MOS parallel I\O will be covered.
We'll see, if we have enough time\capacity to go for the 6551.
Our plan is to start with dissecting the MOS video chips in 2023.
Re: MOS 6522 dissection //NMOS
daniMolina wrote:
Amazing work, as always. Too bad, it stills a few steps out of reach for my brain. Will keep trying to understand, though.
If you have difficulties in understanding a 6526 dissection later: just dare to ask, and I'm trying to help.
-
daniMolina
- Posts: 214
- Joined: 25 Jan 2019
- Location: Madrid, Spain
Re: MOS 6522 dissection //NMOS
ttlworks wrote:
daniMolina wrote:
Amazing work, as always. Too bad, it stills a few steps out of reach for my brain. Will keep trying to understand, though.
If you have difficulties in understanding a 6526 dissection later: just dare to ask, and I'm trying to help.
-
lance.ewing
- Posts: 6
- Joined: 07 Jan 2013
Re: MOS 6522 dissection //NMOS
Fantastic work! I've been checking on here every few days over recent months in anticipation, and was quite excited today to see your posts. I'll certainly be reading through them in detail over the next few days and weeks.
I considered reverse engineering the 6522 a couple of times in the past, made some headway, but its quite a commitment to complete a whole chip, so I'm glad that someone else has done it
I considered reverse engineering the 6522 a couple of times in the past, made some headway, but its quite a commitment to complete a whole chip, so I'm glad that someone else has done it
Re: MOS 6522 dissection //NMOS
lance.ewing wrote:
Fantastic work!
Hey, there still is some work to do:
"Somebody" could write a few technical articles about the cycle exact behaviour of 6522 handshake, timers, shift register and such.
I don't have the capacity for doing this, because there still are enough other chips to dissect...
Re: MOS 6522 dissection //NMOS
ttlworks wrote:
I don't have the capacity for doing this, because there still are enough other chips to dissect...
Re: MOS 6522 dissection //NMOS
fhw72 wrote:
MOS6520 on the way...
Is that 8 registers I see there? I thought the 6520 only had 6? (But I really know nothing about this IC or how to decode the picture).
-
BigDumbDinosaur
- Posts: 9427
- Joined: 28 May 2009
- Location: Midwestern USA (JB Pritzker’s dystopia)
- Contact:
Re: MOS 6522 dissection //NMOS
AndrewP wrote:
And randomly I was looking at the 65C21 today and trying to work out what it does and what I would ever use it for
Think of the 65C21 as a 65C22 minus the timers and shift register. WDC’s main target for the 65C21 is a replacement for the old MOS 6520 and the Motorola equivalent (MC6821).
x86? We ain't got no x86. We don't NEED no stinking x86!