i have replace the 74ACT00 by a 74AC00 and the ninja tap work fine
https://msxvillage.fr/upload/ninja_tap_proto.png
i redraw the schematic with players in order
https://msxvillage.fr/upload/ninja_tap_by_jipe.png
i have testing with magical labyrinth remix and i have 4 players :)
@aoineko, it looks like your s_ntap test program check for the presence of Ninja Tap only once at the beginning. Is it correct? (not in the sense that is right or wrong, lol, this is just to know if I understood the disassembly of the code correctly.
This is the case. You can press 'R' to rescan the ports for Ninja Tap detection.
If you prefer look directly at the code source it's available on MSXgl's GitHub:
- The driver I use (DM-System 2 driver convert to sdasz80 assembler): https://github.com/aoineko-fr/MSXgl/blob/main/engine/src/dev...
- The C wrapper for MSXgl: https://github.com/aoineko-fr/MSXgl/blob/main/engine/src/dev...
- And the sample source: https://github.com/aoineko-fr/MSXgl/blob/main/projects/sampl...
.
This is the case. You can press 'R' to rescan the ports for Ninja Tap detection.
If you prefer look directly at the code source it's available on MSXgl's GitHub:
- The driver I use (DM-System 2 driver convert to sdasz80 assembler): https://github.com/aoineko-fr/MSXgl/blob/main/engine/src/dev...
- The C wrapper for MSXgl: https://github.com/aoineko-fr/MSXgl/blob/main/engine/src/dev...
- And the sample source: https://github.com/aoineko-fr/MSXgl/blob/main/projects/samples/s_ntap.c
Thank you !
I have finally started to make some experiments with hardware and that will be very useful!
If you need something else, just tell me.
For example, I can add your version of the driver as an alternative in MSXgl.
Today I did some experiments with the circuit . I don't have one ACT chip, unfortunately, only got my hands on a 74'00 from HC, HCT and LS families. also used s_ntap. The Setup is a HotBit HB8000 .
As predicted, neither one of the three chips is beefy enough to win the fight against the open collector gate inside the MSX, and because of that the software can not "see" on pin 7 the inverted output from the signal on pin 8.
Then I patched the software changing the three bytes I mentioned in a previous post.
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 .... ....
With the patched software running, success!!
I repeated the test with all the chip families I have here (HC, HCT and LS). All were able to work in the circuit. Speaking of that, with the patch, both Ninja Tap and Shinobi Tap feedback circuit worked, nevertheless the small differences.
Next time I had available I should test the alternative detection routines I wrote for Shinobi tap and test with my famiclone controllers.
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:
7 6 5 4 3 2 1 0 │ │ │ │ └───┴───┴───┴── Number of joystick ports available (2, 5 or 8) │ │ └───┴────────────────── Tap type pluged in port 1 (0=No Tap, 1=Ninja Tap, 2=Shinobi Tap) └───┴────────────────────────── Tap type pluged in port 2 (0=No Tap, 1=Ninja Tap, 2=Shinobi Tap)
If you can change your detection routine to fit this format, it would be perfect.
Easy, Change the table to
TBPLRS: db 0A8h,068h,0E5h,025h,098h,058h,0D5h,015h,0B5h,075h,0F2h,032h,085h,045h,0C2h,002h
I have updated the MSXgl sample program (same address: https://github.com/aoineko-fr/MSXgl/raw/main/projects/sample...) with 3 drivers that you can choose with the 'D' key:
- DM-System2 (the "original" driver by Gigamix)
- MSXgl (a WIP rewrite of the driver for ease of use)
- Shinobi (Danjovic driver)
For the 'Shinobi' driver, the type of Tap found is displayed.
In OpenMSX, this driver reacts strangely and only gives the right result if another driver has been called before. Furthermore, it detects the virtual Ninja Tap device as a Shinobi Tap.
Let's see with the real hardware what happens.