Read read joystick with cassette plugged in

[AndyH]

I have two older (2 prong power) Vic's that I have hit a problem on with my joystick code. The code I use is below and when a cassette unit is plugged in to the vic, I can only ready the right direction on the joystick. Up, left, down and fire are unresponsive.

Is there something I need to do while reading the joystick to get the values correctly?

Code: Select all

VIC20_PORTACASS = $911F
VIC20_PORTBVIA2 = $9120  ; Port B 6522 2 value (joystick)
VIC20_PORTBVIA2d = $9122 ; Port B 6522 2 direction (joystick)

ReadJoy1
	LDA VIC20_PORTACASS
	EOR #$FF
	AND #$3C
	LDX #$7F
	SEI
	STX VIC20_PORTBVIA2d
	LDY VIC20_PORTBVIA2
	BMI _JoySkip
	ORA #$02
_JoySkip
	LDX #$FF
	STX VIC20_PORTBVIA2d
	CLI
	LSR
	STA joy1

As mentioned the above code works if the cassette unit is not plugged in. I only mention testing on the older model Vic's as that is all that I have to hand right now, not been able to test on a CR Vic. In VICE I get no issues.

[AndyH]

Ah, a little more detail and context probably helps.

I have a tape and Tapino inserted together on a Y connector and I am loading from the BackBit cartridge. Small details are probably important right? Yes, the issue seems to only occur with the Tapino plugged in and the cassette unit appears not to play a factor with the problem.

I can get the joystick to work if I select and play a tape image on the Tapino, or if I unplug the Tapino before switching on and loading.

Oh, I did also try jsr 65017 at the start of my program, as I had found a comment about it fixing a similar issue, but unfortunately it seems to have no effect for me in this situation.

[Mike]

Your joystick routine looks fine, given it properly extracts the relevant bits from $911F and $9120 and doesn't work with entire register contents.

Two possible candidates:

• other software like the drivers for the Tapuino or Backbit set the bits responsible for fire and left/up/down direction to output, for whatever reason. You should check whether the DDR of VIA #1 Port A contains the default value, PRINT PEEK(37139) should give 128 as result.
• you don't tell where "joy1" is located. If it is somewhere in zeropage, chances are that, again, the Tapuino or Backbit software interferes.

A cross-check with other joystick routines is probably also in order. The Denial-Wiki has an example you can try out. It likewise doesn't (re-)init the DDRA register, but that also shouldn't be necessary: if extra hardware uses the joystick signals for a bidirectional protocol, that hardware has a compatibility issue anyhow.

[AndyH]

Thanks Mike, that gives me some things to try - will do so after work.

Joy1 is in ZP but should be in a safe spot. I can move to regular RAM to test also.

I know Backbit has an option (by default) to point to it's own routines and I believe I can switch back to the kernal which I'll look into.

I should also add that I currently have my own VBL interrupt running that bypasses the regular keyboard scan. Hopefully I have not introduced a blunder here:

Code: Select all

; my closing IRQ to avoid keyboard scan
		pla
		tay
		pla
		tax
		pla
		jmp $eb15

[Mike]

Joy1 is in ZP but should be in a safe spot.

That's what I also thought sometimes ...

I can move to regular RAM to test also.

... better safe than sorry.

I know Backbit has an option (by default) to point to it's own routines and I believe I can switch back to the kernal which I'll look into.

That actually doesn't tell me much. Of course I'd suppose Backbit wedges in own KERNAL routines, but the question remains whether they actually need to fiddle around with DDRA of VIA #1 - IF that's actually the issue!

I should also add that I currently have my own VBL interrupt running that bypasses the regular keyboard scan. Hopefully I have not introduced a blunder here:

Code: Select all

; my closing IRQ to avoid keyboard scan
		pla
		tay
		pla
		tax
		pla
		jmp $eb15

The KERNAL ISR already has saved A, X, Y on stack before your own routine at ($0314) is called (see $FF72 as vectored to by the hardware IRQ vector in ROM at $FFFE!), so you don't need to stack them on your own. If you remove that supposed redundancy from your IRQ wedge, you can also omit the PLA/TAY/PLA/TAX/PLA incantation from your IRQ exit, as $EB15 already does this on its own, with the already stacked register contents.

[AndyH]

I could not find a solution programatically. However, I found another behaviour. CTRL+1 or 7 to change the cursor colour to black or blue did not work with the Tapino plugged in either. Other keypresses worked, and 1 and 7 worked on their own. Play an image on the Tapino and these keys worked, allowing Black and Blue to be set.

I've tested this on two other Vic's - another one with a 2 prong power supply does the same but a newer Vic with a C64 style power input works fine and does not exhibit the problem at all.

I guess my Tapino has some incompatibility with my two older Vic's ... whether this is common to all Tapino's or just mine I could not say.