DOSBox doesn't have a "mouse driver", the int33 handler is already chained from a callback (set as the default interrupt handler like a BIOS routine).

Hi, thanks for the reply.
I meant something different: In src\hardware\input\mouseif_dos_driver.cpp the int33 is set up for the mouse driver and I want to add additional functions on this interrupt written within the DOSBox code, not from within a DOS application. My code is working when I modify int33_handler() directly, I can handly my own signals, but to have a cleaner code (and can my load my code independently from the mouse driver), I tried to implement to chain my own function call with CALLBACK_Setup in MOUSEDOS_Init(). But while the original mouse code is called when executing int 33h, my own code is not called (my Init is called after MOUSEDOS_Init).
I also was able to connect my own callback handler to int 34h from some selfwritten Pascal code, but since the DOS application is calling in33h this would not be an option.

Caligula wrote on 2023-12-25, 23:33:

In src\hardware\input\mouseif_dos_driver.cpp

I don't know what that is, it's not part of regular DOSBox.

Hi,
Sorry, that was code from dosbox-staging. I also checked out Dosbox-staging and Dosbox-X to see if I can find additional clues in these repositories and I accidentially copied it from dosbox-staging. But it is essentially the same as the MOUSE_Init() from trunk\src\ints\mouse.cpp or BIOS_PS2Mouse_Startup() from Dosbox-X.

But I still did not figure out how to store the original interrupt handler and call it from my own routine.

CALLBACK_Setup is probably not meant to be used for chaining interrupt handlers - and I seriously doubt any fork does something like this, as that would bring performance penalty.

Unless you are developing a mouse driver API extension, adding any special/custom function to INT33 is probably not the best idea - as the user can load it's own mouse driver (like CuteMouse), which might render your custom function inaccessible.

What functionality are you going to provide via this custom function? Is this some private experimentation, or do you intend to publish the patch eventually? Is your development focused on a single DOSBox branch/fork, or is it going to be a cross-flavour functionality?

For some reason I did not get the notification that you posted something here.

I started porting the Forte VFX1 drivers to OpenVR (Decent2 and the Mars demo included with the drivers are working now, but no luck with Magic Carpet 1/2 so far) which is hooking up to int 33h, ah=60h..70h. al contains the acutal command (all info based on the VFX1 sdk). For now I modified the mouse driver interrupt in Dosbox-staging, my plans are to provide a patch for Dosbox vanilla, -X and staging. But modding the int 33h mouse driver code itself is not the best and cleanest solution and would mean additional effort for three branches.

The original VFX1 driver is actually taking over int 33h (VFX1.com must be installed after the mouse driver) and forwarding non-VFX1 calls to the original mouse driver.

I see. Indeed, it would be best to have interrupt chaining eventually, in case someone wants to use an original DOS mouse driver.

Well, good luck then 😀

[edit] Unfortunately, latest drivers and game patches cannot be downloaded any more, despite the web page still exists: http://www.mindflux.com.au/products/iis/vfx1.html

Via archive.org the site is still working: https://web.archive.org/web/20010208083755/ht … s/iis/vfx1.html - but the SDK sometimes refers to the developers manual and so far I saw the usage of two undocumented calls (al=90h for SET_CALLBACK and al=91h). I try to clean up my code and upload it to github when I find some time soon.