The new fork of HuC

[spenoza]

The web is a highly customizable experience. Let us not condescend on the web browsing choices of others.

[elmer]

I'll pick it up tomorrow. E-mail me the latest compiler, too, when you get a chance, so I can check to see if I've broken anything else.

OK, I've checked in the SOUND_BANK change into github, made a build and emailed it to you.

So i should install and run someone elses (possibly buggy, possibly invasive) program when I can just turn Java and it's variants off? And lose the added bonus of no more forced ads and tons of spam? <sarc>

Also, keep in mind I'm on XP. Does firefox 34 even support plug-ins?

You can choose to live with whatever level of paranoia you like, especially if you wish to keep on accessing the internet with an out-of-date version of Firefox on an unsupported version of Windows. 

Nope, I didn't rebuild the MML because I didn't need to ... there's already a working MML file.

Yes, but it was built for an SCD. You need to re-build it for a CD, which involves specifying a cd-useable bank number.

And it all runs quite happily on HuCard, SCD, and now on CD, too.

And you already know that I need you guys to change mml2pce in order to add the "__" to the variable names.

Already in there, with the -p flag.

Thanks for adding that, and for finally making it available to me, yesterday, for testing.

Err ... I'm not seeing any problem with that. The new HuC is a bit more strict about where it puts the trampoline code for banking in the .proc functions.

So, if I understand this right....
It uses the entire last page for the trampoline code?

Well, the last "bank" not "page", but yes, that's what it appears (to me) to be doing, and then it maps it into MPR4 ($8000-$9FFF).

By declaring that the sound data starts in bank 6 (or 5, or 9), you're just pushing all of the code into later banks and wasting space.

Understood. But there's no reliable way to know the last-used bank ahead of time, that we have found. Of course, its been a few years since I looked at, and I've learned some things since then, so maybe I'll find a better way.
Keep in mind, this is a test program. Good tests highlight the problem only.

Well, it's up to you how you choose to organize your example code, but from where I'm sitting, you're just creating an artificial problem for HuC users by effectively-recommending a setup that forces all their HuC data and code into a smaller area.

Now I see why Catastrophy is sitting there with banks 5,6,7 and 8 completely empty, and with bank 4 just containing a totally-unused 200-byte table for program overlays.

I can only imagine that it all came about from the time that you guys were moving code/data from C into assembly.

[OldMan]

emailed it to you.

Got it. Thx.

Well, the last "bank" not "page", but yes, that's what it appears (to me) to be doing, and then it maps it into MPR4 ($8000-$9FFF).

Right, bank. (That's the 24-bit address in the card. I still get them confused.)
I assume its not going to be a problem with the MML being mapped into pages 4 and 5, then.

...if you wish to keep on accessing the internet with an out-of-date version of Firefox on an unsupported version of Windows. 

Hey, if it isn't broke, don't fix it

Thanks for adding that, and for finally making it available to me, yesterday, for testing.

It's been done for a couple of weeks. Was just waiting until I got the rest to be compatible.
I figured you'd get tired of fixing snginit(), though.

Now I see why Catastrophy is sitting there with banks 5,6,7 and 8 completely empty, and with bank 4 just containing a totally-unused 200-byte table for program overlays.

Feel free to move the mml into bank 5. It's simple enough to re-build the snginit() with a different page.

[elmer]

The point is to avoid new developers tripping over some black-magic problem and getting stuck by it.

This is exactly it, and I think it needs a special warning coming of PCEAS, at the end - "WARNING: Unstable ROM size - add data to 392k to fix corrupted mirroring " for exactly this fixed number of banks.

I've put a fix into the new HuC so that it always pads out a HuCard to the nearest power-of-2 ROM size (64KB, 128KB, 256KB, 512KB, 1024KB) so that nobody using it will ever hit this problem again.

For assembly-language users, there's a flag to PCEAS to invoke the option, and you'll get a warning message whenever you make a 384KB HuCard ROM without using that option ... which is a perfectly sensible thing to do if you're working on a translation patch for a 384KB Japanese game.

Now, to me, the simplest "fix" for this would be to add an optional flag to PCEAS to make it automatically pad HuCard ROMs to the nearest power-of-2, i.e. 64KB/128KB/256KB/512KB/1024KB.

Lol. <snort>. Changing HuC/PCEAS is probably going to be a pain.

Not really! 

31 lines of changes, and 13 of those were just adding the warning message. 


***********************

Here it is ...

http://www.dropbox.com/s/r5qbcz4xapapgye/huc-2017-02-21.zip?dl=0


And this is the changelog for the new version ...

New in version 3.99:
2017-02-21
- Fix writing of instructions/data that cross a bank boundary.
- Add "-pad" to PCEAS to pad out HuCard ROM images to next power-of-2 size.
- Change HuC to use "-raw" and "-pad" options to avoid 384KB HuCard problem.
- Add warning whenever a 384KB HuCard image is created to highlight problem.


Everything is in github for those folks that want to make their own build.

[DildoKKKobold]

http://www.dropbox.com/s/r5qbcz4xapapgye/huc-2017-02-21.zip?dl=0

C:\Huc\catastrophy>pass 1
#[3]   sound.asm
       00:FA3B                  .bank           PSG_BANK,"PSG Driver"
       Different bank names not allowed!
   (Warning. Opcode crossing page boundary $E000, bank $01)
# 1 error(s)

looks like it doesn't like squirrel anymore?

[Arkhan Asylum]

Well, that's odd.   Especially since that's the same bank name that PSG_BANK is given by the regular magic kit code.

[elmer]

C:\Huc\catastrophy>pass 1
#[3]   sound.asm
       00:FA3B                  .bank           PSG_BANK,"PSG Driver"
       Different bank names not allowed!
   (Warning. Opcode crossing page boundary $E000, bank $01)
# 1 error(s)

looks like it doesn't like squirrel anymore?

Have you changed the version of Squirrel from the one that I sent you a few months ago? 

If you remember, I had to make a bunch of changes to Squirrel to make it compatible with both the old HuC and the new HuC.

I'm having no trouble building the recent version of Catastrophy that you sent me, with the latest HuC build, and the modified Squirrel.

But if I change to the old sound.asm, then I get the same error that you're seeing.

Well, that's odd.   Especially since that's the same bank name that PSG_BANK is given by the regular magic kit code.

Errrr ... we went through this one page ago in this thread, starting with this post from TheOldMan ...

https://www.pcengine-fx.com/forums/index.php?topic=21350.msg480600#msg480600

... and we both agreed to change that PSG_BANK to SOUND_BANK ...

https://www.pcengine-fx.com/forums/index.php?topic=21350.msg480851#msg480851

I sent you guys the changes for using Squirrel with both the old HuC and the new HuC a few months ago, which included the change to SOUND_BANK.

[Arkhan Asylum]

Oh right.   I remember skimming/almost committing the SOUND_BANK rename to memory/getting sidetracked and forgetting about that bit.


I thought DK had already been utilizing the new Squirrel, hence more confusion.

but, I also thought he  mentioned he was switching to using Huzak?

[elmer]

Oh right.   I remember skimming/almost committing the SOUND_BANK rename to memory/getting sidetracked and forgetting about that bit.

Yep, it's so easy for stuff to just drop out of "current memory" when we switch between lots of different projects.

I'm back on the LoX translations at the moment, and it's taken me a while to remember where-on-earth I left off. 

I thought DK had already been utilizing the new Squirrel, hence more confusion.

Yep ... me too. I have no idea what's up with his local build setup. 

but, I also thought he  mentioned he was switching to using Huzak?

I think that they're wanting to do that at some point ... but I'm still not ready to give Huzak out to people, it's just not stable-enough yet.

Michirin9801 has found a bunch of new "compatibility" problems for me to fix.   

[Arkhan Asylum]

I've mostly got PCE on the backburners while I finish MSX.   I try to focus on one thing at a time so they get done sometime soon. 

[Sunray]

Hello, I'm trying to get my game up and running in this new version of HuC (previously used a fork of Uli's) but I'm having problems. I'm trying one commit at the time.

The following commit introduces this compile error:

Code Select Expand

commit: Fix arg_to_fptr() usage of magic numbers for argument types. 11/14/2016 08:16 John Brandwood

1>  ;error: pce/pce.c(479)
1>  ; case 0: map_data = pce_ep1_map00; pce_map_banks = bank( pce_ep1_map00); set_map_data( pce_ep1_map00 + 4, 32, 32); break;
1>  ;                                                                                                                ^
1>  ;******  can't get farptr  ******

