SONIC THE HEDGEHOG PORTED TO THE SUPER NINTENDO

[Steven Pendleton]

20 minutes ago, Tanooki said:

Wow Sonic 2 Chemical Plant Zone on PCE that's on point.  You'd really have to have a well trained ear to the original to start nitpicking some little details on where you have differences.

Yeah, it's crazy, isn't it? The bass part is obviously the PC Engine since that's definitely the PC Engine's bass sound, but most of the rest of it is extremely close. For the first 5 seconds or so before the bass starts playing, you'd think it was the original music instead! At least, I did.

[roadrunner]

Why did the person that made this remove the rom? When's he gonna post a new one?
Release the rom  

[No One You Know]

On 8/28/2020 at 3:47 PM, Steven Pendleton said:

https://youtu.be/qOWXaQaPVI4

Wow. That's amazing. thanks !

 

 

On 8/28/2020 at 5:13 PM, Black_Tiger said:

Tricky, Moto Roader 1 & 2, Nadia, Fiend Hunter, Sword Master, Fire Pro Wrestling 2, Lapras no Ma, Cyber Dodge and Dead Moon are some that have bgms that sound similar to Mega Drive games.

I'll have to check those out too. thanks!

17 hours ago, Tanooki said:

Wow Sonic 2 Chemical Plant Zone on PCE that's on point.  You'd really have to have a well trained ear to the original to start nitpicking some little details on where you have differences.

Well not that well trained. You can hear differences (mostly in quality) but they are very minor and not even as wide as between your average GBA and SNES versions of a game.

[DragonGrafx-16]

19 hours ago, Steven Pendleton said:

Yeah, it's crazy, isn't it? The bass part is obviously the PC Engine since that's definitely the PC Engine's bass sound, but most of the rest of it is extremely close. For the first 5 seconds or so before the bass starts playing, you'd think it was the original music instead! At least, I did.

I think I like the PCE version of the track much more other than the bass... the PCE just has much better audio sample support as the Genesis only had monophonic sample playback... but the PCE could play back samples polyphonically and even have stereo panning for drums! 

[Tanooki]

Yeah the PCE is an improvement over the Genesis audio any day in so many respects that it's just pathetic making you wonder why Sega cut some budgetary corners on specific chips they had wide well tempered experience with given their arcade roots between the 68000 and the YM (yamaha) chip as well.  That was kind of Sega though, halfassing all sorts of stuff and cutting corners and not the right way.  NIntendo was and is the master of being cheap, using older stuff to new maximums to get the most for your gaming buck, they could have taken a lesson before it was too late.  The fact the older NEC hardware outdid the Genesis in audio and video too in many realms from color to more is just pathetic.  I think had NEC USA decided to emulate the Japanese market instead of picking to leave the best stuff mostly stuck on the island, who knows how the 90s would have unfolded as they even gave Nintendo a bit of a pounding too in that period over there.

[DragonGrafx-16]

For example in the 4th stage of Final Soldier on the PC Engine... the music has a part were a sampled kick and hi hat play at the same time...

 

 

Can't do that on the Genesis! Nor the panning toms!

[Lost Monkey]

I don't know if it is still readily available, but there is a homebrew Sonic demo for PCE-CD.  It is quite impressive considering (I believe) it was done in HuC.

Edited August 30, 2020 by Lost Monkey

[turboxray]

On 8/28/2020 at 6:33 AM, No One You Know said:

In theory you could just sample the full repeating FM loop and use it as a wavetable but with only 32 sampling points that would have to be low resolution and pretty rough if you are not intervening with the CPU, not to mention the 5 bit depth. I suppose it is only important that it sounds similar. Can you have one of the oscillators alternate between playing a wavetable and then muting for the next loop of the wavetable so you have two channels playing one 64 sample wavetable? I suppose the CPU is reasonably fast especially when compared to the SNES so you could do software sound though that probably would be hard to as well as software parallax. I will have to look at aldynes again then.

Wait.. what.. no! Why would you even take that approach??? For one, that's not going to work because a frequency is a 3.57mhz clock with a divider.. you're never going to align up perfectly with an arbitrary frequency to pull that off. And if you somehow could, that take near 100% cpu resource to pull that off accurately. The 5bit resolution doesn't actually matter in practice for two reasons; the waveform data is only 32bytes so having anything higher bitrate doesn't really do anything, and it's not going to produce a low res 'stair case' effect, unless you're using really low frequencies, because of the analog filtering. The sample data might be 5bits, but the volume levels for each of those channels is not in that 5bit space. 

 

If want more advance sound on a single PCE channel, you setup an ADSR type envelope (something based on a 60hz tick), and simply update the channels waveform data as it moves to the next phase in the envelope. On top of that, individual notes can have their own brightness (timbre) just like on an FM chip - because they can have their own set of 32byte waveforms to cycle through. It's only 32bytes, so it's no big deal on the PCE to update (no faster than 1/60hz frame tick). If you look at PCE games with chiptunes, they're really simple sound engines - they don't do this (with exception of like three titles). If you ever heard anything impressive music on the PCE, it was down to the composers skills and not something technical being done on the sound chip side. A lot of developers used the very minimal approach to the sound chip (aka 'nes with extra knobs'). Fragmare's covers are more technical with the sound chip, but are not heavy cpu usage, and definitely not the limit of what the PCE can do (in game perspective; not this trend of using 60% cpu resource to make unrealistic music).

 

I mean I wrote a 4 channel MOD player for the PCE that uses 24% cpu resource. It resampled all samples in realtime for each channel. It still had 2 channels left over for simple sample playback too (all 6 channels together took 29%). Considering Air Zonk sound engine can easily hit up to 21% cpu resource because it decompresses samples, etc that's not really out of the realm of a game engine.

 

You can do simpler things like pair two channels and have one act as carrier and the other act as a modulator - limiting the two waveforms in the channel to upper 4bits and lower 4bits, and having the volume of the modular channel brighten or lower the timbre of the combination (because amplitudes add), and using fast period/frequency 'bumps' to bend the sound. The timbre and bending is so strong of an effect (and smooth), that pair with two other channels for a three note chord sounds as if all three notes had that effect going on. You can combine that approach with the ADSR waveform change approach too. You can do hard-sync using the TIMER interrupt. And as a last resort you can do realtime resampling on like 2 channels for DDA playback. Mix/match whatever.

 

[chuckwalla]

Being a huge fan of Sonic I think it's great to see a port on the SNES.

 

Right now i'm living a bit of a video game fantasy (since the early-mid 1990's) playing Sonic CD on the Samsung GXTV via the Mega Everdrive Pro.

 

Maybe we'll even see a port of Sonic on the Atari 7800 or even 2600 before long.

 

Keep the classic video gaming innovations coming...

[0078265317]

Actually there was a 2600 version.

 

https://www.polygon.com/2013/9/17/4741800/sonic-the-hedgehog-comes-to-the-atari-2600

 

