I fell down a rabbit hole…

[Shadoclaw]

I swear I was sober when I started this. I may have been stoned during it (marijuana is legal here), but that does not make the idea any less cool or insane.

Part the first: I want to port the Sid v2 architecture to mios32. Specifically, to an STM32f103. More specifically, to a so called “Blue Pill”, with a few changes to fit the mad SCIENCE!!! Which has become my design.

I understand the reasons why the SID V2 has not been imported to MIOS32 yet: differences in voltages and logic for one, and the old MIOS8 architecture works well enough that a port may not have been necessary, especially since the SID chips themselves have their own requirements that make porting over the system uncomfortable to say the least. Even swinSIDs have similar issues.

So, for that reason and the prohibitive cost and rarity of said chips, I will not be using them for my design.

I think you know where I am going, but please don’t jump ahead.

No analog, so I don’t need analog pins. I’ll be using a 4*20 iic LCD for the display, which means I can ditch the parallel ports for the display. Instead of CAN, I’ll be using directly connected UART to the audio boards to control the “SIDs”, which means I can ditch the CAN interface. Patch storage will be on a 2 gig SD card, native to MIOS32 and much more efficient and elegant than Bank Sticks.

So in reality, all I need from the core module is 2 UARTs (1 internal, 1 external), DIN, DOUT, and iic.

So the audio boards will be powered by 2 Propellers running SIDCogs.

“It’s just an emulation.”

“The filtering doesn’t sound right.”

Don’t care. I can live with the difference.

Each propeller will be running 4 SIDCogs set to mono output (SIDCogs are stereo now, but not for the purpose I am planning). Each SIDCog will have its own dedicated Mono output, and will be controlled via MIDI from the core module’s internal UART. Each propeller has a dedicated 64k eeprom to hold the code for the SIDCogs and what I am now referring to as the “special sauce” (detailed shortly).

This takes up 8 of the 32 pins on each Propeller, and roughly six out of the eight cogs on each propeller. Unused pins and cogs? SPECIAL SAUCE- the remaining cogs will be set up as iic slaves, allowing the core to access the additional 48 IO pins on the propellers. This is just the planning stage, so I don’t know yet what I will do with the extra pins, but I don’t like waste.

The 8 audio output pins will go through a small discrete circuit to boost it close to line level, then to quarter inch output jacks. From there, the outputs can be routed to a built in 4*8 patch bay, also utilizing 1/4 inch jacks and powered by 2 TL072s or similar low noise dual opamps.

The enclosure will be constructed from wood and two soft steel panels, the most difficult part of which will be drilling all the holes for the LED matrix.

I think I’m ready to be committed now, in more ways than one.

[Shadoclaw]

A quick handdrawn schematic of the blue pill core module. Might be changes later on. Empty pins can be used for gpio and other things.

[Shadoclaw]

Update: iic slave protocol will not work for the props, due to address conflicts with the props internal EEPROM and the preexisting antiquated bank stick system.

Proposed solution: switch the slave system to spi, giving quicker response and essentially turning the empty pins into a glorified dual direction shift register for either DIO OR a DIO MATRIX.

Another handdrawn schematic detailing the prop side, including audio, proposed patch bay, and new spi protocol pinout. Pin assignment may change based on convenience, if the DIO option is used, open pins will have the appropriate resistor pull-ups and such depending on the assignment of the pin in question.

[Shadoclaw]

Another update. It’s a WIP, so that is to be expected.

Ditching the USART connection to the props and only connecting via SPI. Frees up USARTs on the core, frees up pins on the props, and SPI is a more robust and faster data transfer protocol than MIDI.

Sound feasible? T.K.? Wilba?

Stay tuned, more to come. Breadboarding the blue pill and LCD first to confirm communication, and starting to assemble the core module on perfboard.

Fun times indeed.

[Shadoclaw]

I’m having the hardest time programming the Blue Pills.

Amazon sold me a shit ST-LINK dongle with broken pins. Fixed the pins, but the damned thing still wouldn’t work, so trashed it and looked for another solution.

Built and programmed a Picoprobe, which was hilariously easy to program. STM Cube programmer would not recognize it, despite supposedly being in compliance. Ditched STM Cube, went to keil. Keil recognized the picoprobe but refused to flash the bootloader.* so desperate, I used OpenOcd. OpenOcd said that it flashed the chips but could not verify, also it seems to have locked up the chips. Will try unlocking them and reprogramming them in about 30 minutes or so.

In the meanwhile, I developed a low cost board for the prop side, using a propeller P8X32A-DIP40 chip, an external 64k eeprom, and a 10Mhz crystal (I did not have a 5, a 10 will work, just have to adjust the PLL in the firmware). I also moved the audio pins for convenience (the old audio pins were at the top of the chip, P0-3. Moved them down to pins P14-17). I also developed an ESP32 based programmer for the prop.

Pictures? Pictures.

[Shadoclaw]

Found the problem with the blue pills.
TK used a 12Mhz crystal to time his STM32f1 builds. The blue pills are on an 8Mhz crystal.

Erase the flash on the Blue Pills, adjust the PLL to x9, then reflash with the updated bootloader.

Should be a piece of cake. In the meanwhile, I am switching this particular project to an STM32f407vgt.

Fun times