FPGA replacement for VIC I chip?

[lance.ewing]

Having spent quite some time studying the luminance section, I think I can say with certainty now that the metal line I was assuming to be SYNC is indeed the sync line. I now fully understand how both the SYNC pull down and the BLACK/BLANKING pull down blocks work. Looking back at the post from the 11th June where I showed an image of that section, I mentioned that I wasn't yet certain what it was that controlled the difference in luminance output level between the SYNC and BLACK/BLANKING scenarios. The only difference between the two appeared to be the difference in width and shape of their serpentine transistors.

Having now calculated the resistance of those two serpentine shaped transistor gates (using a rough value of 10000 ohms per square), it works out that the SYNC transistor gate would have a resistance of about 40 ohms and the BLACK/BLANKING of about 60 ohms. The 10000 number is not really known though, but it is something of that magnitude, and this is simply to illustrate that there would be a difference in resistance of those transistor gates, even though they are so very wide (not long but wide). So that's one difference.

I've since realised that at the output of the BLACK/BLANKING transistor, there is a short polysilicon line that would also add a bit of resistance for the BLACK/BLANKING scenario (I had initially viewed that simply as a connection to the luminance metal line). It could be something in the order of 150 ohms, assuming the resistance per square for polysilicon were 15 ohms in this die shot, which is something we'll never know for certain, but we have to pick something semi-realistic to work with in these thought experiments.

So a small difference in resistance of their transistor gates, and the addition of the resistance of the short polysilicon line in the case of BLACK/BLANKING, would account for the difference in luminance level between the two.

[lance.ewing]

Let's take a closer look at the Cyan luminance block in the die shot:

The following image shows the schematic for the above:

beyond_shift_reg_35_schem.png (6.88 KiB) Viewed 2106 times

The same principal applies for all seven colours, so I'll explain it in detail in this post and then this can be applied to the other six colours. So let's say that the colour whose luminance is being generated is Light Cyan. The CYAN line would be on, which would turn on transistor Q1. Since it is Light Cyan, then SHADE would be off (since SHADE is off for the light colours and on for the dark colours). This in turn means that the transistor Q2 is off. This results in resistors R1 and R2 being in series and we can basically ignore Q2. For the purposes of determining the resistance, we can't quite ignore Q1 though. As previously mentioned, a turned on transistor gate has a certain amount of resistance and it would have a small effect on the luminance level. R1 and R2 provide by far the highest proportion of the overall resistance.

Let's talk it through with some numbers. I've measured the Q1 transistor gate to be about 407.2 pixels "wide" and about 7.5 pixels long. Therefore the length of the transistor gate in squares is 7.5/407.2 = 0.018418468 squares. So yes, you're reading that correctly, i.e. it is a small percentage of a single square, being nearly 2% of one square. But according to the Mead/Conway book, a turned on transistor gate could be about 10000 ohms per square. Multiple that by the number of squares and we get about 184 ohms.

R1 in the case of the Cyan luminance block is about 237 squares long. R2 is about 135 squares long. Both of these resistors are polysilicon lines. The Mead/Conway books says that at the time the book was written, polysilicon lines typically had a resistance per square of between 15-100 ohms. Not particularly exact, and its quite possible that for the 6561 it doesn't even fall within that range. But let's just pick 15 ohms and see what we get. R1 would therefore be 237*15 = 3555 ohms and R2 would be 135*15=2025.

Since Q1, R1 and R2 are in series when Q2 is turned off, it would mean that in this example (and assuming the resistance per square for a turned on transistor is about 10000, and the resistance per square for polysilicon is something like 15 ohms) that the total resistance between the output labelled LUM shown on the right, and GND shown on the left, would be 184 + 3555 + 2025 = 5764 ohms. Obviously this is going to be nowhere near the real value, but hopefully it is vaguely ball-park-ish. - Note that the LUM output shown in the diagram is connected directly by a metal link to the bonding pad that is connected to the luminance/sync pin. There is nothing else along that line, i.e. LUM in effect represents the luminance/sync pin, which is open drain. So its not a voltage value that is leaving that pin. Instead it provides part of the pull down side of the voltage divider that determines the luminance level. The rest of that voltage divider is on the VIC 20 board.

