How Do I Driving Paddle?

[Cybearg]

As suggested by Random Terrain in this thread, I've made a new thread to ask the specific question: How do I get the driving paddle to work?

 

I know that it's been done in zombie chase and the code is something akin to this (this version was tweaked a bit by bogax:

 

const nomove = 1
const turnright = 0
const turnleft = 2

data ptbl
nomove, turnright, nomove, turnleft
turnleft, nomove, turnright, nomove
turnright, nomove, turnleft, nomove
nomove, turnleft, nomove, turnright
end

temp1 = SWCHA / 4 & $C
temp1 = temp1 | last
last = temp1 / 4
if ptbl[temp1] & nomove then goto no_move
if ptbl[temp1] & turnleft then goto left else goto right

 

However, when I try this, it just results in a constant turn one direction or the other. Note: that is using Stella with the Driving controller selected.

 

Could someone perhaps give a very simple working example or maybe point out what's wrong, if anything?

[Omegamatrix]

The driving controller has a few quirks about it. If you spin it really fast you start missing states as it changes it state faster then you are sampling. At slower speeds this seems fine, but you hit a secondary effect where if you turn to slow you continually stop and start. I was thinking about driving controllers today and in particular about your game, Cybearg and I got a routine working (in assembly). I hacked it into a quick and dirty reverse engineered source. It doesn't need to go where I put it, I just did it this way to get it in there. In the end the idea is BB doesn't know or care what controller is plugged in. It just checks left or right and moves the rings as it normally does. The process lies underneath and instead of using joyp0 or whatever it is called, you do just do bit tests on the variable I named "tempJoy".

 

 

hbJoyDrive.zip

 

The "old" rom is a really old rom that I got running the merged JoyDrive code on this afternoon. It works. The "new" rom I just did from the newest rom I could find, but I haven't tested it on real hardware. It is essentially the same code places in the new rom, and I expect it to work.

 

 

I originally wrote a routine, and then went looking for betters ones until I found one on the Stella Mailing List by TJ. I couldn't get his super optimized code to work, so I started with his mid optimized one. EOR'ing instead of using a second table was a clever idea.

 

I wrote a routine that does a little bit more then check if the controller is moving left or right. I made it continually check for is a driving controller or joystick is being used in a single port (in this case the left side). The driving control is not connected to pins 4 (right) and pin 3 (left) as can be seen here in the schematic. When the joystick is pressed in the right or left direction it grounds these pins. So the first check I do is to see if either pin is grounded. If it is I presume a joystick is plugged in.

 

The driving controller is connected to the up (pin 1) and down (pin 2) pins. To check for the driving controller you can either check for the graycode pattern to appear, or what I did was look for both up and down to be pressed at the same time (this is simple and saves bytes). This condition doesn't happen too much for the joystick as you need to press left and right on the joystick to scroll the ring. However, when you scroll the knob even a little bit you will soon hit '00'.

 

The main driving force between having the port handle both joystick and driving controller is that the player can switch the controller on the fly and not have to do anything. The secondary reason is I know at least for myself I never read the manual, so yes, I am guilty of being lazy like that. I'd just rather have something work without having to fiddle with thinking which switch to press.

 

Finally, here are some Random Thoughts:

- I tested this (well the rom marked old) on real hardware and it worked great! The response was spot on.

- In emulation this might be a bit of a nightmare because you have to tell Stella that a driving controller is hooked up in which port. I don't know how it will react if you tell it that there is a driving controller plugged in when there really is a joystick. Using the difficulty switch won't help here, because this has to be updated in the game properties. The simple thing to do is use both ports, have one for the joystick and one for the driving controller. If you have only one Stelladapter then I'm quessing you'd have to tell the game if you were using the left or right port still. I don't think there will be any easy way about it in emulation, but I'm waiting to here what Stephena has to say. I do own a Stelladaptor, but I don't have it with me.

 

 

Anyhow on real hardware no issues. It just works as is.

