The new fork of HuC

[OldRover]

3MLE is the tool I use for MIDI->MML conversion. Works like a charm.

[Gredler]

https://youtu.be/XeZTqqN0FtM

Thanks for posting these here, but I've gone through them a bunch of times already - I really appreciate the detailed documentation between these and the readme.

3MLE is the tool I use for MIDI->MML conversion. Works like a charm.

I think this is where the disconnect is for myself and the two guys I've tried to get to use this workflow - authoring a halfway decent midi.

Where were you getting your midi's from?

Right now it seems like making the song straight up in 3mle is my best option, but I've looked into "anvil" and a few other programs to create midis with.

[Arkhan Asylum]

I use fruity loops.

Really though, making music requires you to ... know how to make... music.

Any music program from the last 25 years that isn't a shitheap can export a MIDI, basically.

[Gredler]

Really though, making music requires you to ... know how to make... music.

Well, danmit. Where is the make music button?! Get your shit together!

[TurboXray]

pcedev.net/pics/compression/sprite_compression.png

 So one example of your large sprite, here I color coded a few areas to show some simple compression schemes you could apply directly in HuC. So while the PCE sprites cells are 16x16 in hardware, that doesn't mean you couldn't store them in smaller components like 8x8. Matter of fact, it's pretty easy to convert four 8x8 sprites into a single 16x16 when writing it to the hardware. But for the sake of simplicity and keeping the planar format, I chose 8px wide as the smallest width.

 So the simplest area of compression is of course just to omit blank 16x16 tiles. Those are marked in red (a group of 8x8 tiles making a 16x16 block). But obviously it doesn't always work with all sprites and sizes.

 The darker blue translucent areas show part of the image that can be represented as 2bit color instead of 4bit. That's an automatic 50% saving in those areas. Some of the transitioning areas of the bag in that image, have a limit of 7 colors and could be stored in 3bit format for a 25% savings per cell area (which I didn't highlight). Notice that I used 8x8 sectioning in the highlighting.

 The light blue and orange-ish areas show repeated data. Since this is planar, and a byte can represent 8px across, that data can be represent in numerous ways (RLE, bitmask for repeat patterns, etc). You can head sections of tile groups with headers, indicating which tiles are compressed and what type of decompression to use. I didn't highlight the whole image with all of columns of repeating 8px wide sections along 8x8 cells, but just enough to demonstrate.

Darker-Pink is similar to light blue areas, except the whole tile can be represented as a single row of 4bit 8x line and a simple RLE for the column length.

 The purple one is just an example of where a whole 16x16 cell is wasted to show a few pixels. The art could be changed slightly, and you'd save 128bytes right there.

 And just look at all those 8x8 green tiles (which are invisible pixels). Those could easily be represented as a single header byte (blank 8x8 tile). There are all sorts of compression schemes that you can throw at it, and having a diverse set of simple schemes can help out quite a bit. These types of schemes are also very fast to decompress to vram; many hucard games use compression schemes like these. If all you did was compress for blank 8x8 tiles and nothing else, you'd save 1,800 bytes alone in that pic (20% rom saving in space for the image).

[Gredler]

Thanks Bonknuts! I totally see the sloppiness in the edges cutting into 8x8 quadrants of larger sprites like this in many of my assets, if we implement a compression element that would need to be updated, but thats nbd if needed!

I should note that this image was a rough cutout for the web, the final sprite is cut into small enough peices that most of the green empty 8x8 quadrants are not accounted for.

Great to know about the color compression potential as well, if we can implement that the art can design around these restrictions for sure!

[esteban]

sprite_compression.png

 So one example of your large sprite... you'd save 1,800 bytes alone in that pic (20% rom saving in space for the image).

I just wanted to say that even though I don't post often in technical threads, I absolutely love reading them, (especially when I can actually follow along semi-competently).

I appreciate the time you, elmer and others take to explain stuff.

[DildoKKKobold]

