6561 Die Shot Reversing Explorations

[nippur72]

No, I don't think that will match because yesterday I simulated all possible combinations, changing speeds, connections and so on, but nothing of what I tried matched the real VIC-20 output.

I now believe the LFSR is running at the correct speed because of the loop cycle length, and also the audio is running at the correct speed (twice faster than CR-C as you initially proposed), that is confirmed by the fact that the smallest wavelength increment does matches the VIC-20 one.

But for some reason our model is outputting shorter runs of "0"s and "1"s... I just don't know why.

Today I extracted the "bits" from the real audio waveform, decoding it as if it was a sort of digital transmission. It wasn't easy because it required precise clocking, but luckily I was able to derive a clock correction from the signal itself.

Illustrated in the picture below:

Inspecting the bitstream I verified it repeats every 65535 bits, which is indeed the length of the LFSR cycle.

Now that we have the actual bits coming from the 8bit SR, I'll use them in my debugs, hoping that will lead to some new insight. I attached the file in case you want to run your own experiments on it. Tell me if you want it in some other form (JSON or else).

[tlr]

That bucket plot was a clever idea. I'm following this with great interest!

I have a theory that the sometimes shifting timbre of the noise generator is related to a pattern that gets stuck in the shift register and then modulates the output of the LFSR in some way. I can't really find a good explanation on how though. I'm hoping that Lance will come up with something from the die.

[nippur72]

I have a theory that the sometimes shifting timbre of the noise generator is related to a pattern that gets stuck in the shift register and then modulates the output of the LFSR in some way. I can't really find a good explanation on how though. I'm hoping that Lance will come up with something from the die.

yes the change in timbre is almost surely due to certain patterns stuck in the SR. The matter is HOW it gets stuck, because on the three sound voices the SR quickly fills with "0" after the voice has been turned off. Instead the SR on the noise voice seems to never gets cleared.

My guess (described in one of my prev messages) is that there's an XOR in place of an AND gate in the feedback bit, making the SR change behavior the following way:
- voice "on": SR rotates and inverts the feedback bit, square wave is generated
- voice "off": SR rotates and not inverts the feedback bit, the SR just rotates
This implies that if you turn on the noise voice while SR is in the middle of its rotation, a certain pattern gets stuck there. I already have that in the FPGA and indeed it works similarly to a real VIC. But first we need to address the issue why the generated random sequence does not match the real hardware.

[lance.ewing]

I've just been doing some simulations, and it appears to me that the trigger for the 8-bit shift register is edge triggered and not level triggered. So that link from the LFSR, i.e. NSR0 (first bit), will only trigger the 8-bit SR shift when it goes from low to high. If I leave it on high, I can clock phase 1 and phase 2 of the clock as much as I like but it doesn't move at all. Only when I take NSR0 back down to low and then back to high will it shift again.

If you implement that, does it make a difference? I can't concentrate enough at the moment to work that out.

I was looking at this line in the VICE code:

Code: Select all

if((j != 3) || ((j == 3) && (noise_LFSR & 1))) {

and to me that looks like it is going to be true whenever NSR0 is HIGH. I think it has to change to the positive edge.

I also noticed that the VICE code appears to mix in the noise output regardless of the value of the enable bit. I don't think I've mentioned it before, but the enable bit controls three separate things: One is shown in the logisim diagram for the LFSR, one is shown in the logisim diagram for the 8-bit SR, and the third previously unmentioned one is that it pulls the noise output low just prior to the point that it mixes the 4 voices together. Would this mean that it shouldn't add the noise voice into the mix if not enabled, i.e. skip this?

Code: Select all

snd.accum += snd.ch[j].out;

[lance.ewing]

yes the change in timbre is almost surely due to certain patterns stuck in the SR. The matter is HOW it gets stuck, because on the three sound voices the SR quickly fills with "0" after the voice has been turned off. Instead the SR on the noise voice seems to never gets cleared.

The other three sound voices have the SR shift when the counter times out, whereas the noise voice shifts when the LFSR first bit transitions from low to high. If a normal sound voice is disabled, then the 8-bit SR is still shifting, because the counter is still triggering the shift. But for the noise voice, the LFSR will fill with HIGHs and basically stop shifting the 8-bit SR. Since the trigger bit for the 8-bit SR is NSR0, then that is actually the first bit that starts filling with HIGHs. So the shifting of the 8-bit SR is going to stop either immediately, or on the first timeout of the counter.

[nippur72]

OOOH YESSS!

I haven't checked it rigorously (it's late), but a quick visual inspection shows they are indeed identical!!!

top real VIC-20, bottom FPGA with "edge trigger"

4.png (5.55 KiB) Viewed 6282 times

[nippur72]

and btw, it seems that the edge trigger solves the "timbre" effect as well ! (I will check it more rigorously tomorrow).

