For what it's worth, overall I agree with byuu's stance on this (i.e. I've never seen C as a practical language on the 6502/65c02/65816 given how the designs and limitations of the architecture). I also agree that the 68K almost certainly is a substantially better CPU for C (or x86/x64 for that matter). All the additional registers, instructions, and addressing modes/features make it a better choice.
Switching consoles for just this paragraph: I think there are some C-based NES games which are pretty cool, but yes, you aren't going to find anything like, say, Gradius 2 in C on the NES -- or if you do, all the key/critical innards are done in native 6502. C has just too much "overhead" on the 65xxx architecture.I don't write C compilers or look at their innards
, but the limiting factors with the CPU architecture have nothing to do with the SNES's memory models (mode 20/21/25), although you probably would want mode 21/25 for a linear memory map, though the trade off is that MMIO register accesses take longer (you either use 24-bit addressing or you're going to be doing phb ... plb
a lot), and the lda #$2100, tcd
trick probably isn't going to help you either (I imagine C compilers on the 65816 make heavy use of DP).
I feel like a broken record saying this, but for the 65816, there are actually two C compilers that I know of: Toshi Morita's lcc816 and ORCA/C
for the Apple IIGS. I can't remember if cc65 can be used either, but I do know ca65 has some very annoying design quirks/issues with 65816 that make it painful (I can't find the link on the forum, but we've discussed it before). lcc816 outputs code intended for ORCA/M
(Apple IIGS), because Toshi did a lot on the IIGS (he's a guy I met back in 1993 and spent an afternoon/evening around). If you want to talk about "C compiler design for 65816" (since this thread is about the SNES, hence 65816), then Toshi might be a worthwhile person to ask, especially given his background
(read, don't skim -- you will find several compilers he's worked on). (Injected note: I feel lucky that I still have my ORCA/M data around, as the Syndicomm website seems to be completely MIA at this point. That Opus ][
product is probably the best bet for getting your hands on it). If I remember correctly, and this is key, the ORCA/C manual actually goes over some of the internals of *how* it was designed/works.
I used ORCA/C on the IIGS for small/worthless projects (back when I was trying to learn C) and because it was the compiler used
as part of the Apple IIGS's UNIX OS called GNO/ME
. You'll find that most Apple IIGS projects involved ORCA/M (assembler), simply because, yes, that's right, the 65816 doesn't cater well to C in general. There were a couple games made for the IIGS in ORCA/C, but they were things like Tetris clones and (sorry for downplaying the complexities) "simple" games. For anything highly complicated and needed every cycle, assembly was the go-to. There were LOTS of great games on the IIGS in assembly. I can't speak for others, but I mainly did everything in ORCA/M (65816) (using Applesoft BASIC or ORCA/Pascal to generate data sets for me, although I did write a CDA in ORCA/Pascal). On the SNES, most of my efforts were done using a PC and cross-assembler, with nothing more than edit.com
(QBasic in editor mode); any graphics/layout data I did was all hand-done using .dcb
Did you notice a common theme in my above paragraphs? If not, here you go: the projects done using ORCA/C and similar were done on a system and environment -- the Apple IIGS, usually within GS/OS -- where tools were available (and those which weren't, you made yourself), all the way down to graphics editors (DreamGrafix
) and audio tools (Soundsmith
), and with tools that integrated with assembly very very well (this is critical/key!). Debugging was possible through a multitude of ways (GSBug, and classic printf-style debugging if you were using something in the ORCA shell environment), etc... Basically none of this is available on the SNES because it's a video game console, not a home computer. (Injected note: the guys who made DreamGrafix -- Jason Andersen and Steven Chiang -- were both co-founders of Tiburon Entertainment (now known as EA/Tiburon) and did all the Madden SNES titles. Jason worked way too much stuff
(almost all in 65816), and Steven's now the executive VP
at Warner Bros. Games).
So, all that said: the lack of C compiler really isn't what's keeping people from doing SNES homebrew. There's a term for this that I can't recall right now, but it's one of those "convenient excuses" that people use rather than actually putting in the time/effort to do what their heart is set on. The elephant in the room isn't the lack of C compiler, it's that "writing stuff on the SNES is hard". "What are all the registers? OMG", "I don't understand assembly language, it's nothing like Ruby/Python/Node/blah blah", that kind of thing. Consoles, much like arcades, are a completely different world. The potential gamedevs that might be considering the SNES probably come from backgrounds that are PC-centric, using a plethora of tools and languages and frameworks to accomplish their goal. You throw them into an environment that offers none of that and they're like a fish out of water. Why do you think there's such a humongous influx of indie games on Steam/etc. that have "16-bit-like graphics" but are PC (possibly Mac/Linux) titles?THAT
is why people aren't doing more SNES homebrew.
Breaking out of this excuse model is possible. One such example, though for the NES, is forum user JoeGtake2's game Mystic Searches (see The New 8-bit Heroes
). He had game development experience prior, but no 6502 or NES knowledge. He set his mind to it, and he's doing it. In C? Nope, in assembly.
So, really, the reality is that people want "a convenient way to make stuff", and like arcades, there is nothing convenient about classic video game consoles when compared to present-day stuff for the PC (in contrast/comparison). The "lack of C compiler for SNES dev" is really not the crux of the matter.