I threw this template "getting started" project together, with the basic toolchain included "ready to go" for Windows and Linux. The goal is to provide a starting point for people who are totally new and want to start trying things quickly. I'm normally opposed to things like including binaries, but the ones included are 1) rather small and 2) don't require the user to do any environment setup ("What's my 'PATH'?").
A tiny demo program is included, with verbose comments to try to make the purpose behind everything and its organization clear.
https://github.com/mikejmoffitt/nes-template
Cool!
*checks repo*
Hmm, I remember that unnecessary "file = %O" noise in the linker provided by tepples.
Otherwise, nice demo!
Oh, and nice trick with bank_load. Just a thing: I think it's better to use local labels inside of a macro, I haven't tried, but that anonymous label inside of that macro might confuse a branch to an unnamed label around a macro invokation.
Also, why giving "asm" extension instead of "inc" or "h" to files intended to be included, not assembled?
Jarhmander wrote:
Also, why giving "asm" extension instead of "inc" or "h" to files intended to be included, not assembled?
Well, I prefer .asm too. I make the distinction between assembled and included files with a folder structure.
I suppose nes.asm isn't being assembled, but the header file is, so it seems appropriate to at least give that one an asm file extension.
tokumaru wrote:
Jarhmander wrote:
Also, why giving "asm" extension instead of "inc" or "h" to files intended to be included, not assembled?
Well, I prefer .asm too. I make the distinction between assembled and included files with a folder structure.
Hmm, you agree with me, but tell that you prefer using the "asm" extension...
Using .asm for all files can get confusing if/when you start assembling more than one file (cl65 foo.asm bar.asm ...). If you assemble the wrong files, you might end up with multiply defined symbols and other problems. (Especially a problem if you just happen to stumble on some source code and it doesn't include a build script.)
If you plan to only have one "master" file which includes everything else, then I don't see any problem in using .asm for all files.
To prevent that from happening, I've been working with one top-level main.asm file, which is responsible for including other things. Coming from a C background, it was irritating to deal with not having even a mechanism like an include guard.
There's a
.ifndef directive that can make you feel even more closer to C that is available in ca65. My personal exemple:
https://github.com/Jarhmander/nesgame-001/blob/master/include/audio.inc.
Note that you should use "HEADER_INC = 1" (or equivalent),
not ".define HEADER_INC", because
.define merely declare a substitution string, not a symbol, whereas
.ifndef test for a defined symbol, which can be done with e.g. "symbol = <number expression>. Yeah, it's a bit counterintuitive,
and I was bit by that in the past...