[Pioneer] (No)EPG checksum berekening

[Satori]

De EPG checksum berekening wordt steeds minder belangrijk nu de nieuwe firmware releases dit zelf regelen, maar ik kreeg een vraag via mail en toen ik het antwoord aan het uitschrijven was, dacht ik dat het wel aardig was om het nogmaals te posten.

 

Berekening:

 

Oude checksum = PP QQ

Nieuwe checksum = XX YY

XX = [8 bytes van oude EPG] ^ [8 bytes van nieuwe EPG] ^ [Eerste byte oude checksum]

YY = 0xFF - XX

 

Het ^ staat voor 'exclusieve of' functie.

Zo'n functie werkt op bit niveau:

In een waarheidstabel:

 

b a | Q

-----|--

0 0 | 0

0 1 | 1

1 0 | 1

1 1 | 0

 

(Voor degene die thuis een wissel - of hotel schakeling hebben moet dit bekend voorkomen)

 

Wij werken op hex niveau. Dat lijkt anders, maar is een verkorte schrijfwijze voor de bitjes.

 

De hiernavolgende 2 rijen zijn hetzelfde, maar anders weergegeven

 

00000001 00100011 01000101 01100111 10001001 10101011 11001101 11101111

0x01 0x23 0x45 0x67 0x89 0xAB 0xCD 0xEF

 

Ik heb expres 8 bytes gebruikt (de lengte van een key) om aan te geven dat daar dus 8*8 = 64 bitjes in zitten.

 

Terug naar de xor

 

Als ik nu de eerste 2 getallen hierboven xor dan gaat dat als volgt

 

getal_1: 11001101 0xCD

getal_2: 11101111 0xEF

-------: -------- ----

Xor : 00100010 0x22

 

De 2 kolommen in bitjes of hex doen dus hetzelfde.

 

- Als we een getal met zichzelf xor_ren komt er 0x00 uit (probeer maar)

- Als we een getal met 0x00 xor_ren komt er hetzelfde getal weer uit.

Deze 2 rekenregels samen betekenen dat we vij een berekening altijd alle 0x00 er uit kunnen strepen

 

We hoeven de berekning niet met de hand te doen. We kunnen de standaard calculator die bij Windows zit gebruiken.

We kiezen voor scientific mode. Vervolgens vinken we HEX aan.

 

Als we de V5 eeprom die ooit gedistribueerd is als uitgangspunt nemen vinden we als oude EPG vanaf 0xDE:

0x3B 0x00 0x00 0x00 0x60 0x00 0x00 0x00 met als checksum 0x88 0x77

 

In de nieuwe EPG willen we alle EPG bitjes op 0x00 hebben

0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

 

Dus XX = 0x3B ^ 0x00 ^ 0x00 ^ 0x00 ^ 0x60 ^ 0x00 ^ 0x00 ^ 0x00 ^ 0x00 ^ 0x00 ^ 0x00 ^ 0x00 ^ 0x00 ^ 0x00 ^ 0x00 ^ 0x00 ^ 0x88

 

Ten behoeve van onze berekening vallen alle 0x00 weg (Volgens de rekenregels die ik eerder beschreven heb)

 

We houden over:

 

XX = 0x3B ^ 0x60 ^ 0x88

 

Berekening:

 

0x3B = 00111011

0x60 = 01100000

---------------

Xor 01011011 = 0x5B

0x88 = 10001000

---------------

Xor 11010011 = 0xD3

 

Dus XX = 0xD3

ZZ = 0xFF - 0xD3 = 0x2C

 

En dus wordt de nieuwe checksum 0xD3 0x2C

 

Succes met narekenen

Satori

[Gast]

Hallo Satori,

 

00D8 = 003B

00E0 = 0060

0128 = 0088 0077

 

Satori we houden toch over :

 

XX=0x3B^0x60^0x77

 

Mag ik voor de rechtse byte :

3b xor 60 xor 77 xor = 2C

 

En voor de linkse byte:

ff xor 2C = D3

 

Dus 0128 ------------- 00D3 002C

 

Of draai ik nu de boel om ?

Ik ben er nog steeds niet uit !

M-Z hanteerd een andere berekening maar

komt wel op het zelfde neer.

Het valt wel op dat de checsum die in de

noepg file's van philips op de site van

