CC65 and the PCE

[elmer]

I've put a new Windows build of Mednafen up on my PogoPlug for anyone that wants it ...

[EDIT] <2015-08-11 removed dead link>

This is still a 32-bit version that only supports the PCE and PC-FX.

New features are ...

• The memory debugger has now been expanded to 800x600 and made more readable.
• You can use either "G" or "ENTER" to set the address on both the main view and the memory view ... rather than having the same function on different buttons on different views.
• Built with it's own 64-bit version of zlib to make Mednafen happy.

Patch files and a build script are included for the adventurous.

Here are "before" and "after" screenshots of the memory view ...

[touko]

Downloaded, thanks ;-)

[elmer]

I've put up another new Windows build of Mednafen up on my PogoPlug for anyone that wants it ...

[EDIT] <2015-08-11 removed dead link>

This is still a 32-bit version that only supports the PCE and PC-FX.

New features are ...

• Built with today's new Mednafen 0.9.38.4 release (which fixes touko's SuperGrafx bug).
• Added a bit more white-space between lines on the PCE & PC-FX debugger screens to make them easier to read.
• Reorganized PC-FX register display a bit because of the previous change.

Patch files and a build script are included for the adventurous.

[touko]

oh cool,2 gifts in one ;-)

[elmer]

oh cool,2 gifts in one ;-)

You're welcome! 

I'm glad that someone else is finding the changes useful.

[touko]

Tested, and it still doesn't work with my sgx stuffs 
Even with the last mednafen release .

[elmer]

Uh-oh ... can you please test with the official new 0.9.38.4 Mednafen binary release to make sure that I've not screwed something up?

[EDIT]
I've diff'd  0.9.38.3 vs 0.9.38.4 and I can see that Ryphecha made some changes in src/hw_video/huc6270/vdc.c (and .h) that I can only assume are there to fix the bug that you reported.

[touko]

Uh-oh ... can you please test with the official new 0.9.38.4 Mednafen binary release to make sure that I've not screwed something up?

Already tested, it works with an old release of flappy bird, but not with the last .

[elmer]

Already tested, it works with an old release of flappy bird, but not with the last .

Sorry ... I can't tell what you mean from that, which "it" (official Mednafen or my Mednafen) and which "last" (Mednafen or Flappy Bird")?

Does the latest official Mednafen fix the version of Flappy Bird that you sent to Ryphecha when you reported the problem?

If it does, then does my build also work with that same version of Flappy Bird?

Since you've kept on developing ... perhaps you've found another problem with Mednafen, or perhaps Ryphecha's fix didn't fully work in all cases.

I'm just trying to figure out if your current problem is in the current official Mednafen, or if it is something that only breaks with my msys2 build.

[touko]

Sorry ... I can't tell what you mean from that, which "it" (official Mednafen or my Mednafen) and which "last" (Mednafen or Flappy Bird")?

Oups sorry, i sent a version of my flappy bird clone to mednafen author ,the last build of mednafen (0.9.38.4) works fine with it .
i tested a new version of flappy with some optimised code in graphic libraries, and it didn't works, i have a black screen, but it works fine on the old mednafen 0.8 and true hardware .

Does the latest official Mednafen fix the version of Flappy Bird that you sent to Ryphecha when you reported the problem?

Yes it works 

I'm just trying to figure out if your current problem is in the current official Mednafen, or it it is something that only breaks with my msys2 build.

i thought too, but no, the two versions have the same issue, a black screen .

EDIT: Ok set and sbc was the problem, for sure this doesn't work on real hardware ;-)

[elmer]

I'm just trying to figure out if your current problem is in the current official Mednafen, or it it is something that only breaks with my msys2 build.

i thought too, but no, the two versions have the same issue, a black screen.

It's good to know that all my patches haven't broken anything!

i tested a new version of flappy with some optimised code in graphic libraries, and it didn't works, i have a black screen, but it works fine on the old mednafen 0.8 and true hardware .

I can see that you've reported the issue on the official Mednafen board, so I'll keep a watch on it there and see if I need to make a new build.

[EDIT]

Looks like you're doing a naughty thing with the SET instruction that's definitely not documented in the official Hudson manual, or Charles MacDonald's hardware notes.

If you confirm that it actually does work on real SGX hardware, can you please test to see if CMP and LDA also work with SET (just like the Mitsubishi 740 series)?

