|
Post by Arkhan on Oct 23, 2019 17:27:39 GMT
It's 3.99-c266d57. I wish I didn't overwrite the problematic .c file. Oh well. you sent me a screenshot! YOU CAN REBUILD IT PUNCH. lol Wasn't it just #defines and a declaration/init on the same line?
|
|
|
Post by Arkhan on Oct 23, 2019 17:28:16 GMT
In HuC 3.21, it was not valid to assign a value at definition. It would cause a compile error. I think Punch said he tried this on 3.21 and it still built. We're really bad at keeping versions of exes straight when we're fucking around on Discord so who knows lol
|
|
|
Post by dshadoff on Oct 23, 2019 17:38:25 GMT
In HuC 3.21, it was not valid to assign a value at definition. It would cause a compile error. I think Punch said he tried this on 3.21 and it still built. We're really bad at keeping versions of exes straight when we're fucking around on Discord so who knows lol I was building an app in HuC 3.21 literally a few days ago, and it was very clear that definition and assignment in the same line will fail at compile... so I am quite confident. Unless there were different releases claiming to be 3.21 ...
|
|
|
Post by Arkhan on Oct 23, 2019 17:53:38 GMT
I think Punch said he tried this on 3.21 and it still built. We're really bad at keeping versions of exes straight when we're fucking around on Discord so who knows lol I was building an app in HuC 3.21 literally a few days ago, and it was very clear that definition and assignment in the same line will fail at compile... so I am quite confident. Unless there were different releases claiming to be 3.21 ... Yeah, that's a possibility, or he ran it in 3.99 again, or we confused each other while talking. I knew it wasn't allowed and let punch know, so I had to have seen the error before like 10 years ago to remember it lol.
|
|
|
Post by elmer on Oct 23, 2019 20:49:35 GMT
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. Uli's HuC improvements do allow you to declare variables in the middle of functions ... or, rather, at the beginning of a compound-statement (i.e. a block), which is the ANSI-C standard. It wasn't until the C99 standard that you could just delcare variables anywhere. Uli's HuC also has proper #define macros, unlike the old HuC 3.21.
|
|
|
Post by DarkKobold on Oct 24, 2019 0:28:12 GMT
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. Uli's HuC improvements do allow you to declare variables in the middle of functions ... or, rather, at the beginning of a compound-statement (i.e. a block), which is the ANSI-C standard. It wasn't until the C99 standard that you could just delcare variables anywhere. Uli's HuC also has proper #define macros, unlike the old HuC 3.21.
Are define macros the #ifdef? If so, those are a huge help for debugging modes.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 24, 2019 8:11:19 GMT
Found it on my chatlog with Ark. This was the problematic program. This is the header file.
|
|
|
Post by elmer on Oct 24, 2019 17:22:04 GMT
Are define macros the #ifdef? If so, those are a huge help for debugging modes. AFAIK, the old HuC already had "#ifdef", IIRC I think that it's used in a bunch of places. Yep, it's very useful for debugging ... although the old HuC didn't have the corresponding "#if", which the new HuC also has. What I was (poorly) referring to was macro functions, which the old HuC also did not have. That's something like ... #define addition(a, b) a + bIt can be very, very useful for making readable code.
|
|
|
Post by gredler on Oct 24, 2019 17:38:26 GMT
Artist trying to understand coding warning - excuse my ignorance please! Would macros be a sort of simple way of creating functions that are commonly used to call them in larger sets of code?
|
|
|
Post by elmer on Oct 24, 2019 17:39:15 GMT
Errr, punch ... I typed in those examples, adding some missing defines for the game overlay ... #define ADDR_IPL 0 #define SIZE_IPL 4096 #define SECSIZE_IPL 2
#define ADDR_Title_Screen 2 #define SIZE_Title_Screen 40960 #define SECSIZE_Title_Screen 20
#define ADDR_Game 22 #define SIZE_Game 49152 #define SECSIZE_Game 24
#define ADDR__CDROM_Specs_Padding 46 #define SIZE__CDROM_Specs_Padding 262144 #define SECSIZE__CDROM_Specs_Padding 128
#include "huc.h" #include "labels.h"
main () { int framecount = 0; int a;
set_color_rgb(1,0,0,0); set_color_rgb(2,7,7,7);
set_color_rgb(17,7,7,7); set_color_rgb(18,1,1,1);
set_font_color(2,1); set_font_pal(0);
load_default_font();
a = SECSIZE_Game; put_number(SECSIZE_Game, 6, 0, 5); put_number(24, 6, 0, 6); put_number(a, 6, 0, 7); }
And it works fine when compiled with "HuC (v3.99-c266d57, 2018-07-07)", printing "24 24 24" with whatever optimization settings I use. Can you please try to repeat the problem on your computer with that code? Since your header file example doesn't actually define SECSIZE_Game, are you absolutely sure that you didn't have a SECSIZE_Game defined to "1" somewhere else in your code?
|
|
|
Post by elmer on Oct 24, 2019 21:12:51 GMT
Would macros be a sort of simple way of creating functions that are commonly used to call them in larger sets of code? Yes, they can be used that way, and often were far back at the distant dawn of time (or in the current HuC) ... but that particular use for them was replaced by inline functions in C99 (and long, long before that in most compilers). The point is that they are evaluated during compilation, and not during execution, and so they add no runtime overhead to the final program, but do use more memory because of the extra code that they generate. They can also be used to provide generic template functions which take different parameter types ... although that gets ugly really quickly. As much as C++ purists really hate them, they can also still be amazingly useful in C++ code. You can easily build a pretty-sophisticated and *fast* RTTI, type-introspection, and class-serialization solution with the help of some simple macro functions and some simple coding practices, even within the restrictions of the Embedded C++ subset of the language.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 24, 2019 21:53:05 GMT
Yeah I know exactly what happened: the HuC external .exe call to PCEAS sucks!
You might have seen my pyDiscMaker thread. The problem I had with HuC was that it would do this weird thing where it would invoke PCEAS to compile the generated .s file then immediately exit without waiting PCEAS to finish. Due to the way it works (it compiles the same overlay TWICE because we need to know what's the actual size of it to know where it'll end on the CD alongside other data, and the overlay needs to have the labels handy so it knows where the OTHER files will end up with, so we do a first "pass" merely to figure out how big are the overlays with bogus label values) sometimes the overlay versions would be mismatched with older compilations or error out (because the ovl isn't on disk yet!).
The generated labels set the PROGRAM binaries to size = 1, sectors = 1 on the first pass... and the reasoin I couldn't reproduce the error again is that I was both making the demo program AND fixing up the script at the same time, so it would do that weird thing where the label would resolve to 1 until the shell command parser and the actual commands changed to call HuC with the -s flag, THEN after it quits it would call PCEAS.
This it what the shell command tag and attributes would look like for compiling the source files defined in the .xml:
<compiler name="HuC SCD" command="huc -scd -overlay -s $filePath"/> And this is what it now looks like, after I worked around the issue:
<compiler name="HuC SCD" command="huc -scd -overlay -s $fileName.c & pceas -scd -overlay $fileName.s"/>
Yep. This was a totally unrelated issue and I'd probably be confused to this day about the "outdated overlay" issue if not for Ark to tell me he experienced that issue during the development of Insanity. This is definitely something that needs some work because any automated build script will get ruined by that curveball. And I only realized this was causing the #define problem when you wrote the key phrase 'are you absolutely sure that you didn't have a SECSIZE_Game defined to "1"'...
There are some other issues I've found but those might be just ANSI C jankiness (having an if (A && B), where B is a binary AND/OR operation always results in FALSE for me), alongside some errors that are only caught in the PCEAS stage (missing a comma or forgetting to define a global variable for instance). But those are admittedly pretty minor compared to a #define that goes wrong at random so no issue there.
The real issue is the lack of explanations of arguably pretty important stuff (how do you know what System Card banks are occuppied by the HuC overlay and critical code? What's the syntax for a farptr? How does farmemget even work? What MPR registers can I mess with without throwing a wrench into HuC's internals? Is it safe to do X/Y/Z? etc. etc.) Stuff like this is pretty well explained on the CD BIOS official manual (even if the text is not perfect and clumsily translated) and it would be nice to have the info somewhat handy instead of having to spelunk in HuC's asm libraries and source code. Even my original question in this thread went unanswered, which makes me very worried that no one actually knows OR doesn't really care to explain. It's no wonder the PCE is lacking on the homebrew side of things compared to other consoles. I think my script and Syscard wrappers solves this weird implementation of CD games via ISOLink, but if you look at what HuC is actually doing, it turns out to be too tightly coupled to ISOLink's goofy overlay table scheme. I have NO way of letting the user set up a System Card error overlay with my script simply because I don't know how the custom configurable jump works (so you have to let the default system card message appear -- or do it by hand but what doesn't with base HuC?), and who knows what obscure bug I'm going to end up triggering with my custom overlay loading code that can work WITHOUT the overlay table. It's all very infuriating and I can't imagine the headaches people who are working hard on real games have with HuC's quirks.
End of rant and uhh what was I talking about again? Oh yeah the bug isn't a bug but a result of an interaction with another bug.
|
|
|
Post by dshadoff on Oct 25, 2019 0:04:45 GMT
Yeah I know exactly what happened: the HuC external .exe call to PCEAS sucks! You might have seen my pyDiscMaker thread. The problem I had with HuC was that it would do this weird thing where it would invoke PCEAS to compile the generated .s file then immediately exit without waiting PCEAS to finish. I think you mean it "behaves differently than the way it was probably intended to". I can tell you that it was not intended to return prior to pceas completion, as you state. In main.c, the function execvp() is employed; I believe that this was David Michel's idea for cross-platform compatibility (as I had never used that function). According to all the man pages I have just consulted, they do not explicitly state the behaviour that the calling process is supposed to do - however, since the called process *replaces* the calling process in memory, it implies that the process space remains the same, and the calling process is not deemed to complete until the called process completes. What kind of build system are you using to invoke huc ? I am wondering whether it might be an issue with the calling make system spinning off a thread and not waiting... I haven't seen the behaviour you describe on any of my prior projects. There are some other issues I've found but those might be just ANSI C jankiness (having an if (A && B), where B is a binary AND/OR operation always results in FALSE for me), alongside some errors that are only caught in the PCEAS stage (missing a comma or forgetting to define a global variable for instance). But those are admittedly pretty minor compared to a #define that goes wrong at random so no issue there. For the (A && B), I would explicitly put parentheses around subordinate expressions; I don't believe that HuC differentiates between '&' and '&&' for order-of-operations. I agree that there could be better documentation, and I think collaboration could improve it. I think that one needs to come to terms with the fundamental concepts that: a) HuC is not a product. It has always been run by volunteers, and so contributions (such as in the direction of documentation) would always be helpful in a 'pay it forward' kind of way. b) The origins of a compiler that even works on a 6502 will have limitations, and sometimes those limitations will be the state of 'C' back in the '90's (which is different than today). c) The system itself is fundamentally limited, and one's expectations of a program fully in 'C' should not be high. I think that one should expect to dip their toes into assembler at times, and expect to read assembler from time to time (and to implement critical sections in it). Back to your questions... Several of the questions you ask above could easily be answered in a forum like this, but I rarely see them asked... Farptr is another thing that David Michel added - I'm not 100% clear on the syntax myself, but it basically works by passing the MPR value as a parameter and the address as another - so it's really 2 parameters but looks like 1. For the banks, "which can I mess with" really depends on context. Are you returning them to their original values afterward ? Are you "messing" during a possible interrupt ? If you turn off interrupts and return everything to its original value afterward, you can even mess around with the otherwise-sacrosanct MPR7 ($E000-$FFFF). The way farmemget works is: based on the absolute bank of the far memory, it temporarily maps that bank in one of the mappable data banks, then alters the read address to match (i.e instead of $9100, maybe it reads at $5100, if that bank is mapped in the $4000-$5FFF area). Unfortunately, HuC is far more complex than the CD BIOS functions which are exposed to the user, and so it isn't as trivially easy to explain as the CDROM System Card functionality. It definitely will help to dive into the assembler source, because it is heavily commented for precisely this purpose. I'm not clear on your statement about not being able to set up a System Card error overlay; that is clearly documented in "doc/huc/overlays.txt" and "src/isolink/main.c" ... Also, at Zeograd's Lair there is "Sample Code - CDROM overlays" here: www.zeograd.com/creation_download.php?lang=en&page=7Have you seen the sample code and projects there ? -> If not, I strongly suggest looking there for all sorts of examples. I can't speak much to versions of HuC after v3.21, but I can help (when I have time) identify whether something is a bug or not, and how it might be addressed. Dave
|
|
|
Post by elmer on Oct 25, 2019 2:13:01 GMT
I agree that there could be better documentation, and I think collaboration could improve it. I think that one needs to come to terms with the fundamental concepts that: a) HuC is not a product. It has always been run by volunteers, and so contributions (such as in the direction of documentation) would always be helpful in a 'pay it forward' kind of way. Yep.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 25, 2019 2:17:50 GMT
Hey I've seen that movie before. I disagree and that's all I'm saying on the matter.
|
|