|
Post by turboxray on Jan 1, 2020 16:55:24 GMT
Not to mix up with the other PCM driver (soft mix channels), this thread is for the scaled frequency sample driver. This is the first public release (ver 1.2.2): gitlab.com/RickSugar/hupcm-driverHere's the driver, and a quick and dirty XM player (parser) to show the driver in action. Highly recommend mednafen, if you want to quick here the examples in an emulator (Ootake has some weird distortion for higher rate DDA stuff, Magic Engine.. do people still use that thing???). Or just the real hardware. Keep in mind for the examples: there are only 3 FX supported for the player, so the songs might not sound exact (I tried to pick songs that had minimal FX usage). A lot of these example songs play the samples from 14khz to 56khz range! While this player supports that, it's not meant for such high frequencies (because of the nyquist limit and it just crushes those frequencies). The driver, not the player, calibrates C octave 3 to 7000hz. For a frame of reference: C4 = 14khz, C5 = 28khz, C6 = 56khz. So there be sample skipping like crazy to get those octaves haha. The samples are straight ripped and bit-shifted to 5bits. No fancy frequency re-scaling or nice filter before conversion. So they sound a bit crunchy/noise-y. Since the PCE has hardware volume, it's really important to maximize the samples amplitude to full range (even beyond that if needed) to get the full resolution of 5bit - and then adjust the volume to compensate (this is true for any samples on the PCE though). These samples are not adjusted for that. So this quickly hacked together player is to demonstrate the driver in action, not the quality it can achieve, etc. Also, these songs only use 4 channels (doesn't use the fixed frequency channels). This driver version doesn't have the faster 16bit PHA mode yet (I need to do some ifdefs). These songs run at 30% cpu resource if all channels playing (would be 26% for 16bit PHA). I'll update that soon. This version is the ram friendly one. The next planned version is to use a double buffer system and scale the samples outside the driver ISR. That should bring down the cpu resource to 19-20%.
|
|
touko
Punkic Cyborg
Posts: 106
|
HuPCM
Jan 1, 2020 17:28:00 GMT
Post by touko on Jan 1, 2020 17:28:00 GMT
Thanks to share this driver
|
|
|
HuPCM
Jan 1, 2020 20:15:48 GMT
Post by elmer on Jan 1, 2020 20:15:48 GMT
Cool stuff, it's good to see you releasing stuff again, and with such amazingly-comprehensive documentation! I see that you're still using the 3.22 version of PCEAS that you improved back in 2011. As an assembly-language guy, there's probably not a lot that I've added to the assembler in the new HuC that will interest you, but FYI, I did find and fix a bug in the changes that you made to allow assembling across bank boundaries (since Uli imported all of your changes into his branch of HuC). github.com/jbrandwood/huc/commit/81a8f8bffb207cf8fb96349a315d5e21fe087fe5In the event that there's any of my source code that you want to use in the future, you'll also need this patch, because I use the syntax everywhere (it was common in 6502 and 65C816 assemblers back-in-the-day) ... github.com/jbrandwood/huc/commit/928805e3fe97429383a98a8f06f10218e483b7cc
|
|
|
HuPCM
Jan 1, 2020 22:30:08 GMT
Post by monstersgoboom on Jan 1, 2020 22:30:08 GMT
Great stuff. thanks for sharing. no idea how to make a lib for C via HuC yet. but this sounds great.
|
|
|
HuPCM
Jan 2, 2020 16:42:13 GMT
Post by turboxray on Jan 2, 2020 16:42:13 GMT
Cool stuff, it's good to see you releasing stuff again, and with such amazingly-comprehensive documentation! Thanks haha but honestly it needs more documentation. Or rather, some examples without HuXM player to show the macros in usage more clearly. I'm looking at the github diff between the files, and the original code there is from 2005 (not me) - it doesn't have my changes. But it's weird, cause I know I changed it at some point for a dissassembled Bonk 1 rom I had that needed it because that game use 3 and 4 bank linear layouts for functions. I even had test cases for the changes. Ahh nice. But is #high, #low, #bank still there for compatibility?
|
|
|
HuPCM
Jan 2, 2020 18:51:28 GMT
Post by elmer on Jan 2, 2020 18:51:28 GMT
Ahh nice. But is #high, #low, #bank still there for compatibility? Yep, I generally *try* not to break compatibility (unless there's a *really* good reason)! I'm looking at the github diff between the files, and the original code there is from 2005 (not me) - it doesn't have my changes. But it's weird, cause I know I changed it at some point for a dissassembled Bonk 1 rom I had that needed it because that game use 3 and 4 bank linear layouts for functions. I even had test cases for the changes. Sorry, I thought that Uli merged in all of your 3.22 version changes ... I can certainly see stuff like your .dwl & .dwh additions. Maybe he missed something. The problem with instructions crossing banks is definitely in your 3.22, I just tested it again. Your changes allow instructions to cross banks, and pop up a warning instead of an error, but the bytes that cross the boundary aren't written ... they stay as the PCEAS-default value of $FF. This is masked in your test file in pceas2_ver322.zip because you do a lda #$FF to test the boundary crossing, and so the output looks correct. If you change the line in test.asm (line 102) to lda #$03 for example, you'll see that the $03 isn't written, and the 2nd byte of the instruction remains the default $FF.
|
|
|
HuPCM
Jan 3, 2020 20:29:19 GMT
Post by turboxray on Jan 3, 2020 20:29:19 GMT
Yeah, but I remember having issues with Bonk (and comparing the reassembled code against the rom). Maybe I didn't release the update, or maybe I never made it haha. It's been too long to remember. What's the licensing agreement for including/distributing just the binary? Wait.. does the new version of PCEAS support passing in equate values via commandline argument like HuC does? Or at least multiple ASM files?
|
|
|
Post by turboxray on Jan 3, 2020 22:25:13 GMT
Okay, I updated the project for the fastmode equate (it's in the doc and example builds). Base cpu resource dropped down from 30% to 26% in those example builds. I added both source file versions so you can compare the difference. I also messed up and forgot to tell git I renamed the directory haha.. all new changes to the driver When I do the sample buffer version, which will be faster, I think I'll add the option to use the two fixed frequency channels as a 10bit pair, and soft mix a few channels to them. Honestly, 2 resample channels at stereo 5bit and 4-6 softmixed mono channels at 7bit should complement nicely. Could probably get around 26% for that combo (4 soft mixed channels, 2 resampled channels; give the PCE 8 total channels). But then now I'm crossing products. I guess I can make the soft mix part modularized so it's independent heh.
|
|
|
Post by elmer on Jan 4, 2020 4:15:51 GMT
What's the licensing agreement for including/distributing just the binary? AFAIK it basically amounts to "Do WTF you wish!". From what I remember back on PCEFX, we never really got any formalized agreement for the original authors as to a license for HuC/PCEAS, and I believe that everyone just wants the whole thing to be as close to Public Domain as possible, and to encourage people to use it all and modify it as they want. That's certainly the case with any of the changes that I have made, and I believe that Artemio and Uli feel the same. Wait.. does the new version of PCEAS support passing in equate values via commandline argument like HuC does? Or at least multiple ASM files? I have no idea about the ability to define stuff on the command line. I recommend that you give it a go ... and if it doesn't do what you want, upgrade it and send me a "Pull Request" (or the changed files). I don't believe that you can put multiple ASM files on the command line, but I ".include" assembly language files all over the place ... if there's a nesting limit, then I haven't reached it yet!
|
|
|
Post by dshadoff on Jan 4, 2020 4:37:18 GMT
From what I remember back on PCEFX, we never really got any formalized agreement for the original authors as to a license for HuC/PCEAS, and I believe that everyone just wants the whole thing to be as close to Public Domain as possible, and to encourage people to use it all and modify it as they want. That's certainly the case with any of the changes that I have made, and I believe that Artemio and Uli feel the same. I remember quite well your concern over the licensing several years back, and reaching out to David Michel and Zeograd so that we could all consent to this. It wasn't a legalese-crafted document, but the emails amounted to, "we always wanted collaboration; that's why we published all of the source... please contribute as you wish". Of course, HuC was based on a compiler for whom we ourselves couldn't find complete attribution, and was the original authors were either untraceable or unreachable or both, but was used for the basis of other internet projects as well without incident. It is a shame that there is some version fragmentation among users and that there were changes introducing incompatibilities (which likely caused the fragmentation), but at least it's back in the hands of a maintainer. I hope that this is built-upon rather than forked into oblivion.
|
|
|
HuPCM
Jan 5, 2020 3:50:38 GMT
Post by turboxray on Jan 5, 2020 3:50:38 GMT
Ohh cool. Yeah, I'll update with the current PCEAS and a link to the github page.
I do have a list of some stuff I wanted to add. Mostly a few things for macros ("." in the name), a few more address modes that can be passed in (indirect-indexing), and registers to be passed in (A, X ,Y, etc). I think it already has a string you can pass into it (nice for making some commands for a macro). I wanted my macros to be like MOVE.b instead of an underscore. Works nicer with a syntax highlighter too (and the .b could be a different color... so beautiful).
PCEAS also really needs some namespace filtering directive haha. I mean there's proc, and local labels, but ...namespacing!
|
|
|
HuPCM
Jan 6, 2020 2:15:28 GMT
Post by elmer on Jan 6, 2020 2:15:28 GMT
PCEAS also really needs some namespace filtering directive haha. I mean there's proc, and local labels, but ...namespacing! Hahaha ... we'll have to agree to disagree on the value of namespacing, I've hated it for years because it means that you never really know what you're looking at, and the code becomes unmaintainable by anyone except for the original programmer, unless they have a "smart" editor that pre-processes the program so that it can know what is really what.
|
|
|
HuPCM
Jan 6, 2020 5:48:16 GMT
Post by turboxray on Jan 6, 2020 5:48:16 GMT
You know.. I'm not even crossing a page boundary, just ending at it and starting a new .db after it.. and this is what it does: 53:9FE3 00 00 00 53:9FE6 00 53:9FE7 00 00 00 .db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 53:9FEA 00 00 00 53:9FED 00 00 00 53:9FF0 00 00 00 53:9FF3 00 00 00 53:9FF6 00 53:9FF7 00 00 00 .db 0,0,0,0,0,0,0,0,0,0 53:9FFA 00 00 00 53:9FFD 00 00 00 53:A000 FF .endif
416 54:A001 40 40 40 .db $40,$40,$40,$40,$40,$40,$40,$40,$40,$40,$40,$40,$40,$40,$40,$40 54:A004 40 40 40 54:A007 40 40 40 54:A00A 40 40 40 54:A00D 40 40 40 54:A010 40 417 54:A011 40 40 40 .db $40,$40,$40,$40,$40,$40,$40,$40,$40,$40,$40,$40,$40,$40,$34,$34 54:A014 40 40 40 The .db literally ends at 9fff and the next one starts at a000, but it keeps doing this hahah I'll try it with the most recent PCEAS build tomorrow. I'm not sure if it's related to the macro or not. Probably is. I can't put a .org (* -1) inside the macro either to fix it, even though that works everywhere else, and in other macros.
|
|
|
HuPCM
Jan 6, 2020 6:28:58 GMT
Post by elmer on Jan 6, 2020 6:28:58 GMT
You know.. I'm not even crossing a page boundary, just ending at it and starting a new .db after it.. and this is what it does: ?? You're defining 10 bytes, starting at $9FF7 ... so the next .db should start at $A001, which it does. The $FF at $A000 looks like the final byte of the .db isn't being written, which is basically the bug in pceas 3.22 that I was talking about. If it still does that in the current pceas, then there's a edge-case that I missed, and you've found a new bug! <edit> I just tested both pceas 3.22, and the my 2018 release of HuC ... and v3.22 shows the bug that you're seeing, but it is fixed with the newer PCEAS.
|
|
|
HuPCM
Jan 6, 2020 16:35:34 GMT
Post by turboxray on Jan 6, 2020 16:35:34 GMT
You know.. I'm not even crossing a page boundary, just ending at it and starting a new .db after it.. and this is what it does: ?? You're defining 10 bytes, starting at $9FF7 ... so the next .db should start at $A001, which it does. The $FF at $A000 looks like the final byte of the .db isn't being written, which is basically the bug in pceas 3.22 that I was talking about. If it still does that in the current pceas, then there's a edge-case that I missed, and you've found a new bug! <edit> I just tested both pceas 3.22, and the my 2018 release of HuC ... and v3.22 shows the bug that you're seeing, but it is fixed with the newer PCEAS. Okay, but it was more than just that haha. Here's the same with 9 entries: 53:9FE3 00 00 00 53:9FE6 00 53:9FE7 00 00 00 .db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 53:9FEA 00 00 00 53:9FED 00 00 00 53:9FF0 00 00 00 53:9FF3 00 00 00 53:9FF6 00 53:9FF7 00 00 00 .db 0,0,0,0,0,0,0,0,0 53:9FFA 00 00 00 53:9FFD 00 00 00 .endif 416 53:A000 FF FF FF .db $40,$40,$40,$40,$40,$40,$40,$40,$40,$40,$40,$40,$40,$40,$40,$40 53:A003 FF FF FF 53:A006 FF FF FF 53:A009 FF FF FF 53:A00C FF FF FF 53:A00F FF 417 54:A010 40 40 40 .db $40,$40,$40,$40,$40,$40,$40,$40,$40,$40,$40,$40,$40,$40,$34,$34 54:A013 40 40 40 54:A016 40 40 40 Now it aligns, but all the next 16 bytes in the db are $ff Okay I'll build the newest PCEAS version and try that. UPDATE: New PCEAS build broke one of my macros. Doesn't like the jsr \1 inside the macro. ; ................................................ CALL .macro
jsr \1
.endm I don't think I use it, so I just commented it out. It's not the jsr \1, because I have it in other macros, but just that it's by itself. Weird haha.
|
|