RE: Boot failures w 3.2.8 & serial joydrv's

Developers
2008-06-04
2013-05-16
1 2 > >> (Page 1 of 2)
  • Gene Heskett
    Gene Heskett
    2008-06-04

    So I built a joydrv_6551L.sb that saves the slot select, put it on the slot 0, does its thing and then restores the original slot # on exit.  This read, according the <D.BtBug as 3 on the first boot attempt, but it still seems to do a puls pc,cc into never never land, except that about 10 minutes later, while I'm studying the listing, up popped a green screen with part of sysgo's output on it, but it then failed at the date t display.

    On several reboots, including a powerdown reset for about 30 seconds, it is now displaying a '/' in place of the 3.  To display a '/' there, with this code:
      lda   #'0
      adda  SlotSave, pcr
      jsr   <D.BtBug
    it has to be reading $FF from SlotSave,pcr, which was originally written:

    SlotSlct  fcb  MPISlot
    SlotSave  fcb  MPISlot scratchpad space
    [...]
      lda  >MPI.Slct which assembles as $B6FF7F 
      sta  SlotSave,pcr

    I just ran through the assembled defs 3 times without finding a location, hopefully in DP, that records the current MPI.Slot!  From that I have to assume that $FF7F is both readable and writable.

    So how do we keep track of it?

    --
    Cheers, Gene

     
    • Gene Heskett
      Gene Heskett
      2008-06-07

      Here is the email:
      ------------
      Hi Guys;

      >The size limit applies to 6809 boot files not 6309. It could well be a
      >'new' bug but Boisy reminded me this was discussed previously in the
      >defunct NitrOS-9 newsgroup/mailing list.
      >I don't recall this existing in stock OS-9 Level2 or the original
      >NitrOS-9 (Gale Force) versions. There were massive changes made to
      >modules when Boisy decided there should be as much common source code as
      >possible so Level1, Level2, Level3, and 6809/6309 could be generated
      >from the same source code. This bug could easily have been introduced in
      >this period.
      >
      >You can make finding the source of the memory limit bug your next
      >project after you solve your joystick problem. :)

      I think it also applies to 6309 machines as well.  I put my bootlist on a diet
      and got it down to a few bytes over 32k, and with a few caveats, it is working.

      Sorta.

      1. I have a scope on the mouses output, and I can see the blinking in the video
      when I move the mouse, which tells me the IRQ line is being pulled down in
      response to the mouse data coming in, and that the IRQ is being serviced
      because the blinking is for as long as I'm moving the mouse, or pressing and
      releasing a button on it.  Before, it was never being initialized enough to
      register and enable the chip to issue IRQ's, so this is progress.  This is with
      joydrv_6551L.sb set for a mouse address of $FF6C.  Now, irqs says its there,
      and at $FF6D.

      2. On a reboot, back to this same disk, the boot will stall at about joydrv
      init, and wait either for the rapture, or for me to move the mouse a fraction
      of an inch.  This says to me that the IRQ routine isn't being installed before
      the chipset is properly init'ed and flushed of any pending data.  Should we not
      re-arrange that order somehow, but first disabling the chips ability to
      generate an IRQ, then flush it, then install the IRQSvs, and then enable the
      chip?

      3. Multivue still cannot see the mouse, so I'm stuck with a useless multivue
      screen I can't get rid of till a reboot is done.  I looked at /dd/sys/env.file,
      but that doesn't tell gshell where the mouse is & 15 years ago ISTR there was a
      place/file that did tell gshell where it was.

      Now, from reading the multivue book on mouse use, it reads like it shouldn't
      really care what PTRSID is set to in the env.file as long as the joydrv
      SS.Mouse call works.  So I'm confused.  Its currently, and was 15 years ago
      when this all worked but before all this 'modularization', set to PTRSID=1. 
      What, if anything should it be set to now with this new joydrv thing?  Back
      then I *think* it was part of cc3io or??

      --------------------

      I also found what I'd sure call a bug in os9gen, it is treating an empty line in
      bootlists/genes.bl as the eof, stopping the generation of the os9boot file at
      that point, and w/o any reported error.  I don't know when that crept into the
      file, but I expect that has been part of my trouble every since the high window
      descriptors were all found to be copies of each other.  That really ought to be
      fixed at some point so it doesn't bail out till it gets a real eof from the
      filesystem.

      --
      Cheers, Gene
      "There are four boxes to be used in defense of liberty:
      soap, ballot, jury, and ammo. Please use in that order."
      -Ed Howdershelt (Author)
      --------------
      11:44 Saturday June 7th, 2008

       
      • Boisy Pitre
        Boisy Pitre
        2008-06-07

        I remember years ago when using OS-9 Level II that I had the same issue with joydrv for the 6551.  Until I moved the mouse, OS-9 wouldn't fully come up.    I don't have this setup any longer, so I cannot assist in debugging.

        Some investigation will be required to understand why moving the mouse is necessary.  I wonder where in the source that things could be "locked up" until the mouse moves.

        As for os9gen, the behavior you described is not a bug.  os9gen has always worked this way.

         
      • Robert Gault
        Robert Gault
        2008-06-08

        Gene, you have a point about joydrv_6551L.asm. Currently the init routine installs an IRQ before initializing the PIAs. That alone does not make sense. The order in init should be

        suspend all interrupts
        initialize PIAs, GIME, and MPI slot
        send command (if there is one) to the 6551 to halt/reset
        clear all flags
        engage interrupts

        It would be easy enough to relocate the OS9 F$IRQ to the end of the init routine. There is no equivalent to a 6551 Reset command in the code but if there is a Reset, it could be added.

        Want to rewrite init and test it?

         
        • Robert Gault
          Robert Gault
          2008-06-08

          The info in the RS-232 manual has a table indicating a write to $FF69 is a forced soft reset. Specifically, "A res* from the bus will clear all registers in the 6551, while a soft reset will only disable interrupts and transmitter, turn off the echo mode, and clear the overrun flag." Ambiguously, the manual also states, "The soft reset opertion clears the 6551 internal registers but does not cause any data transfer."
          So, does a soft reset clear all registers or only a hardware res* ?

          In either case, joydrv_6551L.asm does send a soft reset command to the 6551 in the init routine.
          orcc  #IntMasks  disable IRQs while setting up hardware
          sta   PRstReg,x  reset 6551
          PRstReg is defined in l51.defs as $ff69 so the code is clearing the 6551 as best as is possible. The only problem, in my opinion, is the orcc comes too late in the routine, after the OS9 F$IRQ call.

           
    • Gene Heskett
      Gene Heskett
      2008-06-08

      Hi Guys;

      suspend all interrupts
      initialize PIAs, GIME, and MPI slot
      send command (if there is one) to the 6551 to halt/reset
      clear all flags
      engage interrupts

      That makes sense to me. At present, I am getting an "IRQ Storm" as soon as it has been init'ed.  Also the scope says it is outputting a packet, maybe more, of data when the acia is enabled, which in turn powers up the mouse since it is powered from the acia lines.

      As for this:
      "PRstReg is defined in l51.defs as $ff69", note that is PRstReg,x and PRstReg is actually an offset of 1 and in this code x=$ff6C (I hope anyway) so that write would be correctly made to $FF6D.

      However, even if I do move the mouse in time and it boots fully, multivue still can't find it.  But I suspect that is a different beast entirely. :-)  It does show up in the irqs report then, unlike the boot it is booted to now, where only the /t2 irq is showing.  But that boot with a mouse will not format a floppy.  This one will.

      {t2|08}/DD/NITROS9/6309L2/MODULES/SCF:irqs

      Polling Table at: 5DFB
      Device Table at: 5C00

      Device    Driver  IRQ   Flip
      Port Mem   Name  Vector  &Mask Pty
      ---- ----  ------------  ----- ---
      FF69 4C00  sc6551  E392  00 88  0A

      Thanks for any more insight you can toss my way, I'm not exactly a 6551 guru.  OTOH, I have found some nice info on this drain bamaged chip on the net, complete with workarounds for the ugliest bug related to CTS dropping in mid char.

      One last thought, I've set the watch bit on this forum, which means I should be getting an email alert when a new post is made.  I am not getting these, and someone please check why?

      --
      Cheers, Gene
      "There are four boxes to be used in defense of liberty:
      soap, ballot, jury, and ammo. Please use in that order."
      -Ed Howdershelt (Author)
      In matters of principle, stand like a rock;
      in matters of taste, swim with the current.
                      -- Thomas Jefferson

       
    • Boisy Pitre
      Boisy Pitre
      2008-06-08

      Gene,

      Please let us know what the outcome is when you rearrange the code.  The ideal scenario is to not have NitrOS-9 wait for the mouse to move.

      I'm anxious to see you results.

      Boisy

       
    • Gene Heskett
      Gene Heskett
      2008-06-08

      Hi again Guys;

      I've re-written it to do things in the order suggested by Robert.  The reboot still hangs at i2xoXXX where X is a char I put in to indicate the execution of each of the 3 subroutines I made out of the individual pieces of code.  I also commented out a boatload of code that was never called in the original version 6.

      Now I push cc and disable the interrupts
      Init the PIA's. GIME and MPI.slot (subroutine 'P')
      reset the acia
      clear the 8 byte wide buffer U points at
      Init some of that buffer to starter values as before, but I'm not sure they are correct
      read the chip to clear pending data as originally done, take exit if it won't clear on 2nd read as before
      Install the svs routine with I$IRQ as before
      enable the interrupts by pulling cc.

      Now it will boot after outputting the tallies I put in the 3 subroutines I made of the above.
      With these caveats of course:
      at i2xoXXX, I have to move the mouse for it to proceed, but it then booted normally, initing all 4 screens I normally used and the shell on /t2.

      However, the keyboard seems to be blocked until the mouse is moved, even just to service the clear key to switch screens!  After quite a bit of that it seemed to get well and I could run utils from one of the screens.  Multivue still can't find the mouse however, the pointer is stuck in the upper left corner.

      The shell on /t2 I'm looking at here seems to be functional, a dir -e works, and an irqs shows:
      {t2|08}/DD:irqs

      Polling Table at: 6AFB
      Device Table at: 6900

      Device    Driver  IRQ   Flip
      Port Mem   Name  Vector  &Mask Pty
      ---- ----  ------------  ----- ---
      FF69 5300  sc6551  E3B7  00 88  0A
      FF6D 10EC  sc6551  B7E7  00 0F  01

      Now, I'm about burned out for the day.  I would like to put this code up so others can play & offer insight, or finish the fixing maybe, but my asking for instructions on how to use cvs to update a single, or maybe 2 or 3 files (joydrv_6551L.asm, dcheck.asm, and vtio.asm) in the repo have been ignored.  I think now that there may be bogus control data being written either to PIA(0/1?), or to the 6551 itself.

      I also added a counter output to the normal exit of the IRQSvs routine so I could see the byte count building up in buffer,u, but that is covered by the green screen in milliseconds after I move the mouse to generate that data.  My persistence of vision isn't THAT good. :)

      --
      Cheers, Gene
      "There are four boxes to be used in defense of liberty:
      soap, ballot, jury, and ammo. Please use in that order."
      -Ed Howdershelt (Author)

       
      • Boisy Pitre
        Boisy Pitre
        2008-06-08

        Gene,

        Good progress made.  If you want to commit your changes, change to the directory where the files are and type:

        cvs commit

        You should be able to commit them that way.

        Boisy

         
        • Gene Heskett
          Gene Heskett
          2008-06-09

          CVS: Modified Files:
          CVS:    joydrv_6551L.asm joydrv_6552L.asm scf.asm snddrv_cc3.asm
          CVS:    vtio.asm kernel/krnp2.asm

          I think there are no substantive changes in scf.asm or krnp2.asm.  Some tally outputs in the others added to trace things, and those can go as easily as they were added.  joydrv_651L.asm is the biggie.

          Does it ever tell me when its done?

          I think I might have a handle on the irq lockup/storm, I believe the control register is getting set so an IRQ is generated for a TBE condition, which would always be true.  I've downloaded the WDC version of the docs, 34 pages of dead tree now, and will see if I can get that sorted one way or the other.

          But I am still not getting emails from srcforge when you all post replies.  I did when I first signed up, but no more, and there is a checkmark beside the watch this on the forum's top page.

          I did a forced exit, used a ! to reuse that log the next time, and then got informed I need write access to do that, bummer.  So I suspect the repo is not touched.

          --
          Cheers, Gene

           
    • Boisy Pitre
      Boisy Pitre
      2008-06-09

      Robert went through the exercise recently of setting up his copy of the repository.  You have CVS access to the project so you should be able to make commits IF you have checked out the repository as a user and not anonymously.

      As far as monitoring the forum, I have this forum monitored and I get emails when you or anyone else posts here.  I would check to see if your account has a current email on file.

      Boisy

       
    • Gene Heskett
      Gene Heskett
      2008-06-09

      I'll do that.  In the meantime this joydrv_6551L.asm seems to be set for some 5 byte packet protocol, and the logitek is a 3+1 protocol, the +1 (4th byte) being only for a middle button event.  So that part of it is going to need a major rewrite as its expecting 5 bytes per packet.

      In the meantime, the protocol says that on cycleing RTS, it will spit out the first of 2 ID bytes about 14ms later, followed by a second 'variation' byte about 63 milliseconds after that.  I see 2, separated by about those times, bytes being sent by the mouse after the hardware reset and re-init I'm doing in this code ATM.
      I've written it so that it should spit out those 2 bytes, they are supposed to be printable ascii bytes, to the screen during the init, then output a "S" to indicate its frozen there so I can read what it says between the i2xoPG and the S, but all I'm getting is i2xoPGS
      Here is that code snippet from the listing:

      00202    0086 AE8DFF81   ClrACIA        ldx       M$Mem,pcr           get base h
      00203    008A 4F                        clra
      00204    008B 5F                        clrb
      00205    008C ED02                      std       CmdReg,x            do full hd
      00206                    * loads $0918, $09 to CmdReg=tx irq dis, no par, tx low
      00207                    * $18 to CtrlReg= 1200 baud 1 stop
      00208    008E CC0918                    ldd       #(TIC.RTS!Cmd.DTR)*256+(DB.8!C
      00209    0091 ED02                      std       CmdReg,x            set comman
      00210    0093 3420                      pshs      y
      00211    0095 108E0000                  ldy       #$0000              long delay
      00212    0099 313F       NxtByte        leay      -1,y                start cntr
      00213    009B 2712                      beq       NxtBExit            was InitEr
      00214    009D A601                      lda       StatReg,x           *Rx data,
      00215                    * this doesn't check TBE or IRQ
      00216    009F A48DFF82                  anda      Pkt.Mask,pcr        IRQ bits s
      00217    00A3 27F4                      beq       NxtByte             repeat 655
      00218    00A5 9408                      anda      Stat.RxF            got byte?
      00219    00A7 27F0                      beq       NxtByte             no, try ag
      00220                    * got a data byte, show it
      00221    00A9 A684                      lda       DataReg,x           get ID byt
      00222    00AB 9D5E                      jsr       <D.BtBug            what was i
      00223    00AD 20EA                      bra       NxtByte             there may
      00224                    * temp stopper
      00225    00AF 3520       NxtBExit       puls      y                   fix stack
      00226                    * show we're stuck here
      00227    00B1 8653                      lda       #'S
      00228    00B3 9D5E                      jsr       <D.BtBug
      00229    00B5 20FE       letmesee       bra       letmesee
      00230    00B7 39                        rts

      If it was an M$ 3 button mouse, I should be seeing "i2xoPG'M3'S" there, so I'd assume for a logitek, it might be something like "i2xoPG'L3'S".  But all I'm getting is "i2xoPGS", and the mouse is sending the 2 bytes of data, I can see it on the scope I have hooked up as it goes by.  Obviously there is something wrong with my conditional branching above, but I can't see it.

      One step at a time here, before I go charging off in all directions at once.

      PktMask=$0F, and Stat.RxF=$08, correct according to the docs from WDC, who is making a cmos version of this chip.  Nice docs too.

      --
      Cheers, Gene
      "There are four boxes to be used in defense of liberty:
      soap, ballot, jury, and ammo. Please use in that order."
      -Ed Howdershelt (Author)
      The curse of the Irish is not that they don't know the words to a song --
      it's that they know them *___all*.
                      -- Susan Dooley

       
      • Robert Gault
        Robert Gault
        2008-06-10

        Gene,
        It's hard to tell without seeing your complete code for the init routine but the snipit posted seems to be missing something. When you reset the 6551 you not only should read the status register but should also write to it. Are you writing to Status?
                 sta   PRstReg,x  reset 6551
        L51.defs defines PRstReg as StatReg
        StatReg is defined as port+1
        Port is defined in systype but the code for init gets that with
                 ldx   M$Mem,pcr  get base hardware address again

         
    • Boisy Pitre
      Boisy Pitre
      2008-06-09

      Gene,

      I've managed to pull out a box of 9 pin mice that I have and want to set up my RS-232 pak (actually a Ken-Ton dual RS-232 pak) to duplicate what you are seeing.

      I have a 25 to 9 pin adapter plugged into the Ken-Ton's 25 pin connector, and the mouse is plugged into the 9 pin end of that adapter.  I am not getting any response on the mouse, nor do I see the lock-up problem.  I'm using joydrv_6551L as well.  Are there any hardware hacks (i.e. line manipulations) that need to be done for the mouse to talk to the serial port?

      Boisy

       
    • Boisy Pitre
      Boisy Pitre
      2008-06-09

      Gene,

      Disregard the previous post.  I found Bruce Isted's original documents on the serial mouse, and modified my Ken-Ton pak to divert pin 16 of the 6551s to ground as per his instructions.  I am now using joydrv_6551L with a Logitech mouse and am seeing similar behavior.  The mouse must be moved in order for the boot to proceed. 

      Boisy

       
    • Boisy Pitre
      Boisy Pitre
      2008-06-10

      It has been YEARS since I set up a system with these serial mice, so it took me a while to re-acclimate myself to this setup and remember the issues surrounding using these serial mice.

      As I indicated in an earlier post, I modified my Ken-Ton Dual Serial Pak to tie pin 16 (/DCD) of both 6551s to ground.  In my pile of mice, I found two mice that worked: one with the joydrv_6551L driver and the other with the joydrv_6551M driver.  Both appear to exhibit the same lockup behavior at bootup.

      In the interest of taking one thing at a time, I'll focus on joydrv_6551L.  One issue that came up is the MPI slot select, which is set to $00 in my joydrv_6551L.  I noticed in the Init routine that a value of $80 or higher would cause a bmi to branch around the write to $FF7F.  Changing the $00 to $FF got around the write to $FF7F, but with that change, the mouse quit responding.

      Then I realized that without the $FF7F write, the IRQ from slot 1 wasn't making it to the 6551.  My MPI does not have the *CART line strapped!

      This is the whole reason that Tandy supplied that poor ModPak driver for its 300 baud Modem Pak.  That driver latched on the 60Hz VIRQ and check the hardware for a ready character.  Imagine polling the serial hardware 60 times per second... not an ideal solution for high speed serial communications.

      There's no doubt that a *CART strapped MPI is a necessity to use serial mice.

      With the mouse working, I ran Multi-Vue (the version in the repository) and I was able to move the mouse around on the screen, so it IS working.

      Robert, I looked at your message regarding OS9 F$IRQ coming before the ORCC.  I do not see that as being an issue.  Typically, before tickling register that might cause an interrupt (even if interrupts are masked), it is a good practice to insure that an interrupt service routine is installed and prepared just in case a spurious interrupt may fire.  So I would recommend NOT rearranging the order of the Init routine.

      At this point, I don't have an idea as to why the boot process is stalling until a mouse move.  I'll have to think about it.

      I also suspect that some of the mice I have in my collection are putting out a packet that is different than what these modules are programmed for.  That should be investigated as well.

       
      • Robert Gault
        Robert Gault
        2008-06-10

        Regards OS9 F$IRQ, what I had in mind was preventing system response to spurious interrupts. That's what the orcc #$50 would do. With the interrupt installed before the PIA, GIME, MPI and 6551 are initialized, there's no telling what the system would do with a spurious interrupt.

        Since we now have data that suggests the mouse itself is not being correctly initialized even though the system and 6551 are, perhaps the RTS line is not being help low for a long enough period of time.
        Gene, the data you referenced, "The mouse driver can recognize a mouse by dropping RTS to low and raising it again. About 14 ms later the mouse will send 0x4D ('M') on the data line. After a further 63 ms, a Microsoft-compatible 3-button mouse will send 0x33 ('3')." and the fact that you have problems seeing the full mouse response, suggests a timing problem.
        Perhaps the last step in the init sequence should be to re-toggle the RTS line with a long low period?

         
    • Gene Heskett
      Gene Heskett
      2008-06-10

      sta PRstReg,x reset 6551  That is, according to the docs I have, depends on the contents of regs A.
      With d2 zeroed, it is a program reset, with d4 set, is also a full hardware reset.

      What I'm doing is a full hardware reset by writing all zeros to both Command and Control registers, the n reloading them to the proper 1200 baud 8n1 configuration.

      By doing what I'm doing, I have to flush 3 bytes from it at the reset, a '_M3'  The M3 is supposed to be an indicator of the M$ 3 button protocol, but this obviously differs because a press or release of the middle button adds a 4 data byte to the packet, where the M$ protocol says it sends a 3 byte null packet for a middle button push.

      The M$ spec says the 'M' byte is 14 milliseconds after the mouse is powered up, and if its a 3 button mouse, it will send an additional '3' 63 milliseconds after the M.  But my first received char from the acia is an underscore, $7F, but I only see 2 chars go by on the scope, so I *think* the acia is catching the $7F thing because the mouse is slower to reach powerup than the acia is, so its a bit like seeing a break signal to the acia.  I'll put that lda #$10, sta PRstReg,x in it tomorrow and see if the "_" disappears.  I have doubts, but one never knows for sure till its tried.  :)

      I have an init routine just now that specifically gobbles up those 3 "_M3" bytes.  This is booting ok, and everything seems to work UNTIL I move the mouse.  Then it alternates between a dead keyboard (because its waiting on a 5 byte protocol mouse to finish sending the full 5 bytes I assume, or something along those lines) and working normally, dependent on where the mouse stopped moving.

      Some of it can be simplified though, cuz I have timeout stops in it that will trigger if the mouse is too slow coming up after the reset.  Those can go when its all working.  Then the question becomes one of how can we use that response to auto configure the driver so all we have to do is change the drivers hardware address to where ever the users acia is actually addressed. We may be able to use that 4th byte to autoconfig it the first time it gets one.  Otherwise if all 3 bytes are null data, use that as the middle button down signal.

      You can find simplified data on these protocols at <http://linux,die.net/man/4/mouse>, and at <http://www.kryslix.com/nsfaq/Q.12.html>

      Thanks, and goodnight.

      --
      Cheers, Gene
      "There are four boxes to be used in defense of liberty:
      soap, ballot, jury, and ammo. Please use in that order."
      -Ed Howdershelt (Author)
      McDonald's -- Because you're worth it.

       
      • Robert Gault
        Robert Gault
        2008-06-10

        I think I've lost the message indicating which type of mouse you are using. Since you refer to a 5 byte packet, that means you have a Mousesystems mouse? If not, why are you using a 5-byte packet?

         
      • Robert Gault
        Robert Gault
        2008-06-10

        " sta PRstReg,x reset 6551 That is, according to the docs I have, depends on the contents of regs A.
        With d2 zeroed, it is a program reset, with d4 set, is also a full hardware reset. "

        I've a pdf of the data sheet, the specs from the Tandy manual on the RS-232 pak, and a reference on Sock's web sit. All of these say a write to the Status register ignores the data sent.

        Just a clarification which probably has no bearing on your problem unless you have omitted writing to Status.

         
    • Gene Heskett
      Gene Heskett
      2008-06-10

      No, in fact I was doing that write at a point well above that code, a $10, which acc my docs, does a full hardware reset.  Testing shows I can leave the other command and control zeroing out, doesn't make any diff here.

      The acia init routine got so long doing it sequentially that I crunched it down into subroutines, getting rid of about $40 bytes or more, but ATM I am having major problems getting conditional branches to behave.

      Furinstance

      Regs.a has the character 'M' in it, returned from GetByte
      NxtByte ...
           cmpa  #'M
           bne   NxtByte

      And it loops back to NxtByte, never falling through to
      Get3Byt  bsr  GetByte

      so it will get the final 3 from the mouses pwrup sequence.

      Here is that snippet of code:

      lrACIA  ldx   M$Mem,pcr  get base hardware address again
               lda   #$10
               sta   StatReg,x reset again
               ldd   #(TIC.RTS!Cmd.DTR)*256+(DB.8!Ctl.RClk!BR.01200) [D]=command:control
               std   CmdReg,x   set command and control registers
      * do instant reads for trash collection
      * and clear status of Stat.RxF bits
      * read it 16 times!
               ldb   #$10
      flshinit lda   DataReg,x
               lda   StatReg,x
               decb
               bne   flshinit
      * that kills some of the 14 milliseconds
      * to the mouses first response byte
      * now, lets see what mouse we have
      * prints __1MM1331tg
      NxtByte  bsr   GetByte GetByte shows char, then this will too
               ifeq  DEBUG-1 debugging is killing me
               pshs  a,b,x,u,y,cc,dp
               jsr  <D.BtBug show this one
               lda   #'1 will repeat with the '_' throwaway
               jsr  <D.BtBug still in first char mode
               puls  a,b,x,u,y,cc,dp
               endc
      * this is NOT working when a=#'M ???
               cmpa  #'M some mice may not do '_' as they powerup
               bne   NxtByte skip to
               bsr   GetByte got _M, get 3
               ifeq  DEBUG-1
               pshs  a,b,x,u,y,cc,dp
               lda   #'3  show we're in 3rd byte
               jsr   <D.BtBug
               puls  a,b,x,u,y,cc,dp
               endc
               cmpa  #'3
               beq   GotByte
               comb  set error
      GotByte  rts
      *********************************
      * Entry  : x pointing at hardware
      * Mangles: a,b
      * Returns: char in A
      * Error  : cc set, err code in B
      * scans acia for a byte of data
      GetByte  pshs  y
               ldy   #$01C0 set timeout to fail
      GetByte1 leay  -1,y
               beq   GByteFai
               clra  kill some time
      Dly1     deca
               bne   Dly1
               lda   StatReg,x look for byte
               anda  Pkt.Mask,pcr
               tsta  Stat.RxF
               beq   GetByte1
      * got a byte
               lda   DataReg,x
               ifeq  DEBUG-1
               pshs  a,b,x,u,y,cc,dp
               jsr   <D.BtBug
               puls  a,b,x,u,y,cc,dp
               endc
               puls  y
               clrb in case cc set
               rts

      GByteFai puls  y
               clrb  clear carry
               ifeq  DEBUG-1
               pshs  a,b,x,u,y,cc,dp
               lda   #'t indicate timeout
               jsr   <D.BtBug
               puls  a,b,x,u,y,cc,dp
               endc

      GBytFail equ   *
               ifeq  DEBUG-1
               pshs  a,b,x,u,y,cc,dp
               lda   #'g  GByt stuff failed
               jsr   <D.BtBug
               puls  a,b,x,u,y,cc,dp
               endc
               comb  set carry
               ldb   #E$PrcAbt
               ifeq  DEBUG-1
      lettgsho bra   lettgsho
               endc
               rts

      With DEBUG equ 1 at the top of the file, I'm getting
      i2xo__1MM1331tg printed on the screen, and that final 1 tells me that

              cmpa  #'M some mice may not do '_' as they powerup
              bne   NxtByte skip to, will throw out the '_'

      is not working cuz if it was I'd get
      i2xo__1MM1333
      and the boot would coninue.  but since I'm stuck in the first loop due to the miss firing bne, it times out, adding the 'tg' from GByteFai routine and stalling so I can read the screen.

      So what's wrong with that cmpa #'M, bne?  As I understand it a cmp is a sub that throws away the answer but sets the z flag if the sub result=$00, otherwise clears the z flag, which is what beq and bne run on, right?

      I reset the triggering on my scope, and I now see a period of about 1 bytes duration of near ground voltage before it resets to the - rail as its powering up, and I assume that is where I'm getting the initial $7F, "_" from the ACIA.  Obviously other mice might behave differently.  But if its there, throw it away.

      ATM I'm going to dup that first loop as a second and drop the throwaway unless the failed conditional can be explained & made to work correctly.  That means it may then be specific to my mouse and I don't like that idea either. My mouse could have a pwrup hiccup that others don't.  And AFAIK, that is the only one I have, its been carefuly cleaned, buttons resoldered and maintained for 20 years now. :(

      We'll get to the packet size issues when this is working.

      --
      Cheers, Gene
      "There are four boxes to be used in defense of liberty:
      soap, ballot, jury, and ammo. Please use in that order."
      -Ed Howdershelt (Author)

       
      • Robert Gault
        Robert Gault
        2008-06-10

        What happens if you remove the
        cmpa #'M some mice may not do '_' as they powerup
        bne NxtByte skip to
        Does the boot continue or still fail?

        When you use the  jsr <D.BtBug  routine, the interrupts will be temporarily turned off. That might cause you to lose data from the mouse.

         
    • Gene Heskett
      Gene Heskett
      2008-06-10

      At 1200 baud, the mouse at that point can wait a considerable amount of time.

      Anyway I got that working, and turned off the jsr <D.BtBug noise and started on the IRQSvs routine.  The first thing I run into is that in l151.defs, both SyncData and SyncMask are wrong.

      These are 7 bit devices, and bit d7 is not used for anything even if it is transmitted by the mouse.

      So SyncData needs to be changed from its current binary 10000000, to 01000000, or #$40, which I've done in that code now.

      Then SyncMask is similarly wrong it should not be 11111000=$F8, but 01111000=$78 and I have changed that also.

      Stat.IRQ is correct as thats read from the acia.  PktSize s/b 4 maybe, but we'll cross that when we get there.

      Humm, fixing that made the mouse virtually kill the keyboard.  Just for grins I'm going to put a read and do nothing return there.

      That fixes about 98% of the keyboard lockouts.

      But not all, so that is not the right fix.

      Grepping thru the srcs, I note there are many more orcc #IntMask's than there are andcc #^IntMask

      There is no IRQ re-enable (there is a disable) other than pulling cc in joydrv_6551L.asm, so I'm assuming the dispatcher is supposed to do that when it returns from calling the devices IRQSvs routine?

      I take it the actual interrupt dispatcher is in krn.asm?

      I need to go warm up the grill, maybe back later.  About burned out with obtuse code for today.

      --
      Cheers, Gene
      "There are four boxes to be used in defense of liberty:
      soap, ballot, jury, and ammo. Please use in that order."
      -Ed Howdershelt (Author)
      The revolution will not be televised.

       
    • Gene Heskett
      Gene Heskett
      2008-06-12

      Robert Gault said a couple of days ago:

      I think I've lost the message indicating which type of mouse you are using. Since you refer to a 5 byte packet, that means you have a Mousesystems mouse? If not, why are you using a 5-byte packet?

      I'm not, but this driver seems to have been written with that in mind, none of the code I'm looking at make any sense at all with either an M$ 3 byte mouse, or a Logitek 3+1 mouse, almost identical mice.

      Where the two differ is in how they handle the 3rd, center button of a 3 button mouse.  M$ it says here, (http://www.kryslix.com/nsfaq/Q.12.html)uses an empty packet to send a middle button down event and any other data in the packet indicates 3rd button up, whereas the logitek mice are identical to the M$ in data format EXCEPT for the middle button.  IN the event of a middle button down event, the logitek sends a 4th byte with D5 set, a($20) or with it clear=$00 when the button is released.  Otherwise its identical the the M$ driver for a 2 button mouse.

      See page 2 of that link for a graphical representation of the bit assignments in the 3 byte packet of an M$ mouse.  Then add a 4th byte only for a 3rd, middle button event.

      Note that the first byte contains the 2 MSB's of a 8 bit value for each direction that represents the vector motion since the last packet was sent.  The MSB of each(y-d3,x=d1) are sign bits to tell which way it has moved since the last packet.

      In fact, I think I am going to forget working on this driver, and see if the 6551M driver makes more sense.  If it does, then I'll blow this one away, copy the M version to the L version and modify it to handle the middle butons 4th byte.  That of course depends on whether or not the M driver makes sense.

      I did a couple of experiments today is all, and may not have time to fool with it tomorrow as I'm due to have some of my test gear at a local radio station at 10ish in the morning & see if we can figure out why its dropping power from 25kw to maybe 7kw when the VSWR shows quite low on one meter, but another at the final output says its getting 20% of the output power back from someplace.

      What I found is that if I do nothing but read the data that caused the IRQ, and skip to the return code, it works fine, UNTIL I move the mouse, then the keyboard is blocked, and I suspect that is because someplace in the return path from the irq service routine, the interrupts are not being re-enabled, so the keyboard IRQ never is recognized.  Moving the mouse may get it to take a key now and then, but be gentle cuz it will eventually go completely away in a screen full of nicely colored confetti.

      Now, when the system boots, I would _think_ that by the time Sysgo is running the startup script, that I should be able to run 'irqs' from the startup script, but without at least a sleep 50 as the next to the last command in the startup, irqs is fetching totally trashed data, particularly with regard to the owner of that interrupt, in one of them when I only had a sleep 10 in there, it actually showed 5 IRQ's, claiming they all belonged to rb1773?  Hit the reset button again, and the next time it might show garbage hex data there, add a few more ticks to the sleep, and its output becomes normal.  Normal looks like this:

      {t2|08}/DD/NITROS9/6309L2/MODULES/SCF:irqs
      Polling Table at: 6AFB
      Device Table at: 6900
      Device    Driver  IRQ   Flip
      Port Mem   Name  Vector  &Mask Pty
      ---- ----  ------------  ----- ---
      FF69 4700  sc6551  E3D0  00 88  0A
      FF6D 10EC  sc6551  B808  00 0F  01

      The top one is the shell running on /t2 of course.  The bottom one is the mouse.  But its showing the thing as belonging to sc6551, and I am under the impression that this driver is 100% self contained, so the sc6551 reference is as bogus as a $3 bill AFAIAC.  Am I wrong somehow?

      So, have a fine one guys.  I'm only going to do one more build and test cycle using the M$ driver tonight since I have to be awake a bit earlier than is normal for this old fart tomorrow.

      --
      Cheers, Gene
      "There are four boxes to be used in defense of liberty:
      soap, ballot, jury, and ammo. Please use in that order."
      -Ed Howdershelt (Author)
      The revolution will not be televised.

       
    • Gene Heskett
      Gene Heskett
      2008-06-12

      Hi Guys;

      I sent you both an email with an attachment, and that totally fixed the keyboard lockout problems woith an IRQSvs routine that does nothing but read the data from the acia and throw it away.

      Now, I've found a dis of a cc3io I did in late 93, at a time when I believe the mouse was working nicely, and I sent that also.  Then in some more trolling through that maxtor copy, I found a cc3io.dr module a few bytes longer yet, and dated in December 94, carrying the name cc3io_m51.mine.

      Now the question is, do we have in the toolshed, a disassembler, like sleuth or disasm?  Taking it apart on this system would be a lot faster.

      That .dis file I sent is os9 style eol's, I can't seem to make tr work to translate them, and it would be half a day in vim to hand convert it.  Is there another way?

      Thanks.

      --
      Cheers, Gene
      "There are four boxes to be used in defense of liberty:
      soap, ballot, jury, and ammo. Please use in that order."
      -Ed Howdershelt (Author)
      The universe is like a safe to which there is a combination -- but the
      combination is locked up in the safe.
                      -- Peter DeVries

       
1 2 > >> (Page 1 of 2)