PCM Hammer P12 development

[antus]

No worries, its always a fun game, and with useful outcomes too. Especially Gampy on this one. Reverse engineering is fun game, but what you can do varies region to region. I think we can find all the information we need without too much trouble. What tends to be harder is building our own stuff and getting it right. You can see the process for this here but the little gotchas are often not obvious and you spend most of the time getting stuck somewhere you didn't expect when you started and you just don't know this ahead of time. Its the old story - the fix? a $2 nut. the cost? $200,000 of time and experience to know where to put it. You really need to experiment and try try again to figure out why your code which 'should work'[tm] does not.

[Gampy]

No worries, its always a fun game

Ask my bare bloody scalp if it's having fun, or all the hair scattered about me on the floor!
Or ask my eyelids, the toothpicks are starting to poke through!

Gawd I love this stuff!

Ok, I've decided to try something different ...

I have sent a test with a larger than 2048 byte kernel, using LS1 DLC's, FA55 and FA21 COPs and address FF2000, my goal is just to see it handle a multi-part kernel ...

[Gampy]

Whoo Hoo, we have bared some fruit ... A nibble at least!

We got a response from the PCM after an upload ...
Unfortunately it's priority 6C we are expecting 6D, easy fix!

edit; Wrong, it does support mode3680 ...
But the bigger find is, this PCM does not recognize Mode36.80 only Mode36.00.

[12:08:44:460] TX: 6D 10 F0 36 00 07 62 FF 28 00 . . . . . . . . . . Wacked for brevity
[12:08:45:960] RX: 6C F0 10 76 00 73
[12:08:45:960] Ignoring message: UnexpectedResponse 6C F0 10 76 00 73

I'm going to build another version of VPW Explorer that only sends one Mode36.00 packet and expects a priority of 6C and see where that goes ...

Edit,
Next test is in the outbox.

[kur4o]

This seems to come from pcm and not flash routine.

The execute might be done by sending mode 34 with addressing or something after you upload code.
Not very clear yet. Or upload a separate empty execute only message.

I will try to get that cleared soon.

[Gampy]

It does come from the PCM Os, it is exactly what I expect and have been looking for ...

The PCM receives the upload, responds with success, then if it was a mode36.00 it waits for the next packet, if it was a mode36.80 it jumps to the kernel ...

edit,
In the case of the P04, it accepted 1 mode36.00 packet, responded with success, then jumped to the provided address.

[kur4o]

This ones works different.

You send mode 34 before each upload event. For execute it is unclear what will work. Factory reflash seems to use non standard communication, and the communication is done by pcm and not by flash routine. However I saw jsr(a2) in dissasembly, so it must be supported.

Before first block transfer of bin you send full mode 34 with size and address, where it will be uploaded. I guess this triggers the reflash event.

[Gampy]

It refuses mode 34 with size and address ...

Sure wish I had an sps log or the like.

[kur4o]

It will if not in range, that is unknown. try ffff4000.

ALso the full upload sequence must be done before that.

SO here is how factory stuff works.

mode 34
mode 3600 load at ffff2000

mode 34
mode 3600 load at ffff6000

mode 34
mode 3600 load at ffff6e00

mode 34 00 10 00 ff 40 00
upload first part of bin at ffff4000

We will need to reverse the execute sequence from disassembly I guess.

[darkman5001]

It refuses mode 34 with size and address ...

Sure wish I had an sps log or the like.

An SPS log? Tell me exactly what you need. I have SPS on standalone.

[kur4o]

looked at the disassembly.

It supports 36 80 for sure, also figured cop2

eori.b #$80,(byte_FFFFFA21).w

Must be spaced from cop1, not executed at the same time.

Now to figure exact sequence of uploading, and some filters if there is any.