6561 Die Shot Reversing Explorations

Modding and Technical Issues

Moderator: Moderators

lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: 6561 Die Shot Reversing Explorations

Post by lance.ewing »

lance.ewing wrote:I haven't jumped completely into Verilog yet, although I'm mostly through reading a basic introductory book and have looked over a number of cheat sheets. I'm finding that using the schematic tool within Lattice Diamond to build a module is quite educational as well, since you can then easily see what Verilog it generates for the schematic that you've created.
The schematic tool appears to have a few issues that are difficult to work around. As I mentioned in what I quoted above, I'm starting out with an approach that involves building a lot of the modules using the schematic tool, i.e. creating an Input file of type Schematic and then drawing the circuit out rather than writing Verilog for the module. When saving such a schematic, it automatically generates the Verilog.

The issue that has blocked me a number of times is that it seems to silently refuse to update certain changes to the Ports that are defined. For example, if I add a couple more ports to a schematic, the schematic to verilog tool runs automatically but the verilog output doesn't have the new (in this case) outputs. Likewise if I try to redefine the type of a Port, e.g. make it 8 bits instead of 1 bit, it seems to ignore this as well (or rather it logs an error saying that the port type doesn't match what it is connected to, which isn't true in this case). For a while I thought it was just something I was misunderstanding in using the schematic tool, e.g. perhaps in the way I was naming the nets, but when I create a completely new schematic and add the ports exactly as I was trying to modify the previous one to be like, it works. It seems that it is remembering something about the ports that were defined earlier when I saved it and then it won't update those if I try to change them. It's a bit of an issue because my plan had been to have the main top level module as a schematic block diagram like what I have shown above that I was building in Logisim. If I can't reliably update an existing schematic, it makes it quite difficult to continue building that schematic up over time, which could be many months. I've searched through the menus looking for some option to force a clean generation from the schematic in its new state but I can't find anything like that.

I know I can avoid all this by simply writing it in Verilog, but I was hoping to build up some schematics by hand, place the modules and components as I want them visually, mainly because a big part of the goal is to document things through schematic diagrams like I was doing previously in Logisim. Perhaps an FPGA tool is the wrong tool for that type of goal. I was hoping I'd get further on the simulation side using an FPGA tool though, i.e. to prove that the schematics I'd reversed are behaving as we'd expect.

My current work around for the above mentioned issue is to create a new schematic input file, then copy and paste the whole diagram from the broken one into the new schematic, save the new one and delete the old. Everything is fine with the new schematic then, even though visually it is identical to the one that was supposedly broken. Very strange.
Hoax
Vic 20 Newbie
Posts: 2
Joined: Tue Jun 05, 2018 1:35 pm
Location: Sweden
Occupation: Hobby chip designer

Re: 6561 Die Shot Reversing Explorations

Post by Hoax »

lance.ewing wrote:I thought I might start a new topic to continue the 6561 die shot reversing that I began last year.
Thanks for an excellent thread. I think I'm even more interested in the previous attempt, is there a thread for that one also? I failed to find it, If so where?
User avatar
Mike
Herr VC
Posts: 4841
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: 6561 Die Shot Reversing Explorations

Post by Mike »

Hoax wrote:Thanks for an excellent thread. I think I'm even more interested in the previous attempt, is there a thread for that one also? I failed to find it, If so where?
Lance started with the reversing of VIC-I at page 4 of the thread 'FPGA replacement for VIC I chip?', in 2016, and collected most of his insights in this thread here.

I'd be very much interested to see this endeavour continued, especially given what has lately been found out regarding the Paddle jitter:
in another thread, Mike wrote:So, whatever disturbs the POTY input, it must have to do with the data being read by VIC-I in the display area. The part of VIC-I that controls the video DMA must lie in the near vicinity of the POTY comparator and/or is coupled by a parasitic capacitance to the chip interconnect between POTY bonding pad and POTY comparator.
Emphasis added.
Hoax
Vic 20 Newbie
Posts: 2
Joined: Tue Jun 05, 2018 1:35 pm
Location: Sweden
Occupation: Hobby chip designer

Re: 6561 Die Shot Reversing Explorations

Post by Hoax »

Mike wrote:Lance started with the reversing of VIC-I at page 4 of the thread 'FPGA replacement for VIC I chip?', in 2016, and collected most of his insights in this thread here.
Thanks a lot Mike! I will be heading there as soon as I get the time, reading through the whole thread.
Kakemoms
Vic 20 Nerd
Posts: 740
Joined: Sun Feb 15, 2015 8:45 am