[Omegamatrix]

Before I forget, if you are using the DC with Stella, don't forget to press the tab button and go into "game properties". Select controller and from the dropdown use "driving" for the driving controller. You might have to restart Stella after this IIRC.

 

 

 

 

Also relevant parts of the code (this is not contiguous):

 

 

START:
;after clear routine,
;prep previous postion on driving controller at power on
 LDA  SWCHA
 AND  #UP_DOWN_MASK
 LSR
 LSR
 LSR
 LSR
 STA  previousPos
;=======================================
;when testing left and right use tempJoy
LF687:
;  bit  SWCHA  ; 4  replacing SWCHA
 BIT  tempJoy
 NOP
LF698:
;  bit  SWCHA  ; 4
 BIT  tempJoy
 NOP
;=======================================

;code that updates tempJoy:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Read Driving Controller
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
RIGHT_BIT  = $80
LEFT_BIT  = $40
DOWN_BIT  = $20
UP_BIT  = $10
LEFT_RIGHT_MASK  = $C0
UP_DOWN_MASK  = $30
tempJoy  = $A9
previousPos  = $AA
joyCounter  = $AB
joyFlag  = $AC
TEST_DRIVE:
 sta  WSYNC
;---------------------------------------
 lax  SWCHA
 and  #LEFT_RIGHT_MASK
 cmp  #LEFT_RIGHT_MASK
 bne  .decisiveControl  ; left or right pressed
 txa  ; SWCHB
 and  #UP_DOWN_MASK
 bne  .finishContCheck  ; branch if up, down, or both (up and down) not pressed...
 ; Don't branch when both up and down are pressed,
 ; unlikely for joystick, but happens all the time for DC.
.decisiveControl:
 lda  #0
 ror
 sta  joyFlag  ; $80 = DC, $00 = Joystick
.finishContCheck:
 txa  ; SWCHB
 bit  joyFlag
 sta  WSYNC
;---------------------------------------
 bpl  .finishMove  ; joystick being used
 and  #UP_DOWN_MASK
 lsr
 lsr
 lsr
 lsr
 ldy  previousPos
 sta  previousPos
 eor  NextLeftTab,Y
 beq  .left
 eor  #$03
 beq  .right
 cpy  previousPos
 bne  .continueLastDirection
 inc  joyCounter
 lda  joyCounter
 and  #$0F
 bne  .continueLastDirection
 sta  joyCounter
 lda  #(LEFT_BIT | RIGHT_BIT)
 .byte $0C ; NOP, skip 2 bytes
.left:
 lda  #~LEFT_BIT
 .byte $0C ; NOP, skip 2 bytes
.right:
 lda  #~RIGHT_BIT
.finishMove:
 sta  tempJoy
.continueLastDirection:
 jmp  FINISH_VSYNC
NextLeftTab:
 .byte 1,3,0,2

 

Edit: having a hard time here with the forum eating my code, I edited a few times now!

Edited February 19, 2013 by Omegamatrix

[Cybearg]

[Omegamatrix]

I have no idea what that is, or if he is happy, or if he just saw a horror show.

[Cybearg]

I have no idea what that is, or if he is happy, or if he just saw a horror show.

It is a gasp of absolute joy, as the sparkles indicate.

 

As always, thanks so much! Now, as much as you integrated everything so nicely in the assembly, I'd love it if we could get it working as an include or somesuch. I've sent you a PM to discuss the details.

[Omegamatrix]

I won't have much time for playtesting, unfortunately. I got more mid-terms coming up after this week, and after that it is the mad sprint towards the end of the semester. I did enjoy working on this though, and I learned a few things about how BB is structured so all in all it was a win-win for everyone. I just hope this last little bit goes smoothly. I also hoped you snagged yourself a driving control to try this on real hardware. It was a lot of fun with it!

[Cybearg]

Yep, I've got a driving controller. I'm just waiting for a Harmony to arrive.