https://atariage.com/forums/topic/170135-sonic-the-hedgehog-on-the-2600/#comments

[No One You Know]

On 8/30/2020 at 6:09 AM, Tanooki said:

Yeah the PCE is an improvement over the Genesis audio any day in so many respects that it's just pathetic making you wonder why Sega cut some budgetary corners on specific chips they had wide well tempered experience with given their arcade roots between the 68000 and the YM (yamaha) chip as well.  That was kind of Sega though, halfassing all sorts of stuff and cutting corners and not the right way.  NIntendo was and is the master of being cheap, using older stuff to new maximums to get the most for your gaming buck, they could have taken a lesson before it was too late.  The fact the older NEC hardware outdid the Genesis in audio and video too in many realms from color to more is just pathetic.  I think had NEC USA decided to emulate the Japanese market instead of picking to leave the best stuff mostly stuck on the island, who knows how the 90s would have unfolded as they even gave Nintendo a bit of a pounding too in that period over there.

The YM21612 isn't that bad for goodness sake. You really exaggerate it. The lack of colours on the Mega Drive compared with the PCE was quite a pitfall as its not even there as an option like the SNES but I suppose the saved RAM would help for the extra tilemap. Would have been interesting to see the TG-16 managed better. Need a killer app I suppose as always.

On 8/30/2020 at 2:10 PM, Lost Monkey said:

I don't know if it is still readily available, but there is a homebrew Sonic demo for PCE-CD.  It is quite impressive considering (I believe) it was done in HuC.

HuC? I want to see that now anyway.

On 8/30/2020 at 8:15 PM, turboxray said:

Wait.. what.. no! Why would you even take that approach??? For one, that's not going to work because a frequency is a 3.57mhz clock with a divider.. you're never going to align up perfectly with an arbitrary frequency to pull that off. And if you somehow could, that take near 100% cpu resource to pull that off accurately. The 5bit resolution doesn't actually matter in practice for two reasons; the waveform data is only 32bytes so having anything higher bitrate doesn't really do anything, and it's not going to produce a low res 'stair case' effect, unless you're using really low frequencies, because of the analog filtering. The sample data might be 5bits, but the volume levels for each of those channels is not in that 5bit space. 

 

If want more advance sound on a single PCE channel, you setup an ADSR type envelope (something based on a 60hz tick), and simply update the channels waveform data as it moves to the next phase in the envelope. On top of that, individual notes can have their own brightness (timbre) just like on an FM chip - because they can have their own set of 32byte waveforms to cycle through. It's only 32bytes, so it's no big deal on the PCE to update (no faster than 1/60hz frame tick). If you look at PCE games with chiptunes, they're really simple sound engines - they don't do this (with exception of like three titles). If you ever heard anything impressive music on the PCE, it was down to the composers skills and not something technical being done on the sound chip side. A lot of developers used the very minimal approach to the sound chip (aka 'nes with extra knobs'). Fragmare's covers are more technical with the sound chip, but are not heavy cpu usage, and definitely not the limit of what the PCE can do (in game perspective; not this trend of using 60% cpu resource to make unrealistic music).

 

I mean I wrote a 4 channel MOD player for the PCE that uses 24% cpu resource. It resampled all samples in realtime for each channel. It still had 2 channels left over for simple sample playback too (all 6 channels together took 29%). Considering Air Zonk sound engine can easily hit up to 21% cpu resource because it decompresses samples, etc that's not really out of the realm of a game engine.

 

You can do simpler things like pair two channels and have one act as carrier and the other act as a modulator - limiting the two waveforms in the channel to upper 4bits and lower 4bits, and having the volume of the modular channel brighten or lower the timbre of the combination (because amplitudes add), and using fast period/frequency 'bumps' to bend the sound. The timbre and bending is so strong of an effect (and smooth), that pair with two other channels for a three note chord sounds as if all three notes had that effect going on. You can combine that approach with the ADSR waveform change approach too. You can do hard-sync using the TIMER interrupt. And as a last resort you can do realtime resampling on like 2 channels for DDA playback. Mix/match whatever.

 

Alright. Take a chill pill. No need to get offended. The idea of using two channels was to reduce CPU requirements. I didn't think of synchronisation but I still don't understand why that is a problem? As you said all channels are based on a base clock with a divider so wouldn't they all be synced when running at the same frequency? Changing waveforms for different parts of the ADSR cycle is useful for realistic sounds in a sample synth but it won't give you more detailed waveforms. I just added the 5 bit thing as a side note. I didn't think about it in detail and as you point out you are unlikely to need more in normal use when you only have 32 samples per waveform. You are going to be using a lowish frequency if you are sampling a full FM cycle in just a 32 sample wavetable. Only 24% CPU time for a MOD player? That impresses me. Maybe in game sample synth is more feasible than I used to think on this and the lynx. But with resampling? So you are changing the sampling frequency? What?

 

You say a channel can *cycle* through a set of waveforms independently? So in effect you have a longer than 32 sample (20 bytes) wavetable? That would be a game changer but I suspect you just worded it wrong.

On 8/31/2020 at 1:04 AM, chuckwalla said:

Being a huge fan of Sonic I think it's great to see a port on the SNES.

 

Right now i'm living a bit of a video game fantasy (since the early-mid 1990's) playing Sonic CD on the Samsung GXTV via the Mega Everdrive Pro.

 

Maybe we'll even see a port of Sonic on the Atari 7800 or even 2600 before long.

 

Keep the classic video gaming innovations coming...

There has been Zippy the porcupine for a while:

7800 sonic could be at least as good as the NES sonic.

 

oh yeah and @Steven Pendleton, I didn't really think about it in depth before, but I suppose on the PCE you would still use the normal scrolling as well as the software parallax by hardscrolling the tiled foreground and just setting up the blank areas or bits that have transparency to display your soft drawn bitmap. It wouldn't be really simple but not rocket science either. An as for the mega-cd, sega retro mentions something about it having a HAM mode like in the amiga but it is only mentioned once.

Edited September 1, 2020 by No One You Know

[Tanooki]

1 hour ago, No One You Know said:

The YM21612 isn't that bad for goodness sake. You really exaggerate it. The lack of colours on the Mega Drive compared with the PCE was quite a pitfall as its not even there as an option like the SNES but I suppose the saved RAM would help for the extra tilemap. Would have been interesting to see the TG-16 managed better. Need a killer app I suppose as always.

