6561 Die Shot Reversing Explorations

[lance.ewing]

i_in_matrix: Is the inverse of the in_matrix signal and is used to enable the Horizontal Cell Counter and Video Matrix Counter.
i_mtrx_line: Is the inverse of the matrix_line signal and is used as part of the logic to enable the Cell Depth Counter.
bus_avail: Goes LOW about a cycle before the i_in_matrix signal goes LOW. It goes pretty much directly to the driver logic for the unused Bus Available bonding pad. This signal isn't used internally by the chip (or externally since the bonding pad is not connected to a pin).

I was taking a closer look at the timing of this last night. As far as I can tell, there are 6 full cycles between the SX compare value going HIGH (i.e. when the Screen Origin X value matches the Horizontal Counter) and Border pixels no longer being output on the left hand border (i.e. because it then starts outputting the text window pixels).

* There is one cycle between SX Compare going HIGH and it entering the "In Matrix" (i.e. in text window) calculation.
* There is one cycle between this and when the Bus Available line changes.
* There is one cycle between that and when the "In Matrix" signal (i_in_matrix) changes to enable the Video Matrix Counter and Horizontal Cell Counter.
* There is one cycle between that and when the Address Ouput Enable goes HIGH (there is therefore two cycles between when Bus Available changes and the 6561 outputs an address).
* There is then one cycle where the 6561 is getting the cell index.
* There is then another cycle where the 6561 is getting the character data.

It's at that point that the border turns off and we get the pixels from the pixel shift register being output.

So by the time the text window pixels start being output, the Horizontal Counter will have incremented a further 6 times since the Screen Origin X value matched it.

[Jogi]

Hi,

New Info Die Shot 6560-101 and 6561-101

http://vic20.de/html/vic_6560-6561.html

Best regards Jogi

[lance.ewing]

Wow! Thanks for these images of the 6560-101 and 6561-101. As you can imagine, I've been waiting eagerly for these since I first heard the work was being done. They will no doubt keep the community happy for many years. I'm keen to identify all the differences between the three versions now. I won't have a lot of time over the coming weeks though, as I've booked a lot of travel, but I'll certainly be right into looking at this when things settle down. Thanks again.

[nippur72]

the noise generator as discovered by Lance is now implemented in VICE:

Code: Select all