Getting back to work on Catastrophy, I've had a few thoughts on what would be helpful to have, as asm code.

First, there is no way to clear vram directly. A quick bit of asm that writes all zeros to vram would be helpful. cls() and reset_satb() don't actually empty the vram. (The main reason I need this is because I'm using 48pix high images in 64pix high sprites. Thus, I need to clear out the extra 0x80 of unused sprite space)

Second, an asm code for doing simple RLE decoding into vram would be awesome, assuming one could also add a separate program that compresses images into .bins, and tells you the % savings.

Finally, a program that helped you keep track of what is in vram would be awesome. Essentially, it'd just be a 32pixel wide listing from 0x0000 to 0x8000, so you could insert your images, and see how much you are using up. I know that sort of exists in emulators, but its hard to actually use.

[OldRover]

I handle the last part by planning out a VRAM map in advance. It's not terribly difficult to do, and saves a lot of headache later.

Normal tiles use 0x10 VRAM words (#incchr).
Metatiles use 0x40 VRAM words (#inctile).
Sprites use 0x40 VRAM words per section (so a 32x64 sprite, 8 sections, is 0x200 VRAM words).
Each section of the BAT uses 0x400 VRAM words (so the default 64x32 BAT is 0x800 VRAM words).

The rest is just knowing where stuff goes. The BAT is typically at the start of VRAM, the SATB at the end. So you have all the space in between to do whatever you want with, though personally, I typically put the font right after the BAT.

Here's how Lucretia is set up, for example:

Code Select Expand

common graphics addresses
4600-49FF pause graphics
4A00-4FFF UI
5000-53FF player 1 sprites
5400-57FF player 2 sprites
5800-59FF projectiles
5A00-5BFF items

stage 1
3000-3BFF demon lamp
4000-42FF onigrass
4400-45FF oni-o-lantern
5C00-5FFF moon
6000-69FF birdie
6A00-71FF witch
7200-73FF powerup
7400-75FF tombstone
7600-79FF fence

[touko]

First, there is no way to clear vram directly.

Yes, there is a way, you can use VRAM->VRAM DMA.

Or in asm, a loop with some stx can do the job quickly .

[OldRover]

I think he meant with straight-up HuC code though... there's no direct function for it.

[touko]

I think he meant with straight-up HuC code though... there's no direct function for it.

Ah ok, if it's only huc functions you'r right .

[TurboXray]

Getting back to work on Catastrophy, I've had a few thoughts on what would be helpful to have, as asm code.

First, there is no way to clear vram directly. A quick bit of asm that writes all zeros to vram would be helpful. cls() and reset_satb() don't actually empty the vram. (The main reason I need this is because I'm using 48pix high images in 64pix high sprites. Thus, I need to clear out the extra 0x80 of unused sprite space)

Yeah, if I remember (this weekend), I can write you a simple set of functions in HUC to do this for you. If someone hasn't already.

Second, an asm code for doing simple RLE decoding into vram would be awesome, assuming one could also add a separate program that compresses images into .bins, and tells you the % savings.

That's pretty doable. I don't know about anyone else, but I've had to write different RLE compressors to re-inserting compressed graphic data back into rom (hacking). So it wouldn't be too difficult just to adapt such tools for regular use.

Finally, a program that helped you keep track of what is in vram would be awesome. Essentially, it'd just be a 32pixel wide listing from 0x0000 to 0x8000, so you could insert your images, and see how much you are using up. I know that sort of exists in emulators, but its hard to actually use.

So you feed a "script" file some text, like what HUC uses, and use that to output a list as well as a visual pic of how vram is organized? Pretty doable, but it's only really valuable if your level or such is static in vram usage. Dynamic allocation is a bit harder to show resource usage for.

[DildoKKKobold]

So you feed a "script" file some text, like what HUC uses, and use that to output a list as well as a visual pic of how vram is organized? Pretty doable, but it's only really valuable if your level or such is static in vram usage. Dynamic allocation is a bit harder to show resource usage for.

Honestly, I was just thinking something like an excel style chart, where I could just load the PCX files in. Its probably really not necessary, as better planning and execution would help. As rover pointed out, a little bit of planning goes a long way. Usually I just load stuff into vram where I'm fairly certain there is free space.

[DildoKKKobold]

Getting back to work on Catastrophy, I've had a few thoughts on what would be helpful to have, as asm code.

First, there is no way to clear vram directly. A quick bit of asm that writes all zeros to vram would be helpful. cls() and reset_satb() don't actually empty the vram. (The main reason I need this is because I'm using 48pix high images in 64pix high sprites. Thus, I need to clear out the extra 0x80 of unused sprite space)

