Na az assembly topikban
ergoGnomik felvetései alapján elgondolkodtam pár dolgon,
és bár valszeg az IstvanV által megadott számítások megértéséhez szükséges időt nem fogom soha rászánni a EP alapú fejlesztésekre (így kb. soha nem lesznek olyan mély ismereteim a z80 és EP memória működéséről, amivel igazán optimális megoldásokat lehetne találni, de még az is lehet, hogy ez nem is akkora baj abból a szempontból, hogy ha ilyen szintű optimalizálásokat is figyelembe veszek, az még hatványozná a különböző verziók és lehetőségek számát, így a fejlesztési időt is.)
De mindenesetre (függetlenül attól, hogy a sprite kimásoló ciklusmagom mennyit lassul/gyorsul ha a forrása "fast" RAM -ban van, vagy nem) abból baj nem lehet, ha a sprite adatokat, és az őket kirajzoló kódot egy az assembly topikban már említett módon kölön szegmensre rakom, mely a nullás lapra lapozódik majd be.
Annál is inkább, mert ezt a gondolatot tovább vittem, és további jóságok (annak tűnő dolgok) derültek ki belőle.
Mi is a szitu:
Alap lapkiosztás:
F8 - általános kód és adat
FC - video ram 256 -os scanline- okkal, melyeknek első 104 byte -ja alkotja a scanline- t, és a második 152 byte -ja pedig szabad (ide kerültek volna eredetileg a sprite adatok).
FD - ugyanaz mint FC
FE - ugyanaz mint FC csak az utolsó 6KB már üres, jelenleg itt vannak a hangok, innen játsza le a 4KHz hangmegszak a mintákat, 4KHz -enként 2 byte kiolvasása a video RAM -ból.
Háttérben, nem állandóan belapozva:
FF - az elejét felülírtam az LPT adatokkal
F9 - csillagmozgatás kód + adat (csillagmozgatás fázisok). 50 Hz -enként belapozva a nullás lapra, kirajzolja a csillagokat.
FA - sprite kirajzolás kód + adat (sprite fázisok). 50 Hz -enként belapozva a nullás lapra, kirajzolja a sprite -okat.
FB - jelenleg még üres.
A sprite -oknak használ (nem tudni pontosan mennyit) ha "fast" RAM -ban vannak, és mivel egy sprite- jaim 16X16 pixelesek (duplázott méretű pixelek!), ezért eltolt fázisokhoz 5X16 byte kell, a szín keveréshez pedig fázisonként 2 db grafika, ezért 5X16X2 = 160 byte egy fázis. Egy lapra 102 fázis férne el, de lesz ott kód, és miegyéb, tehát mondjuk 64 fázis, ami akkor mondjuk 8 darab 8 fázisú, vagy 16 darab 4 fázisú, sprite grafika férne el, ami sztm. simán elég lehet. Vagyis a sprite -oknál veszíteni ezzel nem veszítünk semmit.
A plussz jó dolog meg az, hogy mivel a hangok úgyis a video RAM -ból vannak játszva, ezért ha már megy a csillagmozgás, meg a sprite- ok a jelenlegi kb. 6 hangos bufferrel,
akkor opcionálisan ki tudom terjeszteni egy módszerrel a hanglejátszást a kiűresedett scanline közökre.
Ugye 4Khz -en egy video "megszak" (50 Hz) alatt kb. 80X van hang megszakítás. Vagyis egy 80+pár byte -os puffer elég ahhoz, hogy 50 Hz -enként kelljen csak legyen a hang lejátszás ellenőrizve. Ez már most is így van a kódban.
Namost nekem 152 byte -om van a scanline -ok között üresen, ha lecsökkentem kicsit a hang frekijét 4KHz -ről pld. 3.5 KHz -re, akkor már elfér a 152 byte -on két 70 byte -os minta chunk (ami a 3.5KHz alatt kb. elegendő lesz 25 Hz -re), és 6 - 6 byte a két végén overhead, ami a minta korábbi ill. későbbi 6 -6 byte -ját fogja tartalmazni a minta chunk 2 végén.
Ezek a plussz 6-6 byte -ok arra kellenek csak, mivel nem tudjuk azt pontosan, hogy vajon a 3.5Khz -es megszakunk tényleg darabra megérkezik -e a videomegszakok ideje alatt.
Na ez még nekem is bonyolult volt, próbálom tisztábban:
A hangmegszak kicsit rosszabb kell legyen, mint 4KHz, mert 4KHz -en 80 byte kell egy 50 Hz -es intervallum alatt, és ha egy 50 Hz -es megszakításnyi időre csak 80 byte -ot tárolok bele a 152 byte -os területembe akkor sok memória pocséklódna el még mindíg. 2 db 50 Hz -es megszakításnyi idő meg már 160 byte lenne, nekünk meg csak 152 folyamatos byte -unk van.
Továbbá nem tudjuk az 50 Hz -es megszakjainkban pontosan elkapni darabra a hangmintákat, lehet hopgy 2 video megszak között egyszer 78 egyszer meg 83 minta játszódna le. Ezért kell kétoldalt egy kis ráhagyás, átfedés a minta chunk -ok között. Ami tovább növeli a byte -ok számát.
Tehát kicsit lejjebb megyek a hang frekivel úgy, hogy 152 byte -ba beférjen 2 50 Hz -es megszak idejéhez szükséges hangminta + az átfedések. Ez kb. úgy 3.5 Khz körül lesz.
Beállítom a hanglejátszást a hangmintám első darabkájának az elejére, és elindítom a lejátszást.
A hangmegszak az eddig megismert módon semmivel nem törődve, maximális sebességgel tolja a hangot.
Majd 2 50 Hz -es megszakításnyi idő múlva (mert tudom, hogy ennyi időre biztosan van elég hangmintám) , átírom a hangmegszak címét egy olyan rutin címére, ami elvégzi a csekkolást is, nem csak a hangot adja.
Ez a megszakítás megnézi (csak 25 Hz -es lefutással ugye), hogy a hangom pontosan melyik mintánál jár (nyilván az átfedő 6 byte -os részen kell legyen), és úgy állítja a következő scanline üres helyére elhelyezett hang chunk -ra, hogy ott meg a kezdő 6 byte -os tűrési zónán belül a megfelelő "folytatás" hangminta legyen.
Ezután a megszak címet persze visszaállítja a gyors lefutású hangmegszakra.
Igy akkor az össz sebesség szerintem növekedni fog, mert levettük a hangferit 3.5 KHz -re, és csak 1/25 Hz -enként nézzük meg részletesen a hangminta pozícióját.
És kapunk még 16K-18K hang memóriát a meglévő 6K -hoz ... lesz kb. 24K hang buffer ... az már akkor kb. 7 másodperc hang ... vagyis lehetne pár hosszabb is ...
És mindez opcionális, ráérek akkor ha már látszik valami, és a futáson csak gyorsítani fog.