Weird Joystick behaviour

[DragWx]

As for $9F27, CC65 doesn't replace the kernal's default IRQ handler,

I still don't understand how that installs things well enough to use it. (other than to copy the exact code.)
How would you install a keyboard handler?

Oops, let me clarify; if you use CC65's ".interruptor" system, then CC65 will replace CINV with its own IRQ handler (which calls all interruptors), but it saves the old value of CINV so it can jump to it when it finishes, so that's how I made an interruptor and how the kernal's IRQ handler was still working.

If you don't mark anything as an interruptor, then CC65 doesn't touch any of this, and you'd be free to modify CINV yourself however you'd like.
For keyboard handlers, CC65 doesn't do anything with $32E as far as I can tell, so you can modify it however you'd like.

Am I going to have to install and setup a new development framework? and which one and why?

Were you using a makefile to build your program, or did you just have a script or batch file that called the compilers or called CL65?

I'm really sorry that setting up the development environment is the hardest part of programming, but I promise we all share the same frustration.

Edit: If CC65 came with Cygwin, then from what I've read (I'm not familiar with Cygwin I'm afraid), you should be able to run the setup program again, and you might get the option to update the various programs that are installed along with it, like CC65. If not, no big deal; if you download CC65 from Github, you can just unzip it anywhere, and then add the "bin" folder to your PATH variable in Windows (in your environment variables), and you'll be able to invoke the compiler and assembler, especially CL65, from a regular Windows command prompt, but you won't be able to use a Makefile that expects a Unix environment, which is why I asked if you were using one.

[ch4rl3sb]

if you use CC65's ".interruptor" system, then CC65 will replace CINV with its own IRQ handler (which calls all interruptors),

I had no idea such a feature existed.

Were you using a makefile to build your program, or did you just have a script or batch file that called the compilers or called CL65?

I'm using a makefile, but I don't know why or how. I copied it from an existing mixed C and asm example that I stripped the code out of. Maybe I could just use a batch file. I would have to understand what it's doing and why to know.

Code: Select all

ALL_ASM = $(wildcard *.asm) $(wildcard *.inc)
ALL_C = $(wildcard *.c) $(wildcard *.h)

ALL_OBJS = $(patsubst %.c,%.o,$(wildcard *.c)) $(patsubst %.asm,%.obj,$(wildcard *.asm))

all: $(ALL_OBJS)
	cl65 -t cx16 -o SPACED.PRG -m hello.mmap $(ALL_OBJS)

%.o: %.c
	cc65 -t cx16 -Oirs -o $(patsubst %.o,%.s,$@) $<
	ca65 -t cx16 -o $@ $(patsubst %.o,%.s,$@)

%.obj: %.asm
	ca65 -t cx16 -o $@ $<

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

I assume it's collecting and compiling .c, .asm, .h, and .inc files from my project. but I don't know what the rest is, (except for the
-Oirs optimizations.) I don't know how it's doing it. but my latest version was going to just be a C file and headers.

[DragWx]

CC65 is unique in that it contains a program, CL65, which is meant to simplify the process of building your program's source code. So, instead of using a makefile and/or manually calling CC65, CA65, and LD65, you can simply call CL65 with your commandline arguments and the list of your source code files, and it'll figure everything out for you.