I don't think I am, at least for the Genesis version of it and the other limits of that home version of that popular arcade yamaha hardware.   That chip on a real cabinet or emulated as such in MAME (etc) sound damned amazing cranking out some very clean, clear and booming pieces without the static and tinny sounds or muffled damage to sampled audio it seems to do in the Genesis.  I just find it very bothersome and obnoxious.  Either way, definitely, the Genesis in a way with the lack of colors it's right in there almost like some screwy middle ground between the NES or SMS of all things and the PCE which is just sad given there really was no good excuse cutting it short.   I have to agree to a point, as you're right, had TG16 been handled correctly, I think it would have clobbered the Genesis and odds are arriving near/same time too if not before as it did in Japan.  Had NEC Japan had the strange hold tactics NCL (Nintendo of Japan) had on their US office on what to put out and not, and they had released so many of those notable loved imports people have been digging on for 20+ years now the story would have had been written dramatically different in their favor.  Sega would have been on the ropes earlier than later, due to NEC instead of Sony.  Had all those nice Konami, Capcom, Taito, the third parties to those third parties stuff (like 1943 Kai for Capcom through AVE) came out in the states Sega would have been in deep shit.

[Steven Pendleton]

5 hours ago, No One You Know said:

oh yeah and @Steven Pendleton, I didn't really think about it in depth before, but I suppose on the PCE you would still use the normal scrolling as well as the software parallax by hardscrolling the tiled foreground and just setting up the blank areas or bits that have transparency to display your soft drawn bitmap. It wouldn't be really simple but not rocket science either. An as for the mega-cd, sega retro mentions something about it having a HAM mode like in the amiga but it is only mentioned once.

Yes, you could do that, if you wanted. Actually, the 240p test suite on the PC Engine uses Sonic 1's backgrounds from Green Hill (it looks a bit strange because it's been converted to 256, though...), and it does actually have the parallax scrolling, even if it looks kind of weird. Still, it's not a bad implementation and the regular PC Engine could absolutely do it if you put some work into software parallax. If you wanted, you could make it a CD game and sample the YM2612 music and play that back as CD audio and you'd get an extremely good port.

 

You could of course do this on the SuperGrafx, as well, and it would add the hardware scrolling while making history at the same time because there are no SuperGrafx-exclusive or SuperGrafx enhanced CD games. If you REALLY wanted to do something cool, you could make it an Arcade Card game on the SuperGrafx and maybe make it better than the original version, but I'm not sure exactly what all you'd be able to do with all of that extra RAM from the Arcade Card. There are no Arcade Card SuperGrafx-exclusives, either, so this would also be interesting!

[No One You Know]

On 9/1/2020 at 2:59 AM, Tanooki said:

I don't think I am, at least for the Genesis version of it and the other limits of that home version of that popular arcade yamaha hardware.   That chip on a real cabinet or emulated as such in MAME (etc) sound damned amazing cranking out some very clean, clear and booming pieces without the static and tinny sounds or muffled damage to sampled audio it seems to do in the Genesis.  I just find it very bothersome and obnoxious.  Either way, definitely, the Genesis in a way with the lack of colors it's right in there almost like some screwy middle ground between the NES or SMS of all things and the PCE which is just sad given there really was no good excuse cutting it short.   I have to agree to a point, as you're right, had TG16 been handled correctly, I think it would have clobbered the Genesis and odds are arriving near/same time too if not before as it did in Japan.  Had NEC Japan had the strange hold tactics NCL (Nintendo of Japan) had on their US office on what to put out and not, and they had released so many of those notable loved imports people have been digging on for 20+ years now the story would have had been written dramatically different in their favor.  Sega would have been on the ropes earlier than later, due to NEC instead of Sony.  Had all those nice Konami, Capcom, Taito, the third parties to those third parties stuff (like 1943 Kai for Capcom through AVE) came out in the states Sega would have been in deep shit.

I think the arcade machines usually use the YM2151 which is 8 channel and might have a few other bits and bobs, plus they are usually coupled with hardware pcm players so playback isn't dependent on software like with the mega drive. Having said that though, arcade games were usually programmed by the same company that specced their machine, end I'm sure there would have been some overlap between the hardware designers and the programmers as the hardware is designed to be programmed. So naturally companies that elected to use a certain chip probably would have already preferred it and had experience with it. Games using GEMS other than maybe Cool Spot and a few others usually aren't good representations of what it can do even if some like earthworm Jim have some good qualities. The MD really should have just given up some more RAM for extra palettes though. I'm sure they could have implemented that as they were adding modes to the chip.

 

Yeah, or NEC America could have been better on their own like sega of America. But Nintendo has a better track record and the PCE was big in Japan unlike the MD so being under their control probably would have been a better choice. Also about the euro popularity thing, I looked for master systems on eBay here in the UK and there are a lot. They are worth less than mega drives generally too which could either be that they are quite common (I have seen them for sale elsewhere too) or that no one wants them or a combination of the two. I should probably have one but now I am anxious (is that the right term?) that I would have got one yet cheaper years ago. I never got one as i didn't have that much interest and because he MD is technically backwards compatible even though I know the power base converter/MS converter is rare and expensive. Collectors might not be particularly interested in them but you'd think if they were really popular people with nostalgia for them would be buying a lot of them. Interestingly most are model 2s which suggests that they were used as like a budget alternative to the mega drive in the 90s which would make sense as they supported for most of the same time. That would make sense as to why the MS converters are so rare as people would have one or the other rather than having an MS and then upgrading and wanting to play their old games, and people with a Mega Drive already would just get the mega drive versions of games.

 

On 9/1/2020 at 7:00 AM, Steven Pendleton said:

Yes, you could do that, if you wanted. Actually, the 240p test suite on the PC Engine uses Sonic 1's backgrounds from Green Hill (it looks a bit strange because it's been converted to 256, though...), and it does actually have the parallax scrolling, even if it looks kind of weird. Still, it's not a bad implementation and the regular PC Engine could absolutely do it if you put some work into software parallax. If you wanted, you could make it a CD game and sample the YM2612 music and play that back as CD audio and you'd get an extremely good port.

 

You could of course do this on the SuperGrafx, as well, and it would add the hardware scrolling while making history at the same time because there are no SuperGrafx-exclusive or SuperGrafx enhanced CD games. If you REALLY wanted to do something cool, you could make it an Arcade Card game on the SuperGrafx and maybe make it better than the original version, but I'm not sure exactly what all you'd be able to do with all of that extra RAM from the Arcade Card. There are no Arcade Card SuperGrafx-exclusives, either, so this would also be interesting!

Is that by the guy that does all the PCE mini demos that has a blog and lives in Japan? I will have to look it up. I always thought it would be cool to see sonic CD on PCE CD too. You wouldn't have any problem with the music tune except for past stages, but as turbo X ray said MOD players can be done on PCE without using too much CPU time. I think the other reason talking about the supergrafx annoyed me is because it's not really a question of whether or not you could do it on supergrafx. I suppose the advantage the MD is meant to have over other things is loading tiles quickly but I'm sure sonic is not too fast for the PCE CPU. It would be good to see an actual supergrafx CD game. You could do a pretty good Super Street fighter 2 port especially with the arcade card but for sonic or even sonic CD I'm sure the super CD would be enough. With the arcade card you have to actually have something to put in the extra RAM.

