How to program an NES game in C

Post by digi_owl » Sun, Aug 13, 2017, 3:48 PM UTC

DSMan195276 wrote: post #10

simias wrote: post #3

Earlier quoted context omitted.

I feel like handling ROM banking would be the most challenging part of coding in C. You have to swap portions of your program in and out constantly (unless you manage to fit it all in a single bank). It seems hard to abstract that efficiently from a high level language. I heard there were C compilers for the Game Boy as well but as far I know they were never widely used.

Yeah, C generally assumes a 'linear' memory space, so memory banks don't really fit into it extremely well. That said, with a little work you could likely coax the linker into doing a lot of the work for you. You would have to be a little careful though, as code in different banks could not effectively call each-other directly, even though the compiler would likely not yell at you. But you could just organize your co…

Post by pjmlp » Sun, Aug 13, 2017, 3:52 PM UTC

userbinator wrote: post #9

pjmlp wrote: post #5

Earlier quoted context omitted.

Even a 8080 would be problematic, given near and far segments and the memory tricks we used to do to fit everything into the available memory. Then it also depends on the IO and video architecture. The PC ones were a bit of a pain.

A 8080 has a linear 64K address space, like the 8085 and the Z80. Perhaps you were thinking of 8086? In any case, 64K address space is not the real limiter with a 6502 --- it's other things, like the tiny number of registers, relative shortage of 16-bit addressing modes, and fixed(!) 256-byte stack which make it difficult to program in C. Even the 6800, with its 16-bit index and stack pointer registers, would be easi…

Post by Drakim » Sun, Aug 13, 2017, 4:18 PM UTC

digi_owl wrote: post #12

DSMan195276 wrote: post #10

Earlier quoted context omitted.

Yeah, C generally assumes a 'linear' memory space, so memory banks don't really fit into it extremely well. That said, with a little work you could likely coax the linker into doing a lot of the work for you. You would have to be a little careful though, as code in different banks could not effectively call each-other directly, even though the compiler would likely not yell at you. But you could just organize your co…

My impression is that the banking was more often used for graphics rather than logic.

Post by mstevens » Sun, Aug 13, 2017, 4:53 PM UTC

userbinator wrote: post #2

IMHO a 6502 is too limited to be effectively programmed in C; even this part of the article gives all the limitations: https://nesdoug.com/2015/11/15/2-how-cc65-works/ With this important note: "clean unaltered C code will compile into very slow code that takes up too much of the limited memory space." In other words, "C" written for such a CPU will be in a vastly different style from more "normal" C, so that it migh…

Post by chrisseaton » Sun, Aug 13, 2017, 5:02 PM UTC

mstevens wrote: post #18

userbinator wrote: post #2

IMHO a 6502 is too limited to be effectively programmed in C; even this part of the article gives all the limitations: https://nesdoug.com/2015/11/15/2-how-cc65-works/ With this important note: "clean unaltered C code will compile into very slow code that takes up too much of the limited memory space." In other words, "C" written for such a CPU will be in a vastly different style from more "normal" C, so that it migh…

From that page, "use ++g instead of g++ (it’s faster)" I've seen people say this a repeatedly when talking about "embedded" environments, but never understood why - won't it end up compiling to the same thing either way?