Features:

Stereo or Dual sid possible.
Dual pin pwm, 5bit+5bit for 10bit with less r/c filtering.
X/Y paddle adc.

Midi in/out, uses $d41d and $d41e

wildcard at $d41f, like small program download/firmware upload.
and for permanent settings.

Pad 5 and C(with analog) can be used for diy stuff,
like a wire for dual sid or a wire to Restore key that if you hold it down for 2sec it will pull C64 Reset low etc.

I will send a way for 3 pcb proto today, should have something built in 2 weeks,
then later I will start selling them at $29, software probably will be a group project.

Maybe you have a good sid and still want to use it,
stack it, as I edited it so it now got through holes.

But what to do about the Capacitor that is on the audio out on stsid-r/c ?,
it will filter the original sid's audio-out a little probably
Put a 220ohm series resistor on stsid as to isolate the cap a little?

I plan to use 740ohm & 0.01uf for a cut off freq of 21'518 Hz

Should I put a 1K pull-down on audio-in, as I plan to use that pin as
audio2-out, starting running out of space even for a 0603.

Wow, that looks neat, What kind of emulation is this using? Looking forward to hear more about his and sample audio if possible.

I am always interested in new SID projects.

Def like to test one !!!

You should look into have an open api, so the chip can be controlled from the C64. Look into ARMSID or FPGASid.

/Michael

Sent to Oshpark (in USA) so now wait a week, first class mail from Oregon to Florida is super fast, normally takes 2days, so I should have it in 8-10 days.

Stats:
MCU 16Mhz STM8S003K3T
8K flash, 1K ram, 128bytes eeprom.

This 8bit mcu have many of the features of 16/32bit mcu.
20bit address space so no page flipping 256byte blocks.

32bit opcode, but similar to 6502 simplicity so I think writing software in
assembler for speed and time determinized.


PWM audio:
Though 16bit is possible, even at 16MHz a period would be 256Hz lol

10bit would be 16KHz period, reasonable but rms hum or freq cut-off in the r/c filter.

8bit a very good 65KHz period, but resolution is... 8bit

So 9bit:
Doubles the resolution but use a gpio as highbit to the resistor adder,
and 8bit pmw for the lower bits.

Or could do 6bit pwm + 6bit pwm as highbit gpio can also be on the same timer as compare2.

This timer only have 3 compares, so stereo would only be 9bit on one of the channels.

This mcu have another timer with 4 channels, but due to pin layout trying to be so data and address lines up on ports in a continues order, I did not try this at this reversion.

Looks really promising! Hope it works out for you. Nothing wrong at all with having another SID alternative available.

Has there been any update as of now for this project? I'm interested in getting a pair.

Nice to see someone else programming in assembly!

I love the midi option, seems like a very smart thing to do

Are you going to implement the midi straight to SID parameters ? Or will you keep it to the software side of things on the C64 as to how it's arranged? Or both?

It looks like it's just a pass-thru -- I am assuming the chip shoves the incoming MIDI packets into a ring-buffer. Reading from the specified address reads it, one byte at a time (been there, done that). The logic to decode the MIDI packets (decoding channel information, process MIDI commands, SysEx messages et cetera) still needs to be done by a C64 program. (I am incidentally working on a project that decodes MIDI on a MCU, delivering updates to SID I/O space only, so no heavy lifting is required on the C64 itself other than just copying values over.)

I hope the MIDI buffers have an adequate size -- MIDI is not the most compact protocol, too small a buffer and it gets overflowed real fast.

Edited to add I also suspect that having just a single byte for MIDI in may not be enough. Imagine $F7 is on it, and it gets read by a program. If no new data has come in yet, how is the program going to know when there is new valid data in the buffer? It cannot assume that by reading $00 there is no data, because $00 could be a valid MIDI data payload...

So it is probably a good idea to reserve an extra byte for MIDI in/out status flags (bit 0 = input buffer has data, bit 1 = output buffer full, and more bits for other status information).

Yes just having 0x00 or 0xFE for midi buffer empty is probably not going to work.
So all reads will start with a 1byte header, or use the IRQ out hocked up to a CIA.

But one problem I could see is that the 16MHz mcu is not fast enough to reply back on address reads as the 6510 expect data-bus to be set in ~100ns (I guess)

I guess most sid tunes don't do read-n-modify on registers? just plan write?
Though I could see programs do reads on random generator register.

i'd try to get some sid emulation running before even thinking about midi details

Any news on this?

I am also interested in helping to test.