Anyone know anything about them from a software development perspective? I assume they just connect rx and tx between the ps1 pad/MC port and the mobile tx/rx. I will have a closer look when I get a minute.

Donate & Support PSXDEV.NET
We have been operating since 2012 providing users with a place for free information, free downloads & zero ads.
It has always been a safe and clean forum with no spam for other members interested in the PlayStation 1 to meet and make new friendships.
It's a place for those who are interested in learning about programming, reverse engineering and experimenting with hardware/software for the console.
We have never asked for donations before but it has reached the point where the server costs are becoming too much for us.
We would like to politely ask that if you use this site that you donate any amount you can to show your support to assist with the hosting fees in order to keep PSXDEV.NET alive.
Users who donate will be rewarded with a new profile rank on their account badge
Just be sure to include your handle/alias when sending the donation or message me here with your BTC address.
Bitcoin: 1GqS7rr8jYPzT4Lp9Uua3D5thUH8ZnWyD8
Thank you for your contribution
We have been operating since 2012 providing users with a place for free information, free downloads & zero ads.
It has always been a safe and clean forum with no spam for other members interested in the PlayStation 1 to meet and make new friendships.
It's a place for those who are interested in learning about programming, reverse engineering and experimenting with hardware/software for the console.
We have never asked for donations before but it has reached the point where the server costs are becoming too much for us.
We would like to politely ask that if you use this site that you donate any amount you can to show your support to assist with the hosting fees in order to keep PSXDEV.NET alive.
Users who donate will be rewarded with a new profile rank on their account badge

Just be sure to include your handle/alias when sending the donation or message me here with your BTC address.
Bitcoin: 1GqS7rr8jYPzT4Lp9Uua3D5thUH8ZnWyD8
Thank you for your contribution


I mode cable/software
I mode cable/software
I have just acquired a nice cheap little item, which comes with the I mode cable. This allowed selected Japanese I mode enabled mobile phones to link to the playstation.
Anyone know anything about them from a software development perspective? I assume they just connect rx and tx between the ps1 pad/MC port and the mobile tx/rx. I will have a closer look when I get a minute.

