HIDtest v3.1 released

HIDtest v3.1 released

by sd_snatcher on 09-02-2020, 00:30
Topic: Software
Languages:

The version 3.1 of the HID tester and HIDlib has just been released, with many optimisations and bug-fixes:

  • Added the Generic Joystick 2-byte mode, that disables PnP detection and shows raw data from the joystick rows, to help to check for miswirings and nonMSX-HID joysticks.
  • Fixed the center value for the analog direction display
  • HIDlib: Added support for nonMSX-HID device handling. The idea is to make the life of the programmers easier, by allowing these devices to be handled by the same code and driver structure, except for the missing PnP detection.
  • HIDlib: Improved driver for the XE-1AJ analog mode: faster and can now read the buttons A' and B' independently from A and B. Implemented digital direction emulation on the analog mode, to facilitate its use on menus
  • HIDlib: New version of the Arkanoid Vaus paddle driver. Smaller, faster, fixes centering on turbo machines and has a new disconnection detection method that is not dependent on the 74LS165 chip specifics.
  • HIDlib: changed the way the channels are mapped for PWM devices. This is meant to improve compatibility with the Break Out MSX-paddle.

Both the binaries and sources can be downloaded from FRS' MSX Page.

Comments (19)

By Pippo

Hero (521)

Pippo's picture

10-02-2020, 20:11

Very helpful utility! Big smile
Thanks a lot, Frs, for it. Smile

By gdx

Enlighted (6103)

gdx's picture

11-02-2020, 11:03

Thank for this tool.

I tried it on real Turbo R and it doesn't quit properly when I press ESC.

In addition, I think use is a little obscure for non-experts. A menu to select used controller following by corresponding test screen would be better. Then Row 0 and 1 seem to be inverted when /G is specified. (Row 1 is optional, moreover nothing prevents adding rows by using external chip.)

HIDTEST screen wrote:

Note: if you get spurious detections, your joystick might not be wired according to the MSX specification.

I think the sentence below is more appropriate because the MSX specification does not forbid using GND instead of STROBE to make special controllers. The standard wanted to be open about it and that is why these ports are called "General Purpose Ports".

if you get parasitic detections, the wiring may be incorrect or the controller is not generic.

By sd_snatcher

Prophet (3645)

sd_snatcher's picture

11-02-2020, 15:18

gdx wrote:

Thank for this tool.

Thank you for taking some time to test it too. Smile

Quote:

I tried it on real Turbo R and it doesn't quit properly when I press ESC.

Humm. I'll take a look into that.

Quote:

In addition, I think use is a little obscure for non-experts. A menu to select used controller following by corresponding test screen would be better.

Here you got me confused. There are two modes:

1) Easy, fully automatic, "cooked" information: MSX-HID mode
2) Expert, raw information: Generic 2-byte mode

Maybe I should have called it just "Expert" mode, but then I have only one driver for this mode and it's the Generic 2-byte (aka Generic 2-rows). I must admit I'm terrible to pick up names while I'm programming. (see "signatures" vs "fingerprints" controversy) Tongue

And this caution with controversy must always be taken into consideration around here. There's always a possibility of someone activating their offensive mode and start saying things like "you call THAT an Expert mode? What ridiculous/presumptuous/pedantic/preposterous programmer you are! An Expert mode should have <this or that>, and never <this or that>!"

Anyway, the Expert/Generic mode is indeed meant to debug hardware. It's meant for those who built their joysticks themselves, and want to see if there's some miswiring. It also serves for those who aren't experts, but can take a picture or video of the screen and post on a forum to get some expert help. Any expert will be able to quickly identify what's wrong with the joystick from that simple screen.

It's also "Generic 2-byte" mode because only the two basic rows are read. Yes, there are many other different protocols and ways to transmit buttons, but then they send much more data than just 2 bytes/rows via specific (IOW, non-Generic) protocols and are out of the scope of this mode.

Quote:

Then Row 0 and 1 seem to be inverted when /G is specified. (Row 1 is optional, moreover nothing prevents adding rows by using external chip.)

This is weird. The following screenshot shows what I get by pressing UP+Button1 on a standard MSX joystick. Why do you think the rows are inverted? The row number is represented by the value of the Output pin. And I'm representing the rows in the same ascending order that we're used with the keyboard matrix.

gdx wrote:
HIDTEST screen wrote:

Note: if you get spurious detections, your joystick might not be wired according to the MSX specification.

I think the sentence below is more appropriate because the MSX specification does not forbid using GND instead of STROBE to make special controllers. The standard wanted to be open about it and that is why these ports are called "General Purpose Ports".

Maybe the problem here is semantics. The specification is very clear on how a standard MSX joystick must be wired:

This means that anything different than that isn't wired according to the MSX specification, period. Yes, I agree that they can be freely connected to the General Purpose Ports (sometimes with an adapter in the middle), but that doesn't make them standard and they won't behave perfectly like one. This is the case of Megadrive controllers, FM-Towns controllers and so on. They'll only be compatible to a certain degree, and any programmer has to keep these restrictions in mind.

Quote:

if you get parasitic detections, the wiring may be incorrect or the controller is not generic.

Bingo! And agreed. And within the screen space restrictions, that's exactly what the Generic mode screen says, isn't it? :)
It's further detailed on the TXT manual.

By sd_snatcher

Prophet (3645)

sd_snatcher's picture

11-02-2020, 16:27

I must say I had a good laugh with the "joystick simulator" used to illustrate this article. I've never heard of that weird device. Did it really work, or was just a gimmick? I'm under the impression that it wan't exactly great to play with that thing. Big smile

Does it support 2 buttons, or just one?

By hamlet

Scribe (4105)

hamlet's picture

11-02-2020, 18:03

I bought it on the Nimega fair last week, so it comes just in time for your news post.
After cleaning it it works nice. Well, not for gaming of course. Feels like playing an IOS game on an virtual joystick.
Suncom did a lot of experimental joysticks for the VCS, they all had only one button.
But it uses a selector for 8 or 4 way direction.
I really like the TAC2, which don't use switches, just a metal ball.
Glad you like it!

By gdx

Enlighted (6103)

gdx's picture

12-02-2020, 02:00

sd_snatcher wrote:

Maybe the problem here is semantics. The specification is very clear on how a standard MSX joystick must be wired:

The diagrams given in the MSX datapack are basic diagrams for generic controllers (joystick, mice, paddles, etc). Standard also says joystick can have one or two buttons (type A or type B controller). It does not say that we cannot do otherwise.
For example the FM-Towns controllers are made in a slightly different way but are 100% compatible and all those who sold them indicated "compatible FM-Towns, MSX, X68000, etc" (except Fujitsu because it was not in their interest).
In addition nothing is said about "MSXHID". So better not be so categorical.

sd_snatcher wrote:

Why do you think the rows are inverted?

As it is now, row 0 is to access specific buttons, etc, and the row 1 is to access standard joystick. Don't you find it weird?

By sd_snatcher

Prophet (3645)

sd_snatcher's picture

19-02-2020, 19:14

gdx wrote:
sd_snatcher wrote:

Why do you think the rows are inverted?

As it is now, row 0 is to access specific buttons, etc, and the row 1 is to access standard joystick. Don't you find it weird?

Are you sure of that? Because, as the screenshot shows, button-1 and UP are being pressed and they are shown on row-0.

By gdx

Enlighted (6103)

gdx's picture

20-02-2020, 11:53

OK, I understood. It is reversed when I use the JoySNES in Extra mode. In this mode the pin 8 status is probably taken into account with a little delay. It also tried with an MSX joypad and its ok, and with an FM-Towns joypad both react at the same time.

gdx wrote:

I tried it on real Turbo R and it doesn't quit properly when I press ESC.

This bug is annoying.

By Emily82

Resident (46)

Emily82's picture

26-02-2020, 02:41

Guys the standard schematics should be pin9 (GND) used as ground and not pin8 that is not granted to be at 0V. I know there are compatible joysticks working with pin8 as ground but it should be pin9 the only ground to be used.

By sd_snatcher

Prophet (3645)

sd_snatcher's picture

26-02-2020, 04:19

Quote:

Guys the standard schematics should be pin9 (GND) used as ground

Nope. The pin-8 must be the common pin. This is the official schematic for the joystick:

You can check it on the following official documentation:

  • MSX Turbo-R Datapack Vol.1, pg-20
  • MSX Technical Handbook, pg-27

You can also confirm it on the online version of the MSX Datapack.

It was done this way by design. The pin-8 acts as an enable/disable pin for the MSX-joystick.

By Emily82

Resident (46)

Emily82's picture

26-02-2020, 05:49

Ah ok so putting "high" the pin8 it could be possible to disable mouse / joystick from software?

By sd_snatcher

Prophet (3645)

sd_snatcher's picture

26-02-2020, 06:51

Emily82 wrote:

Ah ok so putting "high" the pin8 it could be possible to disable mouse / joystick from software?

This is the case for the joystick, but not the mouse. The "joystick ports" are in fact officially named General Purpose I/O Interfaces on the MSX Datapack.

This means that its pins will have different functions depending on the device and protocol connected to them.

In the case of the mouse, the pin-8 is used to clock the communication with the device. Check more about it here.

For the MSX-Touchpad, the pin-8 is used as a /CS (chip select) for the uPD7001 A/D converter. In this case it can be said it's similar to the joystick.

For the MSX-Paddles, the pin-8 is used to trigger the PWM pulse sent by the device.

For the Vaus Arkanoid Paddle, the pin-8 is used to trigger a new internal counting session.

And so on... The list is long. :)

By Emily82

Resident (46)

Emily82's picture

26-02-2020, 06:49

Now for fun i quickly took a breadboard, some female-male arduino cables, a small pushbutton.

I connected the cables to the pin 6 of and 8 of my msx so that if i push the button they are connected.
Wrote 2 lines of basic code and .. it works perfectly! EHEHEH

Im thinking to make my own joystick for msx Tongue cause the old original one is broken without any hope to repair (the axis is very defective)

By sd_snatcher

Prophet (3645)

sd_snatcher's picture

26-02-2020, 07:30

Nice!

Here goes a tip: since you're going to use an Arduino, it's easy to go wild and support both digital and analog joystick protocols. For example, it could be:

1) Digital
- joyMega: Many games were patched to support this.

2) Analog
- PWM mode is useful because it can be read from the MSX-BASIC. You can pick either joyDA15 or the dual-Analog joystick. These will also work with the recent Galaga patch, but keep in mind that it's hard to play paddle games with an analog controller
- The Micomsoft XE-1AP supported the MSX. But the real thing is horribly expensive, hard to find and has a somewhat clumsy design.
- The Sega Saturn "3D" analog controller has a very powerful protocol, and is quicker to transmit than the previous two. And the real controllers aren't that expensive and it wouldn't be hard for games to support the real thing and homebrew versions. The protocol is described on the Sega SMPC User's Manual. But always remember that, just like the joyMega, the state of the pin-8 is inverted on the MSX.

When changing from one controller type to another, you must simulate a disconnection. This means leaving all pins in high state for some time.

By gdx

Enlighted (6103)

gdx's picture

26-02-2020, 09:16

Note that at that time several Japanese computers used the same (or very close) connectors and sometimes the GND was used instead of pin 8. FM-Towns did this to be able to add two buttons without using an additional chip.

By sd_snatcher

Prophet (3645)

sd_snatcher's picture

26-02-2020, 15:32

Quote:

FM-Towns did this to be able to add two buttons without using an additional chip.

If you connect the common pin of the FM-Towns controller to the pin-8 of the MSX, it works exactly the same, but solves the collision/mirroring problem. So that's not the case.

Fujitsu simply have shown no worries to comply to the MSX specification when they connected the common pin of their joystick to the pin-9/GND.

That design decision came to hunt them later. It's not possible to easily differentiate between their 6+2button controller from their 2+2button controller without pressing any buttons. And if you connect a standard MSX joysticks to the FM-Towns, it won't work with games that don't care about the pin-8 state like MSX software do.

In a nutshell, the FM-Towns controller is proprietary, and while there is some interoperability, the compatibility between the two standards isn't 100%. Not even Fujitsu claims MSX compatibilty.

By gdx

Enlighted (6103)

gdx's picture

27-02-2020, 02:06

sd_snatcher wrote:

If you connect the common pin of the FM-Towns controller to the pin-8 of the MSX, it works exactly the same, but solves the collision/mirroring problem. So that's not the case.

I never tried because someone who had tried said it doesn't work. I will test myself ...

sd_snatcher wrote:

Fujitsu simply have shown no worries to comply to the MSX specification when they connected the common pin of their joystick to the pin-9/GND.

That design decision came to hunt them later. It's not possible to easily differentiate between their 6+2button controller from their 2+2button controller without pressing any buttons.

It's the same for MSX controllers. Only the controllers that use pin 8 for extra function will send something that will depend on the hardware design, but one thing is certain: this data is not an official means of detection. It's just a tip.

sd_snatcher wrote:

And if you connect a standard MSX joysticks to the FM-Towns, it won't work with games that don't care about the pin-8 state like MSX software do.

I believe I saw in the developer manual that pin 8 is high by default on FM-Towns. If this is the case, it is normal because developers don't have to take care of pin-8 state for generic controllers. This does not interfere with the compatibility of FM-Towns classic joypad with MSX.

sd_snatcher wrote:

In a nutshell, the FM-Towns controller is proprietary, and while there is some interoperability, the compatibility between the two standards isn't 100%. Not even Fujitsu claims MSX compatibilty.

No, if Fujitsu doesn't claim the MSX compatibility it is for another reason.
Controllers for NEC PC-6001 and Sharp x68000, etc are fully MSX compatible (pin 8 is used) but NEC nor Sharp claim the MSX compatibility.

http://www.lcv.ne.jp/~mgs1987/gimic2c/x68ver2z1.html

But other accessories brands that sold them indicate the compatibility. The reason is just that the goal is different. It's just marketing.

All of these controllers can work on MSX.
https://ameblo.jp/koorogiyousyoku/entry-11518989201.html

By sd_snatcher

Prophet (3645)

sd_snatcher's picture

28-02-2020, 15:17

gdx wrote:

This bug is annoying.

Do you want to help with some testing? Try to run the following BASIC program with those file managers you use:

10 SC=PEEK(&HFCAF):WD=PEEK(&HF3AF)
20 SCREEN1:WIDTH32
30 ?”Test. Press any key to exit.”:A$=INPUT$(1)
40 SCREEN SC:IF SC=1 THEN WITDH WD

By gdx

Enlighted (6103)

gdx's picture

28-02-2020, 15:59

This goes into SCREEN0 mode in 80 columns with no issue. Even if I go to the DOS then run MM or M afterwards.