Dragon Serial Mouse

Up2Date '93

The trouble with serial, & RS232 is it immediatly causes confusion about where to connect things. For example, do you connect Transmit Data from one device to Transmit Data on the other (surely they'll both be trying to transmit data on the same wire then?) or do you cross them over (a 'null' modem cable does this so I'm informed) which is more logical to me. Without trying to explain all that because, I opened up the lead I made for my mouse & jotted down the connections.

My mouse is, I believe a standard Microsoft compatible one & hence is pretty much industry standard. It comes with a 25 way D-Type connector (not industry standard for mice). In order to connect it to the Dragon, I made up an adaptor lead with a 25 way connector on one end & a 7 pin DIN on the other. Therefore, the connections I give are for this arrangement. If you decide to chop of the original connector & replace it with a DIN connector, I'm not quite sure how that relates. You may need to swop the TX & RX lines around.

Based on the pinout numbering shown on the diagram, the following connections should successfully connect the mouse up. I've also put the equivalent pinout of a 9 way D Type.

Pin #
7 PIN DIN       25W D TYPE      9W D TYPE
   1                2               3
   2                7               5
   3               20               4
   4                3               2
   5                n/c             n/c
   6                n/c             n/c
   7                n/c             n/c

link pins 5,6   link pins 4,5   link pins 7,8

Essentially, all you are doing is connecting TX to TX, RX to RX, DTR to DTR & GND to GND, with CTS & RTS at both ends connected together (or tied active) for good measure. All I can suggest f it doesn't work is try swopping them around (ie. RX to TX), you won't hurt the machine by trying.

PCs use a mouse driver to deal with the data the mouse feeds into the serial port & convert it into some meaningful format for applications to access. The program MOUSE.BIN is a mouse driver, which loads into the Dragon's cassette buffer. It should be run by typing EXEC which will install the interrupt vectors & set up the Dragon's serial chip to work with the mouse. It maintains 3 bytes in memory giving a horizontal position from 0-255 in location $F8, a vertical position from 0-191 in location $F9 and a status byte for the mouse buttons in location $E7. These locations are updated every time the mouse is moved & can be read from BASIC or another machine code program. The X & Y bytes can be directly plotted onto the hi-res screen, the button pressed can be assertained by ANDing the status byte ($E7) with 1, 2, or 4 (for RH, Middle & LH buttons).

Notes:

1. If you reset the machine, the serial chip will need to be initialised as followes:

POKE &HFF07,&H18
POKE &HFF06,1

2. If you access the disk system, the mouse driver should be disabled, then re-enabled afterwards as any mouse movement during a disk access will corrupt the disk.

Disable the driver via: POKE &HFF06,0
Enable the driver via:  POKE &HFF06,1

Adapting a joystick driven program to mouse.

Once you've used a mouse with an art package or for menu selection it's painful to have to go back to using a joystick, and since almost no programs for the Dragon are written with a mouse in mind, adapting an existing program is almost the only course of action available.

Converting a program will probably be quite straightforward, but can be time consuming. If the program is written in BASIC then there will usually be one routine for updating the joystick (using a cross referencing program such as DYNAXREF to look for the keyword JOYSTK will be useful). Once you've located the joystick routine it is then fairly simple to replace it with PEEKs to the mouse driver locations. Normally hi-res joystick routines come in 2 forms:

a) the first variant reads the absolute position of the joystick pot (0-63) and multiplies it to give a range of 0-255 for the X axis & 0-191 on the Y axis eg.

        X = JOYSTK(0)*4
        Y = JOYSTK(1)*3

the mouse routine is therefore straightforward:

        X = PEEK(&HF8)
        Y = PEEK(&HFA)

b) the secound variant only makes use of the far ends of the pot <5 and >55 for example and increments or decrements a counter eg.

        X1 = JOYSTK(0)
        IF X1<5 THEN X=X-8
        IF X1>55 THEN X=X+8
        IF X>255 THEN X=255
        ...

this routine is probably best replaced with a direct read of the mouse X & Y locations as before.

The joystick fire button is accessed via a PEEK to location 65280 (or &HFF00). Again, a cross referencing progam is useful here to look either for PEEK or 65280/FF00. This location returns either 126 or 254 when the right button is pressed or 125 or 253 when the left button is pressed. The program may interpret this in differnt ways, acting on it directly with an IF statement or it.

        IF PEEK(65280)=126 or PEEK(65280)=254 ..

        or

        FI = PEEK(65280)

FI will therefore be either 0 or 1 depending on the fire button. The direct translations for a mouse button would therefore be something like:

        IF PEEK(&HE7)=131 THEN

        or

        FI = (PEEK(&HE7) OR 251)+3

This last example will ensure that pressing the left button will return a value in FI equivalent to one of the joystick values.

If the program is written in machine code, or uses a machine code routine to read & implement the joystick routine, it becomes harder. I've never converted a machine code driven routine to mouse since I've never come across one. If you do come across a machine code routine you could try the following:

Look through the code for the bytes $BD, $BD, $52 (the nmenonics for JSR $BD52, the Dragon joystick routine) with a simple FOR/NEXT loop. You can then POKE in a new address instead of $BD52 for your own mouse routine. This will need to store the mouse movement into locations $15A & $15B (the right joystick X & Y locations) as a value between 0-63. Alternatively, disassemble the routine around the JSR call to try to understand what the program does with the joystick values.

Dealing with the fire button is even more difficult, this time you need to look for $B6, $FF, $00 or $F6, $FF, $00 (LDA $FF00 or LDB $FF00) and replace it with your own code. A disassembler & a good knowledge of machine code is a must.

Once you've altered the driver code there is a number of other modifications to be made. Make sure the mouse driver program is loaded & run at the start of the program. Add the serial port enable POKEs at the start of the program to ensure the mouse is activated should you reset the machine. You should also ensure the mouse is disabled when you quit the program. If there are any disk accesses, make sure the driver is disabled when these occur.

All being well, the program should happily run with a mouse.

Addendum - May '96: There are two mouse drivers listed here for the two mouse variants I have come across, MOUSE.BIN I believe is the Microsoft protocol and if your mouse is a 3 button type then this is the one to try first. In addition, mice conforming to the MOUSE2.BIN driver often require RTS/DTR linking together at the Dragon end.