I mode cable/software

BIOS, Controllers, Memory Cards, Serial I/O, Parallel I/O, etc.
danhans42
BANNED
BANNED
Posts: 329
Joined: Nov 28, 2012

I mode cable/software

Post by danhans42 » August 13th, 2013, 12:51 am

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.

Image
IMG_20130812_145026.jpg
You do not have the required permissions to view the files attached to this post.

User avatar
Shendo
Verified
C Programming Expert
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

Post by Shendo » August 13th, 2013, 12:32 pm

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).
Last edited by Shendo on August 16th, 2013, 1:20 am, edited 1 time in total.
Dev console: SCPH-7502, FreePSXBoot, CH340 serial cable.

danhans42
BANNED
BANNED
Posts: 329
Joined: Nov 28, 2012

Post by danhans42 » August 13th, 2013, 8:41 pm

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
Last edited by danhans42 on August 14th, 2013, 5:02 am, edited 1 time in total.

danhans42
BANNED
BANNED
Posts: 329
Joined: Nov 28, 2012

Post by danhans42 » August 14th, 2013, 4:58 am

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.

User avatar
Shendo
Verified
C Programming Expert
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

Post by Shendo » August 16th, 2013, 1:28 am

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.
Dev console: SCPH-7502, FreePSXBoot, CH340 serial cable.

danhans42
BANNED
BANNED
Posts: 329
Joined: Nov 28, 2012

Post by danhans42 » August 16th, 2013, 4:27 am

Inside of the cable...

Image

Image

danhans42
BANNED
BANNED
Posts: 329
Joined: Nov 28, 2012

Post by danhans42 » August 16th, 2013, 10:27 am

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.

User avatar
Shendo
Verified
C Programming Expert
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

Post by Shendo » August 16th, 2013, 12:56 pm

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.
Dev console: SCPH-7502, FreePSXBoot, CH340 serial cable.

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 549
Joined: Nov 12, 2012
Contact:

Post by nocash » August 10th, 2023, 11:04 am

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).

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 549
Joined: Nov 12, 2012
Contact:

Post by nocash » August 16th, 2023, 11:18 am

Here's the pinout for the I-mode connector and chipset...

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
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?

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 549
Joined: Nov 12, 2012
Contact:

Post by nocash » August 17th, 2023, 11:44 am

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).

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                ;/
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!!!

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).
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.

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   ;/
ASCII Strings
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)
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...?

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 549
Joined: Nov 12, 2012
Contact:

Post by nocash » August 19th, 2023, 11:33 am

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...

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
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?
Last edited by nocash on August 21st, 2023, 4:26 am, edited 1 time in total.

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 549
Joined: Nov 12, 2012
Contact:

Post by nocash » August 19th, 2023, 12:40 pm

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...
connector.gif
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.

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 549
Joined: Nov 12, 2012
Contact:

Post by nocash » August 21st, 2023, 4:20 am

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).

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?
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...

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
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.

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 549
Joined: Nov 12, 2012
Contact:

Post by nocash » August 27th, 2023, 8:58 am

I got some background info on japaenese phones via PM...
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.
And specifically on the 50x mova series...
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.

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 549
Joined: Nov 12, 2012
Contact:

Post by nocash » August 27th, 2023, 9:45 am

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:

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.
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...

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).
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.

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 549
Joined: Nov 12, 2012
Contact:

Post by nocash » September 2nd, 2023, 7:50 am

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:

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                             ;/
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:

Code: Select all

2Fh stages (0..2Eh)
29h events (0..28h, or -1=none)
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

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)
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.

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 549
Joined: Nov 12, 2012
Contact:

Post by nocash » September 4th, 2023, 12:37 pm

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:

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)
That is, it's sending a large packet with some binary header:

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
followed by and lengthy POST http message in ASCII:

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
Plus CRC16 at the very end of the packet (this appears only in the last 80h-byte snippet):

Code: Select all

91 58
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?

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 549
Joined: Nov 12, 2012
Contact:

Post by nocash » September 6th, 2023, 11:23 am

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?

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/"..) ;/            ;/
Packet Type can have following values:

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
Packets with Type other than 10h have different formats, other than shown above.

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 549
Joined: Nov 12, 2012
Contact:

Post by nocash » September 7th, 2023, 3:07 pm

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:

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
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.

Post Reply

Who is online

Users browsing this forum: No registered users and 9 guests