CC65 and the PCE

[spenoza]

Squirrel would have to be re-diddled for CC65 at some point, assuming it's usage takes off.  Without Squirrel, basically any compiler is useless to me.

I know Squirrel is your baby and caters to your musical strengths, but with all the potential audio engine options on the horizon, it might be worth seeing if you can adapt the MML format to other engines to share some of the MML love.

[Arkhan]

Squirrel would have to be re-diddled for CC65 at some point, assuming it's usage takes off.  Without Squirrel, basically any compiler is useless to me.

I know Squirrel is your baby and caters to your musical strengths, but with all the potential audio engine options on the horizon, it might be worth seeing if you can adapt the MML format to other engines to share some of the MML love.

There aren't many potential options on the horizon.   Isn't there just HuSound?   The way it expects things does not lend itself well to MML.    Writing an MML compiler that produces output for HuSound is a bit of a waste of time. 

Especially because HuSound doesn't have a CC65 thing yet either, does it?

So really, any sound library needs CC65'd.

Squirrel was designed to adhere to MML standards and be inline with how commercial software at the time (and now, on MSX) is done.     I don't see a reason to forego that. 

The people that are using other engines are probably using it because they don't like MML.   Providing them MML options don't help them.

[spenoza]

There aren't many potential options on the horizon.   Isn't there just HuSound?
...
The people that are using other engines are probably using it because they don't like MML.   Providing them MML options don't help them.

Sounds like Bonknuts is cooking something up to pair with his 4-channel MOD engine, so that's 2 options (or one compound option) right there. But yeah, your point is taken. You're probably right.

[Bonknuts]

