No Joystick detection durcing system VBI?

[bugbiter]

Hi, I have a problem with my Picture viewer.

 

I have set up a custom deferred VBI for my colour cycle headline. In the menu, the joystick works fine, the system VBI including copying port A values into stick0 is working and my custom deferred vbi routine is done as well after that.

 

During picture display kernel the joystick isnt working. Tracing the program I see that the system VBI execution is very short and backs out before the OS joystick and my custom routine is reached.

 

CRITIC seems not to be the issue. I've never heard about other circumstances that affect VBI execution.

 

This is the short vbi dump: The OS routine checks something in the stack and then quits. What is that? How can I get it to do the full system routine so that my joystick is working again?

 

(41541:248, 35) A=00 X=00 Y=00 S=EB P=77 ( V IZC) C022: 8A TXA
(41541:248, 38) A=00 X=00 Y=00 S=EB P=77 ( V IZC) C023: 48 PHA
(41541:248, 42) A=00 X=00 Y=00 S=EA P=77 ( V IZC) C024: 98 TYA
(41541:248, 44) A=00 X=00 Y=00 S=EA P=77 ( V IZC) C025: 48 PHA
(41541:248, 48) A=00 X=00 Y=00 S=E9 P=77 ( V IZC) C026: 8D 0F D4 STA NMIRES [$D40F] = $5F
(41541:248, 54) A=00 X=00 Y=00 S=E9 P=77 ( V IZC) C029: 6C 22 02 JMP (VVBLKI) [$C0E2] = $E6
(41541:248, 60) A=00 X=00 Y=00 S=E9 P=77 ( V IZC) C0E2: E6 14 INC RTCLOK+2 [$14] = $4E
(41541:248, 65) A=00 X=00 Y=00 S=E9 P=75 ( V I C) C0E4: D0 08 BNE $C0EE
(41541:248, 68) A=00 X=00 Y=00 S=E9 P=75 ( V I C) C0EE: A9 FE LDA #$FE
(41541:248, 70) A=FE X=00 Y=00 S=E9 P=F5 (NV I C) C0F0: A2 00 LDX #$00
(41541:248, 72) A=FE X=00 Y=00 S=E9 P=77 ( V IZC) C0F2: A4 4D LDY ATRACT [$4D] = $00
(41541:248, 75) A=FE X=00 Y=00 S=E9 P=77 ( V IZC) C0F4: 10 06 BPL $C0FC
(41541:248, 78) A=FE X=00 Y=00 S=E9 P=77 ( V IZC) C0FC: 85 4E STA DRKMSK [$4E] = $FE
(41541:248, 81) A=FE X=00 Y=00 S=E9 P=77 ( V IZC) C0FE: 86 4F STX COLRSH [$4F] = $00
(41541:248, 84) A=FE X=00 Y=00 S=E9 P=77 ( V IZC) C100: AD C5 02 LDA COLOR1 [$02C5] = $0A
(41541:248, 88) A=0A X=00 Y=00 S=E9 P=75 ( V I C) C103: 45 4F EOR COLRSH [$4F] = $00
(41541:248, 91) A=0A X=00 Y=00 S=E9 P=75 ( V I C) C105: 25 4E AND DRKMSK [$4E] = $FE
(41541:248, 94) A=0A X=00 Y=00 S=E9 P=75 ( V I C) C107: 8D 17 D0 STA COLPF1 [$D017] = $0F
(41541:248, 98) A=0A X=00 Y=00 S=E9 P=75 ( V I C) C10A: A2 00 LDX #$00
(41541:248,100) A=0A X=00 Y=00 S=E9 P=77 ( V IZC) C10C: 20 55 C2 JSR $C255 [$C255] = $BC
(41541:248,106) A=0A X=00 Y=00 S=E7 P=77 ( V IZC) C255: BC 18 02 LDY CDTMV1,X [$0218] = $00
(41541:248,110) A=0A X=00 Y=00 S=E7 P=77 ( V IZC) C258: D0 08 BNE $C262
(41541:248,112) A=0A X=00 Y=00 S=E7 P=77 ( V IZC) C25A: BC 19 02 LDY CDTMV1+1,X [$0219] = $00
(41541:249, 2) A=0A X=00 Y=00 S=E7 P=77 ( V IZC) C25D: F0 10 BEQ $C26F
(41541:249, 5) A=0A X=00 Y=00 S=E7 P=77 ( V IZC) C26F: A9 FF LDA #$FF
(41541:249, 7) A=FF X=00 Y=00 S=E7 P=F5 (NV I C) C271: 60 RTS
(41541:249, 13) A=FF X=00 Y=00 S=E9 P=F5 (NV I C) C10F: D0 03 BNE $C114
(41541:249, 16) A=FF X=00 Y=00 S=E9 P=F5 (NV I C) C114: A5 42 LDA CRITIC [$42] = $00
(41541:249, 19) A=00 X=00 Y=00 S=E9 P=77 ( V IZC) C116: D0 08 BNE $C120
(41541:249, 21) A=00 X=00 Y=00 S=E9 P=77 ( V IZC) C118: BA TSX
(41541:249, 23) A=00 X=E9 Y=00 S=E9 P=F5 (NV I C) C119: BD 04 01 LDA $0104,X [$01ED] = $27
(41541:249, 28) A=27 X=E9 Y=00 S=E9 P=75 ( V I C) C11C: 29 04 AND #$04
(41541:249, 31) A=04 X=E9 Y=00 S=E9 P=75 ( V I C) C11E: F0 03 BEQ $C123 <============ HERE THE VBI BACKS OUT
(41541:249, 34) A=04 X=E9 Y=00 S=E9 P=75 ( V I C) C120: 4C 8A C2 JMP $C28A [$C28A] = $68
(41541:249, 38) A=04 X=E9 Y=00 S=E9 P=75 ( V I C) C28A: 68 PLA
(41541:249, 43) A=00 X=E9 Y=00 S=EA P=77 ( V IZC) C28B: A8 TAY
(41541:249, 46) A=00 X=E9 Y=00 S=EA P=77 ( V IZC) C28C: 68 PLA
(41541:249, 51) A=00 X=E9 Y=00 S=EB P=77 ( V IZC) C28D: AA TAX
(41541:249, 54) A=00 X=00 Y=00 S=EB P=77 ( V IZC) C28E: 68 PLA
(41541:249, 59) A=00 X=00 Y=00 S=EC P=77 ( V IZC) C28F: 40 RTI

