Zdar chlapi,
ok, příště se polepším, všechno hazím sem :-)
No ale jak zmínil Zdeněk, limity možností Sharpa jsem využil tak z 25%, umí víc a rychleji.
Ano dokonce jsem si mohl dovolit ten luxus použít instrukci INIR místo série instrukcí INI,
no jenom pro zvuk, pro video tam ty INI mám :-)
Tohle demo vzniklo tak trošku jako vedlejší produkt při testování rychlosti a nových vlastností unikarty.
S "klasickým" hardwarovým ramdiskem to běží bez problémů, nedělá totiž wait stavy. Problém vzniká
v unikartě, kde je ramdisk emulovaný přes souborový systém, takže je okamžitě dostupný obsah pouze
vyrovnávací paměti (512 bytů), pokud chci jinou oblast, musím počkat na seek v souboru a načtení
nového obsahu. Sekvenční čtení pak vypadá tak, že pro prvních 511 čtení dostanu data okamžitě
(no nebo s minimem wait stavů, třeba 1 nebo 2) a 512té čtení se zasekne třeba s 3000 wait stavy.
Cca 1ms zaseklý procesor, to je pro přehrávání zvuku nepoužitelné.
Proto jsem zkusil takovou obezličku, po přečtení 512tého znaku se wait stavy nekonají a načtení dalšího
sektoru se provádí v unikartě na pozadí. Pokud těch následujících 3000 hodin procesoru nic po unikartě
nechci, v klidu dočte nový sektor a je schopná mi na další vyžádání opět vracet data bez extra wait stavů.
Pokud si vzpomenu dřive jak po těch 3000 hodinách, tak si holt počkám ve wait stavech, dokud se data
nedočtou, jak to bylo dřív. Pokud s tím tedy aplikace počítá, může běžet bez časového omezení ze strany
emulovaného ramdisku. Samozřejmě to snižuje maximální prostupnost ramdisku, protože musím
na konci každého sektoru čekat než se načte nový sektor, ale nečeká ve wait stavech, může provádět
něco jiného (třeba přehrávat hudbu).
Z toho vyplývá odpověď na použití API repozitáře karty. Ačkoliv je rozhraní karty streamové, fyzicky čte
z SD karty opět po sektorech, takže máme stejný problém, 511x čtení ok, po 512té tisíce wait stavů.
Takže by se to sekalo (minimálně zvuk, na tom by to bylo poznat velmi). Šlo by opět udělat tu obezličku,
co jsem udělal pro ramdisk a pak by to s tím, že musí aplikace počkat než začne vyčítat další sektor,
šlo vyřešit, ale zase za cenu ztráty průměrné rychlosti vyčítání.
Stran použití RLE komprese pro případ podobných dat je to dobrý nápad, bohužel s emulovaným ramdiskem
to opět naráží na to, že snímky musí být zarovnané na 512 bytů, a to se to zase trošku (dost) komplikuje.
No nakonec k vlastnostem mz8win. Bohužel na jinak dokonalém (sám jsem šťastným uživatelem) emulátoru
jsou malé odlišnosti, no nutno přiznat, že s tím má problém akorát to moje demo :-)
Takže čím jsem vyprovokoval emulátor k odlišnostem od reálného Sharpa:
1) přerušení od i8253 čítač 0 mód 2 je dvakrát pomalejší než v reálu (kterej blbec, kromě mě, používá 11 tisíc
přerušení za sekundu :-)
2) Potřeboval jsem pomocí změny jednoho 8bitového registru přepnout scrollování o 100 řádků (nechtěl jsem
se piplat se synchronizací na vertikální synchronizaci a dělat to mimo zobrazovanou plochu). SOF pro 100
řádků je na dva zápisy, to po prvním zápisu rozhodilo obraz. Takže to dělám jen nastavením registru SSA.
Všechno nastavím na posun o 100 řádků: SSA=0, SEA=7D, SW=7D, SOF=1F4 a když nechci scroll, tak jen
přepnu SSA=7D. Mno je to prasárna, ale podle servisního manuálu to smysl dává a fakt to funguje.
Emulátor bohužel scrolluje dál. No mohl jsem udělat detekci emulátoru a upravit to tak, ať to hraje dobře i tam,
ale stejně je tam omezení na 1MB ramdisk.
Jenom pokud někdo tápe proč scrolling na video, tak protože je počet snímků za sekundu malý (6,25 - by člověk
neřekl, že tak málo, když to vidí na vlastní oči), sestavuje se obraz z jednotlivých barevných rovin na přelomu
stránky a teprve až je kompletní, tak se odscrolluje na střed a tak dokola, díky tomu obraz v prostřed nebliká
(narozdíl od těch podivností nahoře a dole).
Tolik ve zkratce :-)
Díky za podporu, za výdrž pokud jste dočeli až sem a omlouvám se netechnikům za mraky technických podrobností.
Zatím
Bohouš
---------- Původní zpráva ----------
Od: Zdenek Adler (sharpemupandora.cz) <zdeneka[doména skryta]>
Datum: 17. 5. 2013
Předmět: Re: Bohousova Madonna
Bohouš se s tím jistě chtěl pochlubit, až to rozchodí přes celou obrazovku při 25-ti snímcích za sekundu
Demo jsem zatím moc podrobně nezkoumal, nicméně jsem si z 16MB souboru ukrojil jen první 1MB a zkusil ho v emulátoru. Zvláštní je, že obraz se mi ukáže jen v horním a spodním uříznutém filmovém políčku a ne uprostřed. Čímpak to? Chyba v emulátoru?
Je to už víc jak 10 let, co jsem na Sharpa dělal něco podobného v rozlišení 160x100 a pseudo 256-ti barvách mi z ramdisku nekomprimované video (po sobě jdoucí stránky videoram) běželo zhruba 15 snímků za sekundu možná jsem to i dával sem na Pandoru. Jen tak zběžně jsem se koukal, že Bohouš vyčítá data z ramdisku instrukcí INIR já tehdá dosáhnul mírného zrychlení použitím sady za sebou jdoucích instrukcí INI.
Možná by bylo zajímavé i použití RLE komprese, kterou by se video asi značně zkrátilo, ale chápu že by to asi nepředvídatelně nabouralo časování celého dema. Jen mě to tak napadlo, při pohledu na ty černé plochy
Jinak dobrá práce, gratuluju!
Zdeněk
From: mailto:ordoz[doména skryta]
Sent: Friday, May 17, 2013 8:44 AM
To: Konference "Počítač SHARP MZ-800 a emulátory"
Subject: Bohousova Madonna
Ahoj chlapi,
takhle by to teda neslo! Kdyz udelate nejake nove demo pro Sharpa, tak o nem taky pekne napiste i tady do konfery! ;)
http://www.8bity.cz/2013/video-na-sharp-mz-800-madonna-2/
Bohousi, chtel bych se zeptat, zda to pracuje s "libovolnym" 16MB ramdiskem a nebo zda to navic jeste vyuziva nejaky hack ve tvem scandoubleru.
Z predpokladu, ze je to plne kompatibilni se Sharpem, nebylo by lepsi udelat to nacitani dat primo z SD karty pomoci API k repozitari? (Tam prece po otevreni souboru neni potreba nic strankovat a pokud se pri kontinualnim cteni vykasles na kontrolu statusu, tak v podstate jen dokola provadis IN a jednou za cas provedes seek na zacatek souboru.)
Michal
---
Pobyty na horách se slevou