Is there a C compiler for the W65c816?

WDC has a C compiler, but their website (https://www.westerndesigncenter.com/wdc/tools.php) says:

I want to emulate the W65c816 on an FPGA processor, but the purpose of this exercise would be to run C code, especially Free-RTOS.
The W65c816 is a good target for a byte-code VM because all of the opcodes are one-byte, as compared to the more popular MC6811 and MC6809 that have multi-byte opcodes.

Over at https://github.com/lcc-816 there is a repository with source for a port of a recent-ish version of the LCC compiler for 65C816. There is also a repository with a copy of the source for Toshiyasu Morita's 1994 port of an older version of LCC that targets the Apple IIGS platform. Alas, the usual 6502 C compilers (vbcc, cc65, llvm-mos) seem not to support the 65C816, though I believe many of them have associated assemblers that may. (Not a help for programming in C, I know.)

Maybe somebody else here knows of better, or more, options?

I was recently contemplating whether it would be feasible to port chibicc to target the 65C816. That would seem to involve replacing the codegen.c file (~1500 lines) with something that produces 65C816 assembly instead of x86-64 assembly.

Calypsi C is the compiler utility that i've been using for a while now. it's pretty good.

I wouldn't let the CPUs underlying opcodes be a reason for/against running a bytecode VM on it, however ...

I have a bytecode VM running on my '816 systems. I do not feel It's a good target for a bytecode engine host for many reasons...

One - the core function of fetching bytes - is that the '816 lacks an instruction to load an 8-bit byte into the 16-bit Acc, zeroing the top 8-bits at the same time. So the core fetch code in my VM wastes a memory cycle loading 16-bits, then wastes another 3 cycles with a 16-bit AND instruction before it can then index that value in the jump table. This overhead adds 4 cycles to every single byte code fetched which may not seem a lot, but it adds up.

You may think that dropping into 8-bit (memory) mode might help but that just adds cycles going each way and it still doesn't zero the top 8-bits of the 16-bit acc.

Other reasons include dealing with the 64K banks of RAM because my target high level language (BCPL) wants a linear address space. But even with that, it dos run well and has enabled me to do what I want in BCPL including running the compiler on the hardware and writing a multi-tasking OS with it.

The only C I've used on the 65xx is cc65 which doesn't support the '816 - I've really no idea how the other compilers fare when dealing with data structures > 64KB in ways transparent to your code or things that compile to > 64KB of code. Then there's the issue of loading your program+data into all those 64K banks before you can even run it... I'm suspecting that may be left as an exercise to the user... but if anyone has some examples (make a video?) I'd like to see..

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Data structures larger than 64k are trivial on the 65816 due to the absolute long addressing modes.
Code larger than 64k is a bit more tricky but pretty much all that matters is that no function is sitting on a bank boundary, and that all functions jump between each other using JML, JSL, and RTL.
Thats what the largest data and code sizes do in calypsi C, and it's also what I use despite all my programs being smaller than 64k so far.

It's trivial - for a cost. That cost is your time to work out the right/best way to do it - which may not be the most efficient way for the CPU to work. (ie. incrementing a 24-bit pointer in DP vs. INX and so on) All decisions I had to make in my BCPL VM system - and I really should go back and re-evaluate them.. One day!

I've managed to find the manual for Calypsi C.. It seems you do need to be aware of what size/model your code and data needs, so you can either be lazy and declare everything to be 'huge' (requiring 32-bit pointers for things), or try to optimise it yourself when you know the size of data structures, arrays and so on. Which is fine, but it does add an extra bit of thought on the programmers part. (And I know some may argue this is par for the course, given the nature of the '816).



What is your target? Do you have a Foenix system or your own '816 board? If the latter, how much work was it to make the compiler work with your own hardware - IO, program loader and so on... ?

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

You misunderstood me:
I meant that the W65816 would be the byte-code VM that is emulated on my more powerful processor.
I would get rid of 8-bit mode completely --- I have no interest in running old 65c02 software.
This frees up a few opcodes in the W65c816 that can be converted for use in supporting Forth. This won't help the C compiler, but it won't hurt it either (I assume that the C compiler didn't use 8-bit mode).

The purpose of emulating an existing processor such as the W65c816 is so that I can have C code running on my processor without me needing to write a C compiler. This is going to be much slower than native machine-code on my processor, but the advantage is that I can have gigantic programs and an RTOS out there in external-memory, whereas internal-memory is limited to a few KW.

I'll look into those C compilers the others mentioned.
I remember reading the book on LCC back in 1994. It didn't work for me then because it requires a lot of registers, which I didn't have on the MiniForth processor. In a W65c816 emulation though, we can have a lot of pseudo-registers in zero-page --- also, zero-page can be mapped to internal memory for speed.

Other than C compilers, is there any useful software in the public-domain for the W65c816?
I have read that there are emulators for the W65c816 that can run old Super Nintendo games. This is pirating though --- all of the Super Nintendo games are proprietary to Nintendo --- I don't want to run any W65c816 software that I don't have permission to run (I already mentioned the WDC C compiler).

What I remember from the 1990s is that the W65c816 was used in the Apple-IIgs (the W65c816 may have been developed specifically for the Apple-IIgs). The Apple-IIgs died because it was considered to be a poor man's Mac, but the price of the Mac went down so that it became affordable. Then the W65c816 got chosen for use in the Super Nintendo. Bill Mensch was extremely pleased with this, as the Super Nintendo was a cash-cow for WDC. Because of this, he ignored everybody else --- if you weren't buying W65c816 chips by the thousands, then you weren't getting any support from WDC --- so the W65c816 didn't get used very much --- when the Super Nintendo died, the W65c816 pretty much died with it.
Does that pretty much cover the history of the W65c816? There are still W65c816 enthusiasts, mostly on this forum, but the W65c816 is no longer gets much (any) use in commercial applications.

Are there any FPGA W65c816 processors?

Oh, Right.

In which case why are you bothering with it at all? Just pick a nice CPU that's well known and understood, doesn't have the 64K bank shenanigans and use that instead. I can recommend RISC-V having worked with it recently - it's a joy to use. Several C compilers and easy to code for in assembly and FreeRTOS already going on it...



and as you're finding they aren't many - hence my choice to use another language (BCPL) and my suggestion to you to use another CPU.



SNES games are usefull to many... the Apple IIgs is still usefull to many too. The Acorn Communicator? Not really.



The Acorn Communicator pre-dates the Apple IIgs (but not by much). It was built by Acorn and aimed at the business market - people who wanted a usable desktop system with built in modem - in the pre-internet UK we had a dial-up thing called Prestel that was intended to be used by small businesses - I think it might just have been the travel agents who used it a lot, but who knows. Acorn dropped it as they were developing ARM at the same time, so no point continuing when they have much nicer and 100x faster CPUs to work with.

But yes, the '816 is dead - or seems that way. The SNES version had additions to the hardware that were handy for video. WDC are still making them though, so somewhere there are enough commercial projects still using them - I suspect buried inside some embedded systems somewhere, but where? Who knows.



Several - WDC has their own commercial one and there are a few free offerings online - also software emulators in e.g. the PiTubeDirect project. https://github.com/hoglet67/PiTubeDirect

Here is an FPGA one, but I've no idea what its state is: https://opencores.org/websvn/listing/v65c816/v65c816

Some interesting ideas though.

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

(Sorry, this is all a bit OT to the thread itself)



Nice find, but there's nothing there yet - just a two month old repo. The developer (Valerio Venturi) does have a track record, an enhanced 6502 (video demo)

A relatively major problem, I think, is the number of corner cases in the '816 behaviour, and a lack of a test suite. (Unless, once again, I've forgotten something.)


I'm tempted to say undead! There is a minority interest in this forum, for sure, and it does keep popping up as a possibility. There is a 65816 BBC Basic, extricated from Acorn's Communicator, which might have a 64k allocation for program and data.

Yes - "undead" but not mainstream. I think we do have to remember CPUs like this - there were many that just didn't make it for many reasons and we need to remember why not (history repeating itself and all that), or fitted into the "too little, too late" bracket. It has historic interest though and one day I'll try to use that '816 BBC Basic ...

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I mean if you're writing programs in C for these CPUs you likely aren't going for speed anyways, so personally i don't mind those extra bytes and cycles... especially at 12.5MHz.
as for the data/code sizes, you tell the compiler which one to use by default. but using attributes you can manually declare variables and functions to use different address sizes. (similar to cc65 as well)


It's a custom 65816 SBC. getting the compiler running wasn't that much work.
like with cc65 you need to modfiy the startup assembly file and define your memory map. and ideally also write your own _Stub_write/_Stub_read functions which are used for stdio's printf and similar.
i have a minimal setup on my SBC's github: https://github.com/ProxyPlayerHD/65816_ ... /main/code

Forum member Rob Finch lists his bc65816 on this page of his web site. "I had several requests to post the code, even though untested."

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

What is a "corner case" in the '816 behavior?

The weirdest thing about the '816 was that it had 8-bit and 16-bit mode. If you disassemble the code you don't know what it does without knowing if the registers are 8-bit or 16-bit. I would get rid of 8-bit mode altogether though, so this is no longer an issue. Also, I would require data to be even-aligned (like on the MC68000) because I would have a 16-bit data-bus. A multiply instruction would also be useful. I haven't looked at those C compilers yet, but I would expect that they can easily be upgraded to work with these modifications.

Apparently WDC was given a mandate from Apple that their processor had to run 65c02 code. This is why WDC went with an 8/16 hybrid rather than build a 16-bit processor that would have been competitive with the i8086 and MC68000 that were the mainstream 16-bit processors of that era. The i8086 (and NEC V30, etc.) and MC68000 had excessive interrupt latency that made them bad choices for use in micro-controllers. There are a lot of "might have been" design decisions that could have propelled the '816 into mainstream use --- instead the '816 became a footnote in the history books.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?