Weird Joystick behaviour

[DragWx]

The kernal routines are 3 bytes apart because they're all JMP opcodes. So, when you JSR to $FF68, the actual instruction at $FF68 is a JMP to where the "actual" location of that function is. It's done this way because there's no 6502 instruction for "indirect JSR", so the best we can do is to JSR to a JMP.

One more note, it's a good idea to do "make clean" every once in a while, to delete all of the build artifacts so you can do a fresh recompile of your whole source code. If something's really inconsistent or there's a compile issue that doesn't make sense, this can sometimes fix that. Fortunately, your makefile's "clean" target is just a single line with no variables in it, so you can see exactly what it'll delete (and do make sure to check).

Otherwise, I truly have no idea why __asm__("lda %v", temp); would be producing lda #_temp, unless it's a build issue that requires a clean, or an optimization doing something unexpected and incorrect.

[ch4rl3sb]

they're all JMP opcodes

Oops. I realized that had to be it 5 minutes ago. Doh

it's a good idea to do "make clean" every once in a while,

I've been using a cl65 instruction recently because I didn't know if make was going to use the wrong version of cc65. What does that make clean line delete?

unless it's a build issue that requires a clean, or an optimization doing something unexpected and incorrect

It's only happened to me three times. The first time it took me days to get the compiler working again. This time, I saw what file the error was in quickly.

[DragWx]

I've been using a cl65 instruction recently because I didn't know if make was going to use the wrong version of cc65. What does that make clean line delete?

At the bottom of the makefile you posted, there's the line that says:

Code: Select all

clean:
	rm -f *.PRG *.mmap *.o *.obj *.s

so, it would delete the .PRG, the .mmap file, all of the .o, .obj, and .s files (I noticed your makefile was also set up for you to use .ASM instead of .S for your assembly source code; I'm not familiar enough with CC65 to know if this is common or not, but that's why we were using different file types from each other). If you're using CL65, then none of that matters because it'll always recompile everything; I don't even think it creates any files other than your final .PRG file.

The way GNU Make works is, all of the commands will run just like you're typing them into the same command prompt you invoked "make" from. So whichever version of CC65 runs when you type "CC65" at your command prompt is what will run when you build from your makefile.

[Daedalus]

I routinely clean everything before every build for X16 projects, the compile is so fast, it's not even noticeable anyway, and that just safeguards against 'goofiness'. I started doing that after about the tenth hair pulling session that turned out to be something not being recompiled.

Also, Make requires a TAB as the indent character prior to each line after the rule (Like clean:) instead of spaces. I'm not saying you guys don't know that... it's just easy to mess up and gives no really coherent warning.