[Coco] Need assembly guru (I _thought_ I was half of one)
Gene Heskett
gene.heskett at verizon.net
Mon Jun 9 18:36:30 EDT 2008
Greetings all;
I'm trying to get the mouse and hardware that worked 15 years ago to work again,
but under the new nitros9-3.2.8 regime.
I don't know if I have bad hardware (the extra acia for the mouse in my deluxe
rs-232 pack) or what. But the symptoms from a software view are that bit d3
in the status register is stuck high, as is probably the IRQ flag but I haven't
double checked that as its moot in trying to get the chip setup to receive only
from a Logitek "DexXa' 3 button mouse.
When power to the mouse is cycled by resetting the acia, then re-enabling it,
the mouse spits out its ID bytes, and in fact this one lies about it, claiming
to be a 3 button M$ mouse, but there is a protocol difference. The M$ mouse
sends an empty packet for a middle button down event, the logitek sends a 4th
byte with a single active bit to indicate the button down and button up events
only for the center button. And only sends it for the center button. However,
that is a down the road problem to solve once I get the mouse handshaking
working.
Here is a snippet of the code:
ClrACIA ldx M$Mem,pcr get base hardware address again
clra
clrb
std CmdReg,x full hdwe reset
* loads $0918, $09 to CmdReg=tx irq dis, no par, tx low
* $18 to CtrlReg= 1200 baud 1 stop
ldd #(TIC.RTS!Cmd.DTR)*256+(DB.8!Ctl.RClk!BR.01200)
* [D]=command:control
std CmdReg,x set command and control registers
* do 80 instant reads for trash collection
* and clear status of Stat.RxF bits
ldb #$50
flshinit lda DataReg,x throw it away
lda StatReg,x throw it away
decb
bne flshinit
* that kills most of the 14 milliseconds
* to the mouses first response byte
* now, lets see what mouse we have
pshs y
ldy #$00D0 set dly to fail
NxtByte leay -1,y start cntr
beq NxtBExit was InitErr, do 208 times, let it fail
* more time delay
lda #$00
NxtDly deca
bne NxtDly
* is something screwing with x?
* shouldn't need this, probably not needed
ldx M$Mem,pcr reload x
lda StatReg,x RxF,ovfl,fram,par
anda Pkt.Mask,pcr narrow to lower nibble
* then check for rx buff full
tsta Stat.RxF set z flag if d3=0
beq NxtByte z flag set, try again
* show status as arrive here
pshs a,b,x,u,y,cc,dp
adda #'0 make lower nibble printable
jsr <D.BtBug prints char in reg a on boot screen
puls a,b,x,u,y,cc,dp
* got a data byte, get, show
lda DataReg,x get ID byte
pshs a,b,x,u,y,cc,dp
jsr <D.BtBug what was it?
puls a,b,x,u,y,cc,dp
bra NxtByte there may be 2
* temp stopper so I can read screen
NxtBExit puls y fix stack
* show we're here
lda #'S
jsr <D.BtBug show the S so I know its here
letmesee bra letmesee
----------------------
This outputs 8,_,8,M,8,3, and the final S to the boot screen.
The 8's are the status register, saying that the rx buffer is full and I should
read the data, and the rest "_M3" is from the RxData of the 6551.
This almost looks good, but whats the '_'? As I can see on my scope, the mouse
is only sending 2 bytes unless the chip is reading the powerup transient too
fast, & its already been read more than 80 times at the point I start showing
data. But, the data can be read from the chip in a repeat stream until
overwritten by the next byte from the mouse. The point here is that even after
80 reads, that status byte still says there is data to be read. It is supposed
to be reset by the read, and apparently is not. Or is my code funkity? Blast
away at it folks. :)
I would like to use the "M3" as a validator that the right mouse is hooked up,
but this one looks like it is lying, as that should ID a 3 byte packet M$
mouse.
Ideas anybody?
--
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.
More information about the Coco
mailing list