[touko]

If you confirm that it actually does work on real SGX hardware, can you please test to see if CMP and LDA also work with SET (just like the Mitsubishi 740 series)?

For now i cannot, bacause i have a real sgx but no flash card (my sgx stuffs was tested by a friend) .
Set is the instruction that i want to test absolutely on real hardware .
But it seems that SBC works too .

Looks like you're doing a naughty thing with the SET instruction that's definitely not documented in the official Hudson manual, or Charles MacDonald's hardware notes.

i don't really think that SET is the problem, because it works with the old mednafen version .
And works too with PCE stuffs only, even those that contain the same libraries (with the use of SET) .

[Mednafen]

Just tested to reconfirm it, SET does not appear to have any effect on SBC when paired with it, on a HuC6280(in my PC Engine Duo).  So at the very least, if you're making programs targeting the PC Engine, it's erroneous to use SET with SBC and expect it to work as it would with ADC.

[Mednafen]

Quick and dirty test program: http://sarsie.fobby.net/junk/set-test-apr20-2015.zip

[elmer]

Quick and dirty test program: http://sarsie.fobby.net/junk/set-test-apr20-2015.zip

Thanks for knocking this test program up so quickly!

I've tried it on my Core Grafx II and my 3 Super Grafx consoles (OK, so I'm a bit of a fan) ... and the test fails on all 4 with the same screen as on your Duo.

So unless the test itself is flawed (and it seems good to me from a quick look at the assembly source) then Touko ... I'm afraid that I've got to paraphrase the immortal Inigo Montoya and say ....

"I do not think that instruction does what you think it does." 

[Aladar]

Tested years ago with every single opcode: SET affects only ADC, AND, EOR and ORA.

[touko]

Tested years ago with every single opcode: SET affects only ADC, AND, EOR and ORA.

Yes i saw that on develo book,SET is mentioned only for these opcodes .

I confirm that removing set with sbc made it to work fine .. 
luckily it was used only in load_vram function

then Touko ... I'm afraid that I've got to paraphrase the immortal Inigo Montoya and say ....

"I do not think that instruction does what you think it does." 

it worked very well on mednafen 0.8,if it was fine for him then it was fine for me 
And like the great mulder said " I want to believe" .


Seriously,now i'll test my picky code directly on real thing to be sure .

[Debvgger_]

Hey elmer, thank you very much for this version of mednafen :-) It's very much appreciated.

I don't know how many people would be interested, but you can bet I would use CA65 and LD65 :-)

[elmer]

I've put up another new Windows build of Mednafen (with my changes) for anyone that wants it ...

https://www.dropbox.com/s/o967dmh3v5kq4hg/mednafen-0.9.38.5-x86-elmer.zip?dl=0

Just to remind any newcomers to this thread, the modifications are in Mednafen's PCE and PC-FX debugger displays in order to make them a bit more pleasant to look at, and readable.

This is still a 32-bit version that only supports the PCE and PC-FX.

New features are ...

• Built with the recent Mednafen 0.9.38.5 release (which fixes a PC-FX bug).
• Built with latest msys2 GCC compiler in the hope that this might run on Windows 10.

The patch files and a build script are available at ...

https://www.dropbox.com/s/nuqejdtmxpgur4d/build-msys2-mednafen-0.9.38.5-x86-elmer.zip?dl=0

[NightWolve]

then Touko ... I'm afraid that I've got to paraphrase the immortal Inigo Montoya and say ....

"I do not think that instruction does what you think it does." 

it worked very well on mednafen 0.8,if it was fine for him then it was fine for me 
And like the great mulder said " I want to believe" .

An Inigo Montoya reference followed by one from X-Files in the same thread, great stuff!

Interesting read in this thread BTW, tried to catch up and read most of it!

[elmer]

Bonknuts posted that CC65 has recently got support for the PCE, so I thought that I'd give it a try.

It's only got console-io at the moment, but it certainly works in Mednafen.

Looks like it's time to start figuring out what library functions could be ported over from HuC! 

#include <conio.h>

void main (void)
{
   unsigned uLine;
   for (uLine = 2; uLine < 30; uLine += 2)
   {
      cputs( "Hello, World!\n\r" );
      cprintf( "CC65 console line %d\n\r", uLine );
   };
   while (1);
}

[elmer]

