nesdev.com

Correct first thing:
Have you actually tried snes-sdk's tcc-65816 + optimizer postcompiler passes ? Results aren't great but they do work.

Straightforward but untraveled path:
cc65 doesn't support the 65816, but does support the 65C02. The 65816 has a 99.9%-compatible emulation mode, and the DMA unit still works to copy data from nonzero banks. The DBR/B and PBR/K registers still work in emulation mode, so it's easy enough to use one 64 KiB Mode 21h bank for code, and any one of several places for data (e.g. $7E or something containing some ROM). The only major restriction is that you can't move the stack.

Since it compiles explicitly via assembly output, the assembly-and-linking stage will probably even manage far addresses correctly.

That's nice.


Re-focusing on the fact that this is a thread discussing historic things:

The two main consumer 65816 platforms were the SNES/SFC and the Apple IIGS.

For the SNES/SFC: nobody really did C on this, at least not in bulk. There may be a few commercial SNES/SFC games that used implementations/models that closely resembled that of what a C compiler might output (and a few games which used things like printf() %-formatting strings for control, but odds are did not have a full-on native CRT in the game), but I've not heard of any which used C exclusively. And if they did? Then the CRT was certainly custom-made, and all the management subroutines were *absolutely* written in assembly. If there's large-scale evidence to the contrary, I've never heard or or seen it (I would expect someone like AWJ to have/know this type of information).

There is a C compiler for the Apple IIGS called ORCA/C (which is what was used to port/create the GNO/ME OS (UNIX for the Apple IIGS), which uses ORCA/C as its C compiler).

For cross-compilers on the PC, there is Toshi Morita's LCC816 port and WDC's 816CC. I can't speak on behalf of cc65 (if it can generate 65816 code vs. 6502).


x816 is a 65816 cross-assembler for PC. Period. If you want an SPC700 assembler, there are certainly other tools. I didn't do SPC700 back in the 90s so I can't refer you or anyone else to any, but people absolutely did their own engines/code (Censor SIDMANIA is a great example -- again, there's no video of this on YouTube etc., so I should probably make one. It doesn't run right on emulators :D). Commercial companies may have made their own tools or used whatever SPC700 assembler was provided by Nintendo/Sony. TMK, nobody had a single tool that did both.

Homebrewers on the PC often used TASM (Telemark Assembler / "Table" Assembler) (proof is here -- from the guy who I worked on Super Kid Icarus with) to do SPC700, since TASM is well-suited for that kind of thing.

Being practical: honestly, most homebrew has most of its difficulties relating to the actual platform its being run on (in this case we're talking about the SNES/SFC). People working on a game design the engine, graphics, sprites, and all the "mush" that puts it all together. I can't speak for everyone, obviously, but almost every developer I've seen here starts there -- and worries about the sound aspect later. Music/sound is important, but it MOST DEFINITELY is not where homebrewers start. People doing solely music may in fact start there, but the NES today has several audio engines/sequencers/tools for audio.

While I'm here: please stop this kind of weird "snowballing interconnection" nonsense (bringing C into the picture, expecting a port of an existing tool to contain another assembler for a different chip (do not even start with me about it being a tweaked 65xxx)). Come on, dude.

And I did just that tonight (the bugs are described in the video details): https://www.youtube.com/watch?v=VUfWKdTKc5k

The results are terrible, and do not work. I have lots of data from an upcoming game where that combination fails completely in weird ways, examples like a variable being 16-bit fails but 8-bit and 32-bit work, reordering initializations makes things work while some orders fail, and so on. You can't even call a thing like that a compiler.


I believe you, but why is the past important? Most Genesis games were also made in asm, yet today no dev valuing their sanity does so.


Hey, I mentioned the C compiler in my original post. No snowballing there

Didn't know about this assembler. The latest Windows binaries available on that site are for v1.6.0, which is circa 2006. Where are more recent binaries?

68K is a different architecture altogether, and can actually cater to C's designs/needs easier than the 65xxx series.

Why the past is important... wow, I don't even know where to start, so I'll just brain dump.

We're talking about consoles that were invented in the late 80s/early 90s. These systems were not developed "with C in mind" -- rephrased better, they are not personal computers. They are not intended for multiple tasks (ex. a general home computer at the time was multi-purpose, handling things like spreadsheets, word processing, games, and later on, networking), they more appropriately classify as embedded devices. They were designed with use of assembly in mind -- *especially* the SNES/SFC (all official documentation references assembly methodologies, including providing code and tools for that; NES/Famicom I don't think even included an opcode listing, just that it was a 6502 variant, i.e. you want to work on the console, you write assembly). C compilers were not something that was a focus in either case. I cannot speak on behalf of Genesis/Megadrive because it's a console I haven't spent any time developing on, but I can tell you Toshi Morita -- who was the lead programmer of Zombie's Ate My Neighbours -- did all his work in assembly (I spent an afternoon/evening with him and some others who ended up at Tiburon back in 1993).

Secondly, the initial post talks about making a book about obscure NES games, including homebrew titles (and probably some of the more successful/well-rounded translation/romhacks). Are these games and homebrew titles being done on, say, a PC? Nope. What about an Amiga 4000? Nope. A home video game console of the mid-to-late 80s.

I see this constantly around here now (and in tech in general, but it's prolific as hell around the NES and SNES): people trying to instil crybaby beliefs about PLs into the console. "Wah, I don't like assembly language, but I really want to make something on this archaic system that I'm sporting a major hard on for. I'm familiar with Javascript and Ruby. Why can't the NES run these? This is stupid!" Yes I'm overdramatising (or am I?), but it's a bizarre mindset: wanting to develop software for a 30-year-old system (NES/FC; for SNES/SFC, make that ~24 years), but having present-day ideologies and beliefs and habits (esp. about PLs) somehow take precedence. I'm not talking down anyone on here, honest, but many of us who have been doing 65xxx assembly for a long time know that the architecture does not "mesh well" with C. That said: is it possible to use C on the NES? Yes, and either in this thread or another (I forget), there have been several titles done that way. I think that's awesome. But doing so still requires that you know and use assembly at some point, especially for debugging/troubleshooting. In other words, you cannot avoid the reality of needing to know and use assembly on these platforms.

The reason I asked about the SNES/SFC because the initial post mentioned making SNES books along the same lines as what was proposed for said NES books, with with this line in focus: Interviews with Homebrew developers, musicians, artists, etc. -- and the thing is, those of us who were around during the apex of real homebrew development on the SNES/SFC (the early 90s -- then went on hiatus until the late 90s when emulators started coming to light, prompting the creation of the romhacking scenes more-so than actual homebrew) and the start of North American homebrew for the NES/FC (again: starting in late 90s due to the creation of emulators; I don't know about other countries, incl. Japan)... we're still alive, you know. It's just that nobody has, from what I can discern, bothered to track us down and interview us about how things were then. (I will point out though that different platforms/consoles had very different scenes going on. It would be impossible to do a book on the evolution of emulation because the scenes were all separate/unique: NES vs. SNES vs. Genesis vs. PCE vs. GameBoy vs. PSX etc. -- folks from each scene would have to be tracked down).

So, when you ask a question like "why is the past important?", I cannot help but shake my head. No offense, but it is questions like this which have driven me out of tech (as a career) and greatly diminished my interest in anything technology-related as a hobby. But don't worry, not knowing how something works is the current "in" trend -- but eventually someone does need us.

Eh, it's not like I said history is worthless, I was speaking in the context of making new games. Having no C compiler is a significant obstacle, and that past games were all in asm does not matter vis a vis new development.