Anyone know anything about them from a software development perspective? I assume they just connect rx and tx between the ps1 pad/MC port and the mobile tx/rx. I will have a closer look when I get a minute.
You do not have the required permissions to view the files attached to this post.
-
Shendo Verified
- C Programming Expert
- Posts: 250
- Joined: Mar 21, 2012
- I am a: Programmer
- Motto: Never settle
- PlayStation Model: SCPH-7502
- Discord: ShendoXT
- Location: Croatia, EU
PSX uses modified SPI protocol (250 Khz clock) with the added ACK line for interfacing with peripherals.
This adapter could be either pass through or it implements a SPI to TTL converter.
Each peripheral can be accessed with a different ID in the first byte:
0x01 - Standard digital controller,
0x81 - Memory Card.
I'm guessing this adapter has an ID of it's own too.
Use an I mode compatible software and see if it detects adapter but complains
about the missing phone (then it's not just pass through).
This adapter could be either pass through or it implements a SPI to TTL converter.
Each peripheral can be accessed with a different ID in the first byte:
0x01 - Standard digital controller,
0x81 - Memory Card.
I'm guessing this adapter has an ID of it's own too.
Use an I mode compatible software and see if it detects adapter but complains
about the missing phone (then it's not just pass through).
Last edited by Shendo on August 16th, 2013, 1:20 am, edited 1 time in total.
Dev console: SCPH-7502, FreePSXBoot, CH340 serial cable.
Cheers Shendo,
I know of the PS using modified SPI protocol for mmemory cards and controllers, I was thinking that the playstation perhaps used the MOSI/MISO lines as TTL. I don't think there is actual physical space in the cable for any hardware. If there isn't any hardware in the cable that could be quite cool air might open up the possibility for an additional serial port that can be used.
I'll post more on it later this week when I'm back home. The titles I have are in Japanese mind you
I know of the PS using modified SPI protocol for mmemory cards and controllers, I was thinking that the playstation perhaps used the MOSI/MISO lines as TTL. I don't think there is actual physical space in the cable for any hardware. If there isn't any hardware in the cable that could be quite cool air might open up the possibility for an additional serial port that can be used.
I'll post more on it later this week when I'm back home. The titles I have are in Japanese mind you
Last edited by danhans42 on August 14th, 2013, 5:02 am, edited 1 time in total.
Bit more from Martin Korths (noca$h), psx specs document..
SIO Ports vs JOY PortsSIO uses I/O Addresses 1F801050h..1F80105Fh, which seem to be organized similar to the Controller/Memory Card registers at 1F801040h..1F80104Fh, though not identical, and with an additional register at 1F80105Ch, which has no corresponding port at 1F80104Ch.SIO_BAUD is <effectively> same as for JOY_BAUD, but, <internally> they are a bit different: JOY_BAUD is multiplied by Factor, and does then ellapse "2" times per bit. SIO_BAUD is NOT multiplied, and, instead, ellapses "2*Factor" times per bit. Unlike for the Controller/Memory Card ports, the data is transferred without CLK signal, instead, it's using RS232 format, ie. the transfer starts with a start bit, and is then transferred at a specific baudrate (which must be configured identically at the receiver side). For RS232, data is usually 8bit, and may optionally end with a parity bit, and one or two stop bits.
-
Shendo Verified
- C Programming Expert
- Posts: 250
- Joined: Mar 21, 2012
- I am a: Programmer
- Motto: Never settle
- PlayStation Model: SCPH-7502
- Discord: ShendoXT
- Location: Croatia, EU
Yup. Martin's awesome document was really helpful when I was making siolib for Tail's' PSXSDK.
Anyway, for now you will need to see how software responds.
After that i think the only viable option is to use logic analyzer and see what kind of data is transferred.
There is also a possibility of "bombarding" the adapter with every value from 0 - 255 and see what kind of response
it will give. It's trial and error and it's time consuming but it might yield some results.
Anyway, for now you will need to see how software responds.
After that i think the only viable option is to use logic analyzer and see what kind of data is transferred.
There is also a possibility of "bombarding" the adapter with every value from 0 - 255 and see what kind of response
it will give. It's trial and error and it's time consuming but it might yield some results.
Dev console: SCPH-7502, FreePSXBoot, CH340 serial cable.
Inside of the cable...




looks like the game I have has anti-mod protection.. bollocks.
I will have to open my never used SCPH-1002 and disk swap as I havent as yet figured out how to write what the hell I like to the memory card/joypad SIO port.
I will have to open my never used SCPH-1002 and disk swap as I havent as yet figured out how to write what the hell I like to the memory card/joypad SIO port.
-
Shendo Verified
- C Programming Expert
- Posts: 250
- Joined: Mar 21, 2012
- I am a: Programmer
- Motto: Never settle
- PlayStation Model: SCPH-7502
- Discord: ShendoXT
- Location: Croatia, EU
Yeah. BIOS routines don't allow writing custom data to pads.
And padlib while it patches the BIOS for analog control it still doesn't allow programmer to send custom data.
Luckily Tails implemented direct port access in his PSXSDK for sending whatever you desire to pad and Memory Cards.
You can use QuerryPad routine for this.
And padlib while it patches the BIOS for analog control it still doesn't allow programmer to send custom data.
Luckily Tails implemented direct port access in his PSXSDK for sending whatever you desire to pad and Memory Cards.
You can use QuerryPad routine for this.
Dev console: SCPH-7502, FreePSXBoot, CH340 serial cable.
I've got one of those I-Mode cables, and I am disassembling the "Hamster Club-i" executable.
And I've found this official document, which contains a few info snippets:
http://lorezan.free.fr/ps1/iMODE.pdf Software Development Seminar: iMode System
Is there any more detailed official documentation? According to the above doc, there should be a library called "libimode" - does anybody have that library? Especially, having the "libimode.h" header file would make it easier to disassemble the executable.
Maybe that stuff can be found in some SDKs or CDROMs, dated from 2000 or newer (the I-Mode games are from 2000-2002).
And I've found this official document, which contains a few info snippets:
http://lorezan.free.fr/ps1/iMODE.pdf Software Development Seminar: iMode System
Is there any more detailed official documentation? According to the above doc, there should be a library called "libimode" - does anybody have that library? Especially, having the "libimode.h" header file would make it easier to disassemble the executable.
Maybe that stuff can be found in some SDKs or CDROMs, dated from 2000 or newer (the I-Mode games are from 2000-2002).
Here's the pinout for the I-mode connector and chipset...
That is, I am still miles away from knowing what is going on. I think I still don't know the correct keywords needed to search for information about those highly poular japanese I-mode phones (parts of the problem is that they weren't so popular outside of japan, so maybe the information was never even translated to english).
Connector
What I know is that connector is Hirose MQ138.
The best connector pinout specs I've found are from the "Panasonic G600 Technical Guide" mentioned above, which is about two years OLDER than I-Mode. I guess the I-mode phones did have the AUDIO pins replaced by some SERIAL transfer signal.
Are there pinouts or schematic for newer japanese phones, with I-mode connectors?
Microprocessor
The cable contains a Fujitsu MB90567 microprocessor. There are some datasheets for it, including some wiring info for FLASH programming (either via serial cable, or via parallel EPROM sockets).
But, there seems to be no info on the serial transfer protocol. It doesn't mention if the FLASH programming functions can be also used to dump the FLASH content. And, the MB90567 appears to be the mask ROM version, so it might completely lack any kind of FLASH (or ROM) dumping features.
Anyways, if somebody knows how to dump the firmware... please tell how!
Keitai Eddy cable
The Keitai Eddy game comes bundled with a different phone cable: It connects to PSX SIO port instead of PSX controller port, and there appears to be a small PCB in the middle of the cable.
Does somebody have photos of that Keitai Eddy cable PCB?
Code: Select all
Pinouts - Component List and Chipset Pin-Outs for I-Mode Cable SCPH-10180
-------------------------------------------------------------------------
PSX Controller Port plug (with PCB and cables to Hirose HRS MQ138 connector):
_________________________
|1 2 3 4 5 6 7 8 9|
| _________ ____|___ yellow
| | | / ___|___ orange
| | | / / __|___ red
light green ___|o | MB90567 | / / / |
white ____\o | | o o o /
gray _____\o |_________| o/_____ black
purple ______\o_____________o_o_o/
\ \ \______ dark green
\ \_______ blue
\________ brown
Hirose HRS MQ138 connector (16pin, only 13 pins actually installed though)
.------------------------------------------.
.-| _ _ 1 2 3 4 5 6 7 . _ _ |-. MQ138S-B-G, HRS
| | | (_) (_) | | |
'-| 9 10 ' 12 13 14 15 ' |-'
'------------------------------------------'
<-------- SCPH-10180 -----------> <---- Panasonic G600 Technical Guide ---->
1 nc (not connected) - GND
2 black P61/SOT1 L in TX_AUDIO (analogue)
3 brown GND L - AUDIO_GND
4 red P57/AN7 H out /HF_0N (L=ON) (handsfree on)
5 orange P62/SCK1 2V in /ADP_SENSE (DATA ADAPTOR SELECT)
6 yellow P20/TIN0 2V in SERIAL_UP (UPLINK) ;\9.6..115.2 kbps
7 dark green P12/INT2 H out SERIAL_DOWN (DOWNLINK);/even parity 8E1
8 - (no pin installed) in EXT_PWR (CHARGE) (9.4V max)
--
9 nc (not connected) - TX_AUDIO GND or GND
10 blue P60/SIN1 H out RX_AUDIO (analogue)
11 - (no pin installed) out /RADIO_MUTE (L=MUTE)
12 purple P14/INT4 2V 0V in /HF_SENSE (L=HF MODE)
13 gray P15/INT5 2V 0V out PERF_PWR_ENBL, /FLASH_WE (or VBAT?)
14 white P17/FRCK 2V 1V in IGNITION (H=ON)
15 light green P16/INT6 H out /LOGIC_PWR (H=HANDSET ON)
16 - (no pin installed) out PERF_PWR, PA_ON (POWER AMP. CONTROL)
Note: The Panasonic G600 does have a similar connector (unknown if it's really
compatible... the above pinouts suggest that SIN1 and SOT1 pins are wired to
AUDIO signals?). The Panasonic G600 seems to be from 1998, maybe newer phones
had the AUDIO pins replaced by I-mode data transfer pins?
I-Mode Chipset
Case: "SONY DATA-CABLE, SonyComputerEntInc, SCPH-10180 MADE IN CHINA"
U? 64pin Fujitsu MB90567 "F JAPAN, MB90567, 107, 0051 Z16"
U? 5pin Reset Generator "DDRY"
X? 3pin Crystal "400g"
ZD? 5pin Maybe Quad Zener diodes? "6.8Z"
ZD? 5pin Maybe Quad Zener diodes? "6.8Z"
ZD? 5pin Maybe Quad Zener diodes? "6.8Z"
ZD? 5pin Maybe Quad Zener diodes? "6.8Z"
D? 5pin Maybe Dual Diodes with GND? "XB"
D? 5pin Maybe Dual Diodes with GND? "XB"
D? 5pin Maybe Dual Diodes with GND? "XB"
Fujitsu MB90567 (16bit Microcontroller, 96Kbyte ROM, 4Kbyte RAM):
1 P45/PPG4
2 P46/PPG5
3 P50/AN0
4 P51/AN1
5 P52/AN2
6 P53/AN3
7 P54/AN4
8 P55/AN5
9 P56/AN6
10 P57/AN7 cable red (via diode..?)
11 AVCC 3.5V
12 AVR 3.5V
13 AVSS GND
14 P60/SIN1 cable blue (via diode with 10K ohm pull up)
15 P61/SOT1 cable black (via XB and 100 ohm)
16 P62/SCK1 cable orange (via diode..?)
---
17 P63/INT7/DTTI
18 MD0 3.5V
19 /RST /RESET (from DDRY with pullup)
20 MD1 3.5V
21 MD2 GND
22 X0 crystal
23 X1 crystal (via capacitor?)
24 VSS GND
25 P00
26 P01
27 P02
28 P03
29 P04
30 P05
31 P06
32 P07
---
33 P10/INT0 /JOYn via 220 ohm to psx pin6
34 P11/INT1 /ACK via 22 ohm to psx pin9
35 P12/INT2 cable dark green (via diode with 10K ohm pull up)
36 P13/INT3
37 P14/INT4 cable purple (via XB and 22 ohm)
38 P15/INT5 cable gray (via XB and 22 ohm)
39 P16/INT6 cable light green (via diode with 10K ohm pull up)
40 P17/FRCK cable white (via XB and 22 ohm)
41 P20/TIN0 cable yellow (via XB and 100 ohm)
42 P21/TO0
43 P22/TIN1
44 P23/TO1
45 P24/IN0
46 P25/IN1
47 P26/IN2
48 P27/IN3
---
49 VSS GND
50 P30/RTO0
51 P31/RTO1
52 P32/RTO2
53 P33/RTO3
54 P34/RTO4
55 P35/RTO5
56 VCC 3.5V
57 C*
58 P36/SIN0 JOYCMD via 220 ohm to psx pin2
59 P37/SOT0 JOYDAT via diode? and 22 ohm to psx pin1
60 P40/SCK0 JOYCLK via 220 ohm to psx pin7
61 P41/PPG0
62 P42/PPG1
63 P43/PPG2
64 P44/PPG3
Connector
What I know is that connector is Hirose MQ138.
The best connector pinout specs I've found are from the "Panasonic G600 Technical Guide" mentioned above, which is about two years OLDER than I-Mode. I guess the I-mode phones did have the AUDIO pins replaced by some SERIAL transfer signal.
Are there pinouts or schematic for newer japanese phones, with I-mode connectors?
Microprocessor
The cable contains a Fujitsu MB90567 microprocessor. There are some datasheets for it, including some wiring info for FLASH programming (either via serial cable, or via parallel EPROM sockets).
But, there seems to be no info on the serial transfer protocol. It doesn't mention if the FLASH programming functions can be also used to dump the FLASH content. And, the MB90567 appears to be the mask ROM version, so it might completely lack any kind of FLASH (or ROM) dumping features.
Anyways, if somebody knows how to dump the firmware... please tell how!
Keitai Eddy cable
The Keitai Eddy game comes bundled with a different phone cable: It connects to PSX SIO port instead of PSX controller port, and there appears to be a small PCB in the middle of the cable.
Does somebody have photos of that Keitai Eddy cable PCB?
Here's what I've found out on the software protocol.
There are several software layers, with messages being somehow forward from one layer to another, and finally passed to hardware IRQ handlers.
And the whole thing depends on state variables, which are used to decide which messages are generated or processed at which time.
Controller Port Commands
This part is quite simple. There are 8 commands, although one 6 or 7 are actually used, and some of them seem to be "duplicated" (offering ways to transfer different amounts of data).
I-Mode Messages
These messages are more deeply hidden in the executable, and they seem to be the crucial part for understanding the hardware.
At the moment I've merely compiled a list of existing messages...
Theoretically those messages should be officially documented somewhere, help on finding those documents would be very welcome!!!
I-Mode PSX Library
This is some info from the above .pdf, related to the inner workings of the PSX library (it isn't directly related to the hardware, but it's useful for disassembling the executable).
In particular, one does does apparently need to get through the AUTH and GW stuff before seeing any actual HTTP data transfers.
ASCII Strings
And here's an overview of ASCII strings found in the I-Mode games.
And some general stuff...
I-Mode today
Reportedly I-Mode is still supported in japan, until march 2026. So it might be still possible to transfer data through the I-mode cable... which could be useful to see which commands will receive which replies (for the generic data transfers, the URLs in the above ASCII strings are all down, so there's little chance to receive PSX game-specific replies).
Supported phones (SCPH-10180)
From the pdf: "Compatible only with the iMODE mobile phone that supports "iNavilink". Currently, the [DoCoMo] P502i, F502it and N502it are the only compatible equipment. The 503 series will be sold after this [which?] winter and all units will be compatible."
Whatever that means.
There appears to be little info about "iNavilink".
The connector did apparently exist in the above phone models... and maybe also newer models from other manufacturers... or maybe it was quickly discontinued and didn't make it into other/newer/modern phones?
Maybe the game manuals or other documents or reviews contain more info about supported models...?
There are several software layers, with messages being somehow forward from one layer to another, and finally passed to hardware IRQ handlers.
And the whole thing depends on state variables, which are used to decide which messages are generated or processed at which time.
Controller Port Commands
This part is quite simple. There are 8 commands, although one 6 or 7 are actually used, and some of them seem to be "duplicated" (offering ways to transfer different amounts of data).
Code: Select all
Controller Port Commands
Send 41h 1xh .. .. ;1xh = 11h..18h
Reply 00h 5Ah .. ..
Commands:
11h len=5 reply: 00 5A 8E 0n 00 ;cmd 11h..18h: n=0 or 1
12h len=7 reply: 00 5A 6F 00 00 0n 00 ; (n=1 after cmd 13h,0Fh)
13h len=5 reply: 00 5A C0 0n 00 ; (n=0 after cmd 17h)
14h len=88h reply: 00 5A 00 00 00 00 00 00 00 .. .. 0n 00 ;DATA[80h+3]
15h len=1Fh reply: 00 5A 00 00 00 00 00 00 00 .. .. 0n 00 ;DATA[..]
16h len=5 reply: 00 5A 4A 0n 00
17h len=5 reply: 00 5A 56 0n 00 ;FLAG
18h len=6 reply: 00 5A 00 00 0n 00 ;DATA[..]
There seem to be two data streams:
Small Control Messages (sent/received via command 14h, 15h, or 18h)
Large 80h-byte Data Blocks (sent/received via command 14h)
The games are sending data at 500kbit/s (except, the first byte (41h) should be
always sent at 250kbit/s, to properly deselect controllers or memory cards).
BUG: The 1st reply byte is 00h (rather than HighZ), that reply byte will occur
even when trying to access other hardware like joypads or memory cards.
Command 11h (unused in Hamster Club-i)
Send Recv
00h 41h 00h ;#cmd
01h 11h 5Ah ;/
02h ? 8Eh ;-
03h ? 00h or 01h ;#stat/flag?
04h ? 00h ;/
Command 12h
Send Recv
00h 41h 00h ;#cmd
01h 12h 5Ah ;/
02h 00h..04h 6Fh ;# ;<-- always sends 00h
03h 03h or 06h 00h ;
04h ? 00h ;/
05h ? 00h or 01h ;#stat/flag?
06h ? 00h ;/
Command 13h
Send Recv
00h 41h 00h ;#cmd
01h 13h 5Ah ;/
02h 0Fh C0h ;-
03h ? 00h or 01h ;#stat/flag?
04h ? 00h ;/
Command 14h
Send Recv
00h 41h 00h ;#cmd
01h 14h 5Ah ;/
02h Data[80h] Data[80h] ;#
82h ? ? ;# ; checksummed
83h ? ? ; OtherData[3] ? ;
84h ? ? ;/ ;/
85h Chksum? Chksum ;-checksum (above bytes XORed)
86h ? 00h or 01h ;#stat/flag?
87h ? 00h ;/
Command 15h
Send Recv
00h 41h 00h ;#cmd
01h 15h 5Ah ;/
02h Data[1Ah] Data[1Ah] ;-checksummed
1Ch Chksum? Chksum ;-checksum (above bytes XORed)
1Dh ? 00h or 01h ;#stat/flag?
1Eh ? 00h ;/
Command 16h
Send Recv
00h 41h 00h ;#cmd
01h 16h 5Ah ;/
02h 00h or 01h 4Ah ;- ;<-- 00h=UseCmd15h, 01h=UseCmd14h
03h ? 00h or 01h ;#stat/flag?
04h ? 00h ;/
Command 17h
Send Recv
00h 41h 00h ;#cmd
01h 17h 5Ah ;/
02h FLAGS 56h ;-
03h ? 00h or 01h ;#stat/flag?
04h ? 00h ;/
FLAGS (03h or 0Ch or 0Fh or 10h):
bit0 Clear Send queue ;#clear queue inside of PSX (probably implies
bit1 Clear Recv queue ;/request to also clear queue in Fujitsu chip)
bit2 Ack/swap/apply/discard TX block number? ;#for 80h-byte data blocks
bit3 Ack/swap/apply/discard RX block number? ;/
bit4 Reset
Command 18h
Send Recv
00h 41h 00h ;#cmd
01h 18h 5Ah ;/
02h Data[2] Data[2] ;-
04h ? 00h or 01h ;#stat/flag?
05h ? 00h ;/
These messages are more deeply hidden in the executable, and they seem to be the crucial part for understanding the hardware.
At the moment I've merely compiled a list of existing messages...
Theoretically those messages should be officially documented somewhere, help on finding those documents would be very welcome!!!
Code: Select all
I-Mode Messages
Hamster Club-i is sending/receiving the following messages.
Unknown how it's doing that, probably via command 14h, 15h, and/or 18h.
The messages start with an 8bit value (eg. 85h), following by several "4bit
bytes" (which have the upper 4bits set to zero).
Send:
85h,01h,01h,02h,plain_random[8],00h,03h,00h,00h,01h ;#AUTH related?
85h,01h,04h,02h,crypted_random[8] ;/
85h,01h,05h,02h
85h,01h,06h
8Eh ;-is that same 8Eh as in Keitai Eddy?
F2h,00h,01h,02h,00h,00h,00h,00h,00h
F2h,00h,01h,02h,01h,00h,00h,00h,00h
F2h,00h,01h,02h,08h,00h,00h,00h,00h
Recv:
38h,02h,.. ;return 06h=CONNECTED ;#
85h,01h,02h,.. ;return 02h=AUTH_STARTED ;
85h,01h,03h,.. ;return 01h=AUTH_STARTING ;
85h,01h,04h,.. ;return 03h=GW_CONNECTING ; state
85h,01h,07h,.. ;return 04h=GW_CONNECTED ;
F1h,00h,03h,xxh,xxh,...,xxh ;return 05h=CONNECTING and do stuff ;
F2h,02h,02h,xxh,xxh,...,xxh ;return 0Bh or 0Dh and do stuff ;
F2h,00h,03h,.. ;return 0Ch=DISCONNECTED ;/
80h,.. ;#
81h,.. ;
8Ah,.. ;
8Bh,.. ; ?
A4h,.. ;
A5h,.. ;
A6h,.. ;
A7h,.. ;
AAh,.. ;
E0h,.. ;
E6h,.. ;/
C0h..CFh ;ignored ;#
D1h,... ;data packet maybe? ; data?
00h..0Fh ;data bytes? ;/
At some point after the AUTH/CONNECT stuff, the software should somehow happen
to send HTTP messages in ASCII (eg. GET http, POST http).
This is some info from the above .pdf, related to the inner workings of the PSX library (it isn't directly related to the hardware, but it's useful for disassembling the executable).
In particular, one does does apparently need to get through the AUTH and GW stuff before seeing any actual HTTP data transfers.
Code: Select all
sceImode_Param Context Structure
00h short fCommandType; Command type (00h..07h)
02h short fPortNo; iMODE cable connection port (0:port1, 1:port2)
04h short fSlotNo; iMODE cable connection slot (A~D:0~3) (unused)
06h - padding -
08h char* fSendBuff; Send data buffer address ;#
0Ch short fSendBuffSize; Send data buffer size ; TX
0Eh short fSendDataSize; Actual size of send data ;/
10h char* fRcvBuff; Receive data buffer address ;#
14h short fRcvBuffSize; Size of receive data buffer ; RX
16h short fRcvDataSize; Size of receive data buffer ;/
18h char* fInfoBuff; Info data receive buffer address ;#
1Ch short fInfoBuffSize; Info data receive buffer size ; Info ?
1Eh short fInfoDataSize; Actual size of info data received ;/
20h short fStatus; State variable (00h..10h)
22h short fLastError; Error class (signed, -63h..+00h)
Commands:
0=IMODE_CMD_RCV Check receive data (default)
1=IMODE_CMD_SND Send request
2=IMODE_CMD_STS Get state
3=IMODE_CMD_ABORT Abort send/receive
4=IMODE_CMD_AUTH_START Begin authentication
5=IMODE_CMD_AUTH_END End authentication
6=IMODE_CMD_GW_CONNECT Connect gateway
7=IMODE_CMD_GW_DISCONNECT Disconnect gateway
States:
-1 =UNINITIALIZED Pre-Init / Post-Finalize
00h=DORMANT Initial State ;-
01h=AUTH_STARTING Authenticating ;#CND_AUTH_START
02h=AUTH_STARTED Authenticated ;/
03h=GW_CONNECTING Gateway connecting ;#
04h=GW_CONNECTED Gateway connected ; CMD_GW_CONNECT
? 05h=CONNECTING Connecting ;/
? 06h=CONNECTED Connected
?? 07h=SENDING Sending ;#IMODE_CMD_SND
?? 08h=SENDCOMPLETE Send completed ;/
?? 09h=RECEIVING Receiving ;#IMODE_CMD_RCV
?? 0Ah=RECEIVECOMPLETE Receive completed ;/
? 0Bh=DISCONNECTING Disconnecting ;# CMD_ABORT?
? 0Ch=DISCONNECTED Disconnected ; CMD_GW_DISCONNECT
0Dh=GW_DISCONNECTING Gateway disconnecting ;
0Eh=GW_DISCONNECTED Gateway disconnected ;/
0Fh=AUTH_ENDING Authentication ending ;#CMD_AUTH_END
10h=AUTH_ENDED Authentication ended ;/
And here's an overview of ASCII strings found in the I-Mode games.
Code: Select all
The games don't contain detailed debug messages. However, some games do contain
ASCII strings related to networking:
Hamster Club-I:
has several ASCII strings:
800108BC " HTTP/1.0",0Dh,0Ah,"User-Agent: ",00h
800108D4 0Dh,0Ah,"Content-type: text/plain",0Dh,0Ah,"Content-Length: ",00h
80010904 "Content-Length: ",00h
80013C18 "uid=NULLGWDOCOMO&val=",00h
80013C30 "http://ne-net.com/hc/i/ps/",00h
80013C30 "HTTP/1.0",0Dh,0Ah,"User-Agent: ",00h
80013C64 "DoCoMo/1.0/ex_ps1302",00h
80013C7C 0Dh,0Ah,"Content-type: application/x-www-form-urlencoded",0Dh,0Ah,
"Content-Length: ",00h
80014040 "Ranking.cgi"
800141DC "Regist.cgi"
800145E0 "HamList.cgi"
80014668 "HamSet.cgi"
800148C0 "ArenaParty.cgi"
80014948 "ArenaBattle.cgi"
80014958 "ArenaResult.cgi"
80014AEC "Stroll.cgi"
80018B88 "-- autholize pass -2",0Ah,0
80018DD0 "User-Agent:DoCoMo/1.0/ex_ps",00h
80018DEC "User-Agent: DoCoMo/1.0/ex_ps",00h
80018E0C "TL_Disconnect Invalid TL handle = %d ",0Ah,00h
80018E34 "TL_Disconnect TLCF2_ERR_OTHERS",0Ah,00h
8001910C "Ayame.log",00h
80019118 "com1:"
800D8C60 25h --> "%"
800E1648 48h,54h,... ---> "HTTP/1.0",0Dh,0Ah,00h
800E16C8 55h,73h,... ---> "User-Agent: DoCoMo/1.0/",00h
801018F0 "Access TLm Version 3.0 (Ayame)",00h
80101910 "Copyright 1997 - 2000 Access Co., Ltd.",00h
80101938 "Gamma Release 1.3 (Apr. 18, 2000),00h
801024E8 "GET",00h
80102500 "POST",00h
80102728 "POST",00h
and some known code/data locations:
800CA80C code: send joy byte
800D94BC code: send imode byte 41h
800D9F3C code: send NOT(-42h) aka NOT(FFFFFFBEh) aka 41h
To get I-Mode transfers: In main menu, select "iE-K" then select "NETWORK
BATTLE" (or the other option; other than the two RANKING options).
i-mode mo Issho - Doko Demo Issho Tsuika Disc:
has similar ASCII strings:
GET http, POST http://dkd.to/p/, User-Agent, com1:, Access TLm, ..
Motto Trump Shiyou yo! i-Mode de Grand Prix:
has a few ASCII strings:
8006AB6C-and-up maybe compare 5Ah for replies?
80072144 80014548h "-- autholize pass -2",0Ah,0
80072CB8 80014790h "User-Agent:DoCoMo/..."
80072D34 800147ACh "User-Agent:DoCoMo/..."
80073498 800147CCh "TL_Disconnect Invalid TL handle = %d ",0Ah,0
8007A9E4 80014ACCh "Ayame.log"
8007A9F0 80014AD8h "com1:"
800852C0 48h,54h,... "HTTP/1.0",0Dh,0Ah,00h
80085340 55h,73h,... "User-Agent:"
One Piece Mansion:
has ASCII strings (only in memory when selecting 3rd main menu option).
Mobile Tomodachi:
no ASCII strings (and merely accesses phone address book, without internet?).
requires entering a 4-digit PIN (that part is similar as in Keitai Eddy)
I-Mode today
Reportedly I-Mode is still supported in japan, until march 2026. So it might be still possible to transfer data through the I-mode cable... which could be useful to see which commands will receive which replies (for the generic data transfers, the URLs in the above ASCII strings are all down, so there's little chance to receive PSX game-specific replies).
Supported phones (SCPH-10180)
From the pdf: "Compatible only with the iMODE mobile phone that supports "iNavilink". Currently, the [DoCoMo] P502i, F502it and N502it are the only compatible equipment. The 503 series will be sold after this [which?] winter and all units will be compatible."
Whatever that means.
There appears to be little info about "iNavilink".
The connector did apparently exist in the above phone models... and maybe also newer models from other manufacturers... or maybe it was quickly discontinued and didn't make it into other/newer/modern phones?
Maybe the game manuals or other documents or reviews contain more info about supported models...?
One major finding: There's a whole web browser for I-Mode. And it's somewhat hidden in plain sight: The SCPH-10180K package contains the SCPH-10180 cable, and PBPX-95013 cdrom (with some gray-on-gray artwork in a gray cardboad box, it's almost invisble, and looks more like a random CDR than an actual retail disc).
Updated list for known supported software...
I am not sure which disc(s) the first two "Doko Demo" entries are referring to, or if they do really support I-Mode (especially the one from 2000 sounds dubious as everything else is dated 2001/2002).
And there is that "Dragon Quest Monsters 1 & 2" game, as far as I remember some webpage/magazine claimed that it would be released with I-Mode support... but actually... instead of the I-Mode cable, it seems to use bloody passwords to "transfer" data between PSX and mobile phones?
Updated list for known supported software...
Code: Select all
Sxxx-????? Doko Demo Issyo (PlayStation the Best release only) (Sony) 2000
Sxxx-????? Doko Demo Issyo Deluxe Pack (Bomber eXpress/Sony) 2001
SLPS-03266 Hamster Club-I (Jorudan) 2002
SCPS-10141 iMode mo Issyo: Dokodemo Issho Tsuika Disc (Bomber/Sony) 2001
SLPS-02717 Keitai Eddy (iPC) (phone cable connects to SIO port) 2000
SLPS-03121 Komocchi (Victor) 2001
SLPM-87151 Mobile Tomodachi (Hamster) 2002
SLPS-03321 Motto Trump Shiyouyo! i-Mode de Grand Prix (Pure Sound) 2002
SLPM-86837 One Piece Mansion (Capcom) (japanese version only) 2001
PBPX-95013 Keitai Henshuu (CompactNetFront browser) (in SCPH-10180K kit) 2001
And there is that "Dragon Quest Monsters 1 & 2" game, as far as I remember some webpage/magazine claimed that it would be released with I-Mode support... but actually... instead of the I-Mode cable, it seems to use bloody passwords to "transfer" data between PSX and mobile phones?
Last edited by nocash on August 21st, 2023, 4:26 am, edited 1 time in total.
And another breakthrough: The name "iNavilink" in the pdf is bogus.
The correct spelling appears to be "i-Navi Link".
With that keyword, the search results have almost doubled (from "near zero" to "not much more").
Hmmm, that doesn't change my overall impression: Mobile phones didn't exist back then, or their existance wasn't documented anywhere.
Or I am just the wrong person for that kind of research (I've perhaps used mobile phones 2-3 times in my whole life). Maybe people with more mobile phone experience will find it easier to search information & schematics for those data cable connectors (?)
At least, I've now found a phone user manual that seems to depict a connector resembling those on the I-Mode cable...
The correct spelling appears to be "i-Navi Link".
With that keyword, the search results have almost doubled (from "near zero" to "not much more").
Hmmm, that doesn't change my overall impression: Mobile phones didn't exist back then, or their existance wasn't documented anywhere.
Or I am just the wrong person for that kind of research (I've perhaps used mobile phones 2-3 times in my whole life). Maybe people with more mobile phone experience will find it easier to search information & schematics for those data cable connectors (?)
At least, I've now found a phone user manual that seems to depict a connector resembling those on the I-Mode cable...
You do not have the required permissions to view the files attached to this post.
Last edited by nocash on August 21st, 2023, 6:11 am, edited 1 time in total.
I've found pinouts for another similar connector. Interestingly, it does list wirings for different external devices like PC cable, printer, or download (whatever that is).
I don't know if that one is compatible with the I-Mode cable, but it looks a bit closer than the Panasonic G600 stuff with analog audio signals. And it does somewhat confirm that identical looking connectors can have different pinouts (and perhaps different internal transfer protocols for the RXD/TXD pins).
A lot more mobile phone pinouts can be found here, http://rtfm.vtt.net/pinouts/pin_Cellula ... .shtml.htm but most or all of them seem to use different looking connectors... although that webpage does also include the Sharp GX10i... which is only looking different because they have omitted the two large round coaxial connectors on the left/right of the 16pin block.
For the name of the connector, the official name appears to be "External Connector", which isn't too useful when searching for pinouts/specs. There are some other alternate names...
For the transfer messages, the PSX software seems to be basically waiting for incoming messages from the phone. Except, after some timeout, it's sending the 1-byte 8Eh message to the phone (probably some reset command), and then keeps waiting for incoming messages.
Without having specs for the protocol or data logs from real phones... the only way will be trying to emulate messages like "85h,01h,02h,.." and then see if the PSX sends some auth related message in response.
Code: Select all
Sharp GX10i Service Manual, External Connector CN302:
Schematic JTAG Genie Download Printer PCcable Normal
1 - GND GND GND GND - GND GND
2 in USC4(RTS) - - - - RTS (AUX_IN)
3 - GND GND GND GND - - GND
4 out (JTAGEN) J.EN - - - - AUX_OUT
5 out V-EXT_CN(2.5V) VCC - - - VCC VCC
6 in USC1(RXD) - - RXD RXD RXD RXD
7 out USC2(TXD) - - TXD TXD TXD TXD
8 in CHRIN - - - - - Flashload
--
9 - GND GND GND GND GND GND GND
10 out USC5(CTS) - - - - CTS (AUX_OUT)
11 in nRESET /RES - - - - AUX_IN
12 in GPIO_8(CONT1/DTR) - - - CONT1 DTR CONT1
13 in USC6(var...) TMS DebRx - - - CONT2
14 in USC3(ADPDET) TDI - - - Low ADPDET
15 out USC0(var...) TDO DebTx - - - ADP
16 in CHARGER_REG TCK - High - - _ON
--
17 - - - - - - Power(-)
18 - DC+ - - - - Power(+)
Unknown where pin 17/18 are supposed to be, maybe the MQ138 coaxial
contacts, or maybe even the MQ138 locking clips?
A lot more mobile phone pinouts can be found here, http://rtfm.vtt.net/pinouts/pin_Cellula ... .shtml.htm but most or all of them seem to use different looking connectors... although that webpage does also include the Sharp GX10i... which is only looking different because they have omitted the two large round coaxial connectors on the left/right of the 16pin block.
For the name of the connector, the official name appears to be "External Connector", which isn't too useful when searching for pinouts/specs. There are some other alternate names...
Code: Select all
External connector
Terminal under the terminal cover at the bottom
Wall Outlet connector (for AC adaptor)
Cigarette Lighter connector (for DC adaptor)
Hirose MQ138-series Universal Plug (for PDC Type Digital Cellular Phones)
Japanese Phone connector
Without having specs for the protocol or data logs from real phones... the only way will be trying to emulate messages like "85h,01h,02h,.." and then see if the PSX sends some auth related message in response.
I got some background info on japaenese phones via PM...
And specifically on the 50x mova series...The biggest problem with those Japanese phone expansion connectors is that there are lots of variants - about the only pins you can generally expect to be the same are the ones used for charging the battery. Different variants used different signaling protocols - the early ones ran on top of PDC (what DoCoMo called their "mova" service), some later models used US style (but incompatible!) CDMA and the ones after that used W-CDMA or "foma" in DoCoMo speak). Although they used the same plug and similar electrical protocols the signaling was different and you can't be sure that just because the plug is the same it will actually be able to communicate.
A good example of this was the navigation unit I had in my car - it had a data link with one of those Hirose plugs on it, and it would plug into my (foma) phone - the charge indicator came on and the "data" icon turned on .. but it didn't work. After much talking to technical support and reading the manual, it turned out my phone was just too new.
So if you are trying to figure this stuff out you you have to start by identifying the exact models it worked with, and then find out what underlying technology they used. You definitely can't assume that just because the plug fits it will work.
The first letter (or sometimes letters) of the DoCoMo model numbers does indeed identify the manufacturer - so "N" was NEC, "F" was Fujitsu, "P" was Panasonic, "D" was for some reason Mitsubishi, etc. The 50x indicated a MOVA model and the 'i' i-Mode support. So a "D501i" was the first NEC DoCoMo handset with i-Mode support and D502,D503.. were the later models.
Trying to figure out the exact specs is hard because DoCoMo were using an early version of the ODM model - they had a spec for what a "501" phone was supposed to do and then the various manufacturers built their own flavors, all of which were then sold by DoCoMo. That document would tell you exactly what they all had in common, but it was presumably under NDA and doesn't seem to have ever leaked.
iNaviLink was a DoCoMo service for getting traffic status updates on your car navigation system - that was actually what I was talking about earlier that didn't work on my later model FOMA phone despite the plug being the same.
Note that all the other Japanese phone companies had broadly similar (but generally incompatible) standards for this - and even in the case where the handsets were basically compatible with the network standards you would end up with a bunch of features not working because the implementation was different.
This finally resolved itself with the introduction of 3G, where eventually the Japanese started using the 3GPP UMTS 3G system just like everyone else.
For the response messages mentioned above (eg. 38h,02h etc), Hamster Club-i contains a terrible table (at 80101F9C), plus several child tables for computing the format/length of the separate messages:
With that info, it's possible to create mimmicked response messages for the command messages. This is how far I can get when emulating that in no$psx...
That is, I am about halfway through the connection stuff (which should consist of AUTH, GW_CONNECT, and CONNECT). AUTH is passing, and the 1st half of GW_CONNECT is also passing, but 2nd half of GW_CONNECT does then unfortunately start to send other messages through the 80h-byte stream, and I haven't much of an idea what it is doing there and why, and least what kind of response it's expecting.
At least, I've tracked down some code snippets related to those 84 01 3F EB DF bytes.
The first byte (84h) contains the length (4 bytes) in lower 7bit, and some flag in upper bit.
The next two bytes (01h,3Fh) are the actual message, 01h has some fixed meaning, and 3Fh is composed by ORing two state variables with each other (with values 10h OR 2Fh). Well, and that's where I am lost, I don't know how to interprete that bytes, and where the code is checking the expected response (which might be an equally short message, but it's hard to guess how it should look like).
The last two bytes (EBh,DFh) contain some CRC16 variant, the CRC is computed on the message bytes (01h,3Fh) with initial value FFFFh, it seems to use a CRC_CCITT table... yet there may be some variation on whether or not inverting the initial and/or final value.
Code: Select all
C0h..CFh
19h
35h,x, ... , endflag(bit0)
38h,data[1]
61h,data[10h]
64h,01h
64h,02h,data[1]
64h,03h,data[6]
64h,04h
64h,06h
64h,07h
64h,0Dh,data[24h]
64h,0Eh, ... , endflag(bit0)
6Ch,01h
6Ch,02h,data[1]
6Ch,03h
6Ch,06h,data[7+1],H,L,data[HL*2],data[5],,H,L,data[HL*2],H,L,data[HL*2] ;?
6Ch,07h
6Ch,08h
6Ch,0Ah,data[5+1+3],H,L,data[HL*2],H,L,[HL*2] ;?
6Ch,0Ch
6Ch,0Dh,data[24h]
6Ch,0Eh, ... , endflag(bit0)
6Eh,data[1]
80h
81h
85h,x,01h,data[0Eh]
85h,x,02h,x,x,H,L,data[HL]
85h,x,03h,data[3]
85h,x,04h,00h,data[9],H,L,data[HL]
85h,x,04h,02h,data[8]
85h,x,05h,data[1]
85h,x,07h
86h,data[1]
87h
missing 8Ah
missing 8Bh
A3h
missing A4h
missing A5h
A6h
A7h
missing AAh (but may work as breakout code?)
missing D1h (but may work as breakout code?)
missing E0h
E2h,x, ... ,AAh ;with end_code=AAh
missing E6h
E7h,data[2]
E8h,x,x,N,data[N*2]
F1h,x,03h,x,H,L,data[HL]
F1h,x,04h,data[2]
F2h,x,02h,x,00h,x,H,L,data[HL+4]
F2h,x,02h,x,08h,x,H,L,data[HL+4]
F2h,x,02h,x,01h,x,H,L,data[HL+1]
F2h,x,02h,x,09h,x,H,L,data[HL+1]
F2h,x,03h,x,x,H,L,data[HL]
Whereas,
x = don't care for length (but actual code may insist on specific values)
H,L = high/low nibbles of HL length value
missing = not handled in length table (but exists in code)
The length table contains many messages that aren't handled in actual code.
Code: Select all
Hamster Club-i
*** Simulated known Patch: get_imode_irq_hook_addr
imode recv msg <-- 38 02
imode send msg --> 85 01 01 02 00 0C 04 05 0A 0F 0D 0D 00 03 00 00 01 (auth start)
imode recv msg <-- 85 01 04 00 01 02 03 04 05 06 07 08 00 08 01 02 03 04 05 06 07 08
imode send msg --> 85 01 04 02 03 09 03 03 04 01 09 0E (auth crypt)
imode recv msg <-- 85 01 02 00 00 00 08 01 02 03 04 05 06 07 08
imode send msg --> 85 01 05 02 (auth done)
imode send msg --> F2 00 01 02 08 00 00 00 00 (gw_connect)
imode recv msg <-- F2 00 02 00 08 00 00 04 01 02 03 04 05 06 07 08
imode send stream --> 84 01 3F EB DF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
imode send stream --> 84 01 3F EB DF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
imode send stream --> 84 01 3F EB DF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
imode send stream --> 84 01 3F EB DF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
imode send msg --> F2 00 01 02 00 00 00 00 00 (gw_disconnect)
imode recv msg <-- F2 00 02 00 00 00 00 04 00 01 00 00 01 02 03 04
imode send msg --> 85 01 06 (deauth)
Note: Additionally, I am sending a dummy resonse byte during inactivity
to keep the connection alive. For the dummy byte, I've tried D1h (which
didn't work), and AAh (which did work).
At least, I've tracked down some code snippets related to those 84 01 3F EB DF bytes.
The first byte (84h) contains the length (4 bytes) in lower 7bit, and some flag in upper bit.
The next two bytes (01h,3Fh) are the actual message, 01h has some fixed meaning, and 3Fh is composed by ORing two state variables with each other (with values 10h OR 2Fh). Well, and that's where I am lost, I don't know how to interprete that bytes, and where the code is checking the expected response (which might be an equally short message, but it's hard to guess how it should look like).
The last two bytes (EBh,DFh) contain some CRC16 variant, the CRC is computed on the message bytes (01h,3Fh) with initial value FFFFh, it seems to use a CRC_CCITT table... yet there may be some variation on whether or not inverting the initial and/or final value.
I am still workinjg on that obscure cable, and making some progress on solving the message layer for the 80h-byte stream.
First hurdle
This almost made me give up. The first thing you see when looking at the 80h-byte message handling is stuff like this:
Which looked like some weird encryption or randomizing. After adding the comments, it turned out to be some kind of code optimization that went wrong.
The N*ADD5E633h is basically a fixed point divide by BC8h (the buffer size). That kind of fixed point maths is fine for audio/video, but they must be very confident that the rounding errors won't mess up memory addressing when doing it for buffer indexing.
The X*BC8h stuff is more reliable, although I can't imagine how they could believe that the 7 ALU opcodes could be faster than 6-cycle UMUL opcode, not to mention that the rest of the program is completely unoptimized and wastes millions of clock cycles everywhere else ; )
Function Table and Code
The next thing is a huge function table with 2Fh*29h entries. Which contains different event handlers for different stages:
There are three eye-catching events (timeout_retry, timeout_giveup, and timer_tick). So it's quite clear that those function vectors are related to events.
And next, there are about 5600 lines of code for handling the 80h-byte stream messages, half of it is generic code, and the other half contains the event handlers... which are unfortunately mostly changing some flags and variables, without any obvious hints on what they are supposed to do.
I've spend about a week on disassembling those 5600 lines, without getting a glimpse of an idea about the overall program flow - until finally finding the code for response handling...
Response Messages
With that, I can probably piece it together and figure out which replies result in which commands (and vice-versa).
Half of the replies seem to be invalid, and only a few dozen are actually used. So it's (maybe) not too difficult to emulate them (unless those 5600 lines of code do contain anything that's actually important for message handling).
Hmmm, as far as I remember some I-mode document mentioned something about 5bit headers... I wonder if that could correspond to the above Reply bitfields... and if so, if I have finally reached a software layer that is officially documented somewhere?
Cable Hardware
The actual cable may also need some more research. I have the feeling that it might contain two serial buses, one for the auth/connect messages, and one for the 80h-byte messages.
First hurdle
This almost made me give up. The first thing you see when looking at the 80h-byte message handling is stuff like this:
Code: Select all
800DC518 00001810 mov r3,hi ;N*ADD5E633h/100000000h ;#
800DC51C 00671821 add r3,r7 ;N*1ADD5E633h/100000000h ;
800DC520 00031AC3 sar r3,0Bh ;N*1ADD5E633h/80000000000h ;uh? ;
800DC524 00621823 sub r3,r2 ;round-up if negative? ;/
800DC528 00032840 shl r5,r3,1h ;N*1ADD5E633h/80000000000h*2 ;#
800DC52C 00A32821 add r5,r3 ;N*1ADD5E633h/80000000000h*3 ;
800DC530 00052900 shl r5,4h ;N*1ADD5E633h/80000000000h*30h ;
800DC534 00A32823 sub r5,r3 ;N*1ADD5E633h/80000000000h*2Fh ;
800DC538 000528C0 shl r5,3h ;N*1ADD5E633h/80000000000h*178h ;
800DC53C 00A32821 add r5,r3 ;N*1ADD5E633h/80000000000h*179h ;
800DC540 000528C0 shl r5,3h ;N*1ADD5E633h/80000000000h*BC8h ;/
800DC544 00E52823 sub r5,r7,r5 ;N - N*1ADD5E633h/80000000000h*BC8h ;#
800DC548 00052C00 shl r5,10h ;
800DC54C 00052C03 sar r5,10h ;/
800DC550 00101840 shl r3,r16,1h ;X*2 ;#
800DC554 00701821 add r3,r16 ;X*3 ;
800DC558 00031900 shl r3,4h ;X*30h ;
800DC55C 00701823 sub r3,r16 ;X*2Fh ;
800DC560 000318C0 shl r3,3h ;X*178h ;
800DC564 00701821 add r3,r16 ;X*179h ;
800DC568 000318C0 shl r3,3h ;X*BC8h ;/
The N*ADD5E633h is basically a fixed point divide by BC8h (the buffer size). That kind of fixed point maths is fine for audio/video, but they must be very confident that the rounding errors won't mess up memory addressing when doing it for buffer indexing.
The X*BC8h stuff is more reliable, although I can't imagine how they could believe that the 7 ALU opcodes could be faster than 6-cycle UMUL opcode, not to mention that the rest of the program is completely unoptimized and wastes millions of clock cycles everywhere else ; )
Function Table and Code
The next thing is a huge function table with 2Fh*29h entries. Which contains different event handlers for different stages:
Code: Select all
2Fh stages (0..2Eh)
29h events (0..28h, or -1=none)
And next, there are about 5600 lines of code for handling the 80h-byte stream messages, half of it is generic code, and the other half contains the event handlers... which are unfortunately mostly changing some flags and variables, without any obvious hints on what they are supposed to do.
I've spend about a week on disassembling those 5600 lines, without getting a glimpse of an idea about the overall program flow - until finally finding the code for response handling...
Response Messages
Code: Select all
Sending/receiving command/reply messages can be done via the 80h-byte portion of
command 14h. It seems that the 80h-byte portion can contain one or more message
snippets, each starting with a length byte:
000h 1 1st DataLen (plus bit7=flag) (or 00h=None)
001h .. 1st Data[..] (last two bytes contain a CRC16) (CRC depends on flag?)
... .. More such datalen/data pairs (or 00h=None) (?)
... .. Unused padding
07Fh 1 Seems to contain some special flag in bit0 (?)
I-Mode Reply Messages on 80h-byte stream
Replies are decoded by examining the first 2-3 data bytes of the reply. The first
byte must be 01h or 03h (01 or 11 binary). The second byte consists of several
bitfields (with the overall response type in lower 1-2 bits). A few replies are
also using a third byte. Below are the supported replies (in binary):
x1_BBB0xxx0_nnnnnnnn event=0Fh (matching BBB blkno) ; x1_BBB0xxx0 event=10h (wrong BBB blkno) ;
x1_BBB1xxx0_nnnnnnnn event=11h (matching BBB blkno) ;
x1_BBB1xxx0 event=12h (wrong BBB blkno) ;/
x1_xxx00001 (aka 01h) event=14h ; x1_xxx00101 (aka 05h) event=17h ;
x1_xxx01001 (aka 09h) event=1Ah ;
01_xxx10001 (aka 11h) event=13h ;
11_xxx10001 (aka 11h) event=15h ;
01_xxx10101 (aka 15h) event=16h ;
11_xxx10101 (aka 15h) event=18h ;
01_xxx11001 (aka 19h) event=19h ;
11_xxx11001 (aka 19h) event=1Bh ;
x1_xxx0NN01 (other) event=27h (invalid) ;
01_xxx1NN01 (other) event=26h (invalid) ;
11_xxx1NN01 (other) event=28h (invalid) ;/
01_00001111 (aka_0Fh) event=23h ; 11_00001111 (aka 0Fh) event=27h (invalid) ;
01_00011111 (aka 1Fh) event=22h ;
11_00011111 (aka 1Fh) event=26h (invalid) ;
x1_00101111 (aka 2Fh) event=1Eh ;
01_00111111 (aka 3Fh) event=26h (invalid) ;
11_00111111 (aka 3Fh) event=1Fh ;
x1_01000011 (aka 43h) event=20h ;
11_01010011 (aka 53h) event=21h ;
01_01010011 (aka 53h) event=26h (invalid) ;
x1_01100011 (aka 63h) event=1Dh ;
01_01111111 (aka 7Fh) event=1Ch ;
11_01111111 (aka 7Fh) event=None/07h/08h (error, ignore/retry/giveup)
01_10000111 (aka 87h) event=25h ;
11_10000111 (aka 87h) event=27h (invalid) ;
01_10010111 (aka 97h) event=24h ;
11_10010111 (aka 97h) event=26h (invalid) ;
x1_xxx0xx11 (other) event=27h (invalid) ;
01_xxx1xx11 (other) event=26h (invalid) ;
11_xxx1xx11 (other) event=28h (invalid) ;/
xxxxxxxx (other) ignored (1st byte other than 01h or 03h or 10h+x)
xxx1xxx0 ignored single-byte reply, do NOT reload timeouts
xxxxxxxx (other) ignored single-byte reply, but DO reload timeouts
xxxxxxxx_xxxxxxxx reload timeouts (on any reply with 2 or more bytes)
The replies are triggering the events that are shown above, which are then
triggering a send_request (numbered 10h, 20h, 40h, 80h, 100h, 200h, 400h,
800h). Those send_request are then triggering event 0Ah..0Eh. And those events
are then using the send_request or other flags to decide which command message
they want to send. Those commands are usually 2 or 5 bytes tall (event 0Ah,0Bh
are additionally sending taller commands/packets)
Half of the replies seem to be invalid, and only a few dozen are actually used. So it's (maybe) not too difficult to emulate them (unless those 5600 lines of code do contain anything that's actually important for message handling).
Hmmm, as far as I remember some I-mode document mentioned something about 5bit headers... I wonder if that could correspond to the above Reply bitfields... and if so, if I have finally reached a software layer that is officially documented somewhere?
Cable Hardware
The actual cable may also need some more research. I have the feeling that it might contain two serial buses, one for the auth/connect messages, and one for the 80h-byte messages.
Got it!
It did require only a single 5-byte response on the 80h-byte stream: 84 01 73 83 57. That is, some kind of "final snippet" flag (bit7) with length (4), the actual 2-byte response (01h,73h) (which I had mistyped 01 7F in previous post). And the CRC16 (5783h) (which isn't a normal CRC16_CCITT, instead it's a less common CRC16_CCITT_REVERSE, with initial value FFFFh, and final result XORed by FFFFh).
What I am now getting with Hamster Club-i in no$psx is:
That is, it's sending a large packet with some binary header:
followed by and lengthy POST http message in ASCII:
Plus CRC16 at the very end of the packet (this appears only in the last 80h-byte snippet):
And then it does disconnect in lack of a response, but at least I've now got through the PSX/I-mode/phone-specific connection stuff... and the rest is hopefully standard HTTP which could be perhaps forwarded to real internet, or redirected elsewhere if the sites are down...
Maybe the PSX browser is even still working as is? I don't know if or how it can browse to custom webpages though, the GUI seems to be merely allowing to select an "I-Mode Menu", maybe that's just some kind of default webpage?
It did require only a single 5-byte response on the 80h-byte stream: 84 01 73 83 57. That is, some kind of "final snippet" flag (bit7) with length (4), the actual 2-byte response (01h,73h) (which I had mistyped 01 7F in previous post). And the CRC16 (5783h) (which isn't a normal CRC16_CCITT, instead it's a less common CRC16_CCITT_REVERSE, with initial value FFFFh, and final result XORed by FFFFh).
What I am now getting with Hamster Club-i in no$psx is:
Code: Select all
imode recv msg <-- 38 02
imode send msg --> 85 01 01 02 00 0C 04 05 0A 0F 0D 0D 00 03 00 00 01 (auth start)
imode recv msg <-- 85 01 04 00 01 02 03 04 05 06 07 08 00 08 01 02 03 04 05 06 07 08
imode send msg --> 85 01 04 02 03 09 03 03 04 01 09 0E (auth crypt)
imode recv msg <-- 85 01 02 00 00 00 08 01 02 03 04 05 06 07 08
imode send msg --> 85 01 05 02 (auth done)
imode send msg --> F2 00 01 02 08 00 00 00 00 (gw_connect)
imode recv msg <-- F2 00 02 00 08 00 00 04 01 02 03 04 05 06 07 08
imode send stream --> 84 01 3F EB DF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
imode send stream --> 58 01 00 01 49 ED 10 0A 01 01 01 01 8C 01 FF 00 0A 09 48 21 C0 03 B7 50 4F 53 54 20 68 74 74 70 3A 2F 2F 6E 65 2D 6E 65 74 2E 63 6F 6D 2F 68 63 2F 69 2F 70 73 2F 41 72 65 6E 61 50 61 72 74 79 2E 63 67 69 20 48 54 54 50 2F 31 2E 30 0D 0A 55 73 65 72 2D 41 67 65 6E 74 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
imode send stream --> 58 3A 20 44 6F 43 6F 4D 6F 2F 31 2E 30 2F 65 78 5F 70 73 31 33 30 32 0D 0A 43 6F 6E 74 65 6E 74 2D 74 79 70 65 3A 20 61 70 70 6C 69 63 61 74 69 6F 6E 2F 78 2D 77 77 77 2D 66 6F 72 6D 2D 75 72 6C 65 6E 63 6F 64 65 64 0D 0A 43 6F 6E 74 65 6E 74 2D 4C 65 6E 67 74 68 3A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
imode send stream --> 58 20 37 38 39 0D 0A 0D 0A 75 69 64 3D 4E 55 4C 4C 47 57 44 4F 43 4F 4D 4F 26 76 61 6C 3D 25 30 41 25 30 41 25 46 46 25 31 46 25 41 44 25 31 44 5A 25 44 41 25 30 30 25 30 30 25 30 30 25 30 30 25 32 39 25 32 37 25 38 32 25 42 34 25 39 43 25 36 43 25 36 30 25 36 30 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
imode send stream --> 58 45 31 25 35 34 25 30 36 25 41 44 5A 25 46 43 25 44 37 2B 51 25 41 43 25 43 34 25 31 38 25 42 35 25 45 35 25 36 37 25 42 42 25 39 32 25 32 43 25 44 46 25 41 31 52 25 39 39 25 36 45 43 25 42 35 25 31 45 25 44 34 25 32 32 25 39 32 25 39 38 69 25 42 37 4B 25 39 38 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
imode send stream --> 58 46 43 25 31 45 25 31 31 25 45 45 25 36 45 25 38 31 25 44 44 25 46 39 25 30 45 45 25 32 39 25 42 31 25 42 33 25 46 37 72 71 25 39 43 25 46 35 6F 25 38 35 25 30 38 25 44 43 25 30 45 78 25 39 34 25 42 35 33 25 31 41 57 25 44 45 30 53 25 42 45 25 42 41 25 30 32 25 41 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
imode send stream --> 58 42 25 32 39 25 31 38 51 25 39 35 25 34 32 64 25 32 36 25 37 46 25 32 31 25 39 30 25 36 41 25 39 41 25 32 32 25 43 30 25 32 32 69 25 38 31 25 42 38 6C 25 30 42 25 42 41 25 30 36 39 49 25 41 32 25 45 45 25 43 38 25 35 46 45 25 31 41 25 45 36 25 38 42 25 37 46 25 46 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
imode send stream --> 58 45 25 45 37 25 35 36 59 25 30 44 62 25 41 35 25 32 39 25 39 44 25 42 30 25 37 46 68 25 39 41 25 32 33 25 39 43 25 35 31 25 45 45 25 30 37 25 42 31 25 33 46 25 41 43 5A 25 37 44 25 43 34 25 46 46 4A 25 39 33 25 38 38 25 44 35 73 25 45 36 25 45 38 4B 25 44 35 25 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
imode send stream --> 58 36 4A 25 44 37 25 39 37 25 37 44 42 37 25 37 44 25 46 38 66 25 31 44 25 32 41 75 25 46 31 25 39 37 25 31 37 41 25 31 41 25 34 30 4F 25 30 46 32 25 32 39 25 46 30 25 43 37 25 38 30 25 38 35 25 36 32 25 31 35 25 44 43 25 31 36 54 25 41 43 25 30 45 25 35 42 25 37 42 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
imode send stream --> 58 25 35 45 25 45 34 25 37 36 25 30 41 25 44 44 25 31 35 25 44 46 25 46 30 4E 25 44 39 25 43 42 25 44 34 25 39 33 25 34 34 5A 25 44 31 55 66 25 38 33 25 46 31 25 44 34 25 32 34 25 42 46 6B 6E 25 44 35 78 25 39 43 25 46 31 25 39 43 30 25 43 37 25 41 30 25 38 38 25 37 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
imode send stream --> 58 32 25 38 44 25 30 37 6C 79 25 32 41 25 37 46 25 37 46 25 41 31 75 25 37 46 25 42 34 25 39 31 25 39 36 25 41 39 25 44 38 25 32 36 25 38 34 25 39 30 6D 25 31 45 46 4B 48 25 38 39 25 45 35 25 42 42 25 45 43 25 46 30 33 25 39 42 25 41 35 42 25 33 46 4C 64 25 38 32 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
imode send stream --> 58 39 33 25 35 45 25 35 45 33 34 25 44 45 63 25 37 46 57 62 25 46 45 25 32 39 25 45 33 25 44 35 52 38 25 41 42 25 30 33 25 41 46 61 67 25 45 34 25 46 37 31 77 25 41 38 25 42 33 25 46 46 58 25 38 36 25 46 34 25 39 34 25 45 32 45 25 45 42 25 39 36 25 43 44 25 31 33 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
imode send stream --> 87 30 33 25 30 37 91 58 84 01 3F EB DF 84 01 3F EB DF 84 01 3F EB DF 84 01 3F EB DF 84 01 3F EB DF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
imode send stream --> 84 01 3F EB DF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
imode send stream --> 84 01 3F EB DF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
and, after long delay/timeout...
imode send stream --> 8B 01 00 01 DA FE 20 01 05 00 2B 5A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
imode send stream --> 84 01 3F EB DF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
imode send stream --> 84 01 53 81 76 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
imode send msg --> F2 00 01 02 00 00 00 00 00 (gw_disconnect)
imode recv msg <-- F2 00 02 00 00 00 00 04 00 01 00 00 01 02 03 04
imode send msg --> 85 01 06 (deauth)
Code: Select all
01 00 01 49 ED 10 0A 01 01 01 01 8C 01 FF 00 0A 09 48 21 C0 03 B7
Code: Select all
POST http://ne-net.com/hc/i/ps/ArenaParty.cgi HTTP/1.0
User-Agent: DoCoMo/1.0/ex_ps1302
Content-type: application/x-www-form-urlencoded
Content-Length: 789
uid=NULLGWDOCOMO&val=%0A%0A%FF%1F%AD%1DZ%DA%00%00%00%00%29%27%82%B4%9C%6C%60%60%E1%54%06%ADZ%FC%D7+Q%AC%C4%18%B5%E5%67%BB%92%2C%DF%A1R%99%6EC%B5%1E%D4%22%92%98i%B7K%98%FC%1E%11%EE%6E%81%DD%F9%0EE%29%B1%B3%F7rq%9C%F5o%85%08%DC%0Ex%94%B53%1AW%DE0S%BE%BA%02%AB%29%18Q%95%42d%26%7F%21%90%6A%9A%22%C0%22i%81%B8l%0B%BA%069I%A2%EE%C8%5FE%1A%E6%8B%7F%FE%E7%56Y%0Db%A5%29%9D%B0%7Fh%9A%23%9C%51%EE%07%B1%3F%ACZ%7D%C4%FFJ%93%88%D5s%E6%E8K%D5%16J%D7%97%7DB7%7D%F8f%1D%2Au%F1%97%17A%1A%40O%0F2%29%F0%C7%80%85%62%15%DC%16T%AC%0E%5B%7B%5E%E4%76%0A%DD%15%DF%F0N%D9%CB%D4%93%44Z%D1Uf%83%F1%D4%24%BFkn%D5x%9C%F1%9C0%C7%A0%88%72%8D%07ly%2A%7F%7F%A1u%7F%B4%91%96%A9%D8%26%84%90m%1EFKH%89%E5%BB%EC%F03%9B%A5B%3FLd%82%93%5E%5E34%DEc%7FWb%FE%29%E3%D5R8%AB%03%AFag%E4%F71w%A8%B3%FFX%86%F4%94%E2E%EB%96%CD%13%03%07
Code: Select all
91 58
Maybe the PSX browser is even still working as is? I don't know if or how it can browse to custom webpages though, the GUI seems to be merely allowing to select an "I-Mode Menu", maybe that's just some kind of default webpage?
Network expert anyone?
I've examined the binary packet header. It does contain a TCP-style 16bit checksum, but the rest doesn't look like TCP. Is that some other common standard format?
Packet Type can have following values:
Packets with Type other than 10h have different formats, other than shown above.
I've examined the binary packet header. It does contain a TCP-style 16bit checksum, but the rest doesn't look like TCP. Is that some other common standard format?
Code: Select all
Pre 3 Send Command (01h,00h,01h) (imode/cable-specific send command)
000h 2 TCP-style Checksum (sum of following big-endian 16bit values plus carry outs)
002h 1 Packet Type (10h) (can have other values, see below)
003h 1 Unknown (0Ah)
004h 1 Unknown (01h) (composed of bit0-6, plus bit7)
005h 1 Unknown (01h) (composed somehow)
006h 1 Unknown (01h)
007h 1 Unknown (01h)
008h 1 Unknown (8Ch)
009h 1 Unknown (01h)
00Ah 1 Unknown (FFh)
00Bh 1 Unknown (00h)
00Ch 1 Unknown (0Ah)
00Dh 1 Option Flags (09h) (indicates presence of below optional components)
... 2 Unknown (4821h) ;-when bit3=1 ;'
... 1 Unknown (-) ;-when bit1=1 ; Optional
... 1 Unknown (C0h) ;' ;
... 2 Data Length (03B7h) ; when bit0=1 ;
... 3B7h Data ("POST http://ne-net.com/"..) ;/ ;/
Code: Select all
All values: 10h,11h,12h,20h,21h,30h,31h,40h,41h,50h,60h
For Send: 10h, - , - ,20h,21h,30h,31h, - ,41h,50h,60h
For Receive: - 11h,12h,20h,21h,30h,31h,40h, - ,50h,60h
Some I-Mode documentation does actually exist in public.
DoCoMo Technical Journal
The "DoCoMo Technical Journal" contains four "Special Issue on I-mode
Service" articles:
Media Concept https://www.docomo.ne.jp/english/binary ... _010en.pdf
Network System https://www.docomo.ne.jp/english/binary ... _014en.pdf
i-mode Server https://www.docomo.ne.jp/english/binary ... _020en.pdf
Micro Browset https://www.docomo.ne.jp/english/binary ... _026en.pdf
That includes some technical overview about the network layers... instead of "TCP/IP" they are using a custom "TLP" (or short "TL") protocol.
Patents
I've found one patent, it's rather incomplete, and it's from 2007 (much newer than the PSX stuff), but it's clearly matching the packet format used in the PSX.
https://patentimages.storage.googleapis ... 22290C.pdf
FIG.5 is a packet transfer flowchart
FIG.8,9,10 are packet formats
EDIT: That stuff is also in an US patent, https://patents.google.com/patent/US6898640 (which is available in better quality than the ugly CA2322290C scan).
Message Types
Merging the info from the disassembly and from the patent, there are these messages types:
The PSX is copying the header bytes to/from internal variables... the undocumented packets are mostly using the same variables as the documented ones (or a subset thereof), so it should be relative easy to resolve the contents of those undocumented packets.
DoCoMo Technical Journal
The "DoCoMo Technical Journal" contains four "Special Issue on I-mode
Service" articles:
Media Concept https://www.docomo.ne.jp/english/binary ... _010en.pdf
Network System https://www.docomo.ne.jp/english/binary ... _014en.pdf
i-mode Server https://www.docomo.ne.jp/english/binary ... _020en.pdf
Micro Browset https://www.docomo.ne.jp/english/binary ... _026en.pdf
That includes some technical overview about the network layers... instead of "TCP/IP" they are using a custom "TLP" (or short "TL") protocol.
Patents
I've found one patent, it's rather incomplete, and it's from 2007 (much newer than the PSX stuff), but it's clearly matching the packet format used in the PSX.
https://patentimages.storage.googleapis ... 22290C.pdf
FIG.5 is a packet transfer flowchart
FIG.8,9,10 are packet formats
EDIT: That stuff is also in an US patent, https://patents.google.com/patent/US6898640 (which is available in better quality than the ugly CA2322290C scan).
Message Types
Merging the info from the disassembly and from the patent, there are these messages types:
Code: Select all
10h Send - len=0Eh + options + datalen.16bit patent.FIG.8 ;connect req
11h - Recv len=0Dh + options + datalen.16bit patent.FIG.9 ;connect ack
12h - Recv len=5 ;connect ?
20h Send Recv len=6 + ...
21h Send Recv len=6 + ...
30h Send Recv len=9 + datalen.16bit patent.FIG.10A ;data
31h Send Recv len=5
40h - Recv len=7 + datalen.16bit
41h Send - len=4
50h Send Recv len=6 + len.8bit
60h Send Recv len=4
? ? ? len=4..5 patent.FIG.10B ;ack
Who is online
Users browsing this forum: No registered users and 1 guest