The new fork of HuC

[elmer]

FWIW, I've created a github fork of Artemio's fork of Uli's updated HuC so that I can make some changes.

The lack of the standard "<", ">", and "^" synonyms for PCEAS's "LOW()", "HIGH()", and "BANK()" just finally got me annoyed-enough that I fixed it.

CA65 (and most other 65xx assemblers) support the "<", ">", and "^" syntax, and the lack of them in PCEAS was making it troublesome to convert source code back-and-forth between assemblers.

I've also taken the opportunity to fix the Windows compilation of PCEAS and the other tools so that they can be built with msys2/mingw-w64 so that cygwin isn't needed anymore.

And for the last thing, I've updated PCXTOOL with the latest changes from Markus Buretorp's fork of HuC.

Anyone that's interested in building the tools can find the source at https://github.com/jbrandwood/huc

There's a pre-built 32-bit Windows version of the new/updated tools at ...

<Removed link to obsolete version>

You *should* just be able to drop these into your existing /huc/bin/ directory and have things work as normal.

I *may* look at the other HuC compilation issues at some point, but it's a low-priority for me.

I'm more interested in making some more small changes to PCEAS, such as allowing the user to specify the load address and start address of an ISO.

Enjoy! 

[Bonknuts]

Nice!

 Do you want the main.c file I modified for HuC?

[elmer]

Do you want the main.c file I modified for HuC?

I just read back through the thread ... I'd forgotten that you'd already fixed the HuC compilation issues.

Yes, please! 

Then I can make a full build of the new HuC that doesn't rely on the gawd-awful-slow-and-huge cygwin.

[Bonknuts]

http://pastebin.com/raw/QtUmw5jV
It's a little bit dirty, in that I just redid 7 functions that work specifically with data and rodata. All the final output code cares about, is a pointer to a block of memory anyway.

[Bonknuts]

{} style brackets aren't use for anything in PCEAS, right?

One of the problems I've had with PCEAS with when I want to group multiple data assets together and still use sizeof(). Currently, you can only use sizeof on a label if an incbin immediately follows it on the same line. Would be nice to be able to encapsulate data and get the size of it as a whole without manually doing it. The label right before the starting bracket would be the label for the whole data set, although any labels inside would still be global and not limited in scope.

 And better yet, have the encapsulation mechanism build out labels from the primary label with added "." to the labels inside.
Like this:

Code: [Select]

encap Level1 {

.tileset .incbin "tileset1.dat"
.pal .incbin "pal1.dat"
.map .incbin "map1.dat"
.startX:
  .db 00
.startY
  .db 00

thisIsGobal: .incbin "some.dat"


someBssVAR = var  ;var being a BSS define

}

 So it creates labels like Level1.tileset, Level1.someBssVar, Level1.thisIsGlobal, etc. Both local labels and global labels inside the encapsulation would be dot connected - all become global.

 Or maybe I should just save this for my pre-processor project for PCEAS.. heh.

[elmer]

Thanks to Bonknuts' generous help and source code, the entire HuC compiler and toolchain is now compiling cleanly on Windows with msys2.

Github has been updated with the latest changes, and a complete build of the latest version of HuC, with all the executables, include files, examples and source code can be found here ...

<Removed link to obsolete version>

If anyone downloads this and gives it a try, even perhaps, you know, like the folks involved in a certain high profile Kickstarter ... then I'd love to get some feedback on whether there are any problems (I hope not).  :-"

[DarkKobold]

Thanks to Bonknuts' generous help and source code, the entire HuC compiler and toolchain is now compiling cleanly on Windows with msys2.

Github has been updated with the latest changes, and a complete build of the latest version of HuC, with all the executables, include files, examples and source code can be found here ...

https://www.dropbox.com/s/kknwx1jqitizeap/huc-2016-11-03.zip?dl=0

