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:
.
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.
XE-1AP
Moderator: BigEvilCorporation
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Re: XE-1AP
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.
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.
Re: XE-1AP
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 :
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 !
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 !
-
- Very interested
- Posts: 624
- Joined: Thu Nov 30, 2006 6:30 am
Re: XE-1AP
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.
I'll confirm the nibble swapping in PC vs MD mode when I get a chance.
Re: XE-1AP
(´・ω・`)Mask of Destiny wrote: ↑Tue Oct 24, 2017 8:38 pmI'll confirm the nibble swapping in PC vs MD mode when I get a chance.
Anyway, there are reports that the throttle can end up backwards:
https://www.sega-16.com/forum/showthrea ... s-reversed
They tried rotating but no dice? Or are they misunderstanding how it works? ($00 being up and $FF being down does seem correct from what I remember, but I haven't paid much attention to it).
Also yeah, I had noticed the extra axis years ago when I was trying to reverse engineer it by myself (admittedly, only from After Burner 2). I assumed it was in case they ever decided to expand it to be proper dual stick, considering the missing axis would be the X of the 2nd stick (the throttle is normally used vertically so it'd make sense as its Y axis).
Sik is pronounced as "seek", not as "sick".