Indeed, I also always have a mouse connected and on my turbor GT it's not an issue....
To be honest, I do not understand a word!
... It also does not seem to be a problem with real hardware.
I just tested with my own real mouse on a real system, and there is no issue.
So, this area is certainly interesting, but I don't think I'll bother doing anything if this problem actually lies in openmsx (and: bluemsx as far as I can tell).
@Bengalack
Sorry for the delay to reply. RealLife (TM) is consuming all my free time lately.
It seems that the problem is solved. (or never really happened)
Would you anyway still be interested in the explanation? (maybe for future projects, joyMega support or to ignore other devices, like the touchpad or paddles)?
Would you anyway still be interested in the explanation? (maybe for future projects, joyMega support or to ignore other devices, like the touchpad or paddles)?
Thanks, but let’s take that at the next crossroads
Is this issue still present with the latest openMSX development build?
Never mind, I can still reproduce it. I wonder what's going on though. Can someone help to investigate what openMSX is doing differently than the real thing here, which makes the game not respond in the title screen?
Seems like the overview from https://www.msx.org/wiki/MSX-HID#Fingerprints_of_MSX_devices is what is happening when using openmsx. A mouse connected will, according to the page, and when no movement is happening, send 0000 as the four lowest bits from PSG reg #14. This means that Right, Left, Down and Up, is pressed.
My code flips these bits, and a bit that is set means pressed.
My code checks the bits in this order: JOY_BIT_TRG_A, JOY_BIT_TRG_B, JOY_BIT_UP, JOY_BIT_DOWN, JOY_BIT_LEFT, JOY_BIT_RIGHT
Furthermore, in my code when the bits are checked, will returns as soon as one set bit is found, and in our case, the first found is: JOY_BIT_UP. No other keypresses are "getting through" because of this return.
Run the game without mouse plugged and you will get the exact same behaviour if you just hold the UP key while on the title screen. Pressing down will not help or pressing space will not do anything at this point.
If you enter "plug joystickporta mouse", when in the game, you will see Lilly go left (and no cursor keys or space will work). When inside the game, the code is a bit different, and I check for vertical keypresses first and THEN horisontal, as keys can be combined. If Lilly is placed on normal ground you will not see her move up nor down (but UP will get "marked as pressed i the code"), but horisontally LEFT is check before RIGHT, so Lilly is moving left.
Not sure why openmsx sends the signals (ie. value of PSG reg #14) as described on the aforementioned page when a real MSX does not.
This is amazing work and really nice music! I especially appreciate that you have used MSX2 hardware to the fullest and no MSX2+ or better is needed. That leads to my question. Do you think that one of my favorite game Chuka Taisen could be improved with MSX2 hardware? Here's a gameplay example: https://www.youtube.com/watch?v=KCban2rJBis
And here's Master System version: https://www.youtube.com/watch?v=qKy9mnTxMvY
Or could that SMS scrolling be achieved with MSX2+ version of the game?
Well, one can mask the shaky borders with sprites, but that'll cost you two sprites per row - and probably a number of sprite-splts. And in a game like Chuka Taisen you'd rather want some extra sprite-bullets or sprite-enemies on screen.