M-Z niet overeen komen met de berekening !

 

 

Gr. Bios

[Satori]

Het doet me deugd dat er mensen zijn die hier in willen duiken en kritisch zijn.

 

Eerst even de adres-aanduiding:

 

Ik heb even bij M_Z gekeken, daarom begrijp ik hoe je aan je aanduiding bent gekomen.

Je geeft onderstaande tabel weer:

 

Uitgangspunt:

00D8 = 003B

00E0 = 0060

0128 = 0088 0077

 

Dit is niet correct.

Het is gebruikelijk om met bytes te werken.

Een byte bestaat uit 8 bits.

Een nibble bestaat uit 4 bits en dus een byte uit 2 nibbles.

Met de getallen 0-9 en de letters A-F kunnen we 16 waarden aangeven en dat zijn 4 bits en dat is dus een nibble.

Willen we een byte aangeven, dan hebben we dus 2 nibbles en dus 2 cijfers of letters nodig.

Een byte waarde varieert daarmee van 0x00 tot 0xFF. (De 0x is bedoeld om aan te geven dat het hexadecimaal is).

 

=> Ik kan geen nette tabel maken, omdat meerdere spaties door het board vervangen worden door 1 spatie, daarom heb ik soms puntjes als vulling gebruikt.

 

Uittreksel uit Pioneer eeprom:

 

.......... 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

-------------------------------------------------------

0000D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3B 00

0000E0 00 60 00 00 00 00 00 00 00 00 00 00 00 00 3B 00

000120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 88 77

 

Als we nu gaan kijken waar de bytes staan, dan vinden we 0x3B op adres 0xDE. 0x60 op adres 0xE1 en de checksum op adressen

 

0x12E en 0x12F.

Als je extra nullen aan de voorkant toevoegt, wordt het adres natuurlijk ook anders.

Vb: We vinden de bytes 0x00 0x3B op adres 0xDD.

 

De tabel bij M_Z geeft 4 nibbles per byte weer. Ik denk dat dit te maken heeft met de hex-editor die zij voor de Philips gebruiken.

 

Extract van tabel bij M_Z

........................................................v Dit is byte 0xDE

00D8: 0000 0000 0000 0000 0000 0000 003B 0000 ......;. Begin van EPG Bitmap is hier 3B (nullen).

00E0: 0000 0006 0000 0000 0000 0000 0000 0000 ........ In deze regel ook 06 nullen.

0128: 0000 0000 0000 0000 0000 0000 00F1 000E ......ñ. De laatste 2 bytes zijn de checksums

 

De berekening:

In het voorbeeld dat jij geeft, neem je de oude en nieuwe bytes, samen met het tweede byte van de checksum om het tweede byte van de nieuwe checksum te berekenen.

 

Dat is technisch goed. Er zijn nl meerdere manieren om dezelfde berekening uit voeren.

Als XX YY de nieuwe checksum is, dan is de een berekeningsmogeljkheid:

 

XX=0x3B^0x60^0x88 = 0xD3

YY=0x3B^0x60^0x77 = 0x2C

 

omdat 0x88^0x77 = 0xFF (logisch, want we eisen van de checksum dat 0xff^0x88 = 0x77) en alle andere bytes gelijk zijn, moet voor de einduitkomst XX en YY ook de som 0xFF zijn en dus maakt het niet uit om eerst XX uit te rekenen en met 0xFF^XX = YY te bepalen of andersom: eerst YY bepalen en met 0xFF^YY = XX te bepalen.

 

Soms zie je de aftrekking 0xFF - XX staan. Dit levert dezelfde uitkomst op als 0xFF ^ XX.

 

De uitkomst van M_Z is verschillend, omdat zijn uitgangspunt verschillend is. Op 0xE1 staat 0x06 ipv 0x60 en de checksum, die hij als uitgangspunt neemt, is ook anders en dus zal zijn einduitkomst met dezelfde EPG bytes ook anders zijn.

Vergeet niet dat de M_Z berekening tbv de Philips deco's is en dat ik uitga van de Pioneer BCT14xx en compatibles.

 

Succes met narekenen.

Satori

 

<small>[ 21-04-2002, 02:03: Bericht gewijzigd door: Satori ]</small>

[Gast]

Hallo Satori ik ben er uit bedankt

voor je duidelijke uitleg en hulp

 

Gr.