If anyone downloads this and gives it a try, even perhaps, you know, like the folks involved in a certain high profile Kickstarter ... then I'd love to get some feedback on whether there are any problems (I hope not).  :-"

       Unknown instruction!
       --:A068                  __cmpwi_eq      3
       Unknown instruction!
       --:A078                  __cmpwi_eq      0
       Unknown instruction!
       --:A078                  __lbeqn LL1234
       Unknown instruction!
       --:A07F                  __cmpwi_eq      0
       Unknown instruction!
       --:A07F                  __lbeqn LL1235
       Unknown instruction!
       --:A08F                  __cmpwi_eq      4
       Unknown instruction!
       --:A09F                  __cmpwi_eq      0
       Unknown instruction!
       --:A09F                  __lbeqn LL1239
       Unknown instruction!
       --:A0A5                  __lbran LL1238
       Unknown instruction!
       --:A0A5                  __lbran LL1217
       Unknown instruction!
       --:A16E                  __lbnen LL1244
       Unknown instruction!
       --:A177                  __incb_s        0
       Unknown instruction!
       --:A031                  __lbeqn LL1256
       Unknown instruction!
       --:A036                  __lbran LL1246
       Unknown instruction!
       --:A028                  __lbnen LL1261
       Unknown instruction!
       --:A031                  __incb_s        1
       Unknown instruction!
       --:A053                  __lbnen LL1265
       Unknown instruction!
       --:A08A                  __lbnen LL1269
       Unknown instruction!
       --:A093                  __incb_s        0
       Unknown instruction!
       --:A0B7                  __addb_s        2
       Unknown instruction!
       --:A0FC                  __lbeqn LL1271
       Unknown instruction!
       --:A126                  __lbeqn LL1272
       Unknown instruction!
       --:A150                  __lbeqn LL1273
       Unknown instruction!
       --:A172                  __addwi_sym     _my_buffer
       Unknown instruction!
# 1017 error(s)

Tried it out, tons of fails. No idea how to help.

[elmer]

Tried it out, tons of fails. No idea how to help.

Thank you, I really appreciate you giving it a try! 

At first glance that looks like a whole bunch of missing macros.

IIRC, bonknuts said something about Uli renaming a few things ... but that may have nothing to do with this.

Since I'm an assembly guy, and not a HuC guy, I'm going to have to do some research, and hopefully get some help from bonknuts and any other HuC user that's actually tried the recent Uli/Artemio builds.

Thanks! 

[DarkKobold]

I'm not at a system that I can test this code on, but try this out:

Code: [Select]

void clearVram(int cellOffset, int numOfCells)
{

  /* vramAddress and VDCcells are global ints */
  vramAddress = cellOffset<<4;
  VDCcells = numOfCells;
 
#asm
   
    ;// In ASM, global variables are accessed with a preceding underscore.
   
    st0 #$00
    st1 #low(_vramAddress)
    st2 #high(_vramAddress)
    st0 #$02
       
    lda #low(_VDCcells)
    ldx #high(_VDCcells)
    st1 #$00

   
.loop   
    ;// Plane 0 & 1
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
   
    ;// Plane 2 & 3
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
   
   
    sec
    sbc #$01
    bcs .loop
    dex
    bne .loop

  #endasm

}

 It doesn't stall interrupts. It clears vram on a tile basis count, and a tile offset location. Normally vram is $0000 to $8000, but using tile offsets it's $000 to $800. Typically, HuC puts tiles at vram address $1000, which it tile offset $100. If you want to clear a single sprite cell, that would be a group of 4 tiles (a tile is 32 bytes, a sprite cell is 128 bytes). For example: to clear a single 16x16 sprite at vram address $5000, then do $5000 / $10 = $500 and a sprite cell is 4 tiles, so clearVram($500, 4). To clear all of vram; clearVram($000, $800). Etc.

 It's pretty rare that you'd want to "clear" a section of vram that's not tile based (the offset or segment system) - i.e. finer than 32byte segment/offset. It's also faster to do it this way too (32 bytes are clear in one loop iteration).

FYI, this worked great. Finally got a chance to add it to the code. Honestly, I'm pretty much always going to just be doing clearVram(0, 800); when a new level starts.

[Bonknuts]

I'm not at a system that I can test this code on, but try this out:

Code: [Select]

void clearVram(int cellOffset, int numOfCells)
{

  /* vramAddress and VDCcells are global ints */
  vramAddress = cellOffset<<4;
  VDCcells = numOfCells;
 
#asm
   
    ;// In ASM, global variables are accessed with a preceding underscore.
   
    st0 #$00
    st1 #low(_vramAddress)
    st2 #high(_vramAddress)
    st0 #$02
       
    lda #low(_VDCcells)
    ldx #high(_VDCcells)
    st1 #$00

   
.loop   
    ;// Plane 0 & 1
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
   
    ;// Plane 2 & 3
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
    st2 #$00
   
   
    sec
    sbc #$01
    bcs .loop
    dex
    bne .loop

  #endasm

}

 It doesn't stall interrupts. It clears vram on a tile basis count, and a tile offset location. Normally vram is $0000 to $8000, but using tile offsets it's $000 to $800. Typically, HuC puts tiles at vram address $1000, which it tile offset $100. If you want to clear a single sprite cell, that would be a group of 4 tiles (a tile is 32 bytes, a sprite cell is 128 bytes). For example: to clear a single 16x16 sprite at vram address $5000, then do $5000 / $10 = $500 and a sprite cell is 4 tiles, so clearVram($500, 4). To clear all of vram; clearVram($000, $800). Etc.

 It's pretty rare that you'd want to "clear" a section of vram that's not tile based (the offset or segment system) - i.e. finer than 32byte segment/offset. It's also faster to do it this way too (32 bytes are clear in one loop iteration).