[Steven Pendleton]

21 minutes ago, No One You Know said:

Is that by the guy that does all the PCE mini demos that has a blog and lives in Japan? I will have to look it up. I always thought it would be cool to see sonic CD on PCE CD too. You wouldn't have any problem with the music tune except for past stages, but as turbo X ray said MOD players can be done on PCE without using too much CPU time. I think the other reason talking about the supergrafx annoyed me is because it's not really a question of whether or not you could do it on supergrafx. I suppose the advantage the MD is meant to have over other things is loading tiles quickly but I'm sure sonic is not too fast for the PCE CPU. It would be good to see an actual supergrafx CD game. You could do a pretty good Super Street fighter 2 port especially with the arcade card but for sonic or even sonic CD I'm sure the super CD would be enough. With the arcade card you have to actually have something to put in the extra RAM.

I don't know who exactly did the PC Engine port of the 240p test suite, but it's here if you want it

 

http://junkerhq.net/xrgb/index.php?title=240p_test_suite#PC_Engine.2FTurbo_Grafx-16

 

By the way, this is what I meant when I said the 240p test suite parallax looks a bit weird on PC Engine

 

 

Anyway, yeah, I'm not sure what you could do with all of the extra RAM if you made it an Arcade Card game. Maybe you could use it to reduce slowdown or something like that since I think all 4/5 (depending on how you want to count them) of the original 16-bit Sonic games do have some slowdown in a few places, but I am not sure.

Edited September 3, 2020 by Steven Pendleton

[No One You Know]

5 minutes ago, Steven Pendleton said:

I don't know who exactly did the PC Engine port of the 240p test suite, but it's here if you want it

 

http://junkerhq.net/xrgb/index.php?title=240p_test_suite#PC_Engine.2FTurbo_Grafx-16

 

Anyway, yeah, I'm not sure what you could do with all of the extra RAM if you made it an Arcade Card game. Maybe you could use it to reduce slowdown or something like that since I think all 4/5 (depending on how you want to count them) of the original 16-bit Sonic games do have some slowdown in a few places, but I am not sure.

Reduce slowdown I suppose if that slowdown was caused by cartridge access. Wouldn't help to much other kinds of slowdown except in a few cases where you can get speed up from repeating lots of things - I suppose the actual programming can have long stretches of repeated functions where there would usually be a fixed loop which is a RAM eating technique to avoid the lost time in jumping backwards for a loop. I looked up the test suite on YouTube and saw it running on a Sony CRT (weird bending effect but that's just because it's a curved screen being filmed) and it was mainly just linescroll effects. Nothing overlaps other than with the plamtrees which can be added with sprites, so all of that would just be done by changing the scroll pointer after a certain line. You couldn't get away just with that if you wanted proper parallax whilst also having the landforms in the actual game but of course other PCE games have shown there are still other techniques you could use. Speaking of calibration after about 5 years I only just figured out that I needed to change the colour setting on the crappy ~15 year old LCD TV I use with my mega drive, PS2 and Dreamcast to stop it turning yellows orange all the time. Colours look washed out by comparison after turning it down but that's just because I'm used to the ridiculous oversaturation I had on the other setting where the ground below the grass on emerald hill zone is almost red and the wall in Bob omb battlefield on SM64 go solid orange at times. Everything looks quite clear when you have it turned all the way to zero so everything is black and white.

[turboxray]

On 8/31/2020 at 5:26 PM, No One You Know said:

Alright. Take a chill pill. No need to get offended. The idea of using two channels was to reduce CPU requirements. I didn't think of synchronisation but I still don't understand why that is a problem? As you said all channels are based on a base clock with a divider so wouldn't they all be synced when running at the same frequency? Changing waveforms for different parts of the ADSR cycle is useful for realistic sounds in a sample synth but it won't give you more detailed waveforms. I just added the 5 bit thing as a side note. I didn't think about it in detail and as you point out you are unlikely to need more in normal use when you only have 32 samples per waveform. You are going to be using a lowish frequency if you are sampling a full FM cycle in just a 32 sample wavetable. Only 24% CPU time for a MOD player? That impresses me. Maybe in game sample synth is more feasible than I used to think on this and the lynx. But with resampling? So you are changing the sampling frequency? What?

 

You say a channel can *cycle* through a set of waveforms independently? So in effect you have a longer than 32 sample (20 bytes) wavetable? That would be a game changer but I suspect you just worded it wrong.

I'm not offended haha. I just find the idea of why you would even do that as a little bit absurd, because you waste so much resource trying to reproduce a 64 sample waveform channel. 

 

(Just to note: you can't do the 64 sample waveform expansion like you described, to any arbitrary note frequency. It's not really practical or feasible)

 But 64 samples over 32 isn't going to net you much. Low frequency waveform updating approach is vastly cheaper cpu resource wise, doesn't waste a channel, and gets you far better capabilities than bumping up to 64 samples. Especially considering the 'attack' phase of an instrument is pretty important compared to a single unchanging timbre of a fixed tone with 32 or 64 sample waveform (disregarding the secondary effect of timbre changes in the sustain/release phase for bending/twang).

 

On the note of modeling 'realistic' instrument, that's not what it's about. It's about changing the characteristic sound of an instrument's note over time, like pretty much every synth in the world since they've been invited. That's it. Making that particular channel more versatile in sound capability. From the sound hardware perspective (disregarding cpu resource), the PCE only has 6 channels, so wasting a channel to pair in order to make a 64 sample cycle seriously hurts the overall/complete sound capability for literally nothing. By comparison (wasting a channel for an effect) you'll get more of an effect by simply pairing two channels and detuning one of them (which PCE games do). The PCE really should have had 8-10 channels for what it was doing/designed, so multiple pair could have been more prevalent. 6 channels basically puts you right at the minimum; 3 voice lead (or up to three chords), 1 voice rhythm, 1 voice bass, and 1 voice percussion - leaving sound effects to cut out one of those channels.

 

 The MOD thing. Well, it's more of a sample-synth driver in that you can interface with as if it were hardware, so any music engine can use it. I write a very simple MOD player to show off how to use the driver. As far as cpu resource, it should have been less than 24% but it has to deliver the samples to the channels via an interrupt service, so that over head factors in. It's not the amazing. I mean, all you are doing is using a fixed point counter (phase accumulator) to fetch samples for from memory (nearest neighbor scaling the frequency of the sample to a fixed output frequency). They're bytes. There's no software mixing or software volume. There's not need for it on the PCE since that hardware already exists. You just write straight to the channel port. The samples might be 5bit, but the volume is hardware (you would need 10bits of resolution, per channel, to emulate that in software). And it's in stereo. I implemented loop point support for samples too (it's forward looping, but ping-pong looping is easily done to the sample manually, externally modifying the sample). The loop points can exist anywhere in the sample, and takes up literally no cpu resource to do. I mean, this is a 7.16mhz CPU. This is a pretty easy task for the processor. Any channel can be used as sample-synth or normal channel, and changed on the fly. It doesn't restrict or reserve the channel.

 

By comparison, if you were to do a 4 sample-synth channels on a single 8bit DAC in software, each channel would only be 6bits resolution at max volume (otherwise volume is going to drop to 5bits, 4bits, 3bits, etc). The PCE can pair two channels to create perfect 10bit linear sample DAC (thanks to the hardware volume allowing this trick). You can soft mix multiple channels to a 10bit sample buffer and output that (albeit mono). Whether that's resampled-frequency or fixed frequency, that's up to how much you want to spend on cpu resouce. 

 

Quote

You say a channel can *cycle* through a set of waveforms independently? So in effect you have a longer than 32 sample (20 bytes) wavetable? That would be a game changer but I suspect you just worded it wrong.

Yes. Simply update the 32 byte waveform, regardless of the note frequency (independently). So can have longer than a 32byte waveform from the perspective that the instrument 'note' isn't limited to a single 32byte waveform, but you can't update it as soon as it's done playing a 32byte segment - at some arbitrary note frequency (you could do that with a fixed frequency that would align up with the timer interrupt, but then you lose ALL note frequency control - at that point it's just sample streaming, and each channel already has a mode for that - DDA). That in effect would be variable frequency sample streaming (aka Paula on the Amiga; the buffer empties, it fetches the next small 'group' of samples from memory - per channel basis). I'm talking about having a 1/60hz tick for a low frequency envelope (or whatever mechanism) that updates those 32bytes for that channel. Kind of like a scanline in HAM mode, but for audio. It's lossy, but it's better than no change at all.

 

