OldComp.cz

Velesofte kdyz budes potrebovat tak ti muzu poslat 2x CPU DIL 20MHz a 2x DMA DIL 10MHz. Kdyz by se to poslalo ve ctvrtek tak by jsi to mozna mohl testovat uz o tomto vikendu. Napis v pripade ze to ma smysl.

Opravuji, ta DMA je 8MHz.

Slibene fotky:



Vice detailu:
http://velesoft.speccy.cz/other/dma04.JPG
http://velesoft.speccy.cz/other/dma05.JPG
http://velesoft.speccy.cz/other/dma06.JPG
http://velesoft.speccy.cz/other/dma07.JPG
http://velesoft.speccy.cz/other/dma08.JPG
http://velesoft.speccy.cz/other/dma09.JPG
http://velesoft.speccy.cz/other/dma10.JPG
http://velesoft.speccy.cz/other/dma11.JPG
http://velesoft.speccy.cz/other/dma12.JPG
http://velesoft.speccy.cz/other/dma13.JPG
http://velesoft.speccy.cz/other/dma14.JPG

_________________
http://velesoft.speccy.cz/

Zkouska na SAM COUPE:

- pri osazeni Z84C0020PEC (20MHz verze Z80 CPU) pocitac nahodne padal. Casto se samo od sebe generovalo NMI nebo probehl reset/zhrouceni. Vsiml jsem si, ze je procesor nejak horky, coz by nemelo byt, zvlast kdyz je to 20MHz CPU podtaktovany na 6MHz. Po blizsim prozkoumani jsem zjistil, ze jde o preznacenou Z80. Cip ma podivne matne pouzdro a ti vcetne vnitrku kulatych plosek, ktere maji byt vzdy leskle. Zkusil jsem CPU vymenit za muj stary 10MHz procesor koupeny kdysi v GME. A hele, procesor najednou nehreje (ani naznakem) a pocitac je zdanlive stabilni. Po nejakych peti minutach se opet zacina automaticky generovat NMI. Podrilo se mi nahrat software v podporou DMA, ale zda se, ze DMA vubec nereaguje a nepozastavuje procesor. A ted koukam, ze se krome zacina CPU hroutit, neco je spatne. Pritom CPU je pripojene prakticky 1:1. Áha, ted jsem zmeril napeti na procesoru a je tam jen 4.67V a trochu to kolisa. Takze je mi ta nestabilita uz jasna.... Jdu pokracovat....

- DATA-GEAR obsahuje resetovaci obvod, ktery hlida pokles napeti a pri urcite urovni automaticky generuje reset. Stejny obvod je pripojeny take na NMI. Oba jsem prozatim vyndal z patice a nahradil je kouskem dratu z odporu. Obvody byly ocividne na pokles napeti citlivejsi nez realne cipy CPU a asi i DMA. Prozatim to bez nich uz nepada. CPU funguje uz delsi dobu stabilne a je studenej jak psi cumak (mam tedy CPU 10MHz). Napojil jsem logicky analyzator na ridici signaly a kdyz spustim DMA rutinu, je videt, ze DMA opravdu generuje signaly jak ma. Odesila zadost o DMA pristup procesoru, CPU odpovi, ze je odpojenysignalem BUSACK a nasledne DMA pekne zacne generovat opakovane cteni a zapis, na stridacku. Jenze v pocitaci se nedeje vubec nic. DMA rutina prenasi data z ramky do oblasti graficke casti videoram (nebo se o to fakt snazi), ale presto ze nic nedeje. Obraz se behem DMA prenosu nezmeni, takze ani jediny bajt pri DMA prenosu neprojde. Stejny DATA-GEAR jsem zkousel nedavno v mem ZX Spectru 128+2 a tam fungoval dobre. U SAM COUPE to typuju na nejaky problem s casovanim signalu generovanych z DMA. Nakonec si s timpohraju. DMA ma nastavitelne casovani signalu i rychost prenosu. Zkusim nastavit nejpomalejsi DMA prenos a uvidime. Jo a malem bych zapomel, 5V vetev byla na desce datagearu tazena na zacatku rozvodu tenkym vodicem, sice jen kratkym, ale pomohlo male premosteni kouskem dratku. Ted se napeti dostalo na rozumnou uroven.

- A abych nezapomel, DATA-GEAR ma na sobe jumper, ktery umi vypnout MIDI porty #FD a SAM tak sice nemuze nijak komunikovat s midi, ale zase tim odpadne dalsi problem u zx her, ktere sahaji na AY porty nebo strankovaci porty #7FFD. Zkousel jsem treba DIZZY 5 a se zakazanyma midi portama bezi hra uplne normalne, zatimco s povolenym MIDI portem SAM generuje s kazdym pristupem na porty #xxFD preruseni a to samozrejme totalne rozhodi casovani hry az do naprosto nehratelne podoby.... Takze alespon tady mohu potvrdit, ze tato funkce vypinani portu midi opravdu funguje. Misto jumperu lze pripojit kabel s prepinacem a za chodu si kazdy muze funkci nastavit jak uzna za vhodne. Kdo midi nepouziva, klidne muze nechat port vypnuty natrvalo.

_________________
http://velesoft.speccy.cz/

Zkusil jsem tedy modifikovat DMA rutinu tak, aby byl DMA prenos pomalejsi, tedy konkretne nejpomalejsi jak jen to jde = 4 takty nacteni jednoho bajtu + 4 takty na jeho zapis = 8 taktu na prenos kazdeho bajtu. Po spusteni se opravdu DMA prenos spustil. Sice se do obrazovky zapsaly uplne nekorektni data, ale alespon to neco udelalo. Zkusim experimentovat dal s casovanim signalu. Vime, ze data-gear na zx funguje, takze je zapojeni v poradku. Na SAM COUPE je rozdil akorat v tom, ze je procesor brzdeny waitem,narozdil od zx, kde se brzdi hodiny (CLK).

Vyzkousel jsem DMA prenos z portu FE na port FE. Takze kdyz stisknu klavesu, zmeni se take barva borderu. Tento prenos funguje bez problemu. No slava, takze prvni uspech. S DMA casovanim je opruz, napisu na to radeji nejaky programek, ktery bude mit setup v basicu a vygeneruje DMA rutinu. Pro testy to bude lepsi... I tak jsem ale opet zkusil prenos pamet<>pamet s rychlym prenosem a neco to udelalo. Alespon se tedy vyplnila obrazovka jak bylo treba, akorat kravinama a cele se to seklo, pomohl jen reset. Pak jsem DMA nastavil nejak nevhodne, ze se seklo totalne a nesel pocitac ani zresetovat, to je znamej problem i na ZX. K tomuto ucelu je na desce jumper, ktery povoluje resetovani cmos dma cipu soucasne se zx resetem. Odzkouseno a resetovani zaseknuteho CMOS DMA cipu funguje

Problem s nestabilitou resetu a nmi odpadl s premostenim tenkeho spoje napajeci vetve 5V. Ted je to stabilni a napeti se drzi na 4.93V.

_________________
http://velesoft.speccy.cz/

Napsal jsem v ZX basicu DMA konfigurator, kde lze nastavit jak casovani signalu, tak rychlost ci rezim prenosu, zdrojovou i cilovou adresu, delku bloku a nastavit jestli samostatne u zdroje i cile jde-li o port ci pamet. Nastaveni by tam mohlo byt jeste vice,, ale to se da kdykoli dopsat. Takze jdu to zkusit na sam coupe....

V emulatoru ZX Spectra snapshot s basicem funguje dobre, dokonce i DMA prenos v realspectru jede. SNA soubor jsem importoval na DSK image pro emulator SAMa a tam rovnez snapshot spustim a basic probehne ok. Pokud DSK soubor prenesu na disketu a spustim to na realnem sam coupe, snapshot se sice spusti a basic take vypada normalne, az na to, ze neco prerusi prubeh basicu, jako kdyz se breakne a vypise se (v ZX rezimu se zx romkou na sam coupe) hlaska "L BREAK into program, 520:1" a stejna hlaska se objevi ihned jak zadam GOTO 520. Proste prikaz GOTO nefunguje jak ma a to ani na jine vyssi radky. GOTO 0 ale uz funguje, ikdyz se to opet zastavi. Nekdy neskonci na radku 520, ale treba na jinem... Co to muze zpusobovat ? At mam datagear pripojeny, nebo to zkousim na obycejnem sam coupe se samotnym procesorem, furt se to chova stejne. Kdyz z diskety udelam na PC image a spustim v emulatoru SIM COUPE, stejny snapshot zase funguje korektne. Muzete prosim nekdo vyzkouset tento DSK soubor na realnem sam coupe ?
Prikladam natocene video z emulatoru, kde je videt cisty prubeh. Spousteno bez DMA, v basicu se zadavaji jen hodnoty do promennych a ty se pak posilaji na port 107, ktery na SAM COUPE neexistuje, takze to ani nic delat nemuze. Pro jistotu jsem cislo portu zkousel zmenit, ale furt se to chova blbe. Jak v zx emulu, tak v sam coupe emulu to funguje, na realnem sam coupe ne. Zkusil jsem i vymenit ramku a zadna zmena, nic jineho me fakt nenapada... I vadna disketa se muze vyloucit, zkousel jsem jich vic a beze zmeny.