FYI, this worked great. Finally got a chance to add it to the code. Honestly, I'm pretty much always going to just be doing clearVram(0, 800); when a new level starts.

I should probably note: Don't call this during active display. Matter of fact, I should probably modify this source code to save the VDC reg. You'll get all sorts of corruption if you call this at the wrong time. Sorry. I tend to think in terms of ASM, where this wouldn't be a problem for me. I'll update the code when I get a chance. I mean, it might work now - but it's best to make it safe for active display (and just in case vblank interrupts it too).

 Elmer: Yeah, he changed internal macro stuff so that it couldn't possibly conflict with HuC label names.

 It might be that DarkKobold is mixing library code between builds (paths are shared or something, library files directly in project folder, etc).

[elmer]

       Unknown instruction!
       --:A068                  __cmpwi_eq      3
       Unknown instruction!
       --:A078                  __cmpwi_eq      0

       ... and so on!

Tried it out, tons of fails. No idea how to help.

It might be that DarkKobold is mixing library code between builds (paths are shared or something, library files directly in project folder, etc).

Yep, that's what I'm thinking, too.

Those macros are all part of Uli's new version of HuC.

The new compiler can find them and use them fine when it builds the programs in the Examples directory.

I can only assume that DarkKobold has either got some old files in his project directory, or that his paths are set up so that some of the old HuC executables/include-files are being used.

DK ... while my first build of the tools-only could just be dropped into an existing HuC "bin/" directory, the last build of the entire HuC compiler and tools absolutely *must* be used as a *replacement* for the old version of HuC.

AFAIK, the easiest thing to do is to just rename you old HuC directory as HuC-old, and then create a new HuC directory for the new version.

When you've done that, you'll need to delete any old HuC-generated ".s" files in your project directory.

I hope that that will get things working for you!

[DarkKobold]

       Unknown instruction!
       --:A068                  __cmpwi_eq      3
       Unknown instruction!
       --:A078                  __cmpwi_eq      0

       ... and so on!

Tried it out, tons of fails. No idea how to help.

It might be that DarkKobold is mixing library code between builds (paths are shared or something, library files directly in project folder, etc).

Yep, that's what I'm thinking, too.

Those macros are all part of Uli's new version of HuC.

The new compiler can find them and use them fine when it builds the programs in the Examples directory.

I can only assume that DarkKobold has either got some old files in his project directory, or that his paths are set up so that some of the old HuC executables/include-files are being used.

DK ... while my first build of the tools-only could just be dropped into an existing HuC "bin/" directory, the last build of the entire HuC compiler and tools absolutely *must* be used as a *replacement* for the old version of HuC.

AFAIK, the easiest thing to do is to just rename you old HuC directory as HuC-old, and then create a new HuC directory for the new version.

When you've done that, you'll need to delete any old HuC-generated ".s" files in your project directory.

I hope that that will get things working for you!

So I've been.... sloppy. I've been doing all of my code generation in the HuC/bin directory.  (I know, I know, don't murder me!)

Would it be sufficient to just delete the HuC/include, delete the .s files, and then overwrite the HuC/bin executables?

[elmer]

Would it be sufficient to just delete the HuC/include, delete the .s files, and then overwrite the HuC/bin executables?

Errr ... possibly, but you'll need the new include directory, and you'd have a mess of files between different versions.

If you've got all of your source code in the huc/bin/ directory (not a good idea, but not a horrible sin), then can you just delete all the other directories in /huc/ *except* for /huc/bin/ and then decompress the new files into /huc/ as normal?

The executable files for the new HuC have the same names as the old ones and should just overwrite the old files.

[Bonknuts]

Here's a question that's been bothering me: why is your project files inside huc\bin directory?

[DarkKobold]

Here's a question that's been bothering me: why is your project files inside huc\bin directory?

A combination of simplicity and how Catastrophy came about. I literally just started one file using the tutorial in the HuC\bin folder, so I could compile by executing "huc main.c" from a command window. Everything has grown organically from that. Yes, I could set paths and etc, but there was never a compelling reason to. Catastrophy literally started as "Do I have the ability to program for the PC Engine?"

Technically, these two videos are iterations of the same C file. I never started from scratch after doing the tutorial.

EDIT: Got it working. However, it has two conflicts with Squirrel


#define  IRQ_TIMER      0
#define  IRQ_VSYNC      1

These are duplicated in Squirrel. Deleting them causes a ton of errors.