What is your experience in audio hardware? Do you code music/sound engines? 

 

Quote

Reduce slowdown I suppose if that slowdown was caused by cartridge access. Wouldn't help to much other kinds of slowdown except in a few cases where you can get speed up from repeating lots of things - I suppose the actual programming can have long stretches of repeated functions where there would usually be a fixed loop which is a RAM eating technique to avoid the lost time in jumping backwards for a loop.

You mean loop unrolling. There's a lot more you can do with extra memory, especially ram, with 65x based processors that definitely speeds it up (in assembly, anyway). 

Edited September 5, 2020 by turboxray

[No One You Know]

4 hours ago, turboxray said:

I'm not offended haha. I just find the idea of why you would even do that as a little bit absurd, because you waste so much resource trying to reproduce a 64 sample waveform channel. 

 

(Just to note: you can't do the 64 sample waveform expansion like you described, to any arbitrary note frequency. It's not really practical or feasible)

 But 64 samples over 32 isn't going to net you much. Low frequency waveform updating approach is vastly cheaper cpu resource wise, doesn't waste a channel, and gets you far better capabilities than bumping up to 64 samples. Especially considering the 'attack' phase of an instrument is pretty important compared to a single unchanging timbre of a fixed tone with 32 or 64 sample waveform (disregarding the secondary effect of timbre changes in the sustain/release phase for bending/twang).

 

On the note of modeling 'realistic' instrument, that's not what it's about. It's about changing the characteristic sound of an instrument's note over time, like pretty much every synth in the world since they've been invited. That's it. Making that particular channel more versatile in sound capability. From the sound hardware perspective (disregarding cpu resource), the PCE only has 6 channels, so wasting a channel to pair in order to make a 64 sample cycle seriously hurts the overall/complete sound capability for literally nothing. By comparison (wasting a channel for an effect) you'll get more of an effect by simply pairing two channels and detuning one of them (which PCE games do). The PCE really should have had 8-10 channels for what it was doing/designed, so multiple pair could have been more prevalent. 6 channels basically puts you right at the minimum; 3 voice lead (or up to three chords), 1 voice rhythm, 1 voice bass, and 1 voice percussion - leaving sound effects to cut out one of those channels.

 

 The MOD thing. Well, it's more of a sample-synth driver in that you can interface with as if it were hardware, so any music engine can use it. I write a very simple MOD player to show off how to use the driver. As far as cpu resource, it should have been less than 24% but it has to deliver the samples to the channels via an interrupt service, so that over head factors in. It's not the amazing. I mean, all you are doing is using a fixed point counter (phase accumulator) to fetch samples for from memory (nearest neighbor scaling the frequency of the sample to a fixed output frequency). They're bytes. There's no software mixing or software volume. There's not need for it on the PCE since that hardware already exists. You just write straight to the channel port. The samples might be 5bit, but the volume is hardware (you would need 10bits of resolution, per channel, to emulate that in software). And it's in stereo. I implemented loop point support for samples too (it's forward looping, but ping-pong looping is easily done to the sample manually, externally modifying the sample). The loop points can exist anywhere in the sample, and takes up literally no cpu resource to do. I mean, this is a 7.16mhz CPU. This is a pretty easy task for the processor. Any channel can be used as sample-synth or normal channel, and changed on the fly. It doesn't restrict or reserve the channel.

 

By comparison, if you were to do a 4 sample-synth channels on a single 8bit DAC in software, each channel would only be 6bits resolution at max volume (otherwise volume is going to drop to 5bits, 4bits, 3bits, etc). The PCE can pair two channels to create perfect 10bit linear sample DAC (thanks to the hardware volume allowing this trick). You can soft mix multiple channels to a 10bit sample buffer and output that (albeit mono). Whether that's resampled-frequency or fixed frequency, that's up to how much you want to spend on cpu resouce. 

 

Yes. Simply update the 32 byte waveform, regardless of the note frequency (independently). So can have longer than a 32byte waveform from the perspective that the instrument 'note' isn't limited to a single 32byte waveform, but you can't update it as soon as it's done playing a 32byte segment - at some arbitrary note frequency (you could do that with a fixed frequency that would align up with the timer interrupt, but then you lose ALL note frequency control - at that point it's just sample streaming, and each channel already has a mode for that - DDA). That in effect would be variable frequency sample streaming (aka Paula on the Amiga; the buffer empties, it fetches the next small 'group' of samples from memory - per channel basis). I'm talking about having a 1/60hz tick for a low frequency envelope (or whatever mechanism) that updates those 32bytes for that channel. Kind of like a scanline in HAM mode, but for audio. It's lossy, but it's better than no change at all.

 

What is your experience in audio hardware? Do you code music/sound engines? 

 

You mean loop unrolling. There's a lot more you can do with extra memory, especially ram, with 65x based processors that definitely speeds it up (in assembly, anyway). 

Sorry. It's a bit hard to interpret expressions in text. Probably has gotten me into a lot of unnecessary arguments. Yeah the channel combining thing for 64 samples is pretty terrible. I was working under the assumption that you are not intervening with the CPU whatsoever, but considering the presence of DDA modes (so they are fixed frequency then in DDA mode?) for all or most of the channels, they must have expected you to do that frequently. So with regards to changing waveform with an envelope ("waveform cycling") you mean in software at a low frequency just to distinguish the attack timbre from the sustain timbre rather than extending the length of the repeated waveform? OK.

 

What do you mean? Samplers are certainly about realistic instrument sounds. I suppose, as you point out, all mixing is done in hardware as well as volume control for each channel so you are just copying data and not processing it other than resampling, so it shouldn't eat everything. I don't quite get your analogy to HAM mode. Do you mean changing colour palettes per scanline rather than HAM? I don't actually have any experience programming sound hardware yet (never will unless I actually get on with stuff) but I have always liked to read and think about it. Loop unrolling is the only thing I could think of other than page mode but I don't see how extra RAM would help you make any more use of that than normal. You don't have more separate RAM banks with separate buses like in a PC, nor could you even use that to speed up the CPU without a different, or help any of the other hardware with it.

[turboxray]

18 hours ago, No One You Know said:

Sorry. It's a bit hard to interpret expressions in text. Probably has gotten me into a lot of unnecessary arguments. Yeah the channel combining thing for 64 samples is pretty terrible. I was working under the assumption that you are not intervening with the CPU whatsoever, but considering the presence of DDA modes (so they are fixed frequency then in DDA mode?) for all or most of the channels, they must have expected you to do that frequently. So with regards to changing waveform with an envelope ("waveform cycling") you mean in software at a low frequency just to distinguish the attack timbre from the sustain timbre rather than extending the length of the repeated waveform? OK.

 

What do you mean? Samplers are certainly about realistic instrument sounds. I suppose, as you point out, all mixing is done in hardware as well as volume control for each channel so you are just copying data and not processing it other than resampling, so it shouldn't eat everything. I don't quite get your analogy to HAM mode. Do you mean changing colour palettes per scanline rather than HAM? I don't actually have any experience programming sound hardware yet (never will unless I actually get on with stuff) but I have always liked to read and think about it. Loop unrolling is the only thing I could think of other than page mode but I don't see how extra RAM would help you make any more use of that than normal. You don't have more separate RAM banks with separate buses like in a PC, nor could you even use that to speed up the CPU without a different, or help any of the other hardware with it.

So DDA mode isn't fixed in frequency per se (it's tied to the 3.57mhz divider), so it's as fast as you can write to the port.

Here's a really old example I made: 

 

It's lossy ADPCM so I could get it to fit on the SF2 mapper rom (2.5megabytes rom), but has examples of 20khz and 33khz DDA playback. That was recorded on a real white original model PCE (the low amplitude hum in the quiet parts is from the console and not sample output. The console was in bad shape and needed to be recapped).

 

Typically, most PCE samples are written to DDA ports at a rate of 7khz because that's the fastest timer resolution. You could use the scanline interrupt (it's generated for ALL scanlines, not just visible) for 15.7khz, but it has more overhead than the timer interrupt. You can use the timer interrupt to write two DDA updates every other interrupt call, given 9-10khz output. Doesn't sound like much, but depending on the sample's frequency characteristics, that can be a huge increase in quality. You also get a bit of free analog filtering starting at 7khz and up, which is nice for DDA sample output. Ideally though, you'd want a higher programmable timer interrupt circuit on a card/hucard (very doable and cheap). There is another methods of delivering samples, using the 32bytes as a 'buffer', but on the PCE it requires two channels (on the SGX it only requires one channel, because of the 'A' revision cpu). But this requires much more careful planning in relation to raster interrupts (scanline effects). Doable, but a more advance technique. The up side is that you can deliver something like 224khz samples using the 7khz update, or low cpu resource with something like 1.7khz updates for 56khz. If you 'interleaved' ever other sample, you get two sample channels (no independent volume though) at 28khz, or 4 sample channels at 14khz. 1.7khz to drive that means just 29 updates per frame. At that point, I would just tie it to the scanline interrupt system to keep things clean.

 

 About the waveform update, I compared it to HAM because in HAM mode you can only change one of three R/G/B values at a time (at whatever the clock tick is for 'copper'), so you get more colors per line but at the expensive of the image being lossy. The same is true for updating the waveform at low frequency - you're not limited to 32byte waveform for the whole 'note' because you can update it, but it's lossy in that the updates aren't done after every 32bytes being played. As as it turns out, that's not really an issue. So yes, the fidelity of the change isn't high res, like naturally occurring in FM, but the ear hears it none the less and recognizes the timbre change (and not as coarse steps).

 

 

Quote

Loop unrolling is the only thing I could think of other than page mode but I don't see how extra RAM would help you make any more use of that than normal. You don't have more separate RAM banks with separate buses like in a PC, nor could you even use that to speed up the CPU without a different, or help any of the other hardware with it.

 For one, ram means you can do self-modifying code. Not that means much by itself, because CD games for PCE can already do this VS hucard games (which has very little ram), but this is something you can layer on top of other exploits of larger memory access. I.e. you can't necessarily do this with just larger rom. Having more memory allows for more LUTs. Some LUTS are direct access (load from it) and others are implemented as a jump table. Small LUTs are the magic elixir of the 65x design. The indexing of any addressing mode is free on the 65x, and it's fast. You can do something like ldy table,x and then lda table2,y right after it. That's pretty powerful. The first table could be a shift table, and the table could be something like AND $xx and then add +2. I'm spending just a few cycles to access the table that would otherwise take a lot more cycles to implement with instructions. I mean, those tables can do pretty much anything - including multiplication, division, etc. Now if you look closely, if I were iterating over a range of linear memory, I would need to get a value into Y.. but there is no ldy (zp) address mode. With ram, I make that ldy addr and use self modifying code to increment 'addr'. More memory in general allows the 65x design to take advantage of exploits, and when it's ram, it allows a layer of self-modifying optimizations to be applied on top of it. My 'mod' driver sits in ram because it uses self modifying code. The DDA timer routine sits in ram because of this as well. When I write raster interrupt routines, the first half is in ram for some self modified optimizations. I have a custom divide by 3, 5, 24 etc routines that can perform a 16bit value divided by any of those constants in just 40 cycles (50 if you want the remainder). Those each of those constants take about 4k of space for the special tables. And in the context of Sonic, the game is decompression stuff in real time for the maps and such. Decompression isn't free. Having lots of memory means direct access which is the fastest method. Having lots of memory means you can tailor wasteful but fast data structures to the 65x design. And lastly, the fastest way to update tile/sprite cells to vram on the PCE (actually any vram data to the VDC), is by embedding graphics as ST1/ST2 opcodes. It gives a huge boost in transfer bandwidth. More memory allows the opportunity to embedded more frames/cells in this format, ram as allows you to make that dynamic (which also goes into a whole nother level of tricks for the VDC, including dynamic tiles for parallax). I'm being too general here because the optimizations for lots of ram are very specific to what you're trying to speed up, so I would have to go into specific details and that's beyond the scope of this post. Some of the optimizations are because of 'extra ram', but most are simply because it's 'extra memory' - the arcade card is both.

 

 

 

 

 

 

 

 

 