In general, what you pass to CL65 are, all of your .C files (don't pass the .H files; the fact that your .C file #includes the .H file is enough), and all of your .S files (again, if file1.S .includes file2.S or file3.INC, you only need to pass file1.S; the fact that the other files are .included is enough).

So for example, if you had main.c, enemies.h, enemies.c, irq.s, and constants.inc:
cl65 -t cx16 -o MYGAME.PRG main.c enemies.c irq.s (plus whatever optimization flags you want)
...because you already #include enemies.h in main.c (and optionally in enemies.c), and you already .include constants.inc in irq.s, so you leave enemies.h and constants.inc out of your call to cl65, since there's no need to compile them separately.

If you're OK switching to CL65 instead of makefiles, I just wrote a simple tutorial on how to install the latest version of CC65 directly on Windows, because I'm not actually familiar with Cygwin at all, so I wouldn't be able to help you update its version of CC65, however it got installed inside there. (If someone else knows though, please chime in!)

[ch4rl3sb]

Although Cygwin does have a cc65 directory, unless make accesses that directly, it isn't in the path.
I have another cc65 install that is in the path.

But, when I set that as backup and dropped a new snapshot in as my cc65 directory, it still does the same thing.
first call to joystick does not respond.

[DragWx]

Does this code from before display the text correctly when you build it with the updated CC65? I just want to make sure we can rule out CC65 and/or its libraries being outdated, because if it isn't that, then I'd likely need to see the full source code of the program before I can figure out what precisely is going wrong.

[ch4rl3sb]

Does this code from before display the text correctly when you build it with the updated CC65?

Yes. it does work now.
My program will *sometimes* work on the first joystick call *if* I configure the mouse pointer first. but only sometimes.
I'm going to give up working on that for now, because I can just use an extra joystick call to get it to work, and then
I can go back to working on the program and not fussing with why this isn't working.

also, the "temp = stick;" line was there because I didn't think I was reading stick into asm properly, but that was with
one joystick call, (which simply wasn't working in the first place.)

__asm__ ("lda %o",stick);
does seem to be working.

[ch4rl3sb]

also, it absolutely IS making it's own .s files on me.
and it occasionally makes a mistake.

Code: Select all

.proc	_Config_Mouse: near

.segment	"CODE"

	jsr     pusha
	lda     (sp)
	sta     _temp
	ldx     #80
	ldy     #60
	lda     #_temp
	jsr     $FF68
	jmp     incsp1

.endproc

line " lda #_temp" causes an error. and it doesn't need the #.

[ch4rl3sb]

but now this new mouse config completely eliminates joystick from working at all anymore...
(i was initiating the mouse (from basic before running my program) with MOUSE 1.)

edit:
And, now, even that completely shuts off joystick from working. No mouse for me.

[DragWx]

Yeah, I think I'm at the point where I need to see the source code in order to figure out what's wrong, if that's ok.

Edit: I see what's going on with the generated .S files, and it's a misunderstanding on my part: It's CC65 to go from .C to .S, and then CA65 to go from .S to .O, and then LD65 with all .O to get the finished binary. I thought CC65 went straight from .C to .O, my mistake. So, your makefile is doing it correctly, I thought it was adding something extra.

I might potentially know what's going on with the "#_temp" error. If that comes from an __asm__() directive, you might have the wrong type of "%" token in there. It'd be nice if CC65's documentation gave an example for each different type of token though. (EDIT: Nope, that's not it, the compiler's good about giving errors, so there might actually be an extra "#" in the __asm__() directive, like "#%v" instead of "%v")

[ch4rl3sb]

so there might actually be an extra "#" in the __asm__() directive, like "#%v" instead of "%v"

it gave an error because there was a difference between the asm command in .c and the version it had in .s

i had:
//__asm__ ("lda %v",temp);
__asm__ ("lda #1");

and I was switching between the two lda to see why it wouldn't work. I would have this version, compile and run, then
comment out lda #1, uncomment lda %v, and the compiler spits out an error with lda #_temp.

I had one of those errors in a .s file for days and couldn't compile ANYTHING, because I didn't know it was in the .s file
that I didn't even know about. I kept thinking it was the .c file. I figured it out when the line # of the error was beyond
my .c file and i looked closer at the error. I hadn't even known it was creating that file.
Much of the time, the .s file doesn't even exist. it pops in and out.

odd thing i just noticed. do you know why the kernal routines are 3 bytes apart instead of 2?
I thought i might have the wrong addresses for a moment when i noticed some of them were numerically odd.