jojo, měto připomnělo, že pořád ještě mám komentovanej výpis romky http://kabinet.cz/…age00057.htm – pro většího nadšence je stále k dispozici, vyhodit je mi to líto :-)
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.
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).
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(
_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í! ;-)
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.
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.
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.
Tak jsem se tím trochu vrtal a je to takhle
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 ;-)
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 :(
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 ;)
Ř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í.
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žší.
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.
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.
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“.
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.
Ještě přidávám malé doplnění ke kapitole o ZX80 a ZX81. Podařilo se
mi zachránit další tři odstavce, které se mi záhadně „ztratily“
z Flashky (nějaký noname výrobce), samozřejmě až po vydání článku
:-(
Při generování obrazu na ZX81 se využívala velmi úzká spolupráce
mikroprocesoru Z80 s čipem ULA (Uncommitted Logic Array) vyrobeným
speciálně pro tyto počítače firmou Ferranti. Konkrétně se využívalo
specifické vlastnosti mikroprocesoru Z80, který v režimu HALT (zastavení a
čekání na přerušení) nezastavil zcela svou činnost, ale neustále
opakoval instrukce NOP (tuto instrukci již známe, značí no-operation),
během nichž se neustále měnil obsah registru R (refresh counter).
Mikroprocesor také sloužil pro generování adres znaků, které se měly
zobrazit na obrazovce. Použitá technika byla zajímavá: mikroprocesor skočil
(instrukcí JMP) na začátek řádku v obrazové paměti a snažil se, jak je
to běžné, načítat instrukční kódy jednotlivých instrukcí. Ovšem tento
stav byl zachycen ULA (jednalo se o adresu zvětšenou o 32768, tj.
s nastaveným nejvyšším bitem). Mikroprocesor postupně na adresovou
sběrnici posílal zvyšující se adresy a paměť (zcela běžně) na datovou
sběrnici posílala kódy jednotlivých znaků, co znak to jeden byte. Tyto byty
nikdy nebyly mikroprocesorem přečteny: ULA je „ukradla“ (a využila),
zatímco všechny vodiče datové sběrnice nastavila na logickou nulu.
Mikroprocesor tedy ve skutečnosti přečetl místo kódu znaku (který by
pravděpodobně nedávat jako kód instrukce smysl) byte s hodnotou 0, což
v instrukční sadě Z80 značí NOP. Jediný kód, který ULA z datové
sběrnice neodstranila, byl kód pro novou řádku (NEWLINE) zakódovaný do
čísla 118, což je (jistě ne náhodou :-)) operační kód instrukce HALT.
Od této chvíle je mikroprocesor zastaven (provádí NOP a zvyšuje obsah
registru R) až do chvíle, kdy obsah registru R přeteče z maximální
hodnoty do nuly. V této chvíli se vygeneruje přerušení a činnost
mikroprocesoru může pokračovat. Čip ULA se interně stará
o zpracovávání jednotlivých znaků. Adresy znaků jsou generovány pomocí
mikroprocesoru (viz odstavec výše), ULA v každých čtyřech taktech
vygeneruje osm pixelů. ULA obsahuje vnitřní čítač použitý pro načtení
korektního bytu z paměti ROM, která obsahuje bitové mapy znaků – adresa
dodaná CPU je s obsahem tohoto čítače zkombinována a výsledkem je adresa
konkrétního jednoho řádku bitové mapy znaku, který je načten z ROM do
ULA, konkrétně do posuvného registru, ze kterého jsou jednotlivé bity
vysouvány a použity pro generování video signálu.
Jo, takto som vo svojom deme riešil „každý riadok iná dvojica farieb“ (čiže časovanie atď), ale nestihol som to na celú šírku, myslím že niekto iný áno, hoci netuším ako.
Myslím, že keby Sirovi Sinclairovi v roku 1982 ukázali nejaké Spectrum demo z roku 2000, tak odpadne. ;-)
Najdete si kontakt na http://www.ttklavesnice.cz/ a napiste jim. Folie maji doslova za babku. Hlavne zapomente na zlatokopy na aukru, tady nakoupi folii za 120 a na aukru ji prodavaji za 500.
To je s velkou pravdepodobnosti vadny ASIC, ktery neni dostupny a nema zatim nahradu. S popisem chyby grafiky se muzes ozvat na sam.coupe@centrum.cz.
sam.speccy.cz
Nedokázal by někdo poradit, zdali se nedá z toho Dooma nějakým způsobem dostat ta hudba? Tajle se dá stáhnout: http://www.users.zetnet.co.uk/…ews/doom.htm
Jsem napsal GPL hru v assembleru http://ronja.twibright.com/jswx.php
GPL softwaru existuje víc
http://demfir.sourceforge.net/ (pro DivIDE) http://ci5.speccy.cz/mdos3/ (pro DivIDE) http://cygnus.speccy.cz/ (sekce utility)
A kdyby někdo hledal manuály – výše třeba výpis ROM, tak nejlepší o kterém vím je zde http://softhouse.speccy.cz/docs.htm plus další dokumentace ve skvělém zpracování.
Len poopravím link, lebo z organizačných dôvodov som dokumenty presunul na http://softhouse.speccy.cz/dokumenty.htm
Koupil jsem si ZX81 pred 33lety..
Dnes opet - z nostalgie.
Tenkrat jsem mel k dispozici RAM 1KB !!!! A kazetu se 2 hrami. "Tiranosaurus Rex" a "Pristani na mesici". Neskutecne v jednom kile...
Tak rad bych si jeste dnes pristal na mesici. Ale marne hry shanim.
Nama ji nekdo jeste?
Dekuji :-)
mdu@o2active.cz