Overall it does seem like the development scene is pretty slow even compared with the NES and Mega Drive, never mind the C64...

There's been a persistent barrier in that even the best, structured 65816 code is basically a write-only language (I've had to abandon several fan translations due to code rot.) And the CPU is just too slow and too limited (*one* accumulator, *two* index registers, awkward 8/16-bit toggling) to pull off a higher level language.

What has made the Mega Drive a breakout hit in homebrew is that you can write the non-critical sections in C. Any attempts at C with the 65xx chips produce unusably slow code.

I disagree. The 816 is relatively suitable for C, its stack modes in particular are useful for that; not as well as m68k, but far from unusable. I have several titles shipped in C for the NES, and Little Medusa for SNES, and given it's not unusably slow for NES, how could it be for the 1.5-2x faster SNES?

It's not the lack of suitability, but the lack of a compiler. Genesis has the latest GCC, arguably the best compiler in the world. SNES has nothing*, though I managed to use cc65 on it, cc65 doesn't count as a "real" SNES compiler in that it doesn't support it fully. It works, but it produces 8-bit code, which is not as fast as it could be on a 16-bit processor.

You can expect more SNES titles now that we have cc65 set up. Even with its limitations, it's a massive productivity improvement over asm.

while I will agree that 65816 is not the most readable language, and write only as you put it. I will however point out that 65816 is good solid chunk a head of 6502 in this regard, and the superlative specs of the SNES make it less of an issue compared to a C64.

I'm curious regarding your cc65 comment for the snes. What are the limitation to expect? Since I like more and more to write c code for the nes the logical thing would be to write some for snes too but it's always good to be aware about the trade off to do so.

In general, cc65 is limited in that it's not a C-level optimizing compiler. It just translates what you write, and applies some asm-level optimizations. SNES specifically, it doesn't do banking, but just like with NES banking, you can work around that, with trampolines for example.

For banking that is not a big issue. What I would be more concerned is the comment about 8 bit generated code. That seems not much convenient. For UI screen it may be ok but more intensive code, I guess it need to be written in asm anyway.

ORCA-C's license has a no commercial use clause. That's a dealbreaker, so I didn't even look further at what it might be able to do.

When told to compile for 816, cc65 uses the best instructions it knows, which are the 65c02 extensions IIRC. Thus the code is better than when targeting NES, even if it doesn't know about 816-exclusive instructions. cc65 allows inline asm, and a SNES trampoline might work by a jump table, but many other ways too. Lorom yes, since it expects RAM in the same address space. It does not use the 6502 emulation mode, it runs natively, meaning any asm functions you've written can use anything new.

That's not much different from the NES; the speed-requiring functions are written in asm and everything else in C.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum