OldComp.cz

V případě jednobajtového XORU by měl v případě chyby nastat falešně správný test nejspíš s pravděpodobností 1:256 (0.39%), v případě dvojbajtového testu 1:65536 (0,0015%), nepletu-li se.

Pokud muze nastat chyba v jednom bitu. Ze se prehodi. Tak pravdepodobnost ze se prehodi bit na stejne pozici je u 8 bitoveho kontrolniho bajtu (1/8)^2=1/64=1.5625%
Ale asi by se do toho jeste mela zapocitat pravdepodobnost ze nastanou 2 chyby. Pokud jedna nastane 1/100. Tak 2 asi 1/10000. A to jeste vydelene tema 64.
A mozna kecam.

PS: Kdyz je vlastne jedno v jakem bitu nastane chyba a zalezi az na druhe chybe aby se trefila tak je to spis 1/8 u bajtu.
PSS: S pravdepodobnosti jedne nebo 2 chyb to bude asi urcite jine. Ale zkousel jsem to dvema zpusoby a nesedi me navzajem tak to nema ani cenu psat. Stesti ze mam zkousku z pravdepodobnostniho poctu davno za sebou. .)

_________________
Z80 Forth compiler (ZX Spectrum 48kb): https://codeberg.org/DW0RKiN/M4_FORTH

Ano, to je pravda, samoopravna, resp. samoignorujuca sa chyba
Ale popri nej moze nastat kdekolvek (v inom bite) ina, tentokrat uz kriticka chyba, ktora tymto ujde pozornosti.
No prave ! A najhorsie na tom je to, ze nech vymyslis akykolvek test (s lubovolnym poctom kaskad, zacykleny kde prvy kontroluje posledneho, viac testov kde kazdy kontroluje kazdeho), vzdy sa da vytvorit taka porucha, kde zmenou nejakeho velmi maleho poctu bitov (dva, tri, mozno styri...) mozno dosiahnut stav ze kod bude chybny a testy to nezistia.

Ještě by bylo i jiné reseni:



Potom se XXX s XXX nevyrusi, YYY tam vubec nemusi byt, když se testuje na nulu, a je potřeba projit max. 256 moznosti nez se nejake reseni najde.

To už rovnou může být původní rutina, XXX je stejně konstanta, a pokud by XXX začínalo třeba od nuly, pak
XXX xor #3E xor XXX xor ... xor ... xor #FE xor YYY xor ... = YYY
0 xor #3E xor 0 xor ... xor ... xor #FE xor YYY xor ... = YYY
0 XOR cokoliv je pořád cokoliv, nic neovlivní (takže se může vynechat).
Z čehož nám pak vyjde úžasná rovnice
#3E xor ... xor #FE xor YYY xor ... = YYY
tedy, že XOR všech těch dat včetně YYY se musí rovnat YYY (ale to bylo myslím jasné už na začátku): YYY XOR konstanta = YYY
Z čehož vyplývá, že XOR všech ostatních dat by měla být nula.

Já bych to asi oddělil, porovnávací YYY i XXX nechal jako nulu, a jeden bajt v datech použil na zarovnání těch ostatních na nulu:
0 (XXX) XOR 0 (YYY) XOR konstanta XOR konstanta = 0 (YYY)

Zacinam se ztracet co jeste resite kdyz Panda38 a Antony/DTA uz rekli reseni.

Za XXX dosadim nulu a celou oblast prexoruji.
A xor B xor #00 xor C... => treba #83, tuto hodnotu dosadim za XXX
A xor B xor #83 xor C... => #00

V programu udelam OR A a zjistim zda je nula.. takze XXX je tam jen jednou. Ale ani cp #00 by nic nezkazilo. Jen je to trapny.

To same pokud delam add, jen dosadim negovany vysledek.

Vyreseno!

A nebo ne? Co kdyz tam chci mit xor i add najednou? Tak to mam podle me smulu.

PS: A pokud delam ... tak to bych mel jeste vysledek prerotovat podle pozice XXX.

_________________
Z80 Forth compiler (ZX Spectrum 48kb): https://codeberg.org/DW0RKiN/M4_FORTH

Pravda, pravda . A ještě platí zákon, že malá chyba nikdy neudeří sama, ale počká si na jinou, aby ji podpořila!


No a existuje vůbec nějaký testík, který odhalí v bloku dat:
změnu bitu v nějakém byte + změněné pořadí bajtů v bloku
???
Ale samozřejmě tak aniž bych neměl 1:1 celý blok kódu i jinde

Jinak mne ještě napadlo test té výsledné hodnoty (tj. mé YYY) nejen kontrolovat v kódu, ale z paranoi výše uvedené ukázat i uživateli. Např. vypsat onu výslednou hexa hodnotu na roh obrazovky při resetu a v manuálu se uvede jaká ta hodnota má být Viděl jsem to i v mnoha BIOSech na PC (hlavně základní desky INTELu), ale samozřejmě nevím jestli si tím kontrolovali CRC nebo nějaké jiné hodnoty z řadičů apod...

Každopádně díky všem za příspěvky. Takto plodnou diskuzi jsem ani nečekal.

Tohle by mohlo fungovat. V hlavicce nemusi byt nuly, ale pak se musi ignorovat.
Prvne zjistim vysledny hromadny XOR a doplnim do hlavicky.
Pak zjistim celkovy soucet i s tim uz zadanym XORem. Otocim znamenko.
Doplnim 2x do hlavicky, tim nebudu rusit XOR soucet.
Na konci me vyjde nula a tim ze je to tam 2x tak ta posledni hodnota. Takze se to ma rovnat te posledni hodnote.
Je to tak trosku princezna kolobezka. Protoze to delam nad VSEMY daty, ale proste by stacilo hlavicku z casti ADD ignorovat.

Zajimavejsi je ale u toho scitani mit scitani s prenosem carry. ADC ADC ADC

... + #61 = neco + carry

neco + carry + negadd = 0 => negadd = -neco - carry = #100 - #EA - carry

Takze nove to je

... + #61 + #EA = #00 + carry, kde to carry je na 99.99% jednicka. Nula muze byt jen pokud vsechny data byla nulova

Tak jako tak bych to minimalne nejpozdeji ted udelal posledni soucet bez prenosu abych vedel na 100% s cim mam porovnavat. Jeste lepe bych zakoncil soucet pred poslednim bajtem.

_________________
Z80 Forth compiler (ZX Spectrum 48kb): https://codeberg.org/DW0RKiN/M4_FORTH

Změněné pořadí bajtů odhalí polynomální CRC.

_________________
i++ (INC) increment
i-- (DEC) decrement
i@@ (EXC) excrement

Na zmenu poradi jsou hashovaci funkce.


Jinak pokud se pouzije to scitani s prenosem tak pokud se prohodi bajty mezi useky kde se pouzil carry tak to pozna koukam taky.Jinak mam pocit ze pouhe opakovane ADD neodhali vubec nic, co uz neudela opakovany XOR.

PS: Koukam ze jsem omylem scital prvne #78 a pak uz pokracoval v puvodnich datech, takze 2x #78 a ani jednou #55. Jinak vyjde zase #0. Takze ADC neodhali prohozeni bajtu. Takze to chce rotace. Kde se staci netrefit do stejneho posunu a melo by to byt videt.

12 xor (2*55) =B8
55 xor (2*12) =71
12 + (2*55) =BC
55 + (2*12) =79

PPS: Ani rotace tam nemusi byt. Staci kazdou sudou polozku duplicitne pricist a nebo xorovat jednu rotaci. Je pak 50% sance ze to odhali zamenu, ale zaroven 100% ze to odhali sousedni zamenu. Jako preklep.

PPPS: A ty rotace to chce udelat tak aby to poznalo prohozeni souvisleho bloku dat. Pokud se to bude rotovat o 1 bit po kazdem bajtu tak to nepozna bloky po 8 bajtech. Takze prohozeni 256 bajtoveho bloku taky ne. Kdyby se ale kazde nejlepe prvocislo udelala zmena. Napr. Kazdy 7 bajt se udelala rotace o 2 bity... Tzn. ze by to nepoznalo prohozeni bloku po 7 bajtech, ale zase to odhalilo nasobky mocnin 2.

_________________
Z80 Forth compiler (ZX Spectrum 48kb): https://codeberg.org/DW0RKiN/M4_FORTH

Jazykovedne okenko: pri opakovanem Post Scriptum se mnozi pismeno P nebo se postupne cisluji; viz napr. https://cs.wikipedia.org/wiki/Postskriptum

V posledni dobe to se mnou jde nejak z kopce. Nemohu se soustredit. Delam chyby ktere jsem driv nedelal... asi bych mel jit na vysetreni zda na me nejde demence. Konec spamu.

_________________
Z80 Forth compiler (ZX Spectrum 48kb): https://codeberg.org/DW0RKiN/M4_FORTH

SUB A vynuluje A cim sa z tej mojej rovnice odstrani jedno XXX co som presne pisal ze treba urobit.
V takom pripade je ale zbytocne pamet zaplacavat operacnym kodom zbytocnej instrukcie LD A,... a to jedno XXX staci umiestnit niekam na konec alebo medzi iny kod

Jasne, ze bez te LD A, instrukce je to ještě lepsi a kratsi.

Ja jen reagoval na poznámku, ze dane číslo XXX nutne musí být mimo oblast XORovanych dat - nutne nemusi, když se pozmeni program. A pozměnit mozno bud tak, ze se tam prida nejaka zbytecna instrukce jako LD A, ; nebo tak, ze se jeden bajt prida nekam, kde se nebude vykonávat.