Where's CC65 at with regards to using it instead of HuC for making games?
Short Answer:
It just requires the desire to use it, and the willingness to copy over any HuC library routines that you want to use.
From my POV, that makes it perfectly usable, but I suspect that you've got a different POV.
------------------------
Long Answer:
The workflow is definitely going to be different to HuC, because of it is the more-traditional compile/assemble/link style, and because it doesn't have HuC's PCE-specific #incpal/#inctile/#incspr functions.
CC65/CA65 are working perfectly fine as a compiler/assembler.
I've built a test-rom with it to confirm that it compiles standard C code (a FAT32 library for reading the Everdrive's SD card).
It was easy to use and incredibly flexible once you've got your head around the power of its code-layout and startup options.
The point is that it's
all configurable and
you get to decide where the linker puts the startup-code/library-code/game-code/data.
The guy that was working on the PCE-port hasn't committed anything new in about 4 months. But that's not really a problem since he was definitely a novice on the PCE and was doing some things in a very strange (and wrong) way.
Because it's all "linked", we can just use the bits of his CC65-specific code that we like, and override anything else with new code.
Then, if you want to make a CD, you have to piece-together the .iso binary with something like 'bincat' and then modify the 2nd-sector with your particular
------------------------
Here's my batch file for compiling the test code ...
# C files.
cc65 -O -t pce hello.c
cc65 -O -t pce fatfs/ff.c
cc65 -O -t pce fatfs/diskio.c
cc65 -O -t pce fatfs/option/unicode.c
ca65 -t pce -v hello.s
ca65 -t pce -v fatfs/ff.s
ca65 -t pce -v fatfs/diskio.s
ca65 -t pce -v fatfs/option/unicode.s
# ASM files.
ca65 -t pce -v crt0.s
ca65 -t pce -v text.s
ca65 -t pce -v sd.s
# Link
ld65 -o hello.pce -m hello.map -C pce.cfg hello.o text.o sd.o fatfs/ff.o fatfs/diskio.o fatfs/option/unicode.o crt0.o pce.lib
------------------------
I decided to use the following layout for the HuCard ...
The STARTUP & library CODE go in bank $00 that lives at $E000-$FFFF.
The INIT code and the 'initialized' DATA (that get copied to RAM) goes in bank $01 that lives (temporarily) at $C000-$DFFF.
Once the HuCard starts up and my customized crt0.s runs the INIT code, and copies the 'initialized' DATA to RAM, then I map banks $02-$05 into $4000-$DFFF for my main code, and leave $C000-$DFFF for paging code/data as I need to.
Now I'm not saying that this is a particularly great way to lay out a HuCard, but I needed an uninterrupted 32KB for the FAT32 code, and the big point is that I was easily able to do that with CC65.
And here's my customized CC65 configuration file for that layout ...
SYMBOLS {
__STACKSIZE__: type = weak, value = $0300; # 3 pages stack
}
MEMORY {
# Preserve System Card standard ZP locations.
ZP: start = $00, size = $ec, type = rw, define = yes;
# reset-bank and hardware vectors
ROM0: start = $E000, size = $1FF6, file = %O, fill = yes, define = yes;
ROMV: start = $FFF6, size = $000A, file = %O, fill = yes;
ROM1: start = $C000, size = $2000, file = %O, fill = yes, define = yes;
ROM2: start = $4000, size = $8000, file = %O, fill = yes, define = yes;
ROM6: start = $C000, size = $2000, file = %O, fill = yes, define = yes;
ROM7: start = $C000, size = $2000, file = %O, fill = yes, define = yes;
# First RAM page (also contains stack and zeropage)
RAM: start = $2200, size = $1E00, define = yes;
}
SEGMENTS {
STARTUP: load = ROM0, type = ro, define = yes;
INIT: load = ROM1, type = ro, define = yes, optional = yes;
CODE: load = ROM0, type = ro, define = yes;
RODATA: load = ROM0, type = ro, define = yes;
DATA: load = ROM1, type = rw, define = yes, run = RAM;
SDCODE: load = ROM2, type = ro, define = yes;
SDDATA: load = ROM2, type = ro, define = yes;
BSS: load = RAM, type = bss, define = yes;
VECTORS: load = ROMV, type = rw, define = yes;
ZEROPAGE: load = ZP, type = zp, define = yes;
EXTZP: load = ZP, type = zp, define = yes, optional = yes;
APPZP: load = ZP, type = zp, define = yes, optional = yes;
}
FEATURES {
CONDES: type = constructor,
label = __CONSTRUCTOR_TABLE__,
count = __CONSTRUCTOR_COUNT__,
segment = INIT;
CONDES: type = destructor,
label = __DESTRUCTOR_TABLE__,
count = __DESTRUCTOR_COUNT__,
segment = RODATA;
CONDES: type = interruptor,
label = __INTERRUPTOR_TABLE__,
count = __INTERRUPTOR_COUNT__,
segment = RODATA,
import = __CALLIRQ__;
}
EDIT:
I guess that it would help to explain a couple of things in the configuration file (it's for the "LD65" linker).
The "MEMORY" section is basically just a list of areas (and their sizes) that get written to the output file ... in this case I'm having it create an 8 bank HuCard ROM image.
The actual names of the different sections in "MEMORY" can be anything ... I'm just using the name "ROM" + bank-offset for my own convenience.
The "SEGMENTS" section defines the names of the different segments in the C and ASM code (user-defined, but with a few defaults like CODE/DATA/RODATA/RAM), and it shows where in the output file those segments should be put.
That's it ... you have total flexibility to map your code/data into the output HuCard/ISO image in any way that you like.
------------------------
