|
Post by elmer on Jul 30, 2018 19:41:09 GMT
Please post questions and/or bug reports here.
|
|
|
Post by elmer on Jul 30, 2018 19:42:43 GMT
Random pointless comment to take up space so that I can edit it later on.
|
|
|
Post by theoldman on Jul 30, 2018 20:50:05 GMT
I see. Looks to me like put_tile() never got updated to handle the 3 parameter version of set_tile_data(). While you were looking at this, did you fix the 1 parameter version of set_tile_data()? As far as I can tell, it's not using a far pointer. But then, it doesn't allow for setting the palette array, either.
I understand that, but the data has to get mapped in to be read. That kind of stuff gets mapped to the CONST_BANK, afaict. And I vaguely remember a pointer fixup being done for that, when things get loaded.
Good to know its fixed. Better to know pointers are being normalized. (Maybe we can get them actually working right)
|
|
|
Post by elmer on Jul 30, 2018 23:43:19 GMT
While you were looking at this, did you fix the 1 parameter version of set_tile_data()? As far as I can tell, it's not using a far pointer. But then, it doesn't allow for setting the palette array, either. The 1 parameter version of set_tile_data() only works with #inctile_ex() ... which automatically puts the header and the palette lookup table (that it generates) directly into CONST_BANK. No fix is needed. And I vaguely remember a pointer fixup being done for that, when things get loaded. For load_map()? Yes. For put_tile()? No, not until now. Better to know pointers are being normalized. (Maybe we can get them actually working right) Do far pointers not work properly with something? Can you provide an example (in the new "HuC Support" thread)?
|
|
|
Post by theoldman on Jul 31, 2018 6:22:42 GMT
Okay. Let me see if I have this straight.... IF I use #inctile_ex(), then I need to use set_tile_data() with 1 parameter (ok, that's all I have from #inctile_ex()), and everything will get loaded into CONST_BANK. And put_tile() should work. BUT if I use #inctile() /#incpal() / #incbin() , I need to use the 3 parameter version of set_tile_data(), and because I #incbin() the palette index, put_tile() will fail, because it is -not- in the const bank. But If I set the indexes up myself, they go in the CONST_BANK, and put_tile() works.? Sometimes?
Yep, sounds like HuC. And you wonder why no one caught the problem? <lol> No one could figure out how to use them! Pointers in general haven't worked quite right in HuC ever. It's nothing specific to the new Huc. I hope they do work right now. I kinda miss int (*( f[3] ) () ); ....
x = f[n]();
|
|
|
Post by elmer on Aug 1, 2018 5:08:42 GMT
I kinda miss int (*( f[3] ) () ); ....
x = f[n](); Ah, function pointers used to create jump tables or a state machine? Something like ... int func1 (void) { return 1; } int func2 (void) { return 2; } int func3 (void) { return 3; }
typedef int (*func)(void);
func state[] = { func1, func2, func3 };
void main (void) { char i,j; for (i = 0; i < 3; ++i) { j = (*state[i])(); } } Yeah, that definitely doesn't work, even with all of the wonderful changes that Uli made to HuC. You've still got to drop down into assembly-language to create/use those in the new HuC. <edit> But ... the new HuC does actually support typedef and void now, so it's really beginning to look a lot more like normal modern C code.
|
|
|
Post by alekmaul on Aug 1, 2018 5:53:16 GMT
it seems there is a small typo in documentation (clibref). We're still talking about get_tile function. This function seems to be rename to map_get_tile.
|
|
|
Post by theoldman on Aug 1, 2018 7:01:03 GMT
I don't remember talking about get_tile(). The problem is in put_tile(). see the function above map_get_tile in clibref. Either/both. Yeah, they can be done in asm, but they have to reside in the same 8k block. The auto-mapping doesn't work for them. (Yeah, I know how to do it, and have done so. It's just a pain, especially with a half-dozen or so different object types)
|
|
|
Post by gredler on Aug 1, 2018 17:11:14 GMT
Lol looks like I started this thread, but man what an awesome one to have! Thanks for the contributions and discussion, HuC!
|
|
|
Post by alekmaul on Aug 1, 2018 19:13:31 GMT
I don't remember talking about get_tile(). The problem is in put_tile(). see the function above map_get_tile in clibref. And I'm not talking to you , it is about a bug I found in current Elmer documentation (clibref_fr.htm). My purpose was to inform him, that's all.
|
|
|
Post by elmer on Aug 2, 2018 20:40:11 GMT
it seems there is a small typo in documentation (clibref). We're still talking about get_tile function. This function seems to be rename to map_get_tile. Yeah, the current documentation is an absolute mess. The French text file is out-of-sync with the English text file, and the html versions look like they are out-of-sync with both of them. I'm actually reluctant to make any changes to them at all, it seems like too much of a can-of-worms! But thank-you for the report. If I do edit the files, I'll bear that in mind.
|
|
burke
What's a PC Engine?
Posts: 2
|
Post by burke on Aug 30, 2018 15:35:44 GMT
Hi, I got jbrandwood/huc to compile under FreeBSD using Clang, but I had to suppress some warnings. I've submitted a pull-request for this on GitHub. I've got some questions now: 1. While perusing the examples I noticed that "shmup" is silent, even though it should feature both music and sfx. I've tested it with both Mednafen and a real PCE. When looking at in Mednafen's debugger the PSG channels show no signs of life. Can anyone confirm that the bgm/sfx works for them? Pointers to what might be wrong are also appreciated. 2. tgemu shows no screen. The program keeps running until I exit with ctrl+c, I've tried with both the examples and other roms. How is this supposed to work? (The source is beyond me.) And finally some suggestions for Elmer: a. I saw you have an updated feature list on this forum. You should put that in the GitHub README as well. b. Enable "Issues" for the GitHub repo. Thanks for all the hard work!
|
|
|
Post by elmer on Sept 7, 2018 17:58:03 GMT
Hi, I got jbrandwood/huc to compile under FreeBSD using Clang, but I had to suppress some warnings. I've submitted a pull-request for this on GitHub. Thank you so much for this. I'm back from my vacation in the desert now, and I'll take a look at the changes and your suggestions. I've enabled "Issues" in github now ... whoops, I didn't realize that I hadn't done that!!!
|
|
|
Post by elmer on Sept 9, 2018 19:33:09 GMT
1. While perusing the examples I noticed that "shmup" is silent, even though it should feature both music and sfx. I haven't taken a look at this, yet, but I'm guessing that it will be because I neutered Uli's only-partially-implemented-and-slow SimpleTracker PSG driver. That thing needs to disappear entirely, and new developers should either roll their own driver (unlikely), or use Aetherbyte's Squirrel or my Huzak driver (when I release it). Please remember folks ... HuC is a multi-decade-long collection of different developer's disparate, and often unfinished, parts. Apart from bug fixing, there's really very little more that I want to change in the current HuC. Instead, I'd rather take everything, tidy it all up, refactor it, make technical and documentation improvements, and then release a HuC4 ... which folks can choose to either use or ignore. 2. tgemu shows no screen. The program keeps running until I exit with ctrl+c, I've tried with both the examples and other roms. How is this supposed to work? (The source is beyond me.) It's not supposed to be a game-playing emulator. Uli added it to HuC in order to do the regression-testing for the HuC compiler. It is supposed to run short test programs and then return a "succeeded" or "failed" code to the testsuite. If you want an full PCE emulator to run on FreeBSD, then I suggest that you compile mednafen, it's in the FreeBSD ports tree. a. I saw you have an updated feature list on this forum. You should put that in the GitHub README as well. Please see the "whats.new" file for detailed change lists. b. Enable "Issues" for the GitHub repo. Done!
|
|
burke
What's a PC Engine?
Posts: 2
|
Post by burke on Sept 14, 2018 18:42:26 GMT
[...] I'm guessing that it will be because I neutered Uli's only-partially-implemented-and-slow SimpleTracker PSG driver. That thing needs to disappear entirely, and new developers should either roll their own driver (unlikely), or use Aetherbyte's Squirrel or my Huzak driver (when I release it). Squirrel seems nice, but there doesn't seem to be any source included and the binary release is Windows only. It does seem to run fine under Wine though. At what point of development are you with Huzak? Will it be open source software and are you planning on integrating it with HuC4? [...] I'd rather take everything, tidy it all up, refactor it, make technical and documentation improvements, and then release a HuC4 ... which folks can choose to either use or ignore. I noticed you already have a HuC4 repo on GitHub, is that where your future development will be concentrated?
|
|