Sice bych to cele mohl obejit treba prepsanim basicu nebo cistym strojakem, ale tento problem by to chtelo take vyresit.



Tak nakonec to vzpada na nestabilni adresovku a problem s klavesnici.... Obesel jsem to pridanim radku 400 PAUSE 20.
A mame tu prvni dobre zpravy... zkusil jsem DMA rezim 3T read+3T write bez zkracenych prubehu signalu a dma prenos se opravdu uskutecnil. Bohuzel po ukonceni DMA prenosu se pocitac sekne a poskodi se atributy a grafika obrazu. Je ale videt, ze se prenos horni tretiny obrazovky do spodni casti vydaril a data se prenesla 100% v poradku. Az tedy na to, ze po DMA prenosu uz pocitac nereaguje. Ne prvni pohled to vypada, jako kdyby se poskodila pamet pri absenci refreshe pameti. Ale vzhledem k tomu, ze samotny DMA prenos linearne zvysuje adresy, ze kterych cte, melo by to refresh plne nahradit.

22:01 - Vyzkousel jsem si hrat s casovanim DMA a zadarilo se. Ted mohu potvrdit, ze prvni funkcni DMA prenos 2kB bloku dat probehl korektne. Jde o rezim kdy DMA cte bajt 3 takty CPU a dalsi 3 takty CPU ho zapisuje na cilovou adresu. Pritom ale bylo nutne zkratit prubeh sygnalu MREQ,RD i WR, aby skoncily o 1/2 cyklu drive. Teoreticky mame funkcni DMA prenos, kdy je rychlost komplet prenosu jednoho bajtu z pameti do pameti za 6 taktu. Prakticky se to ale takhle pocitat neda, protoze ASIC(ULA) prubezne brzdi procesor(a tedy i DMA) signalem WAIT. I tak je to znatelne zrychleni u delsich bloku dat. Nejrychlejsi instrukce pro prenos jednoho bajtu je u Z80 procesoru LDI, ktera trva 16taktu. DMA provede stejny prenos uz za 6 taktu, tedy asi 2.66x rychleji. Chova se asi jako procesor bezici na 16MHz...

22:45 - Zkousel jsem 2T cteni, ale pri teto rychlosti DMA nestiha nacist korektni data. Ono by se to dalo stihnout, je videt, ze prenasena data temer souhlasi, az na to, ze nektere datove bity proste nestihaji.... mam D7 trvale v log.1 a pri uprave sacovani jinych ridicich signalu ve 2T rezimu je to jeste horsi. 2T rezim by mel jit podle me pouzit s externi megovkou nebo s romkou, a to jak pro cteni, tak pro zapis. Ciste teoreticky by slo nastavit 2T read+2T write rezim pro prenos dat v externi megove pameti, coz mame 4 takty na prenos bajtu = 4x rychlejsi nez procesor (DMA by zde prenaselo data stejnou rychosti, jako kdyby bezel procesor na 24MHz).
Dalsi na rade bylo 4T cteni pameti. To ale neni pouzitelne, pocitac vzdy vytuhne. Nevadi, nam jde o rychlost a ne o "pomalost"
Ted uz vime, ze pro cteni pameti (alespon te v sam coupe,ktera je cela sdilena s ulou) muzeme pouzit akorat 3T rezim. (4T nefunguje a 2T nestiha). DMA ale dovoluje nastavit jine casovani pro cteni a jine pro zapis. Zapis jsem testoval opet jen s interni sdilenou ramkou a dosel k zaveru, ze 2T zapis nikdy nic neudela. Proste je to prilis kratka doba na to, aby ASIC(ULA) akceptoval pozadavek o zapis dat. 3T i 4T zapis funguji vzdy a s jakymkoli casovanim. Muzeme to kombinovat a mame na vyber z techto variant:
a) 3T read + 3T write
b) 3T read + 4T write
Pro pristup do externi 1MB ramky, ktera neni sdilena/brzdena, by mel jit pouzit i 2T rezim.