Since the HuC code for reading/writing a Turbo Everdrive's SD card seems to have been stuck for quite a while now, I thought that I'd see if CC65 could compile one of the more popular open-source FAT32 libraries.

It compiles with no problem at all. 

Here's the size of the compiled code with various different options enabled.


FatFs - Generic FAT File System Module
http://elm-chan.org/fsw/ff/00index_e.html

Size            Writable     Long Filename   Limitations
-------------------------------------------------------------
$725B : FATFS : read-write : UNICODE LFN   :
$3E3F : FATFS : read-only  : UNICODE LFN   :
$34F9 : FATFS : read-only  : UNICODE LFN   : no directories
$239F : FATFS : read-only  : no LFN, CP437 : no directories


Petit FAT File System Module
http://elm-chan.org/fsw/ff/00index_p.html

Size            Writable     Long Filename   Limitations
-------------------------------------------------------------
$1A42 : PFF3, : read-write : no LFN, CP437 : no lseek, fat16 & fat32
$1907 : PFF3, : read-write : no LFN, CP437 : no lseek, fat32 only
$16fa : PFF3, : read-only  : no LFN, CP437 : no lseek, fat16 & fat32
$15BF : PFF3, : read-only  : no LFN, CP437 : no lseek, fat32 only


Now, if I could get the TED2 low-level assembly code to actually read blocks of data from the SD card instead of crashing, then we might have something useful. 

[ccovell]

Can these actually be made into libraries accessible from ROMs, eg PCEmon, a hacked TenNoKoe Bank ROM, etc?

[elmer]

Can these actually be made into libraries accessible from ROMs, eg PCEmon, a hacked TenNoKoe Bank ROM, etc?

I don't think that I quite understand the question?

These are libraries, distributed as "C" source.

You just include them in your CC65 project, decide what code/data segments/banks you want to put them in ... and use them.

CC65 doesn't really impose any limitations on where you choose to place stuff ... it is entirely flexible.

With CC65/CA65, it's easy to mix "C" and assembly code ... so you just write your ROM in whichever language makes you happy.

I still need to finish-off low-level SD-card access functions ... the one's that Mooz did for the TED1 have needed a fair bit of fiddling about to get them even partially-working on the TED2.

I can't see them being much use for hacking into the TenNoKoe Bank ROM. Instead, I'd rather assume that anyone wanting to copy data from Backup Memory to SD card would just write a completely new ROM.

If you're thinking about an expanded Super System Card with something like PCEMon and copying Backup Memory to/from SD card, saving screen grabs on SD card, etc ... then "yes", I'd say that it is certainly possible.

Something along those lines is one of my goals, with the TED2 System Card patch as a 1st-step.

The TED2's built-in USB connection to a PC makes things even easier and more convenient for people.

[Arkhan Asylum]

I think the topic of CC65 came up awhilllllle ago one time, and it never went anywhere only because there were (are) like 3 active developers.

at the time I think it was something like, Bonknuts wasn't using C, we were already successfully bitch slapping HuC into producing games that move faster than -12 FPS, Rover was around there too, and Cabbage was using ASM too?

so nobody wanted to make libraries or spend time on it.

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 don't think it would be too hard.   Famous last words.

[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 Asylum]

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.

[TurboXray]

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, fuck 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, fuck 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.

[OldMan]

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.

[OldMan]

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

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

[TurboXray]

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. 

[OldMan]

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 Asylum]

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:

• 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.
• 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.
• To provide a fast, easy, headacheless way to produce sound effects and music in a game.  See: Atlantean

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]

• 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.

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 Aetherbutt'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.

[Arkhan Asylum]

• 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.

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.

Yeah.  The PSG thing is already present if you have the CD hardware (System Card).   When we originally did this, we were making Insanity for PCE CD.   So, it made alot of sense to just use what was there instead of wasting time trying to make our own stuff.

Initially, we had this sort of "on the fly" parse/play thing for MML that at least demonstrated that the idea worked.   It wasn't perfect.  I remember spending alot of time trying to get intervals to work right.   


and yeah, Squirrel simply turns an MML file into the bytecode expected by the PSG driver. 

[Pokun]

I see, thanks!

[elmer]

I've put up another new Windows build of Mednafen (with my changes) for anyone that wants it ...

