Vlákno názorů k článku Grafika na osmibitových počítačích firmy Sinclair od Michal Kára - Pokud se nemylim, v clanku neni zminka o prokladanem radkovani...
-
Michal Kára (neregistrovaný)
Pokud se nemylim, v clanku neni zminka o prokladanem radkovani ZX Spectra, tj. v pameti byl ulozen 1., pak 9., 17. … mikroradek az po 1/3 (?) obrazovky a nasledne 2., 10., 18., … pak stejnym zpusobem dalsi dve retiny obrazovky. Mam takovy dojem, ze toto bylo kvuli nejakym kolizim ULA s mikroprocesorem, ale tim uz si nejsem jisty.
-
_mj (neregistrovaný)
Niekto tvrdí, že je to kvôli rýchlejšiemu prístupu do videopamäti – spodný bajt pixelovej aj atribútovej adresy sa rovnajú a ULA nemusí toľko meniť CAS. Všeobecná zhoda je ale skôr v tom, že takéto organizovanie videopamäti umožňuje písať rýchlejšie rutiny, keď prechod na ďalší pixelový riadok je možné urobiť iba inkrementovaním horného bajtu adresy (síce iba v rámci „znakového“ riadku, ale využívajú to aj rutiny ROM).
-
Kiron (neregistrovaný)
No rychlejhší, jak se to veme. Pro ULUu určitě, pro programétora grafiky to byla pohroma. Např. vypočítat polohu bodu na obrazovce. Některé demo rutiny to dokonce myslím řešily tabulkou adres pro jednotlivé body, či spíše řádky. Ale co s tím někteří dokázali, nad tím mi tůstávál stát ..... rozum. Největší frajeřinou byly border-efekty, čili třeba běžící text v okraji obrazovky, kde se dala pouze měnit barva. Rychlou změnou barev v průběhu vykreslování paprsku na televizi se tam v podstatě dalo „kreslit“ :o)) No na mém Didaktiku M to většinou nefičelo, protože obvod ULA byl nahrazen jiným, my mu říkali pracovně ČULA, a takto přesné časování nesedělo s paprskem obrazovky :o(
-
JS (neregistrovaný)
_mj ma pravdu. Pokud mate adresu do videopameti v HL, pak je skutecne snazsi a rychlejsi dat INC H nez nahravat obsah H do A, abyste mohl pricist 32. Pocitani polohy bodu na obrazovce se nepouziva tak casto, vetsinou spis potrebujete posunout to, ceho adresu uz stejne nekde mate.
-
Nikdy jsem to neřešil, ale jen tak narychlo z hlavy jsem vymyslel následující:
add h ; zvýšení mikrořádky
ld a, h
and a, 7 ; test na přetečení mikrořádky
ret nz ; návrat, pokud nedošlo k přetečení
ld a, 20h
add a, l ; zvýšení řádky, test na přetečení třetiny
ret c ; návrat, pokud došlo k přetečení
ld a, h ; snížení hodnoty třetiny, když přetekla mikrořádka a nepřetekla řádka
sub a, 8
ret ; šlus
Princip je v tom, že adresace je normální, jen tři horní bity registru L jsou prohozené se třemi dolními bity registru H. Je možné, že to jde ještě jednodušeji, ale zatím mě nenapadlo jak. Těším se na vaše vylepšení! ;-)
-
Bobo E (neregistrovaný)
Tak na to si přesně vzpomínám. Jako zázrak potom působily rutinky UPHL a DOWNHL z knihy Assembler Z80 od George K, které právě řešily přechod adresy jednoho pixelového řádku (uložená v registru HL) na následující.
Co se týče border efektů, ty na „emku“ opravdu neběžely korektně. Ale mám pocit, že to bylo hlavně proto, že CPU tohoto Didaktiku (tuším nějaký Intel 8080) běželo na 4MHz, což rozhodilo časování (dělané většinou syncvhronizací s přerušením – halt – a prokládáním programu nicnedělajícími instrukcemi – nop, or a, ld a,a ap.)
Ještě si pamatuju na český program (nevzpomenu si na jméno), který jsem viděl v jednom čísle Proxima magazínu – uměl tzv. Hi-Color obrázky, tj. časováním obcházel omezení dvou barev na 8×8 a umožňoval dvě barvy na 1×8 bodů. Fullscreen obrázek sice žral téměř všechen procesorový čas, ale zbylo něco málo třebas na scrollující text a přehrávání hudby přes AY.
-
Kiron (neregistrovaný)
Kde jste proboha vzali ty 4MHz???? Mělo normálně 3.5, dokonce tam mám originál Zilog CPU. Kdyby tam dali intel 8080 tak vám tam nic nepoběží, protože zilog Z80 a klony měly rozšířenou instrukční sadu. Kompatibilita pouze směrem dolů k intelu 8080, né naopak. Problém byl skutečně pouze ten nový zákaznický obvod.
-
wintermute (neregistrovaný)
No Intel 8080 to urcite nebol. To by na tom skoro nic nebezalo, kedze original mal procesor Z80 a kompatibilita bola len v smere z Intel 8080 na Z80 ale nie uz opacne.
Bol to procesor z byvaleho vychodneho nemecka a mal oznacenie U880D a bola to kopia Z80 ale dobra kopia, tu by som problem nevidel. Skor to bolo tou pamatou.
-
Bobo E (neregistrovaný)
Tak jsem se tím trochu vrtal a je to takhle
- Didaktik měl CPU na 4MHz
- Byl to klon procesoru Z80A, v dokumentaci se však uvádělo, že je to odvozenina/následovník Intelu 8008/8080 (asi aby se neřeklo, že je to klon Z80)
- Jiný ULA než originální ZXS – „čtvercový“ obraz 4:3, není rozdíl mezi rychlou (horní) a pomalou (dolní) RAM.
- Díky noriginálnímu procesoru prý několik málo instrukcí trvalo jiný počet taktů (toto zatím nemám ověřeno)
-
Radovan (neregistrovaný)
Frekvenci 4 MHz (a ruskou ULA) měly Didaktiky M a Kompakt, původní Gama s originální ULA od Ferranti jela na 3,5 MHz stejně jako Speccy. Já mám v jednom Didaktiku NEC D780 a v druhém Z8400, mám pocit že přímo od Zilogu, ale už je to pár let co jsem ho měl rozšroubovaný, takže to nevím přesně. A aby to s těmi odvozeninami bylo úplně přesné, tak Z80 nevychází přímo z 8080, ale z jeho nástupce 8085 ;-)
-
Rado2 (neregistrovaný)
Ak niekto potreboval prevádzať súradnice pixelu na adresu, tak zle rozmýšľal. Ani v dnešnej dobe nikto neprogramuje celú grafiku cez PutPixel. Bolo potrebné prepnúť na vyššiu úroveň predstavivosti a písať rutiny priamo pre pamäťový model ZX. Dali sa tak napísať rýchle rutiny pre vykreslovanie čiar aj spritov. To je pre hru hlavné, nie je porebné kresliť nejaké bodky. Myslím že ku koncu éry DM som to tiež dostal do krvi a nebol to problém. Dnes by som už asi na vlastné programy pozeral ako puk a zrejme sa mi asi aj tak nič už nezachovalo :(
-
P.V.L. (neregistrovaný)
tato „finta“ s INC H je dobra max pro kresleni znaku .. a koho zajima rychlost v „textoveho rezimu“.. Pro jakoukoli grafiku je to ale naprosto k nicemu, protoze to neni universalni ale plati to jen v ramci kazde tretiny obrazovky..
Takze uprimne doufam v to co se tvrdilo, ze to je kvuli rychlemu vykleslovani ULA (pixel i atribut maji stejnou pulku adresy)
no ale co, aspon to nebyla takova nuda neco kreslit ;)
-
ondra.novacisko.cz (neregistrovaný)
Řekněmež, že framebuffer je na adrese 0 (BIT 14 = 1, BIT 15 = 0, neuvažuji
BIT 0–4 = sloupec (s)
BIT 5–7 = řádek v třetině ®
BIT 8–10 = řádek ve znaku (m)
BIT 11–12 = číslo třetinky (t)
Jak to přepočteme na adresu atributů? Atributy začínají na adrese 6144 (BIT 11=1, BIT 12 =1). Mapování tedy bude takovéto:
0 1 0 1 1 0 t t | r r r s s s s s
ULA tedy nemá o nic lehčí práci, než jen brát jiný bity. Pokud bych totiž měl běžné mapování ttrrrmmmsssss, pak udelat z toho 110ttrrrsssss je otázkou posunu pěti bitů o tři pozice. Místo toho tedy posouváme jen 2 bity. Posun se přitom zadrátuje velice snadno, prostě jen přepojíme piny.
Důvody je třeba hledat v ROMce. Pro výpočet adresy znaku a atributů stačí následující.
- Spočítat pozici jako r * 32 + s.
- pro adresu bitové masky udělat 3× posun doleve (implementoval se tuším přes 3× ADD H,H)
- pro adresu atributů přidat ty dvě jedničky.
- pro každý mikrořádek pak stačí INC H
Zase, kdyby to bylo ve formě ttrrrmmmsssss, pak je to ještě jednodušší, protože by se do H strčil řádek a do L sloupec. Výpočet attributové oblasti však bude náročnější, i posun o mikrořádek už nebude triviální.
Já sám osobně zastávám spíš názor nechtěné chyby, tedy někdo při návrhu ULA někde otočil číslování a ROMka se pak přizpůsobila dané chybě, protože cokoliv jiného by vyšlo dražší.
-
Pavel TišnovskýZlatý podporovatelAno, mam dojem, ze prave toto byl duvod pro to rozdeleni pameti. Ale pri natahovani obrazku to vypadalo docela efektne :-)
Mimochodem, uplne stejnou veci trpi i CGA (radky nejsou adresovany linearne) a tam je to uplne zbytecne, slo by to odstranit prohozenim dvou vodicu.
-
to je blbost, refresh tam byl 7bitovy, tedy cpu refreshuje najednou vsechny adresy, jejichz spodnich 7 bitu odpovida obsahu 7 bitu r-registru z80.
btw, synchronizace ula s cpu se da i rozbit a to tak, ze se do i registru da hodnota ukazujici do druhe ctvrtiny ram. tim se lehce naboura zobrazovani (rozjede se o 1 byte).
podle me je geometrie obrazu dana casovanim (256 bodu na radek, z toho 192 ovladatelnych, zbytek border atd..). a sekvence adresovani je optimalizace, aby byl hw co nejlevnejsi.
-
ondra.novacisko.cz (neregistrovaný)
Nebyl on registr I v Z80 použit pro vektorová přerušení?
IM 0 – při přerušení RST 38 IM 1 – při přerušení přečte datovou sběrnici a data interpretuje jako instrukci IM 2 – přečte datovou sběrnici a byte spoji s hodnotou I registru, Výsledkem je adresa, ze které vyzvedne dvobajtové číslo, jenž obsahuje adresu obslužné rutiny.
Škoda, že změna vektoru přerušení neumožnila změnit chování instrukcí RST.
-
Pavel TišnovskýZlatý podporovatel
Z80 mela jak registr I (interrupt), tak i registr R (refresh, ten se automaticky inkrementoval po skoro kazde instrukci a tak vlastne obcerstvoval DRAM pameti dummy ctenim, u slozitejsich instrukci s prefixem se jeho hodnota zvysila o 2).
Mikroprocesor ihned po nacteni kazde instrukce tento registrovy par zapsal na adresovou sbernici a skutecne – pokud I prekrocilo 64, tak to ULA zmatlo a vynechal jeden byte (mozna i atribut??? – fixme), takze obrazovka byla „zasnezena“.
-
Substance242 (neregistrovaný)
Neviem, či som nejako takto nechcene neprišiel na „efekt“, kedy bol okolo všetkého akoby „šum“, že riadky trochu lietali vľavo-vpravo. Muselo to byť niečo veľmi krátke, lebo viem že som to mal hneď v BASICovom loaderi a že Raxoft mi písal že to nie je celkom korektné a môže byť na inom počítači (klon) problém, alebo s nejakou perifériou, alebo tak čosi.
-
Pavel TišnovskýZlatý podporovatel
Skutečně není, bude to uvedeno příště (v rámci multicolor režimů) i s vysvětlením časování při vykreslování, tj. přesně jakým způsobem se vykreslilo celých 312,5 obrazových řádků na televizi. Pěkně to popsal jeden autor emulátoru Speccyho, ten s tím docela bojoval.
