---------------Circuit---------------------
Driver Orig. Orig+fix Shinobi unknwon None
DMs n.d. n.d. n.d. n.d. n.d.
MGl n.d. n.d. n.d. n.d. n.d.
Shi Ninja Ninja Shinobi Shinobi n.d.
The detection works for both Joystick Ports
But I have to check the code again as the Unknown type device is being detected as a Shinobi.
Found the error, I was not pulling pin 6 down to perform the detection. It was observed also on the oscilloscope.
The corrections are shown below. Full detection code is on github.
CKANYTAP: di ; ld c,0 ; ; port A ld de,0ba3ah ; (HERE) start with Joysel port A, pins 8=1, 7=1, 6=0 (read a1) call FBCHECK ; return Cy = State of pin 7 rl c ; c = 0 0 0 0 0 0 0 a1 ld de,08f0fh ; repeat with Joysel port A, pins 8=0, 7=1, 6=1 (read a0) call FBCHECK ; feedback check at pin 7 rl c ; c = 0 0 0 0 0 0 a1 a0 ; port b ld de,0ba7ah ; (HERE) repeat with Joysel port B, pins 8=1, 7=1, 6=0 (read b1) call FBCHECK ; return Cy = State of pin 7 rl c ; c = 0 0 0 0 0 a1 a0 b1 ld de,08f4fh ; repeat with Joysel port B, pins 8=0, 7=1, 6=1 (read b0) call FBCHECK ; feedback check at pin 7 rl c ; c = 0 0 0 0 a1 a0 b1 b0 ret ; and B = B+1
EDIT: Patched the last s_ntap rom and it works now, detecting the unknown device.
---------------Circuit---------------------
Driver Orig. Orig+fix Shinobi unknwon None
DMs n.d. n.d. n.d. n.d. n.d.
MGl n.d. n.d. n.d. n.d. n.d.
Shi Ninja Ninja Shinobi Unknow n.d.
I updated the shinobi driver with your new code from Github but I still have the same behavior under OpenMSX:
- Ninja Tap device is detected as Shinobi Tap,
- Detection is only correct if I make a detection with another driver first.
Don't know for real hardware.
I added your driver as a file "ninjatap_st.asm" (see https://github.com/aoineko-fr/MSXgl/tree/main/engine/src/device)
I updated the shinobi driver with your new code from Github but I still have the same behavior under OpenMSX:
- Ninja Tap device is detected as Shinobi Tap,
- Detection is only correct if I make a detection with another driver first.
It might be related with past states of the emulated PSG registers
Don't know for real hardware.
It works with both shinobi tap and ninja tap circuitry I have breadboarded.
On the real hardware, the state of the register 14 reading for pins 6,7 depends upon the state of the corresponding bits on register 15.
reg14_TRG_A = joystick_TRG_A_state & reg15_TRG_A reg14_TRG_B = joystick_TRG_B_state & reg15_TRG_B
Which means that if the bit from Register 15 trigger button is LOW, the Register 14 corresponding bit state will always read LOW.
This is because of the open collector gates at the trigger lines of the joystick port, that will tie the line to GND when the corresponding bit of register 15 is low.
On the other hand, if such bit is High, the open collector gates are in high impedance and the level of the line is weakly pulled HIGH by a resitor but can be freely changed LOW or HIGH by an external signal (for instance a switch to ground, or the output from aother chip).
The original Ninja Tap circuit uses a feedback from pin 8 to pin 7, but the way it was wired was not good because it allows a bus contention to occur, in other words it makes possible to happen a situation where two outputs are connected to the same pin, active at the same time but with opposite logic levels - a short circuit . That is the reason why the logic family of the chip used on the Ninja Tap is critical.
The creators of the interface probably realized that, as pointed by the remainings of original code (commented lines inside DM System 2 driver source) which keep pin7 floating all the time. But sometime such information was lost and the DM System 2 drivers hold pin7 on ground during detection, causing a brief "short circuit" that - by chance or by purpose - the ACT family can win. It doesn't change the fact that this is still a bad condition and thus be avoided.
@aoineko, if you allow me to suggest, I would recommend you to change that 3 values of the bytes of your driver, to make pin 7 float during detection. The original Ninja Tap will still work, but will avoid the "short circuits" to occur
@Manuel, for the OpenMSX I still haven't read the source code deeply enough to propose a code change, but if you allow me to suggest, the following logic might solve the issues with Ninja Tap detection
reg14_TRG_B = joystick_TRG_B_state & ( reg15_TRG_B | NinjaTapConnected)
CKNTAP: di ld b, #0 ; b=Max Player ld de, #0xBF0A ;#0xBF00 <-Here call CHECK ; Port1 Check ld c, a ld e, #0x4A ; #0x40 <-Here call CHECK ; Port2 Check rlca or c .... .... CHECK: call PORSEL inc b and #0xCA ; #0xC0 <-Here out (0xA1), a ; 6,8=L 7=H ex af, af' ;' ld a, #14 out (0xA0), a in a, (0xA2) and #0x20 ; 7=H ? ret z .... ....
I tried this patch but it don't work (at least in MSXgl).
Ninja Tap is not detected any more.
Did not work anymore in real hardware ?
I don't have any Ninja Tap hardware so all my testing is done on OpenMSX.
Jipe is kindly checking on real hardware (an original Ninja Tap and a DIY clone) but I didn't put this patched driver version on GitHub so there was no testing on emulator.
I will take a look at the openMSX code to see if I can suggest something.
At the moment I am testing the Shinobi Tap on the breadboard, and it is working nicely. I should build a prototype soon.
Well It looks to me that in Ninjatap.cc code the state of pin 7 is being inverted only when pin 8 is HIGH, but pin 7 should always be the inverse level of pin 8, because the detection routine checks the response to both states of pin 8.
In practice just take out the "else"
...
} //(HERE) else {
// pin 7 = 0 : detect mode, b5 is inverse of pin8
// TODO what happens with other bits?
// Pin 7 always present the inverse value of pin 8
if (value & 4) { // is Pin 8 High?
status &= ~0x20; // then set pin 7 low
} else {
status |= 0x20; // otherwise set pin 7 high
}
//} (HERE)
It should be suffice to make it work with the patched driver, because on MSXPSG.cc the MSXPSG::readA function ANDs the values of pins 6 and 7 with the values of the outputs corresponding to bits 0,1 or 2,3 for either joystick port A or port B.
well this part of code is now commented because of Ninja Tap compatibility, but a workaround could be something like this:
// pin 6,7 input is ANDed with pin 6,7 output
byte pin67 = prev << (4 - 2 * selectedPort);
byte mask = ntap ? 0xef : 0xcf;
joystick &= (pin67| mask );
Note: assuming 'ntap' is a boolean variable to have the state of the ntap connection and it can be made visible from the scope of the MSXPSG::readA function.