https://www.dropbox.com/s/9kmh6wiscv411ni/mednafen-0.9.38.7-x86-elmer.zip?dl=0

Just to remind any newcomers to this thread, the modifications are in Mednafen's PCE and PC-FX debugger displays in order to make them a bit more pleasant to look at, and more readable.

This is still a 32-bit version that only supports the PCE and PC-FX.

New features are ...

    Built with the recent Mednafen 0.9.38.7 release.
    Built with latest msys2 GCC compiler in the hope that this might run on Windows 10.


The patch files and a build script are available at ...

https://www.dropbox.com/s/2g6xwo4w4owwkuc/build-msys2-mednafen-0.9.38.7-x86-elmer.zip?dl=0

[touko]

Downloaded, thanks .

[tonma]

Downloaded too. Thanks, I'll try it soon.

[elmer]

I've put up yet-another new Windows build of Mednafen (with my changes) for anyone that wants it ...

https://www.dropbox.com/s/6rpkviyhgihw4gt/mednafen-0.9.38.7-x86-elmer-2.zip?dl=0

Just to remind any newcomers to this thread, the modifications are in Mednafen's PCE and PC-FX debugger displays in order to make them a bit more pleasant to look at, and more readable.

This is still a 32-bit version that only supports the PCE and PC-FX.

New features are ...

    PCE now has 480KB of SCD RAM (banks $44-$7F), plus the 2MB ACD RAM (banks $40-$43).
    PC-FX now has 8MB RAM.

    The extra RAM can be useful during homebrew development as a place to store debugging-info.

    It might also be useful for someone that needs the extra memory for a translation.

    N.B. This is a 32-bit build, but 64-bit Windows builds are now working if someone wants to build it from source.

The patch files and a build script are available at ...

https://www.dropbox.com/s/i3mor256dhrddef/build-msys2-mednafen-0.9.38.7-x86-elmer-2.zip?dl=0

[Arkhan Asylum]

Rather than sift through this and try to figure out what the hell was going on:

Where's CC65 at with regards to using it instead of HuC for making games?

[elmer]

Where's CC65 at with regards to using it instead of HuC for making games?

Short Answer:

It just requires the desire to use it, and the willingness to copy over any HuC library routines that you want to use.

From my POV, that makes it perfectly usable, but I suspect that you've got a different POV. 

------------------------

Long Answer:

The workflow is definitely going to be different to HuC, because of it is the more-traditional compile/assemble/link style, and because it doesn't have HuC's PCE-specific #incpal/#inctile/#incspr functions.

CC65/CA65 are working perfectly fine as a compiler/assembler.

I've built a test-rom with it to confirm that it compiles standard C code (a FAT32 library for reading the Everdrive's SD card).

It was easy to use and incredibly flexible once you've got your head around the power of its code-layout and startup options.

The point is that it's all configurable and you get to decide where the linker puts the startup-code/library-code/game-code/data.

The guy that was working on the PCE-port hasn't committed anything new in about 4 months. But that's not really a problem since he was definitely a novice on the PCE and was doing some things in a very strange (and wrong) way.

Because it's all "linked", we can just use the bits of his CC65-specific code that we like, and override anything else with new code.

Then, if you want to make a CD, you have to piece-together the .iso binary with something like 'bincat' and then modify the 2nd-sector with your particular

------------------------

Here's my batch file for compiling the test code ...

Code Select Expand

# C files.

cc65 -O -t pce hello.c
cc65 -O -t pce fatfs/ff.c
cc65 -O -t pce fatfs/diskio.c
cc65 -O -t pce fatfs/option/unicode.c

ca65 -t pce -v hello.s
ca65 -t pce -v fatfs/ff.s
ca65 -t pce -v fatfs/diskio.s
ca65 -t pce -v fatfs/option/unicode.s

# ASM files.

ca65 -t pce -v crt0.s
ca65 -t pce -v text.s
ca65 -t pce -v sd.s

# Link

ld65 -o hello.pce -m hello.map -C pce.cfg hello.o text.o sd.o fatfs/ff.o fatfs/diskio.o fatfs/option/unicode.o crt0.o pce.lib

------------------------

I decided to use the following layout for the HuCard ...

The STARTUP & library CODE go in bank $00 that lives at $E000-$FFFF.

The INIT code and the 'initialized' DATA (that get copied to RAM) goes in bank $01 that lives (temporarily) at $C000-$DFFF.

