Understanding the SID

[BigEd]

aah, I've no idea. I suppose you could try a Google book search, in case some textbook happens to cover these cases.

[ttlworks]

Back in 2016, when trying to draw a schematic for the SID envelope DAC counter control, to me the results somehow looked odd.
viewtopic.php?f=8&t=4150&start=90&sid=6 ... 0ec#p47184

After gaining some "mental distance" from this adventure, I eventually found the time to dig into that part of the silicon again.

;---

First, a polygon picture with some parts not related to the circuitry to be dissected deleted:

;---

Now for what I think that's supposed the equivalent of the circuitry drawn with switches and pullup resistors.

clk1 actually means sid_clk1, same thing for clk2 and sid_clk2.

Switches and resistors are placed in the schematic similar as they are placed in the silicon
Ignore that odd numbering convention, it's just that the chip layout is dense and a bit hard to follow,
so numbering the switches really is helpful for cleaning up the circuitry.

[ttlworks]

Looks like my schematic from 2016 is wrong... don't know if my schematic from 2017 is right.

[ttlworks]

Just a little attempt for translating the envelope circuitry to sort of a TTL equivalent,
sorry for the bad quality of the pictures.

I'm sure, this stuff contains quite some errors, and probably a few of the flipflops could be optimized away.

[Gigillo]

ttlworks wrote:

Just a little attempt for translating the envelope circuitry to sort of a TTL equivalent,
sorry for the bad quality of the pictures.
I'm sure, this stuff contains quite some errors, and probably a few of the flipflops could be optimized away.

Hi ttlworks, i like your idea very much. I would like to build a SID wid TTL/CMOS discrete IC.
I use Eagle CAD for my project and if you can help me i can build SID schematic and PCB with CAD.
Waiting for your help,
Luigi.

[ttlworks]

Hi Luigi,
Sorry for the delay, was on vacation and away from internet.

Just to be fair, I have to say this won't be a small project:
implementing the envelope generators and especially the filter won't be easy.

Would like trying to help you a bit, PM sent,
for this project we better start a new thread in the hardware section of the forum.

;---

Edit: August 21, 2018.
More than 4 months have passed by, and to me it looks like Luigi has lost interest.

Again: building a TTL implementation of the SID won't be a small project,
and when trying to do it "right" this probably could take 3 years+.

So when starting it, you better be serious about "getting the job done".

[d3bug]

I found something interesting that could help in a non-destructive way to reconstruct the SID (if anyone has the $ and inclination)...
[PDF Warning] Computed Laminography for X-ray Inspection of Lightweight Constructions

[ttlworks]

Hi d3bug, and welcome to the forum.

In theory yes, but the hardware required for X-ray scanning 2 micrometer sized chip structures this way probably would cost more than a new car,
and one would need to have some in_depth knowledge of mechanical construction and machine engineering for building a scanner working at a reasonable precision.
Turning the sensor data into distortion free vectorized images won't be trivial, especially when it comes to manually routed chip layouts.

We had dissected all of the SID circuitry so far, but two mysteries are remaining:
We don't have transfer curves for the FETs in side the chip, so the parameters for the analog part of the SID are "guesswork",
and one month of staring at the microscopic silicon pictures didn't answer the question why the LFSR Bits are flipping from 0 to 1 after a while.

It's questionable if X-raying the SID would bring us far there, but X-raying chips that are no 'mixed signal designs' "in theory" might be interesting.

[BigEd]

Indeed welcome! There are techniques of lapping which can similarly recover the geometry. But the most labour-intensive step is always the creation of the equivalent polygons - what would have been the original mask data - and debugging any opens or shorts or misconnections.

[ttlworks]

Nowaday, designers seem to use fancy CAD tools for "cobbling together" a set of "standard cells".

But old MOS\CSG chips (like used in the C64) are manually routed, the designers sure had pulled every dirty trick there is for making the design as compact as possible.
From what I have heard, automated software has problems with generating polygonized images out of something not made from "standard cells",
so the usual approach is to take a microscopic chip picture, then to _manually_ draw the polygonized picture from it by using Inkscape or such...
...for maybe more than 3000 transistors, what sure takes some time (maybe more than 3 months per chip). For more details, see here.

The other thing is, that MOS\CSG seemed to know the one or other thing about the chip manufacturing process (while tinkering with it),
and that knowledge went lost. The blue prints and the original mask data for the chips went lost, too. The old MOS\CSG factory building had an 'existence failure'.
After more than 37 years, the original designers of the chips probably can't remember anymore what they did, and why.

Really, trying to reverse engineer old MOS\CSG chips is a fascinating/entertaining hobby.
Unfortunately, destructive/non_destructive "scanning" of the chip silicon only is one step of a labour intensive process.

Looking forward to seeing somebody building an inexpensive X-ray chip scanner, good luck.