status: pending --> closed-fixed
Version: general --> v3.x
Port: -->
Category: new feature (VIC20) -->
[bugs:#1125] 6561 noise generator has been reverse engineered
Status: closed-fixed
Version: v3.x

[nippur72]

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.

Does this align with what people have observed?

Lance, are you sure about the speed of CR-D? The new sound generator has been implemented in VICE 3.3 and the resulting noise is one octave higher than a real VIC-20. This might suggest that CR-D and CR-C share the same clock divider. Or perhaps CR-D is halved down somewhere when mixed with the LFSR... what do you think about?

[lance.ewing]

Lance, are you sure about the speed of CR-D? The new sound generator has been implemented in VICE 3.3 and the resulting noise is one octave higher than a real VIC-20. This might suggest that CR-D and CR-C share the same clock divider. Or perhaps CR-D is halved down somewhere when mixed with the LFSR... what do you think about?

I am fairly sure that CR-C and CR-D take different outputs from the sound clock divider circuit. I've just checked the outputs again and they're not from the same point. I would have to check the whole thing over again to be sure that those two outputs have a different rate. The way it is laid out though, it wouldn't make a lot of sense for them to be the same. The circuit that I reversed by hand from the clock divider section, and that I then simulated in logisim (the diagram as shown in an earlier post), does have the CR-C output at half the rate of the CR-D. So I'm currently leaning towards there being something else that halves it again within the noise specific section. I haven't found it yet though, but there must be something that does it.

[nippur72]

ok, thank you for checking and glad to read you again!

There is another little but crucial detail I would like you to check on the die shot. It seems to me the 8-bit shift register on the noise voice behaves differently respect to the ones on the three sound voices. According to my hypothesis such register is not cleared when the voice is "off" as it does on CR-A, CR-B, CR-C, but it runs free (ROLs) without inverting the feedback bit.

My hypothesis implies a change in a logic gate, instead of AND, there's an XOR. In pseudo C-code:

Code: Select all

unsigned char SR; // the 8 bit shift register
unsigned char enable = peek(36877) >> 7;
unsigned char bit7 = (SR >> 7) & 1;

// actual (but wrong)
// unsigned char feedback = ~bit7 & enable;  

// my hypothesis 
unsigned char feedback = bit7 ^ enable;  

SR = (SR << 1) | feedback ; 

This models justifies the change in timbre on the noise voice when you repeatedly turn it off and on, and it's also what I've found experimentally (at least it seems so). But of course that has to be confirmed on the die shot.

I will write a longer post with all my findings, I'm sampling from a real VIC-20 comparing it to emulation.

[lance.ewing]

ok, thank you for checking and glad to read you again!

Mid-July to mid-September is often an offline period for me, due to a mixture of weeks of holiday, and participating in an annual JS game programming contest.

There is another little but crucial detail I would like you to check on the die shot. It seems to me the 8-bit shift register on the noise voice behaves differently respect to the ones on the three sound voices. According to my hypothesis such register is not cleared when the voice is "off" as it does on CR-A, CR-B, CR-C, but it runs free (ROLs) without inverting the feedback bit.

My hypothesis implies a change in a logic gate, instead of AND, there's an XOR.

Interesting. I will take a closer look at that part and see if it matches. One thing I haven't done yet is to reverse the 8-bit shift register of CR-A, CR-B, and CR-C. I might start by doing one of those, so I can compare the two designs and spot the differences.

[nippur72]

I'm afraid there is another glitch somewhere in our model.

I sampled a POKE 36877,255 and performed auto-correlation of a small slice over the whole recording.

On a real VIC-20 the waveform loops every ~15.2 seconds.

On our simulated model (FPGA):
- with CR-D speeding same as CR-C, the pitch is correct but it loops every ~30.4 seconds (twice as a real VIC-20)
- with CR-D speeding twice as fast as CR-C, it loops correctly every ~15.2 seconds, but pitch definitely isn't right

Also, none of the emulated waveforms do match the real VIC20 via correlation analysis.

My only guess is that the 16-bit LFSR and the 8-bit SR somewhat are running at different speeds... but I don't know how. Or perhaps it's just the LFSR that is 15 bits instead of 16, thus looping in half the time?

[lance.ewing]

It seems to me the 8-bit shift register on the noise voice behaves differently respect to the ones on the three sound voices. According to my hypothesis such register is not cleared when the voice is "off" as it does on CR-A, CR-B, CR-C, but it runs free (ROLs) without inverting the feedback bit.

Edit: Sorry, Ignore the below post/question. I've re-run the simulation of the 8-bit SR now and can see what you mean. The simulation does clear the SR when the voice is disabled, but it does so after 8 more shifts of the shift register. I am assuming this is what you meant.


Can I clarify something about the above bit I've quoted? I wanted to see if I understand what you are saying. If you read the following post:

http://sleepingelephant.com/ipw-web/bul ... 10#p104357

...I think it does show that in isolation the SR would continue to shift when the voice is "off". Disabling the noise voice doesn't in itself stop the shifting. I did some playing around with that in the logisim simulation, as mentioned in this bit of the post:

So during normal operation, we'd see 8 HIGH levels shift through the shift register, followed by 8 LOW values, and then 8 HIGH values, etc. But as has been observed in the past, if the noise voice enable bit is turned on and off, it is possible to change this pattern of HIGHs and LOWS. I was able to, for example, set up a pattern of HIGH, LOW, HIGH, LOW, HIGH, LOW, HIGH, LOW across the 8 bits by simulating this voice enable switching in Logisim.

I haven't tried the simulation today, but if I trust what I wrote and drew 5 months ago, then I think that the inverting does not happen when the voice is off. This is how I was able to set up that pattern across the SR, which normally wouldn't be possible. In my simulation, I was manually triggering the shift, whereas in reality the first bit of the LFSR controls that. So perhaps now I have to look back at the LFSR shifting logic to see how long after the voice is disabled does it continue to shift the 8-bit SR from NSR0.

I found this bit in one of my posts on the LFSR, which I think will be relevant:

The LFSR shifts whenever the CNT_RELOAD signal goes HIGH. Shifting doesn't appear to be affected by the noise voice enable bit. Obviously though the feedback logic is affected by the noise voice enable bit. So when the noise voice is disabled, it continues shifting and shifts HIGH in at the top. After 16 counter reloads, every bit will be HIGH. It will continue to shift after this, but obviously shifting HIGH into something that already has HIGH in every bit isn't going to make a difference at that point.

Edit: Sorry, Ignore the above post/question. I've re-run the simulation of the 8-bit SR now and can see what you mean. The simulation does clear the SR when the voice is disabled, but it does so after 8 more shifts of the shift register. I am assuming this is what you meant.

(mod: link repaired)

[lance.ewing]

I'm afraid there is another glitch somewhere in our model.

I sampled a POKE 36877,255 and performed auto-correlation of a small slice over the whole recording.

On a real VIC-20 the waveform loops every ~15.2 seconds.

On our simulated model (FPGA):
- with CR-D speeding same as CR-C, the pitch is correct but it loops every ~30.4 seconds (twice as a real VIC-20)
- with CR-D speeding twice as fast as CR-C, it loops correctly every ~15.2 seconds, but pitch definitely isn't right

Also, none of the emulated waveforms do match the real VIC20 via correlation analysis.

My only guess is that the 16-bit LFSR and the 8-bit SR somewhat are running at different speeds... but I don't know how. Or perhaps it's just the LFSR that is 15 bits instead of 16, thus looping in half the time?

The LFSR is definitely 16-bits. I've just had a look and can see the 16 cells. So given what you've said above, if it correctly loops when CR-D is twice as fast as CR-C, then its starting to feel like we were right about it being twice as fast; well at least up to the point of the LFSR. But if the pitch is wrong, then could it be something after the LFSR that is causing that? I guess I'm mainly asking myself that question out loud.

[nippur72]

Regarding on the 8-bit SR: I can definitely see it behaves differently from the other voices. On the three sound voices you can turn them off and on and always get the same waveform:

two different slices of 36876,255 compared:

1.png (4.91 KiB) Viewed 3995 times

But if you do the same on 36877 you don't (always) get the same waveform.

2.png (7.43 KiB) Viewed 3995 times

And when you randomly get the same waveforms, it's because by chance you are turning on the voice exactly when the 8bitSR is all full (255) or all empty (0).


Furthermore, I can deduce the 16 bit LFSR is self-clearing correctly as you described because if you power on the VIC20 and type POKE36877,255 you always get the same waveform, no matter how much you delay in typing the command:

two different power ups/POKE36878,15:POKE 36877,255

But if you do not power off (e.g. run/stop+restore) or even power off+on too quickly (flip flops not erased) you do not get the same waveform, suggesting the 8bitSR doesn't clear at all.

Also, by looking at the waveform generated by the prolonged power off+on I can deduce that the 8bitSR gets 0 or 255 as initial value.

[lance.ewing]

What do those same three graphs look like for your FPGA implementation?

I've tried looking for a difference in the part of the 8-bit SR that rols back to the first bit, but to me they look the same when comparing noise vs non-noise.

[nippur72]

The FPGA and VICE emulation are the same (DC drift apart) but they are different from the real VIC-20:

from top: real VIC-20, VICE emu, FPGA

In a desperate attempt to understand what's going on, I analyzed the distribution of the wavelengths of each pulse of the random waveform:

- blue is the real VIC-20
- orange is emulation at speed like CR-C
- gray is emulation at speed twice fast as CR-C

Notice how the orange plot misses half the "buckets", while gray and blue do fill the same buckets but gray has predominance of the shorter wavelengths resulting higher in pitch.

[lance.ewing]

So looking back at your last few posts, are we saying that it appears that the LFSR is shifting at the correct speed when the CR-D increment speed is twice CR-C's increment speed, but the 8-bit SR is then shifting twice the speed it should? Interesting. I will have to take a close look at the connection between the LFSR and 8-bit SR to see if perhaps its every two pulses from the LFSR that cause a shift by 1 of the 8-bit SR. Would that match what you're seeing?

I may not have simulated the two connected yet. I will give that a go tonight.