Probable bug in joydrv_joy.asm

Developers
2010-04-29
2013-05-16
  • Robert Gault

    Robert Gault - 2010-04-29

    In patching the Sierra games for Drivewire, the joystick button action was found not to work in Black Cauldron. At first this was believed to be the result of changes to mnln, a Sierra module. However, replacing our mnln with the original one does not correct the problem. Using the original game with our mnln, does not display the problem. Clearly something is wrong with the way the NitrOS-9 joydrv_joy.asm is handling button sampling.
    The game reads the joysticks with the SS.JOY setstt call; regB=$13. I think that is handled by the above driver. The code in the following section does not look right.
    SSJoyBtn ldx   #PIA0Base  PIA#1 base address
             clrb 
             comb 
             stb   $02,x      clear PIA#1 key strobe lines
             ldb   ,x         read data lines
             comb             only buttons and comparator valid
             andb  #$0F       only buttons; 0=off 1=on
             rts  

    SSMsBtn  bsr   SSJoyBtn
             tfr   b,a
             anda  #%11111010 regA=left buttons; should be $0A not $FA
             pshs  a          save left button values
             andb  #$05       regB=right buttons
             orb   $01,u      ORB with previous state??
             leax  <L0187,pcr point to sequential switch table possibilities
             lda   b,x
             anda  #%00001010 keep only left values
             sta   $01,u      save for change test
             ldb   b,x        repeat
             andb  #%10000101 keep flag and right values
             bpl   L0184
             ldb   ,u         previous min/max state
    L0184    orb   ,s+        ORB with current left values and pop stack
             rts  
    L0187    fcb   $00,$03,$00,$03,$08,$06,$02,$06,$80,$02,$00,$02,$08,$06,$0a,$06

    The LevelII owner's manual has a typo for the exit conditions. I think regB should return 0-3 for the type of button(s) pressed and regA indicates if any were pressed. That does not seem to be what the above code does.

    One other point. Joydrv_joy may also process the SS.Mouse setstt which is much more complex. Perhaps the above code looks odd because it also handles the SS.Mouse call. Whatever the case, something is likely wrong with joydrv_joy.

     
  • Gene Heskett

    Gene Heskett - 2010-04-29

    Robert, I am afraid I know very little about that code, all I worked on was the joydrv_6551 stuff.

    However, if its any consolation, I too was not terribly impressed with the button treatment in the SS.Mouse gttstt that exists in joydrv_6551.asm.  Something seems to have gotten miss placed somewhere along the line as I can recall 15 years ago, being able to make use of all 3 buttons on my serial mouse in Icnedit.  That was however, using a set of patches to co3io, and that was deprecated long ago.  I never dissed it either, it Just Worked(TM) so I had no reason to dig into it.

    Now only one, the left one works in Icnedit.  The Mouse packet, an 8 byte array, is being properly setup according to the includes, although I did expend them somewhat to add better definitions but I don't believe that the actual code changed once I had fixed an off by one in the bit mapping of the mouses return of data about buttons so the buttons bits actually wind up where the defines say they should be.  I have verified that with that bit of dmem!dump code you suggested, watching the mouse data array in real time.

    Does the joydrv_joy even use the l51defs defsfile?  If not then ignore the following.

    You might want to compare the L51.defs in the repo with what I have here, at
    <http://gene.homelinux.net:85/gene/nitros9/>

    Whether changing out the l51.defs file and rebuilding your joydrv_joy would help I haven't a clue, but it might be worth a shot.  Or maybe you can shoot a few holes in my version.
    Cheers, Robert.  Gene

     
  • Robert Gault

    Robert Gault - 2010-04-29

    After studying the code, I've found two modules handle joystick buttons, vtio.asm and joydr_joy.asm. One or both don't match what is expected from the Sierra game. Neither seems to exactly match the tech section of the manual for SS.JOY which is called by the game.

     
  • Robert Gault

    Robert Gault - 2010-05-01

    This is getting stranger and stranger. I ran a test of the SS.JOY getstt call in NitrOS-9 3.2.9 using a Basic09 program which repeatedly called the function. It worked perfectly.
    The Sierra module mnln uses only SS.JOY to read the joystick and buttons so why is this not working in the current NitrOS-9 build but does work with the older OS-9 of the game?

     
  • Gene Heskett

    Gene Heskett - 2010-05-01

    Humm, do either of those, vtio or joydrv_joy use L51 defs?  Maybe my fixing the off by one in the mouse returns did something odd that in turn needs fixed in those drivers?

    This of course isn't a SWAG, just a WAG.  I wish I had more to contribute but that is about it as I am not familiar with either of those drivers.

     
  • Robert Gault

    Robert Gault - 2010-05-01

    Gene, I don't see how anything you did with L51 could be involved. That def is not used by joydrv_joy or vtio.

     
  • Gene Heskett

    Gene Heskett - 2010-05-01

    Well, that more or less gets me off the hook I guess.

    Have you used the idea that you gave me to trace the packet data in real time (or as real as the coco can get)?  That might tell you which of the translations is at fault.  The 8 byte packet from the IRQ service routine, or the SS.joy which is I believe the translator from the 8 byte packet the pointer returns, to the 32 byte packet that SS.joy returns to gshell/multivue etc.  There be dragons in that code I believe.  Perhaps that dmem|dump thing you taught me might be modified to watch that 32 byte packet if we could determine its address in memory.  OTOH, your b09 routine could also do that?

    Cheers Robert.

     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks