Celé vlákno · 5 zpráv

Nerad bych ted kecal, ale myslim ze Fuzzyho vypocet byl spravny - pokud se
nemylim (je to mozne, rutiny monitoru pro praci s RD nemam moc
prostudovane), tak se nejprve program prenese z ramdisku do pameti od
adresy
0x1200 a teprve potom se LDIRem prenasi na spravne misto v pameti. Krom
toho
asi Feri pocital i cas, ktery trva inicializace samotneho monitoru ....
Pokud se jeste bavime o rychlosti, jednoznacne nejlepsi je v tomto
zalohovany RD kompatibilni s originalem ktery disponuje automatickou
inkrementaci adresoveho citace po kazdem cteni/zapisu bytu. Nezalohovany RD
typu Pezik ma nevyhodu v tom, ze se navic musi pred kazdym ctenim/zapisem
do
nej nastavit nova adresa a take zbytecne zabira moc portu (512K verze
obsadi
8 portu).

Zdenek

==================================================
ano, ALE!

napocítat to cez Tstates je korektnejsie, uznavam. lenze ten bitrate od
Fuzzyho je sice presny (co do Tstates), ale zaroven nepresny (co do
filozofie). boot zo SRAM (po nabehnutie obrazovky Flappyho) je asi 5s. z
toho inicializacia HW a monitora je asi 3s. zvyšných 2s zaberie load 44k zo
SRAM, spocitanie checksum a relokacia cez LDIR. teraz sa treba zamysliet -
bude swap pamate pocitat s checksum? ja myslim ze by mal. cena za rychlost
je umerna miere pruseru pri chybe: ak zlyha chcecksum, treba proces zhodit,
ak nebudeme kontorlovat spravnost zapisu tak akakolvek chyba je fatalna pre
cely system...

tiez treba pouvazovat, ako riesit multitasking - ak sa maju (docasne)
neaktivne procesy odswapovat, tak to bude dost sekat (tzn cas swapovania
bude ovela dlhsi ako cas behu).

p.s.: nepochopil som zmienku o zapise 16 byte naraz. bud 16 bit - a to nie
je v ziadnom pripade dvojnasobna bitrate, nakolko jedna blokova instrukcia
prenesie vzdy maximalne 256 bytes, takze 128x16 bit. ak to ale fakt ma byt
16bytes, tak netusim ako :-(

Feri.

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

> in a, (0eah)    ; nacteni dalsiho byte z RD: 11T
> ld (hl),a         ; ulozeni do RAM: 7 T
> inc hl            ; dalsi adresa v RAM: 6T

Tohle vsechno jde nahradit jednou instrukci INI (16 TStates), jedna se nejen
o usporu mista v pameti, ale i o zrychleni (16T vuci 24T). Jinak ten
checksum dat na ramdisku je vazne hloupost....
Jinak co se tyce swapovani, mame pochopitelne moznost k nemu vyuzit i HDD
(rychlost bude podobna, maximalne o par desitek cyklu bude navic), akorat v
pripade vyuzivani systemu s CompactFlash kartou bych mel vazne obavy, jestli
by takova CF prezila alespon hodinu neustaleho swapovani :-)

Zdenek


---
Odchozí zpráva neobsahuje viry.
Zkontrolováno antivirovým systémem AVG (http://www.grisoft.cz).
Verze: 6.0.520 / Virová báze: 318 - datum vydání: 18.9.2003

> pripade vyuzivani systemu s CompactFlash kartou bych mel vazne obavy, jestli
> by takova CF prezila alespon hodinu neustaleho swapovani :-)

AFAIK CF karty maji logiku, ktera vytezuje pametovy prostor rovnomerne. 
takze pokud bys na dejme tomu 128kB kartu svapoval
po par bytech, tak tech 1000 cyklu krat kapacita/mnozstvi.

nicmene to stejne na swapovani asi neni nejvhodnejsi medium :o)

peca

k ke rychlosti RD:
Diky za pripominku, Zdenku.
Tak jeste ta optimalizace:

loop:
ini		; 16T
ini		; 16T
..
..
(celkem 16x)
..
..
ini		; 16T   16*16T = 256T
dec de		; 6T
ld a,d		; 4T
or e		; 4T
jr nz,loop	; 12 T
=======================
celkem		282T na 16B
coz dela 	193 kB/s, t.j. 32 kB za 0.17s

Jeste abych trochu snizil ty obavy z neustaleho swapovani:
Cas CPU budou dostavat nikoliv vsechny procesy co bezi,
ale jen ty, co jsou ve stavu READY. Dost bezicich procesu bude
ve stavu SLEEP - napr. cekat na vstup z klavesnice, a ty klidne
muzou byt neustale odswapovany (dokud se ta klavesa neuhodi,
pak se musi naswapovat...).

Fuzzy