Issues with SF2 mapper with C code - Only seems to work with assembly

[bfrasure]

I've attempted to use the SF2 mapper but did not find a route from the SF2 build parameter in assembly to the HuC build function. Supplying it seems to be ignored.

[jbrandwood]

That is because HuC does not support the SF2 mapper, and is unlikely to ever do so because the 20+ year old HuC support library and code layout are currently incompatible with using the PCEAS assembler's recently-added support for SF2 mapper.

There is work being done on a successor to HuC and its support libraries that will be compatible with the SF2 mapper and other "modern" targets such as the Turbo Everdrive.

Until the new compiler is ready for public release, you can only develop for the SF2 mapper in assembly language (see the huc/examples/asm directory).

[bfrasure]

Thank you. I actually tried implementing it before posting this and ran into a few roadblocks. In the meantime, this is a completely separate question, not an issue; I was able to build code that can play a 3-second ADPCM sound via HuC code. The limitation I've run into is the integer size defining the length of the ADPCM. Since ASM is not great for building a game, I would prefer to stick with C where possible. Are you aware of anyone who has implemented long ADPCM samples similar to Y's IV, Addams Family, etc? I'm sure it could be done by building dozens of small clips and running through them, but there might be a less complicated way.

[jbrandwood]

Since ASM is not great for building a game, I would prefer to stick with C where possible.

Really? All of the commercial games released during the PC Engine's lifetime (except for a handful) were written in assembly language. ;-)

You may not personally have the patience or knowledge to write in assembly language, and there's absolutely nothing wrong with that, but please understand that the HuC compiler produces really slow and bloated code. It was created as a way for people to get started on the PC Engine, with the hope that they would quickly begin to start optimizing their code with sections of asm, and then eventually outgrow HuC and write completely in asm. You do not have to follow that path, and you can still produce some reasonably-decent stuff in HuC, but please understand that the ancient HuC system has some pretty restrictive performance and capability limitations.

As for playing back long ADPCM tracks ... sure, it's definitely possible. You just stream the ADPCM from CD directly into ADPCM memory, there's a System Card function to do it. There's also an asm library to do it that doesn't use the System Card.

Have you found the official Hudson PC Engine developer documentation yet?

I don't think that the regular HuC library makes that System Card function available to HuC developers, but I've already added it to HuCC. In the meantime, you could call that function from HuC if you use a little bit of inline assembly language.

If you wish to chat generally about PCE development, and ask questions about HuC, then may I suggest that you consider joining the PC Engine Bible forum and ask there? https://pcengine.proboards.com/

There are also a couple of Discord channels that HuC users hang out in that you might find, but I'm going to suggest that saying "hello" on the forum is your best way to get invited to those.

Best wishes,

John

[bfrasure]

Thanks for the references - precisely what I needed. C definitely attracts developers, which will, in turn, help improve the SDK tools (and grow the number of assembly devs). I look forward to using the expanded storage of the SF2 mapper as the physical Hu-Cards grow in size - and then seeing what the homebrew community does with it.