PCMHammer P04

[ProfessWRX]

I've started a disassembly of Gampys beta p04 kernel so I can understand that more. I don't see it on github anywhere.

[antus]

Look at the antus/p08 branch, its a fork of that. The magic is in the alignment, there wont be much difference. Perhaps a couple of different opcodes, but the p08 version works as well. The magic part is still not 100% understood, there are things in the hardware of this platform that we probably never will understand. You can add a single nop so some bytes move and it fixes or breaks the kernel. That is the problem we have not been able to solve. I would like to see Gampys code too, as I would like to just code freeze it and have multiple versions in the source tree with a warning about the stability but he does not want to release it at this stage. If we get the code we'll use it. If we do not then we'll have to revert to antus/p08 branch and implement some copies of kernel.s and code freeze it there. https://github.com/LegacyNsfw/PcmHacks/ ... 08/Kernels

If you would like to help work on pcmhammer that would be awesome. There are more loose ends in the app, than the kernel at this stage. Do you know enough C# to help with the front end? I know what we need to do, but dont have the time.

[ProfessWRX]

I taught myself c coding working on the same stuff on Subarus.
I piggybacked off another guys work and copy pasted until I understood it better.
Then I was able to write full routines inside his framework.

So I’m able to follow a lot of the code around but because my work was inside an ecu and I had his framework it made it quite simple.
I have no idea how computers talk to each other or how to write programs.
I don’t even understand how git works.

The good news is: I know what I know and I know what I don’t and I can always find the info I need.

All that said, If you give me a mission and tell me where the work is done I’ll figure it out. I always do. I can learn anything.

[ProfessWRX]

Also as far as your kernel I noticed you’re putting it in an area that the pcm uses. I was quite surprised by that. If you’re not clearing out the ram before you use it it’ll cause issues like you say. Or if the pcm still needs it while the kernel is running it’ll do the same.
I assume you already know all that though.

[antus]

We move the stack and disable interrupts, that is all that is needed. RAM is at a premium, it is all used, so overwrite is normal. Because its overwrite it does not matter what was there beforehand. No RAM is used uninitialized at runtime. Packet size is read from the header so checksum, for example, does not run off the end of any received packet.
However if you have more knowledge of the internals of the P04 and you know how to modify the code or where to load it to improve stability, go for it. I don't mean that the kernel we build is unstable, but the source is. Small changes can outright break the kernel and we can't explain this. If you can, you would be a legend.

[ProfessWRX]

We move the stack and disable interrupts, that is all that is needed. RAM is at a premium, it is all used, so overwrite is normal. Because its overwrite it does not matter what was there beforehand. No RAM is used uninitialized at runtime. Packet size is read from the header so checksum, for example, does not run off the end of any received packet.
However if you have more knowledge of the internals of the P04 and you know how to modify the code or where to load it to improve stability, go for it. I don't mean that the kernel we build is unstable, but the source is. Small changes can outright break the kernel and we can't explain this. If you can, you would be a legend.

Can you send me some working kernels and some broken ones? Maybe a list of changes so I can look quickly?

[ProfessWRX]

I could be way off base, but here's another question, you move the stack, but if in the process of running the modes what if it's pulling from a RAM address?

Specifically ROM:0000D68E 010 tst.w (word_FFFF8400).w ; Test an Operand
(12588500)
I again, have no idea how the Modes work and I haven't run the logic on any of them, but I think that's something for mode 2. So if mode 2 is run, if it's running through that code would it read that Ram Address which is not what it's expecting? That's just the first one I found. If this is an issue, I could easily check for others.

[antus]

The OS shuts down its tasks before jumping to RAM, so the system is idle when the kernel runs. It wont accept a mode 36 upload unless criteria are met that it is safe to do so. (engine not running, car not moveing etc). Then the kernel should be the only thing running. But we cant be 100% sure of this, as we dont have details of the hardware. It is how the factory and after market tools all work, and it is the official though proprietary way.

[ProfessWRX]

Ok, I'm looking at something weird in the Kernel. It's the same problem in the p08 and p10 kernels.

Code: Select all

ROM:0000006E                     cmpi.w  #$3D03,d0       ; Compare Immediate
ROM:00000072                     beq.w   sProcessOSID    ; Branch if Equal
ROM:00000076                     cmpi.w  #$3D05,d0       ; Compare Immediate
ROM:0000007A                     beq.w   sProcessEraseSector ; Branch if Equal
ROM:0000007E                     lsr.w   #8,d0           ; Logical Shift Right
ROM:00000080                     cmpi.b  #$34,d0 ; '4'   ; Compare Immediate
ROM:00000084                     beq.w   sProcessMode34  ; Branch if Equal
ROM:00000088                     cmpi.b  #$35,d0 ; '5'   ; Compare Immediate
ROM:0000008C                     beq.w   sProcessMode35  ; Branch if Equal
ROM:00000090                     cmpi.b  #$36,d0 ; '6'   ; Compare Immediate
ROM:00000090     ; ---------------------------------------------------------------------------
ROM:00000094                     dc.b $67
ROM:00000095                     dc.b $FF
ROM:00000096                     dc.b   0                                                                   <-----------Something's wrong with this.
ROM:00000097                     dc.b   0
ROM:00000098                     dc.b 4
ROM:00000099                     dc.b $56 ; V
ROM:0000009A     ; ---------------------------------------------------------------------------
ROM:0000009A                     cmpi.b  #$20,d0 ; ' '   ; Compare Immediate
ROM:0000009E                     bne.s   sMainLoop       ; Branch if Not Equal
ROM:000000A0                     movea.l #unk_FF8796,a0  ; Move Address
ROM:000000A6                     move.w  #4,d0           ; Move Data from Source to Destination
ROM:000000AA                     bsr.w   sVPW_Send       ; Branch to Subroutine
ROM:000000AE                     bsr.w   sWasteTime      ; Branch to Subroutine
ROM:000000B2                     reset                   ; Reset External Devices
ROM:000000B4

[ProfessWRX]

that 67 is the start of a branch command, but ff after is supposed to be 00 and then it's the Hex offset to branch to.
The FF 00 00 04 56 is not code.

That's a 6 byte command and it's supposed to be 4.

Should be 67 00 04 56.