Yeah, if I remember (this weekend), I can write you a simple set of functions in HUC to do this for you. If someone hasn't already.

Any luck with this?

[TurboXray]

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

Code Select Expand

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).

[touko]

It's more faster to hide sprites and clear the BAT (addr $0000 -> $0800,it depend of your virtual screen size), than all the vram .

If you put zero in the BAT region to clear it, you'll see some artifact the next time on empty BAT parts if your screen is not entirelly filled with tiles,this is why it's better to clear the BAT with an empty tile .

[TurboXray]

I'm assuming he wants to clear vram so that when he's viewing it in debugger window, vram contents match the area/section of the game code.

[DildoKKKobold]

I'm assuming he wants to clear vram so that when he's viewing it in debugger window, vram contents match the area/section of the game code.

Actually, its because we use quite a few 32x48px tall sprites, just loaded into a 32x64 sprite size. So, I load the VRAM with 0x180, and the extra 0x80 is filled with a previous VRAM load.

P.S., thanks for the code. I'll probably just use it to clear VRAM entirely at each level load, so timing shouldn't matter a ton.

[TurboXray]

I'm assuming he wants to clear vram so that when he's viewing it in debugger window, vram contents match the area/section of the game code.

Actually, its because we use quite a few 32x48px tall sprites, just loaded into a 32x64 sprite size. So, I load the VRAM with 0x180, and the extra 0x80 is filled with a previous VRAM load.

P.S., thanks for the code. I'll probably just use it to clear VRAM entirely at each level load, so timing shouldn't matter a ton.

Let me know if you have problems with it, or want to change it in anyway. I usually have some time on the weekends, so I can get to it within a week time frame. PM here and I'll give you my tomaitheous email address.

[touko]

Actually, its because we use quite a few 32x48px tall sprites, just loaded into a 32x64 sprite size. So, I load the VRAM with 0x180, and the extra 0x80 is filled with a previous VRAM load.

With meta sprites your problem would have gone .

You can also use this trick, you can transfert a blank 32x16 sprite in top/bottom of your 32x48 to clear the unused part,before transfer your sprite .
It's more faster than clearing all sprites/VRAM .

[TurboXray]

Well, I'm assuming he wants to do this during the start of level or area loads. Not exactly in the middle while the game mechanics are functioning.

 Otherwise, if you're dynamically updating sprite data during the game and have this issue, I would use a special sprite load routine where it blanks out the remaining cells.. is best (and not the whole 32x64 block). That could work during in game updating. The routine I wrote could still work in conjunction with this as well.

[DildoKKKobold]

Actually, its because we use quite a few 32x48px tall sprites, just loaded into a 32x64 sprite size. So, I load the VRAM with 0x180, and the extra 0x80 is filled with a previous VRAM load.

With meta sprites your problem would have gone .

I haven't a clue what you mean by metasprite? A 32x32 and 32x16 put together?

[touko]

I haven't a clue what you mean by metasprite? A 32x32 and 32x16 put together?

Yes it's an exemple, it's a logical(software) sprite composed by many hardware sprites .
for a 32x48 pixels sprite you don't have to worry for the last 32x16 pixels,because it decomposed into 2 "little" sprites(32x32+32x16) and not a whole 32x64 like you did with 1 hardware sprites.
It's also a more efficient method to avoid/reduce flickering.

