Satori Geplaatst: 15 april 2002 Geplaatst: 15 april 2002 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 Geplaatst: 20 april 2002 Geplaatst: 20 april 2002 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 Geplaatst: 20 april 2002 Auteur Geplaatst: 20 april 2002 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 Geplaatst: 22 april 2002 Geplaatst: 22 april 2002 Hallo Satori ik ben er uit bedankt voor je duidelijke uitleg en hulp Gr.
Aanbevolen berichten