|
Post by elmer on Jun 21, 2022 14:36:56 GMT
As far as I understand, the HuC's system code bank is overflow... In a test application... elmer , Just in case, I've sent you the test app. Again, thanks for the test app, that helps show what is happening. Basically, you've not understood what I've told you about how to add assembly-language code into a HuC project, and between mpd.h, spd.h and now scale_2x.asm you're trying to add over 1.5KBytes of extra code into LIB1_BANK, and there just isn't room for it. Please take a look at the file "include/huc/sgx_gfx.asm", and see how it splits each assembly-language function into one small part (with the maplibfunc) that goes into LIB1_BANK, and then the actual function itself is put in LIB2_BANK. In your case you need to still put the small maplibfunc part in LIB1_BANK, but your code should go into LIB3_BANK ... at which point you'll need to define "HAVE_LIB3 = 1" in the file "lib_exclude.asm". If this all sounds like a horrible mess ... it kinda is, but that's historical, and unlikely to change. You do have another alternative, and that is to take a look at the assembly-language code that HuC produces, and rewrite your assembly-language functions as PCEAS "procedures" with .proc and .endp. If you do that, then PCEAS handles all of the banking and relocation for you. If you take a look at the library functions in "examples/asm/elmer/include/" you'll see that nearly-all of the functions are procedures, except for a few tiny bits of code in common.asm Whichever method you choose to use ... you CANNOT just keep dumping large chunks of code into LIB1_BANK! Good luck!
|
|
|
Post by 0x8bitdev on Jun 21, 2022 18:07:22 GMT
elmer, Thanks again! Actually I do not know what is the 'lib_exclude.asm' and 'libslot1.asm'. It is just a legacy code that somehow works for me... So, in short:1. A code in a pure assembly will be placed in LIB1_BANK by default. The LIB1_BANK memory is not rubbery. 2. Use 'maplibfunc' if you want to place your code optimally in the HuC's library space. 3. Use .proc/.endp to simplify your life. The .proc/.endp looks like a piece of cake. Are there any cons of using .proc/endp ?
|
|
|
Post by elmer on Jun 22, 2022 12:35:55 GMT
Actually I do not know what is the 'lib_exclude.asm' and 'libslot1.asm'. It is just a legacy code that somehow works for me... They are things that were added to HuC last year by turboxray as one method to try to get around the difficulties of adding new library code to HuC. They should work fine, but you have to follow the appropriate steps, which both aren't documentented, and rely on a knowledge of how HuC works, so I can easily understand that it's a bit of a mystery to you. I'm sorry for that, there just haven't been many people trying to expand HuC's capabilities over the years, and you're getting caught by all of the undocumented traps that are part of the legacy codebase! 1. A code in a pure assembly will be placed in LIB1_BANK by default. The LIB1_BANK memory is not rubbery. 2. Use 'maplibfunc' if you want to place your code optimally in the HuC's library space. 3. Use .proc/.endp to simplify your life. Yes, that's right (from my personal point-of-view). The .proc/.endp looks like a piece of cake. Are there any cons of using .proc/endp ? As long as you understand that the assembly can and will automatically move different procedures into different banks, that you MUST save and restore MPR4 if you need to change it within a routine, and that you execute procedures with a "CALL" instruction rather than a "JSR" instruction ... then "no", from my point-of-view there are no significant "cons", and procedures are really easy to use for library code. If you look at my library code in "examples/asm/elmer/include", you'll also see the use of ".procgroup" and ".endprocgroup", which the HuC compiler itself never uses. Those allow you to group together a set of individual procedures (and other code), and tell the assembler to put them ALL into the same bank. Good luck!
|
|
|
Post by 0x8bitdev on Jun 22, 2022 16:33:41 GMT
Thanks for clarifying the situation. As long as you understand that the assembly can and will automatically move different procedures into different banks, that you MUST save and restore MPR4 if you need to change it within a routine, and that you execute procedures with a "CALL" instruction rather than a "JSR" instruction ... then "no", from my point-of-view there are no significant "cons", and procedures are really easy to use for library code. It is something new! 'CALL' is a macro for calling procedures? If you look at my library code in "examples/asm/elmer/include", you'll also see the use of ".procgroup" and ".endprocgroup", which the HuC compiler itself never uses. Those allow you to group together a set of individual procedures (and other code), and tell the assembler to put them ALL into the same bank. The '.procgroup' and '.endprocgroup' are useful things, especially when there is no banks switching between library calls. --------------- My question is about the .proc/.endp. With simple routines everything is clear. But, for example, I have the same routine with 4 and 3 arguments. Initially my code looked like this: _foo.4:
.. some code ... ...
_foo.3:
.. some code ... ...
rts
With the .proc/.endp I just need to wrap it... _foo.4 .proc
.. some code ... ...
_foo.3:
.. some code ... ...
rts
.endp
...or it's not as simple? [upd]: or _foo.4 .proc
.. some code ... ...
call _foo.3 rts
.endp
_foo.3 .proc
.. some code ... ...
rts
.endp
|
|
|
Post by 0x8bitdev on Jul 11, 2022 14:21:13 GMT
Another one "gift"... But this time the HuC level is passed. Welcome to the next level! Now PCEAS throws an internal error. I have the following output: B:\my_projects\crossdev\GITHUB\MAPeD-SPReD\samples\pce\sprite_render\animation_test\huc2>huc -fno-recursive -msmall main.c PC Engine Assembler (v 4.00-bfd3ee0-dirty, 2022-06-18)
PCE_INCLUDE = "E:\programs\crossdev\HUC\include\huc\"
pass 1 pass 2 .proc trampolines between $8000-$807D are overwritten by code or data!
BANK B 597/7595 DATA $E000-$E254 [ 597]
HuC (v4.00-bfd3ee0-dirty, 2022-06-18)
No errors The program compiles well, if I do not use the PCEAS's optimized procedure packing algorithm. huc -s -fno-recursive -msmall main.c pceas main.s
Does it make sense to ignore -O or can this issue be resolved? The test program is hereBackstory. This is a one of the SPReD-PCE sample projects that has always compiled without problems, but recently I have optimized meta-sprites data. Now meta-sprites data takes up less memory and this error has appeared.
|
|
|
Post by elmer on Jul 11, 2022 14:42:25 GMT
.proc trampolines between $8000-$807D are overwritten by code or data! That error message is telling you something important ... the question is WHY are the trampolines being overwritten, because that shouldn't ever happen when building a HuC program, only an ASM program where you have chosen to take control of where the trampolines are located. I'll take a look at the test and see what is going on, and in the meantime, you can do a 2-stage (HuC then PCEAS) build and remove the -O from the PCEAS part of the command line.
|
|
|
Post by elmer on Jul 11, 2022 19:48:34 GMT
Another one "gift"... But this time the HuC level is passed. Welcome to the next level! Now PCEAS throws an internal error. Hahaha ... you keep on doing "interesting" things that nobody else has ever done before, and you're helping to flush out some very old bugs in the toolchain! In this case, the assembly-language code from SPRed (rather than the sprite or other binary data) has crossed a bank boundary and has increased the size of the ROM, but PCEAS doesn't recognize that fact until the LAST_PASS, which is too late, and which causes PCEAS to put the procedure trampolines into the wrong bank. Wow ... the underlying code and reason for the problem goes back at-least as far as HuC v3.21, and probably earlier, but it was hidden because you weren't allowed to assemble data across banks. You're probably the first person to get hit by the bug because you're first to be including large amounts of auto-generated assembly-language data within a HuC project. Nice find! And once-again, thank you for providing an example so that I could track down the problem. Anyway, this should be fixed now, and you can grab the latest build from github.
|
|
|
Post by 0x8bitdev on Jul 12, 2022 8:56:51 GMT
Let's make HuC better together! Good slogan. Thanks for fixing that!
|
|
|
Post by hyperfighting on Aug 3, 2022 23:33:24 GMT
elmer I'm just chiming in in a hope you might consider implementing the compiler to throw a syntax error if a function has the wrong number of arguments. One challenge that has thrown me through a loop literally haha is when I change the number of arguments passed to a function and then forget to change some instances where the function is called. In other environments I get shutdown on compile and use that as my clue where the instances need to be adjusted. HuC compiles regardless of the number of arguments passed and then the results are generally a crash when the code runs. In some cases the crash isn't immediate and it makes me wonder where the heck and why the heck etc...
|
|
|
Post by elmer on Aug 4, 2022 15:35:50 GMT
I'm just chiming in in a hope you might consider implementing the compiler to throw a syntax error if a function has the wrong number of arguments. I don't think that's possible within the context of HuC, AFAIK it doesn't do any parameter-validation on function calls. IIRC, the ability to pass different numbers of parameters to functions that have the same name is used fairly-often within the HuC libraries themselves, which is the standard-C equivalent of having variadic functions. Sorry, but I think that you're just going to have to deal with the debugging headache!
|
|
dogen
Deep Blooper
Posts: 30
|
Post by dogen on Aug 4, 2022 16:42:37 GMT
btw i'm still around guys. i'm trying to study some asm so i can program some fancier fx
|
|
|
Post by hyperfighting on Aug 4, 2022 17:19:32 GMT
elmer thanks for getting back to me on the argument checking. I figured I would mention it as it has been one of the major issues I have come across from time to time. I accept nothing can be done
|
|
|
Post by hyperfighting on Sept 1, 2022 14:35:05 GMT
elmer - I am getting the message "No more space in bank for .proc trampoline!" This message appears after I wrote a function. I literally wrote the function and the function has no instances it just sits dormant. If I comment the function out my code complies as per normal. Is this the straw that breaks the camels back? Is it simply a case I have exceed the space for my program code? Any advice would be would be super helpful! My function is pretty basic it does call some other basic switch less functions but I have a feeling its not the function that is the issue but the space I have available. void ZUK_FLIP_JUMP() { changeState (VERTICAL_MOVEMENT); //Minor function one IF statement changeSubState1 (ZUK_JUMP); //Minor function one IF statement changeSubState2 (ZUK_JUMP); //Minor function one IF statement changeSubState3 (NOT_ASSIGNED); //Minor function one IF statement
if (reverseGravity[vramSlot]==ON) { reverseGravity[vramSlot]=OFF; } else { reverseGravity[vramSlot]=ON; }
if (flipState[firstActor[vramSlot]]==NO_FLIP) { flipState[firstActor[vramSlot]]=FLIP_Y; flipState[firstActor[vramSlot]+1]=FLIP_Y; flipState[firstActor[vramSlot]+2]=FLIP_Y; flipState[firstActor[vramSlot]+3]=FLIP_Y; } else if (flipState[firstActor[vramSlot]]==FLIP_X) { flipState[firstActor[vramSlot]]=FLIP_XY; flipState[firstActor[vramSlot]+1]=FLIP_XY; flipState[firstActor[vramSlot]+2]=FLIP_XY; flipState[firstActor[vramSlot]+3]=FLIP_XY; } else if (flipState[firstActor[vramSlot]]==FLIP_Y) { flipState[firstActor[vramSlot]]=NO_FLIP; flipState[firstActor[vramSlot]+1]=NO_FLIP; flipState[firstActor[vramSlot]+2]=NO_FLIP; flipState[firstActor[vramSlot]+3]=NO_FLIP; } else if (flipState[firstActor[vramSlot]]==FLIP_XY) { flipState[firstActor[vramSlot]]=FLIP_X; flipState[firstActor[vramSlot]+1]=FLIP_X; flipState[firstActor[vramSlot]+2]=FLIP_X; flipState[firstActor[vramSlot]+3]=FLIP_X; }
//IF I COMMENT OUT A) THE WHOLE FUNCTION OR B) JUST THESE TWO LAST LINES MY CODE COMPILES x[firstActor[vramSlot]+3]=x[firstActor[vramSlot+1]]; y[firstActor[vramSlot]+3]=y[firstActor[vramSlot+1]]; }
|
|
|
Post by elmer on Sept 1, 2022 19:47:35 GMT
elmer - I am getting the message "No more space in bank for .proc trampoline!" This message appears after I wrote a function. I literally wrote the function and the function has no instances it just sits dormant. If I comment the function out my code complies as per normal. Is this the straw that breaks the camels back? Is it simply a case I have exceed the space for my program code? It is possible that you've hit the limit of code size, but pretty unlikely. It's far more likely to be that something else is wrong, and that you're getting that message by mistake. You'd have to send me your code if you want me to find the problem. BTW, in a separate note ... HuC is going to generate *really* bad code for that function, it doesn't do well with arrays.
|
|
|
Post by hyperfighting on Sept 1, 2022 20:00:29 GMT
Many thanks for looking into this elmer ! Any advice is greatly appreciated! The codes are in your inbox. [upd] Things progressed since my last message (above). The status now is I commented several functions out so I could keep working...
|
|