Drive jsem trochu experimentoval s DMA na ZX a podle dokumentace jsou tu dva bity, ktere mohou mit hodnotu 0-3. 0=4T rezim,1=3T rezim,2=2T rezim a u cisla 3 je poznamka "NEPOUZIVEJTE". V ceske dokumentaci k DMA je u cisla 3 poznamka, ze jde o 1T rezim. Nedalo mi to a vyzkousel jsem. A opravdu to na ZX pouzitelne bylo. Sice ne s pameti, ale pri zapisu na port. Schvalne 1T rezim zkusim zapnout na SAM COUPE a zmezim co z DMA leze ven. Je mi jasne, ze tuto rychlost SAM nepomere, ale me spis zajima, jestli ten 1T rezim u CMOS verze DMA opravdu funguje na 1T... Dam vedet.

Jo, a zapomel jsem prilozit ten DSK soubor, ale hned to napravim. Sice uz tam mam par vylepseni a eliminoval jsem nestabilitu klavesnice, ale tim lip. Je to uz celkem solidni konfigurator DMA. Po nabootovani diskety stisknete 1 pro katalog diskety a zadejte nazev "BASIC2". Jde o snapshot posledni verze konfiguratoru.

_________________
http://velesoft.speccy.cz/

Dnes si dam pauzu, musim zmizet na chatu. Az se vratim, poridim a zverejnim screenshoty z logickeho analyzatoru.

_________________
http://velesoft.speccy.cz/

Slibeny screenshot z DMA prenosu.

http://velesoft.speccy.cz/other/dma%203Trd+3Twr-long.png

_________________
http://velesoft.speccy.cz/

Ehm... pokusil jsem se natocit DMA pri praci, ale kvalita je mizerna.

http://velesoft.speccy.cz/other/DMA_SAM_001.MPG

Je to natocene na SAM COUPE, kde mam v basicu nastaveni kroku, o kolik bajtu se bude obraz posouvat. Na ukazku jsem pouzil graficky mod4 (barevne pixely bez atributoveho omezeni). Krok 1 posouva obraz vzdy o 2 pixely, krok 2 o 4 pixely, atd... A nakonec 128 posouva o 25 pixelu, coz je jeden kompletni mikroradek obrazu, takze vznika vertikalni scroll. Mnou natocene video ma nizke FPS, takze neni plynuly pohyb vubec videt, skoda. Celkem slibne vypada vertikalni scroll, kde by sel take nastavit vetsi krok a zrychlit tak posun obrazovky.

Prenos bloku dat o delce presne 24kB trva DMAcku ruzne dlouhou dobu,protoze je pamet sdilena ale pohybuje se to nekde mezi 41,2267ms a 41,4432ms. Delka jednoho preruseni na SAM COUPE trva 19,9540ms. Takze posun komplet cele videoram (24kB dat) trva DMAcku neco pres dve preruseni. Pokud by se nepracovalo s uplne celou obrazovkou, tak by se to dalo stihnout do dvou preruseni, cili 25fps v tom nejlepsim grafickem rezimu a se dvema videoramkama. Pri vertikalnim DMA scrollu obrazovky je to ryche a zajistene jedinym neprerusovanym DMA prenosem. Pokud by se chtelo DMA vyuzit pro horizontalni scroll,prenosem, neni mozne to zajistit jednim DMA prenosem, ale musi se pro kazdy mikroradek obrazu spustit samotny DMA prenos pro zhruba 128 bajtu. To take znamena, ze to procesoru sezere dalsi cas pro kazde nastavovani parametru DMA (prace s porty). Takze dojde ke znacnemu zpomaleni,ale i tak by se to u prenosu 128 bajtu melo casove vyplatit

Koho by zajimalo, jak se spousti DMA prenos, tak zde je jednoducha sekvence prikazu OUT, ktera funguje jako nahrada LDIR. Jednotlive bajty se postupne posilaji na port 107 (port DATA-GEARu). Je zde napevno nastaveny rezim prenosu pamet>pamet a rychlost 3T read + 3T write. Po dobu prenosu je odpojeny procesor Z80.

