I've been musing about doing some NES dev lately, and went through the first few of Doug's tutorials. The last time I did any 6502 assembly or used cc65 was ~10 years ago, but it seems to be coming back pretty quick.
Just as an exercise try and understand all the tools and basics, I went back to the first tutorial and tried to rewrite it from scratch. I think I have a handle on everything except for the ld65 .cfg file. Basically my question is, where is the information that tells the cl65 linker to output the memory areas in the right order? I can't figure out how anything in the .cfg file informs the linker to output the iNES header, the PRG ROM, the vector table, and then the CHR ROM in the output file. My experience with other toolchains has always been that the linker already knows the executable or library format you intend to make (because the toolchain was built for your OS, or as a cross-compiler). The possibility of a linker being configurable to output into an arbitrary file(s) has never even occurred to me.
The ld65 docs mentioned that the order of the segment definitions determines their order in their output memory areas, but what determines the order (or existence) of the memory areas in the output file? If I rearrange the memory areas in the .cfg, it still works!? Similarly, how does it know not to write other memory areas to the output? Does it not write the RAM area because the only segment in it is type bss? I'm baffled how there is enough information to create a valid .nes file.
Just as an exercise try and understand all the tools and basics, I went back to the first tutorial and tried to rewrite it from scratch. I think I have a handle on everything except for the ld65 .cfg file. Basically my question is, where is the information that tells the cl65 linker to output the memory areas in the right order? I can't figure out how anything in the .cfg file informs the linker to output the iNES header, the PRG ROM, the vector table, and then the CHR ROM in the output file. My experience with other toolchains has always been that the linker already knows the executable or library format you intend to make (because the toolchain was built for your OS, or as a cross-compiler). The possibility of a linker being configurable to output into an arbitrary file(s) has never even occurred to me.
The ld65 docs mentioned that the order of the segment definitions determines their order in their output memory areas, but what determines the order (or existence) of the memory areas in the output file? If I rearrange the memory areas in the .cfg, it still works!? Similarly, how does it know not to write other memory areas to the output? Does it not write the RAM area because the only segment in it is type bss? I'm baffled how there is enough information to create a valid .nes file.