Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

PSX keypad DIY,it's killing me!

Status
Not open for further replies.
Hi guys, as is described in the title, I'm trying to build a PSX keypad from scratch and use it on a PlayStation2 machine. So far, I've been successful making it work on a PSX-USB PC adaptor. The computer recognizes the adaptor as an HID, and when I plug in my custom made device, it works as a general keypad. But problem arose when I tried to connect it to the PS2 machine. The machine didn't recognize it.

I did a lotta work collecting useful info before starting everything. The result which came up most frequently was a *.txt file with logic analysis done by a Japanese. There were also a few forums regarding related issues where I spotted a few threads ending up with no application specific information.The txt file was all the reference I had. It will be included later in the attachment.

The system I built to work as a keypad is based on an ATmega8L AVR microcontroller running at 8MHz internal oscillation. According to the reference file, the PSX hardware interface has at least 7 wires, they are:ACK, CLK, -CS, Vcc, GND, CMD and DAT. Byte aligned data is transferred in serial through the interface. Lines CLK, CMD and DAT form the LSB first synchronous bus, which exactly complies the logical characteristics of the SPI bus in the ATmega8L. I wired up the interface as below:

Wire Pin
ACK <-- PB1(Any general IO could output acknowledge)
CLK --> SCK(Serial clock of the AVR's SPI module)
-CS --> -SS(Slave selection pin of the AVR's SPI module)
Vcc --> Vcc(4.3V System power supply)
GND --> GND(System ground)
CMD --> MOSI(Master out/Slave in data line of the AVR's SPI module)
DAT <-- MISO(Master in/Slave out data line of the AVR's SPI module)

The AVR's SPI module works under SLAVE mode. It's activated when -SS pin is asserted low by signal from the -CS line. According to the txt specification, a none-analog keypad interacts with the host in frames with a fixed 5-byte-length. I made the AVR do exactly it said and it worked with the adaptor on my computer. The format of such frames is:

Offset: 1 2 3 4 5
CMD(0x): 01 42 00 00 00
DAT(0x): FF 41 5A keys1 Keys2 (if no key is pressed,keys1=keys2=FF)

Because this device didn't work on PS2, I built a protocol monitor with another AVR, an ATmega16L running at 8MHz from ext crystal. Its SPI bus is used to monitor a single line at a time. It works under slave mode too, with the SCK connected to source clock and MOSI connected to the data line to be monitored. I programmed this ATmega16L so that it will record the initial 500 bytes of the first SPI bus activity and send them to the computer via an RS-232 interface for analysis. To analyze the bus interaction, the task must be conducted twice: First time on a line, and second time on the other. I disassembled an original SONY PS1 keypad, and connected its serial interface to my bus monitor. I ran the test and found a fixed pattern as below:

(ORIGINAL PAD)
Offset: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
CMD(0x): 01 42 00 00 00 01 43 00 01 01 43 00 01 01 43 00 01
DAT(0x): FF 41 5A FF FF FF 41 5A 01 FF 41 5A 01 FF 41 5A 01

Offset: 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
CMD(0x): 01 43 00 01 01 43 00 01 01 43 00 01 01 43 00 01
DAT(0x): FF 41 5A 01 FF 41 5A 01 FF 41 5A 01 FF 41 5A 01

Offset: 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
CMD(0x): 01 43 00 01 01 43 00 01 01 43 00 01 01 42 00 00 00
DAT(0x): FF 41 5A 01 FF 41 5A 01 FF 41 5A 01 FF 41 5A FF FF

Looking into this, following patters will be found easily:
A) bytes 1-5 form the classic 01 42 00 00 00 frame, with exactly standard FF 41 5A FF FF response.
B) bytes 6-9 form a new 01 43 00 01 frame. with an FF 41 5A 01 response. And this frame is repeated 9 times afterwards until the classic 5-byte frame comes back starting at the 46th byte offset.

I though I was there, and this was it. I started programming the ATmega8L. I used the unique 0x42/0x43 as synchronization marks. And arranged two branches specifically for the 5-byte and 4-byte frames. However, as I tried my device, new problem arose, this byte stream was caught by the monitor:

(DIYed PAD)
Offset: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
CMD(0x): 01 42 00 00 00 01 43 00 01 00 01 45 00 5A 5A 5A 5A
DAT(0x): FF 41 5A FF FF FF 41 5A 01 FF 41 5A 01 FF 41 5A 01

Offset: 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
CMD(0x): 5A 5A 01 45 00 5A 5A 5A 5A 5A 5A 01 45 00 5A 5A
DAT(0x): FF 41 5A 01 FF 41 5A 01 FF 41 5A 01 FF 41 5A 01

Offset: 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
CMD(0x): 5A 5A 5A 5A 01 45 00 5A 5A 5A 5A 5A 5A 01 45 00 5A
DAT(0x): FF 41 5A 01 FF 41 5A 01 FF 41 5A 01 FF 41 5A 01 FF

The nine leading bytes of the two occasions are identical. But on the DIYed pad, the PS2 started acting weird on sending the 10th byte 0x00.

Offset: 1 2 3 4 5 6 7 8 9 10
CMD(0x): 01 42 00 00 00 01 43 00 01 00
DAT(0x): FF 41 5A FF FF FF 41 5A 01 FF

Obviously my custom-made lost sync from the 10th byte. It's really difficult to figure out what happened that made the PS2 host act like this. The custom-made keypad didn't send anything wrong on the DAT line. The only thing that could have made difference would be ACK signal. I don't have a logic analyzer, neither a digital scope. There's probably no way to analyze the ACK signal. Only clue I can come up with is using the capture function of the AVR's timers and record ACK shift time interval in a byte array. But in this way, I will find it hard aligning the waveform with data bytes. So I'm stuck!

Has anyone here ever tried building a PlayStation keypad? I'd like to discuss what the 0x45 and 0x5A commands are. And maybe someone may help me figure out why the PS2 worked in a way I never saw before. My gratitude in advance.
 

Attachments

  • PS2 Connector.JPG
    PS2 Connector.JPG
    6.3 KB · Views: 316
  • PSX Protocol.txt
    16.2 KB · Views: 364
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top