195 - registr 6 - reset
1 - registr 0 - transfer
84, 1 - registr 1 + casovani
80, 1 - registr 2 + casovani
128 - registr 3
173 - registr 4
0,64 - 2b adresa cile (nizsi bajt,vyssi bajt)
207 - registr 6 - load
125 - registr 0(transfer mode)
1,64 - 2b adresa zdroje (nizsi bajt,vyssi bajt)
254,7 - 2b delka prenaseneho bloku (nizsi bajt,vyssi bajt). Musi byt o 1 mensi nez potrebna delka.
146 - registr 5 - CE/WAIT multiplex+stop at end
207 - registr 6 - load
179 - registr 6 - force ready
135 - registr 6 - enable DMA (vyvola start DMA prenosu)

_________________
http://velesoft.speccy.cz/

Blokovy rychly prenos funguje. Zkusil jsem si pohrat s rezimem prenosu po jednotlivych bajtech, kdy DMA prenese pri kazde aktivaci signalu RDY jeden bajt a preda hned zpet rizeni procesoru Z80. Pro bajtovy rezim je potreba nejakou logikou externe generovat signal, ktery bude pozadavkem k prenosu dalsiho bajtu. Zkusebne jsem tam pripojil signal INT (50Hz) a opravdu to funguje. Kazde preruseni DMA prenese jeden bajt. Po experimentovani jsem prisel na to, ze musim odstranit prikaz FORCE READY pred povolenim DMA cipu. DMA prenos jede na 50Hz, coz je dostaterne pomaly prenos, abych mohl sledovat jeho prubeh na obrazovce. CPU se pravidelne strida s DMA, takze to vypada, jako kdyz DMA pracuje paralelne. Neco je ale stale spatne, protoze procesor normalne vykonava cinnost, do toho vidim na obrazovce prenos dat ale po chvilce (jakoby na konci prenosu) procesor bud vytuhne, nebo se neco podela v ramce a basic zacne delat varovnej beep nebo skoci kamsi do zx rom na kazetovou rutinu... Zkusil jsem nakonfigurovat DMA tak, aby v nekonecnem cyklu delalo stejny DMA prenos a zaroven bezelo v bajtovem rezimu. Ale opet probehne jeden dma prenos a po nem vytuhne CPU, ale DMA dale v prenosu pokracuje a po chvilce se vetsinou poskodi obrazovka/ram. DATA-GEAR ma ale signal RDY pripojeny natvrdo na +5V, takze bez uprav bajtovy rezim prenosu podporovat nemuze a zvladne jen jednorazove blokove rychle prenosy dat. Otazka je jestli se timto problemem mam vubec zabyvat. Ma smysl prenaset data po bajtech, kdyz to pujde rovnou v jedinem a rychlejsim blokovem prenosu ? Jasne, zalezi na vyuziti DMA cipu....

Pche... ted koukam, ze i v dokumentacich PDF jsou chyby... spatny popis(zameny portu), spatne nastavene bity,... no des...

Na SAM COUPE lze vypustit nastaveni casovani DMA prenosu a nechat default 3T+3T. Sestavil jsem tabulku posilanych bajtu do DMA podle dokumentace a misto puvodnich (ze ZX) 20 bajtu staci do DMA poslat jen 16 bajtu (pro blokovy prenos). Pro prenos po bajtech by slo jen o 15 bajtu, ale tento rezim zatim nemam odladeny.

Zde postupne 16 bajtu, ktere se musi ve stejnem poradi poslat do DMA pro aktivaci DMA prenosu (psano podle dokumentace, ale musel jsem nektere bity opravit, protoze tam byl spatny popis):
DEFB 120
DEFW ODKUD
DEFW DELKA
DEFB 20
DEFB 16
DEFB 173
DEFW KAM
DEFB 146
DEFB 207
DEFB 5
DEFB 207
DEFB 179
DEFB 135

Tady je ta chybna dokumentace(tabulka na strane 145/stranka znacena cislem 127):
http://www.z80.info/zip/um0081.pdf

DMA rutiny na ZX zapisuji do DMA vetsinou celych 20 bajtu. Rozdil je v tom, ze na zacatku nastavuji softwarovy reset DMA, nastavuji pro cteni i zapis vlastni casovani signalu a nastavuji i stav registru 3, ktery zase v dokumentaci (viz. link) vynechavaji. Asi se spolehaji na default stav.

_________________
http://velesoft.speccy.cz/

Veď to tam máš aj na videu !
Pre rolovanie obrazovky dokola o dva body vlavo treba pred každým DMA prenosom posunúť prvý bajt každého riadku o jeden riadok nižšie a zvetšiť veľkosť prenášaného bloku pre DMA o jeden bajt. Používa sa jeden bajt nasledujúci za obrazovkou !

ld hl,scr+24576-128
ld de,scr+24576
ld b,192
loop:
ld a,(hl)
ld (de),a
ex de,hl
dec h
djnz loop
ret


Ešte mám dotaz k tej rýchlosti:
Neviem ako to funguje a možno práve preto mi je divné že prenos 3T read + 3T write trvá priemerne skoro 10T ?
Keď vie ASIC signálom Wait pozastaviť DMA pri časovaní 3T+3T, prečo to už nevie pri 2T+2T ?

Nojo, mas pravdu. To je jednoduche reseni a DMA prenos muze zustat v jednom bloku pri plne rychlosti. A pri posunu obrazovky, kde se ma objevit nova grafika (jako R-TYPE/ZYNAPS) staci do obrazovky vykreslit vzdy jen novy levy sloupec, ktery se po DMA prenosu objevi zase vpravo Posun po 2 pixelech je nejjemnejsi mozny posun v modu 4, v modu 3(hi-res) je pak posun minimalne o 4 pixely. Pri vetsim kroku posunu treba o 8 pixelu uz by byla casova narocnost pro vykresleni noveho sirsiho sloupce nekolikanasobne vetsi, ale zase s DMA to bude stale rychlejsi nez scroll ciste softwarovy. Pro graficke operace je DMA ted vhodne tam akorat k presunu delsich bloku, takze vlastne scroll obrazovky do vsech stran, klidne i sikmo a to v nekolika uhlech posunu. Procesor pak bude pripravovat nove slopce/radky, DMA provede samotny scroll obrazovky, a procesor pak uz jen muze vykreslit pohyblive sprajty. U vetsiho mnozstvi mensich pohyblivych predmetu nema smysl pouzivat DMA ale vyplati se sahnout po CPU. Kdyby se jeste pripojilo dalsi DMA, ktere bude mit zprehazene adresove vodice, tak by mohlo vykreslovat graficke ctverce treba 16x16 pixelu. Vlastne by oboji zvladlo i jedno DMA, jen kdyby se na desku vesel multiplex... U 4vrstve desky by to slo zajistit.



A nebude spis problem v tom, ze DMA pracuje v rezimu, kdy ma multiplexovany signal CS a WAIT ? Totiz neco jsem tusim cetl o tom, ze pokud ma DMA pracovat s WAITem, tak se nedoporucuje casovani kratsi nez 3T. Nechce se mi to hledat znovu ale nekde jsem to vcera fakt cetl. Spis je zarazejici, proc nefunguje rezim 4T...

Zde je screenshot z DMA prenosu v grafickem modu 4 v okamziku, kdy ASIC(ULA) vykresluje border. Pristup do pameti je zde pribrzdovan waitem tak, aby trval vzdy 4 takty CPU. Prenos jednoho bajtu = 8T CPU.
http://velesoft.speccy.cz/other/dma%203Trd+3Twr-mode4.png

V dobe, kdy ASIC zrovna vykresluje videoram, je pamet sdilena a waitem kazdy pristup do pameti protazeny na 8T CPU. Prenos jednoho bajtu pak trva 16T CPU. Screenshot je zde:
http://velesoft.speccy.cz/other/dma%203Trd+3Twr-mode4-contended.png

Pri prenosu delsiho bloku dat je DMA jen trochu dobrzdovano ULOU na 8T/byte v dobe kdy je TV paprsek mimo pixelovou cast obrazovky, coz je cely horni a spodni border + levy a pravy border. Pri pohledu na dobu, kdy ula vykresluje grafiku, je videt jak je DMA brzdene na 16T/byte a to po dobu 256T a dalsich 128T je levy a pravy border. Za dobu kdy ASIC vykresli jeden TV radek s grafikou, DMA prenese v rezimu 3Tread+3Twrite v modu 4 presne 32 bajtu. A za kazdy TV radek v hornim a spodnim borderu dokonce 48 bajtu.