Which is later fixed by this commit:

Code Select Expand

commit: Hack to fix Uli's fake-symbol kludge that was breaking arg_to_fptr(). That whole fake-symbol klud... 11/15/2016 09:43 John Brandwood
The game however is just completely broken when running in Mednafen. I guess I will have to try all commits in-between (which doesn't compile due to the farptr error above) to find which commit is actually breaking my game.

And finally this commit introduces an assemble error that is still present in the HEAD commit:

Code Select Expand

commit: Change System Card variables in "equ.inc" to use a "__" prefix. 11/16/2016 08:15 John Brandwood
1>  #[1]   game.s
1>   2073  16:A8FF            stx __ax
1>         Undefined symbol in operand field!
1>   2073  16:A902            sta __ax+1
1>         Undefined symbol in operand field!
1>   2075  16:A909              stx __cl
1>         Undefined symbol in operand field!
1>   2082  16:A91A              stx __dl
1>         Undefined symbol in operand field!
1>   2084  16:A921            stx __di
1>         Undefined symbol in operand field!
1>   2084  16:A924            sta __di+1
1>         Undefined symbol in operand field!
1>   2096  16:A934              stx __al
1>         Undefined symbol in operand field!
1>   2097  16:A939            sty __bl
1>         Undefined symbol in operand field!
1>   2097  16:A93E            sty __si
1>         Undefined symbol in operand field!
1>   2097  16:A943            sty __si+1
1>         Undefined symbol in operand field!
1>   2099  16:A94A              stx __cl
1>         Undefined symbol in operand field!
1>   2103  16:A954              stx __al

Not sure what the last one is about. Any pointers?

[elmer]

Hello, I'm trying to get my game up and running in this new version of HuC (previously used a fork of Uli's) but I'm having problems. I'm trying one commit at the time.
...
The game however is just completely broken when running in Mednafen. I guess I will have to try all commits in-between (which doesn't compile due to the farptr error above) to find which commit is actually breaking my game.

Thanks for giving the new compiler a try!

To be honest ... I don't think that you're going to have much luck going commit-by-commit and looking for a problem.

farptrs were horribly broken in Uli's HuC because of his excellent "symbol + offset" optimization, which you're invoking there with your "set_map_data( pce_ep1_map00 + 4, 32, 32);" line.

My early attempts to understand the code and figure out what was wrong sometimes caused other problems.

As far as I know, things are fixed now, but if you've found another corner-case that I'm not correctly dealing with, then I'll need to see some kind of example so that I can track down the problem.

And finally this commit introduces an assemble error that is still present in the HEAD commit:

Code Select Expand

commit: Change System Card variables in "equ.inc" to use a "__" prefix. 11/16/2016 08:15 John Brandwood
1>  #[1]   game.s
1>   2073  16:A8FF            stx __ax
1>         Undefined symbol in operand field!
1>   2073  16:A902            sta __ax+1
1>         Undefined symbol in operand field!
1>   2075  16:A909              stx __cl
1>         Undefined symbol in operand field!
1>   2082  16:A91A              stx __dl
1>         Undefined symbol in operand field!
1>   2084  16:A921            stx __di
1>         Undefined symbol in operand field!
1>   2084  16:A924            sta __di+1
1>         Undefined symbol in operand field!
1>   2096  16:A934              stx __al
1>         Undefined symbol in operand field!
1>   2097  16:A939            sty __bl
1>         Undefined symbol in operand field!
1>   2097  16:A93E            sty __si
1>         Undefined symbol in operand field!
1>   2097  16:A943            sty __si+1
1>         Undefined symbol in operand field!
1>   2099  16:A94A              stx __cl
1>         Undefined symbol in operand field!
1>   2103  16:A954              stx __al

Not sure what the last one is about. Any pointers?

Errrr ... yes.

Uli changed the names of the system variables from the old HuC's single underscore "_ax" to just "ax".

He did that so that the system variables don't conflict with variables that you create in HuC (which automatically have a single underscore added to them in C).

But in doing that, he just made them conflict with variable names that you declare assembly code, and made them inaccessible to C code.

What I did was to rename them all with a double_underscore, which follows standard C practice of using  a leading underscore in C for system/compiler variables, so "_ax" in C code becomes "__ax" in PCEAS after the C compiler has added its extra underscore to it.

Then in any assembly code, you use the "__ax" name.

If you're getting compiler errors like that, then it sounds like you're not using the complete new HuC package, and you're missing the variable declarations in equ.inc


Are you writing in pure HuC, or are you including your own assembly-language source files?
Are you using in-line assembly in the HuC source?
Are you providing your own headers?

[elmer]

The game however is just completely broken when running in Mednafen.

Darn ... the bottom of my previous message got chopped-off ... what I wanted to add was ...

If you are willing to do what the Catastrophy guys did, and provide me with your HuC project (or a small-but-working subset of it), that compiles correctly on Uli's version of HuC, and fails on my version, then I'll track down what the problem is and fix it.

If it's something to do with the map data, that could be a side-effect of the change that I checked-in to stop HuC looking *before* the pointer for tile information. Perhaps the map does that, too.

TheOldRover mentioned something about a map data bug existing in Uli's HuC, but I've not seen any examples of it.
(If I can't see an example of a problem, I can't fix it.)

[Sunray]

Gah, you are right!

I only recompiled the exes and completely forgot to copy the include directory. Game compiles and works fine with the latest HuC when I copied that direcrory, except for sound obviously (I was using Ulis IRQ).

I don't mind sharing the project source if you need more regression tests. I should fix some stuff first though, like sound.

[elmer]

Gah, you are right!

I only recompiled the exes and completely forgot to copy the include directory. Game compiles and works fine with the latest HuC when I copied that direcrory, except for sound obviously (I was using Ulis IRQ).

Excellent, I'm happy that you've got it working! 

Sorry about breaking Uli's sound system, but I had to make a bunch of changes to get Squirrel working, and also allow for using Huzak (or any other sound player) in the future, without people having to change HuC or provide customized startup files.

From what I could see, Uli's SimpleTracker and sound stuff were works-in-progress, and not production-ready.

Are you using those, or doing something else for your sound? 

I'll send you a link to my Squirrel modifications so that you can see how stuff is supposed to be integrated now (it's just a few macros in one file).

