This is a boring technical explanation of how I have adapted EDCW to work with EnterMice.
I think the process can be replicated on other programs easily.
First I put an entry on the movement acquisition routine like this:
vcv ld a,(mouseg); segment where the driver is installed, default is 0, not installed
or a
jp nz,usemou; this is the original Hsoft mouse entry of EDCW
; Modification here
;---------------------------------------------------------------------------------
ld a, (0BFECH); RANDOM_IRQ, 1/50 seg counter as I don't have an interrupt routine
ld hl, interrupt; the same but last time read
cp (hl)
ld (hl), a
jr z, continu; we need to wait up to the next frame for the MSX protocol to work
call msx
jr z, continu; no movement on mouse or EnterMice, X_REL and Y_REL both equal to 0(0,0)
ld hl,X_REL; X displacement
ld a,(hl)
cp 255
jr nz, enterm
inc hl; Y displacement is contiguous
cp (hl)
jr z, continu; no mouse or EnterMice detected, X_REL and Y_REL both equal to 255(-1,-1)
; this avoids the typical Boxsoft annoying diagonal movement and serves to flip from internal
;joystick movement to EnteMice movement automatically
enterm jp entermice
;---------------------------------------------------------------------------------
;end
continu
ld b, 0
call jo1; external joystick 1
This was the hook implanted. Every time the "msx" subroutine is called it returns writing the X_REL, Y_REL and MAINBUTT_STATUS variables, so we need to add the displacements to the actual coordinates. Zero flag is set if no movement(0,0).
What my Entermice routine does is to convert the unusual EDCW's coordinates to standard coordinates on 16 bit format. X can go from 0 to 599, and Y from 0 to 199. You can say that we only need a byte for Y, but take in account that the increments can be positive or negative, from 127 to -128, so we don't have enough with eight bits to do the addition, at least 9 bits are necessary.
Once done the addition, we need to adjust the results to the possible range. First of all we don't need the negative numbers, below zero, then we can cut easily the upper limit.
In this case we don't need again to convert the coordinates to EDCW format, the original Hsoft routine does that for us, only we must find the appropriate point of re-entry, just where the coordinates have been resolved on the original routine.
But the original Hsoft mouse routine had an error that calculated a bad address where to draw the pointer, sometimes just over the EDCW code...
I have only added an offset to the calculated address to fix it, but it take me long to find that bug, as I always though it was only my error...
I hope this explanation will serve so that "soon" other programs would be adapted to EnterMice use.