Presna kalkulace (dma rezim 3Tread+3Twrite):
- jeden tv radek trva 384 taktu CPU
- sam generuje 312 tv radek = celkem 119808 taktu CPU
- celkem 256 tv radek zabere usek s grafikou
- zbyvajicich 120 radek je vyuzito pro border (zjednodusene receno)
- v prubehu kazdeho radku borderu se stihne prenest 48 bajtu (384taktu / 8t prenos = 48 bajtu)
- v prubehu kazdeho radku grafiky se stihne prenest 32 bajtu brzdenych na 16T a 16 bajtu v bocnim borderu

- horni+spodni border = 120 tv radek * 48 bajtu = 5760 bajtu
- graficka cast = 192 tv radek * 32 bajtu = 6144 bajtu
Za jedno kompletni preruseni (50Hz - 119808 taktu pri 6MHz) stihne DMA v rezimu 3Tread+3Twrite prenest presne 11904 bajtu.
Videoramka v modu 4 na sam coupe zabira 24576 bajtu. Fullscreen scroll videoram by DMA cipu trval o neco vice nez dve preruseni, coz je skoda. Ale pokud vynechame 6 mikroradek videoram, se kteryma nebudeme manipulovat, tak by DMA melo zvladnout scroll na 25fps. Realita je ale trosku jina, protoze potrebujeme cas na nastaveni dma prenosu a dale CPU musi prepinat videoramky a dokreslovat sloupce ci radky s grafikou a vykonavat i jiny potrebny kod. Takze bud se spokojime se 17Hz scrollem (mame na dma scroll dve a kousek preruseni a temer cele treti preruseni je pro potreby cpu), nebo budeme mit 25Hz scroll ale za cenu mensi obrazovky. Mam ale obavu, ze aby cpu mohldelat take neco jineho, bude potreba usek videoram jeste znacne zmensit a to uz moc pekne nebude vypadat a i tak CPU nebude mit tolik volneho casu jako pri 17Hz scrollu.

_________________
http://velesoft.speccy.cz/

Kedysi som robil podobny experiment - ale namiesto 50 Hz V-sync som do DMA priviedol 15625 Hz H-sync. Mojim cielom bolo pomocou DMA a D/A prevodnika ziskat cosi ako zvukovu kartu, ktora by dokazala autonomne zahrat nejaky sampel. Ale potom som sa tomu uz nevenoval, pretoze vzhladom na nutnost HW upravy (DRQ pripojene na H-sync) by to aj tak nefungovalo vsetkym (co uz maju DMA aj D/A prevodnik).

Se soucasnym data-gearem se toho uz pro zrychleni nic delat neda. Ovsem kdyby se na desku pridala rychla sramka, dal by se dma prenos jeste zrychlit, teoreticky az dvojnasobne. Ale je to dost prace a rovnou by bylo vyhodnejsi nahradit DMA jednim CPLD, coz by rozsirilo moznosti naprosto neskutecnym zpusobem = az nekolikanasobne rychlejsi prenos dat, moznost vykreslovat i sprajty, pripadne i maskovane.

_________________
http://velesoft.speccy.cz/

Takze po delsim abstaku zpusobenem dostupnosti slabe wifiny pouze na vzdalene recepci hotelu,
jsem dnes po navratu ve tri rano hltave uspokojoval, mezi prestavkami v zalevani vyprahle zahrady,
informacni hlad... a same breaking news.


A v telefonatu s Velesoftem jsem si potvrdil:

Deska je funkcni, menit se nebude. Vsem drive objednanym tento tyden posilam postou.
Vice kusu uz volnych nemam, ale zitra objednam vyrobu dalsich 10 kusu. Takze dojde i na zbyvajici sharpisty a enterprisisty

Co se tyce DMA, Velesoft jeste oba me ruzne kousky potestuje, aby mj. potvrdil ci vyvratil podezreniz padelku - ci potrebe upravy napajeni. DMA tedy neposilam (spolehlive kusy ma snad uz Suksoft...).

O dalsi soucastky nebyl zajem, Velesoft mozna jeste obmeni napajeci cast... ale to uz jsme schopni si nejak poresit (stejne jako event. zmenu obsahu GALu).

_________________
// na co myslím, když sedím u oldkompů: Durov