Am I missing something or does what rainwarrior says sound a bit too complicated?
Deleting a module from a library, consciously placing one custom module before an existing module in the link command in a tricky way, creating an alternate minimalistic library?
Why is all of this needed?
I include "nes.lib" as always and simply never reference any header files from the compiler suite into my project. With this, isn't the following criteria already met?
rainwarrior wrote: ↑Wed Feb 01, 2023 11:10 pm
only the things I need for C, and allows me to provide all the "NES" stuff myself.
I have one Assembly file that I call "Main.s" which has my self-written Reset interrupt, my NMI interrupt and some other basic stuff (so you could say that is this pretty much my version of crt0).
And that's it. From within the Reset interrupt, I can call any of my functions, whether they're written in Assembly or in C.
Command line call:
Code: Select all
cl65 -o Game.nes --standard c89 -O -t nes -C NES.cfg Main.s Common.s MainLoop.c OtherStuff.c OtherAsmStuff.s
Why would you ever fiddle with the existing "nes.lib" file or make your own one? Doesn't the compiler omit everything from that file that isn't used anyway?
So, I would say: Just include "nes.lib" with the
-t nes command, so that the compiler doesn't give you a bazillion errors for common C-related stuff (parameter passing, multiplication etc.). But just don't call any of the functions from the compiler's header files in your code. (Or call only standard C functions like strcpy or rand, but not stuff like WaitForVBlank or whatever such a function would be called in cc65.)
Now you can write your game in C without the compiler doing any NES-related things by itself.
By the way, I need to point out that I don't have any kind of
int main() function this way. The Reset interrupt is pretty much my main function. Or maybe the last part of it where it goes into an infinite loop whenever it's waiting for NMI and where it calls ProcessNextFrame whenever NMI is finished.