Good work Maybe later this year I will be able to try the P2...
Using real MUL in P1V clocked at 114 MHz gave me 64 kHz sample rate for SIDCog. Here we have up to 300 (?) MHz and 2 cycles instead of 4 for an instruction... 250 MHz seems to be available even using the original code (minus mul procedure).
I wrote a SIDCog inspired SID emulator for the Rasperry Pi (in a bare metal enviroment, without OS). My assembly code is not optimized and much more complex than the SIDCog; it uses about 30% of one ARM CPU core @ 1.2 GHz running SID at 960 kHz... maybe a full speed SID emulator wil be possible on a 300 MHz clocked P2 when optimized?...
I have already achieved 250 kHz @ 190 MHz. Mostly thanks to hardware mul and direct access of word, byte, nibble types in cog memory. (no more shifting, masking and juggling with bits). Still there are a lot of potential optmizations possible on the P2! 😀
I Will upload a new version when I have cleaned the code up a little bit.
Nicely done, Ahle2! However, some (or most) pins will just send noise. Edited code to use pins 32 and 34, since they are contiguous and near one of the ground pins. That way, I can easily connect the P2 to an ampifier.
Anyways, is there any hardware limitation regarding the pins to be used? Or in theory, any pin should work and my P2 is defective?
I have already achieved 250 kHz @ 190 MHz. Mostly thanks to hardware mul and direct access of word, byte, nibble types in cog memory. (no more shifting, masking and juggling with bits). Still there are a lot of potential optmizations possible on the P2! 😀
I Will upload a new version when I have cleaned the code up a little bit.
So it seems 490 kHz is possible. 490 kHz is good enough (I tried this with RPi)
We can build a lot of retroemulators with P2 It seems C64 and 8-bit Atari can be done with it.
Nicely done, Ahle2! However, some (or most) pins will just send noise. Edited code to use pins 32 and 34, since they are contiguous and near one of the ground pins. That way, I can easily connect the P2 to an ampifier.
Anyways, is there any hardware limitation regarding the pins to be used? Or in theory, any pin should work and my P2 is defective?
Kind regards, Samuel Lourenço
Any pin should work, I don't know what you are seeing. Strange indeed!
I have already achieved 250 kHz @ 190 MHz. Mostly thanks to hardware mul and direct access of word, byte, nibble types in cog memory. (no more shifting, masking and juggling with bits). Still there are a lot of potential optmizations possible on the P2! 😀
I Will upload a new version when I have cleaned the code up a little bit.
So it seems 490 kHz is possible. 490 kHz is good enough (I tried this with RPi)
We can build a lot of retroemulators with P2 It seems C64 and 8-bit Atari can be done with it.
Yes, the P2 is an amazing platform and I'm looking forward to do a lot of "retro" things with it. A lot more could have been done on the P1 regarding emulation and retro stuff if it just did have a little bit more memory. C64, NES and Atari 8 bit emulation, etc would have been possible with more memory. I'm sure!
Samuel, did you find out what was wrong with the pin configuration? I have not tried a lot of different pins with my code.
No, I didn't. The only "breakthrough" is that I can't hear any noise if I change the supply to those pins from VIO to 3V3 (DC-DC to LDO, essentially). So, it seems that the pins produce no sound and the noise comes from the DC-DC. Haven't tried this with the new version, though.
When connecting the new accessory AV board (and was forced to change the pin configuration) I discovered that the wait for selectable event mechanism locks up when using certain pins.... strange! I'm not sure whether it's my fault or the hardware. Probably mine!
That's the reason why you couldn't get audio on certain pins!
For those people who want to get this code to work with the cross platform p2asm/p2link tools etc and a P2-EVAL board but don't know how to do it (like me about 20 mins ago), this is the list of steps that you need to do...
1) download the SIDcogP2 zip file posted above (250kHz)
2) patch audio pins in SIDcogP2.spin2 file to suit. I fit the A/V accessory board to the P31-39 connector, so I had this:
CON
L_PIN = 38 ' left is lowest pin on the A/V accessory board
R_PIN = 39
3) Fix bug above for setsel instruction by removing comment before | L_PIN.
setse1 #%001_100000 | L_PIN ' Event triggered every new sample period (when "left in pin rises")
4) Patch the SIDcogP2.spin2 file to avoid this compiler error
p2asm -o SIDcogP2.spin2
151: ERROR: Cannot mix float and fix
CON PAL = 985248.0, NTSC = 1022727.0, MAXF = 1031000.0, TRIANGLE = 16, SAW = 32, SQUARE = 64, NOISE = 128
151: ERROR: Cannot mix float and fix
CON PAL = 985248.0, NTSC = 1022727.0, MAXF = 1031000.0, TRIANGLE = 16, SAW = 32, SQUARE = 64, NOISE = 128
151: ERROR: Cannot mix float and fix
CON PAL = 985248.0, NTSC = 1022727.0, MAXF = 1031000.0, TRIANGLE = 16, SAW = 32, SQUARE = 64, NOISE = 128
151: ERROR: Cannot mix float and fix
CON PAL = 985248.0, NTSC = 10
To fix it you just need to split up the float and fixed point constants defined onto separate lines:
CON PAL = 985248.0, NTSC = 1022727.0, MAXF = 1031000.0
CON TRIANGLE = 16, SAW = 32, SQUARE = 64, NOISE = 128
5) Then just assemble, link, download and enjoy! I do this...
Okay, I found the problem.... for some reason the event config looked like this.
setse1 #%001_100000 '| L_PIN
When it sould look like this.
setse1 #%001_100000 | L_PIN
So know the question is why it worked at all using pin 32?!
I think it's because bit 5 of your SETSE1 value is always set, selecting pin 32+.
Yes... that explains it all. When experimenting with getting SIDcog running on the P2 I "temporarily" hardcoded pin 32 and then forget about that little apostrophe. 🙄
I just got it going on P9 and P10 using what you and Chip suggested:
setse1 #%001_000000 | L_PIN ' Event triggered every new sample period (when "left in pin rises")
Sounds really cool, BTW. Might be useful for a game I want to make...
Thanks Rayman... the SID was such an unique sound chip back in the 80's compared to the rest. Much more like a real subtractive synthesizer with features such as ring modulation, pulse width modulation, envelopes and a multi-mode resonant analog filter. Like a Moog in a chip. Too bad it took half a decade before any programmers started using these unique features. Most just made it do square waves without any modulation or filtering and the result was that people thought it was another Atari/Nintendo-style sound chip. Then came Rob Hubbard, Martin Galway, Jeroen Tel, Chris Huelsbeck etc. and changed that forever. Nowdays they make it do things that if played in 1982, would have made people shake their heads in disbelief.
I just wanted to upload my latest version of SIDcog for the P2 before I continue with my other project, a sound driver for the P2.
Use FastSpin to compile it.
So, I am attempting to get SIDcog integrated with a flexprop spin2 program and am having some challenges. The SIDCog posted here obviously doesn't have any spin2 methods defined, however I do not have a need to manipulate it in that way. I just need to start up SIDcog in it's own cog and retrieve the pointer to the starting address of the 24 SID registers. It appears that the cog is executing from Hub RAM in the SIDCog.spin2 file. I think I just need to add a start Pub method in the SIDCog.spin2 file.
Yes, that was before there was any Spin2 interpreter available. SIDcog could run from COG RAM, that's the way it is meant to be. It is small enough. The first SID register in HUB RAM is @ch1_frequencyLo, then you could just have a look at the official SID documentation for the interpretation of all the available byte sized registers.
I probably should make a Spin2 interface now that Spin2 is mature!
I am thoroughly having my head handed to me with attempting to create a start object that I can instantiate and bubble up the Hub address @ch1_frequencyLo. Many hours and several days. Nothing but failure. I have written objects in the past. Why is this so hard? This is what I get for only coding twice a year, LOL.
Thanks Chip. I think I almost got it. This is being done in the FlexProp environment. At this point I think I need a review of @ and @@ :)
This appears to compile and I suspect the cog is executing correctly, I just need to stream some data to the SIDCOG registers at @ch1_frequencyLo. That's gonna take me a minute.
OK, I ran into some FlexProp-isms and a fixed address for the SIDCog registers. I have it somewhat working! At least enough to continue with my project!
Below is my code. The timing is wrong. But I can make of POC out of this.
VGA is on pin 48. If using the A/V board, you will need to change the pins to the last two of the grouping where the A/V board is plugged in.
CON
PINBASE = 48
_clkfreq = 250_000_000
#include "SIDcog.spin2"
DAT
dumpFile file "dumps/Sagyrs_Castle.dmp"
OBJ
scrn: "ansi"
' sid: "SIDcog"
VAR
long Index
long DFIndex
long cog
PUB main()
cog := coginit(1,@SIDEMU) 'Start SIDcog in one cog
scrn.start(PINBASE)
'start()
scrn.str(string(27, "[1;1H"))
scrn.str(string(27, "[0J"))
scrn.hideCursor()
scrn.str(string("Started"))
DFIndex := @@@dumpfile
repeat
Index := $1400
repeat 25
byte[Index] := byte[DFIndex]
scrn.hex(DFIndex,8)
scrn.str(string(" "))
scrn.hex(byte[DFIndex],2)
scrn.str(string(" "))
scrn.hex(byte[Index],2)
scrn.str(string(" "))
scrn.hex(Index,8)
scrn.nl()
Index++
DFIndex++
wait()
Pub wait()
org
waitx ##40_000_00 / 50
end
return
I have been pondering the future of SIDcog back and forth for a while now. The P1 and P2 are different enough so that it doesn't make sense to have two parallel developments going on with the exact same features, changes and releases. I think I will put the official version of SIDcog for the P1 on the self for now (maybe make an official 1.4 version with the fixes discussed in the thread). If SIDcog gets forked anyway, I have had this idea to make a multi-chip sound chip emulator. The P2 is fast enough to make that possible with good sound quality in a single cog. All the work for several different PSGs are already done on the P1. It should be quite easy to put up a first version. It will be adaptable and always maximize the sound quality for the configured number of sound chips.
I think it may be the first CoCo to have an external hardware device that plays SIDs. I remember seeing a CoCo that had a software SID emulator running. That took up all the machines resources and sounded awful.
But it was a really cool proof of concept!
SIDcog on the P2 will be no more and I want a moderator to lock this thread and to insert a link to the Crescendo thread instead. Also, SIDcog on the P1 will be put on ice and all my sound chip emulation efforts will be put into the Crescendo P2 project instead.
@ke4pjw said:
That sounds great! I got my proof of concept working with my retro computing project. My Tandy Color Computer 3 now plays chip tunes!
I have added a video over on Facebook
A number of people were asking about the Yamaha OPL chips over on Facebook.
Thank you for making this software! I have had a lot of fun with this project! I have the best sounding CoCo on the block!
That sounded great! What clock were you running your P2 at? Can someone explain to me if that is emulating a SID at 250kHz, and the original C=64 had a SID running at 1MHz, what the difference is? I thought the SIDcog on the P1 was a full emulation. I wasn't aware that it didn't run at full speed.
Comments
Using real MUL in P1V clocked at 114 MHz gave me 64 kHz sample rate for SIDCog. Here we have up to 300 (?) MHz and 2 cycles instead of 4 for an instruction... 250 MHz seems to be available even using the original code (minus mul procedure).
I wrote a SIDCog inspired SID emulator for the Rasperry Pi (in a bare metal enviroment, without OS). My assembly code is not optimized and much more complex than the SIDCog; it uses about 30% of one ARM CPU core @ 1.2 GHz running SID at 960 kHz... maybe a full speed SID emulator wil be possible on a 300 MHz clocked P2 when optimized?...
I Will upload a new version when I have cleaned the code up a little bit.
Anyways, is there any hardware limitation regarding the pins to be used? Or in theory, any pin should work and my P2 is defective?
Kind regards, Samuel Lourenço
So it seems 490 kHz is possible. 490 kHz is good enough (I tried this with RPi)
We can build a lot of retroemulators with P2
Any pin should work, I don't know what you are seeing. Strange indeed!
Yes, the P2 is an amazing platform and I'm looking forward to do a lot of "retro" things with it. A lot more could have been done on the P1 regarding emulation and retro stuff if it just did have a little bit more memory. C64, NES and Atari 8 bit emulation, etc would have been possible with more memory. I'm sure!
Kind regards, Samuel Lourenço
Kind regards, Samuel Lourenço
When connecting the new accessory AV board (and was forced to change the pin configuration) I discovered that the wait for selectable event mechanism locks up when using certain pins.... strange! I'm not sure whether it's my fault or the hardware. Probably mine!
That's the reason why you couldn't get audio on certain pins!
When it sould look like this.
So know the question is why it worked at all using pin 32?!
I think it's because bit 5 of your SETSE1 value is always set, selecting pin 32+.
Sounds really cool, BTW. Might be useful for a game I want to make...
For those people who want to get this code to work with the cross platform p2asm/p2link tools etc and a P2-EVAL board but don't know how to do it (like me about 20 mins ago), this is the list of steps that you need to do...
1) download the SIDcogP2 zip file posted above (250kHz)
2) patch audio pins in SIDcogP2.spin2 file to suit. I fit the A/V accessory board to the P31-39 connector, so I had this:
3) Fix bug above for setsel instruction by removing comment before | L_PIN.
4) Patch the SIDcogP2.spin2 file to avoid this compiler error
To fix it you just need to split up the float and fixed point constants defined onto separate lines:
5) Then just assemble, link, download and enjoy! I do this...
Yes... that explains it all. When experimenting with getting SIDcog running on the P2 I "temporarily" hardcoded pin 32 and then forget about that little apostrophe. 🙄
Thanks Rayman... the SID was such an unique sound chip back in the 80's compared to the rest. Much more like a real subtractive synthesizer with features such as ring modulation, pulse width modulation, envelopes and a multi-mode resonant analog filter. Like a Moog in a chip. Too bad it took half a decade before any programmers started using these unique features. Most just made it do square waves without any modulation or filtering and the result was that people thought it was another Atari/Nintendo-style sound chip. Then came Rob Hubbard, Martin Galway, Jeroen Tel, Chris Huelsbeck etc. and changed that forever. Nowdays they make it do things that if played in 1982, would have made people shake their heads in disbelief.
I just wanted to upload my latest version of SIDcog for the P2 before I continue with my other project, a sound driver for the P2.
Use FastSpin to compile it.
So, I am attempting to get SIDcog integrated with a flexprop spin2 program and am having some challenges. The SIDCog posted here obviously doesn't have any spin2 methods defined, however I do not have a need to manipulate it in that way. I just need to start up SIDcog in it's own cog and retrieve the pointer to the starting address of the 24 SID registers. It appears that the cog is executing from Hub RAM in the SIDCog.spin2 file. I think I just need to add a start Pub method in the SIDCog.spin2 file.
Yes, that was before there was any Spin2 interpreter available. SIDcog could run from COG RAM, that's the way it is meant to be. It is small enough. The first SID register in HUB RAM is @ch1_frequencyLo, then you could just have a look at the official SID documentation for the interpretation of all the available byte sized registers.
I probably should make a Spin2 interface now that Spin2 is mature!
I am thoroughly having my head handed to me with attempting to create a start object that I can instantiate and bubble up the Hub address @ch1_frequencyLo. Many hours and several days. Nothing but failure. I have written objects in the past. Why is this so hard? This is what I get for only coding twice a year, LOL.
Can you post what you've done so far and what you're trying to do?
Thanks Chip. I think I almost got it. This is being done in the FlexProp environment. At this point I think I need a review of @ and @@ :)
This appears to compile and I suspect the cog is executing correctly, I just need to stream some data to the SIDCOG registers at @ch1_frequencyLo. That's gonna take me a minute.
CON PINBASE = 48 _clkfreq = 250_000_000 DAT #include "SIDcog.spin2" dumpFile file "dumps/Sagyrs_Castle.dmp" OBJ scrn: "ansi" PUB main() coginit (2, @@SIDEMU,@ch1_frequencyLo) scrn.start(PINBASE) scrn.str(string(27, "[1;1H")) scrn.str(string(27, "[0J")) scrn.hideCursor() scrn.str(string("Started"))Sounds like @Ahle2 will have it in a proper spin2 object RSN.
OK, I ran into some FlexProp-isms and a fixed address for the SIDCog registers. I have it somewhat working! At least enough to continue with my project!
Below is my code. The timing is wrong. But I can make of POC out of this.
VGA is on pin 48. If using the A/V board, you will need to change the pins to the last two of the grouping where the A/V board is plugged in.
CON PINBASE = 48 _clkfreq = 250_000_000 #include "SIDcog.spin2" DAT dumpFile file "dumps/Sagyrs_Castle.dmp" OBJ scrn: "ansi" ' sid: "SIDcog" VAR long Index long DFIndex long cog PUB main() cog := coginit(1,@SIDEMU) 'Start SIDcog in one cog scrn.start(PINBASE) 'start() scrn.str(string(27, "[1;1H")) scrn.str(string(27, "[0J")) scrn.hideCursor() scrn.str(string("Started")) DFIndex := @@@dumpfile repeat Index := $1400 repeat 25 byte[Index] := byte[DFIndex] scrn.hex(DFIndex,8) scrn.str(string(" ")) scrn.hex(byte[DFIndex],2) scrn.str(string(" ")) scrn.hex(byte[Index],2) scrn.str(string(" ")) scrn.hex(Index,8) scrn.nl() Index++ DFIndex++ wait() Pub wait() org waitx ##40_000_00 / 50 end return@ke4pjw
I have been pondering the future of SIDcog back and forth for a while now. The P1 and P2 are different enough so that it doesn't make sense to have two parallel developments going on with the exact same features, changes and releases. I think I will put the official version of SIDcog for the P1 on the self for now (maybe make an official 1.4 version with the fixes discussed in the thread). If SIDcog gets forked anyway, I have had this idea to make a multi-chip sound chip emulator. The P2 is fast enough to make that possible with good sound quality in a single cog. All the work for several different PSGs are already done on the P1. It should be quite easy to put up a first version. It will be adaptable and always maximize the sound quality for the configured number of sound chips.
Maybe I could name it Crescendo , short for "Cooperative REtro Sound Chips Emulator Narrowed Down to an Object". :)
haha I like it! 😉
That sounds great! I got my proof of concept working with my retro computing project. My Tandy Color Computer 3 now plays chip tunes!
I have added a video over on Facebook
A number of people were asking about the Yamaha OPL chips over on Facebook.
Thank you for making this software! I have had a lot of fun with this project! I have the best sounding CoCo on the block!
Great work @ke4pjw
, I really like it!
I think it may be the first CoCo to have an external hardware device that plays SIDs. I remember seeing a CoCo that had a software SID emulator running. That took up all the machines resources and sounded awful.
But it was a really cool proof of concept!
SIDcog on the P2 will be no more and I want a moderator to lock this thread and to insert a link to the Crescendo thread instead. Also, SIDcog on the P1 will be put on ice and all my sound chip emulation efforts will be put into the Crescendo P2 project instead.
Is there any optimizations to be made to the multiplication code?
That sounded great! What clock were you running your P2 at? Can someone explain to me if that is emulating a SID at 250kHz, and the original C=64 had a SID running at 1MHz, what the difference is? I thought the SIDcog on the P1 was a full emulation. I wasn't aware that it didn't run at full speed.