Small C on the PC-Engine

HuC has a lot to be desired; it’s no secret. People that know how to get around its short comings, deal with it.

As much as I like assembler, I do like C. I’ve been wanting to code a small game for the PCE in C, for a while now. The past couple of days, I had a short conversation with Chilly Willy over at TE forums. CC65 to be exact. Looking over some of the stuff that you can do with it – it looks pretty decent, and most importantly – full manual page/bank control! That is a VERY important feature for optimization reasons alone. That was thee biggest gripe I had with HuC, over everything else that could be fixed with support code. Even some talk about how to optimize use for SuperGrafx extra ram with CC65.

I’m going to take a serious look at it this year. I don’t know if anyone else is interested in C for PCE, but I’ll be sure to make notes about my experiences. A lot of lib stuff can be ported over to CC65, from HuC. Since HuC is no longer being supported/worked on, I think it’s time to move over to CC65 for the PCE. At least there’s a muuuucchh bigger user base for CC65 (and not just for C64 either). The compiler supports 65C02 code, and to be honest (with C) 6280 isn’t really an improvement over it opcode wise. I doubt you’d see much of any improvement with the added instructions over 6280. They’re more convenient than anything else. And when they are faster, it’s for hand tuned assembly. Excluding the block transfer instructions. And supposedly CA65 supports 6280, so inline assembly should be fine.

SDCC looked decent as well, but there’s no support for 65x based processors (MCU version of 6800 was the closet thing). Too much work to add a new processor. CC65 it is.

8 Responses to “Small C on the PC-Engine”

  1. DefCon1 Says:

    I’m all with you on this one. I did of few demo stuff way back (around 2000 I think) with HuC and it wasn’t really great.

  2. DefCon1 Says:

    Any develepment on this?

  3. グレェ Says:

    FWIW there is a fork of HuC now:

    Port maintainer on FreeBSD’s port is non-existent and I have been stalling on getting the newer code built (the old 2005 HuC revision segfaults and dumps core on an attempt to compile a helloworld.c on 64bit architectures at present unfortunately).

    Glad to see other alternatives! That said, the PC-Engine has less RAM than the PDP7 that Unix was originally written on (in assembly; indeed, C did not even exist as a language until after the PDP11/20 port of Unix), so I sort of feel as though it may be “too high level” for such a limited system; then again, 6502 was the first processor I learned any form of asm on, so there is something very pleasantly nostalgic about jettisoning all of the higher layer abstractions and toolsets and just twiddling registers. ^_^

    • I was looking at that. I’m actually starting the framework for a C (or small C) project for PCE; A tiny game to release. I think I’ll go with cc65 as it’s more mature. I was originally going to use HuC with 100% new lib, but I figured why support that legacy app when CC65 would be the better option, especially if I share TG16 libs for it. I’m not used to a real ‘linker’ for my PCE/console stuff, so I’ll have to remove some old habits – but not a big problem. CC65 makes organizing your subroutines and data, more effective. I can define exactly which back a subroutine should belong to. I can also define lib banks with different sizes; 8kRam/24kCode/16kData or 16kRam/16kCode/16kData setups (SGX and CD with wider fixed ram banks), etc. The way the linker sets this up, in the config file, looks pretty nice IMO.

      • I am uncertain if cc65 has improved much, but I doubt it can be worse than HuC? For some reason, the FreeBSD cc65 port seems atrophied at 2.13, but I was just able to run:
        % git clone
        % make
        % cd bin
        % ./cc65 –version
        cc65 V2.15

        Without issues.

        By comparison, while the HuC port in FreeBSD presumably still segfaults, I can’t even get Uli nor this more recent fork of HuC to compile on OS X Sierra:

        Nor are there documented build instructions for what development environment those HuC forks are using either. It’s not in any maintained port nor package system that I am aware of and seems to be more like a public version of what is more or less a private fork, not too useful when they don’t include the rest of their build environment nor documentation.

        At least cc65 builds, that’s a better stating place. This page of documentation is decidedly troubling and weak: no printf even supposedly? How would even a canonical helloworld.c look without such a function call I wonder?

        Regardless, a buildable compiler framework is at least a safer starting ground than one which doesn’t even ship with a usable Makefile nor any ./configure script magic. Did you ever get any further with cc65?

  4. Has there been any development on using CC65?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: