About Peripherals

For anything related to IO (joypad, serial, XE...)

Moderator: BigEvilCorporation

Eke
Very interested
Posts: 830
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Wed Jul 04, 2007 10:10 am

I have now partial Menacer support (enough to play the crappy 6-in-1 game, which seems to be the only lightgun game that does not also support gamepads) and complete 4-WayPlay/Teamplay support... thanks again for the links you gave me

I am now looking into J-Cart support... I imagine that the additional IO ports are mapped to some adddress in the 68K memory space.
Has anyone managed to understand how this was working or already looked into games supporting this (Pete Sampras tennis, Micromachines serie) ?

User avatar
TmEE co.(TM)
Very interested
Posts: 2321
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Wed Jul 04, 2007 1:06 pm

Give me the schematic, and I'll figure out how it works.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Eke
Very interested
Posts: 830
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Thu Jul 05, 2007 10:03 am

:? those kind of schematics does not seem to be available online
btw, opening a j-cart seems not possible without breaking anything

I made some disassembling using IDA and Pete Sampras' rom:
here is one of the routines that (I think) is used to detect/initialize the gamepads:
sub_63E: ; CODE XREF: main+216p
ROM:0000063E movea.l #$A1000B,a0
ROM:00000644 lea -6(a0),a1
ROM:00000648 move.b #$40,(a0) ; '@'
ROM:0000064C move.b #0,(a1)
ROM:00000650 nop
ROM:00000652 nop
ROM:00000654 nop
ROM:00000656 move.b (a1),d0
ROM:00000658 rol.w #2,d0
ROM:0000065A andi.b #$C0,d0
ROM:0000065E move.b #$40,(a0) ; '@'
ROM:00000662 move.b #$40,(a1) ; '@'
ROM:00000666 nop
ROM:00000668 nop
ROM:0000066A nop
ROM:0000066C move.b (a1),d1
ROM:0000066E andi.b #$3F,d1 ; '?'
ROM:00000672 or.b d1,d0
ROM:00000674 beq.w loc_6D6
ROM:00000678 move.w #1,$5F0E(a5)
ROM:0000067E move.w #0,(unk_3FFFFE).l
ROM:00000686 move.w (unk_3FFFFE).l,d0
ROM:0000068C andi.w #$40,d0 ; '@'
ROM:00000690 bne.s loc_6D0
ROM:00000692 move.w #$FFFF,(unk_3FFFFE).l
ROM:0000069A move.w (unk_3FFFFE).l,d0
ROM:000006A0 andi.w #$40,d0 ; '@'
ROM:000006A4 beq.s loc_6D0
ROM:000006A6 move.w #0,(unk_3FFFFE).l
ROM:000006AE move.w (unk_3FFFFE).l,d0
ROM:000006B4 andi.w #$40,d0 ; '@'
ROM:000006B8 bne.s loc_6D0
ROM:000006BA move.w #$FFFF,(unk_3FFFFE).l
ROM:000006C2 move.w (unk_3FFFFE).l,d0
ROM:000006C8 andi.w #$40,d0 ; '@'
ROM:000006CC beq.s loc_6D0
ROM:000006CE rts
ROM:000006D0 ; ---------------------------------------------------------------------------
ROM:000006D0
ROM:000006D0 loc_6D0: ; CODE XREF: sub_63E+52j
ROM:000006D0 ; sub_63E+66j ...
ROM:000006D0 clr.w $5F0E(a5)
ROM:000006D4 rts
ROM:000006D6 ; ---------------------------------------------------------------------------
ROM:000006D6
ROM:000006D6 loc_6D6: ; CODE XREF: sub_63E+36j
ROM:000006D6 move.w #$FF0,d3
ROM:000006DA clr.w d2
ROM:000006DC bsr.s sub_6E4
ROM:000006DE move.w #$F,d3
ROM:000006E2 moveq #8,d2
ROM:000006E2 ; End of function sub_63E
ROM:000006E2
sub_6E4: ; CODE XREF: sub_63E+9Ep
ROM:000006E4 moveq #$10,d4
ROM:000006E6
ROM:000006E6 loc_6E6: ; CODE XREF: sub_6E4+28j
ROM:000006E6 move.w #0,(unk_3FFFFE).l
ROM:000006EE move.w #$FFFF,(unk_3FFFFE).l
ROM:000006F6 move.w (unk_3FFFFE).l,d1
ROM:000006FC not.w d1
ROM:000006FE ror.l d2,d1
ROM:00000700 andi.w #$3F,d1 ; '?'
ROM:00000704 cmpi.w #1,d1
ROM:00000708 beq.w loc_714
ROM:0000070C dbf d4,loc_6E6
ROM:00000710 bra.w loc_7DC
ROM:00000714 ; ---------------------------------------------------------------------------
ROM:00000714
ROM:00000714 loc_714: ; CODE XREF: sub_6E4+24j
ROM:00000714 move.w #$FFFF,(unk_3FFFFE).l
ROM:0000071C move.w #0,(unk_3FFFFE).l
ROM:00000724 move.w #$FFFF,(unk_3FFFFE).l
ROM:0000072C move.w (unk_3FFFFE).l,d1
ROM:00000732 not.w d1
ROM:00000734 ror.l d2,d1
ROM:00000736 andi.w #$3F,d1 ; '?'
ROM:0000073A cmpi.w #2,d1
ROM:0000073E bne.w loc_7DC
ROM:00000742 move.w #0,(unk_3FFFFE).l
ROM:0000074A move.w #$FFFF,(unk_3FFFFE).l
ROM:00000752 move.w (unk_3FFFFE).l,d1
ROM:00000758 not.w d1
ROM:0000075A ror.l d2,d1
ROM:0000075C andi.w #$3F,d1 ; '?'
ROM:00000760 cmpi.w #4,d1
ROM:00000764 bne.w loc_7DC
ROM:00000768 move.w #0,(unk_3FFFFE).l
ROM:00000770 move.w #$FFFF,(unk_3FFFFE).l
ROM:00000778 move.w (unk_3FFFFE).l,d1
ROM:0000077E not.w d1
ROM:00000780 ror.l d2,d1
ROM:00000782 andi.w #$3F,d1 ; '?'
ROM:00000786 cmpi.w #8,d1
ROM:0000078A bne.w loc_7DC
ROM:0000078E move.w #0,(unk_3FFFFE).l
ROM:00000796 move.w #$FFFF,(unk_3FFFFE).l
ROM:0000079E move.w (unk_3FFFFE).l,d1
ROM:000007A4 not.w d1
ROM:000007A6 ror.l d2,d1
ROM:000007A8 andi.w #$3F,d1 ; '?'
ROM:000007AC cmpi.w #$10,d1
ROM:000007B0 bne.w loc_7DC
ROM:000007B4 move.w #0,(unk_3FFFFE).l
ROM:000007BC move.w #$FFFF,(unk_3FFFFE).l
ROM:000007C4 move.w (unk_3FFFFE).l,d1
ROM:000007CA not.w d1
ROM:000007CC ror.l d2,d1
ROM:000007CE andi.w #$3F,d1 ; '?'
ROM:000007D2 cmpi.w #$20,d1 ; ' '
ROM:000007D6 bne.w loc_7DC
ROM:000007DA rts
ROM:000007DC ; ---------------------------------------------------------------------------
ROM:000007DC
ROM:000007DC loc_7DC: ; CODE XREF: sub_6E4+2Cj
ROM:000007DC ; sub_6E4+5Aj ...
ROM:000007DC move.w #$8700,(VDP_Control).l
ROM:000007E4 move.l #$C0660000,(VDP_Control).l
ROM:000007EE move.w d3,(VDP_Data).l
ROM:000007F4 move.l #$C0000000,(VDP_Control).l
ROM:000007FE move.w d3,(VDP_Data).l
ROM:00000804 bra.s loc_7DC
ROM:00000804 ; End of function sub_6E4
ROM:00000804
it seems that it does some comparison between 2 consecutives read on DATA2 port and eventually go to loc6D6 and then sub_6E4 (which also do some other read/write on address 0x3FFFFE)

