🚀 go-pugleaf

> Sea sisse kord et iga neliku esimesele mehele antakse k�tte punane lipp.
> (�ks bait algusse lisaks) Selle j�rgi tunned �ra kust jada algab.
> Ja j�rjekorranumber. Et keegi vahele ei tr�giks v�i ei j��ks. (veel �ks 
> bait lisaks) Baiti mahub k�ll 256 tegelast, aga kui 255 j�rgi tuleb null, 
> siis liida j�rjele �ks juurde. Matikud �tlevad vist et loendaja on v�etud 
> moodul 256ga.
> Seega �ks blokk on 6, mitte 4 elementi.
>
> N��d kui sul buffer algab "punase lipuga" ja "j�rjega" 34, siis
> 6000. grupi algus on 6*6000+34 ja tema "j�rg" on 194.
> (kontrolli �le).
>
> T�psuse garanteerib mikromasina kvarts.
> Aga seeeest ei pea PC pingutama nagu hull.
> V�id vahepeal netis kirju lugeda. :)
>
> Ja t�pselt sama programm saab hakkama ka selle salvestatud faili 
> t��tlusega.
> Vahet pole, kas lugesid log failist v�i com pordist.
>
> Nii tundub mulle.
> Mis on valesti?
>
> A.R.
Ei, valesti pole midagi.
Aga kui need 4 baiti on tegelikult 32-bit long, mille bittidega mul m�ngida 
tuleb?
igas blokis v�ib juhtuda ainult 1 s�ndmus, aga ei pea.
S�ndmus on see, kui 2 bitt muutuvad korraga kas �heks v�i nulliks.
Nii ma m�tlesingi, et loen bloki, vaatan, kas s�ndmus toimus
ja kas vanad kestavad.
Kui toimus, j�tan m�llu, kui m�ni l�ppes(l�ksid nulliks),
alles siis kirjutan faili(ja ekraanile):
1-m�lust stardiaeg,
2-bittide nimed,
3-reaalne l�puaeg(v�i ajavahe)

Kuna igas blokis on ainult 1 s�ndmus
 ja �ks bittidest on alati 6 noorema seast,
siis on j�lgimist v�he.
Iga bitt on kindel asi, nii, et kui blokk vahelt kaotsi l�heb,
pole viga, saan 6mS hiljem teada, mis juhtus,
mahub 10ms sisse.
Sellest see "raualine" l�henemine asjale.

Lipp tuleb ette jah panna
aga pean vaatama mingi  v�imatu bitiseisu,
ilmselt 255.

Kuidas arvutile ressursiliselt parem on,
nokkida iga blokk puhvrist
v�i pikk jada ning koodis rohkem aja ja j�rjekorra arvutusi teha.

ps. sorry, kui �ra t��tama hakkan