This is the VHDL code of the candidate working version:

Code: Select all

        -- noise gen        
        if audio_div_8 then          
          if noise_sg_cnt = "1111111" then
            noise_sg_cnt <= r_noise_freq + "1";
            if noise_LFSR(0) = '1' and noise_LFSR0_old = '0' then					
               noise_sg_sreg <= noise_sg_sreg(6 downto 0) & (not noise_sg_sreg(7) and r_noise_enabled);					
            end if;       
            noise_LFSR0_old <= noise_LFSR(0);				
            noise_LFSR(15 downto 1) <= noise_LFSR(14 downto 0);            
            noise_LFSR(0)           <= ((noise_LFSR(3) xor noise_LFSR(12)) xnor (noise_LFSR(14) xor noise_LFSR(15))) nand r_noise_enabled;                          
          else
            noise_sg_cnt <= noise_sg_cnt + "1";
          end if;          
        end if;
        noise_sg <= noise_sg_sreg(0) and r_noise_enabled;

[lance.ewing]

I haven't checked it rigorously (it's late), but a quick visual inspection shows they are indeed identical!!!

and btw, it seems that the edge trigger solves the "timbre" effect as well ! (I will check it more rigorously tomorrow).

I'm looking forward to seeing the result of the rigorous testing.

[tlr]

Very promising, good work!

Assuming the LFSR becomes all ones when the gate is off the actual noise pattern/timbre should be fully controllable. Not entierly trivial though as getting the right pattern in the SR depends on the sequence in the LFSR combined with toggling the gate bit at the right spots. You'd want a LFSR pattern with sufficient toggles, but not too far from the all ones state to make the setup time reasonable.

[nippur72]

I'm doing some more accurate tests and there is still something not right when turning off and on the noise voice repeatedly.

The code for edge detection I posted previously doesn't work for some reason, so I am currently using the "rising_edge" VHDL keyword:

Code: Select all

  
  process (noise_LFSR(0)) is
  begin  
    if rising_edge(noise_LFSR(0)) then
      noise_sg_sreg <= noise_sg_sreg(6 downto 0) & (not noise_sg_sreg(7) and r_noise_enabled);					
    end if;  
  end process;

(I guess once we get it working we will be able to translate that into C for VICE).

