Názory k článku
Grafika na osmibitových počítačích firmy Sinclair

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 :-)

A nechces to naskenovat a vyhodit na web?

Když to budu chtít na webu, nemusí to po nocích skenovat, stačí dotaz do oblíbeného fulltextového vyhledávače a mám to hotovo za pět sekund. Je libo v češtině nebo v angličtině? :-)

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.

To je sice všechno moc pěkné, ale nějak to neřeší přechod mezi třetinami obrazovky. Co s tím?

Na toto mi kedysi Raxoft poslal (listom, vtedy sme ešte písali listy, hehe) geniálne krátku rutinu myslím od TRC (Tomáš Rylek), keby som zalovil v krabici s poštou, tak to možno nájdem… možno to skúsim. :-)

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í! ;-)

Ještě poznámka: samozřejmě, že instrukce sub a,8 neexistuje, takže konec má vypadat následovně:

ret c

ld a,h

sub 8

ld h, a

ret

Hmm, mohlo to byť niečo také, veru…

Ale zistil som, že neviem kde mám starú poštu.

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.

Dovolím si drobné upřesnění. 8 jednobitových pamětí měl Didaktik M model 1990, model 1991 měl dvě čtyřbitové.

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.

Jsem si téměř jistý, že didaktik m neměl originál Z80 CPU, ale nějaký kompatibilní klon (možná kompatibilní klon inteláckého klonu). Ale tou frekvencí 4MHz jsem si naprosto jistý. Mimochodem, tyto údaje jsou k holdedání v originální příručce, kterou bohužel nemohu dohledat.

Tak jsem se tím trochu vrtal a je to takhle

1. Didaktik měl CPU na 4MHz
2. Byl to klon procesoru Z80A, v dokumentaci se však uvádělo, že je to odvozenina/nás­ledovník Intelu 8008/8080 (asi aby se neřeklo, že je to klon Z80)
3. Jiný ULA než originální ZXS – „čtvercový“ obraz 4:3, není rozdíl mezi rychlou (horní) a pomalou (dolní) RAM.
4. Díky noriginálnímu procesoru prý několik málo instrukcí trvalo jiný počet taktů (toto zatím nemám ověřeno)

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í.

1. Spočítat pozici jako r * 32 + s.
2. pro adresu bitové masky udělat 3× posun doleve (implementoval se tuším přes 3× ADD H,H)
3. pro adresu atributů přidat ty dvě jedničky.
4. 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žší.

Ja mam jeste matnou vzpominku, ze to mozna nejak souviselo s kolizi ULA a refreshem DRAM procesorem – ze refresh se delal linearne a tak ULA musela chodit nelinearne, aby se nikdy nepotkali na moc dlouho…

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.

Aha, teď to chápu, tady něco o tom píší.

http://8bit.yarek.pl/computer/zx.48/

Ak si dobre pamätám, tak ZX , alebo aspoň DM používali statické pamäti, takže precesor ani nikto iný nemusel refreshovať pamäť a R register bol jednoducho len featura procesora Z80, a na SM sa používal akurát na „generovanie“ náhodných čísel.

Aha tak ale stále som presvedčený, že so niekde čítal že o refresh sa procesor nestará (aspoň na DM), aj keď má na to register, zrejme to robila ULA.

Prohodil jsi IM0 a IM1. Problém je ale v tom, že Z80 na adresovou sběrnici v době refeshe neposílá jenom obsah registru R, který je 8bitový a počítá jenom 7bitově, ale na vyšší bajt posílá registr I.

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.

No koukal jsem jak puk

http://www.youtube.com/watch?…

Pred dvema dny jsem shlednul lonske demo Edge Of Disgrace pro C64. Absolutne nechapu. Co mne pobavilo, ze na stejne party byla i Music Compo a vyhral Jeroen Tel. 8bit porad zije, i kdyz to zni jako blbina.

jeste si pamatuji na trik pro rychle mazani obrazovky (nebo vynulovani kusu pameti). Stack pointer se da na konec vymazavane oblasti, do registru HL 0, a pak se registr HL uklada opakovane na stack. Bylo to mnohem rychlejsi nez LDIR.

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. ;-)

to se asi stihnout neda, pouziva se trik, kdy liche radky jsou plne (FFh) a sude prazdne a attributy se nastavuji pro dvojici radku.

… preto som v tom deme („Out of Time“) mal cez farebné pruhy čierny nápis „Out of Time“, vysprejovaný joystickom v Art Studiu. :-)

Neznate/nevite nahodou kde by mi spravili muj vadny SAM coupe. CPU a RAM jede, nejede grafika. Je to nostalgie, ale chtel bych aby byl ok. Diky za pripadne info.

ja zas mam Spectrum+ a potrebuji opravit folii pod klavesnici (klasika, ta odejde vzdy jako prvni a pak tlacitka prestanou fungovat).

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.

Klávesnice do pluska nestojí 120, ale dvojnásob plus 100Kč poštovné, takže kupovat kusy už zas tak výhodné není. 120 + poštovné stojí klávesnice do Gumáka, tak je o jednu vrstvu tlačítek jednodušší.

Taky zde: http://www.sintech-shop.cz/shop.php?…

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

Diky moc. Zkusim to.

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í.

Jo, jenže Karel toho Jet Set Willyho vytvořil už někdy v 90. letech, odhaduju kolem 1994 nebo tak, takže by se to mohlo možná stát prvním GPL programem pro Spectrum vůbec.

Len poopravím link, lebo z organizačných dôvodov som dokumenty presunul na http://softhouse.speccy.cz/dokumenty.htm

http://zxspectrum48.i-demo.pl/zxgallery.html