The feedback loop of the original circuit allows two outputs to be active at the same time pushing opposite logical levels and requires one to win, which is essentially a bad design. No surprise that the logical family (74ACT) is being a critical issue.
Worth to mention that there is a possibility of burning the internal logic gate without noticeable effects, because the trigger lines are being used almost all the time as inputs.
To avoid such hardware "race condition" to occur on the existing hardware the best option is to patch the software, to allow pin 7 to float all the time.
Now, answering your question, I am using the same components as the original circuit. I am just wiring them properly this time, lol!!!!
So you have modified both the hardware and the driver.
But then, does :
- Your modified hardware compatible with the original driver?
- The original hardware compatible with your modified driver?
So you have modified both the hardware and the driver.
But then, does :
- Your modified hardware compatible with the original driver?
It depends of what is the original driver. If the commented code of the DM System 2 source, is the original code, then either hardware will be compatible. But DM System 2 driver will work only on original Ninja Tap (but only if the chip inside original hardware is able to fight and win the battle against the chip inside msx trying to pull down the voltage on the line).
This "short circuit" can be avoided just by patching three bytes I have pointed in the detection routine some posts ago.
The "read data" routine does not have the contention issue.
Quote:
- The original hardware compatible with your modified driver?
Sure! I can not even say I have written a new driver. I just proposed a new detection routine to allow the Shinobi Tap to be differentiated from the Ninja Tap.
Can you show us the full corrected diagram for Ninja Tap to put it on the wiki page?
For the wiki page surely the original circuit schematics, as drawn by Jipe based on real hardware
And the hardware fix for the circuit, considering that the MSXs have internal pullup resistors on joystick pins, is simply invert diode D1 and remove resistor R1.
Softwarewise everything is fine. Pin 7 will present the inverse level of the state of pin 8. That is what the DM system 2 driver "connection check subroutine" expects, and it looks like this is what is being expected in Ninjatap.cc code.
Hardwarewise, I still don't know if I've been quite clear describing the problem, but I have bumped this topic just because of such oddity found while reading the source code of DM system 2 driver. I do strongly recommend to patch the DMS2 driver (and derivation programs) to keep bits 1 and 3 of PSG in HIGH state during "connection check subroutine" for the sake of internal circuitry of the MSX port.
openMSX emulation of Ninjatap should be fixed in the latest development build. Can you confirm?
My NinjaTap sample works fine on OpenMSX 18.0-92 (both detection and data reading).
Thank for the quick fix.
The only problem is I can't test the use of 2 NinjaTap because of plug command restriction: ninjatap device can only be plugged on joyporta or joyportb but not both.