I had to initialize the 8 bit SR ("noise_sg_sreg") to "11111111" at power on, otherwise the values produced are totally off when compared to the real VIC 20. Now I wonder, is it valid to assume the register flip flops are initialized to "1" in the VIC 20? (e.g. some weird effect due to NMOS gates ... I don't know). Or perhaps we have to rethink the whole model negating all its logic...?

With all bits set to "1" the values do match to a certain extent, but occasionally there is a glitch, a bit is skipped and emulation diverge from real VIC. See the picture attached, what happens at approx 13secs after looping off/on the voice.

6.png (11.3 KiB) Viewed 6216 times

My current guess is that there is some edge case when the counters are updated on the next clock cycle instead of the current. Any idea?

[tlr]

The code for edge detection I posted previously doesn't work for some reason, so I am currently using the "rising_edge" VHDL keyword:

Code: Select all

  
  process (noise_LFSR(0)) is
  begin  
    if rising_edge(noise_LFSR(0)) then
      noise_sg_sreg <= noise_sg_sreg(6 downto 0) & (not noise_sg_sreg(7) and r_noise_enabled);					
    end if;  
  end process;

rising_edge() is kind of risky depending on what architecture you synthesize for. Basically a combinatorial signal will get fed into the clk input of a flop. Depending how that gets mapped in the preceeding LUTs you may get glitches while the logic stabilizes, leading to spurious clocks. For Xilinx devices a single LUT should be glitch free though but you mileage may vary.

[lance.ewing]

I had to initialize the 8 bit SR ("noise_sg_sreg") to "11111111" at power on, otherwise the values produced are totally off when compared to the real VIC 20. Now I wonder, is it valid to assume the register flip flops are initialized to "1" in the VIC 20? (e.g. some weird effect due to NMOS gates ... I don't know). Or perhaps we have to rethink the whole model negating all its logic...?

Actually, there is in effect an inverter in between the output from the 8-bit SR and the point that it mixes with the other voices. Would this address this?

I'll explain what actually happens, and maybe when I get time later this weekend, I'll add a few pictures from the die shot. All of the voices have a kind of voltage divider where if the voice is enabled, then the voltage at that point would be 2.5 volts. This is because VDD is 5V and the voltage divider has the two transistors with equal dimensions, so it halves the voltage. I'm not sure what the most appropriate name to call this point in the circuit is, but lets call it VOICE_OUT. This point will be pulled down to 0V if the first bit of the 8-bit SR is HIGH. Otherwise, (assuming the voice is enabled), if the first bit of the 8-bit SR is LOW, then that point in the circuit will stay at 2.5V. This point in each of the four voices then goes through a resistor (what appears to be the same value resistor for each voice) prior to joining with the other voices.

VOICE_OUT for each voice, going through its resistor, and then joining with the other voices, makes up the start of the analog mixer/summer part of the audio circuit.

[nippur72]

there is in effect an inverter in between the output from the 8-bit SR and the point that it mixes with the other voices. Would this address this?

no, because this only has the effect of negating the whole the output waveform (I still have to check the correct polarity, but we can address it later).

My concern is about the initial value the 8 bit SR gets at power up. Is it "0" or "255"? (Or even random? but I don't think because from my tests I always get the same waveform).

So tu sum up, with SR=0 on power up, the first shot of the waveform (e.g. POKE 36877,255) is identical to the real VIC20. But once you turn the voice off and on the two diverge as you can see from the picture below:

The emulated one gets "fragmented" very quickly, the result of isolated "1" or "0" that somewhat gets in the internal pattern of the SR. That can be seen easily by zooming on the second POKE:

8.png (9.24 KiB) Viewed 6160 times

A totally different result is when hypothetically SR is 255 on power up: the two waveforms are "almost" identical (apart from inversion) for a quite long run, but they don't exactly match. They differ for a "bit" that I wasn't able to reconcile. Perhaps it's an initial value somewhere, or perhaps it's the result of shifting one lag too early or too late.

See the picture below, it's from point in the middle some time before divergence. Emulation seems to be one or two bits too early causing different shape at start and end (red arrows). The internal part does match tough.

My guess is that the "lagging bit" causes differences to accumulate and the sequence to diverge quickly at some point.

[tlr]

So tu sum up, with SR=0 on power up, the first shot of the waveform (e.g. POKE 36877,255) is identical to the real VIC20. But once you turn the voice off and on the two diverge as you can see from the picture below:
7.png

The emulated one gets "fragmented" very quickly, the result of isolated "1" or "0" that somewhat gets in the internal pattern of the SR. That can be seen easily by zooming on the second POKE:

Wouldn't this happen if there was an extra "0" clocked into the SR at gate off? Basically it would stick there and wait until a gate on will allow it to get 0-1 toggles from the LFSR again.

[lance.ewing]

So tu sum up, with SR=0 on power up, the first shot of the waveform (e.g. POKE 36877,255) is identical to the real VIC20. But once you turn the voice off and on the two diverge as you can see from the picture below:
...
A totally different result is when hypothetically SR is 255 on power up: the two waveforms are "almost" identical (apart from inversion) for a quite long run...

I'm only a self taught amateur when it comes to these things. Initial power on state as a general topic is something that I haven't thought a lot about. But I can see that there isn't an explicit power on reset circuit in the 6561 for the noise or other voices. Now, given what you've discovered about it appearing to require the 8-bit SR to start in an all HIGHs state, I'm starting to wonder if there is something more subtle going on, perhaps even intentional to some degree.

One question I have is whether you've tried it with start up values other than 0 and 255? Do other values result in yet more different output?

If 255 is the only value that results in the very close to the VIC 20 output that you're seeing, then I'm inclined to think that there is something in the 6561 design that results in all the bits starting in a HIGH state... particularly if you're seeing the same output from the start every time, and that that is dependent on the power on state.

There are a couple of things that I've been wondering about: When you read up a bit on initial "power on" state for something like a flip flop, in the absence of a dedicated reset circuit, you see discussions about race conditions that tend to quickly settle down due to subtle differences between what should be identical transistors and the connections between them. In reality two identical transistors are never purely identical, so even a deliberately designed symmetrical flip flop, symmetrical with regards to its transistors and the connections between them, would still quickly settle into a stable state, where the output of the flip flop is either on or off. I read one post by a guy that built an SR latch on a breadboard from transistors and it always started up in the same state, presumably due to such subtle differences.

Now, what if a die layout was designed with that in mind, i.e. deliberately design-in physical differences that almost guarantee a winner in such race conditions? e.g. design a transistor to have a quicker rise time, or something like that, or design a connection to have more capacitance. That is one thought I had. I've been looking at things from a purely logical/digital perspective, so haven't considered that kind of behaviour.

Perhaps if you've observed that it needs to be in a 255 state, then we can just accept that this is true, despite there not being an explicit power on reset circuit.

The other thought I had was with regards to the logic level in between a pass transistor and the input to an inverter. At power on, surely this point between the two is lacking charge, so is LOW. So if the input to that inverter is LOW, then the output is HIGH. I was wondering if I could deduce an initial startup state based on that kind of logic, by working out the most likely level at certain points and then expand from there.