There is some information scattered around the forums, but in attempt to generate our own Platform (winceimg.bin OS) files, will start gathering info here.

Condi referred me to this where Ralpharn has some info:

http://avic411.com/i...720#entry254525

However, im not convinced it's all right. Here is what I understand from looking at several versions (2.0007, 3.000, 4.0001) of this.

EU090PLT.PRG

0x0 - 0x199 - custom pioneer header (512 bytes)

0x200 - end - payload (winceimg.bin/NK.nb0/b000f?? wince image)

(note byte order is little-endian due to ARM platform)

Header:

0000: magic word - A5 5A 5A A5
0004: payload byte size word, (i.e., EU090PLT.PRG size - 512 bytes), e.g., 00 0A 8B 01 = 0x018b0a00 = 25889280
0008: crc32 word of payload bytes (0x200 - end)
000c: full version word: e.g., 4.00010 (4.000.100.000) = 00 01 00 40; 2.000700 = 00 07 00 02
0010: major version? byte/word?: e.g., version 4.xxxx = 04 00 00 00, version 3.xxxx = 03 00 00 00, etc
0011-0017: zeroes?
0018-001f: ASCII "EU090PLT"
0020-0199: FF's

able to dump rom contents of newer OS (3.x, 4.x) with:

dumpromx.exe -5 -i 0x200 -d romdump EU090PLT.PRG

(doesnt work on 2.x version with B000FF signature for some reason?)

Next step would be to try to repack. I hear somebody else repacked a wince image. Did it work? What did they use to edit? Can we just use dumpromx to add/replace files?

led0rub - 4pda.ru member gave us another info - thanks friend!:

offset 0 length 32 bit - platform signature 0xA55A5AA5
offset 4 length 32 bit - length of the file without header (payload lenght)
offset 8 length 32 bit - CRC32 crc from 0x200 till the end of the file (payoad crc32)
offset 0xC length 32 bit - agree with pionara this is version
offset 0x10 length 32 bit - unknown, always 0x00000004 (i not agree about major version, this is volume info)
offset 0x18 length 64 bit - file name without exstension.
offset 0x200 till the end of the file - DATA.

file VER to make possible update
offset 0 length 32 bit - platform signature 0xA55A5AA5
offset 4 length 32 bit - length of the VER file
offset 8 length 32 bit - this is version
offset 0xC length 32 bit - this is volume info (look HTM file)
offset 0x10 length 32 bit - always 0x00000000
offset 0x14 length 32 bit -always 0x2c
offset 0x18 length 32 bit -for PLATFORM payload length of EU090PLT.PRG (for another 0x0)
offset 0x1C length 32 bit - for PLATFORM CRC32 of EU090PLT.PRG (payload size without 0x200 header) (for another 0x0)
offset 0x20 length 32 bit - PLATFORM version (for another 0x0)
offset 0x24 length 32 bit - PLATFORM volume info (for another 0x0)
offset 0x28 length 32 bit - in all files 0x0
offset 0x2C length 32 bit - amount of files VER file describe (ie total amount of file s to write)
offset 0x30 length 32 bit - as i see always 0x1 (contex directory depth ) 0x1 = /
offset 0x34 length 0x40 bytes - UNICODE DIR NAME (full path from /)
offset 0x74 lenght 32 bit - amount of files in DIR to proceed (without DIRs)
offset 0x78 lenght 0x38 bytes - UNICODE file name
offset 0xB0 lenght 32 bit - full file lenght
offset 0xB4 lenght 32 bit - CRC32 full file lenght
etc
last 8 bytes of file - 0xA55A5AA5
and CRC32 of VER file including 0xA55A5AA5 CRC32( pos 0x - pos (lenght - 4))

once again - thanks to led0rub for the info

Ok, so im confused - I looked at CNSD-110FM, CNSD-210FM, and CNSD-310FM, and each time byte @ 0010 == byte @ 000f (major version number).

Also, the RGD (ready guard) images had the same convention. Maybe led0rub can join the conversation here... We are making some interesting progress

edit:

Ok looking into developer testmode, I saw some info screens that had Volume as this value, however interestingly, it matched the major version number. So im not sure if there is some convention here on Pioneer's part.

edit2: ok I see this always matches the Volume.dat version... perhaps pioneer wont boot an APL when apl version < volume version?