Shadoclaw

Howdy TK, et al, Recently I was gifted with one of these Spark Core at my place of employment. While Particle has discontinued the product in question, and it does have some limitations (see below), I believe that the onboard peripherals could indeed be used to make a functional MIDIBox Sequencer, with some tinkering and bit bending. As I said, there are some limitations compared to the standard Core_STM32 module (Which I also realize has been retired, but is the closest I could find to the infrastucture used by the Spark Core): *128K Flash memory and 20K of SRAM. This pales in comparison to the 512K Flash and 64K of SRAM on the original Core_STM32 Module. I have some SRAM and EEPROM chips on order, I might be able to use those as a workaround for this. *Only 8 DIO pins (D0-D7) and 8 Analog pins (A0-A7) are available onboard. In addition, some of these pins are used for other MIDIBox related purposes: SPI is handled on A2-A5, D0 and D1 are used for the second USART, and D0 and D1 are also used for I2C. Since I do not plan to use Analog sources in my project, I believe I should be able to use DIN and DOUT Modules to overcome this limitation. *There are only 2 Hardware USARTs, one of which (SERIAL2) is used for I2C, which creates a conflict. I might be able to work around this as well, using the IIC Midi Module or some variation thereof. *With the exception of D0-D7, which are 5V Tolerant, all of the other pins are rated at 3.3V. I don't necessarily see this as too much of a problem, as again I do not plan on using any Analog, but it might prove difficult for future designs with this chip. *While the USB port is described as a full speed USB 2.0 interface, I have my doubts. Requires further testing. *VIN is rated at 3.6 to 6.0V. If I choose to use a 9V adaptor, I will have to use a 5V voltage regulator to step down the power before it hits VIN. Or I can just power it from USB. *I'm not sure, but I believe the device may be optimized to use the Arduino IDE, which limits my programming options (I might be able to port over the MIDIBox software over to the Arduino IDE... Will have to experiment with this as well) So, there are some advantages to this uC as well... *STM32F103CB chip clocked at 72Mhz out of the box *Small form factor suitable for plugging into a breadboard or daughterboard *WiFi antenna built in. Will need to experiment with this, but in theory, it may be possible to transmit MIDI data over WiFi, thus giving another virtual MIDI port So, what do you all think? Good ideas, or am I way off base?

Question: Are you using a full Compliment of Bank sticks? The reason I asked is because it is specified in the MBSid manual that the last bank stick (Bank Stick 7, or the eighth bank stick as the first Bankstick is numbered 0) is reserved for Ensembles. Drum kits, unless I miss my guess, would qualify as ensembles. Course, I could be wrong: I'm new to all this, myself. You could possibly use a Bank stick wired to address 7 and bypass the other bank sticks, but you would be cheating yourself on this, in the end. DB

Excellent! I'll start cracking the code then. Basically, the way I see it, it would be essentially the same code as would be used to decode an 74hc165, I think. Basically we convince the Prop that the Data line is itself a pair of parallel in shift registers. The code would then be handled internally. And considering that the Prop spins (Get it? Spins!) at 80 MHz, I should be fine, though I would have to check the Prop Datasheet again (All 400 pages of it). Unfortunately, the code that I just found for it on the object exchange looks like it itself takes up a cog, so the maximum number of Cogs dedicated to Sims would have to be 6, if my math is right. Then again, I wonder, since we are obviously not trying to actually duplicate the actual SID here, if I can just program each cog with 6 oscillators... this would drop the number of cogs (on a fully loaded MBSID) to 4, and still retain the 24 Oscillators that would be available on 8 SIDs... basically, program each cog to emulate 2 SIDs instead of one. I am also looking to bypass the Filtering issues that Nils detected with the SIDcog initially by dedicating pins to filtering- Basically, 2 in and outs which are connected together by caps. Given the theory about the Serial thing, I might just have enough pins to do a set for each SIDcog, too. And considering they just canned me from work, well, I have plenty of free time on my hands... Cheers! DB

Well, Hello TK! Yes, i see the logic in this... So really, with a StereoSID example, given the hardware, one could merely build an extra Chip Select line into the device? And if we were looking at multiple PICs, each would have to have it's own dedicated Data, address, and control lines as well leading into the device? Starting to Grokk this more... I really need to reread the SID datasheet. My other question was this: Since the Data, address and control lines are sharing the same line, divided by the shift registers, would it be possible to consolidate all of these into one pin on the Prop, basically adapting the firmware to decode the Serial signal as it comes in? I know you're not an expert on the device in question, simply wish to know if the theory was sound. I had thought about doing it this way, might experiment with that as well. Cheers! DB

Hi all! Long time reader, first time poster. I know this topic had been laying dead since 2010 (I know, I know, I'm digging up the bones of the dead horse to kick it once again), but I felt I would post on it anyway, given that it is in line with what I am trying to do. First, to Wilba's statement, and I do quote: "Maybe someone can wrap up that SIDcog core into a SID-pin-compatible package like SwinSID. Someone with more time than I have." It is possible, given the nature of the device, to do just that. The problem lays in two directions: 1)VDD- The maximum voltage you can put on a Propeller's pins is 3.3v. This means that VDD has to be dropped down to that level: Not a problem for new designs, but as a direct replacement, one would have to figure out how to compensate for the Sid's original dual voltage design (In other words, don't try to plug it into your C64). Also, because the pins are only tolerant to 3.3v, any input from other devices has to be dropped down in order to keep from frying the device (I'm thinking pulldown resistors at this point). The good news is, no more dealing with Dual power supplies: the power dropdown for the MBSID applications can be dropped down at the chip using a 3.3 Voltage regulator to supply the supply voltage to the chip. 2) The Propeller is a 40 pin device, 32 of those pins are assignable. Given a Stereo output and a mono input, that leaves 29 pins to play with. Doing the math for a basic 1 SID application, one would need 16 of those 29 pins to interface with the core module on a MIDIbox Sid device: 1 Reset, 1 clock, 1 CS, 5 Address Pins, and 8 Data pins (Do I have that right? I'm going off memory): VDD and Ground are not a part of those assignable pins. This leaves 13 pins to play around with. Oh, and the SIDCog, as per it's name, only runs in one of the Cogs (Prop 32 bit cores are called Cogs, for those not in the know) on the device: The Prop has 8. So what I am thinking, and what I am planning to test once I have the firmware settled to that point, is using the prop to simulate a full compliment of 8 SIDs controlled by 4 Core Modules. Why? Because I'm a bit of a mad scientist, And the old lady is not gonna let me buy a full compliment of SIDs on Ebay for $200 US, especially when I can build a very decent simulation of those chips for around $10. Oh, and because it makes me feel like I'm playing GAWD!!! That was meladramatic... Anyway, I am hoping to compile and test the Firmware for the 8Sid Simulator tonight. I had read on the SwinSID topic that the MultiSID application can control the 2 virtual SIDS in the SwinSID via two additional address lines set to Binary on the SwinSID, is this accurate TK? And if so, would the same apply to this project, basically adding 4 additional address lines to address the SIDS Individually, in groups, or all at the same time using common Data lines? If so, this could be a great boon to the project, as I would only have to assign 1 pin on the Prop for each additional core. Looking forward to hearing from you all, and thanks!