Now, let's say that it is Dark Cyan whose luminance level is being generated. In this scenario, the Q2 transistor will be turned on. What this does is put Q2 and R1 in parallel. I've measured Q2's width in pixels to be 386.1 pixels, and it's length to be 7.5. It's length in squares is therefore 7.5/386.1 = 0.019425019 and therefore the resistance (assuming 10000 per square) would be about 194 ohms. We've already worked out an equally rough value for R1 of 3555 ohms. Using the resistors in parallel formula, the combined resistance of Q2 and R1 would be about 184 ohms.

The total resistance between LUM and GND for Dark Cyan would therefore be Q1's resistance (184 ohms) plus the combined resistance of Q2 and R1 being in parallel (also 184 ohms, which I'm really hoping is a coincidence), and the resistance of R2 (2025 ohms). That makes 2393 ohms.

It is the lower resistance value for Dark Cyan that makes the luminance value lower than for Light Cyan.

Disclaimer: Please don't rely on the accuracy of the numbers mentioned in this post. They're mainly for illustrative purposes, using the typical values of resistance per square for the materials at the time the Mead/Conway book was written. Different fabrication processes would have had different results though. We don't really know what these parameters would have been for the 6561. Perhaps enough analysis might one day reveal these answers, but for now the values mentioned are solely to describe the basic function of the luminance block.

[lance.ewing]

This evening will most likely be the last look at the luminance section. I mentioned in my previous post that the concepts discussed there would apply to the other colours as well. Before completely abandoning the luminance section, I'd like to show a few more of the luminance blocks for some of the other colours, starting with the following:

The above image shows the Orange and Blue luminance generation blocks. It also shows the output of some of the other nearby luminance generation blocks, such as for Green in the top left, and Yellow in the top right. But let's focus on the image above.

The schematic is identical to what was shown in the previous post. The only difference is that where it shows the Cyan signal entering the gate of one of the transistors, it would instead by either Orange or Blue. Obviously the layout on the silicon is different, and this is due to the different value resistors that are required for the R1 and R2 resistors, and also due to the space available on that part of the chip. But it is the length in squares of the R1 and R2 resistors that predominantly determines the luminance values for each.

Edit:

To provide a further example that differs somewhat in shape from all the other colours, the following image shows the luminance generation block for the Yellow colour:

In this example, the serpentine polysilicon resistors R1 and R2 are much longer in length than were seen for the other colours. This is required as a result of Light Yellow's luminance value being quite close to White. The closer the luminance needs to be to White's luminance level, the higher the resistance required and therefore the longer the serpentine resistors need to be.

[lance.ewing]

It's Friday again, and that always seems to be the most likely evening for me to add to this thread. Over recent days, I've been starting to take a look at the tone generators (as I know there's some interest in that), focussing mainly on the noise generator (although it appears that it is structured pretty much the same as the other tone generators, so I'm guessing what I learn from the noise generator will be applicable to the other three).

This is going to take a while to work through, in fact I'll probably try to work most of it out before I start posting anything here in relation to it.

So in the meantime, to keep up people's interest, I thought I'll take a quick look at the Read/Write input pin and see what that does, being as it sits right next to the luminance output and therefore is the next logical thing to look at in the lower right quarter of the 6561 chip from a physical position perspective. This evening I'll try to put up a few posts that follow that input through for a bit, and then maybe I'll focus on analysing the noise generator for the remainder of the weekend.

Here is the first image:

Open that image in a new tab and you will see, on the right hand side, towards the bottom, a metal to diffusion contact labelled R/W. That metal line is connected directly to the R/W bonding pad. If you follow the green diffusion line, you'll see some pink arrows showing the R/W input signal flowing along. The first thing it comes to is an inverter. The output of this is shown by the pink arrow on the left hand side pointing downwards. That output then passes through another inverter, and the output of that second inverter is the pink arrow shown in the top left corner pointing upwards.

