Joystick Port

So, this is what that remark really meant. Someone has shown me this many years ago, IIRC when HIDtest was still called joyTest and I implemented the first version of the detection algorithm based on what I learned from the HAL (and many others) codes.

There was no OCRed version back then, and our smartphones still couldn't read texts from images on the fly.

The guy used a screenshot of this page as an argument to state that Fujitsu designed the port to be "MSX compatible". Since I couldn't read Japanese, I took the statement at face value.

Anyway, so Fujitsu seems to be innocent on this case and it was just another troll pestering me that I shouldn't have done this/that and more blablablablah ranting about joyTest.

Your tests confirmed what I knew: when Fujitsu decided to connect the common pin of their joystick to the GND pin, they have shot themselves in the foot, and this decision came to haunt them later: the joystick support has become the babel you've seen, and even the support for their 6button joypad is somewhat problematic.

This is one of the reasons I'm reluctant to this "let's normalize the GND as common pin on the MSX too" idea. The MSX was simply better designed on this aspect. Sadly, I only see people bashing the problems/restrictions of the MSX, but rarely praising its fortes, even the minor ones.

But at least on the MSX side, the Fujitsu pad compatibility on MSX-HID is now behind us, since I implemented the compatibility mode for their pads, and this allowed even the rare/expensive 6-button controller to be supported.

Since you're a nice guy, let me try to do the opposite too: workaround the FM-Towns joystick babel for you on the joyMega adapter. If you can, please modify your joyMega and test if this works. Some games will require the SW1 to be on 1-2 (inverted) position, and others will require it to be on the 2-3 position (direct). If you get incorrect button mapping on a game, just try the switch on the other position.

If this works, I'll add this switch to the next revision of the joyMega. It will be optional for the MSX, but it can be installed for someone willing to use it on the FM-Towns (and probably X68K too).

But be aware that the games that only support the FM-Towns own 6-button controller won't work with this simple modification. They require a different approach: either a fully modified Mega Drive controller, or a more expensive MCU based adapter.

It must be sufficient only for games that support MSX 2-button joypads, and Mega drive joypads (like SF2).

I don't understand why you are focused on the FM-Towns joystick ports. No one says it's 100% same as the MSX ones, and as I said before not even Fujitsu.

Moreover, what you say about the FM-Towns Technical Hand book is wrong. Everything is well explained and in detail and with diagram. There is even a note for the use of MSX joysticks. It's just that you don't understand much about it. Otherwise, you would have understood that pin 8 does not always work the same as on MSX. This pin is always an output on MSX but not on FM-Towns. It is thanks to this that the additional button that there is on the Marty console works. And that's why this controller can't work on MSX (as indicated on the corresponding wiki page). Fujitsu decided to connect the common pin of their joystick to the GND pin just for this reason.

Why are you digging around all to absolutely make sure that the protocol you called MSX-HID is perceived as standard? Is it so important? Looks like your honor is at stake.

Pentarou, we are the kings of spammer? Please explain why you say it!

You can say what you want but even if the basic FM-Towns controllers are not 100% standard (and I never said otherwise about Run and select buttons), they are usable on MSX. It's not ideal for all uses, but it can help in the majority of cases.

No problem. Take your time.

Yes, this is true. I remember @l_oliveira talked many times about that subtle difference. Thankfully it's easy to workaround.

Why I say it is a new standard? Because as a standard, it is new indeed... As a mean used by some manufacturers to find out what is plugged to the joystick port, not new at all, when someone worked on compiling all known devices that use that method or work with that method, documented it, created all information needed to anyone t add new devices without clashing with existing ones, it became a new standard. Becoming a standard doesn't mean that it is official, and even if it was official (which it is not) doesn't mean everyone shod adhere to it, even official MSX standard rules, we have software and hardware that follows it, and ones that doesn't... Example of hardware, joysticks that are meant for msx but use ground instead of pin 8,example of software, direct access to hardware that the standard says shouldn't be accessed directly...

Just because it is not something compiled by ASCII, or other official entity while MSX was kicking and alive, doesn't mean the idea is not good and can't be seen as a new standard, and old hardware that functions that way exists to prove the idea is good,easy way to detect devices, if more devices come on-board with the idea that started with the observation of how some old hardware worked to be detected and a common method among those, everyone benefits from easy detection support that has a minimal foot print in the program.

Regarding the usage of that method in the bios, I think the author said BIOS has routines for mouse or trackball detection, to distinguish which is plugged and is done through this approach or similar, did not check it personally (and if the author didn't said it, sorry for my memory playing tricks on me, sometimes it happens)

Why bad faith? The list of devices that can be actually identified by this method (MSX centric and non-msx centric but adapted somehow) is crystal clear... You can distinguish quite a lot of devices. FRS devised a way to use this information and easily detect current devices and create new devices...

I think a better question is, how many MSX hardware that goes through the joystick port can't be detected by such proposed standard? For sure there are some, but I really have a hard time to think of many that are used for Human Input that can't be detected through it.

And again, I still think you are stuck with the idea that a standard needs to be something that existed since inception of the platform, which I absolutely disagree and I don't think anyone is trying to sell this as a standard that creators of hardware from the 80's were using and somehow it was hidden from the general public... You can create a standard later, that encompasses all or most of the devices and propose a way to add new devices to be detected in the same manner if such new standard is followed. This surely is not the first time someone made such approach of creating an standard based on observation of how many different people used the same idea to solve a problem. Call it luck coincidence, engineers copying designs, etc... But for sure quite a few manufacturers from that era used the approach of using selection pin (MSX PIN 8) set to it's alternate state (VCC in case of MSX) and reading un-usual values for the input pins when in such state. FRS compiled the list of existing devices that do that, the ones that you can detect in such way, provided a library for easy detection, a way for people to add new devices they create... That, for me, counts as a new standard. If you don't agree, then I think it is time we agree to disagree