PCM Hammer P04 Support Project

They go by many names, P01, P59, VPW, '0411 etc. Also covering E38 and newer here.
User avatar
Gampy
Posts: 2331
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer P04 Support Project

Post by Gampy »

Damn you Antus, you're invalidating all my excuses for not doing this, now how am I going to get out of doing it ... :x

WriteVPW_a0_buffer_d0_length chokes with anything over 10 bytes and PCMHammer expects a 15 byte CRC response.
[05:26:48:223] TX: 6C 10 F0 3D 02 01 00 00 01 00 00
[05:26:48:336] RX: 6C F0 10 7D 02 01 00 00 01 00 00 67 86 6E C2
After 20 hours of it rebooting no matter what I did, I finally realized I forgot to scratch that damn dog! Roaring mad I am, wasted all that time! :oops:
Reverted to original attempt, added a dog scratcher and it again rebooted ... WTF!
That's when I found WriteVPW_a0_buffer_d0_length chokes with anything over 10 bytes.

So, I shortened the response and it worked, I can get a valid matching CRC from a PCM! :D :thumbup:

However, not with PCM Hammer yet, I only quickly looked at PcmHammer to see if it really needs the length and address returned with the results, or if we can just return the CRC, we should be able to.

This needs to get inlined into the current C Kernel! It's so fast!

Good job!

-Enjoy
Intelligence is in the details!

It is easier not to learn bad habits, then it is to break them!

If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: PCM Hammer P04 Support Project

Post by antus »

Good to know its so fast, I thought it might be, there are no costly opcodes there and there are so fewer instructions compared to the supposed fast one with the lookup table. I didnt want to call it early though :thumbup:

You started with my test kernel which was never for reading a pcm. This kernel is from binreader[1] v1.03 which was the last one that didnt use rle compression to save space on the wire. It should be fine. It uses 'wastetime' function to scratch the watchdog and not overrun the buffers. Im keen to follow through on this and get a asm kernel for all pcms, and create a loader for p04. I need your help though. Its too much for one person and I'd go insane on my own. I need someone to help keep making progress so there is always a shiny new fun challenge. We could always implement the RLE compression later too. I wont attach that version now though, its just unneeded complexity.

[1] viewtopic.php?f=42&t=3111&p=33505
Attachments
readcode.asm
(11.6 KiB) Downloaded 44 times
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
Gampy
Posts: 2331
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer P04 Support Project

Post by Gampy »

Looks pretty much like the same code ... I think I have readcode.asm tucked away somewhere.

Come on, you know I love doing this, I just need a little kick in the right direction now and again ... Especially with math shit.

I just built PCM Hammer with modified CRC, it failed because of the repeating requests over and over and over as many as 18 times for 1 crc result! :shock: :?
Need to go teach it to have more patience.

-Enjoy
Intelligence is in the details!

It is easier not to learn bad habits, then it is to break them!

If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
User avatar
Gampy
Posts: 2331
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer P04 Support Project

Post by Gampy »

Antus,

If your readcode.asm works for you, see if you can get "WriteVPW_a0_buffer_d0_length" to send more then 10 bytes.

I'll zip you what I got after I cleanup a bit, but that's is what I am working on, either making the above work with more bytes or make PCMHammer accept fewer ...
Actually, I'm adding OsID lookup in the Kernel right now.

-Enjoy
Intelligence is in the details!

It is easier not to learn bad habits, then it is to break them!

If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: PCM Hammer P04 Support Project

Post by antus »

Well it does work, because im reading 4k packets on my AVT with binreader v1.3 which that kernel is from. So... not sure why you get different results. Maybe there is a problem with it, one which the AVT doesnt have a problem with? Not sure. Though if its crashing the pcm then its something else.

Yes, I know you enjoy it. You wouldnt be here if you didnt. All good.

Yes pcmhammer has to do that, its to solve timing issues where interfaces time out at different times while the CRC is calculated. So pcmhammer polls and the pcm iterates in 8kb blocks per request saying "not ready..." "not ready..." until it is, then "here ya go!". So the functon needs to be wrapped in something that stores the offset and the remainder. Then each time its called it needs to process the next 8kb then return. When its all done, then the caller sends the remainder which is the main working variable, and also the CRC when its done back to the pcm. Then there are no timing problems across the supported interfaces. It'd be really convenient if the pcms had multiple threads, but alas... The gotcha I couldnt easily solve another way was with background processing in the main loop the DLC was missing packets inbound from pcm hammer etc. The remainder (while calculating) / crc (when complete) is in D0.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
Gampy
Posts: 2331
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer P04 Support Project

Post by Gampy »

antus wrote:Well it does work, because im reading 4k packets on my AVT with binreader v1.3 which that kernel is from. So... not sure why you get different results. Maybe there is a problem with it, one which the AVT doesnt have a problem with? Not sure. Though if its crashing the pcm then its something else.
No it does not work for a byte count greater then 10!
Read the code.
WriteVPW_a0_buffer_d0_length is not used for a Mode 35 read transfer ... DoReadBlockTransfer_A0_Address_D0_Length is used for that!

I guess you didn't look to close at all those logs I posted either, because everyone of them was using 4k packets.
antus wrote: Yes pcmhammer has to do that, its to solve timing issues where interfaces time out at different times while the CRC is calculated. So pcmhammer polls and the pcm iterates in 8kb blocks per request saying "not ready..." "not ready..." until it is, then "here ya go!".
No it does not ... I have done it in a single query & response session.
But my CRC code in my Colonel.c kernel is much better and faster then what is used in PCMHammers C kernels ...
It's just not fancy and pretty like PCMHammers code is!

-Enjoy
Intelligence is in the details!

It is easier not to learn bad habits, then it is to break them!

If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: PCM Hammer P04 Support Project

Post by antus »

Gotcha. Im brain wrecked, end of a huuuge week at work this week. Good stuff!
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: PCM Hammer P04 Support Project

Post by antus »

Ive looked more closely at the code, so the block transfer function checks the status of the TX fifo and handles it, the other function that just sends the header does not, so it looks like it'll just overrun the FIFO if you go to long and crash. So you need to either copy the fifo checking code to the header function, or re-organise the tx code maybe to make it shareable, or maybe to use the same code in both scenareos. Its not that many bytes its probably worth just duplicating it now, and we optimise further later. It'll still be way smaller than the C version, and not an issue anyway when we are using a loader.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
Thorwon
Posts: 95
Joined: Wed Jan 16, 2019 1:34 am
cars: 2007 Hemi powered JKUR
1987 YJ
1955 CJ5
1988 MJ Comanche
Location: Commerce GA.

Re: PCM Hammer P04 Support Project

Post by Thorwon »

MudDuck514 wrote:
Thorwon wrote: SNIP
You're welcome.
I still have hopes of running a inline 6 Jeep engine with this PCM. I'm not a programmer, but anything I can help with I will.
Just a thought, are you aware that the Aurora used a dual pickup Crank Position Sensor?

Mike
Ya know I had forgotten about that. But I'll have to make the reluctor anyway. :thumbup:

That shouldn't be too difficult.
Bad things happen FAST!!!
User avatar
Gampy
Posts: 2331
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer P04 Support Project

Post by Gampy »

Yea, WriteVPW_a0_buffer_d0_length needs buffering so we can send longer replies.

But damn that CRC code is fast ... Just over 1 second (~1.031) for a P59 AMD Os sector.
And just under 3 seconds (~2.765) for a 256kb sector on a P12b (addr:100000)

Should be able to remove the CRC polling technique in PCMHammer in favor of a simple request and wait.

-Enjoy
Intelligence is in the details!

It is easier not to learn bad habits, then it is to break them!

If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
Post Reply