Konference: Počítač SHARP MZ-800 a emulátory

Dne 11.12.2011 23:59, Martin Lukasek (sharpemu tu byla ta zakroucena vec pandora.cz) napsal(a):
>
> Taky mně zarazilo, že Unikarta je pomalejší, než fyzický FDD, ale za 
> to může to SD. Když se na divIDE připojí jako HDD adaptér ze SD, tak 
> se taky zpomalí jako hrom. Takže IDE mně fakt láká. A za mně je dobře, 
> že je to fakt IDE a ne jen slot na CF kartu, protože tak nějak 
> nostalgicky lepší je určitě
>

Ahoj Martine,

kdyz jsem mel unikartu jeste na AVR, tak jsem si tady meril stopkama 
rozdil ve startech cp/m a basicu z FDC a z unikarty a ty casy byly 
rozhodne priznivejsi pro unikartu - vysledky jsou nekde v konfere, cca 2 
roky zpet...

Unikarta ma sice pomalejsi jednotlive I/O operace, ale zase narozdil od 
realneho FDC ma minimum stavu, kdy se ceka na nejaky status, nebo kdy je 
potreba neco stabilizovat. Kdyz budes merit treba nacteni jednoho 
konkretniho sektoru, tak pokud pomines nutnost cekat na roztoceni 
motoru, tak zrejme vyhraje FDC. Ale pri praci operacniho systemu 
(zvlaste toho Lamacova, ktery neustale neco poctive testuje) by mela 
vyhrat unikarta, protoze jeji status registr je optimalizovany k tomu, 
aby vracel okamzite takovy status, jaky se ocekava a vsechny cekaci 
status rutiny se tedy moc nezahreji.

Pred merenim si jeste v cp/m muzes poladit setupem casy kterymi se 
nastavuji prodlevy pri praci FDC - unikarta samozrejne unese ty 
minimalni hodnoty.

Napadaji rozdily, ktere v puvodnim AVR nebyly a ktere mohou vyznamne 
ovlivnit mereni:

1. startup vsech subsystemu v STM32 - po resetu je bohuzel STM32 trochu 
pomalejsi, nez bylo AVR... zrejme nameris jiny cas natazeni cp/m po 
zapnuti pocitace (s baterkou/bez baterky),  jiny po resetu a nejkratsi 
po [ reset + M ] a pak [F].

2. integrace Ushellu obnasi to, ze unikarta ve smycce testuje vstup ze 
Sharpa a jeste navic vstupni buffer Ushellu (ale myslim si, ze to je jen 
par instrukci), ktere nemohou byt znat

3. po zpracovani jakekoliv operace a taky uvnitr cekaci smycky viz. 2. 
se testuje navic take interni semafor, ktery zajistuje volani preruseni 
pro Sharpa - to je vec, kterou jsem tam pridal taky az v jednom z 
poslednich FW, ale opet si myslim, ze je to jen par instrukci, ktere by 
se nemely projevit nejakym citelnym zpomalenim.

4. unikarta ma na UARTu interrupt, ktery muze samozrejme ovlivnovat jeji 
cinnost - ten se ovsem aktivuje jen tehdy, pokud prichazeji/odchazeji 
nejake data z USARTu.

5. pokud by byl ve firmware zapomenuty/zapnuty nejaky debugovaci vystup, 
ktery chce posilat hlaseni na RS232 a k unikarte neni pripojeny terminal 
s RTS/CTS, tak po naplneni vystupniho bufferu dochazi s kazdym 
odesilanym znakem k prodleve, po ktere se ten znak zahodi ... To by bylo 
znat docela citelne.


Pokud se tim budes dal zabyvat, tak jsem zvedavy co nameris. Ja bych 
kdyz tak mohl k unikarte pripojit logickou sondu a udelat si profil 
vsech operaci, jen nevim kdy se k tomu dostanu - na takove kramareni s 
HW tu ted bohuzel nejak nemam prostor :(

Michal

Ostatní příspěvky vlákna:

Re: Ramdisk + IDE16 - první návrh (Martin Lukasek, 11.12.2011 22:59)

Re: Ramdisk + IDE16 - první návrh (Vaclav Peroutka, 12.12.2011 08:10)

Re: Re: Ramdisk + IDE16 - první návrh (Martin Lukasek, 13.12.2011 22:16)

Re: Ramdisk + IDE16 - první návrh (Michal Hučík, 12.12.2011 09:07)