The VS23S010D falls between software video generation and a dedicated video IC. It's more a microcode engine than a video generator, using a display list to generate a video signal. Video frames can be any length from 1-1023 lines; lines can be 1-4096 Vclks (8 tiles color carrier) wide. Pixels can ...

Reading the HyperC manual, and writing a bit more test code, I still can't decide on using a register or accumulator architecture for the bytecode. I appreciate you finding the HyperC manual, that's a great resource, Andy!

I see two ways to do the bytecode compiler: (1) a HyperC-like register based ...

@handyandy

I haven't looking into Hyper C before. Some cursory searching on the internet has only yielded a few mentions as well as files that can only be opened, presumably, in an Apple II. If you have some documentation saved on your computer, I would be very grateful if you shared it with me. I ...

@kc5tja You're right, I didn't factor in optimization. With some pen-and-paper experimentation, I've noticed that most stack drops can be left out until the end of a basic block, but I didn't consider stack fiddling. Of course, a code generator for a high-level language shouldn't need to use Forth ...

I don't see a problem with that. Existing CC65 users will greatly appreciate compatibility with the toolchain. I myself don't have experience working with the toolchain.

Or you could re-use the ancient 'register' keyword to zero-page variables
Unfortunately, the register keyword is not allowed for static variables, which you might also want to allocate in zero page.
I've been looking at how the Kiel C51 compiler for 8051-family processors works with the 8-bit ...

The transfer is of course that if a C compiler needs minor incompatibilities with common C to make it really sing for 6502, it seems appropriate to take that avenue.
What are some incompatibilities that you would suggest for the 6502? Are you thinking of extensions to the standard, or deviations ...

I'm not opposed to designing a new 6502-tailored high level language. My goal is specifically to develop a C compiler for the 6502, though. And we won't be bound completely to the C language —the standard makes plenty of provision for platform-specific and non-specific language extensions.

But ...

Since this topic comes regularly (including in my own head), I made a post on NESdev summing up all current existing possibilities to code for the NES (or any other 6502 machine, really) using a high level language. I could do the same here but I do not want to maintain two separate post when I ...

Call graph analysis would be very helpful as well: to build a call graph of all the static functions in a module and automatically assign static spaces for parameter passing and locals. Or, the static qualifier could be placed on a function parameter to be passed the same way.


I don't think C ...

Finally, compilation to bytecode would be a great for memory-limited platforms, though this would greatly slow down execution.
It seems to me that using bytecode would be a good way to hide the underlying CPU -- NMOS, 'C02, '816, whatever. You could start by using an NMOS routine to support each ...

@BigDumbDinosaur, I had no idea how non-specific I was by using the term "NMOS 6502"! A general NMOS 6502 target should cover most use cases. I don't see anyone using a C compiler for Atari 2600 code, but 6507 support should be no problem—just a reduced address space. As for the 6510, the $00/$01 ...

An NMOS 6502 target should still be available, though, for people compiling for retrocomputers and consoles.
CC65 is good for that purpose. My opinion is that the time to be expended in developing a new compiler should be focused on the present state of 65xx technology...
While our focus should ...

C compilers targeting the 6502 have never been very good--the processor just wasn't meant for C. Part of the problem is a lack of good tools...
I would suggest targeting the 65C02, not the NMOS part...
My apologies, when I say 6502, I generally mean the 65C02. I agree that the 65C02 enhancements ...

Hi, 6502.org.

C compilers targeting the 6502 have never been very good--the processor just wasn't meant for C. Part of the problem is a lack of good tools: cc65 (the most commonly-used one) has insurmountable problems owed to its small-C heritage, including relying on a very slow (zp),Y -based ...