Edited September 6, 2020 by turboxray

[No One You Know]

19 hours ago, turboxray said:

So DDA mode isn't fixed in frequency per se (it's tied to the 3.57mhz divider), so it's as fast as you can write to the port.

Here's a really old example I made: 

 

It's lossy ADPCM so I could get it to fit on the SF2 mapper rom (2.5megabytes rom), but has examples of 20khz and 33khz DDA playback. That was recorded on a real white original model PCE (the low amplitude hum in the quiet parts is from the console and not sample output. The console was in bad shape and needed to be recapped).

 

Typically, most PCE samples are written to DDA ports at a rate of 7khz because that's the fastest timer resolution. You could use the scanline interrupt (it's generated for ALL scanlines, not just visible) for 15.7khz, but it has more overhead than the timer interrupt. You can use the timer interrupt to write two DDA updates every other interrupt call, given 9-10khz output. Doesn't sound like much, but depending on the sample's frequency characteristics, that can be a huge increase in quality. You also get a bit of free analog filtering starting at 7khz and up, which is nice for DDA sample output. Ideally though, you'd want a higher programmable timer interrupt circuit on a card/hucard (very doable and cheap). There is another methods of delivering samples, using the 32bytes as a 'buffer', but on the PCE it requires two channels (on the SGX it only requires one channel, because of the 'A' revision cpu). But this requires much more careful planning in relation to raster interrupts (scanline effects). Doable, but a more advance technique. The up side is that you can deliver something like 224khz samples using the 7khz update, or low cpu resource with something like 1.7khz updates for 56khz. If you 'interleaved' ever other sample, you get two sample channels (no independent volume though) at 28khz, or 4 sample channels at 14khz. 1.7khz to drive that means just 29 updates per frame. At that point, I would just tie it to the scanline interrupt system to keep things clean.

 

 About the waveform update, I compared it to HAM because in HAM mode you can only change one of three R/G/B values at a time (at whatever the clock tick is for 'copper'), so you get more colors per line but at the expensive of the image being lossy. The same is true for updating the waveform at low frequency - you're not limited to 32byte waveform for the whole 'note' because you can update it, but it's lossy in that the updates aren't done after every 32bytes being played. As as it turns out, that's not really an issue. So yes, the fidelity of the change isn't high res, like naturally occurring in FM, but the ear hears it none the less and recognizes the timbre change (and not as coarse steps).

 

 

 For one, ram means you can do self-modifying code. Not that means much by itself, because CD games for PCE can already do this VS hucard games (which has very little ram), but this is something you can layer on top of other exploits of larger memory access. I.e. you can't necessarily do this with just larger rom. Having more memory allows for more LUTs. Some LUTS are direct access (load from it) and others are implemented as a jump table. Small LUTs are the magic elixir of the 65x design. The indexing of any addressing mode is free on the 65x, and it's fast. You can do something like ldy table,x and then lda table2,y right after it. That's pretty powerful. The first table could be a shift table, and the table could be something like AND $xx and then add +2. I'm spending just a few cycles to access the table that would otherwise take a lot more cycles to implement with instructions. I mean, those tables can do pretty much anything - including multiplication, division, etc. Now if you look closely, if I were iterating over a range of linear memory, I would need to get a value into Y.. but there is no ldy (zp) address mode. With ram, I make that ldy addr and use self modifying code to increment 'addr'. More memory in general allows the 65x design to take advantage of exploits, and when it's ram, it allows a layer of self-modifying optimizations to be applied on top of it. My 'mod' driver sits in ram because it uses self modifying code. The DDA timer routine sits in ram because of this as well. When I write raster interrupt routines, the first half is in ram for some self modified optimizations. I have a custom divide by 3, 5, 24 etc routines that can perform a 16bit value divided by any of those constants in just 40 cycles (50 if you want the remainder). Those each of those constants take about 4k of space for the special tables. And in the context of Sonic, the game is decompression stuff in real time for the maps and such. Decompression isn't free. Having lots of memory means direct access which is the fastest method. Having lots of memory means you can tailor wasteful but fast data structures to the 65x design. And lastly, the fastest way to update tile/sprite cells to vram on the PCE (actually any vram data to the VDC), is by embedding graphics as ST1/ST2 opcodes. It gives a huge boost in transfer bandwidth. More memory allows the opportunity to embedded more frames/cells in this format, ram as allows you to make that dynamic (which also goes into a whole nother level of tricks for the VDC, including dynamic tiles for parallax). I'm being too general here because the optimizations for lots of ram are very specific to what you're trying to speed up, so I would have to go into specific details and that's beyond the scope of this post. Some of the optimizations are because of 'extra ram', but most are simply because it's 'extra memory' - the arcade card is both.

 

 

 

 

 

 

 

 

 

That MOD sounds almost like a real performance. Actually it is one long recording of a real performance isn't it. Wow. So why do you need to resample if you can write to each DDA channel at any rate? You are not mixing into one channel. I never thought of cards containing interrupt generators before. So when you are updating the wavetables on the fly, you are updating one channel whilst the other begins to play and then the other whilst the first one plays? So you can make it so that each channel goes silent or do they play each waveform twice? What is different in the supergrafx that lets you use only one channel?

 

I thought that HAM was its own background image mode rather than a copper operation? I'm fairly sure it is. So you are just comparing it to HAM because it is lossy? I would have said that HAM was more analogous to DPCM though the numbers themselves in HAM aren't differential but you are still taking the previous signal and modifying it rather than getting a new one. Changing the waveform periodically I would have thought is more like palette swapping. Oh yes, I suppose low frequency updates more frequently than changes for attack, sustain and decay would probably be enough for the lower frequency FM operations that I was thinking of before.

 

About the program optimizations with lots of RAM, you point out a lot of things that I didn't think of but don't really have anything to say about other than agree. Thanks<

[turboxray]

1 hour ago, No One You Know said:

That MOD sounds almost like a real performance. Actually it is one long recording of a real performance isn't it. Wow. So why do you need to resample if you can write to each DDA channel at any rate? You are not mixing into one channel. I never thought of cards containing interrupt generators before. So when you are updating the wavetables on the fly, you are updating one channel whilst the other begins to play and then the other whilst the first one plays? So you can make it so that each channel goes silent or do they play each waveform twice? What is different in the supergrafx that lets you use only one channel?

 

I thought that HAM was its own background image mode rather than a copper operation? I'm fairly sure it is. So you are just comparing it to HAM because it is lossy? I would have said that HAM was more analogous to DPCM though the numbers themselves in HAM aren't differential but you are still taking the previous signal and modifying it rather than getting a new one. Changing the waveform periodically I would have thought is more like palette swapping. Oh yes, I suppose low frequency updates more frequently than changes for attack, sustain and decay would probably be enough for the lower frequency FM operations that I was thinking of before.

 

