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 »

Kakemoms wrote: My thought was that this latch had something to do with prefetch of first character column bits(e.g. screen read and character map read), but it doesn't make sense with the 38&41 trigger (which are essencially mid-screen). Unless its some kind of reset for the prefetch.
The point at which the first character starts can be changed with the control registers, so it wouldn't make sense for that to be hard wired.
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: 6561 Die Shot Reversing Explorations

Post by Mike »

At some time in the raster VIC-I needs to reload/latch the number of columns for a down-counter ("number of columns left for display") - preferably shortly before the border colour could be displayed.

At roughly the same time, it is also necessary to decide whether the next raster forms a new text row (8 or 16 rasters have been displayed from the old text row), in which case the current 10 bit offset into the text register is left as is and latched as new value. Otherwise (old text row) the offset is reloaded from the previously latched value.

I.e. you can expect to find a 10 bit register (current character offset 'under' beam) and latch (start of current text row). And a fast adder which combines screen base and offset for the text screen and colour RAM fetch. And another fast adder, which takes the fetched character code (multiplied by 8 or 16), the Y-offset and the current character base to access either character ROM or internal RAM.
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've started wondering now whether this might be associated with the vertical sync pulses but I have yet to confirm this. Just a suspicion at the moment, but I mean what else could be toggling like that at those points along the line (remembering a whole line is 71)?
I think I've now confirmed this suspicion. I've tracked the output of the latch that has those four X value inputs and it turns out to be the mysterious "Unknown" input leading in to the Y decoder logisim diagram that I posted a few days ago.

http://sleepingelephant.com/ipw-web/bul ... &mode=view

If you look at the bottom left of that diagram, you'll see the Unknown input circled in a light cyan (not intentionally circled, but its nice that it is since it serves a purpose now in drawing your attention to it). That input has a direct connection to the output of what I'm now going to call the VSYNC PULSE latch. So it works in combination with the VSYNC output from the Y decoder. This output from the Y decoder matches the lines where the vertical sync is active, and the vertical sync pulse signal must control what level it is at, i.e. high or low.
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:At some time in the raster VIC-I needs to reload/latch the number of columns for a down-counter ("number of columns left for display") - preferably shortly before the border colour could be displayed.

At roughly the same time, it is also necessary to decide whether the next raster forms a new text row (8 or 16 rasters have been displayed from the old text row), in which case the current 10 bit offset into the text register is left as is and latched as new value. Otherwise (old text row) the offset is reloaded from the previously latched value.

I.e. you can expect to find a 10 bit register (current character offset 'under' beam) and latch (start of current text row). And a fast adder which combines screen base and offset for the text screen and colour RAM fetch. And another fast adder, which takes the fetched character code (multiplied by 8 or 16), the Y-offset and the current character base to access either character ROM or internal RAM.
I will certainly keep an eye out for all of that. I don't have as good an understanding of the timing and behaviour of the 6560/6561 as many of the programmers on Denial, but hopefully I'll learn a bit as I go along, and who knows, maybe I'll try my hand at writing a VIC 20 game at some point. I do have a few game ideas.

I'm expecting to see in the die shot most of what is in the block diagram:

Image

But I'm also expecting there to be more that this. Already, looking at the above block diagram, I'm not seeing much of the X and Y decoder in this block diagram. The SYNC DECODE seems to be the box for it I guess. To me the name sync decode is a nice description for the combination of the bits related to the vertical sync and horizontal sync that we've discovered so far, but there's obviously a lot more that the X and Y decoders do, such as the blanking and colour burst, and since the above is for a 6560, also the interlaced mode. So the block diagram is obviously, and understandably, simplified. I'm hoping to produce a block diagram that has a bit more detail within some of the above boxes.

Last year I think I did a reasonable job of looking at what is in the COLOR DECODE box. What I'm wondering, and it is part of the curiosity, is whether I'll find each of the counters that it mentions. I'm assuming that I probably will, but perhaps a few others. I'm also wondering what each of those lines with the arrow heads really means. Take the line leading down from the SYNC DECODE to the COLOR DECODE. This turns out to be not a single line but at least four that I've discovered so far (a combined V/H sync, the colour burst, horizontal blanking, and vertical blanking).
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: My thought was that this latch had something to do with prefetch of first character column bits(e.g. screen read and character map read), but it doesn't make sense with the 38&41 trigger (which are essentially mid-screen). Unless its some kind of reset for the prefetch.
I was thinking about this again and realised that it leads in well to what I'm intending to look at after the X and Y decoders. Immediately above the Y decoder are two comparators. The comparator on the right takes the value of CR1 (which in the datasheet is called SY or the Screen Origin Y-Coordinate) and the value of the vertical counter, the same lines that pass through the Y decoder. It compares the two values and the output determines whether there's a match. A similar thing happens with the comparator on the left, which takes the bottom 7 bits of the CR0 control register (i.e. SX or the Screen Origin X-Coordinate) and the value of the horizontal counter (the same lines that enter the X decoder), and it compares the two and the output determines whether there's a match. These two comparator outputs lead off to another part of the chip that I haven't yet explored. But that's where I'm intending to look once I'm done with the X and Y decoders. I have a feeling that its these comparators that might decide when to start fetching from the screen and character data.

