pce-devel / huc Goto Github PK

Add support in the help commands for showing how you can use -o to define the output filename directly from the pceas compiler.

The joypad scanning routine is automatically called from within the VSYNC handler - which is generally fine - but should be possible to override with entirely custom code, or at least disable.

In joypad.asm, there is currently a variable referenced, "joyhook" (which is defined in startup.asm), which appears as though it might have been placed here for this very purpose... HOWEVER, instead of overriding the joypad scanning, it is checked AFTER the 5 joypads have been scanned, and called as a subroutine at that point.

There should be a way to turn off this scanning so that special peripherals can be scanned/controlled completely by user code without interference from the framework.

the 'make check' command doesn't seem to properly process the list of files on Mac
According to the output, the mac version of md5sum is expecting an actual filename as a parameter and is confused by the '<'
(this happens with and without the call to dos2unix)

Directly passing the file name to md5sum seems to be working, and only Win platform actually needs the file to be converted to UNIX format

Not sure what I am doing wrong but the following code won't compile.

int vram_curr_addr = 0;

typedef struct {
    unsigned int   frame_count; // number of frames
    unsigned int   block_size;  // block size for frame
    unsigned int   vram_addr;   // vram address for frame 0
    unsigned int   ctrl_size;   // SZ_16x16, SZ_32x32
} SpriteData;

void load_vram_32x32( SpriteData* sd, int* data, int count )
{    
    sd->frame_count = count;
    sd->block_size = 0x100;
    sd->vram_addr = vram_curr_addr;
    sd->ctrl_size = SZ_32x32;
    load_vram(vram_curr_addr, data, count*0x100);
    vram_curr_addr += count * 0x100;
}

I get this error.

;error: scroll.c(27)
; load_vram(vram_curr_addr, data, count*0x100);
;                                            ^
;******  can't get farptr  ******

I did a git clone and build, which seemed to build OK.

When I ran HuC, the usage text didnt identify a version number for HuC (the version information was missing).

HuC (, )

USAGE: huc [-options] infile

Probably there is a version identificaction file (or something similiar) missing from the github repository.

While developing (on a different version), I found a bug in one of the library functions which I was able to fix on my version. I am notifying you so that you can also update, since this bug also exists on the version in this repository.

In include/huc_gfx.asm, the _load_font function doesn't properly set up for loading vram - it fails to set colours, and jumps to the wrong function.

At the termination point from _load_font.3, please replace:
jmp load_vram

with:
stb _font_color+1,<_ah
lda _font_color
bne .l3
inc A
.l3: sta <_al
jmp load_font

The 'Publish Package' step run at the end of the flow seems to be randomly failing, with errors pointing to github infra issues (need logs)

The action 'pyTooling/Actions/releaser' doesn't seem to have any retry mechanism.
See if retries can be added to the action, on if they can be implemented at a higher level, in the yaml file itself using other actions

I've attempted to use the SF2 mapper but did not find a route from the SF2 build parameter in assembly to the HuC build function. Supplying it seems to be ignored.

After build, the following files are showing as "new files" in the source tree (but should be suppressed):

• src/tools/hulz/hulz
• examples/asm/elmer/ipl-scd/ipl-scd.out

Mainly an ease of use convention when compiling w huc and the -sgx flag, and then also invoking the pceas directly compiler by no using -s, produce a .sgx file by default instead of a .pce .

If I'm right, #incchrpal is meant to create a palette array for a corresponding 8x8 tileset and an according map instead of #inctilepal working with 16x16 tileset.

But using this directive trashes the screen, whereas just setting an empty palette array loads the screen correctly ( minus palette index affectation ).

Is there something I'm missing? Wrong use?

TestIncChrPal.zip

Hello/

I use #incbin(file,"file.bin") to nest a music file ( around 6KB) on my project. I use farmemget() this way to iterate through the file:
farmemget(&buffer, file+cursor, 12); // where cursor is an unsigned int, full code in C, no ASM on my side

Everything works fine when the file is the first #incbin, but if it's placed in second position, it crashes. And it seems to be related to the file overlaping 2 data banks.

Is it considered a bug or farmemget() wasn't meant to be used like this?

thanks for your time

The random function is limited to return a char between 0 & 128-1, is there a technical reason for this clamp whereas it takes a char parameter? this limitation was not specified in the doc ( from ArchaicPixels which is now down ... ) and very misleading.