About the program optimizations with lots of RAM, you point out a lot of things that I didn't think of but don't really have anything to say about other than agree. Thanks<

Ohh.. no that video is definitely not a MOD. It's just an example of sample streaming to DDA port at different frequencies (and showing off 10bit audio). The thing about the PCE needing two channels VS the SGX, is that there's a bug in the original audio unit where if you turn on/off a channel then you get a small 'pop' on that channel's output. The 'pop' is directional (turning off the volume, means the pop is negative amplitude spike, and positive for turning on). So if you used a single channel to refill, you'd get an audible buzz on the channel at high frequencies, and clicking at low frequencies. Turning off one channel and turning on another, in the original PCE, cancels out the 'pop' - thus the need for two channels. The SGX fixed this and doesn't need it. But the whole point, is given a fixed frequency - you can treat the 32bytes as a buffer for sample streaming. But yeah, the mod driver I have runs at 7khz output and no where near that quality of the ADPCM demo haha. It's possible to run it at higher rate, but it takes more cpu resource. I wrote the driver to augment the PCE's sound, not replace it with 'mod' music. Matter of fact, I also wrote a driver that does 4 channel at 8bit samples (and software volume) to a 10bit output - two of the channels are frequency scaled and the other two are fixed frequency. It takes two normal channels for paired DDA to do this, but it's better option because the samples are higher resolution but you also get more channels (I also have a 6 channel version; 2 scaled and 4 fixed) - the sound is mono for the samples but it gives you a total count of 8 or 10 sounds channels on the PCE.  Just as a comparison though, the GBA does samplebased-synth in software as well. Most early drivers are 9-10khz with a 9bit DAC output.

 

Quote

So why do you need to resample if you can write to each DDA channel at any rate?

Good question. That's because I don't have four independent interrupt timers to update each channel. I either use the 7khz timer interrupt, or the display's 15.7khz interrupt, for all channels. Since it's one interrupt period system for all channels to be updated, I have to manually scale the frequencies for each channel. Given that the sound chip is on the same chip as the CPU, and the cpu has 21bit addressing, they could have simply made it so that the sound chip fetches from rom itself. That would have been a game changer. But the PCE's design is; clean and fast. No shoe horning in odd features or requirements to get things done. It's a straight forward approach and does it fast. 

[Punisher5.0]

This demo has been recently updated to include sound effects. Still no boss but when you get to the area it locks you in like the original. 

[Leeroy ST]

On 9/15/2020 at 8:47 PM, Punisher5.0 said:

This demo has been recently updated to include sound effects. Still no boss but when you get to the area it locks you in like the original. 

Good progress so far. Was waiting on the sound effects.

[No One You Know]

On 9/7/2020 at 6:34 PM, turboxray said:

Ohh.. no that video is definitely not a MOD. It's just an example of sample streaming to DDA port at different frequencies (and showing off 10bit audio). The thing about the PCE needing two channels VS the SGX, is that there's a bug in the original audio unit where if you turn on/off a channel then you get a small 'pop' on that channel's output. The 'pop' is directional (turning off the volume, means the pop is negative amplitude spike, and positive for turning on). So if you used a single channel to refill, you'd get an audible buzz on the channel at high frequencies, and clicking at low frequencies. Turning off one channel and turning on another, in the original PCE, cancels out the 'pop' - thus the need for two channels. The SGX fixed this and doesn't need it. But the whole point, is given a fixed frequency - you can treat the 32bytes as a buffer for sample streaming. But yeah, the mod driver I have runs at 7khz output and no where near that quality of the ADPCM demo haha. It's possible to run it at higher rate, but it takes more cpu resource. I wrote the driver to augment the PCE's sound, not replace it with 'mod' music. Matter of fact, I also wrote a driver that does 4 channel at 8bit samples (and software volume) to a 10bit output - two of the channels are frequency scaled and the other two are fixed frequency. It takes two normal channels for paired DDA to do this, but it's better option because the samples are higher resolution but you also get more channels (I also have a 6 channel version; 2 scaled and 4 fixed) - the sound is mono for the samples but it gives you a total count of 8 or 10 sounds channels on the PCE.  Just as a comparison though, the GBA does samplebased-synth in software as well. Most early drivers are 9-10khz with a 9bit DAC output.

 

Good question. That's because I don't have four independent interrupt timers to update each channel. I either use the 7khz timer interrupt, or the display's 15.7khz interrupt, for all channels. Since it's one interrupt period system for all channels to be updated, I have to manually scale the frequencies for each channel. Given that the sound chip is on the same chip as the CPU, and the cpu has 21bit addressing, they could have simply made it so that the sound chip fetches from rom itself. That would have been a game changer. But the PCE's design is; clean and fast. No shoe horning in odd features or requirements to get things done. It's a straight forward approach and does it fast. 

Sorry for the late response. Thanks for explaining all of that! I don't think i have any questions now other than your mod driver does mixing too? Yeah GBA stuff usually doesn't sound great but a lot of the time that is probably just low quality samples. The Acorn Archimedes also does software sound (and software graphics drawing too, but it is pretty much the only machine of the time with a fast enough CPU to get away with that with good results) but it has hardware 8 channel mixing (logarithmic which i don't understand yet).

[johannesmutlu]

Yeah sonic the hedge hog demo on snes is pretty impressive(sadly i only got the version without those sound effects for wich i do that also exists),

but i sometimes do wonder if it does make much sense whether system you own either in handheld or console variant of it,

sure the snes has a 16bit cpu but it only runs at 3,5mhz it also has to deal with Dram in it’s cpu ,

the pc engine/TG16 only contains an 8bit cpu but it has Sram in it’s cpu and it runs at a whopping 7,9mhz ,

it also has only 1 background layer BUT with tricks such as rraltime tile updates,a combination of sprites  and parallax scrolling effects,extra backgrounds can be faked,

the sega genesis does have a fast 16bit cou at 7,9mhz with sram in it ,but it needs 2 cycles to execute instructions,but it is still faster then the snes,

also the genesis can only view 64 colors atonce BUT with shadowing mode,you can have more colors on screen,

also the genesis can have aside from FM sound also full digital sound trough software mixing via it’s 8bit dac and you can use the psg chip to get 1bit pcm as a bonus,

while the snes does have 4 background layers,BUT it can be only used at mode 0 with limited colors

and while the snes does have full digital sound support,but sadly most games did not use sound swapping,instead they used cut down and stretched samples to save on memory space resulting in dry audio,also the snes only has access to more memory in lorom mode while in hirom it has access to limited momery,and for extra hirom memory you probably do need bankswitching to get around that,

So each system has their own strength & weaknesses BUT with cool hardware & programming tricks you can get the most out of those systems to get them equally more closer to each other along with certain games?

Edited August 7, 2022 by johannesmutlu