It searches for the Hsoft own created mouse driver, not the Boxoft mouse driver modified by Hsoft:

Now I tried it, but don't work. Driver detected, but system crashed after few seconds Probably started development of this function but don't finished?

And the Mkey.ext says "Enterprise Mouse-Keyboard". It weights 4280 bytes.

The disassembly of the Hsoft mouse driver 1.1 is inside "K", but I don't know with what assembler has been made.

I have "bad-translated" with the aid of Google the MOUSE.DOC file. First I had to put all the á, ó and ú in the text, as it was written on  an EP Magyar type font.

It will aid me to know how EDCW interacts with the HSOFT mouse driver.

There is a command "MOUSE" followed by 0FDh that returns in A and BC the segment and address where is the descriptor of the MOUSE device.

At that position  there are some useful internal variables:

-4      SYNC    The byte synchronism of the scan routine
-5      KEY     b0-b1-b2=Mouse buttons status
-6      X1      mouse X1 relative displacement
-7      Y1      mouse Y1 relative displacement
-8      XH      mouse X position
-9      XL
-10     YH      mouse Y position
-11     YL
-12  *  XH      X Upper limit position, little endian type
-13  *  XL
-14  *  YH      Y Upper limit position, little endian type
-15  *  YL
-16  *  XE      X Sensitivity  (0-7)
-17  *  YE      Y Sensitivity  (0-7)
-18  *  XPH     mouse X position little endian type
-19  *  XPL
-20  *  YPH     mouse Y position little endian type
-21  *  YPL
-22  *  SI      software interrupt mode: b3=movement, b2-b1-b0=buttons
-23     KEY2    mouse button to copy the soft-interrupt
-24     XPH     X copy of the soft-interrupt position
-25     XPL
-26     YPH     Y copy of the soft-interrupt position
-27     YPL


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

I'm now searching for "not entry" labels to save more space for the EnterMice routine.  At this moment I've found one that will save 4 bytes, not much, but I'm only beginning with the listing.

Slowly I am figuring out how EDCW moves the pointer.

Meantime I find some curious details about how it has been programmed.

-It is plagued of auto modifiable code, for example:

wasn    ld a,0
        or a
        jr nz,nonc
 
        ld a,252
        call seize

        ld a,255
        ld (wasn+1),a
-Almost the entire extension is loaded on Z80 Page 0 at 100h address every time it is executed:

        push bc
        ld hl,maincde+1
        ld bc,extname-256; end of the code
        ld de,100h
        ldir
        pop bc
        jp 100h

To do it, there is a compiler command that forces the assembly of that chunk to be executed from 100h:

maincde ret

        phase 100h;  assembles this chunk on 100h address
And, at the end of the code:

extname equ $
        dephase
PEND equ $
END


I think that the Rom version of the EDCW uses the same method, as the author claims the two versions are compatible. It would have cost the rewriting of all the program to remove all that auto-modifiable code.

-An unknown "External keyboard" hardware is used by the program.  Probably also created by Meszaros, uses Z80 ports 60h and 61h, not present  on LGB list.

-Inside the code, some 16 bit input-output port instructions are used. I though they where forbidden due to the paging method of the Enterprise:

int     ld bc,0b5h; b=0
        ld e,7; row 7
        out (c),e; Keyboard/Joystick row select
        in d,(c); Keyboard line status
        bit 2,d; right
        jr nz,wo
Here, "out (c),e" is used to save some instructions when scanning the keyboard.

But here it is used to scan for connected hardware in a way that I still don't understand:

he?     push bc
        in a,(c); I think it searches for hardware in the ports
        inc a
        jr z,pw

        ld (hl),c
        inc hl
        inc d

pw      pop bc
        inc c
        djnz he?

        ret

Surely it is. Not so complicated like the serial card. There is even a driver for it on the HSOFT big file.

A pity that serial keyboards are not so common today. I have thrown many to the junk...

I remember a project to modify the ROM inside on a specific maker....

I remember to have 5 pin DIN to mini-DIN(PS/2) adapters for that XT keyboards.

I think both use the same protocol. Not the same protocol as PS/2 mice but with the same signals, +5, negative, clock and data.

EDCW stores the cursor coordinates with three bytes, first the line(IX), 0 to 199, then the column(IX+1), 0 to 74, and at last the pixel(IX+2), 0 to 7.

This way it is very easy to calculate the exact memory address of the position. It is an intermediate stage between the pure coordinate position and the mere memory position. But adding or subtracting from a position involves to perform many calculations.

At the other side, the  Boxsoft approach(mouse driver, EGI and Paintbox) works internally with simple coordinates, and only translates them to memory position when the pointer has to be drawn.

The good news is that EDCW has already the subroutines to add or subtract from a position, so there I can save some valuable memory. I only have to discover how to call them without disturbing the main process. The ideal approach is to merge the EnterMice movement with the joysticks routines. I think it is possible, because they are already prepared for increments grater than 1. If you press a direction on the internal joystick for a while the pointer begins to move faster. There is an acceleration routine that detects that.

The problem here is that I only have about 13 bytes free, not enough to do beautiful miracles...  

640Kbyte should be enough for everyone Ok. but 13 bytes?

To my tests I am using superb LGB's Xep128. As it access read only the SD-image it is easy to have it mounted as a virtual unit and copy the newly compiled EDCW extension to try.

"superb LGB" Maybe LGB's superb Xep128, but it's even too much Sorry, I couldn't resist to react, but thanks for the nice words

Acutally - I think - you must be careful with that. What you're doing is nice (even I do this sometimes) just care must be taken, as if image changes, EP won't notice it and maybe things cached FAT etc entries (I am not sure about EXDOS/FISH internals ...) will be invalid. But if you modify that among EP reboots etc, it must be safe ... I think

Anyway it's nice that somebody else other than me uses Xep128 too at least Even just myself, I can find bugs if I try to use it eg with Bricky Prise now, the sound problem This is because just developing Xep128 may not expose bugs with testing some "fixed stuff", but the every-day usage can point some other bugs out, sometimes