Re: 6561 Die Shot Reversing Explorations

Post by Kakemoms »

Just to update: I have been working and traveling a lot so didn't finish the pictures of the 6560. That being said, we now have a new 3D optical microscope in the lab, so I want to take some pictures with that before we move out of here.

Next week will mostly be spent in Freiburg, but the week after may be a good one for that. I will keep you updated.
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: 6561 Die Shot Reversing Explorations

Post by lance.ewing »

Mike wrote:I'd be very much interested to see this endeavour continued, especially given what has lately been found out regarding the Paddle jitter
Apologies to all that I haven't been active on this project for a while. I tend to go through cycles with regards to what hobby is currently taking my interest. I made the "mistake" (happy mistake I guess) of purchasing an Oric Atmos computer on ebay back in March. Usually I'm searching for VIC 20 related items for sale on ebay, but every now and then I look at the wider retro computing items that are available. The Oric is something I've had a curiosity in for many years but I've never explored that interest before. After being unable to resist purchasing the Oric Atmos back in March, I've since become a bit distracted by it, the most time consuming part being building an emulator for it. The Oric is quite a simple and yet surprisingly powerful machine. But let's get back on topic...

I do intend to continue with the 6561 die shot reversing work. In my most recent posts on this from a few months back, I was starting to get side tracked by attempting to simulate parts of what I'd worked out, but ran into issues in doing this both in Logisim and Lattice Diamond FPGA tool. In hindsight I think that was probably the wrong time to be diverted by that. I should have just kept going with the die shot reversing. So I think when I return to this, which will hopefully be soon, I will put the simulation on hold and move on with reversing more of the chip.
Mike wrote:
in another thread, Mike wrote:So, whatever disturbs the POTY input, it must have to do with the data being read by VIC-I in the display area. The part of VIC-I that controls the video DMA must lie in the near vicinity of the POTY comparator and/or is coupled by a parasitic capacitance to the chip interconnect between POTY bonding pad and POTY comparator.
Emphasis added.
I'll make that my first port of call when I return to the project then. I think I'd taken the address generation part of the die shot through to completion, so something like the POTs would be a good next section to look at. I'm aware that I left the sound generation incomplete from a couple of years back, so I will return to that at some point, in fact after looking at the POTs, the sound generators would be the last remaining section to look at. Beyond that, its just a few smaller glue bits I guess, and identification of various signals between the different sections, and working out more detail around the chip's timings.
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: 6561 Die Shot Reversing Explorations

Post by lance.ewing »

I made a start the other day on tracing around the diffusion, polysilicon and contacts in the area of the die shot that handles POTX and POTY. Still only part way through, and I don't think we're getting near discovering anything about the jitter yet, but I thought I'd post the following image already, even if it is only the area immediately next to the bonding pads. It seems to answer the question of how often those pins are pulled low. This is probably already known, since I'd imagine that it could be observed with an oscilloscope, but here it is anyway:
potx_poty_bonding_pads.jpg
What this image shows is a metal line coming in from the bottom right that ends at a grey metal to polysilicon contact that controls two pull down transistors. On this contact I have a label that says "EVERY 8TH LINE". The reason for this is that that signal goes HIGH on every 8th value of the vertical counter. Let's see the part of the die shot that generates this signal. It is actually quite some distance away from the POT bonding pads. It's way down to the right of the Screen Origin comparators.
every_8th_line.jpg
This is basically just a 3-input NOR gate followed by a non-inverting super buffer. The inputs to the 3-input NOR gate are labelled as VCNT BIT0, VCNT BIT1, and VCNT BIT2, i.e. the first three bits of the vertical counter. When those three bits are all 0, then the output is 1. The non-inverting super buffer obviously retains that logic level and then the signal makes it way down that diffusion line with the two pink arrows on a rather long path to the POTX/POTY section of the die shot. This signal is used in multiple places, but one of these is for the pull down transistors that are shown in the first image above, i.e. the transistors that will pull POTX and POTY down to VSS.

So the first three bits of the vertical counter will be 0 when the vertical counter is 0, 8, 16, 24, etc. Every 8th line, and that is why I went with that name for the label on the contact. For PAL that would be every 8 x 71 = 568 cycles, and for NTSC that would be 8 x 65 = 520 cycles.

To me it appears that this EVERY 8TH LINE signal would be HIGH for the duration of these vertical counter values. Wouldn't this mean then that POTX and POTY are held LOW for 71 cycles on PAL (65 for NTSC)? Does this correlate with what people might have observed using an oscilloscope when using a paddle? And does it make any sense for these to be held LOW for that duration with regards to people's understanding of what is happening with the charging and discharging of the capacitors and the often mentioned 512 cycle sample period?

I saw this from @groepaz in an earlier discussion on the topic of the paddle jitter:
groepaz wrote:what the circuit needs to do is first "look" at the POT line until its pulled low, this is the start of the sample period. then you need a (variable) counter that waits a bit (max the equivalent of 512 cycles) and then pull the line to VCC until the sample period is over (512 cycles since it was pulled low). then release the line, and repeat
If I read that correctly, it sounds like the pulling low isn't happening every 512 cycles. Rather its saying to wait until the POT line is pulled low first, then you wait "a bit" (would be good to know how long that is actually), then you pull the line to VCC, then wait some more until 512 cycles have passed since the POT line was pulled low, then release the line... and then repeat, which means waiting again for the POT line to be pulled low (I think). So that appears to add up to a bit more than the 512 cycle interval that I've seen mentioned in a few places. Is it true then that the 512 value is simply the measurement duration and that there's a bit of waiting in between? Could that waiting be 568 - 512 = 56 for PAL and 520 - 512 = 8 for NTSC?

I guess we'll find out more as I get further into this part of the die shot. It would be good to know people's thoughts on the questions above though.
groepaz
Vic 20 Scientist
Posts: 1187
Joined: Wed Aug 25, 2010 5:30 pm

Re: 6561 Die Shot Reversing Explorations

Post by groepaz »

the period when the line is pulled low by the VIC is about 64µs (really 64 cycles perhaps?) and the sample period is about ~441µs (PAL) or ~443µs (NTSC) (512 cycles eh?) (obvious measurement errors included). (its really easy to see when you measure it with a scope :))

also, your circuit should never "pull to GND". in the first period the i/o pin you monitor the POT pin with should be "floating high", so you can see how the VIC pulls the pin down, but your i/o wont pull it up. in the second period, after the wait, just really pull to VCC for a short time (doesnt have to be for the rest of those 512 cycles) and then go back to "floating high". repeat.
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: 6561 Die Shot Reversing Explorations

Post by lance.ewing »

groepaz wrote:the period when the line is pulled low by the VIC is about 64µs (really 64 cycles perhaps?)
For PAL, a line takes 71 cycles, which is 64µs (71/1108404). So it sounds like what you're seeing with the scope matches what the silicon appears to show, which is that it is pulled low for the duration of one horizontal line. Can you see from the scope whether this is happening on every 8th line? We should be able to have one probe on the video out and another on a pot pin and see it being pulled low in sync with a horizontal line, and then see it do the same 8 lines later. I was hoping to find time to do this myself with my picoscope, but might not get to it for a few days.
groepaz wrote:and the sample period is about ~441µs (PAL) or ~443µs (NTSC) (512 cycles eh?) (obvious measurement errors included). (its really easy to see when you measure it with a scope :))
I think 512 cycles would be something like 462µs for PAL. When you take the sample period measurement, how is that measured, e.g. what on the scope image are you identifying as the start and end of the sample period?

I have now been able to identify and reverse the 8-bit counter on the die shot that is used in the POTX/Y A to D conversion. There is only one 8-bit counter shared by both POTX and POTY. I guess the datasheet implies this in the block diagram as well. The block diagram doesn't show the detail though. What I assume is happening is that POTX and POTY take turns using the 8-bit counter. I have also identified the POTX and POTY 6561 registers (CR8 and CR9) on the die shot and I can see that the value from the single 8-bit counter can be loaded into either the POTX register or the POTY register. Which one the counter value is loaded into is controlled by two signals, one that I've called POTX LOAD and the other signal POTY LOAD. I'm still part way through working out the logic on when those LOAD signals go HIGH.

I intend to post more detailed information on the POT counter, when it increments and when it resets, along with diagrams, sometime in the next few days.
Kakemoms
Vic 20 Nerd
Posts: 740
Joined: Sun Feb 15, 2015 8:45 am

Re: 6561 Die Shot Reversing Explorations

Post by Kakemoms »