32x64 is very good for a full filled sprite, not for unsuported intermediate size like 32x48 or 16x48 etc ..

[OldRover]

If you have sprites to spare, 32x32+32x16 is better, but if your game is a sprite monster, 32x64 is sometimes your only option. It all depends on your sprite budget. From what I have seen of DK's game, it uses a lot of huge sprites, so maybe 32x64 is better. Also, if you have a general sense of where your sprites will be during gameplay, you can optimize the sprite pixels. For example... in HE's stage 00, we have 32x48 objects, but they have to use 32x64 sprites because the game engine literally uses every sprite the hardware has. However, we leave the bottom 16 pixels open. For some games, you might want to do the reverse... make the top pixels open and align the sprite pixels to the bottom of the sprite block... useful for, say, a 32x48 stalactite in a cavern... that way, you don't have 16 empty lines at the bottom of the stalactite, just waiting to cause an unintended overflow.

[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! 

[TurboXray]

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.

[TurboXray]

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.

[TurboXray]

{} 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 Expand

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). 

[DildoKKKobold]

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! 

[DildoKKKobold]

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

Code Select Expand

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.

[TurboXray]

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

Code Select Expand

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!

[DildoKKKobold]

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.

[TurboXray]

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

[DildoKKKobold]

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.

[elmer]

#define  IRQ_TIMER      0
#define  IRQ_VSYNC      1

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

Can't you just search-and-replace the ones in the Squirrel source file? Say to some like SQ_IRQ_TIMER?

[TurboXray]

IRQ_TIMER and IRQ_VSYNC are used as bitmasks in HuC for enabling/disabling interrupts. Appending _MASK at the end would probably be a better name for them anyway.

[elmer]

IRQ_TIMER and IRQ_VSYNC are used as bitmasks in HuC for enabling/disabling interrupts. Appending _MASK at the end would probably be a better name for them anyway.

I wouldn't disagree ... but it might not be a easy change for DarkKobold to make (multiple files), and it might need the compiler to be rebuilt.

AFAIK Squirrel is a single (or maybe 2) files to change ... and anyway, library code like Squirrel shouldn't pollute the application programmer's global namespace, it's rude. 

[OldMan]

Squirrel is a single (or maybe 2) files to change

Funny thing is, I just did a find in all files (*.*) in the squirrel directory, and there were no hits.
I'm not saying it isn't there, just my editor didn't find it.

And yeah, DarkKobold, if you find it in the squirrel stuff, I'd change it to "PSG_ON_TIMER" and "PSG_ON_VSYNC". Should be more descriptive anyway. Afaik, they are only #defines for the parameter to one of the psg setup functions.

library code like Squirrel shouldn't pollute the application programmer's global namespace, it's rude.

If there were seperate namespaces, it wouldn't. However library code often has include files as part of the interface; using the #defines in them is recommended practice (just in case the values change)

System code and variables, however are supposed to use '__' or '_'  as a preface to indicate it's a system reserved value.

[OldMan]

[Don't know why, But I don't have an edit button, so....]

Okay, I finally found it. It's part of the defines for a test program. One of the squirrel examples. :/
To show people what values are useable, more than anything.

[cabbage]

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). 

I downloaded this link and gave it a try on some code laying around, and I'm getting errors relating to farptr.

This first example is odd; the error seems sporadic and random even without changing the target code...
So, once it might show an error on one line number:

Code Select Expand

;error: player.c(167)
; load_vram(0x6400 ,hero_spr+0x3c0,0x40);
;                                      ^
;******  can't get farptr  ******Another time it might error on a different (but similar) line number:

Code Select Expand

;error: player.c(115)
; else if(i==8)load_vram(0x6400 ,hero_spr+0x80,0x40);
;                                                  ^
;******  can't get farptr  ******..And still other times it builds with no errors but the resulting binary doesn't work correctly. (everything is fine using the ancient build of HuC)

Another project always fails to build, and in the same way each time:

Code Select Expand

04:A267                  sta     <__fptr
Undefined symbol in operand field!
04:A27D                  sta     <__fptr+1
Undefined symbol in operand field!
04:A27F                  lda     [__fptr]
Undefined symbol in operand field!
Hope this helps~

[elmer]

I downloaded this link and gave it a try on some code laying around, and I'm getting errors relating to farptr.

Sorry to hear that!

There's a limited amount of debugging that I can do on the compiler, but let's try and get some of the obvious problems out of the way first.


It would be good to find out if I've broken something, either with my change to PCEAS, or with the mingw-w64 build itself.

Would you please try this version of HuC that I posted a few months ago?

It's built with cygwin using Artemio's source code without any changes ...

https://www.dropbox.com/s/4dy8tujysefqupd/huc-aurbina-2016-06-20.zip?dl=0


If that version still gives you problems, then what you're seeing is because of Uli's changes to the compiler.

If that version works, then we can continue to track down what's gone wrong with the new build.

Another project always fails to build, and in the same way each time:

Code Select Expand

04:A267                  sta     <__fptr
Undefined symbol in operand field!
04:A27D                  sta     <__fptr+1
Undefined symbol in operand field!
04:A27F                  lda     [__fptr]
Undefined symbol in operand field!

I'd focus on this project first! Debugging is so much easier with a reproducible problem.

Hope this helps~

Definitely, thanks!

I don't use HuC myself, and all that I've done is integrate Bonknuts's Windows-compatibility patch into the new compiler (with some of my own changes).

Since I don't use HuC, I'm going to have to rely on other people to come up with existing projects that the new compiler fails on.

[DildoKKKobold]

Squirrel is a single (or maybe 2) files to change

Funny thing is, I just did a find in all files (*.*) in the squirrel directory, and there were no hits.
I'm not saying it isn't there, just my editor didn't find it.

That is the crazy thing. I couldn't find where it was used either. I searched a ton, and as far as I can tell, its just in the "defs" .h file. That said, it wouldn't compile, and it looked to have something to do with the psg stuff, from squirrel. It may have actually been totally unrelated.

Maybe if someone pings Arkhan, we can figure this mess out.

[OldMan]

Maybe if someone pings Arkhan, we can figure this mess out.

<lol> He won't know. I have the original sources for the squirrel player, anyway.

I don't want to mess up my HuC installation (I need it for a game), so I'm working on
re-purposing another computer to install this new build. Once I get a generic "hello"
program compiling, I'll look into it a bit more. I do vaguely remember that there is an
attempt at doing the psg stuff in HuC, but it never got finished. That might be it.
Also note there appears to be a problem with far pointers; I've never used them, but
I'll be looking into that problem, too.

So if you are checking this out and have a problem, please post it here. We can't fix it if we
don't know what/how it broken.

[cabbage]

It would be good to find out if I've broken something, either with my change to PCEAS, or with the mingw-w64 build itself.

Would you please try this version of HuC that I posted a few months ago?

It's built with cygwin using Artemio's source code without any changes ...

https://www.dropbox.com/s/4dy8tujysefqupd/huc-aurbina-2016-06-20.zip?dl=0


If that version still gives you problems, then what you're seeing is because of Uli's changes to the compiler.

If that version works, then we can continue to track down what's gone wrong with the new build.

Another project always fails to build, and in the same way each time:

Code Select Expand

04:A267                  sta     <__fptr
Undefined symbol in operand field!
04:A27D                  sta     <__fptr+1
Undefined symbol in operand field!
04:A27F                  lda     [__fptr]
Undefined symbol in operand field!

I'd focus on this project first! Debugging is so much easier with a reproducible problem.

OK, I just tried with that 2015-10-14 build and got the same errors.

The code I have laying around is designed specifically with HuC in mind (ie, i would likely do things differently when using another compiler), so maybe it's just poor code whose support has been broken by uli's fixes? you're welcome to take a look at the example i used if you like.