6561 Die Shot Reversing Explorations

[nippur72]

[...] appear to be completely redundant, i.e. they don't connect to anything, which makes me think that parts of this circuit within the black box (maybe most of it) has been deliberately disconnected.[...]

could it be a suppressed register loading function? Does the circuit in the black box vaguely resemble that?

My guess is that they designed the 8-bit SRs so that the user would be able to load a "waveform" into it, not only to change the duty cycle of the square wave, but also to define the octave range of the voice (e.g. loading "10101010" => highest octave). But for some reason they decided to remove this feature; and instead of redesigning the area without the SRs, they just disconnected it. Sounds plausible?

[lance.ewing]

This doesn't appear to be the case, because the polysilicon output line coming out of each bit of the shift register is an output only. In all cases it is feeding the input of a transistor gate, in fact in each case the output line is feeding two transistor gates. There's no way for a level to come in via that route. The only way to get a HIGH or a LOW into the shift register is via the feedback path that comes from the NOR gate whose inputs are the 8th bit of the SR and the inverse of the noise enable bit. I can't see any evidence of another mechanism to load a waveform.

I think I'm going to have to reverse this apparently redundant circuit to see what it might have done.

[lance.ewing]

I spent some time this evening reversing what is going on inside that black box, or perhaps I should say what might have been going on if it was connected up. One thing I can say is that it is definitely not purely digital in nature.

I can see lots of pull down transistors, which are the transistors whose gates the various bits in the shift register are connected to. And there is definitely a pattern to those pull downs. What we have is this:

SR7 and SR0 are connected to two pull downs in parallel to each other (a bit like if they were NORed together, if there had been a pull up)
SR6 and SR1 are connected to two pull downs in parallel
SR5 and SR2 are connected to two pull downs in parallel
SR4 and SR3 are connected to two pull downs in parallel

In addition to the the above, we also have:

SR6 and SR1 are connected to two pull downs in series
SR5 and SR2 are connected to two pull downs in series
SR4 and SR3 are connected to two pull downs in series

Given that pattern, it seems strange that there is an absence of SR7 and SR0 connected to two pull downs in series. Instead where I'd expect to see that, we have the area of the die shot that has the two polysilicon lines that I mentioned previously were not connected to anything. I think that these would have originally been where the two pull downs in series for SR7 and SR0 would have been. Instead it seems that SR7 has been disconnected from the polysilicon line that it would have used, SR0 disconnected from the line it would have used, the diffusion link between the two polysilicon lines removed, and SR0 connected to the polysilicon line that SR7 would have been connected to, creating one pull down, which is then connected straight out to the output via a metal line.

There are also a number of transistors that I think are acting as resistors. A good indication of this is when the dimensions of the transistor gate are non-standard for a normal logic gate. When you see all kinds of large shaped transistor gates of varying shapes and sizes, then there's a good chance that they're acting as resistors (although sometimes they'll be a capacitor, so you need to look at whether the transistor gate is connected to the diffusion on one side of the transistor to confirm it is a resistor; it wouldn't make sense for a capacitor to have such a connection).

I think the original design might have had a reference voltage connected to the two pull down transistors in series for SR7 and SR0, then a resistor, then the two pull down transistors in series for SR6 and SR2, then a resistor, then the two pull downs in series for SR5 and SR2, then a resistor, then the two pull downs in series for SR4 and SR3, then a resistor, then the two pull downs in parallel for SR4 and SR3, then a resistor, then the two pull downs in parallel for SR5 and SR2, then a resistor, then the two pull downs in parallel for SR6 and SR1, then a resistor, then the two pull downs in parallel for SR7 and SR0, and then that connects to the output. All those resistors are different shapes and sizes though. I can tell by looking at them that they'd have different resistances.

I don't know much about analog electronics, so not sure what such a circuit would have done. So perhaps it is good that they decided to disconnect it, because now we don't have to worry about it for the purposes of understanding how the 6561 sound works.

Would certainly be interesting to see a die shot of an original pre-VIC 20 6560 (as used in Attack UFO).

[nippur72]

I made a feature request to the VICE emulator asking to implement the newly discovered noise generator. See it here.