[+JAC!]

If the VBI detects that it has just interrupted an IRQ, it behaves just as with CRITIC. This ensures highly frequent IO IRQs don't get broken.

What could be the case is that you actually ran into a BRK instruction unintentionally for example.

Edited March 26, 2015 by JAC!

[bugbiter]

I just noticed my DLI Kernel is still active in line 248 and so the Interrupt flag is still set when the VBI starts.

 

Seems I'll have to start the Kernel manually by checking for scanline #8 and not use a DLI

That way I also don't lose cycles at the start of the Display Kernel by DLI vectoring..

[Xuel]

Or you could just clear the interrupt flag in your DLI, no?

[snicklin]

You appear to be missing a PHA at the start of the dump, or has the output that you sent just commenced after a PHA?

[Rybags]

A DLI that's still running at the end of the visible display will need to return very quickly, VBlank NMI occurs early on the next scanline.

It's sort of misleading, the fact of the matter is that VBlank NMI will usually be over and done with before actual VBlank and VSync have occurred, especially on a PAL machine.

 

If you can't shorten your DLI/kernal then the next best thing is to just use an Immediate VBlank routine and do the stuff that the OS would otherwise skip.

Also, there's nothing wrong with just reading joysticks from the hardware directly. The shadow registers make joysticks easier to handle in Basic, but in assembly all you need is to And or shift the PORTA reading to suit your needs.

[phaeron]

Or you could just clear the interrupt flag in your DLI, no?

 

This is a no-no as it can cause IRQ routines to be re-entered and corrupt state. It's the reason why the OS VBI handler has the I flag check before running stage 2 with interrupts unmasked. Fixing it without skipping iterations is tricky -- one way is to use the serial output complete interrupt to queue a software interrupt.

[Rybags]

Additional to my immediate VB suggestion - check the Critic flag yourself and skip your routine if set.

Critic will usually only be set with SIO is occurring. And in the normal course of events, I flag set and not by you will usually mean a keyboard IRQ is in progress. Delaying that is no problem at all.

[Xuel]

This is a no-no as it can cause IRQ routines to be re-entered and corrupt state. It's the reason why the OS VBI handler has the I flag check before running stage 2 with interrupts unmasked. Fixing it without skipping iterations is tricky -- one way is to use the serial output complete interrupt to queue a software interrupt.

I was assuming IRQEN would be set to zero while the full screen kernel was in effect since SIO wouldn't be possible anyway. But maybe bugbiter is also relying on the OS keyboard interrupt handler in which case I guess that wouldn't work. I admit that my first inclination is always to bypass the OS so I'm not as familiar with proper methods of cooperating with it.

[MaPa]

deleted

Edited March 27, 2015 by MaPa