I don't mind sharing the project source if you need more regression tests. I should fix some stuff first though, like sound.

I'd love to have more tests to make sure that I don't break things in the future. 

Anything that you send me will be kept private.

[DildoKKKobold]

So, its inserting a random zero into the rom, in between incspr? That seems lame.

Also, a faster load_vram would be amazing. wink wink nudge nudge say no more.

OK, here you go, it's an early Christmas! 

https://www.dropbox.com/s/b5c2mjhof9m98h7/huc-2016-12-20.zip?dl=0


This is the cumulative changelog for the current version ...

New in version 3.99:
--------------------
2016-12-20
- Imported Uli's v3.98 version of HuC (https://github.com/uli/huc)
  See README for all the changes that Uli made
- Applied changes from Artemio Urbina's fork of HuC
- Applied changes from Markus Buretorp's fork of HuC
- Fixed compilation on Windows with mingw-w64
- Fixed a few bugs related to Uli's improvements
- Changed System Card parameter equates to have a "__" prefix
- Changed startup.asm to allow a sound driver to use macros to integrate
- Removed Uli's support for interrupt handlers in HuC (they're too slow)
- New str/mem package to replace the old code
    Note 1 : Strings are 255 bytes maximum (+ trailing null)
    Note 2 : When a ptr is returned, it points to the end of the str/mem
             This breaks ANSI/ISO compatibility, but is more useful
    Note 3 : strncpy handing of the 'length' is the same as strncat
             This breaks ANSI/ISO compatibility, but reduces code size
- Bumping version number for all the current changes
- Stop HuC adding an extra ".dw" to usage of .incchr/.incspr/.incpal/etc
- Add extra parameter to set_tile_data() to set the tile type (8 or 16)
    set_tile_data(char *tile, int nb_tile, char *ptable, char type);
- Rewrite load_vram to use 32-byte TIA instructions (3x speed improvement)


Pleafse note the change in the set_tile_data() function call!!! 

Everything is in github for those folks that want to make their own build.

Link is broken! Elmer?

[elmer]

Link is broken! Elmer?

That's an old version. See this post ...

https://www.pcengine-fx.com/forums/index.php?topic=21350.msg487200#msg487200