[lance.ewing]

I made a feature request to the VICE emulator asking to implement the newly discovered noise generator. See it here.

Cool. I read through it and I think the VHDL makes it clear. My only comment about the description is that saying the taps are 3, 12, 14 and 15 might be misleading to some people. I think it needs to spell it out, something like this: "the taps are bits 3, 12, 14 and 15, i.e. the 4th, 13th, 15th and 16th bits. But as I say, as long as they look at the VHDL, then they should get it right.

[lance.ewing]

I was doing a few searches online and it appears that some people were already aware that the VIC 20 noise LFSR was 16-bit:

https://chipmusic.org/forums/post/97950/#p97950

and:

https://books.google.co.uk/books?id=UlB ... &q&f=false

That book (published last year) says on page 71:

A white noise generator, driven by a 16-stage LFSR, generates a binary noise pattern of 65535, which can be modified using a 7-bit frequency register.

I suspect that those two references had the same source, given that they're both about chipmusic/chiptunes. Maybe @plgDavid (David Viens) was the source? If so @plgDavid, I was wondering how you knew this and that VICE was therefore wrong?

[nippur72]

I wonder if they knew the exact LFSR taps, or only that it was a 16-bit one.

P.S. a small errata corrige: I realized in my FPGA implementation the clock is actually twice the 17 Mhz PAL or 14 Mhz NTSC clock frequency (I guess it has something to do with VGA video signal generation), so the clock divider is not 8 but 4.

Talking of frequency there is still something I have to understand: with a POKE 36877,254 the counter is triggered at the rate of 17.74 Mhz / 4 = 4,435,000 Hz. Now the LFSR loops every 65,535 steps, that is 4435000 / 65535 = 67.67 Hz. That mean you should hear a noise "pattern" repeating very quickly forming a humming sound at circa 67 Hz. But instead I can hear very distinctively the repeating "pattern" at a much lower rate, I would say around 10 Hz. It seems there is an 8 scale factor somewhere (perhaps the 8-bit LFSR?)... indeed 67 / 8 =~ 8 Hz which is compatible with what I can "hear". Any thoughts?

[nippur72]

I reply to my own question: in the CR-D the 8-bit shift register is shifted at the rate of the noise LFSR, so that results in an (average) scale down of 16 (the 8 bit sreg needs to roll twice to form a complete square wave). And that is indeed compatible with what I hear.

This also leads to the generic formula of the notes on the VIC-20 (correct if I'm wrong):

Code: Select all

frequency = clock_frequency / clock_divider / 16 / counter

where: 
frequency = 17740000 PAL, 14315000 NTSC
clock divider = 32, 16, 8 or 4
counter = (128-((PEEK(voice)+1) and 127))
16 = steps needed to form a square wave with the 8-bit shift register (8 bit "1" and 8 bit "0").

[lance.ewing]

Over the past few evenings, I've been reversing the part of the die shot where the sound clock dividers reside. The following image shows where that area is, highlighted with a pink border:

And the following is the logic diagram from my simulation of the reversed circuit in logisim:

The circuit uses a 5-bit counter (at the top) in conjunction with a series of NOR gates (at the bottom) to produce the increment signals for the 7-bit counters of the four voices.

The input to this 5 bit clock divider counter is the ~1 MHz (1108404) F1/F2 clock rate (on the right, about half way down), i.e. the 6561 input clock divided by 4. The CR-D (noise) increment goes high at half that rate, the CR-C at half again, CR-B at half again, and CR-A at half again.

I simulated this with Logisim Evolution and produced this timing diagram:

So that means that the 7-bit counter for the noise voice is incrementing at 1/8th the 6561 input clock or 1/2 the 6561 output clock.

Does this align with what people have observed?

Edit: I forgot to mention the interesting bit. There is an unused output from the clock divider circuit that is at half the CR-A rate (shown at the bottom at the far left of the logic diagram). From the die shot design, it is clear that they were experimenting with the rates of the various sound voices. They designed it in such a way that any of the four voices could have their 7-bit counter incremented at any of the 5 rates, just by changing a small piece of diffusion link. What we have in the 6561 is what they must have decided to go with, and that slowest rate ended up not being used.

The squares of diffusion (in green) around the white metal to diffusion contacts, are completely redundant in the die shot image shown above. But their placement is such that they could be connected to one of the five diffusion lines coming down (indicated by the pink arrows near the top). Those five vertical lines are the five outputs from the clock divider logisim diagram shown above. The four horizontal metal lines at the bottom are for the four increment signals for the four voices. So you can see that by linking one of the metal to diffusion contacts (white circles) to one of those five vertical diffusion lines (green), they could choose which of the five rates that each of the voice's 7-bit counters would increment at.

[nippur72]

Does this align with what people have observed?

yes that's exactly what I wrote in the FPGA implementation before knowing the actual figures.

P.S. the unconnected clock divider ... cool!

[groepaz]

regarding that noise LFSR - i looked into the VICE code a bit. i think the code we need to patch is here: https://sourceforge.net/p/vice-emu/code ... und.c#l349

now, the whole file lacks comments, and i am not really familiar with how vic20 sound works at all - that doesnt really help perhaps someone can help to connect the dots =D

one thing thats puzzling a bit - the vhdl code has a one bit output, the vice source uses an 8bit table (in some weird way). so bytes have to be formed from the lfsr output, but how exactly? and what are the frequency counters in the c code? and uhm. yeah =)