lance.ewing wrote:
groepaz wrote:the period when the line is pulled low by the VIC is about 64µs (really 64 cycles perhaps?)
For PAL, a line takes 71 cycles, which is 64µs (71/1108404). So it sounds like what you're seeing with the scope matches what the silicon appears to show, which is that it is pulled low for the duration of one horizontal line. Can you see from the scope whether this is happening on every 8th line? We should be able to have one probe on the video out and another on a pot pin and see it being pulled low in sync with a horizontal line, and then see it do the same 8 lines later. I was hoping to find time to do this myself with my picoscope, but might not get to it for a few days.
groepaz wrote:and the sample period is about ~441µs (PAL) or ~443µs (NTSC) (512 cycles eh?) (obvious measurement errors included). (its really easy to see when you measure it with a scope :))
I think 512 cycles would be something like 462µs for PAL. When you take the sample period measurement, how is that measured, e.g. what on the scope image are you identifying as the start and end of the sample period?

I have now been able to identify and reverse the 8-bit counter on the die shot that is used in the POTX/Y A to D conversion. There is only one 8-bit counter shared by both POTX and POTY. I guess the datasheet implies this in the block diagram as well. The block diagram doesn't show the detail though. What I assume is happening is that POTX and POTY take turns using the 8-bit counter. I have also identified the POTX and POTY 6561 registers (CR8 and CR9) on the die shot and I can see that the value from the single 8-bit counter can be loaded into either the POTX register or the POTY register. Which one the counter value is loaded into is controlled by two signals, one that I've called POTX LOAD and the other signal POTY LOAD. I'm still part way through working out the logic on when those LOAD signals go HIGH.

I intend to post more detailed information on the POT counter, when it increments and when it resets, along with diagrams, sometime in the next few days.
Really interesting development! Are you ready to put it into Verilog yet.. (I know, its a tedious language!) If you want me to put some short routines into verilog, I can certainly manage.
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: 6561 Die Shot Reversing Explorations

Post by lance.ewing »

lance.ewing wrote:What I assume is happening is that POTX and POTY take turns using the 8-bit counter.
Ignore the above. I have realised as I took a closer look tonight that this is a bad assumption. It would actually be quite easy for the counter to be used to measure both pots at the same time. The counter would be reset and then start counting up. The CR8 and CR9 LOAD signals would fire at different times (possibly even the same time on occasions) and therefore load into the corresponding register whatever value the counter was at at that time. It is quite simple and obvious now that I've realised this.
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: 6561 Die Shot Reversing Explorations

Post by lance.ewing »

Kakemoms wrote: Really interesting development! Are you ready to put it into Verilog yet.. (I know, its a tedious language!) If you want me to put some short routines into verilog, I can certainly manage.
I think when I return to using Lattice Diamond, I'll focus on implementing things in Verilog. I think Lattice Diamond wasn't suited to the goals I had when I began using it. I was looking for a tool that would allow me to draw logic diagram type schematics for what I'd worked out, like what I was doing in Logisim, which I could then simulate. I ran into problems with the schematic drawing tool in Lattice Diagram. Things got a bit ridiculous when I was trying to lay out the X decoder. I kept thinking "This would only be a few lines in verilog".

So maybe Logisim, or something simple like that, would be best for creating logic diagrams, and in Lattice Diamond I'll stick to verilog.
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: 6561 Die Shot Reversing Explorations

Post by lance.ewing »

The following image of the die shot shows where the pot counter is, highlighted by the red box:
pot_counter_highlighted.jpg
The following is the logisim diagram for this section of the die shot:
pot_counter_logisim.png
Although it is very similar to the 8-bit horizontal counter, if you were to compare this with the horizontal counter, then you would notice a couple of differences. One is that the clocks are reversed. The pot counter increments on the phase 2 clock, whereas the horizontal counter increments on the phase 1 clock. Another difference is that it has an additional output, which is labelled PCNT_MAX (i.e. pot counter max value, which is HIGH when all the bits of the counter are HIGH). This output is similar to the horizontal cell counter's LAST_VALUE output.

So how is that PCNT_MAX output used?

If you look back at the die shot image showing where the pot counter lies, you'll see a couple of smaller boxes. One of them is pink in colour. This is where the increment logic for the counter lives, which controls when the counter increments. The other box, light blue in colour, is where the pot counter reset logic lives.

The following logisim diagram shows the logic for the pot counter reset and increment:
pot_counter_reset_inc_2.png
pot_counter_reset_inc_2.png (4.99 KiB) Viewed 11142 times
What happens on the chip is that the output of that NOR gate passes through the pass transistor controlled by F1 (which is shown) and then charges up a capacitor while phase 1 is still active (which isn't shown, since Logisim doesn't have capacitors). Then when F1 goes LOW, the charge stored in the capacitor controls another pass transistor that lets the F2 signal through to increment the counter. It seems to be a mechanism to remember the output of the increment logic. Most of the counters on the die shot have such a capacitor.

