I’m not sure why anyone would need to change the default mouse shape on the desktop but if you can do it in Windows maybe an attempt should be made for Diamond GOS. I choose this project because it has been 20 years since the last accessory was written. This was the first idea that came to mind and then I stopped thinking. Plus, I’ll be 80 if I wait 20 years for my next one. This documentation should help.

The Diamond Develop User Manual-Third Printing (DDUM3) contains most of the information on defining accessories, data structure of a mouse shape, and DEFINEMOUSE(13) function.

Page 13 of the DDUM3 contains the data structure of the mouse. It requires 10 bytes to define a mouse. The mouse shape is an 8 X 8 matrix image bit map, just like a character in a standard font. The first 2 bytes define the location of the bit where the mouse’s screen location will be calculated (Hot spot) and the next 8 bytes will be the bit mapped character data. It is noteworthy to mention that each bit is 2 pixels wide. This is make the mouse twice the width of a standard character. Consider this while designing the shape. The mirror image of the mouse pointer was chosen for the shape.

Page 8 explains the mouse functions. DEFMOUSE (13) will be used in the accessory to define a new mouse shape. It says that the sample code should help clarify this but it didn’t. You might want to replace the example code with this code derived from the Diamond Macro Library.

LDA # <NEWCURSOR ;ADDRESS OF MOUSE DATA

STA W0

LDA # >NEWCURSOR

STA W0+1

LDA #13 ;FUNCTION # FOR DEFMOUSE

JSR $8E00 ;CALL DIAMOND

That’s pretty much what we need to build the accessory. The major code and the mouse data is ready to add to the SKELETON.M65.

1000 ;SKELETON for Desk Accessories

1010 ;

1020 .OPT NO LIST

1030 ;

1040 .INCLUDE #D:LIBRARY.M65

1050 .INCLUDE #D:DMACROS.M65

1060 ;

1070 *= $2FF0

1080 ;

1090 .BYTE " Call DOS " ;10 Byte Name

1100 .WORD ENDACC ;End of Accessory

1110 .WORD 0

1120 .WORD RUNACC ;Run Address

1130 ;

1140 ;ACCESSORY VARIABLES

1150 ;

1160 RUNACC

1170 RTS

1180 ENDACC

Add the code to SKELETON.M65, assemble to a .OBJ, and then run ACCMAKER.APP. ACCMAKER strips the first six bits that DOS uses to run the object code and then puts the length, run address and load address after the 10 letter title.

The libraries were not used for this code so the .include was deleted, the 10 letter title was changed, the macro variables were defined, the code was added between line 1160 and 1170, and the mouse data was placed between line 1170 and 1180. Then the program was modified, renumbered, compiled, and modified with ACCMAKER until it worked.

1000 ;LEFT HAND MOUSE POINTER .ACC

1010 ;by PACK007 - 2014

1020 ;

1030 ;Desk Accessory to change

1040 ;mouse pointer shape.

1050 ;

1060 ;

1070 .OPT NO LIST

1080 ;

1090 *= $2FF0

1100 ;

1110 .BYTE "Left Mouse" ;10 Byte Name

1120 .WORD ENDACC ;End of Accessory

1130 .WORD 0

1140 .WORD RUNACC ;Run Address

1150 ;

1160 ;ACCESSORY VARIABLES

1170 ;

1180 DIAMOND = $8E00

1190 W0 = $80

1200 DEFMOUSE = 13

1210 ;

1220 RUNACC,

1230 LDA # <NEWMOUSE ;ADDR MOUSE DATA

1240 STA W0

1250 LDA # >NEWMOUSE

1260 STA W0+1

1270 LDA #DEFMOUSE ;dFUNCTION #

1280 JSR DIAMOND ;DO FUNCTION

1290 RTS

1300 ;

1310 NEWMOUSE

1320 .BYTE 7,0 ;HOT SPOT

1330 .BYTE $01,$03,$07,$0B

1340 .BYTE $05,$04,$08,$00

1350 ENDACC

The zip file contains the .M65 and .ACC files. Add the LMOUSE.ACC file to your boot disk and boot up DIAMOND. “Left Mouse” will be added to the drop down menu. Click on it to change the mouse. You should also know that the change is not permanent. Whenever Diamond changes the mouse, like when you access a disk, it will restore the original mouse. Also when running a new program the mouse will be the original mouse. At least if the program uses the drop down menu the accessory can still be used.

LMOUSE.zip

Note to Future Self.

There was a time when the program would compile and not work. No matter how many times I read the code I couldn’t find an error. I began to wonder if the ACCMAKER.APP and SKELETON.M65 were working correctly. This lead me Matthew Ratcliff’s COLORME.ACC sample accessory in June 1998 issue of Antic. The code was rewritten to use his method of modify the OBJ file and calculating the accessory header data. The code still didn’t work.

Then I found the rookie mistake in line 1270. “LDA DEFMOUSE” will generate a command much different then “LDA #DEFMOUSE”. Once changed Ratcliff’s method magically worked.

The accessory file created with ACCMAKER.APP also worked and is reported above.

This seems to always happen to me.

I just did the last spell check and was making sure ACCMAKER was spelled correctly when I noted some memory locations in the manual where mouse data is stored. I just wondered if something different would happen if I poked the mouse data into this location rather than use the DEFMOUSE function. ??? Then I wondered if anyone cares.