The two comparators I have mentioned are both in the block diagram. It shows that the output of these are fed in to the horizontal cell counter and the video matrix counter. I guess we'll discover whether this is the case when I start looking at where those lines go.
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: That input has a direct connection to the output of what I'm now going to call the VSYNC PULSE latch. So it works in combination with the VSYNC output from the Y decoder. This output from the Y decoder matches the lines where the vertical sync is active, and the vertical sync pulse signal must control what level it is at, i.e. high or low.
I was taking a look at the 6560/6561 datasheet this evening, and although this next diagram is associated with a timing table stated to be for NTSC, it would appear that it can answer a few questions about PAL as well and relates to the vertical sync pulses.
composite_sync_output.png
If you look at the timings table above this diagram in the datasheet, then you'll notice that the EL and VS widths are the same for NTSC (which the diagram isn't accurate with regards to, since it appears to show different widths for EL, but we'll ignore that). What interests me is that the value of EL and VS are three lines in length. So this is a total of 9 lines (EL followed by VS followed by EL). 9 lines is how long the vertical blanking is in the PAL chip. It starts on line 1 and ends when it hits line 10. The vertical sync starts at line 4 and ends when it hits line 7. Put that all together and the values we got from the PAL Y decoder appear to match what the datasheet is telling us.

What is interesting is what the diagram shows for the equalization pulse lines. The shape of the output is basically the reverse of that for the vertical sync area. It is highly likely then that the vertical pulse latch output controls both of these. What I'm assuming now is that somewhere else on the chip, probably nearby, it puts this all together, and inverts the vertical sync pulses for the area of the vertical blanking that is not within the vertical sync area.

It might not be as simple as this for PAL though, since it appears from a quick search that some diagrams are showing that PAL switches from the equalization pulses to vertical sync pulses halfway through the line, but the information I found wasn't consistent about this (although that could well be what the 35 value is intended for, but that's just a guess at this point). I might have to get the Picoscope out to check this.
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:
lance.ewing wrote: I've started wondering now whether this might be associated with the vertical sync pulses but I have yet to confirm this. Just a suspicion at the moment, but I mean what else could be toggling like that at those points along the line (remembering a whole line is 71)?
I think I've now confirmed this suspicion. I've tracked the output of the latch that has those four X value inputs and it turns out to be the mysterious "Unknown" input leading in to the Y decoder logisim diagram that I posted a few days ago.

http://sleepingelephant.com/ipw-web/bul ... &mode=view

If you look at the bottom left of that diagram, you'll see the Unknown input circled in a light cyan (not intentionally circled, but its nice that it is since it serves a purpose now in drawing your attention to it). That input has a direct connection to the output of what I'm now going to call the VSYNC PULSE latch. So it works in combination with the VSYNC output from the Y decoder. This output from the Y decoder matches the lines where the vertical sync is active, and the vertical sync pulse signal must control what level it is at, i.e. high or low.
Yes, I think that makes more sense when I start thinking in PAL terms. I have been focusing on VGA lately, but the vertical sync in PAL is different and do require horizontal latching during vertical sync interval (unlike VGA).

The first character column has to be loaded before its displayed, but as you point out it can be displayed at different locations. It will be interesting to see if the loading occurs during the 8 pixels before the first column is displayed, or whether it occurs earlier (like during display of the last column). I haven't tested that (but maybe Mike knows more about it).
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: The first character column has to be loaded before its displayed, but as you point out it can be displayed at different locations. It will be interesting to see if the loading occurs during the 8 pixels before the first column is displayed, or whether it occurs earlier (like during display of the last column). I haven't tested that (but maybe Mike knows more about it).
Yeah, it seems like the kind of thing that could be tested with a program, and I'd be surprised if it wasn't already known. I assumed it would be immediately before it needs to draw the character. I doubt it would be during display of the last column because what would that mean for the very first character of the first row? I recall it being mentioned in the forums here in years gone by that the visual artefact observed in the border area immediately before the first column was the VIC chip fetching the data required for the first column, caused by some sort of interference within the chip. Am I remembering correctly?
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: 6561 Die Shot Reversing Explorations

Post by Mike »

lance.ewing wrote:I recall it being mentioned in the forums here in years gone by that the visual artefact observed in the border area immediately before the first column was the VIC chip fetching the data required for the first column, caused by some sort of interference within the chip. Am I remembering correctly?
Yes. Here. :)
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: So this is a total of 9 lines (EL followed by VS followed by EL). 9 lines is how long the vertical blanking is in the PAL chip. It starts on line 1 and ends when it hits line 10. The vertical sync starts at line 4 and ends when it hits line 7. Put that all together and the values we got from the PAL Y decoder appear to match what the datasheet is telling us.
...
It might not be as simple as this for PAL though, since it appears from a quick search [on the Internet] that some diagrams are showing that PAL switches from the equalization pulses to vertical sync pulses halfway through the line, but the information I found wasn't consistent about this (although that could well be what the 35 value is intended for, but that's just a guess at this point). I might have to get the Picoscope out to check this.
I had my Picoscope out last night taking a close look at the vertical blanking for the 6561. I can confirm that it is indeed 9 lines, and that those 9 lines appear to be split evenly in three, as is suggested in the datasheet for NTSC and would seem to apply for PAL as well. I captured a diagram below that shows it. A bit hard to see the detail, but I think clear enough to see the 3 lines of equalisation pulses, 3 lines of vertical sync pulses, then another 3 lines of equalisation pulses. One pulse is half a line in each case, so it is actually 6 equalisation pulses, 6 vertical sync pulses, and 6 more equalisation pulses. The bits at either end are the visual lines, with a horizontal sync and colour burst at the start of each.
vertical_blanking_picoscope.png
A couple of observations about this: You might just be able to notice that the width of the narrower part of those pulses is not consistent. This seems to come from the fact that a line is 71 cycles, and the X decoder works off the cycle count for the current line. It's hard to create two identical pulses when you have to halve 71. This seems to be why the numbers for producing these pulses are: 2, 6, 38, and 41. Obviously the gap between 2 and 6 (i.e. 4) isn't the same as between 38 and 41 (i.e. 3). However, the gap between 6 and 38 (i.e. 32) is the same as between 41 and 2 on the next line (i.e. also 32). So 4 + 32 + 3 + 32 = 71.

The other observation is that we have visual lines on each side of the vertical blanking (obviously), and given that the vertical blanking appears to start on Line 1 (rather than when the Y counter is at 0), then the first line is actually the last line? Or what I mean is that the last "visible" line prior to vertical blanking, equalisation pulses, and vertical sync seems to be Line 0.
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: 6561 Die Shot Reversing Explorations

Post by Mike »

http://sleepingelephant.com/ipw-web/bul ... 9&start=39 :shock:

This would explain why display starts again in the last displayed line when YPOS=0!

That "last" line continues from the current text offset, but then the text offset must get reset to the start during VBLANK.
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:
lance.ewing wrote:I recall it being mentioned in the forums here in years gone by that the visual artefact observed in the border area immediately before the first column was the VIC chip fetching the data required for the first column, caused by some sort of interference within the chip. Am I remembering correctly?
Yes. Here. :)
Ah, yes. That was it. I just read in there that I'd "been staring for long periods at the die shot of the 6561". Nearly 5 years later and still nowhere near the end... and still starting for long periods at the die shot. Admittedly I was only staring back then. I didn't really give the reversing a go until things started popping out at me one day, starting with that dot shift register. I'm sure someone like Brad would reverse this thing in no time if he got the hang of recognising the various materials. :wink: Seems like he's been working at that level to produce video output for years.
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:http://sleepingelephant.com/ipw-web/bul ... 9&start=39 :shock:

This would explain why display starts again in the last displayed line when YPOS=0!
Yes, it would explain that. :D
Mike wrote: That "last" line continues from the current text offset, but then the text offset must get reset to the start during VBLANK.
Interesting. I'm wondering now whether a line I saw leading all the way into the bowels of the address computation section of the die shot, attaching itself to quite a number of contacts in that area, and the signal on which I have currently called VSYNC (as it comes out of that part of the Y decoding logic, but its possible I haven't quite got the name of it right), is the reset you're referring to. Now I'm eager to quickly get up to that part of the die shot.
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:
Mike wrote:http://sleepingelephant.com/ipw-web/bul ... 9&start=39 :shock:

This would explain why display starts again in the last displayed line when YPOS=0!
Yes, it would explain that. :D
Mike wrote: That "last" line continues from the current text offset, but then the text offset must get reset to the start during VBLANK.
Interesting. I'm wondering now whether a line I saw leading all the way into the bowels of the address computation section of the die shot, attaching itself to quite a number of contacts in that area, and the signal on which I have currently called VSYNC (as it comes out of that part of the Y decoding logic, but its possible I haven't quite got the name of it right), is the reset you're referring to. Now I'm eager to quickly get up to that part of the die shot.
Very interesting! Although I doubt my VGA output for the Vic-20 will be able to emulate all aspects of that... :(

Anyway, the more we learn the better. I can't remember if its possible to change a character halfway through it, e.g. changing the color byte. Obviously the Character RAM won't be fetched twice as there is no time for it, but the color RAM could. Anyone knows (or has experimented) around this?
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Re: 6561 Die Shot Reversing Explorations

Post by tokra »

Kakemoms wrote:I can't remember if its possible to change a character halfway through it, e.g. changing the color byte. Obviously the Character RAM won't be fetched twice as there is no time for it, but the color RAM could. Anyone knows (or has experimented) around this?
I have experimented with this and don't think it is possible to change a colour-RAM-location mid-character. At least in my experiments I was unable to achieve that result.
Post Reply