There is one other comment to make about this image at this point. At the bottom of the image, a bit left of centre, there is a transistor whose gate is connected to VSS. VSS is logical zero, so that transistor is always turned off. Interesting.

There are other transistors shown in this image, to the left of centre, and in the top half, that we are not yet going to look at, but will be returning to at some point. At the end of this post, I simply want to point out that the output of the two inverters in series is connected to a metal line with three metal to polysilicon contacts on it. These three contacts are each labelled with R/W. They are labelled with R/W because the double inversion means that their logical level is that same as what came in on the R/W input pin. I also want to point out the polysilicon line heading up in the top left corner that is also carrying the R/W value.

[lance.ewing]

Continuing on from the top left of the previous image:

Open the above image in a new tab, and at the bottom you'll see the metal line with the three metal to polysilicon contacts, and the polysilicon line coming out towards the left, and upwards, with the pink arrow on it. That pink arrow leads in to an inverter, the output of which comes out on the polysilicon line leading upwards from the depletion mode transistor on the left and slightly below centre. That output is therefore /R/W, i.e. the inverse of the R/W input value. This polysilicon line connects to a rather wide transistor towards the top, and that transistor is to the right of another wide transistor whose input is connected to F1 (i.e. phase 1). To the right of the /R/W transistor is another transistor whose input is the inverse of the CS line (i.e. the Chip Select).

You will notice that the diagonal metal line, three from the bottom left, is labelled with CS, meaning that it is the Chip Select signal. At the end of that metal line, it connects to a polysilicon line that enters the input of an inverter. The output of that inverter is what connects to the transistor that is to the left of the /R/W transistor mentioned in the paragraph above.

So what we have is a NOR gate with three inputs. Those three inputs are: F1 (i.e. phase1), /R/W (i.e. the inverse of R/W), and /CS (i.e. the inverse of the Chip Select). Remember that when the R/W pin is low, the microprocessor can write data to the 6561. When the R/W pin is high, the microprocessor can read data from the 6561. This is a three input NOR gate, so only when all three inputs are low/off/false is the output true. The three inputs for this particular NOR gate are all false when the following is true:

• It is phase 2 (since the inverse of phase 1 is phase 2)
• The /R/W input is low, i.e. R/W is high, so it's a microprocessor READ.
• The Chip Select inverse is low, i.e. Chip Select is high/true/on.

To put this all together, when we're in phase 2, and R/W is READ, and Chip Select is true, then the output of this NOR gate is true.

I'll call the output of this NOR gate READ (meaning microprocessor READ).

To the right of this 3-input NOR gate is another 3-input NOR gate. This one is very similar but in relation to WRITE. Two of the three inputs are identical, i.e. the inverse of Chip Select, and phase 1. So this second NOR gate will output a true value when the following is true:

• It is phase 2.
• The R/W input is low, i.e. it's a microprocessor WRITE.
• The Chip Select inverse is low, i.e. Chip Select is high.

I'll call the output of this NOR gate WRITE (meaning microprocessor WRITE)

In summary, the output of these two 3-input NOR gates are the microprocessor READ and microprocessor WRITE conditions, i.e. the conditions under which the 6502 can READ and WRITE to the VIC chip control registers. It is only within phase 2, and only when the Chip Select conditions are met.

[lance.ewing]

The outputs of those two 3-input NOR gates are shown towards the bottom left corner of the following image:

Open the above image in another tab and you'll see the two pink arrows pointing to the right on the polysilicon lines slightly left of the centre of the image. These are the two outputs from the two 3-input NOR gates mentioned in the previous post. Each of these polysilicon lines enters the input of an inverting super buffer. The first of the inverters encountered in each case is serpentine in shape. I'm not sure what the significance of this is, but the overall logical function is of an inverting super buffer. The outputs of these two inverting super buffers connect to metal lines and they both head upwards and out of the image in the top right corner.

Edit 1: The two metal lines head upwards over quite a long distance and eventually link to other metal lines heading horizontally to the left that control the reading and writing from and to the control registers. We'll take a look at that in a later post.

