Hello Mike:
The reason to don't have a Propeller as a parameter in that method, is because in the new version it is included in the Base class, so if you needed inside PresentChip(), you just call it as
Chip
.
I want to ask you to post the questions about the GEAR plugins in http://forums.parallax.com/showthread.php/156347-Improved-GEAR-Emulator, to be respectful with the thread about SIDCog.
To clarify better how to use the new plugin system, I could post there a template for the plugins.
The dumping process, closed source and windowsness of the SID dumper drove me crazy, specially with respect to using Propeller HAT as a SID-chip companion to the Pi.
I hacked up siddump into a utility that could stream the registers right out of a SID file and over the UART. By extension it could also be easily modified to dump them by just tweaking the console output and piping the result to a file.
It's a wip, but is presently quite usable if you're willing to tweak a couple of values in code:
I'm thinking of using this in my homebrew build, which is based on an actual 65C02. To that end, I have a couple of questions:
Does the SIDcog implement all the SID registers or just the write-only ones? (This is mainly out of curiosity, I don't think I need the other ones)
If I want to use this with an external processor, would I have to write a cog to adapt the processor's bus to the SIDcog?
What sort of maximum speed do you think I could expect to run an external 6502 at? (I think I can get around this with a little external hardware and a bit of code in an adaptor cog, though, so it's not a problem if I can't sit this directly on an 8-10MHz 6502-style bus)
If you are clocking the 6502 externally from the prop...
An 8 to 10 Mhz 6502 is fast relative to a propeller participating on the bus directly. Pretty sure this is too fast.
You would have to write a COG either way. This has been done, which is a very nice leg up.
I never looked at the register implementation. SIDCOG can play C64 data dumps. That suggests the registers are there. Or at least what you need to present them to the 6502 to do sound is there.
You could slow the bus when talking to (ugly, IMHO), or buffer the data to match up to a propeller. (Sweet)
Propellers participate on a 6502 style bus just fine, but due to number of pins, it's common to use latch, buffer chips and signals to allow the prop to prepare the necessary signals in multiple steps. Sidcog does not need many pins for output. You should be able to talk to the bus by latch buffering an address, then data.
Done that way, you could leave your bus at speed and just expect some time to pass before a transfer operation completes.
If you do that, you get a couple Mhz I/O throughput maybe 3? If you exchange data too quickly, some is lost and or duplicated. But!
This is more than enough. A real SID clocked at 1mhz. Having 3 would mean getting more out of the emulation, if you want to.
On your 6502, just make a bit of code with delay time baked in, and call for reads and writes. A music player could also run just fine on an interrupt.
Maybe include a configurable and maskable interrupt signal from the prop. You could optionally have the Prop signal for transfers, if you want peak rate.
If you have a 6522 (ideally a faster workalike), those have timers and an interrupt signal as well. Set one of those up for 1mhz, and you would have a nice basis for playing existing Sid tunes. Or, if you want interrupts free, and or not complicated by multiple things needing the two available, you can just poll a timer and likely run sound with another short task using the interrupt, say a mouse or other I/O device.
Or!
If you have the Prop clock the 6502, about 3Mhz is possible, and it's been done, there are circuits out there you can build on and from. I'm pretty sure the 3mhz ish figure is based on an 80Mhz prop. They clock to 96Mhz reliably with a 6Mhz xtal. Those can be hard to source. Parallax has them. Bill Henning did a run a long while back. He will have them too.
If you have the Prop clock the 6502, about 3Mhz is possible, and it's been done, there are circuits out there you can build on and from. I'm pretty sure the 3mhz ish figure is based on an 80Mhz prop. They clock to 96Mhz reliably with a 6Mhz xtal. Those can be hard to source. Parallax has them. Bill Henning did a run a long while back. He will have them too.
I'm thinking of using this in my homebrew build, which is based on an actual 65C02. To that end, I have a couple of questions:
Does the SIDcog implement all the SID registers or just the write-only ones? (This is mainly out of curiosity, I don't think I need the other ones)
If I want to use this with an external processor, would I have to write a cog to adapt the processor's bus to the SIDcog?
What sort of maximum speed do you think I could expect to run an external 6502 at? (I think I can get around this with a little external hardware and a bit of code in an adaptor cog, though, so it's not a problem if I can't sit this directly on an 8-10MHz 6502-style bus)
Sorry for the necro.
No, the read-only registers POTX/POTY/OSC3/ENV3 are not implemented.
Unfortunately, to get the cycles needed to write back to HUB it was necessary to permanently disable oscillator 3 output (which saved one multiplication), while still keeping it's envelope and phase-accumulator/waveshaper running just to get the modulator values.
However, I'm quite confident that if you clock the propeller with a 6MHz or 6.25MHz crystal, and keep the SID samplerate at 31250, there should be enough spare cycles to implement that modification *AND* switchable OSC3 audio output as in the original chip.
Given that there's no reads to worry about, I can probably get away without wait-stating the 6502. I'm thinking of setting up a "data taken" output on the prop. The props CS would be controlled by a latch set by the external register's CS, and reset by the DTKN signal, which would also be broken out to at least one memory location for polling purposes(one dedicated, or the whole SIDcog address space in read mode). I have the idea that I should build some kind of interrupt capability into it, but I'll have to think on how to do that.
This'll be a bit of a hybrid/mongrel bus interface, by the looks. The DTKN is similar to the 68K's DTACK, I think, and I think it will be easier to implement if I use the Intel-style RD and WR signals that I'm already generating. Not much of the 6502 bus there, it seems. A little funny, that.
OBEX driver says this: An emulation of the famous sound chip in the Commodore 64 running in a single cog. It is much closer to the 8580 than the 6581 when it comes to filter emulation and combined waveforms.
The 8580 is simply a HMOS version of the 6581 (Inexplicably, there's also a 6582, which is the same as the 8580 except for the part number). It sounds somewhat different to the 6581.
I'm getting back to the P1 after a long hiatus and never really got a fundamental understanding of Spin/PASM objects.
Is there anything special I need to do to have more than one copy of sidcog running at a time? Also, is 1.3 the latest version?
No, just instantiate the same object multiple times.
Thanks Wuerfel. I was already using in this manner, but it turned out I had two different problems, which I'll describe here in case anyone else faces this.
First issue was that I was using a flag to "brad's spin tool compiler" to remove unused methods, which was optimizing away something (don't know what) that rendered every sidcog instance useless except the last one.
Second issue was I set the second argument of sidcog's start to "0", thinking that it was a disable flag (rather than "use pin 0 for left output").
Anyway, things are behaving as I expect now... now off to figure out how to add a LFO to some of the parameters.
BSTC's unused method elimination has bugs? hmm, usually works great for me. (If you care about working around this bug or encounter it again in a different context, you might want to try to have BSTC generate a listing ("-l" option, I think?) for an optimized vs. unoptimized build and then diff them to figure out what's getting eliminated)
Well, there it is: A SID that breaks SIDcog. Or breaks in SIDcog? Anyways semantics aside, this one sounds weird. If you have a recent HVSC, it's under /MUSICIANS/J/Jammer/80squares.sid
Now, this isn't the first broken SID, but this is the first one I think I found that's genuinely SIDcog's fault (as opposed to the dumper being to dump to dump the playroutine (LFT's tunes...) or the tune suffering from being converted into a dump)
I think something's wrong with the combined waveforms. Maybe it's doing ringmod+triangle+square or smth like that. Would have to look into that.
Anyways, here's what it's supposed to be like:
And attached below is what SIDcog makes of it. Mind you, this is already vastly better than both the player in the dumper as well as XMplay, in that it doesn't have obnoxiously loud pops.
I used the dmp file with my own "SIDcog" implemented on RPi - the result is similar to P1 SIDcog. It seems combined waveforms can also be ring modulated (maybe only triangle-based) and I don't even know what can be the result of such modulation. A real C64 with 8580 owner is needed. What we can do is to try enabling ring modulation for combined waveforms and check what result it can make.
I do have a couple C64/128 with 8580s (inexplicably, none with 6581), but none of them are hooked up right now. I don't think there's a DMP player, but I think I should be able to whip one up in a few lines of assembly.
Anyways, I think the effect of ringmod+tri+square is fairly obvious. The phase would need to shift 180 deg based on the MSB of the modulator's phase.
Maybe yes and maybe no. Combined waveform is made of some weird logic done with base waveforms. What can be the result if only the triangle phase is reversed, but not the square and that reversed triangle is combined with a non reversed square?
The simplest thing to try is to add the ring modulation to combined waveforms in SidCOG and play the .dmp. Maybe I will try (later today) with my RPi implementation.
Maybe yes and maybe no. Combined waveform is made of some weird logic done with base waveforms. What can be the result if only the triangle phase is reversed, but not the square and that reversed triangle is combined with a non reversed square?
Well, it helps to understand how the combined waveforms work. here's what I recall:
In the SID, each waveform is always generated, but is separated from the waveform DAC by what is effectively tristate buffer. If more than one of these buffers is enabled, each bit is pulled to some inbetween levels. Since the SID is NMOS, where pulling down always wins, this results in a binary AND. The square wave is special however, in that all of its bits are connected together. So the up-pulling power of the square's bits varies depending on how many bits of the other waveforms are low. Or something to that extent. Basically, there's some analog interaction between the bits. In effect, square+triangle is basically a distorted triangle wave AND-ed with a square wave. Same for square+saw.
Well yes, it was the square+tri+ringmod that was missing!
Now it sounds pretty close to what it's supposed to be. Still a bit off, but probably as good as it's gonna get.
Nice to see that there is still interest in it. I have continued the work on the P2 since I believe that IS the future of it. There is no real version of SIDcog for the P2 just yet other than that hack that I released, but it will come. I will fix this ringmod issue for combined waveforms on the P2 version. I guess the time has come to either fork SIDcog or to have parallel developments on the P1 and P2.
Comments
public virtual void PresentChip(Propeller host) { }been changed in v15 to
public virtual void PresentChip() { }Is it supposed / going to be : ?
public virtual void PresentChip(PropellerCPU chip ) { }Or is there some other mechanism in place / planned to pass the current chip to PresentChip ?
The reason to don't have a Propeller as a parameter in that method, is because in the new version it is included in the Base class, so if you needed inside PresentChip(), you just call it as .
I want to ask you to post the questions about the GEAR plugins in http://forums.parallax.com/showthread.php/156347-Improved-GEAR-Emulator, to be respectful with the thread about SIDCog.
To clarify better how to use the new plugin system, I could post there a template for the plugins.
Antonio
Thanks!
Hopefully someone can point us to a more permanent location, since I will probably only keep the above file available for a short time...
I'd be happy to create a repo for it (and the SIDCog) assuming I don't violate any rules.
Just please send me an IM so that I know to look for this post.
I hacked up siddump into a utility that could stream the registers right out of a SID file and over the UART. By extension it could also be easily modified to dump them by just tweaking the console output and piping the result to a file.
It's a wip, but is presently quite usable if you're willing to tweak a couple of values in code:
https://github.com/gadgetoid/sidstream
What do I load on the propeller to make propeller hat accept SID data from the raspberry pi?
Even though I'm the developer of SIDcog, I don't know what protocol Gadgetoid uses for streaming SID-data.
/Johannes
Does the SIDcog implement all the SID registers or just the write-only ones? (This is mainly out of curiosity, I don't think I need the other ones)
If I want to use this with an external processor, would I have to write a cog to adapt the processor's bus to the SIDcog?
What sort of maximum speed do you think I could expect to run an external 6502 at? (I think I can get around this with a little external hardware and a bit of code in an adaptor cog, though, so it's not a problem if I can't sit this directly on an 8-10MHz 6502-style bus)
Sorry for the necro.
If you are clocking the 6502 externally from the prop...
An 8 to 10 Mhz 6502 is fast relative to a propeller participating on the bus directly. Pretty sure this is too fast.
You would have to write a COG either way. This has been done, which is a very nice leg up.
I never looked at the register implementation. SIDCOG can play C64 data dumps. That suggests the registers are there. Or at least what you need to present them to the 6502 to do sound is there.
You could slow the bus when talking to (ugly, IMHO), or buffer the data to match up to a propeller. (Sweet)
Propellers participate on a 6502 style bus just fine, but due to number of pins, it's common to use latch, buffer chips and signals to allow the prop to prepare the necessary signals in multiple steps. Sidcog does not need many pins for output. You should be able to talk to the bus by latch buffering an address, then data.
Done that way, you could leave your bus at speed and just expect some time to pass before a transfer operation completes.
If you do that, you get a couple Mhz I/O throughput maybe 3? If you exchange data too quickly, some is lost and or duplicated. But!
This is more than enough. A real SID clocked at 1mhz. Having 3 would mean getting more out of the emulation, if you want to.
On your 6502, just make a bit of code with delay time baked in, and call for reads and writes. A music player could also run just fine on an interrupt.
Maybe include a configurable and maskable interrupt signal from the prop. You could optionally have the Prop signal for transfers, if you want peak rate.
If you have a 6522 (ideally a faster workalike), those have timers and an interrupt signal as well. Set one of those up for 1mhz, and you would have a nice basis for playing existing Sid tunes. Or, if you want interrupts free, and or not complicated by multiple things needing the two available, you can just poll a timer and likely run sound with another short task using the interrupt, say a mouse or other I/O device.
Or!
If you have the Prop clock the 6502, about 3Mhz is possible, and it's been done, there are circuits out there you can build on and from. I'm pretty sure the 3mhz ish figure is based on an 80Mhz prop. They clock to 96Mhz reliably with a 6Mhz xtal. Those can be hard to source. Parallax has them. Bill Henning did a run a long while back. He will have them too.
The crystal sold by Parallax is a 6.25Mhz:
https://www.parallax.com/product/251-06250
This yields a 100 Mhz clock at 16XPLL.
No, the read-only registers POTX/POTY/OSC3/ENV3 are not implemented.
I had one version of SIDcog modified to implement OSC3 and ENV3 registers, see http://forums.parallax.com/discussion/133075/polyphonic-sidcog-synth-wip
Unfortunately, to get the cycles needed to write back to HUB it was necessary to permanently disable oscillator 3 output (which saved one multiplication), while still keeping it's envelope and phase-accumulator/waveshaper running just to get the modulator values.
However, I'm quite confident that if you clock the propeller with a 6MHz or 6.25MHz crystal, and keep the SID samplerate at 31250, there should be enough spare cycles to implement that modification *AND* switchable OSC3 audio output as in the original chip.
Given that there's no reads to worry about, I can probably get away without wait-stating the 6502. I'm thinking of setting up a "data taken" output on the prop. The props CS would be controlled by a latch set by the external register's CS, and reset by the DTKN signal, which would also be broken out to at least one memory location for polling purposes(one dedicated, or the whole SIDcog address space in read mode). I have the idea that I should build some kind of interrupt capability into it, but I'll have to think on how to do that.
This'll be a bit of a hybrid/mongrel bus interface, by the looks. The DTKN is similar to the 68K's DTACK, I think, and I think it will be easier to implement if I use the Intel-style RD and WR signals that I'm already generating. Not much of the 6502 bus there, it seems. A little funny, that.
https://spectrum.ieee.org/tech-history/silicon-revolution/chip-hall-of-fame-mos-technology-6581
OBEX driver says this: An emulation of the famous sound chip in the Commodore 64 running in a single cog. It is much closer to the 8580 than the 6581 when it comes to filter emulation and combined waveforms.
What is 8580? Something better?
Is there anything special I need to do to have more than one copy of sidcog running at a time? Also, is 1.3 the latest version?
As far as I know, yes.
Thanks Wuerfel. I was already using in this manner, but it turned out I had two different problems, which I'll describe here in case anyone else faces this.
First issue was that I was using a flag to "brad's spin tool compiler" to remove unused methods, which was optimizing away something (don't know what) that rendered every sidcog instance useless except the last one.
Second issue was I set the second argument of sidcog's start to "0", thinking that it was a disable flag (rather than "use pin 0 for left output").
Anyway, things are behaving as I expect now... now off to figure out how to add a LFO to some of the parameters.
Now, this isn't the first broken SID, but this is the first one I think I found that's genuinely SIDcog's fault (as opposed to the dumper being to dump to dump the playroutine (LFT's tunes...) or the tune suffering from being converted into a dump)
I think something's wrong with the combined waveforms. Maybe it's doing ringmod+triangle+square or smth like that. Would have to look into that.
Anyways, here's what it's supposed to be like:
And attached below is what SIDcog makes of it. Mind you, this is already vastly better than both the player in the dumper as well as XMplay, in that it doesn't have obnoxiously loud pops.
Anyways, I think the effect of ringmod+tri+square is fairly obvious. The phase would need to shift 180 deg based on the MSB of the modulator's phase.
The simplest thing to try is to add the ring modulation to combined waveforms in SidCOG and play the .dmp. Maybe I will try (later today) with my RPi implementation.
Well, it helps to understand how the combined waveforms work. here's what I recall:
In the SID, each waveform is always generated, but is separated from the waveform DAC by what is effectively tristate buffer. If more than one of these buffers is enabled, each bit is pulled to some inbetween levels. Since the SID is NMOS, where pulling down always wins, this results in a binary AND. The square wave is special however, in that all of its bits are connected together. So the up-pulling power of the square's bits varies depending on how many bits of the other waveforms are low. Or something to that extent. Basically, there's some analog interaction between the bits. In effect, square+triangle is basically a distorted triangle wave AND-ed with a square wave. Same for square+saw.
Now it sounds pretty close to what it's supposed to be. Still a bit off, but probably as good as it's gonna get.
So here's to that, SIDcog 1.4, I guess.
Got this
It seems to be something like what it should be, but the further investigation is still needed.
I missed SIDcogs 10 year anniversary! :(
Nice to see that there is still interest in it. I have continued the work on the P2 since I believe that IS the future of it. There is no real version of SIDcog for the P2 just yet other than that hack that I released, but it will come. I will fix this ringmod issue for combined waveforms on the P2 version. I guess the time has come to either fork SIDcog or to have parallel developments on the P1 and P2.
/Johannes
Well yeah, the P2 version's gonna become it's own thing. You ought to pair it up with a good 6502 core so you can play RSIDs!