when debugging my emulator with PORTB connected to gamepad, it does not seems to go into these routines and simply do :

write 0 to 0x03FFFFE written
0x003FFFFE read
write 0xFFFF to 0x03FFFFE
0x003FFFFE read

then return

I assume that this address is used to communicate with the 2 additional ports but I still have no idea how exactly it's done

User avatar
ElBarto
Very interested
Posts: 158
Joined: Wed Dec 13, 2006 10:29 am
Contact:

Post by ElBarto » Thu Jul 05, 2007 12:45 pm

To open a J-Cart you have to unscrew the two screw under the front sticker, I've already done that. I'll try to do a scan tonight if you want.

User avatar
8bitwizard
Very interested
Posts: 155
Joined: Sat Feb 24, 2007 11:35 pm
Location: Austin, TX

Post by 8bitwizard » Thu Jul 05, 2007 2:58 pm

So I guess the port is at 3FFFFE, maybe even 16 bits wide. It's probably mapped to the entire 200000-3FFFFF area. And then D2 is probably either 0 or 8.
ElBarto wrote:To open a J-Cart you have to unscrew the two screw under the front sticker, I've already done that. I'll try to do a scan tonight if you want.
I bet you find a custom chip.

User avatar
ElBarto
Very interested
Posts: 158
Joined: Wed Dec 13, 2006 10:29 am
Contact:

Post by ElBarto » Thu Jul 05, 2007 7:51 pm


User avatar
8bitwizard
Very interested
Posts: 155
Joined: Sat Feb 24, 2007 11:35 pm
Location: Austin, TX

Post by 8bitwizard » Thu Jul 05, 2007 8:13 pm

It looks like I was only half right about the custom chip, but right about the 16 bits. ROM, two bus buffer chips, and a PAL for address decode. It's possible that the TH output for the joystick ports is registered on the PAL chip.

It should be possible to trace the data lines through the LS244 buffers to figure out which pin is which bit.

...and hey, it's even got a 2K byte I2C EEPROM for game saves!