There are many reasons people make their own sound engines, regardless of the higher level format that gets compiled down (MML or not). Usually academic or research/experience, but sometimes other specific reasons (capabilities that doesn't exist in other engines, or resource issues, etc).

Sounds like Bonknuts is cooking something up to pair with his 4-channel MOD engine

My sound engines are just a proof of concept thing, because in all reality no one will probably use it.
Most people don't use other people stuffs in this scene (or even in other console homebrew scenes). And my sound engines also alienates the PCE style of sound by doing something completely different with it, which isn't always popular with chiptunists (it doesn't follow that true PCE sound). I currently don't have an MCU or arduino setup at the moment to play with, so the PCE tends to get some of that stuff that I would probably/normally do for that. But I'm fine with that.

 Tailchao is probably doing his own engine so he has complete control over all variables that go into resource management of it, as well as any distinct features he wants to use. Writing a script compiler is less work than writing a music engine from scratch (although you'll still hear me complain about the script compiler thing). I'm sure he's capable of writing one. As for me, I already have a simple script compiler that I can rework.

 

There aren't many potential options on the horizon. 

 There isn't. Everyone is just doing their own thing. Mooz has a sound engine (based on deflemask format, IIRC). I have two that are fully completed (a tracker/hybrid one, and the full working AirZonk one), and a third one that works/near complete (90% mod FX compatibility and full tracker format). Tailchao has one. DamageX guy with the Phantasy Star PCE demo has sound engine. I'm sure there are others. I tried to pimp out one of mine to chip tuners and what I got back was; no tracker interface, then not really interested. So I started working on an XM to PCE converter, so people could prototype and build the song in milkytracker, and have it play near identical on the PCE. But then I was like.. eh, f*ck it - it's a lot of work and people probably still won't use it. I watched thefox make an awesome tracker for the NES, with some great example songs, and then no one used it. Actually, there are a lot of custom made sound engines in the NESdev scene - made just for the devs themselves because no one bothers sharing stuff that they know no one will bother to use. Everyone would rather just re-invent the wheel (which I can relate to), rather than take the time to alter someone else's design. Famitracker supposedly offers quite a bit, but devs still complain about it and end up writing their own.

 That said, I'd like to see squirrel with ADPCM and/or Timer interrupt sample support - if you guys ever get around to it.

[elmer]

There isn't. Everyone is just doing their own thing. Mooz has a sound engine (based on deflemask format, IIRC). I have two that are fully completed (a tracker/hybrid one, and the full working AirZonk one), and a third one that works/near complete (90% mod FX compatibility and full tracker format). Tailchao has one. DamageX guy with the Phantasy Star PCE demo has sound engine. I'm sure there are others. I tried to pimp out one of mine to chip tuners and what I got back was; no tracker interface, then not really interested. So I started working on an XM to PCE converter, so people could prototype and build the song in milkytracker, and have it play near identical on the PCE. But then I was like.. eh, f*ck it - it's a lot of work and people probably still won't use it. I watched thefox make an awesome tracker for the NES, with some great example songs, and then no one used it. Actually, there are a lot of custom made sound engines in the NESdev scene - made just for the devs themselves because no one bothers sharing stuff that they know no one will bother to use.

IMHO, it's not that difficult to write a basic sound engine and, as you point out, everyone-and-his-dog has done so.

It's one of those fun projects for a programmer to do, with quick feedback (i.e. it makes noises), and it's also easy to convert a simple MIDI tune into something that you can experiment with.

What you've been doing with your custom sample-playback engines is very unusual for the platform, and a giant leap beyond most people's experiments, but, as you say, the real trick is in getting a musician to want to use it.

Back-in-the-day a lot of the early musicians wrote their own sound drivers, because that was easier than explaining it all to someone else, and it gave them perfect control of how to make their own music.

But almost nobody wants to do that anymore, with TailChao being one of the very-few exceptions.

It'll be interesting to see if any of the other musicians here downloads HuSound and tries to use it to make a tune.

Even though I don't personally love MML as a concept, what Arkhan has done really well with Squirrel is to make it easy-ish for musicians to get good sound out of a PCE, without needing to deal with a programmer. That's great!

Deflemask seems to be the current-standard of the Tracker-interface version of the same idea.

With Mooz's player ...

https://github.com/BlockoS/dmf-player

And at-least-some interested PC Engine Deflemask users ...

http://www.delek.com.ar/forum/deflemask/pc-engine-instruments-and-wavetables-pack!!/

Then perhaps that will be another alternative for people.

Everyone would rather just re-invent the wheel (which I can relate to), rather than take the time to alter someone else's design. Famitracker supposedly offers quite a bit, but devs still complain about it and end up writing their own.

I'm waaaayyy passed that stage myself. I've written sound engines in the past, but I've been using other-people's engines for years.

That's precisely because I've found it to be the best way to actually get a musician to write good music. Folks want things to be "musician-friendly", and most programmer-designed sound engines just don't pass that test.

That said, I'd like to see squirrel with ADPCM and/or Timer interrupt sample support - if you guys ever get around to it.

Me, too. IMHO, any PCE sound engine needs to support at-least-one sample-playback channel.

I'd also like to see Arkhan being a little less "precious" with the licensing terms ... but that's already been mentioned. At the end of the day, it's his toy, and he gets to decide how other people can play with it.

[TheOldMan]

That said, I'd like to see squirrel with ADPCM and/or Timer interrupt sample support - if you guys ever get around to it.

Me, too. IMHO, any PCE sound engine needs to support at-least-one sample-playback channel.

Why? I don't understand......?
You can use the 5-bit stuff (re-loading the waveforms) to do some neat things. If you play with it a bit...
I just don't understand how changing the sound engine helps anything. The point behind squirrel (which, once again, is the MML compiler and *not* the assembler playback engine) was to make it possible to create sound that was system card compatible. You can swap your program  to cd, and have it play the same. So you can develop your music (or whatever) on a card image (in an emulator) and drop it into a cd-image.

If I have to use system card memory to hold a player -that's already in the bios-, I'd use a custom engine, too.
So when will it be available for general use, bonknuts? And what kind of resources does it us? (we already know about the cpu time.) How is it on memory? especially the zp space?
[ Don't take that the wrong way. It's -not- a dig; it's a serious question. I'd like to see what it can do, especially the adpcm stuff....]

[TailChao]

Tailchao is probably doing his own engine so he has complete control over all variables that go into resource management of it, as well as any distinct features he wants to use.

Actually, the whole reason I wrote HuSound was to force myself to start writing (NULL == pValue) instead of (pValue == NULL) before starting a new job.

Although yes, it is partially a resource management thing. The driver and toolset are a complete overkill for what most games need. But I think it's easier to take extra features out later on rather than have to jam them in near ship time. The composer can do whatever they want and we put off optimization until later.

It's one of those fun projects for a programmer to do, with quick feedback (i.e. it makes noises), and it's also easy to convert a simple MIDI tune into something that you can experiment with.

Absolutely. It's also a great way to learn about music if you're not a composer. I usually just make the characters move.

[TheOldMan]

... to force myself to start writing (NULL == pValue) instead of (pValue == NULL)

Won't they let you do just (pvalue) for checks??
wow....

[Bonknuts]

That said, I'd like to see squirrel with ADPCM and/or Timer interrupt sample support - if you guys ever get around to it.

Me, too. IMHO, any PCE sound engine needs to support at-least-one sample-playback channel.

Why? I don't understand......?
You can use the 5-bit stuff (re-loading the waveforms) to do some neat things. If you play with it a bit...
I just don't understand how changing the sound engine helps anything. The point behind squirrel (which, once again, is the MML compiler and *not* the assembler playback engine) was to make it possible to create sound that was system card compatible. You can swap your program  to cd, and have it play the same. So you can develop your music (or whatever) on a card image (in an emulator) and drop it into a cd-image.

If I have to use system card memory to hold a player -that's already in the bios-, I'd use a custom engine, too.

 For me, it's because samples have always been part of that staple PCE sound. They were used in a lot of games. Devil's Crush uses up to three sample streams at a time for some parts. Batman on the PCE has a really nice punch to the bass guitar because of samples (as well as the orchestra hit). Bonk's drumskit, Blazing Lazers drumkits, etc.

 You guys obviously know a lot more about the BIOS player than I do. But I do remember looking at games that did ADPCM drumkits/etc and IIRC they used kind of a hacked way going about it. As in another engine running at the same time (in sync), just for the sample side of things. Does this sound familiar? It's possible other ADPCM+PSG usage in CD games made their sound engine, bypassing the BIOS player. Either way, sounds like a pain - running a hack/hook mini engine to run along side of it, or making a new but compatible sound engine with TIMER and/or ADPCM support.

So when will it be available for general use, bonknuts?

I'm working on a few different audio projects, so I'm going to assume you mean the MOD-ish type player. And the first engine at that (not the 8 channel PCM player with higher bit depth).

 Just to be clear, it's sound driver not a music engine. The driver is finished, and that includes the interfacing support for it as well; all the calls needed to load, stop, start, resume, set frequency, etc. The driver package itself will be public this month (I need to comb over the source remove any unnecessary stuff). I plan to write a tiny music engine to show it off (how to use it, etc). And that's planned for this month. But the simple example music engine is not the point and not really for distribution (though I don't care what people do with it).

And what kind of resources does it us? (we already know about the cpu time.) How is it on memory? especially the zp space?

 It uses 3 bytes of ZP space. I guess I should reduce that to 1 byte, and just push $00/$01 on the stack for the interface calls. So.. 1 byte of ZP space. CPU resource is light for the interfacing code. All changes are buffered and applied during a vblank call (the user calls this, not an automatic thing unless the user puts the call inside the vblank routine). This is needed because the TIMER routine is constantly using the PSG regs and you would have a conflict if code outside of the interrupt routine tried to update other PSG regs. Thus the need for buffering. Though that's the issue with any music engine and using the TIMER interrupt for DDA playback.

 As far as cpu resource, disabling a channel for PCM output (making it free for normal use) reduces the cpu resource from 5.7% down to 0.4%. The last two channels, of the 6 total PCM streaming, take up 3.4% for PCM streaming per channel because they are fixed frequency, and they're also at a state of 0.4% cpu resource when not used. The TIMER interrupt overhead itself takes up 6.8% cpu resource regardless if any channels are playing or not. The TIMER interrupt routine immediately enables interrupts so as not to stall the VDC interrupt service. Depending on the length of the VDC interrupt routine, as well as the number of instances, will result in jitter in PCM playback. A tight VDC routine is preferred, but not required. The PCM driver sets a flag during its call to prevent multiple instances from happening if for some reason it didn't finish the routine in time. Also, no banks needs to be permanently mapped for this routine to run. I figured flexibility was worth more than saving a handful few cycles per call.

 It uses ~660bytes of system/ram memory and that includes the driver that needs to sit in ram. It needs 768bytes for the frequency look up table (sits in rom). And about 2k for the interfacing library (rom).

 It's not extreme or drastic, or convoluted/complex in its interface into an another design/layout (game/etc). It's flexible in the number of channels a user can allocate/configure for PCM streaming, gaining back cpu resource for less channel usage. It's simple and realistic. It's not going to break down doors or win sound innovation of the year for retro systems, and it does have some limitations in relation to quality (low bitrate, low frequency output), but it does allow some expansion on the PCE's sound capabilities. For me, that's exciting.

[ Don't take that the wrong way. It's -not- a dig; it's a serious question. I'd like to see what it can do, especially the adpcm stuff....]

No worries I already have the ADPCM routine adapted to the VDC interrupt call (it runs out of there), and I think it was something like 50% cpu resource for decompressing to 10bit output (clipped from 13bit) @ 15.3khz (bound at 256 samples per 1/60 frame to keep things fast ). The interesting part will be preping the audio stream, before compression, to see what kind of quality can be achieved. Anything above 7khz with PCE audio circuit, and filter effects starts to kick in. So it should sound a little smoother than the hardware ADPCM in the CD unit (which is pretty sharp sounding), even though they both output to a 10bit DAC. I've already have a clear idea of how to show it off. It'll be interesting to see how it works out.

[elmer]

Actually, the whole reason I wrote HuSound was to force myself to start writing (NULL == pValue) instead of (pValue == NULL) before starting a new job.

Hahaha ... the joys of "other people's" coding standards. 

I know that "(NULL == pValue)" is supposed to be "good" practice, but I just don't like the look.

I get bitten by the "(pValue = NULL)" bug once or twice a year, but it doesn't take long to find, and is a price that I'm personally willing to pay to not have to mentally deal with reading "reverse-polish" in my C source.

I don't like the old-school "(pvalue)" much, mostly because it gets really ugly (to me) once you start doing things like "(!pStruct || pStruct->mFlag)" ... which is the kind of test I'd rather see written out in long form to make it easier to read.

IMHO ... the "bug-fixing", "maintenance" and "reusability" phases of the life of a piece of source code all take a lot more time than what is saved by skipping a few keystrokes during the "initial coding" phase ... so "readability" is very high on my list of virtues in a programmer.

Of course, that comes from working on multi-programmer codebases that evolve over years of different projects.  Like most people, I'm often a bit sloppier when it comes to my own quick-hack utilites.

I just don't understand how changing the sound engine helps anything. The point behind squirrel (which, once again, is the MML compiler and *not* the assembler playback engine) was to make it possible to create sound that was system card compatible.

Thanks for clearing up the distinction between the compiler and the driver ... I keep on mixing them up. 

It's a great thing to have that System Card compatibility, but IMHO the real question is where you go next.

When the first PCE CD unit came out with only 64KB RAM, it made some sense to have a sound driver in the System Card ROM (although a complete generation of 64KB-or-less 8-bit home computers managed without one).

Once you've got the 256KB of a Super System Card, it makes a lot less sense to be limited by the capabilities of the old driver, just "because-it's-there".

Instead, developers start to want to enhance their games with at-least-some sample-playback, either for instruments, or sound-effects, or speech.

As Bonknuts said, a number of games seem to have done that by using some really ugly hacks while still running original System Card driver. That complicates both the code and the creation of the original music, just to save the few KB needed to put in a new driver.

IMHO, that's not a great choice ... but then Japanese culture is very different to Western culture.

These days, since you guys at AetherByte now have your own source for both the "compiler" and the "playback" side of things, I hope that you guys would want to push things forwards a bit and make some improvements.

Perhaps Bonknuts' core sound driver matched with your higher-level compiled-MML will be a way to do that. 

[TheOldMan]

I know that "(NULL == pValue)" is supposed to be "good" practice, but I just don't like the look.

I get bitten by the "(pValue = NULL)" bug once or twice a year, but it doesn't take long to find, and is a price that I'm personally willing to pay to not have to mentally deal with reading "reverse-polish" in my C source.

Yeah, I don't like the 'reverse polish' notation either. To my mind, I'm comparing a variable to a value - not the other way around.
And just by habit from long ago, my code is littered with  if( cptr == (char *) NULL)... I know it's not needed (but I have a few funny stories about people who thought that and took it out, only to find out it really was needed sometimes), but it helps get around some type-checking warnings.

These days, since you guys at AetherByte now have your own source for both the "compiler" and the "playback" side of things, I hope that you guys would want to push things forwards a bit and make some improvements.

The compiler code, yes.
AFAIK, the player code is still copyright NEC. That's why we aren't changing it, and why we can't license it like people keep asking. As for the licensing terms, that all because Arkhan wants to know who's actually using it - I don't think he's ever told anyone they can't, or had to pay royalties.

Perhaps Bonknuts' core sound driver matched with your higher-level compiled-MML will be a way to do that. 

I would love that. But I'm not sure a compiler-type program would do it. I'd have to see what the driver supports/does. It is a good idea, if it will work...

(I'd like to have a choice of drivers built into a bios image even better. )

[MooZ]

Just a side note : the PC Engine Deflemask player thingie is far from being usable

[Arkhan]

You can fake samples with Squirrel if you convert them to 32 byte waves and cycle them quickly.   I had it doing something at one point.   There's enough space in the "custom waves" area above the presets that you can fit a few samples in.

But again, the real purpose of Squirrel (the MML compiler), was the following:

[uldecimal][li]To properly make use of the already existing sound engine built into the CD hardware since they were nice enough to put the damn thing there for us.[/li][li]To be damn near identical to how things are being done commercially still on the MSX, which is currently the most active old-hardware-game-producing-scene in existence. I worked closely with some MSX friends on some of the MML ideas that made it into Squirrel.   They approved. 

On that note, the Develo stuff basically mentions and includes MML stuff too.  It's clear that is what was meant to be done with it.[/li][li]To provide a fast, easy, headacheless way to produce sound effects and music in a game.  See: Atlantean[/li][/ul]

I am more about functionality than anything.   The player was already sitting there.  IIRC, there is sample support that could be hooked in.  The one doc mentions it.

I could look into it more at some point.  But, I am pretty comfortable with my thumpy kick drum I made without samples, and the snare is pretty cool too, so I was never really itching to use samples.   Lots of high end commercial games don't use samples either.  Some do, some don't.  It's a style thing.

We also just recreated the sound engine for HuCards and removed the necessity of the PSG-BIOS stuff.

But, the ultimately useful thing that Squirrel allows for is flexibility and portability.

Flexibility:
Insanity's soundtrack features CD and chiptunes.   They are generated from the same thing.  I wrote the songs once.  I used a professional music editing program, spit out midis, used 3MLE, and hand tweaked the MML.   There's a video on YouTube demonstrating it.   This workflow is arguably better.  You get to use a modern DAW and all of it's nice features (that people would've killed for back then), and can then produce a file that plays on the PCE with minimal effort.   Slap your VSTs ontop, and now your CD soundtrack is done too.  Just export some .wav files...

Portability:
Songs for Inferno (MSX game I am making) were originally PCE tunes.  I copy pasted the MML into an MSX file and pressed about 4 buttons on my keyboard, and now they're MSX tunes instead.


I like this.

I also like using 3MLE to edit MML and have a visual (piano roll) representation.   There are already existing editors out there for music.   No point reinventing things.   I prefer leveraging stuff that already works, so I can get to the whole "making a game" thing faster.

As for licensing, it's more a matter of "credit us for making your life easier" and "toss us a freebie of a game if you start selling them."

That's about it.

Well, that, and "don't modify the flying piss out of everything", because then it probably won't actually work like it's supposed to, and because we technically jacked things from NEC as OldMan mentioned.

[Pokun]

[uldecimal][li]To properly make use of the already existing sound engine built into the CD hardware since they were nice enough to put the damn thing there for us.[/li][/ul]

I've been wondering about this. Is it a sound engine from the CD cards that can be used by CD games, and stripped down so that HuCard games can use it too? Or is it from some kind of devkit library?
The Squirrel readme mentions Hu7/Develo.

[elmer]

I've been wondering about this. Is it a sound engine from the CD cards that can be used by CD games, and stripped down so that HuCard games can use it too?

The System Card (version 1, 2 and 3) contains what the official documentation calls a "PSG Driver". That's also commonly known as a "Sound Driver" or "Music Engine" or various other synonyms.

My understanding is that "Squirrel" is Aetherbyte's compiler that turns MML into bytecode in the same format that the System Card's "PSG Driver" expects.

The data format that the "PSG Driver" expects is documented in the official Hu7 CD System documents.

From what TheOldMan has said, the actual "PSG Driver" that they're using for HuCards is actually just the same one that's on the System Card, that they've ripped out and disassembled (converted it back into source code), so that it can be re-assembled and used on a HuCard (i.e. it's not legally their code).

Arkhan's explanations of the benefits of multi-platform compatibility are absolutely true, at least for someone that wants to create music for a multi-platform game.

A significant chunk of the videogame industry has been using FMOD (http://www.fmod.org/) for many years, precisely for that reason.