rm/rmnimbus.cpp: Allow choice of HLE mouse processing #11890
Conversation
|
I don't think there is any chance of this being approved, you're replacing 'accurate' (but slightly buggy) emulation with a HLE hack |
Perhaps it could be added under a config port to switch between the two solutions? I think its currently more than just slightly buggy because it's very difficult to move the mouse anywhere! Just try drawing a picture in a paint program! Even playing windows solitaire is frustrating... We had these machines at school so it's mostly nostalgia for me really. |
|
yeah, I can't dictate the policy, but there's more chance of it being accepted if it was an option (if the mouse is pluggable, maybe a 'hle mouse' and a 'proper emulation mouse' although the HLE might be a bit too intrusive to do that) removal of technically more correct emulation entirely, in favour of 'better working' but completely HLE solutions is basically never accepted though, I thought it was important to mention that. |
Yes, thank you. I totally get that and can understand the argument. There used to be a config port to say if a mouse or joystick was connected so I could use that idea to add an option like you suggest. I wish I could improve the interrupt handling but It's been driving me insane! Everything I've tried either makes no difference or breaks it completely! I think putting in the HLE option might be nice until somebody can sort the interrupts. |
|
Maybe there's some way to massage the data being returned so that it comes out correctly without having to do such a blatant hack? |
|
Further commit made to provide "mouse emulation mode" config. By default the old (Real) emulation will be used, but if set to "HLE" my alternative is selected. This makes it easy to compare the two behaviours, and would allow people to switch if they preferred more responsive mouse input. Would this be acceptable at least until the real emulation can be fixed? |
It must be possible to fix, but it's not immediately obvious for sure! It seems that the sequence of interrupts and timing has to be spot on - otherwise the direction of the cursor is suddenly reversed. It's better if you move the mouse very slowly which indicates a timing issue of some sort. Anyway, perhaps we could use my fix, with the config I've just added, until somebody can get to the bottom of it. |
|
With the choice available, this fits a pattern I've used myself where broken keyboard/mouse LLE was available but turned off for a system until it could work properly. And having this broken since 2014 means no easy fixes are in sight. Let's do it. |
rb6502
changed the title
Great, thank you. @rb6502 do you think the default should stay as "Real" or would "HLE" be better in case people do not discover the setting? |
|
I'd just call it "HLE", and maybe make that the default setting. |
Thanks, I will create another pull request to change the default in that case. I think HLE is generally what people will prefer to use. |
The current implementation tries to simulate the mouse interrupts generated by the real hardware, but this results in very erratic movement and a poor user experience (see https://mametesters.org/view.php?id=5745).
After studying this for some time I've come to the conclusion that we don't really need to generate the interrupts at all because all software seems to use the default mouse ISR from the BIOS. This PR basically bypasses the ISR and updates the mouse position directly by writing to the memory locations used by the BIOS. I found these by stepping through the ISR with the debugger.
I've tested this with all 6 BIOS versions and a variety of software, e.g.
RM Basic
Menu
Canvas
Windows 3.0
PaintSPA
Microsoft Word 3.1
It seems to work fine and the mouse finally behaves normally :-)
Do you think this is the correct solution? Obviously it would be better to have the interrupts working properly, but from a user perspective I think having normal mouse behaviour is more important. Very little software was written for the Nimbus and it seems unlikely that there is anything out there that does not use the BIOS routines - unless somebody knows otherwise? Also has anyone come across software that reads the mouse by polling? I've tried to support that method (as before), but cannot find any programs that don't enable the mouse interrupts.
Any comments on the solution itself would also be welcome, e.g. is there a better way to write to the memory or some thread synchronisation method that I'm not aware of.
Config port now included to allow the mouse emulation mode to be chosen by the user (defaults to "Real", with "HLE" for the new high level emulation).