I'll add to MSXgl's sample the 3 detection methods: DM-System2 original, your patched version and your custom detection routine.
I have changed the value return by the C wrapper to put all detection information in 1 byte:
│ │ └───┴────────────────── Tap type pluged in port 1 (0=No Tap, 1=Ninja Tap, 2=Shinobi Tap)
If you can change your detection routine to fit this format, it would be perfect.
From the software point of view, is there any relevant functional difference between the Ninja and Shinobi taps to justify the extra memory used to differentiate between the two? Or can they be treated just as two different+equivalent implementations of the same device?
There is no wasted space here as this is the same byte used to detect the presence of Ninja Tap.
Danjovic seems to want to exploit the 2 extra bits sent back by the Ninja Tap to support pads with 4 buttons. That's the point of differentiating the Shinobi Tap from the original hardware.
[
From the software point of view, is there any relevant functional difference between the Ninja and Shinobi taps to justify the extra memory used to differentiate between the two? Or can they be treated just as two different+equivalent implementations of the same device?
My detection code takes 3 bytes more than the original detection code.
@Danjovic
Yes, definitely the original designs has some flaws in the detection part. Ideally, the fix of having the R1 removed and the D1 inverted should be published (maybe on the MSX-Wiki?).
And only now after looking at Jipe's redrawn circuit I noticed that the R1 is a pull-down resistor, not pull-up. It's such an absurd that my brain had just filtered that possibility out. This makes things even worse, as R1 acts as a voltage divider with the MSX internal pull-up, whose value is not standardized. So, depending on the machine, the resulting voltage might fall anywhere, even the uncertain area between ViH and ViL.
There is no wasted space here as this is the same byte used to detect the presence of Ninja Tap.
Danjovic seems to want to exploit the 2 extra bits sent back by the Ninja Tap to support pads with 4 buttons. That's the point of differentiating the Shinobi Tap from the original hardware.
That's the point: this will be extra code ahead too. Why couldn't the software just support the two extra buttons on both designs? They just won't ever be reported as pressed on the original Ninja tap.
The 2 extra bits are in the middle of the 6 basic bits (direction and two buttons) so in any case they are read (see page 1 of this thread). Only the detection code differs. There is no impact on the RAM and the difference in size of the code seems to me completely insignificant (we are talking about a few bytes).
The most obvious advantage of knowing whether the device supports 4-button controllers or not, is to adapt the code of a game to the number of buttons. For example, in my tennis game Final Smash I use 3 types of shots: button A, button B and button A+B. With a Ninja Tap device that supports 4 button controllers, I could replace the A+B with the 3rd button.
This possibility is worth a few extra bytes in a library like MSXgl which is meant to be general-purpose. Especially since the programmer can choose independently which drivers he wants to use in his program (the Gigamix driver, my custom driver and/or the Shinobi Tap driver).
Then maybe it's better to let the decoding of Fujitsu-style SELECT/RUN buttons to the software on the Ninja tap? Otherwise it will not be possible to know witch controllers have 4 buttons or not on the original Ninja tap.
