A lot of people seem to place a lot of priority on the system having a good basic. I can understand that from a nostalgic or beginner programming view. But personally I would like to see a c (c++) tool-chain for the board. I would not expect it to run natively. This would be more suitable to cross compiling. Most of us will have modern pc's available to do the cross compiling on and can run a proper IDE. The Foenix is not meant as a daily driver :) I think.
I have seen some discussion on this board over this, but it only mentions things like cc65 and how "bad" it is. I was however reminded of a video I watched a few years back:
https://www.youtube.com/watch?v=zBkNBP00wJE
and https://www.youtube.com/watch?v=nLv_INgaLq8
In these videos Jason Turner demonstrated using C++17 for programming the c64 (including demo). It has a GUI that shows c++ with next to it the generated assembly in real-time. In my opinion something like this might make a great match with the foenix. It's really my personal opinion, but assembly is just to much effort and good c code is much more readable and portable and I expect people to want to port to it.
On the Apple IIgs we had APW C from Apple and ORCA/C from the Byte Works. APW C was an ancient K&R C. I can't remember who wrote it, but it was a quick port of some existing compiler for another platform because APDA needed something quick. (similarly the APW assembler was a rebranded ORCA/M) ORCA/C is a proper implementation of C89 (the first modern version of C) that came out two or three years after the launch of the IIGS. It's still sold and recently it's gained some support for parts of C99 added. I haven't used it a lot (back in the 90s I mostly used the ORCA/Pascal and ORCA/Modula-2 compilers) but I've experimented with it some lately. I don't know how good its code generation is but I'm sure it's good enough for most uses. If the code it produced was fast enough fo commercial software on the 2.6 MHz Apple IIGS then that same code ought to be plenty fast on a 14 Mhz machine. Perhaps not for animated graphics or any other particularly performance sensitive stuff but it was fine for desktop applications and utilities back around 1990.
Apple eventually shifted their in-house development to MPW on the Mac, using a cross-compiler to generate 65C816 code. (MPW had both an assembler and a C compiler for producing 65C816 code. I don't remember whether or not MPW Pascal could also generate 65C816 code.) The APW and ORCA tools can be run on macOS, Windows, or Linux using Golden Gate (a commercial product) which emulates the 65C816 and translates GS/OS system calls (and parts of the GS toolbox, e.g., the Text Tools) into POSIX (or win32) system calls.
Two problems with using any of those tools (ORCA, APW, or MPW) to write code for machines other than the IIGS:
They generate OMF files (Apple's object module format) with relocation dictionaries, multiple code/data segments to be loaded into different banks, a segment that determines the amount of memory to allocate for the stack/direct page, etc.
The C compiler (and the other compilers for higher level languages) emit code that depends on GS/OS and the IIGS toolbox: the memory manager, text tools, SANE (Standard Apple Numerics Environment … all the floating point code calls into that I'm sure) etc.
The former isn't a huge problem; writing an OMF loader to load the files would be quite straightforward (the subset of OMF that's allowed in executables is quite small) and some sort of executable format for multi-segment files is a good idea anyway to allow for programs that are larger than 64KB. And for a program that fits into a single segment there's already a tool (the MAKEOBJ tool in ORCA) to turn the relocatable OMF file into a binary that should be loaded at a given address.
The latter is a bigger problem and would make those languages difficult to use for non-GS work without implementations of the necessary toolbox code or making major changes to the compilers' libraries and code generation routines. (All the floating point code would have to be replaced, for example.)
As far as I can tell, the Mega64 is a 65C02 system at it's core (as far as I see it, although it looks like a small number of enhancements, but still the 8-bit system at it's core).
cc65 is not hard to port to a new 6502 platform - I've done it for my own home built 6502 systems, however the Foenix is 65816 based, so any 6502 code is going to be limited to just 64K of RAM.
I've really not looked at taking cc65 to the '816. I'm sure someone can do it - given time and resources though, or even just improve the existing 6502 code generator. Or we (you, me, etc.) buy a commercial license to the WDC 65C816 C compiler, although I'm told the free version is good enough for most projects. I'd like to think that the WDC C compiler produces better code than cc65, but I've no way to check right now and I'd look, but it's really not on my own 6502/65816 roadmap right now. Too much other stuff to do first.
-Gordon
I agree with everything but Gordons last point (though the mentioned tools should definitely be there). The point I was mostly trying to get across is that having a c-compiler (cross compiling) should not be discounted. And that there might be ways to use such a "modern" language on a system like this. There is also a lot of c code out there for things (games? not necessarily c64 based) I and other people might want to port. Rewriting c code to assembly is not really something I would want to do. I realize you can get a lot of performance out of optimized assembly, but it is a lot less portable. With systems like the foenix you talk directly to hardware. But with C-code you would only have to change the function that talk to actual hardware not the logic code.
I believe the mega64 also supports cc65 and supplies some headers and code examples for it on GitHub to give programmers a starting point. Something similar could be done for foenix.
cc65 isn't bad, it's just not good. Lack of general purpose registers makes the 6502 a slightly sub-optimal target for C code generation. It's also 6502 only - there isn't a 65816 variant, however WDC themselves do have a 65c816 version of a C compiler. (both free and paid-for) From what I've seen it's Windows only - probably OK for the majority here though.
And in the past - there were (still are) native C compilers for e.g. the Apple II and BBC Micro. I used one on the Apple II called Aztec C. It wasn't that fast, but was compiling on a 1Mhz 6502 with a relatively slow disk system... Move that to modern hardware and off you go.
Jason Turners seems to be a code translator from x86 to 6502. (someone correct me if I've mis-interpreted that) It's an interesting concept and seems to work for his system.
But while I like C and work with it on a day-to-day basis, I think I'd rather do something like have a good BASIC and a good macro assembler and a mechanism to let them work together. So you do all the "boilerplate" in BASIC and the fast stuff in assembler with a well defined interface to the assembler code...Which is all do-able directly on the system without resorting to cross compiling. (e.g. BBC Basic with it's built-in assembler)
-Gordon