Edit 2/3: I've re-instated what is essentially the original version of the image with the output contacts labelled. It seems that I had them right in the first place.

Prior to the input passing through the higher of the two inverting super buffers, that input signal represents READ, which is when the CPU is trying to read data from a control register. After passing through the inverting super buffer, it is the inverse of this. I've labelled the output of the inverting super buffer as #READ to indicate that it is the inverse. You'll notice that Segher represents the inverse in this way, i.e. with the # in front. The die shot image that I'm using has all of Segher's labels as part of the background image, so up near the control registers, there are a lot of examples of the use of # for the inverse (in fact we're going to see some examples in the next post).

Prior to the input passing through the lower of the two inverting super buffers, that input signal represents WRITE, which is when the CPU is trying to write data to a control register. I've labelled the output of the inverting super buffer as #WRITE to indicate the inverse of this.

Both #READ and #WRITE are used as inputs to the NOR gates used in the control register selection blocks, which we're going to see an example of in the next post.

[lance.ewing]

As part of working out the logic of the previous image, I had to follow the two metal output lines (#READ and #WRITE) to their destinations, so as to be certain that those metal lines really are carrying #READ and #WRITE. I'm now reasonably sure they're correct. As part of following those lines to where they lead, I decided I would look at how they are used with control register D, i.e. the noise control register, since this would be a nice way of leading in to an analysis of the noise generator.

Below we have an image showing the logic that is used to generate the READ and WRITE signals for control register D:

Open that image in a new tab. Hopefully you'll be able to read all the labels. You'll notice towards the bottom one metal line with a metal to polysilicon contact on it that is labelled #WRITE, and above that a metal line with a metal to polysilicon contact on it that is labelled #READ. These two lines have come directly from the output of the two inverting super buffers we saw in the previous post.

You'll also notice four other metal lines that have metal to polysilicon contacts on them. These four contacts are labelled (from the top one) #A0in, A1in, #A2in, and #A3in. These are Segher's original labels. #A0in is the inverse of the value that has come in on the A0 address pin. A1 is the value that has come in on the A1 address pin, and #A2 and #A3 are the inverse of the values that have come in on the A2 and A3 pins.

The following is what the logic diagram is for the above die shot image:

The 4-input NOR gate needs the inputs to be 0000. So to get 0000 as an input, we need #A3 to be 0, #A2 to be 0, A1 to be 0, and #A0 to be 0. This will be the case when A3-A0 represent the binary value 1101, i.e. control register D, the noise register.

By looking at the logic diagram, we now see why the #WRITE and #READ lines are carrying their inverse values. It is because they connect directly to the input of a NOR gate and therefore need to be 0 in order to contribute to an output value of 1. We can see this in action with the #WRITE signal. The image shows that #WRITE has a value of 0, and due to the address matching NOR gate and inverter combination also producing an output of 0, it means that the CR_D_WRITE value is 1. That is, when #WRITE is 0 (i.e. WRITE is 1), and the address matching matches control register D, then the CR_D_WRITE signal is 1.

CR_D_READ and CR_D_WRITE, as shown in the diagram above, are what control the loading of data from D0-D7 internal data bus lines in to control register D, and the reading from the control register on to the D0-D7 internal data bus lines. The same eight data bus lines are used for both writing and reading.

[lance.ewing]

In this post I'm going to continue on from the previous post and show how the CR_D_READ and CR_D_WRITE outputs in the previous post's images are used with the control register. We'll start by showing the image below, which is the section of the die shot that is immediately above the section that we looked at in the previous post:

Open the image in a new tab to get a closer look. You can see the two red polysilicon lines coming in at the bottom of the image. Those are the two outputs from the previous image, i.e. what I labelled CR_D_WRITE (on the left) and CR_D_READ (on the right). The cyan "crD" label kind of gives it away as well, as that was also seen in the previous image. If we follow the polysilicon line on the left, it connects to a metal to polysilicon contact that I have labelled WRITE. The metal line that it is connected to extends the length of the CR-D control register and provides the WRITE signal for all eight of the register's 1-bit cells, via four metal to polysilicon contacts. Only two of those contacts are visible in the image above though.

If we follow the polysilicon line on the right, it connects to a metal to polysilicon contact that I have labelled READ. The metal line that it is connected to also extends the length of the CR-D control register and provides the READ signal for all eight of the register's 1-bit cells, this time via five metal to polysilicon contacts.

The reason why the number of contacts does not match the number of 1-bit cells in the register is because most of those contacts provide the READ or WRITE signal for two of the 1-bit cells. We're going to be focussing on a single 1-bit cell of the register though, so I won't get too much in to that. The image above does happen to show four of the 1-bit cells. I've only highlighted the parts of one of those.

The remainder of the parts highlighted in red, green, blue, grey, and white, all form a part of a single 1-bit register cell. This is what I think the schematic for that 1-bit register looks like:

control_register_cell_schem.png (8 KiB) Viewed 1923 times

I say "I think" because I'm not 100% certain. It is the control registers that I initially started out trying to reverse when I first started looking at this die shot, and the resulting schematic drove me crazy trying to work out. Parts of it didn't seem to make sense, but having now spent quite some time reversing other parts of the die shot, I think I now understand what the circuit is doing in the control register. It relies on a big assumption that the data bus lines are pulled up elsewhere on the chip when in output mode though.

Let's talk it through. The core of the 1-bit register cell is the cross coupled inverters. We can see the two inverters taking up the middle of the image. We can see that the output of the left inverter is connected to the input of the right inverter. We can also see that the output of the right inverter is connected to the input of the left inverter but via the F1 pass transistor (which lets that signal through during phase 1). That connection via the F1 pass transistor is the feedback path that updates itself.

This is kind of a known design up to this point. The bit that was really puzzling me when I was first looking at this is that both the input and output to the register cell come from the same data bus line. From searching the net a bit, I've seen a lot of designs that have separate lines for input and output but I struggled to find anything showing a single line used for both the input and output values.

Ignore for now the label OUT in the diagram above. That is actually the output for the 6561 chip's internal use of the register value. It isn't the output used when the 6502 reads the value of the register. When the 6502 reads from or writes to the register, the data comes in and goes out through that same diffusion to metal contact that is labelled D2 (since this is bit 2 of the control register that we happen to be looking at).

I've tried simulating this and I can't make it work properly. Logically though it seems to make sense. When the 6502 is writing to the control register, the bit value to write will be on the D2 data bus line, and the WRITE line will be on, which will turn on the pass transistor with the W label on the gate. This will let through the D2 value to the input of the first inverter.

That value then gets held within the 1-bit register cell.

When the 6502 is reading from the control register, my big assumption is that the D2 data bus line is being pulled up by something elsewhere on the chip. The READ line will be on, which will turn on the pass transistor with the R label on the gate. You'll notice that the source of that pass transistor is connected to the drain of another enhancement mode transistor whose gate is connected to the input of the pull down transistor in the right hand inverter. That input represents the inverted value of the 1-bit register cell, since it is in the mid point of the two cross coupled inverters. What this means is that if the 1-bit cell's value is currently 0 then that input to the second inverter will be 1, which will turn on the enhancement mode transistor in line with and to the right of the pull down transistor of the second inverter. Now, given that the READ line is on, and the transistor whose gate it is connected to is also turned on, this will pull the D2 data bus line down to 0.

In the other "read" scenario where the 1-bit register cell's value is currently 1, then the mid point, i.e. input to the second inverter, will be 0, which will mean that the D2 data bus line will not be pulled down and therefore will remain as a 1 value as a consequence of it being pulled up elsewhere on the chip.

As I say, it all hinges on there being something that is pulling up the data bus lines when they're in read/output mode.

[lance.ewing]

This evening I'll give an update on where I'm at with the noise generator. It's been slow going, mainly because I've been thinking a lot about the other two VIC 20 projects I've got going in parallel at the moment, but I wanted to make sure I keep this thread going as well.

If we pick up from the end of the last post, where we discussed a single 1-bit cell of the noise control register (CR-D) and show in the following image all eight bits and their values being taken upwards toward the noise generator logic, which is in the section of the chip that is above that shown in this image.

Open that image full size in another tab. At the bottom you can see the very top of each of the eight 1-bit cells of the noise control register. Bit position 2 was the one that we looked at in detail in the last post. Starting at the bottom right corner, we have the value of bit position zero (which I've continued to label D0 for the time being) being taken in to the input of a simple inverter. The output of that then heads up and out of the image at the top. That polysilicon line carries the inverted D0 value, which I've labelled #D0.

Back to the bottom right again, if we move one 1-bit cell to the left, we can see the value of bit position one (which I've labelled D1) being taken up on a polysilicon line that connects to a metal line via a metal to poly contact. That metal line heads up and out of the image at the top. Note that there is no inversion in this case, so the line heading up in the case of D1 is labelled D1.

If we continue back at the bottom of the image again, and follow a similar process for D2 to D6, will see that D2 is inverted, D3 is not, D4 is inverted, D5 is not, and D6 is inverted. The values of each of these are leaving the image at the top edge and are labelled #D2, D3, #D4, D5, and #D6.

The 8th bit position is obviously special and that is taken up on the far left to do its own special function, which we won't come back to until later this year. That line is labelled D7.

One final point to note about this image is that we have a polysilicon line that comes down towards the left hand side and then turns right and passes over #D6, D5, #D4, D3, #D2, D1, and #D0. At each point that it crosses over diffusion, it creates a pass transistor. So this polysilicon line carries a signal that will essentially reload whatever is above this section of the die shot with what is currently stored in the noise control register. That polysilicon line then continues on, turns up and heads out of the image at the top.

[lance.ewing]

Continuing on to the section immediately above the image in the last post, we have the following:

At the bottom we can see the data lines coming in from below, labelled #D6, D5, #D4, D3, #D2, D1, and #D0. Above this, there are three very similar looking sections. To start with, I'm going to look at the first horizontal slice, which looks like this:

In the right corner, we can see #D0 coming in. To the right of it, we can also see the polysilicon line that had formed the pass transistors mentioned in the previous post. These two polysilicon lines are the inputs to this logic block. The logic diagram for this "slice" looks like this:

noise_generator_2a.png (4.11 KiB) Viewed 1884 times

The line I've labelled RELOAD represents the polysilicon line that forms the pass transistors over the seven data lines mentioned in the previous post, and in fact the diagram above shows one of these pass transistors, i.e. the one for #D0. I've called it RELOAD because at this point that is one of the things we know it does. It also happens to be one of the inputs in to the logic block for this first slice, so its also some kind of feedback. The combination of the AND gate and two NOR gates appears to behave as an XOR. It is worth noting though that the output of the first NOR is taken to the next stage (shown by the blue line leaving the image in the bottom right) and therefore I don't think we can simply view this as an XOR. Instead the whole and the part perform two different functions.

The output of the second NOR (i.e. of the XOR) passes through a pass transistor that is controlled by F2 (i.e phase 2). It then passes through an inverter, and the output of that inverter is taken up to the top edge of the image (we'll see where that goes later on). The output is also taken through another pass transistor to the left, which is controlled by something I've labelled F1 (C). I'm not exactly sure what this signal is, but it certainly involves F1 (i.e. phase 1) and a capacitor.

The output of that pass transistor feeds back to one of the inputs of the AND and the first NOR (i.e. it feeds back to the XOR).

[lance.ewing]

At the top of the previous post, I showed an image showing three similar looking sections, the first of which I called a "slice" (my own term to describe it as being a thin horizontal slice of that image). I'm now going to look at the second of those slices. The logic diagram looks like this:

noise_generator_2b.png (4 KiB) Viewed 1882 times

There is a lot that looks different about this diagram. Firstly, the data input, D1, is the non-inverted value (whereas for #D0, it was inverted). The three gates at the bottom are also different. We now have an OR and two NAND gates. The combination of these three gates appears to form an XNOR, in fact you can see exactly this mixed combination of gates mentioned here:

https://en.wikipedia.org/wiki/XNOR_gate

If we look back at the previous post though, and consider that #D0 was the inverted value of D0, then things start to look more aligned when the first slice and second slice with regards to this compound logic gate. An XOR that has a NOT on one of its inputs will behave like an XNOR. So in both cases, it is effectively an XNOR.

The other difference is that the line going up to the top edge is taken up BEFORE the inverter. I don't have any explanation for this yet, so this is an interesting mystery at this stage.

We also have the line going to the next stage in the bottom right corner, once again coming from the middle of the larger compound logic gate. This time it is from the output of the first NAND.

Thinking about it more, the line I've labelled RELOAD might be a slight misnomer. We won't know for sure though until we get to the bit from where that signal comes from.

[lance.ewing]

Now on to the third "slice". I'm not going to go over it in detail because it is exactly the same as the first "slice". So what I'm going to show instead is the first three of these "slices", or stages, linked up together:

And following on from this, we'll see that the fourth one is exactly the same as the second, and that it switches backwards and forwards between the two structures as we go along. The whole seven bit structure looks like this:

At least... that is what I currently think it looks like. I'll have to spend some time thinking it through to see if it makes sense. This is a noise generator though, so its unlikely to make sense . Reading up a bit on how the VIC noise generation apparently works, it supposedly uses a LFSR (Linear Feedback Shift Register), and I guess the above is kind of starting to look a bit like something along those lines, although I can't be sure yet.

And that is as far as I have got through it so far. I should point out that this is only the first half of the noise generator. There is another section at least as big as this one before it gets to its final output. Since I haven't got in to it yet, I'm not sure what connections there are between the above section and the next. We'll have to wait and see.

[tlr]

At least... that is what I currently think it looks like. I'll have to spend some time thinking it through to see if it makes sense. This is a noise generator though, so its unlikely to make sense . Reading up a bit on how the VIC noise generation apparently works, it supposedly uses a LFSR (Linear Feedback Shift Register), and I guess the above is kind of starting to look a bit like something along those lines, although I can't be sure yet.

The details of the noise generator are very interesting because it has not been fully emulated yet. There is a behaviour where the noise waveform will randomly have a different timbre, presumably because the initial contents are different. There were claims in a thread here that this behaviour could be controlled by turning off the noise at controlled timings. That however has to my knowledge never been demonstrated.

[eslapion]

Perhaps a few oscilloscope captures of the noise waveform are in order.

I also wanted to show at what level of volume a VIC-I sound will start suffering clipping.

[Kakemoms]

Reading up a bit on how the VIC noise generation apparently works, it supposedly uses a LFSR (Linear Feedback Shift Register), and I guess the above is kind of starting to look a bit like something along those lines, although I can't be sure yet.

And that is as far as I have got through it so far. I should point out that this is only the first half of the noise generator. There is another section at least as big as this one before it gets to its final output. Since I haven't got in to it yet, I'm not sure what connections there are between the above section and the next. We'll have to wait and see.

I would say this looks like a LFSR with the D0-D7 as a init value and each bit NXOR´ed (or XOR´ed for odd bits) with its inverse previous value and the last lower bit (once it starts propagating). What I don´t understand is the larger diagram which shows a 8-input NAND that is used (with F1 as a control) to decide whether to load the D0-D7 as init (through RELOAD). In practice the 8-input NAND would only output 0 in the special case that all the inputs are 1, so maybe its the logic behind that which is lost to me. It also looks like F1(C) has to be the inverse of F1 in order for this to work. F2 looks like its there to start/stop propagation?

Edit: I suppose there has to be an output to this circuit as well? I tried to simulate the above logic in a short program and it didn´t do well. I got repeating sequences from the logic you showed. In fact, it repeats after 16 numbers independent of the D0-D7 initial value (unless the D0-D7 init changes after a number of cycles). I may have done a mistypo so you might want to confirm that for yourself.

Edit2: Sorry, I meant D0-D6 which repeats after 8 numbers..