Původní podoba příspěvku
Surová data tak, jak byla v roce 2013 stažena z Pandory (HTML zdroj bez úprav, osobní e-mailové adresy jsou maskované).
<!--------------------------------------------------------------> <table width="100%"><tr><td align="left" valign="middle"><B>Re: Re: MZIX-proveditelnost-rychlost MZ-800 - SRAM:</B></td><td align=right valign="middle"></td></tr></table><BR><pre>Ok, Feri, takze muj vypocet jeste jednou - i s opravenym timingem toho 'inc <img src="BODY_IMAGES_WRAP_GIF"> 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 <img src="BODY_IMAGES_WRAP_GIF">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 <img src="BODY_IMAGES_WRAP_GIF">precteni? Jak jsem rekl - jestli nekdo udela pridavnou strankovatelnou RAM (vyuzitelnou <img src="BODY_IMAGES_WRAP_GIF">univerzalne), tak budu stastny jak blecha. Me bohuzel priroda obdarila obemi levymi hornimi <img src="BODY_IMAGES_WRAP_GIF">koncetinami, takze k podobnym cinnostem jsem nepouzitelny. Navic me znalosti HW jsou <img src="BODY_IMAGES_WRAP_GIF">omezene. Fuzzy</pre>