Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 21, 2019 5:51:53 GMT
Alright I've been trying to jump into a HuC overlay built with -scd -overlay, my extremely simple method is: JMP $2648 $2648: JSR cd_read JMP $C000 Certainly nothing fancy there and all based on the fact that first bank ($68) has ovlentry in it (also thanks whoever decided to make $2648 to $2680 a no-man's land). This was working fine in one HuC project, but in another one it does this weird thing where $68 gets mapped both into MPR6 and MPR5, so it goes from $C000 to $A000 into ovlentry, that jumps into $A000 into ovlentry, etc. Since I'm lacking in HuC knowledge, I'd like to ask people who actually worked on it for pointers on how to actually setup and run an overlay after it's fully copied to System Card RAM. This is a important since I'm trying to make CD System Card wrappers to HuC that don't depend on the ISOLink/ovlarray table to work, and this is holding back progress on a lot of stuff I'm trying to do. Give me a hand here, bros. EDIT: Can someone tell me if there's an issue in using C #defines for function parameter values? That might be the issue I'm facing right now. It seems that if I type in "24" manually as the overlay size in my function parameter it works, but if I do a #define blablah 24 and use that instead, the compiled code has the value 1 coming out of the parameter stack. It even shows in the .s file as '__ldwi 24' but I can see it writing '1' to the stack on Mednafen. I don't get it.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 21, 2019 7:11:35 GMT
Ok there's definitely a bug in how #defines are implemented in HuC 3.999999: Minimal example: Expected result: 24, 24, 24 for SECSIZE_Game = 24. #define SECSIZE_Game 24 inside the same .c file as main: #include "labels.h" with #define SECSIZE_Game 24 inside it: Yeah I think something's not right
|
|
|
Post by elmer on Oct 21, 2019 20:34:05 GMT
Ok there's definitely a bug in how #defines are implemented in HuC 3.999999: Thanks for reporting this, and for reducing the problem down to a small example! I'll take a look and find out what's going wrong.
|
|
|
Post by DarkKobold on Oct 21, 2019 23:29:27 GMT
Ok there's definitely a bug in how #defines are implemented in HuC 3.999999: Minimal example: Expected result: 24, 24, 24 for SECSIZE_Game = 24. #define SECSIZE_Game 24 inside the same .c file as main: #include "labels.h" with #define SECSIZE_Game 24 inside it: Yeah I think something's not right This is really, really dumb, but if you switch labels.h to labels.c, does it work correctly? I've never had an issue with defines, and I use them a ton.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 21, 2019 23:57:05 GMT
Same thing really. Ark actually helped me find out what was causing the issue later on.
Doing a declaration plus assignment at the same time causes it. For instance...
#include "a.h" //-> #define aaa 9
unsigned char myFunction(int param){
int somethingUnrelated = 50;
put_number(param, 6,0,5);
}
int main() { myFunction(aaa); }
Yields incorrect values after compilation, but moving the assignment out of the declaration fixes it.
#include "a.h" //-> #define aaa 9
unsigned char myFunction(int param){
int somethingUnrelated;
somethingUnrelated = 1234;
put_number(param, 6,0,5);
}
int main() {
myFunction(aaa);
}
HuC is really infuriating sometimes, that's something I don't want to have anything with after this
|
|
|
Post by Arkhan on Oct 22, 2019 5:08:41 GMT
The other problem is your opening braces are in the wrong spot.
ayyyyyyyyyyyyyyyyyyyyyyyyy.
I could have sworn HuC error'd out if you declared/assigned on the same line, and was surprised that it worked and just mangled your #definery lol
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 22, 2019 6:05:29 GMT
No dude, the braces aren't the issue here. I think it's just the new preprocessor thing since this works fine on 3.21.
edit: what was here before was totally my fault, *snip*
|
|
|
Post by elmer on Oct 22, 2019 6:55:01 GMT
No dude, the braces aren't the issue here. I think it's just the new preprocessor thing since this works fine on 3.21. edit: what was here before was totally my fault, *snip* OK, ... just to be sure that I understand ... are you saying that I can ignore the original report, and just look at the example code that Arkhan posted? Sure, I can absolutely believe that something in Uli's preprocessor changes (or mine) broke things ... but if there's an example, it can be fixed, and then I can create a new test for the testsuite so that we can avoid regressing this in future releases.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 22, 2019 7:44:21 GMT
Ark didn't post any code The code is just a detailed example of what I vaguely wrote earlier (which was just a snippet of code and not a complete example). The problem was happening in the original "example" because I had an assignment alongside the declaration of local variables, so yeah you can ignore the first report.
|
|
|
Post by Arkhan on Oct 22, 2019 20:12:18 GMT
No dude, the braces aren't the issue here. I think it's just the new preprocessor thing since this works fine on 3.21. edit: what was here before was totally my fault, *snip* Dingus I was joking because you put your braces up top like a sinner. lol
|
|
|
Post by DarkKobold on Oct 22, 2019 20:56:47 GMT
Same thing really. Ark actually helped me find out what was causing the issue later on. Doing a declaration plus assignment at the same time causes it. For instance... #include "a.h" //-> #define aaa 9
unsigned char myFunction(int param){
int somethingUnrelated = 50;
put_number(param, 6,0,5);
}
int main() { myFunction(aaa); }
Yields incorrect values after compilation, but moving the assignment out of the declaration fixes it. TBH, I didn't even know HuC was capable of doing assignments at declaration.
HuC doesn't allow for midfunction variable declaration like some languages do, so I've always kept my variable declarations separate. Looks like I got lucky, because this bug would have been absolutely infuriating.
|
|
|
Post by Arkhan on Oct 22, 2019 21:26:46 GMT
Yeah, I THOUGHT it actually gave a compile error, and was surprised when Pumchochgho showed me it.
I'd been not declaring stuff and initializing it on the same line since before Insanity. I swear it was stated somewhere.
|
|
|
Post by dshadoff on Oct 22, 2019 21:51:37 GMT
In HuC 3.21, it was not valid to assign a value at definition. It would cause a compile error.
|
|
|
Post by elmer on Oct 22, 2019 21:54:11 GMT
Ark didn't post any code The code is just a detailed example of what I vaguely wrote earlier (which was just a snippet of code and not a complete example). Good point, that was your example code, and not Arkhan's! OK, I've built you examples using "HuC (v3.99-c266d57, 2018-07-07)", which is that last Windows build that I released, and with "HuC (v3.99-7030417, 2019-10-20)", which is compiled from the latest code that is in github. I've tried all four combinations of the "-msmall" and "-fno-recursive" options, and I'm seeing the correct result (i.e. "9") printed out in all cases, whether the assignment is on the same line as the declaration, or not. Ok there's definitely a bug in how #defines are implemented in HuC 3.999999: I don't recognize that build number, can you please confirm which version of HuC you're using?
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 23, 2019 9:33:26 GMT
It's 3.99-c266d57. I wish I didn't overwrite the problematic .c file. Oh well.
|
|