We can summarise the logic shown in the logisim diagram as follows:
  • The pot counter increments on the phase 2 clock as long as the EVERY_8TH_LINE and PCNT_MAX signals were LOW in the immediately preceding phase 1, i.e. it increments during phase 2 when the current vertical counter value isn't a multiple of 8, and the pot counter hasn't yet reached its maximum value. This implies it stops counting when it gets to 255 and doesn't wrap around.
  • The pot counter resets when the EVERY_8TH_LINE signal is HIGH. So given that this signal is HIGH for a whole horizontal line (e.g. 71 cycles for PAL), then it means that the pot counter doesn't increment at all for such lines and instead is in a constant reset state.
Edit: I have replaced the Logisim diagram for the reset and increment logic. I wasn't happy with the original version, which although it behaved in an equivalent way under simulation, the new Logisim diagram better matches what is on the die shot.
Last edited by lance.ewing on Sat Jun 23, 2018 4:43 pm, edited 2 times in total.
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: 6561 Die Shot Reversing Explorations

Post by lance.ewing »

In this post I'm going to look at the logic that generates the POTX_LOAD and POTY_LOAD signals. These are the signals that trigger the loading of the current pot counter value into either the POTX register (CR8) or the POTY register (CR9). The following image of the die shot shows where this logic lies, highlighted by the pink box:
pot_counter_load_logic_highlighted.jpg
And the following image is a close up of that section of the die shot:
pot_load_logic_die_shot.jpg
Something that becomes a bit obvious after staring at the above image for a while is that the right side is mostly a mirror image of the left side. On the left side is the logic for generating the POTX_LOAD signal, and on the right side is the logic for generating the POTY_LOAD signal. The following image shows a circuit I used to simulate the POTX_LOAD logic in Logisim:
pot_x_load_logic_logisim.png
pot_x_load_logic_logisim.png (6.55 KiB) Viewed 11167 times
The EVERY_8TH_LINE and PCNT_MAX_VAL signals we saw mentioned in my previous posts. The POT_X input on the left has come from a section of the die shot that we haven't looked at yet, but it comes from the direction of the POT X bonding pad after having passed through some circuitry that currently I'm a bit perplexed by (I'm wondering if it relates to the amplifier symbols on the block diagram).

Let's talk through this diagram. Up in the top left, we have an SR flip flop. This flip flop is reset when the EVERY_8TH_LINE signal is HIGH. The inverse output of this SR flip flop is connected to a NOR gate via two paths: One direct path to the NOR gate, and another path (a delay path) through two pass transistors, one controlled by the phase 1 clock signal and the other by phase 2. In the SR flip flop's reset state (as shown above), the output of the NOR gate near the middle of the image is LOW, as shown.

The SR flip flop is set when one of two things happens: The first (and most common case I guess) is when the POT_X signal goes HIGH. The second case is where the PCNT_MAX value goes HIGH (which is when the pot counter has reached 255). When either of these happen, the SR flip flop output changes, i.e. the inverse output goes LOW, which means that the output of the NOR gate near the middle of the image goes HIGH. Note that both the POT_X and PCNT_MAX inputs are controlled by the phase 2 clock signal. So the output of this NOR gate near the middle goes HIGH on phase 2.

Then on the next phase 1 clock signal, the HIGH value between the two inverters changes to LOW. This stops the pull down transistor that this value between the two inverters is connected to from pulling POTX_LOAD LOW. Phase 1 is still HIGH at this point though, so phase 1 (F1) is now pulling POTX_LOAD LOW via the pull down transistor that phase 1 is connected to. When Phase 1 goes LOW again, then there is nothing pulling POTX_LOAD LOW, and the third transistor in the bottom right now has a HIGH on its gate, which lets Phase 2 through to the POTX_LOAD output and so when Phase 2 goes HIGH at this point, POTX_LOAD goes HIGH and follows the phase 2 signal, so POTX_LOAD goes low when Phase 2 goes LOW. This following of phase 2 only happens for this one cycle, since on the next phase 2 signal, the gate of the bottom right transistor is LOW again and the signal between the two inverters is HIGH again. This happens courtesy of the delay path to the bottom input of that NOR gate in the middle. That delay path is of one cycle duration and results in the NOR gate output going LOW again a cycle after it has gone HIGH.

Note that the die shot shows a couple of capacitors (brown rectangles) near the middle of the image. These are once again used as a kind of memory I think. Phase 2 HIGH signal is only let through to the POTX_LOAD output when the capacitor was charged up during the immediately preceding phase 1. I don't show this capacitor in my Logisim diagram, because Logisim is all about logic diagrams and digital simulation, so it doesn't have capacitors. The above Logisim diagram does work though when simulated. This is mainly because my custom "pass transistor" component uses a 1-bit memory cell internally, so the custom pass transistor kind of serves the same purpose of storing the signal from phase 1 that is then connected to the pass transistor that controls Phase 2's access through to POTX_LOAD.

So that was the logic diagram of the left hand side of this "POT load" logic section of the die shot. The right hand side is pretty much identical except that it generates the POTY_LOAD signal and has POT_Y as an input.
pot_y_load_logic_logisim.png
pot_y_load_logic_logisim.png (6.58 KiB) Viewed 11167 times
Everything else is the same. So both flip flops (i.e. one in the POTX load logic and one in the POTY load logic) will reset at the same time, i.e. when EVERY_8TH_LINE is HIGH, which is also when the pot counter is reset. Then the pot counter starts counting up from 0 again (after EVERY_8TH_LINE goes LOW). The flip flop is used so that the POTX_LOAD and POTY_LOAD signals are fired only once within every 8 line period, which will be at the first time that the POT_X and POT_Y inputs are considered to be a HIGH value since the last time the vertical counter was a multiple of 8.
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: 6561 Die Shot Reversing Explorations

Post by lance.ewing »

In this post we're going to look at where the CR8 and CR9 registers lie on the die shot, and how the POTX_LOAD and POTY_LOAD signals load the current pot counter value into those registers. Let's start with the die shot image showing the CR8 and CR9 registers highlighted with a pink box:
pot_x_and_y_regs_highlighted.jpg
I have drawn a pink line down the middle of the box to show that on the left hand side of that line we have the POTY register (CR9), and on the right hand side we have the POTX register (CR8). The following image shows a close up of this section of the die shot:
potx_and_poty_registers_die_shot.jpg
And because it is so big, and we can't really see the detail yet, I have zoomed in again on the top three bits of each register:
pot_x_and_y_regs_close_up.jpg
You will need to click on that image, or open it in another tab, to see the labels.

In the middle of the image, you will hopefully see a couple of metal to diffusion contacts with the labels PCNT1 and PCNT2. These labels represent "pot counter bit 1" and "pot counter bit 2". These two signals come down on two metals lines from the top of the image, just left of centre. There is actually also a "pot counter bit 0" signal coming down from the top as well, but it isn't on a metal line. Instead it is that green horizontal diffusion line at the top, left of centre. Incidentally, although not discussed further in this post, most of those other vertical metal lines left of PCNT1 and PCNT2 (actually all of them other than the VSS and VDD lines) are taking down other bits of the pot counter (i.e. PCNT3 to PCNT7). So we have all the current pot counter bit values coming down into this image from the top left.

If we split this third close up image vertically into three roughly evenly sized sections, and then split it horizontal down the middle, then we have the first three bits of the POTY register on the left, and the first three bits of the POTX register on the right. You will notice D0, D1, and D2 labels on the far right, and also the READ_CR8 and READ_CR9 signals. That is where the current POTX and POTY register values are read by the CPU.

We draw our attention now to the main focus of this post, which are the vertal metal lines in roughly the middle of the image. They have the labels POTX_LOAD and POTY_LOAD on them. These are the outputs of the pot load logic that we were looking at in the previous post. We can now see how these signals are used. The current pot counter value is always available, ready and waiting, on those lines we discussed two paragraphs above. I have labelled the relevant points PCNT0_LOAD, PCNT1_LOAD and PCNT2_LOAD. Now we see that the POTX_LOAD and POTY_LOAD lines are connected to a number of pass transistors. Those pass transistors control access to the "load point" of the 1-bit register cells for the POTX and POTY registers. I think at this point it is self explanatory. When POTX_LOAD goes HIGH, then, for example, the PCNT0 value passes through into bit 0 of the POTX register. Likewise when POTY_LOAD goes HIGH, then, for example, the PCNT2 value passes through into bit 2 of the POTY register. Obviously all 8 bits of the pot counter get loaded into all 8 bits of the relevant pot register at the same time.
Post Reply