if someone could stare at it a bit and throw some ideas, i might give it a try... right now i am very reluctant to touch it, i'll probably only screw it up

some good testcases for this are also very welcomed. like tunes that sound totally broken in vice right now because of the wrong noise generator - and a recording from the real thing.

[nippur72]

@gropaz looking at the VICE code (I'm new to it), it seems to me the mod is between line 353 and 361, in particular line 357.

"snd.ch[3].out" is the output for the noise channel, it's a byte with values $0 and $1 (1-bit output). The VHDL code has also 1-bit output but in C the value is stored as a byte (unsigned char).

The cycle counters in the C code are used to make the computation in batches of CPU cycles, on the contrary the VHDL code works at 1 cycle granularity (that's the difference between software and hardware emulation).

I don't know how to build VICE (needs linux?), otherwise I could give it a try myself. If you need more info PM me or perhaps open a dedicated thread under "Emulation and cross development"?

EDIT: I've opened a dedicated thread: Noise generator implementation in VICE

[lance.ewing]

I realised about a week ago that I've reached a point where I've identified what pretty much all parts of the 6561 die shot do. So I thought I'd have a go at creating a diagram that highlights all of the functional blocks. Here is my first attempt:

https://sites.google.com/site/mos6561vi ... blocks.jpg



There are a number of deactivated 6560 features in the 6561 die shot. There's a "Divide input clock by 3.5" logic block that is completely disconnected. In the 6560, it would divide the 14318181 VIC input clock to get approximately 4090908 Hz, which it would then treat as the equivalent of the PAL input clock and would feed that into the divide by 2 to get the MEM CLK (2045454 Hz), and then divide by 2 again to get F1/F2, which is the output clock (1022727 Hz). The 4090908 Hz would be used as the dot/pixel clock as well. - In the 6561 though, the input clock is the same as the dot clock.

There's also a "Divide input clock by 4" block that in the 6560 divides the 14318181Hz by 4 to get the NTSC color subcarrier frequency of 3579545Hz, but in the 6561 this block has been disconnected, and the input clock connects indirectly up to the line that is used as the PAL color subcarrier frequency, because they're the same frequency. So in the 6561, input clock = dot clock = color subcarrier frequency, but in the 6560, input clock, dot clock, and color subcarrier are all different, which is why it has these extra dividers that are not used in the 6561.

[nippur72]

simply amazing!

EDIT: I just discovered the other thread "FPGA replacement for VIC I chip?" where you discuss about colour generation! It's a quite lengthy thread so I haven't read it yet, but please can you tell me if we have a table of the VIC-20 color palette, or at least a way to calculate it ?

[Kakemoms]

Looks nice.

Could you also say something about how the control register values are stored. Probably not important, but for me it would be interesting to know.

And also... What are the "not used" sections of the tone generators.. Filters? Or has it something to do with the sound mixing?