XE-1AP

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

Moderator: BigEvilCorporation

Post Reply
Mask of Destiny
Very interested
Posts: 558
Joined: Thu Nov 30, 2006 6:30 am

XE-1AP

Post by Mask of Destiny » Tue Oct 24, 2017 7:12 am

So I managed to find an XE-1AP while I was in Japan recently and I wrote a little test ROM to better characterize its behavior. First off, big thanks to Eke for emulating this peripheral in Genesis Plus GX as having some idea how this peripheral was supposed to work was a huge time saver when writing a test ROM. Apart from not fully emulating the delays (understandable since I assume it was put together from reverse engineering games rather than having the hardware available), it's appears to be correct with the exception of one minor error (more on that later).

First a test ROM and source. Essentially, this ROM starts a request with a 1->0 transition on TH and then records values from the IO port in a unrolled loop of move.b instructions to a buffer. This buffer is then analyzed to extract both the data payload and to get a rough estimate of the time between handshake flag transitions. This process is repeated once every 60 frames. A fairly typical run is shown in this screen capture:
Image.

Anyway, so I can confirm what is already documented in the Genesis Plus GX source in that TH 1->0 is indeed used to initiate a request, TR=0 indicates valid data and TL toggles each nibble (0 for first and so on). The data order is as follows (MSB->LSB, all buttons are active low)
0: E1, E2, Start, Select
1: (A & A') (B & B') C D
2: Analog L/R High
3: Analog U/D High
4: Always 0
5: Analog Throttle High
6: Analog L/R Low
7: Analog U/D Low
8: Always 0
9: Analog Throttle Low
10: Always F
11: A B A' B'

This almost exactly matches what's in the GPGX source with one exception: there's an extra unused nibble between throttle low and the final A B A' B' nibble. Since this last nibble is presumably only used by games that need to distinguish the "prime" buttons from the normal A & B buttons, this probably does not impact most software.

Now for an interpretation of the delay information. In the screenshot above, there are 3 hex numbers followed by a dash, then another 3, another dash and a final value. The last number is the actual byte read. The first 3 represent delay information related to the first nibble in the byte and the second 3 represent the same information for the second nibble. The first number in a group, is the number of bytes read with the not-ready bit set before the nibble, the second is the number of bytes read before TL toggles and the third is the number of bytes read before TR goes back to indicating the "not ready" state. Both the second and third numbers start counting from the first byte indicating a valid nibble (TR=0) so those delays overlap. As you can see in the screenshot, TR always goes back to 1 before TL toggles for the low nibble (TL=1). What''s not really visible is that the reverse is true for the high nibble (TL=0); however, the gap is much smaller in this case which is why they seem to happen at the same time. In some instances, I'll get a delay of only 6 reads for the TL toggle. As a result, the most reliable method to poll this device is probably to just ignore TL and use TR exclusively.

Since bytes are read from the I/O port with move.b (a2), (a6)+, each byte of delay represents about 12 M68K cycles which is 84 master clock cycles. This gives us the following delay times:

First nibble ready: 3780 cycles, 70 microseconds
TR=0 to TL=1, TR=0 to TR=1: 588 cycles, 11 microseconds
TR=1 to TR=0 (transition from high nibble to low nibble): 252 cycles, 5 microseconds
TR=1 to TR=0 (transition from low nibble to high nibble): 1176 cycles, 22 microseconds

Note that the first delay is sometimes quite a bit longer (as long as 10500 cycles, 196 microseconds), but the rest of the delays are pretty consistent. When I have the chance, I will try to measure these delays with something a bit faster than a Gen/MD so I can get more precise data.

User avatar
Stef
Very interested
Posts: 2627
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: XE-1AP

Post by Stef » Tue Oct 24, 2017 8:18 am

Thanks for the detailed description of the IO protocol for this monster controller :)
What's surprise me the most is that this controller wasn't even made by Sega but is supported by a bunch of Sega games.

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

Re: XE-1AP

Post by Eke » Tue Oct 24, 2017 8:43 am

Yes, it was mostly emulated by reversing the various games that use it and then later completed (the unused buttons mostly) using some XE-1AP driver code that was posted on sega-16

http://www.sega-16.com/forum/showthread ... JP-docs%29

especially this comment :

Code: Select all


			┌───┬──┬──┬──┬──┬──┬──┐
			│IOA│ 6 │ 5 │ 3 │ 2 │ 1 │ 0 │
			└───┼──┼──┼──┼──┼──┼──┤
				│ ACK│ L/H│ D3 │ D2 │ D1 │ D0 │
		┌───────┼──┼──┼──┼──┼──┼──┤
		│1回目のACK│ 0 │ 0 │ A │ B │ C │ D │
		├───────┼──┼──┼──┼──┼──┼──┤
		│2回目   〃   │ 0 │ 1 │E1 │E2 │ F │ G │
		├───────┼──┼──┼──┴──┴──┴──┤
		│3回目   〃   │ 0 │ 0 │        1  H        │
		├───────┼──┼──┼───────────┤
		│4回目   〃   │ 0 │ 1 │        2  H        │
		├───────┼──┼──┼───────────┤
		│5回目   〃   │ 0 │ 0 │        3  H        │
		├───────┼──┼──┼───────────┤
		│6回目   〃   │ 0 │ 1 │        4  H        │
		├───────┼──┼──┼───────────┤
		│7回目   〃   │ 0 │ 0 │        1  L        │
		├───────┼──┼──┼───────────┤
		│8回目   〃   │ 0 │ 1 │        2  L        │
		├───────┼──┼──┼───────────┤
		│9回目   〃   │ 0 │ 0 │        3  L        │
		├───────┼──┼──┼───────────┤
		│10回目   〃   │ 0 │ 1 │        4  L        │
		├───────┼──┼──┼──┬──┬──┬──┤
		│11回目   〃   │ 0 │ 0 │ A │ B │ A'│ B'│
		└───────┴──┴──┴──┴──┴──┴──┘

		     トリガー A,B,C,D,E1,E2,F,G =“0”;Trigger ON

						=“1”;Trigger OFF

Apparently, it was not 100% correct as you figured there was an extra nibble before the last one

Thanks for this very complete description anyway !

Mask of Destiny
Very interested
Posts: 558
Joined: Thu Nov 30, 2006 6:30 am

Re: XE-1AP

Post by Mask of Destiny » Tue Oct 24, 2017 8:38 pm

Interesting. The comment does seem to be in line with what the code does (saves the 12 nibbles as 12 bytes in the buffer and pulls the A,B,A',B' state from the 11th byte rather than the 12th). Though it also suggests that A,B,C,D comes in the first nibble with E1,E2,Start,Select in the second. It looks like maybe the nibbles are swapped when the controller is in MD mode compared to what they are in PC mode (which would be used for the X68000). This would also explain the unused analog channel coming before the throttle (there are trimmer pots for CH1-3 on the back of the device, so presumably the unused channel is supposed to be CH4).

I'll confirm the nibble swapping in PC vs MD mode when I get a chance.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest