The new fork of HuC

[elmer]

I successfully compiled HuC with the msys2 you linked, but I cannot launch the executables outside the msys shell. Missing msys-gcc_s-1.dll and more.

You didn't make a static build, so it's bringing in a bunch of DLLs.

You can just copy the DLLs from their location in msys2 ... but it'd be better to make a static build so that they're not needed.

You may also be missing a bunch of the static libraries, it depends upon the packages that you've installed in the msys2 environment.

That's why I have my own batch file to automate an installation! 

<EDIT>

These 2 commands will install my base set of msys2 packages ...

 pacman -S --noconfirm --needed base-devel nano
 pacman -S --noconfirm --needed mingw-w64-i686-toolchain

I *may* have needed some other packages for my GCC and Mednafen builds, and they *may* have pulled in something else that's missing on your setup ... but if so, I don't know what.

[Sunray]

Yep, I installed the wrong gcc package (just named "gcc"). Apparently that is based on Cygwin... 

EDIT: Works now and the game runs. I also had to increase "#define NUMTAG 10" to 64.

[Bonknuts]

elmer: But.. if you use ZP as a fast stack.. how are we going to use recursion to solve ackermann's function?

[elmer]

I'd recommend programming your new Sharper Image Internet-Connected Back Scratcher to solve the problem, instead.

It's probably got more processing power by itself than every PCE ever made put together! 

[Bonknuts]

Yeah.. well... yeah.. but.. so.. well.. 3 PCE's networked together with three monitors to do a faithful port of Darius!

[elmer]

Yeah.. well... yeah.. but.. so.. well.. 3 PCE's networked together with three monitors to do a faithful port of Darius!

Well ... since it's you asking, I probably should have just said  ... "You can write it in assembly language with a couple of simple macros". 

It's best (IMHO) to tailor HuC to the things that the 6502/6280 does well ... and a small zero-page stack together with a reasonable use of "global/static" variables, and continued upgrades to the libraries, could allow us to get to that "only 2-4 times slower than hand assembly" goal that I'd love to see.

BTW ... it's going to be easy to modify Mednafen so that it will trap and report a stack-overflow condition with the small stack. That, together with a good error message about using "static variables" or the "-fno-recursive" option, should avoid the annoyances of the random crashes that a small stack architecture can lead to.

The next big question is going to be how to get a decent (and legal) sound driver.

As DK & Gredler have talked about with Catastrophy, it's hard to get someone on this side of the planet interested in MML.

A MOD player of some kind is going to be needed ... preferably with some sample playback, and/or use of the ADPCM hardware. I know that Arkhan loathes the format ... but musicians that either love or tolerate it are *much* easier to find on this side of the pond.

It's a pity that the Deflemask internal audio format isn't documented anywhere.

Do you know of any other good, popular MOD players? 

[TheOldMan]

The next big question is going to be how to get a decent (and legal) sound driver.

I'm voting for a stock interface to the sound driver from system code. Kind of "these are the routines you supply, and this is when they are called". That would allow us to have multiple drivers (presumably in seperate directories in pce/include), that could be turned on/off via #defines in the user code. [Which would use sound.inc to include the correct files]

Do you know of any other good, popular MOD players?

The place to start with that is Bonknauts. He did a -lot- of work on various sound routines.
After that, -if- we straighten out the system files, it should be (relatively) easy to install user supplied drivers, provided they work in a 'standardized' way.

[elmer]

I'm voting for a stock interface to the sound driver from system code. Kind of "these are the routines you supply, and this is when they are called". That would allow us to have multiple drivers (presumably in seperate directories in pce/include), that could be turned on/off via #defines in the user code. [Which would use sound.inc to include the correct files]

I'd prefer to avoid the overhead of a JSR if possible (especially in a TIMER interrupt) ... but it would certainly be possible to have a 2-level structure in startup.asm ...

Level 1 would just invoke different #include files for in-the-middle-of-vsync, in-the-middle-of-timer, and other-stuff-in-the-system-bank.

If those were something like "sound/vsync.asm", "sound/timer/asm", and "sound/system.asm", then you'd just change your PCE_INCLUDE environment variable to include whichever driver you wanted.

Level 2 would be a #define to entirely remove the vsync and timer handling code from system.asm and let you define your own, in which you could do whatever you like.

I suspect that we don't need a more complex interface than just providing those two options to any programmer.

The place to start with that is Bonknauts. He did a -lot- of work on various sound routines.
After that, -if- we straighten out the system files, it should be (relatively) easy to install user supplied drivers, provided they work in a 'standardized' way.

I'm hoping that he'll have an opinion to share! 

In the meantime ... it looks like the Deflemask formats *are* somewhat documented ...

http://www.deflemask.com/DMF_SPECS.txt
http://www.deflemask.com/DMP_SPECS.txt

That's good/bad/annoying/hopeful. 

[Bonknuts]

Sound drivers.. that's messy business

 I think by MOD, you're probably meaning "tracker" or tracked format? And not specifically long sample frequency-scaling MOD specific?


I wasn't going to release these yet, but whatever:

This is the sample sound driver. It's a real "MOD" sound driver. As in, it resamples the frequency on the fly to play whatever long samples on the PCE MOD style. It has some requirements for video setup (263 scanline mode recommended), but I have a future version that eases that timing requirement by a lot. They'll play identical. Mean while, you can take a look at this mess...
http://www.pcedev.net/HuPCMDriver/HuPCMDriver1.2.1.zip

 XM is sooo much a better fit than the traditional MOD format. Even if you just used PCE legal 32byte waveforms.. XM format is superior. I was able to write this super basic XM player for the PCE in 4 hours. The TXM format is just the XM file without its sample or envelope data. But other than that, it's XM song data to the tee.
http://www.pcedev.net/HuPCMDriver/HuPCMDriver_Demo_HuXMPlay.zip

In order to make the wave files repeatable, I have this utility that will convert 8bit wave files to 5bit special format (has terminator marker in the sample data either for end of sample or for looping. The converter allows creating loop points).
http://www.pcedev.net/HuPCMDriver/wave2six_ver1.1.2.zip


 It wasn't really meant for HuC. Matter of fact, I didn't think anyone would even use it (I use it, though).

[Bonknuts]

In the HuPCMDriver, I'll be moving the ProcessPCM code (macro) inside the sound driver so timing will never be an issue. Simple fix, just didn't get around to it.

 Deflemask is a really good format to go with. It supports some nice PCE only effects. Something XM and other generic trackers don't.

 As far as Deflemask. Just use the cooked output. Yeah, it's big - but LZSS compress the shit out of the main data, and just slowly decompress to a small window and execute the updates as it goes along. Samples will always be samples. So nothing to lose there.

[Arkhan]

Squirrel can be fudged into using samples. 

Though, I really think everyone who doesn't like MML simply misunderstands it.

You don't write the songs in MML.   That's 100% stupid.   You write them elsewhere and simply CONVERT the songs to MML.   If you understand half an ounce of sheet music (anyone who claims they are a musician should be able to comprehend even the most basic bits), using MML is easy.

Especially with piano-roll software like 3MLE that visually shows the crap.

I think people need to get over it.  Everyone waves their dicks around about all this technical crap, and is stopped up by something that can be called from BASIC with a PLAY command?

Please., lol

[TheOldMan]

I think by MOD, you're probably meaning "tracker" or tracked format?

To me, MOD means some program that looks sorta like a piano roll, and makes sound.
I don't really understand the difference between trackers and mods, and probably never will (I don't care that much how it makes sound. Just that it does)

Just out of curiosity, would we need an HSync hook? I can foresee that being a problem; it already can be in the bios player, if you are doing scroll areas.

[Bonknuts]

Squirrel can be fudged into using samples. 

Doesn't Squirrel use the sys card PSG player? AFIAK, it doesn't support samples. The two games that use it and ADPCM at the same time, use some hack-y audio driver on the side the peeks at the player, and syncs itself with it as it runs a separate data stream/channel for manipulating ADPCM stuffs. Other games just straight out bypass the sys card player all together. What do you guys do for sample support?

[Bonknuts]

Just out of curiosity, would we need an HSync hook? I can foresee that being a problem; it already can be in the bios player, if you are doing scroll areas.

 No Hsync. It's all timer based. Vblank is used to resync the timer every frame (reset the TIMER counter unit). And the Timer IRQ code immediately re-enables interrupts so that Hsync always has priority. That was a big thing I wanted in the player. The player also has a flag so that it can't be called more than once when interrupts are re-enabled during its initial call. That keeps things from crashing into each other. It might delay the sample(s), but "jitter" on these old systems is pretty much unavoidable. And it's not like it'll be Genesis bad - lol. So yeah, it plays nice with Hsync interrupts.


 MOD.. eh. In the context of computers, it just means tracked music. But in the context of consoles, it's about playing wave files at different frequencies. Basically what the PCE does with its little 32byte buffer each channel, but these are biiiiggg samples. It's why the Amiga and the PCE, while both technically the same in application - sound nothing a like. They both use samples. They both use the exact same period system and same period values for notes. But the PCE's sample memory is so gimped, that it sounds more like PSG than anything from "sample-based synthesis" (SNES, AMIGA, TRACKED music for 90's PCs, etc). MOD is basically sample-based synthesis. Lots of consoles in the 32bit generation (PS1, Saturn, Jag), and later generations (PS2, etc) use this but with better refinement.

[Arkhan]

Squirrel can be fudged into using samples. 

Doesn't Squirrel use the sys card PSG player? AFIAK, it doesn't support samples. The two games that use it and ADPCM at the same time, use some hack-y audio driver on the side the peeks at the player, and syncs itself with it as it runs a separate data stream/channel for manipulating ADPCM stuffs. Other games just straight out bypass the sys card player all together. What do you guys do for sample support?

The HuCard version sure as shit doesn't use the system card player, since the system card doesn't exist.

At one point years ago, I fudged a drum sample.  if you get a short enough wave, you can break it into a few 32byte segments as custom waveforms, and then switch them.

It works, but isn't exactly ideal.   Especially for literally every other human that might use it besides me, since MML hurts everyone or whatever.

I decided I liked my deep kickdrum that is currently in use more anyways.   Some of the greatest PCE games don't even use samples, and rely on noise-drums, so I also stopped caring.