In that case, I'm guessing that the EEPROM is at 200000-2FFFFF, and the joystick port is at 300000-3FFFFF. You'll need to disassemble the code to find out how the EEPROM is accessed.

TascoDLX
Very interested
Posts: 248
Joined: Tue Feb 06, 2007 8:18 pm

Post by TascoDLX » Fri Jul 06, 2007 9:09 am

Eke wrote:it seems that it does some comparison between 2 consecutives read on DATA2 port and eventually go to loc6D6 and then sub_6E4 (which also do some other read/write on address 0x3FFFFE)
The routine at 0006D6 is a debug routine so ignore it.

The J-Cart ports work the same as the usual ports (setup for joypad access). The value written to 3FFFFE is the TH signal (FFFF is TH=1, 0000 is TH=0). The value read from 3FFFFE is the DATA port value. Both ports are accessed simultaneously: the low byte is J-CART PORT A and the high byte is J-CART PORT B.

From the code, it looks like you need a controller in J-CART PORT A on startup. Otherwise, the J-Cart ports not read.

I don't see any EEPROM code... on first glance.

Eke
Very interested
Posts: 830
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Wed Jul 11, 2007 7:13 pm

Thank you for all these precisions, this works perfectly :D

For information, the two Pete Sampras' titles use 0x3FFFFE and the others (Mircomachines series & Super Skidmark) use 0x38FFFE...


I have a question regarding external devices (SRAM, EEPROM, adapter,...) that can be mounted in cartridges. If i'm not wrong, they are mapped into the rom area for 68000 (0-0x400000): could it be possible to access them with derivate techniques such as VDP DMA copy (to copy the content of SRAM to VRAM for example) or through the Z80 bank ?

User avatar
8bitwizard
Very interested
Posts: 155
Joined: Sat Feb 24, 2007 11:35 pm
Location: Austin, TX

Post by 8bitwizard » Sat Jul 14, 2007 2:41 am

The only difference to DMA between ROM and cartridge RAM is that the cartridge RAM can be written.

Except I don't think you can DMA with 68000 address space as the destination (it's only 68K->VDP, fill->VDP, and VDP->VDP), so it doesn't matter that the RAM can be written.

TascoDLX
Very interested
Posts: 248
Joined: Tue Feb 06, 2007 8:18 pm

Post by TascoDLX » Sat Jul 14, 2007 6:04 am

Eke wrote:I have a question regarding external devices (SRAM, EEPROM, adapter,...) that can be mounted in cartridges. If i'm not wrong, they are mapped into the rom area for 68000 (0-0x400000): could it be possible to access them with derivate techniques such as VDP DMA copy (to copy the content of SRAM to VRAM for example) or through the Z80 bank ?
Virtua Racing works this way. The SVP renders to a buffer in shared cartridge RAM and DMA transfers straight to VRAM. There is an issue (timing, I believe) which requires the source address to be set 1 word ahead [+2]. This same issue exists with DMA transfers from Sega CD's WORD RAM, which is the same concept.

Eke
Very interested
Posts: 830
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Sat Aug 02, 2008 6:28 pm

TascoDLX wrote:
Eke wrote:I was wrong about the Menacer game, it did read the DATA2 register and i've been able to simualte lightgun by triggering a level2 interrupt and mapping the Fire Button to D1 (0x02 mask). START button (pause) is mapped to D3 input (0x08 mask)
I believe a common mapping of buttons is SCAB -- from D3 down to D0: START, C, A, B -- with the trigger mapped to the A button. This, however, is merely a formality since the Menacer's buttons aren't labelled. But it can be useful if you want your game to support either the gamepad or the Menacer.

For the more curious among us, the Menacer is covered in US patent 5,351,969.

Funny thing about the Menacer is that there seems to be a significant delay between the gun sending its signal and the HV counter latch. The software needs to translate the HV value into more accurate coordinates.

Even funnier is that the delay seems to vary from game to game. For instance, the correction for Menacer 6-in-1 is different than that of T2 - The Arcade Game, even though you'd expect it to be the same. There's some unknown factor that affects this delay, whether it's I/O, VDP, or whatnot.

This is also the official reason that Fusion doesn't draw its own cursor when emulating the Menacer.
huh, quite hard to find that old post again :-)

since wiimote support is now completely stable in Wii homebrew, I took some time to investigate deeper into lightgun games ;)

as a result, I finally get accurate Menacer emulation and even Justifier emulation working perfectly for the few games that are supporting guns.

I also took the time to write some kind of complete documentation from my notes, maybe this could interest some of you ...




alternate link
Last edited by Eke on Sun Aug 10, 2008 6:01 pm, edited 3 times in total.

User avatar
HardWareMan
Very interested
Posts: 715
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Post by HardWareMan » Sun Aug 03, 2008 7:06 am

Link is dead.

Eke
Very interested
Posts: 830
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Sun Aug 03, 2008 9:31 am

hmm, weird, it still works for me

User avatar
HardWareMan
Very interested
Posts: 715
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Post by HardWareMan » Sun Aug 03, 2008 9:47 am

Eke wrote:hmm, weird, it still works for me
Image
Can you upload this document somewhere else?

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests