|
Post by 0x8bitdev on May 24, 2022 18:30:29 GMT
0x8bitdev , if you build HuC from source, you can grab the contents of my repo, but be aware that we're in the middle of moving stuff around for the transition to an "organization". As mentioned in the other thread, the biggest user-facing change is that you need to change "include/pce" to "include/huc". On Windows I use compiled binaries... How, where, when compiled version with the latest changes will be available?
|
|
|
Post by elmer on May 24, 2022 22:31:26 GMT
On Windows I use compiled binaries... How, where, when compiled version with the latest changes will be available? Both release builds and current daily-builds should eventually be available on the "organization"'s github in the future, but we're not quite there yet. In the meantime, I've made the current Win64 build available in the stickied post at the top of Elmer's PC Engine Programming Resource Links. As mentioned before, and as I'll no-doubt need to say again, in order to use this you need to change your PCE_INCLUDE environment variable from "<wherever-huc-lives>/include/pce" to "<wherever-huc-lives>/include/huc". Because the batch file in the example that you sent me had you running huc.exe and then running pceas.exe again afterwards (why?), you also need to know that you must now pass "-O" to PCEAS in order for it to activate its optimized procedure-packing. This used to be the default with Uli's version of HuC, but PCEAS has now been changed to not do that by-default so that its default behavior is to produce identical output to PCEAS v3.21. If you allow huc.exe to automatically run PCEAS, then it passes the new flag, and HuC behaves just the way that it has for the previous 6 years.
|
|
|
Post by 0x8bitdev on May 25, 2022 8:45:15 GMT
Thanks for the updated archive. This will help everyone who uses compiled binaries stay up to date with the last changes, while the automated build system in development. Because the batch file in the example that you sent me had you running huc.exe and then running pceas.exe again afterwards (why?)... Thanks for the comment! That's my mistake. That was a 'hard legacy' of my assembly samples. After that I just added the huc line and was happy. ...you also need to know that you must now pass "-O" to PCEAS in order for it to activate its optimized procedure-packing. This used to be the default with Uli's version of HuC, but PCEAS has now been changed to not do that by-default so that its default behavior is to produce identical output to PCEAS v3.21. If you allow huc.exe to automatically run PCEAS, then it passes the new flag, and HuC behaves just the way that it has for the previous 6 years. Ok, I'll use it.
|
|
|
Post by 0x8bitdev on Jun 5, 2022 14:43:38 GMT
I got the following warning:
B:\my_projects\crossdev\GITHUB\MAPeD-SPReD\samples\pce\sprite_render\Zuks_Test\huc>huc -s -fno-recursive -msmall main.c HuC (v3.99-master-0-g20ba36e, 2022-05-24) defenum (null) enum base type 9
No errors
B:\my_projects\crossdev\GITHUB\MAPeD-SPReD\samples\pce\sprite_render\Zuks_Test\huc>pceas -S main.s PC Engine Assembler (v 3.25-master-0-g20ba36e, 2022-05-24)
pass 1 (Warning. Opcode crossing page boundary $8000, bank $0B) pass 2 segment usage:
USED/FREE ZP $2000-$2026 [ 39] 39/ 217 BSS $2200-$2BA7 [2472] 2472/5720
BANK 0 Base Library 1 8031/ 161 CODE $E010-$FF64 [8021] CODE $FFF6-$FFFF [ 10] BANK 1 Base Library 2/Font 5885/2307 DATA $6000-$65FF [1536] CODE $A600-$B6FC [4349] BANK 2 Constants 117/8075 DATA $4000-$4074 [ 117] BANK 3 User Program 8192/ 0 DATA $6000-$7FFF [8192] BANK 4 8192/ 0 DATA $6000-$7FFF [8192] BANK 5 8192/ 0 DATA $6000-$7FFF [8192] BANK 6 8192/ 0 DATA $6000-$7FFF [8192] BANK 7 8192/ 0 DATA $6000-$7FFF [8192] BANK 8 8192/ 0 DATA $6000-$7FFF [8192] BANK 9 8192/ 0 DATA $6000-$7FFF [8192] BANK A 8192/ 0 DATA $6000-$7FFF [8192] BANK B 8192/ 0 DATA $6000-$6001 [ 2] DATA $8002-$8428 [1063] DATA $6429-$7FFF [7127] BANK C 3912/4280 DATA $6000-$6F47 [3912] BANK D 7915/ 277 CODE $A000-$BEEA [7915] BANK E 7825/ 367 CODE $A000-$BE90 [7825] BANK F 288/7904 PROC $8000-$811F [ 288] ---- ---- 106K 22K
TOTAL SIZE = 128K
Why does this happen? What data cannot cross page boundaries?
|
|
|
Post by elmer on Jun 5, 2022 16:13:36 GMT
Why does this happen? What data cannot cross page boundaries? What you're seeing is an artefact of the original design decisions that were made when David Michel and Charles Doty modified J.H. Van Ornum's old as6502 assembler source to create PCEAS/NESASM. At that time, the decision was made that each 8KByte PCE/NES bank would be completely separate, and that no code or data should be allowed to cross from one bank to the next, because that was "obviously" the sign of a bug in the user's program. Eventually, they realized that it was massively useful for *some* kinds of graphics data to be allowed to overflow one bank into the next, and so the restriction was limited for certain assembly language pseudo-ops, but not for others. This was the case all the way through HuC v3.21, until turboxray finally got annoyed-enough a few years ago that he added the capability to assemble code across bank boundaries, and he changed the previous "error" into a "warning", which is what you've just encountered here ... BANK A 8192/ 0 DATA $6000-$7FFF [8192] BANK B 8192/ 0 DATA $6000-$6001 [ 2] DATA $8002-$8428 [1063] DATA $6429-$7FFF [7127]
So the answer is that currently, there is very little, maybe nothing at all, that can't cross page/bank boundaries ... but you sometimes get a warning message, and as you can see, the "page" mapping of the data can be a bit weird and buggy, which is because of PCEAS not being consistant about how it both processes and reports the bank crossings. This is what I'm currently trying to fix.
|
|
|
Post by 0x8bitdev on Jun 6, 2022 13:22:41 GMT
elmer Thanks for the detailed answer! Can I be sure that the program will work correctly with such a warning?
|
|
|
Post by elmer on Jun 6, 2022 18:28:40 GMT
Can I be sure that the program will work correctly with such a warning? As long as the displayed data address doesn't wrap around from $FFFF->$0000, then I believe that you should be OK with the current build. If you do have code or data that wraps around 64KB, then you'll need the fixes that I'm still working on.
|
|
|
Post by 0x8bitdev on Jun 17, 2022 14:59:09 GMT
I got the following error:
B:\my_projects\crossdev\GITHUB\MAPeD-SPReD\samples\pce\sprite_render\Zuks_SPReD\huc>huc -fno-recursive -msmall main.c HuC (v3.99-2c19b90-dirty, 2022-06-07) defenum (null) enum base type 9 ;error: main.c(224) ;struct Entity ; ^ ;****** struct table overflow ****** ;error: main.c(225) ;{ ;^ ;****** illegal symbol name ****** ;error: main.c(225) ;{ ;^ ;****** syntax error ****** ;error: main.c(226) ; int x; ; ^ ;****** missing open paren ****** ;error: main.c(226) ; int x; ; ^ ;****** too many errors, aborting ******
What does it mean?
|
|
|
Post by elmer on Jun 17, 2022 17:38:21 GMT
It means that you're mistaking HuC for a modern compiler again ... "enum"? Really? In this case it looks like you've hit the limit on the maximum number of different "struct" members that can be defined ... and that may well include all enums. The limit is currently defined as 128, but there's probably no harm in increasing that to 256. I'll let let you know when there's a new build, but I can't make the change until tonight, I'm in the middle of making other changes that aren't quite ready to be checked-in yet.
|
|
|
Post by 0x8bitdev on Jun 17, 2022 19:40:38 GMT
It means that you're mistaking HuC for a modern compiler again ... "enum"? Really? Oh, those bad habits!.. In this case it looks like you've hit the limit on the maximum number of different "struct" members that can be defined ... and that may well include all enums. The limit is currently defined as 128, but there's probably no harm in increasing that to 256. I've deleted the only enum I used. Will wait for a new build. Is this a limitation for all members of all structures, or for members per one 'struct' ?
|
|
|
Post by elmer on Jun 18, 2022 0:24:39 GMT
I've deleted the only enum I used. Will wait for a new build. Is this a limitation for all members of all structures, or for members per one 'struct' ? The change is checked-in, and the automated build has passed the tests ... good luck! I *think* that the limit is the total number of of structure member definitions, and not structure member instances ... but I don't really know for sure. As I have said before, I don't actually use HuC.
|
|
|
Post by 0x8bitdev on Jun 18, 2022 16:17:40 GMT
elmer, Unfortunately the last HuC changes have not solved the compilation error. I've sent you a test project via PM.
|
|
|
Post by elmer on Jun 18, 2022 18:32:47 GMT
elmer , Unfortunately the last HuC changes have not solved the compilation error. I've sent you a test project via PM. Thanks for the test project, as you know, being able to reproduce a problem makes it so much easier to track down! It turns out that there is also a limit on the total number of different structure definitions in HuC ... which I have increased from 10 to 64. The change is checked-in, and once again there's a new automated-build on github. FWIW ... this new build also marks a change in the HuC/PCEAS/ISOlink version number to v4.00!
|
|
|
Post by 0x8bitdev on Jun 18, 2022 18:48:57 GMT
elmer , Thanks a lot! Using HuC is like walking on the minefield. You never know what step will the last one.
|
|
|
Post by 0x8bitdev on Jun 20, 2022 17:07:39 GMT
Another surprise from HuC! B:\my_projects\crossdev\GITHUB\MAPeD-SPReD\samples\pce\sprite_render\Zuks_SPReD\huc>huc -s -fno-recursive -msmall main.c HuC (v4.00-bfd3ee0-dirty, 2022-06-18)
No errors
B:\my_projects\crossdev\GITHUB\MAPeD-SPReD\samples\pce\sprite_render\Zuks_SPReD\huc>pceas -S main.s PC Engine Assembler (v 4.00-bfd3ee0-dirty, 2022-06-18)
PCE_INCLUDE = "E:\programs\crossdev\HUC\include\huc\"
pass 1 #[1] main.s 3406 01:0001 jsr _spd_farptr_add_offset CODE section wrapped from MPR7 to MPR0! # 1 error(s)
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.
|
|