Once the HuCard starts up and my customized crt0.s runs the INIT code, and copies the 'initialized' DATA to RAM, then I map banks $02-$05 into $4000-$DFFF for my main code, and leave $C000-$DFFF for paging code/data as I need to.

Now I'm not saying that this is a particularly great way to lay out a HuCard, but I needed an uninterrupted 32KB for the FAT32 code, and the big point is that I was easily able to do that with CC65.

And here's my customized CC65 configuration file for that layout ...

Code Select Expand

SYMBOLS {
        __STACKSIZE__: type = weak, value = $0300; # 3 pages stack
}

MEMORY {
        # Preserve System Card standard ZP locations.
        ZP: start = $00, size = $ec, type = rw, define = yes;

        # reset-bank and hardware vectors
        ROM0: start = $E000, size = $1FF6, file = %O, fill = yes, define = yes;
        ROMV: start = $FFF6, size = $000A, file = %O, fill = yes;

        ROM1: start = $C000, size = $2000, file = %O, fill = yes, define = yes;
        ROM2: start = $4000, size = $8000, file = %O, fill = yes, define = yes;
        ROM6: start = $C000, size = $2000, file = %O, fill = yes, define = yes;
        ROM7: start = $C000, size = $2000, file = %O, fill = yes, define = yes;

        # First RAM page (also contains stack and zeropage)
        RAM: start = $2200, size = $1E00, define = yes;
}

SEGMENTS {
        STARTUP:  load = ROM0, type = ro,  define = yes;
        INIT:     load = ROM1, type = ro,  define = yes, optional = yes;
        CODE:     load = ROM0, type = ro,  define = yes;
        RODATA:   load = ROM0, type = ro,  define = yes;
        DATA:     load = ROM1, type = rw,  define = yes, run = RAM;
        SDCODE:   load = ROM2, type = ro,  define = yes;
        SDDATA:   load = ROM2, type = ro,  define = yes;
        BSS:      load = RAM,  type = bss, define = yes;
        VECTORS:  load = ROMV, type = rw,  define = yes;
        ZEROPAGE: load = ZP,   type = zp,  define = yes;
        EXTZP:    load = ZP,   type = zp,  define = yes, optional = yes;
        APPZP:    load = ZP,   type = zp,  define = yes, optional = yes;
}

FEATURES {
    CONDES: type    = constructor,
            label   = __CONSTRUCTOR_TABLE__,
            count   = __CONSTRUCTOR_COUNT__,
            segment = INIT;
    CONDES: type    = destructor,
            label   = __DESTRUCTOR_TABLE__,
            count   = __DESTRUCTOR_COUNT__,
            segment = RODATA;
    CONDES: type    = interruptor,
            label   = __INTERRUPTOR_TABLE__,
            count   = __INTERRUPTOR_COUNT__,
            segment = RODATA,
            import  = __CALLIRQ__;
}

EDIT:

I guess that it would help to explain a couple of things in the configuration file (it's for the "LD65" linker).

The "MEMORY" section is basically just a list of areas (and their sizes) that get written to the output file ... in this case I'm having it create an 8 bank HuCard ROM image.

The actual names of the different sections in "MEMORY" can be anything ... I'm just using the name "ROM" + bank-offset for my own convenience.

The "SEGMENTS" section defines the names of the different segments in the C and ASM code (user-defined, but with a few defaults like CODE/DATA/RODATA/RAM), and it shows where in the output file those segments should be put.

That's it ... you have total flexibility to map your code/data into the output HuCard/ISO image in any way that you like.

------------------------

[Arkhan Asylum]

Ah.  Well, that's straightforwardish. 

And I guess really, the real dilemma for me is the whole Squirrel thing.   lack of chiptunes = how do I games.

Though, I don't think dealing with the CD BIOS to feed Squirrel in would be too hard.

Mapping in all the HuCard version crap might not really be that hard either.   

I'd look, but I don't want to distract myself from finishing this MSX game.

I tend to work serially on things. 

[OldMan]

And I guess really, the real dilemma for me is the whole Squirrel thing.

Don't worry about it. From what I've seen, we can put the player in whatever page we want, and fix the startup/irq code to handle it. It shouldn't be any worse than the Huc modifications.

My worry is getting the Huc functions to work. Guess I'll install this, and see what I can do..