It is possible that one or more of the data lines to the SID are not working properly… so that most of the time things are working but you are noticing incorrect frequencies being written to the SID’s data registers.
to make sure the tracks between the 74HC595 and the SID are working correctly.
See the README.txt file inside the zip for instructions.
Check also there are no shorts between the pins on the SID sockets, and the 74HC595 below the SIDs.
Let’s say there was a short, then in the case that both pins are outputting the same value (0V or 5V) then you wouldn’t notice it, but when they are outputting different values, then they’d both be 0V, I’m guessing. Or could be something else depending on stuff I don’t know about electronics (which is a lot). Either way, it might make some bit patterns still work fine, like most note frequencies in a given note range, and then be totally wrong all the time for some other note range.
You might want to test this theory by setting the pitch bend range to something large, and then hold a note down and do some pitch bending… if you hear jumps in the pitch instead of a smooth glide, then the problem is definitely between the PIC/74HC595 and the SID and (most likely) nothing to do with the firmware or MIDI events being interpreted wrong, etc.
You might want to test this theory by setting the pitch bend range to something large, and then hold a note down and do some pitch bending… if you hear jumps in the pitch instead of a smooth glide, then the problem is definitely between the PIC/74HC595 and the SID and (most likely) nothing to do with the firmware or MIDI events being interpreted wrong, etc.
Thats exactly what happens! I got jumps on the above mentioned notes (A2, G3, A3)
Awesome! I’ll reply to the questions for completeness…
But would this not also affect other registers?
Yes, but it might not be affecting the ones that count, or are audible. i.e. filter cutoff frequency might also be wrong, but you wouldn’t notice unless you were doing slow filter sweeps.
Note also that the frequency is sent in two bytes, so both bytes of the register would be wrong, but you wouldn’t have heard much difference in the low bits, and probably half the time, it wasn’t wrong (i.e. it was a zero bit anyway).
Yes, but I think TK recalculated this table using the formula in the datasheet, as there are some rounding errors in the table, so what is in the firmware is not identical to the table.
I found out there is a correlation between the failing notes and the 11th databit!!!
hehehe I was going to check if there was, but it was late and finding a short would have proved the theory right a lot quicker.
Can I ask if you used the interconnection test to discover the short to ground, or just tested each pin with a multimeter to find out what was wrong?
Yes, but I think TK recalculated this table using the formula in the datasheet, as there are some rounding errors in the table, so what is in the firmware is not identical to the table.
<klugscheisser>Yes, but no? Wilba’s right as usual, they’re not identical. The table in the datasheet is off.</klugscheisser>
Yes, but it might not be affecting the ones that count, or are audible. i.e. filter cutoff frequency might also be wrong, but you wouldn’t notice unless you were doing slow filter sweeps.
Now i notice! Some presets sound different and even the startup sound was not audible before -
But when you don’t know how they should sound than you think: okay - not so nice preset
The tuning error for the 3rd bit in the low byte was apparently to small to notice.
Can I ask if you used the interconnection test to discover the short to ground, or just tested each pin with a multimeter to find out what was wrong?
No - was to lazy Just had a look on the SID spec to narrow the search area, played some notes and than it was obvious. (especially when having a look on the completely failing octave)
At least the highbyte values are the same as in the table.