Joystick Port

Page 6/14
1 | 2 | 3 | 4 | 5 | | 7 | 8 | 9 | 10 | 11

By mars2000you

Enlighted (6317)

mars2000you's picture

16-08-2022, 12:37

There is another source of confusion on the MSX-HID page:

"Devices that do not support the protocol:
* MSX joystick and joypad
....
The first three devices are not even wired according to the standard MSX joystick schematics."

while it is also mentioned this on the same page:
"Fingerprints of MSX devices
Unconnected, or MSX-joystick : 3Fh,3Fh,3Fh"

Must I understand that there are problems with (some models) of MSX joypads?

By gdx

Enlighted (5694)

gdx's picture

16-08-2022, 13:36

The values returned depend on the components used and how they are connected. So neither "fingerprint" nor "signature" is adequate. If you have a better idea, feel free to change it. "fingerprint" seems better to me.

This trick needs the pin 8 to works. So it only works with controllers that use it.

MSX Joysticks are connected to no pins when no switch is pressed. So they are not detectable too.

By mars2000you

Enlighted (6317)

mars2000you's picture

16-08-2022, 13:42

gdx wrote:

-

MSX Joysticks are connected to no pins when no switch is pressed. So they are not detectable too.

ah.. I see the subtility ..

By aoineko

Hero (523)

aoineko's picture

16-08-2022, 22:47

I read the part of the Datapack about the general purpose port, but it doesn't talk about detection at all (as you might expect).
Access times are only specified for reading data from the mouse.
The information I am missing is mainly how the numbers in the MSX-HID article are obtained. I don't own any of the devices that are not supposed to return the same value all the time, so it's hard to test to know the right way to read these bytes.

gdx wrote:

And here is an extract from the Pratique du MSX (which says almost the same thing in French)

This also only talks about reading the data from the mouse.
Just to clarify: my mouse reading function (derived from MRC one) works just fine. :)

Now, I would like to add a detection function.
Even if the MSX-HID never existed as such, it seems that is the method used by the MSX2 BIOS (or more) to detect joysticks, mouse and trackballs (?) and manage them differently.
Without implementing all the MSX-HID protocol I would like to have at least the BIOS detection level in my library.

By sd_snatcher

Prophet (3551)

sd_snatcher's picture

16-08-2022, 23:57

mars2000you wrote:

There is another source of confusion on the MSX-HID page:

Sadly, the article is now so disfigured that and full of obsessive prejudice labeling it's almost falling apart. Many parts have conflicting misinformation that were not there originally.

Better check the wiki history tab for versions that still made any sense.

By sd_snatcher

Prophet (3551)

sd_snatcher's picture

17-08-2022, 02:17

Except for some short messages, I've been keeping some distance from these forums and, in particular, from anything that "shouldn't have been done" for the OPLL, MSX-Audio, MSX-HID or game patches.

I hope I don't regret coming back here to try to clarify your questions. I also hope you don't mind that I use some relatively modern terms to describe ancient hardware, just to make comprehension easier.

aoineko wrote:

I have a question about how this detection method works. I'm a dummy in electronics so I don't understand all these references to pins and their high/low values.

Having some knowledge on electronics is important to understand what's happening, since that's exactly what the algorithm uses to detect the devices. Without that, all I can tell you is "don't worry, it works just fine if all the premisses are followed." Smile

One important aspect that is present on the HIDlib documentation (README.TXT file) and not on the article (*1) is that it's a stateful machine. IOW, you have the "detection state" and the "device mode" state.
*1: Never found again the motivation to add it there

  • Detection state: just care about detecting the devices, but doesn't know how to talk to them
  • Device mode: Doesn't do any detection. It will just call the appropriate driver to read a package of data from the device. If the driver signals that the device was disconnected, the "device mode" state switches the machine to the "Detection state".
Quote:

Still, I'm not sure how I'm suppose to get those numbers. ^^
- Write R#15 with 'pulse' set, then read R#14 three times?
- Write R#15 with 'pulse' set, read R#14 once, reset R#15 'pulse', then read R#14 twice?

And what about the timing between those access?

Here's where the electronics knowledge is more important. I'll try to explain the best I can:

On the "detection state", the pin-8 of the joystick port is used to send clock pulses. On each pass you read the 6bits of the joystick port to check how the device reacted, and flip the pin-8 value for the next cycle to use, then save that value and repeat until 3 values have been read. Yes, you could read more values, but just 3 is enough. These are the "device fingerprint". In a nutshell, you read the 3 values with the pin-8 in low, HIGH and low states respectively.

Don't care about the timings on the clock pulses, since it's not relevant. All the peripherals I checked were tolerant to the clock speeds that the existing MSX models can flip the pin-8 port state. Probably we would only have to care about timings if we had anything quite faster than the R800. And yes, I know about the mouse timings. But for its detection it's also not relevant. All the relevant timings are mentioned in the premises (i.e.: the device will auto-reset to the 1st byte after ~8ms without receiving clock pulses).

The first 2 bytes if the fingerprint form a unique ID that can be used for the "device mode" to select which driver it will call to talk with the device, or to just ignore it if it's not known. A higher level UI also can display the device name based on this ID. The 3rd byte is used only when relevant, to differentiate between variations of some devices and to detect PWM devices. There are where even more bytes can be read on detection, like the Megadrive 6-button joypad. But this can be done only when really necessary.

Note: It is very important that you read and understand the premises listed in the MSX-HID article.

This is all that there is. It's simple and it just works, if the premises are followed. The rest is implementation dependent. In example, for speed/memory reasons HIDlib will crunch the first 2 bytes of the device fingerprint into a single-byte hash using the "HIDID" formula mentioned in the article.

By aoineko

Hero (523)

aoineko's picture

17-08-2022, 02:29

Thank you for these detailed explanations.

For the moment, I implemented a single byte detection in MSXgl because I was mostly interested in detecting the mouse and trackpad among standard MSX devices.

Testing with OpenMSX, BlueMSX and fMSX, I could see that everything works fine for the joystick, mouse, trackpad and paddle, however, the touchpad and lightgun return different values than those in the MSX-HID article. I don't know if the emulation of these devices is perfectly correct.

And about the article, it's really a pity that there was so much misunderstanding between MRC users. You have done a lot of work that has not been rewarded to its true value. Maybe if you had made it clear from the beginning that this was not a standard, but experimental results, there would have been no (or less) objections. Once this fact is established (which I didn't understood at my first reading), I personally see no problem even in talking about "protocol" or "signature".
It would also have been interesting to first explain how the MSX2 BIOS differentiates between Joystick, Mouse and Trackball. This is the closest thing to a standard.

This said, imo the article even altered by the numerous modifications is still interesting.
Thank you.

By mars2000you

Enlighted (6317)

mars2000you's picture

17-08-2022, 02:37

The touchpad is not emulated, so you can't check that in emulators.

For the lightguns, the emulation is probably uncomplete.

By sd_snatcher

Prophet (3551)

sd_snatcher's picture

17-08-2022, 03:45

aoineko wrote:

Thank you for these detailed explanations.

You're welcome. Smile

Quote:

this was not a standard, but experimental results, there would have been no (or less) objections.

But these are not just experimental results. As I explained earlier in this thread, I even don't dare to call this "my algorithm" or "my discovery" because some original MSX software also used some or another (sometimes simpler) variation of this type of detection, and it would be unethical to try to claim the credit for the idea.

What I did was just to reverse engineer how it was done, combine the variations I found in a more uniform approach, and describe everything the best way I could on that Wiki document so any MSX programmer could use it reliably.

I also wrote HIDtest and HIDlib to show that it is simple and works just fine on a real application. I just imagine if I didn't, the destructive criticism could be even worse.

Quote:

For the moment, I implemented a single byte detection in MSXgl because I was mostly interested in detecting the mouse and trackpad among standard MSX devices.

Ok. But please be aware that a single-state single-byte detection will give you false results under some conditions.

By sd_snatcher

Prophet (3551)

sd_snatcher's picture

17-08-2022, 03:30

mars2000you wrote:

The touchpad is not emulated, so you can't check that in emulators.

openMSX emulates the touchpad, but it still doesn't behave like the uPD7001 when clock pulses are sent to the pin-8 of the joystick port. This is why the detection fails.

Page 6/14
1 | 2 | 3 | 4 | 5 | | 7 | 8 | 9 | 10 | 11