Ok, Feri, takze muj vypocet jeste jednou - i s opravenym timingem toho 'inc
hl':
loop:
---
in a, (0eah) ; nacteni dalsiho byte z RD: 11T
ld (hl),a ; ulozeni do RAM: 7 T
inc hl ; dalsi adresa v RAM: 6T
---
in a, (0eah) ; nacteni dalsiho byte z RD: 11T
ld (hl),a ; ulozeni do RAM: 7 T
inc hl ; dalsi adresa v RAM: 6T
---
in a, (0eah) ; nacteni dalsiho byte z RD: 11T
ld (hl),a ; ulozeni do RAM: 7 T
inc hl ; dalsi adresa v RAM: 6T
---
(a takhle celkem 16x)
..
..
---
dec bc ; dekrementuj pocet 16B bloku k preneseni 6T
ld a,b 4T
or c ; konec prenosu? 4T
jr nz, loop 12 T
===========================
coz dela 410 T na 16 bytes.
Pri 3.5MHz je to 133 kB/s
Jak psal Feri, mozna by se to dalo jeste zoptimalizovat ctenim pres INIR, ale
to jsem uz nepocital.
Jinak jestli nekdo chcete udelat/nekde vyhrabat prototyp optimalizovane rutiny
pro cteni z RD (i ruznych typu), tak samozrejme muzete, bude se to urcite
hodit.
Ten checksum na RD: neni to paranoidni? Pri cteni z RAM se taky nedela,
a po chipove strance jde to to same... Nebo je zde realne nebezpeci spatneho
precteni?
Jak jsem rekl - jestli nekdo udela pridavnou strankovatelnou RAM (vyuzitelnou
univerzalne),
tak budu stastny jak blecha. Me bohuzel priroda obdarila obemi levymi hornimi
koncetinami,
takze k podobnym cinnostem jsem nepouzitelny. Navic me znalosti HW jsou
omezene.
Fuzzy