Edit:
The X-ray micro-CT scanner project on HaD might be a nice starting point.
When tinkering with X-rays, please don't forget to have an adequate shielding.

[fhw72]

ttlworks wrote:

...
From what I have heard, automated software has problems with generating polygonized images out of something not made from "standard cells",
so the usual approach is to take a microscopic chip picture, then to _manually_ draw the polygonized picture from it by using Inkscape or such...
...for maybe more than 3000 transistors, what sure takes some time (maybe more than 3 months per chip)

Good guess! That's approx. the time it took me to polygonize the MOS6509! (Maybe it was a bit less... but not much).

[ttlworks]

fhw72 wrote:

Good guess! That's approx. the time it took me to polygonize the MOS6509! (Maybe it was a bit less... but not much).

I know.

...plus maybe another three months for making sense and/or partial schematics of the polygonized images (if you know what you are doing),
if the chip doesn't happen to be too complex... like a CPU or such.

Extracting the transistor netlist from the polygonized images by automated software tools for running a simulation might be possible... someday...,
(at least for chips which are not 'mixed signal designs' containing digital plus analog functionality like the SID,)
but that won't be too helpful for trying to figure out how the chip actually works "as a whole" in all of the little details.
You need to understand what's inside the chip by making use of your own brain... and this might involve paper, pencil, and a lot of spare time.

LFSR based counters, FET switches creatively making use of trace capacitances for implementing transparent latches, and so on.

[ttlworks]

Since Drass is away for a while, I have tried to "translate" some of the results of our SID dissection into sort of a conceptual TTL schematic.

Pre_Farnell Eagle 6.4, because I happen to have the full version and I'm used to it (as in "drawing goes faster this way").

SID_8580_TTL_ConceptualSchematics.zip

(277.27 KiB) Downloaded 252 times

Edit: sid_main.sch, page 7:
Looks like something went wrong with the notation of the signal names: A0..A4, should be _A0.._A4, sorry.
Anyhow, it's only a "test balloon".

;---

Decided to aim for the 8580, because I lack some info for implementing the 6581 filter.
Nevertheless, resistor values in the waveform selectors are like in the 6581, take care.
Schematics are _not_ verified, and I shouldn't try to do a verification because I'm too deep into these schematics.
Would be better to check if 'PHI11' and 'PHI22' are assigned correctly to the circuitry.
Schematics might contain some errors, and I wouldn't trust the envelope control circuitry too much.
Really, you better question/doubt anything in the schematics. Take them with a grain of salt.

Couldn't resist "to try making the bus interface 20MHz", because we have that 20MHz TTL CPU.
Of course, the oscillator\envelope logic probably won't be able to go faster than 2MHz,
running the design with two phase_synchronous PHI2 clocks (registers 20MHz, oscillator\envelope 1MHz)
might create some _other_ problems...
...also, because there probably won't be enough PCB space for even thinking about double buffering the control registers.

It's going to be a stack of four PCBs:
Three identical PCBs for the voices (oscillator + envelope + the related DACs), //3* 105 ICs
One PCB containing the bus interface, the filter and the rest. //1* 56 ICs

Since the schematics are not verified, it doesn't make sense to spend any thoughts yet on if/how that stuff might be going to fit on the PCBs,
371 ICs in total, have fun.

;---

Bus interface, with the wrong sort of connectors of course:

One voice, three such PCBs required. //Note the massive use of BAS40-05 and BAS40-06 Schottky diodes.

It's a beauty... at least to fans of Boris Karloff.

;---

Edit:
After some tinkering with the 'voice' schematics and PCB layout, I would dare to say that there is no way to squeeze this into a 160mm * 100mm form factor.
I'm sorry to say this... but maybe we should spend some thoughts about an alternative concept.

[mathop]

Bit late to the party.
I don't think anyone mentioned here yet why the noise LFSR magically turns to all-1s when you keep the test bit set.

Each bit in the noise LFSR has three pass transisors, LC (copying the nomenclature that was already used here), that is used to shift in the neighboring bit, and c1 and c2, used to refresh the register.
When the test bit is set, LC is ON and c1 and c2 are OFF.
That means that the contents of the bits won't be refreshed, so the bits of poly that come off c1 gradually lose charge, and the inverter connected to it will become 1 after some time.

[sharptrickster]

ttlworks wrote:

Before we take a look at the filter section, some words about the amplifiers.

The designers were not able to implement real OpAmps,
so the amplifiers in the 6581 are self_centering inverters.

I'm sorry to bother, but I'm trying to simulate this "opamps" and the VCF on LTSPice, and failing to do so.
I gather 69/27, 18/74 and 18/42 are W/L parameters, is that right?
Any advice on how to set NMOS parameters here?
Currently the OPA does not even reach unity gain with 1 meg resistors on input and feedback, 330K (as in the filter schematic) makes thing even worse, because without unity gain on a state variable the other taps wont generate bandpass and highpass correctly as well.

Thanks!