Názory k článku Jak se dělá pixel art?
-
anonymníhttp://www.humanbalance.net/gale/us/
GRAPHICSGALE umi gradace v palete, nahledove okno, layery, animace s timelajnou a nahledama a milion dalsich veci a je zadarmo !!! Na Pixel Art neni za ty 0 prachy nic lepsiho ! milionkrat lepe ovladatelne jak GIMP milionkrat rychlejsi ! -
petris (neregistrovaný)Pamatuju si, ze jsem mel program, kterej na atari 800xl zobrazil matici 256ti ruznejch barev (najednou). Zkousel jsem to vygooglit, ale nasel jsem jenom tydle mice http://www.youtube.com/watch?v=pfz-e7iwJTM a prohlizece na jpegy http://rjespino.tripod.com/8bit/colrjpeg/gallery.html (doporucuju kouknout i na ty cernobily)
-
Najvacsi problem ale bol v obmedzeni farieb per line. Cim viac farieb (max 16) sa malo zobrazit v jednom riadku, tym bolo rozlisenie mensie. Nasledne sa samozrejme v dalsom riadku mohla zmenit napr. paleta (alebo kompletne zobrazovaci mod), takze sa dali spravit rozne figle a zdanie viacfarebnosti, avsak z mojho subjektivneho pohladu bola (najma staticka) grafika na atari menej pestra, ako na zx / c64. -
Pavel Tisnovsky (neregistrovaný)Mate pravdu, moc zmen v barvovych registrech Atarka se na jednom radku nedalo provest a kdyz uz, tak se muselo velmi peclive casovat. Zmeny barev mezi jednotlivymi radky byly OK, ostatne efekt s horizontalni duhou byl vlastne uz na Atarackem logu.
Spectrum melo nejvetsi problem v tom, ze se nedalo prepnout do stupnu sedi. Samozrejme se to resilo HW upravou ale je to skoda, protoze mit rezim 256x192 v sestnacti stupnich sedi by nebylo k zahozeni. -
Pavel Tisnovsky (neregistrovaný)No to ja taky, ale mel jsem elektronkovy televizor Salermo. To byl strasny hnus - nejak blbe navrhli obvod pro synchronizaci obrazu, takze ve chvili, kdy elektronka ECL-85 nebo ECL-805 trosku zestarla, tak zacal obraz rolovat nahoru nebo dolu. Dalo se to rucne doladit vzadu nejakym potenciometrem, ale nakonec jsem si ten potak vyvedl az k pocitaci, protoze to po zahrati rolovalo kazdych par minut. Proste bomba - v dobach integracu s mnoha desitkami az stovkami tisic tranzistoru jsme v Elektrodome shaneli elektronky (a porad je meli, asi ta chyba nebyla jen u Salerma; presneji receno je meli pod pultem, proto si taky pamatuji to oznaceni).
-
Pavel Tisnovsky (neregistrovaný)mozna PCL, to presne nevim. Ale cislo bylo tutove bud 85 nebo 805. Tusim nejaka dvojita pentoda nebo neco podobneho. nakonec jsem nasel schematko, ve kterem tu elektronku nahradili tranzistory, ale nakonec jsem tu televizi stejne vyhodil a pouzil mnohem lepsi Color Oravan.
-
Kiron (neregistrovaný)Tez se mi zda ze PCL, jojo, uz tenkrat jsem jako osmilety koukal opravari na prsty :o)) Ten potenciometr byl uzasna vec, pamatuju si jak nektery clen rodiny ladil, a ostatní ho povzbuzovali a radili o kolik a kam pootocit, protoze kdyz jste ladil, tak jsete nevidel na obrazovku :o))
-
tisnik (neregistrovaný)Televizi bylo zapotrebi z boku obejmout :-), levou rukou ladit a koutkem oka sledovat obraz (jeste ted bych ten pohyb zvladl, odhaduji, ze ho delalo tak milion lidi). Nebo se dalo koukat na okolni skrine se sklenenou vyplni, co se tam odrazi. Proste genialni vyrobek socialistickeho planovani.
-
krupkaj (neregistrovaný)Omezeni na radek je docela velke, nicmene kouknete se na obrazky, ktere se daji delat v programu Graf2font http://g2f.atari8.info/
-
tisnik (neregistrovaný)presneji: omezeni 4/16 barev na radek je pouze v pripade, ze program meni barvove registry v horizontalnim navratu paprsku, tj. pri preruseni. To je ficurka Atarka (a treba i VGAcka). Pokud nekdo zvladne nacasovani zmeny barvovych registru i uvnitr radku, je tech barev samozrejme vic.
Uz bych to asi nespocital, ale mam dojem, ze barva se ustihala menit kazdych cca 5-6 pixelu a to uz je slusne. Samozrejme zalezi na tom, jak je cely obrazek popsan, ono mit nekde bitmapu o 8 kB a vedle toho na dalsich 8 kB barvove pole uz je docela dost. Tj. tech barev na radek muze byt vic nez 4/16, ale chce to fikanejsi program. -
Pavel Tisnovsky (neregistrovaný)omlouvam se, zapomel. Trosku jsem se o nem zminoval v predchozi casti tohoto serialku, ale tady na nej nevyzbylo misto. AA Pro jsem moc nepouzival, ale puvodni AA byl opravdu dobry. Byl to vlastne maly programek (urcite se vlezl na disketu) a umel toho strasne moc. Co se mi libilo:
- vyber nastroju (do sesti ci osmi tlacitek se daly vybral libovolne nastroje, tj. clovek nemusel mit obrazovku preplnenou)
- nastrojova lista se dala vypnout a potom byl videt obrazek v plne krase 320x200 pixelu
- dobre vyreseny animace pres cells
- podpora pruhlednosti (sice jen 1bpp, ale zato ovladatelna mnohem lepe nez u nekterych konkurentu)
kam vubec AA zmizel? Vim, ze autodesk mel neco pod Windows, ale to bylo tusim uz vektorove.
Jeste neco jste mi pripomel: animaci Top Gun (ceskou) Zna to jeste nekdo??? -
TM (neregistrovaný)AA pro sel jeste dale - prinesl SVGA (v zavislosti na karte a podpore VESA az 1024x768 bodu), lepsi animaci a tusim i pruhlednost),... naprosto genialni bylo jeho ovladani (nastaveni pouzivanych funkci, nastaveni zoomu, celikosti oken),...
skoda ze nevznikla zadna dalsi verze - propracovat se az do dneska jako alternativa k photoshopu tak by to bylo super...
K topgun - existoval i druhy dil.. sice kratsi, ale taky nebyl spatny... jednicku je mozne prohlednout na http://www.youtube.com/watch?v=bu9qdKeh05A -
Pavel TišnovskýZlatý podporovatelty byl az AApro ne? AA delal FLI v rozliseni 320x200 (klasicky VGA mod 13h) a az AApro umel FLC a tim i vyssi rozliseni vyslednych animaci.
Osobne si taky myslim, ze zpusob ovladani AA i jeho GUI je dost dobry. Podle vseho je to prace nekolika lidi (i pod 3D Studiem pro DOS je nekolik autoru), takze moc nechapu, proc to AutoDesk dale nezainvestoval. Jak uz jsem psal, tak neco vzniklo i pro Windows, ale takove nemastne neslane (podobne dopadla T602, jeji windowsovska verze taky byla nic moc). -
potwor (neregistrovaný)No, ja si nemuzu pomoct, ale "Leonardo" byl jenom jinak pojmenovany artist - oproti art-studiu mel navic elipsy, prekonaval ho ale tak maximalne uvodnim obrazkem, protoze byl cca 2x pomalejsi - no a kdyz vyslo ArtStudio128, tak ho uz neprekonalo nic..
jeste si vybavuju "ScreenMachine", ktery jako jediny co vim mel funkci "natocit obraz po stupnich" - patrilo to k dtp baliku "Textmachine" -
anonymníDovolil jsem si ušetřit vám čas (a můžete ho na oplátku věnovat psaní dalších super článků, které hodnotím jako jedny z nejlepších, co na rootu pamatuju):
http://creativebits.org/the_first_version_of_photoshop
http://www.guidebookgallery.org/apps/photoshop -
Pavel Tisnovsky (neregistrovaný)moc dekuju za odkazy i hodnoceni clanku :-)
Kdyz se na to divam, tak jenom od oka mam dojem, ze se dokonce "inspirovali" i presnym tvarem ikon - namatkou "laso", "tuzka", "ruka" jsou snad na pixel stejne :-) U "obdelnikoveho vyberu" to jeste beru, co taky jineho vymyslet... Njn, hlavne ze Adobe dneska nechava zatykat ruske programatory... -
Obrazovku tvoril pomocny obvod ULA, jedine co to zatezovalo z pohledu behu programu byly pristupy do pameti, takze cely druhy 16kB blok pameti (prvni cast byla VRAM) byl malinko "pomalejsi". Rozdil se dal poznat tak ze kdyz se do toho bloku pameti ulozila tabulka preruseni, tak na obrazovce zacalo "snezit" protoze ULA nekdy nedostala data z VRAM.
Na Atari800 myslim CPU delal i obycejny obraz, casto se pak jeste pridali radkova preruseni po vykresleni urciteho radku na zmenu spritu/barev (u ZX preruseni na konci radku neexistovalo, programy si samy pocitali pocet taktu procesoru a kde se nachazi vykreslovaci paprsek na TV), a samotny program pak jel o dost pomaleji oproti tomu kdyz se vypnulo zobrazovani. Na C64 urcite sli delat taky radkova preruseni, ale nevim jak se generoval obycejny obraz. -
Pavel Tisnovsky (neregistrovaný)Nene, z tohoto hlediska je na tom Speccy a Atarko velmi podobne - cteni pixelu pro zobrazovani nedelal CPU, ale jiny obvod. Ovsem v pripade Atarka se graficky koprocesor (Antic) prihlasoval o sbernici tak, ze poslal signal HALT, procesor se zastavil a ANTIC si v klidu precetl co potreboval. Proto cim "vetsi" graficky rezim se pouzil (GR.8, GR.15), tim vice casu CPU stravil v rezimu HALT. Maximalni zpozdeni bylo cca 30%.
Speccy na tom bylo podobne - pristup do spodni RAM byl pomalejsi, ale mozna to nebylo az o 30%, ale min.
Co si pamatuji, tak C64 jel na necelem 1MHz a jak CPU 6502 tak i VIC (graficky cip) se pri pristupu do obrazove pameti stridaly. Dokonce tusim, ze VIC mel nejaky buffer na cely obrazovy radek nebo barvove atributy. -
duri (neregistrovaný)Na spectre boli maskovane hodiny CPU. Ked sa cpu snazilo dostat do vram (cely dolny 16k blok ramky) a prisla poziadavka od uly, procesoru sa jednoducho zastavil takt, a pokracoval az ked ula skoncila. Na zbernici boli medzi procerom a zvyskom datovej zbernice (ULA a vram) odpory aby sa natvrdo ignoroval stav CPU zbernice v case ked bola ULA master :). V pripade ze CPU islo do hornych 32k ramky frcalo to bez prerusovania na plny vykon. Ako kolega hore spomenul dalo sa trikom zaistit prsanie obrazu co bolo sposobene vlastnostou Z80 procesoru pri spracovani prerusenia, ale uz si nepamatam ako to presne fungovalo (je to straasne davno :) )
-
Pavel Tisnovsky (neregistrovaný)Aha, takze to opravdu pracuje na zhruba stejnem principu. Zatimco Antic posilal do 6502ky signal HALT, tak se u speccyho se zastavily hodiny, coz je vlastne to same (zastaveni hodin u Z80 zapricinilo nastaveni vstupu do vysoke impedance?). Akorat nevim, jak by se na neco podobneho 6502ka tvarila, kdyby ji nekdo zastavoval hodiny, takhle dobre emulatory nejsou, aby to slo odzkouset :-(
-
duri (neregistrovaný)na to boli rezistory na zbernici medzi cpu a ulou z vram ! mily a neskodny hack :) Ule bolo jedno co si cpu robi zo zbernicou v pripade ze isiel pristup na hornych 32kb ktore boli spojene priamo. Ked isiel na dolnych 16kb (ula to vedela podla adresnej zbernice) tak mu podla potreby zastavila hodiny aby nekolidovala adresacia z vram a odelovacie rezistory sa postarali o to aby bolo jedno aky je stav na CPU datovej zbernici.
-
duri (neregistrovaný)este doplnim, na scheme:
http://zxm.speccy.cz/dok/sch/ZX%20Spectrum%20Issue%202%20Schematics%20+%20Layout.zip
su to rezistory R1-R8 dole pod pamatovym blokom IC6 (4116) -
ja jeste doplnim, ze ula (tj. rekneme tehda pouzivany predchudce fpga) mel v logice chybu, resp. mel jednodussi logiku, takze obcas nefungoval uplne spravne. dal se presvedcit k cekani na cpu. slo ho k tomu prinutit treba prepnutim do im2 a presunem interrupt tabulky, nebo hranim s r-registrem (refresh registr, s tim se daly delat veci.. :-)
chybu opravoval pocitac mistrum (vysel tusim v jednom modrem AR), ktery se pozdeji upraveny prodaval jako Didaktik M. -
Zilog (neregistrovaný)ULA cetla videoram ve "fast-page" modu, tj. naadresovala RAS atributu a pak 2x CAS pro pixelbyte a attrbyte. Totodelal dvakrat za sebou, a pak dovolila procesoru na 2 takty cokoliv (tj. procesor pristupujici do vram po dobu jejiho vycitani dostaval rpideleny 2T sloty kazdych 8T pro zahajeni strojoveho cyklu).
Ze ma byt cyklus blokovan se detekovalo podle A15:14=01. Tj. pristup do VRAm byl zastaven jeste nez procesor zaktivoval /MREQ, a /MREQ ula pouzivala primo jako /OE svych prelacovacich budicu proti odporum z multiplexu DRAM.
Biohuzel, automat pro detekci zacatku a konce blokovaneho MCycle potreboval "jiste vedet", ze skoncil - a delal to podle A15:14 != 01. Pokud preruseni ukazovalo do VRAM, toto nenastalo, procesor tedy nebyl pri pristim pristupu zastaveny (ULA si myslela, ze stale stoji), a svym zaktrivovanym /MREQ odbudil ULA. Ta tedy nacetla nahodny byte odjinud - a vzniklo no nedeterministicke prseni v obraze.
Jinak Mistrum != didaktik M. didaktik M pouziva wait-state ULA (krokuje pomoci /WAIT, deaktivovanym jednou za 4T, ne blokovanim hodin, tj. kazdy mcycle trva N*4T). ULA pochazi zrejme z ruskeho klonu Hobbit. Mistrum pouzival stinovou VRAM...
Z. -
anonymníchci podekovat za super clanky at uz o historii grafickych karet nebo fraktalech a ted spritech je to jeden z mala autoru kvuli kteremu se da jeste root cist a clanky jsou plne informaci ne jen flame blbosti .
PS. A kdo rika , ze bylo neco lepsiho jak Atari 800XL tak lze ! :-)) tsss nejake c64 ci spectrum :P
diky -
Pavel Tisnovsky (neregistrovaný)To musim uznat, kazetak na Atarku byl des a hruza. Americani si vylozene nedokazali predstavit, ze ve vychodni Evrope bude spousta Ataristu, kteri nebudou mit ani cartridge ani disketovou jednotku :-)
Ten kazetak byl z jejich pohledu asi takova ulitba pro potreby porovnani s dalsimi osmibity - proste se v recenzich psalo "Atari podporuje i kazetak" a basta. Protoze to bylo odflakly jak po HW strance (kazetak byl jedine neinteligentni zarizeni na jinak genialni sbernici SIO), tak i softwarove (600 baudu, bloky, neexistence hlavicek). Zlate Turbo 2000. -
potwor (neregistrovaný)hehe, at tak nebo tak, atari/c= a skoro (skoro) i amiga byli pocitace delany na hry - a vyrostlo u nich spousta hracu her - kdezto zminene speccy vychovalo spoustu programatoru a hw-guru (viz treba i rusky boom v 90tych letech, kdy vysokoskolaci nahradili dreveny klavesnice klonama zx ;-)), to je nesporny fakt - v situaci kde sou k dispozici omezena reseni je potreba vymejslet novy postupy :-)
zdravim vsechny prerostle hrace :-)) -
Pavel Tisnovsky (neregistrovaný)no, na Atarku se taky dalo naucit programovat a to IMHO docela dobre:
1) Atari Basic, Turbo Basic, Microsoft Basic (pro zacatek)
2) Atari Logo, LISP (co vic si prat)
3) Deep Blue C, Action! (dobry zacatek pro vsechny, kdo potom presli na unixy ci DOS)
4) FigForth (mam pro tento jazyk slabost)
5) Atari Macro Assembler, MAC/65, Atari Assembler/Editor + asi 1000 dalsich assembleru a debuggeru
6) i nejaky ten Placal by se nasel, ale nikdy jsem necitil potrebu ho vlastnit
+ "office" programy:
1) Mikronotes (dodnes v nem mam databazi knizek - teda vytistenou, originalni podoba je kdesi na kazete)
2) SpeedScript (editor), Cheops Writer (srovnatelne s T602, ma i menu!)
3) VisiCalc (spreadsheet svetove urovne)
nakonec jsem skoncil tak, ze se u nas Atarko pouzivalo z 30% na hry, z 40% na programovani a zbytek "office" veci
Ale ten vas pohled plne chapu, i dneska je IHMO dobre zacinat na stroji, ve kterem je vsechno pruzracne jasne a prehledne. To vsak dnesni systemy nejsou. -
anonymníNo, já nevim... Ta gumová klávesnice vyloženě sváděla k programování... ;-)
A pokud jde o programování na C64 - 6502kovej Assembler si pamatuju dodnes, včetně nejčastějších opkódů. V počítačovém kroužku jsme měli PMD-85 (jako mučící nástroj na prsty bezvadná věc) a pak Didaktiky Gama, takže můžu porovnávat, ale ta C64 mi připadala prostě příjemnější po všech stránkách, když člověk nechtěl dělat zrovna v BASICu - ale taky co chcete na osmibitech dělat v BASICu. -
potwor (neregistrovaný)Jer fakt, ze "Minigraf Aritma" byl nejrozsirenejsi (a asi i nejhlasitesi :-D) ploter (pak jeste byly dalsi verze, jedna z nich snad i barevna) u nas, pripojoval se k pdm, zx,atari, sharpu. K posledne jmenovanemu sharpu byl take pekny mini-ploter - sirka papiru cca asi jako zx printer :-)
mno a nesmim zapomenout na "Alfi" - genialni prace jednoho inzenyra, co z merkuru vyrobil stavebnici ploteru, i ten byl pripojovan (nejen) k atari (hlavne k zx, "jak jinak" ;-)) -
anonymníTa cihlová zeď mi připomněla tohle zajímavé video:
http://youtube.com/watch?v=kyzStoxnTKs -
tisnik (neregistrovaný)dobry, taky bych si zahral v roli pixelu :-)
trosku podobny je "real" PacMan (http://www.newscientist.com/article/dn6689-human-pacman-hits-real-city-streets.html) -
cubic (neregistrovaný)http://www.blinkenlights.de/interactive.en.html
uz je to hodne davne co jsem k tomu videl i nejake video, treba na tech strankach je nekde zahrabany -
Pavel Tisnovsky (neregistrovaný)nahodou vim, ale taky jsem si dlouho nemohl vzpomenout - Amaurote, viz predchozi cast tohoto serialu nebo Wikipedia
http://www.root.cz/clanky/pixel-art-aneb-umeni-prace-s-body/ a http://en.wikipedia.org/wiki/Amaurote -
Pavel Tisnovsky (neregistrovaný)no, dlouho jsem si nemohl vzpomenout na spravny nazev a dokonce i v emulatoru mam snapshot pojmenovany spatne. Takze, alespon podle Wikipedie, to neni ani Amaouroute ani Amaroute, ale Amaurote :-)))
Jeste si to pro jistotu spustim v emulatoru a poreferuji, co se zobrazuje na uvodni obrazovce :-) -
Jirka (neregistrovaný)Jak byla myslena ta poznamka s nemoznosti zmenit jas sede u Spectra? Co si pamatuju, tak tam bylo pro kazdy ctverecek 8x8 bodu moznost priradit dve barvy, INK a PAPER, a celemu ctverecku nastavit normalni nebo vyssi jas (BRIGHT ve spectracke hantyrce). Barvy byly: BLACK, BLUE, RED, MAGENTA, GREEN, CYAN, YELLOW a WHITE. Dalo by se tedy i rict, ze tedy bylo dvanact barev (modra, cervena, fialova, zelena, svetle modra a zluta, kazda ve dvou odstinech) a pak cerna a bila a dve stupne sedi. Kazdopadne moznych kombinaci v ramci ctverecku bylo pomerne malo.
Mozna by nebylo taky od veci zminit moznost prepinani pametovych bank s dvema ruznymi videoram, diky cemuz slo na pokrocilejsich klonech puvodniho Spectra tvorit obrazky s vice barvami. A dalsi zajimavosti bylo kresleni do BORDERu. Dalsi podivnosti byla organizace videoram, radky nesly za sebou, ale ve trech blocich a v nich navic prokladane. Atributy (tedy ty barvy a jasy) pak uz sly normalne za sebou po radcich. No a konecne by asi za zminku stala poznamka o dvou v zadratovanem BASICu pouzitych souradnicovych systemu (pro body nula vlevo dole a pro atributy vlevo nahore). Sice se to netyka primo pixelartu, ale je to zajimave. -
Pavel Tisnovsky (neregistrovaný)Barvova paleta Spektra je jasna, ale mel jsem na mysli to, ze se nedalo prepnout do ciste grayscale rezimu. Napriklad na Atarku to mozne bylo - misto barvovych odstinu se pouzivaly pouze stupne sede (16 stupnu sedi). Kdyby speccy melo prepinani barvy-stupne sedi (elektronicky je to docela jednoduche, proste se meni pouze signal Y a ne rozdilove signaly), tak by bylo mozne treba i zobrazovat pekne fotky. Ostatne v demoscene ZX Spectra jsem videl spoustu dem pripravenych prave pro grayscale s nejakou jednoduchou HW upravou (nebo v jednodussich pripadech staci stahnout barevny kontrast na TV :-).
Pokud se dobre pamatuju, tak byla pouze cerna, bila a jedna seda, ta druha nesla nastavit (15 kombinaci misto sestnacti, je to divne, ale tak ULA pracovala). Je to dobre videt tady http://en.wikipedia.org/wiki/ZX_Spectrum_graphic_modes, proste cerna je porad cerna bez ohledu na BRIGHT.
To prokladani video RAM je dobre patrne pri nacitani uvodnich obrazku do her, diky za pripomenuti. -
Cygnus (neregistrovaný)Kdyby jen fotky, v sobotu jsem viděl na ZX Spectru docela pěkné video :-) Kdo tam byl, tak ví. Pravda, je k tomu potřeba ZX Spectrum 128k s DataGearem (DMA) a DivIDE (IDE s CompactFlash). Ale co by spectrista neudělal pro přehrávání 50Hz fullscreen videa v barvách a s trochou toho času na zvuk (zatím jen plánováno), že ano? Pravda, změnu barevné palety do odstínů šedi by to fakt chtělo. Btw. ZX 128 nemá YUV, ale RGB. YUV výstupy mají 16kB a 48kB verze, Didaktik Gama a všechny další klony se 48k ULA. Ostatně pomalou animaci lze přehrávat i z diskety, ale není to ono http://cygnus.speccy.cz/popis_vpl2.php.
Mimochodem, tady je malá galerie obrázků ze ZX Spectra s DMA čipem. V podstatě klasický multikolor, ale barvy se přepínají každé 4 pixely. http://velesoft.speccy.cz/data-gear.htm Pokud vím, tak kromě úplné náhrady grafického čipu neexistuje na ZX Spectrum lepší způsob jak eliminovat problém se čtvercovatostí barev na 8x8 pixelů. Ale to už není o pixel artu, spíš o překonání hardwarového omezení, protože obrázky jsou většinou konvertované. -
Cygnus (neregistrovaný)Ještě doplním, oblíbeným trikem je rychlé přepínání videoram v ZX 128k, dosáhne se tím efektu sloučení dvou obrazů do jednoho. Sice to pekelně bliká (25Hz), ale funguje to, některé hry to používají k zobrazení menu přes obrázek a pod... s mým malým LCD monitorem blikání prakticky nevadí, ale s CRT monitorem, nebo v emulátorech to je dost nepříjemné.
Ovšem při použití ditheringu v kombinaci s vhodnými barvami lze dosáhnout jakéhosi rozšíření barevné palety, jsou dema, kde blikání není téměř znát ani na CRT monitorech a barvy tím lze rozšířit v krajním případě asi na 60. Nicméně jen několik jich je opravdu hezky a bezproblémově použitelných. Typicky v jedné obrazovce zelená a v druhé azurová míchané v překrývající se pixelové šachovnici ... chce to vyzkoušet :-) Na ruských Pentagonech tomu říkají gigascreen ... nejsem si jistý, ale myslím, že přepínání VRAM realizuje hardwarová úprava jejich kopie graf. čipu ULA a to tak, že přepíná po mikrořádcích místo úplně celé VRAM naráz, jako to umí tovární ZX 128k. -
Pavel Tisnovsky (neregistrovaný)Podobne se to resi v novejsich demech na Atarku - myslim to problikavani dvou obrazku pres sebe. Jediny problem je v tom, ze je to koukatelne pouze na originalnim Atarku, protoze v emulatoru obnovovaci frekvence originalniho obrazu (50/60 Hz) koliduje s obnovovaci frekvenci "hostujiciho" pocitace a vysledek je vetsinou nekoukatelny kvuli "zaznejim".
Mimochodem mam dojem, ze takto byla resena hneda barva uz u starickeho Jet Set Willyho ne? Ale nejsem spectrista, mozna si to s necim pletu. -
Jirka (neregistrovaný)Uz si nepamatuju, jak to s tou cernou bylo, ale na tom obrazku z Wikipedie rozdil vidim. Mozna mam jenom oci jako osm sokolu, nevim.
Jinak ja mel doma nejprve velkou CB televizi Tesla Neptun. Pozdeji jsem to obcas pripojil k barevne televizi, ale tam jsem se setkal s problemem (ktery byl castecne viditelny i na tom Neptunu) - jakmile se nekde pravidelne stridaly pixely dvou barev, pres takto "obarvenou" plochu litaly sikme pruhy z tech dvou barev. Dost to otravovalo a nevedel jsem, jak se toho zbavit. Mozna to bylo tim, ze jsem to provozoval klon ze Skalice, nikoli original Spectrum.
Asi by za zminku stala jeste pseudografika, slozena ze ctverecku 4x4 pixelu, ktere se vkládaly vlastně jako zvláštní pseudograficke znaky. -
Pavel Tisnovsky (neregistrovaný)To je pouze zrakovy klam :-) Doopravdy, kdyby pod temi cernymi pruhy nebyla ty dva modre pruhy, neuvidite rozdil. Schvalne jsem si ten obrazek stahnul a otevrel v prohlizeci obrazku (IrfanView). Celkovy pocet barev=15, po najeti "pipetou" na cerny pruh je to porad #000000.
To stridani barev a poblikavani nastalo v pripade, kdyz se zobrazila sachovnice? Spektralni sirka televize by afaik mela na prenos barev ze Spectra (256 pixelu na sirku+nejaky border) stacit (problemy mela treba Amiga ve vyssich rozlisenich), jestli nahodou neslo o problem PAL/SECAM?
Jeste me napada, ze na starsich televizich se dal doladit color burst (nove televize to delaji automaticky), vetsinou stacilo snizit barevny kontrast (stejny problem mela Color Oravan, kdyz se barvy "presmahly"). -
Jirka (neregistrovaný)Vida, i osm sokolu se da omamit pozlatkem.
Jojo, pri sachovnicich. Nebylo to ale poblikavani, spis opravdu pruhy celkem pomalu se posouvajici tam a pak zase treba zpet (tak, jak to popisuje prispevek od jakeho si C++ gurua o neco niz). Dalo se to videt i na CB televizi, jenze tam to vetsinou nebyl moc velky problem, nebot pruhy byly jasove podobne, a tak to tolik nerusilo. -
Guru C++ (neregistrovaný)sikme zabarvene pruhy vznikaly interferenci 4.43 MHz barvoniosne s 7MHz, generujicimi pixelclock (ULA internals). podle teploty a plavani frekvence obou krystalu pruhy bud jezdily sem-tam, nebo i castecne mizely, pokud se ve snimcich jdoucich po sobe fazove vyrusily.
to je mimochodem i duvod, proc maji 128k stroje a novejsi modely jiz jen jeden jediny krystal na vsechno (a proc jejich mikroradek netrva 64ys, ale vice, a proc maji 228T/line ane 224, a maji jen 311 radku, a ne 312).
detailne http://85.132.166.194:21002/~zilog/Miscellaneous/Timing/timing.gif :)).
Z. -
Cygnus (neregistrovaný)Druhý důvod bordelu v obraze je přimíchaný zvuk, který se přimíchává do kompozitního signálu, aby následně mohl být modulován a TV připojená přes anténu zobrazovala i hrála ...
Stačí uštípnout nožičku jednoho 20pF kondenzátoru a obraz se radikálně zlepší, zmizí asi 3/4 popisovaného bordelu, mihotajicích se barev atd... To co zůstane je prostě vlastnost PAL kompozitního signálu. U některých typů to lze zlepšit oddělením jasové a barvové složky a z kompozitního PALu udělat S-Video nebo ještě lépe (u 128kB modelů) využít rovnou RGB. RGB tohle rušení prakticky neobsahuje (není znatelné), ale chce to monitor/TV s RGB vstupy, které se bohužel nevyskytují moc často. Určitou nadějí jsou LCD TV monitory se Scart konektorem a komponentními vstupy.
... AD 311 řádků ... jestli on to není důvod, proč můj TV -> VGA tuner neobnovuje se ZX 128k obraz a se ZX 48k funguje perfektně. Už jsem změřil i trvání snímkového pulzu, zkusil jsem ho posílit, utlumit, separovat ... :-) V nějlepším případě se obraz nezasynchronizuje, pomalu se posouvá vzhůru, ale obnovuje se. Jakmile se zastaví = tuner reaguje na synchro pulz, tak se obnovovat přestane. -
Pavel Tisnovsky (neregistrovaný)to by se imho dalo zmerit - jeden chybejici skenovaci radek dela pri 50 Hz 50 radku za sekundu, to je pri cca 300 radcich o neco vic nez 6 sekund na to, aby se cely snimek "orotoval".
Ale Speccy prece generuje synchro pulzy a VGA ma prislusny vstup (tusim invertovany), takze by se i normalni multisync VGA monitor (dneska kazdy sunt za 2000,-) mel zasynchronizovat. Nebo vy vytvarite VGA signal az z TV vystupu? my jsme na monitoru zobrazovali i primitivni vystup z CCD cipu, samozrejme trosku "opatchovany", resp. s primichanymi synchro pulsy. -
Zilog (neregistrovaný)On ten snimek nerotuje.
Original 48k byl cisty design - 7MHz pixelclock, 448T na mikroradek (tj. 64ys), 312 radku, tj. 50.08Hz vertikal.
Jenze, ty dva nestastne krystaly - 14MHz do oscilatoru v ULA, a druhy, 4.43MHz, primo u LM1889, delajici ony barevne rozpruhovane interference.
Proto jeste Sinclair u 128k frekvence posunul, aby byly odvoditelne z jedne jedine - ctyrnasobku PAL barvonosne, tj. 17.72MHz. Procesor pouziva petinu, tj. 3.544MHz, AY desetinu.
Takze procesor se nepatrne zrychlil, a radek by trval nepripustnych 63.2ys, coz dekoder BTV nezkousne ani u PALu (u Secamu by to byl duhovity paintrbrush, a ne obraz), trpely by horizontalni hrany. Proto do ULA pridali pro horizontalni vycitani jeste 4T navic, cimz to zase ale o neco presvihli, a radek trval 64.3ys. Jenze, Spectrum pouziva 50Hz vertikalni interrupt jako jediny zdroj externi casove zakladny, tj. je zahodno, aby to bylo skutecne 50Hz, a ne 49.neco, jako by tomu bylo pro 312 radku. Proto jeden ubrali.
Btw. ruska ULA-1 se timto vubec neobtezovala, radku ma 314, a frekvenci 49.7Hz - zrejme podle poucky "relevizor Rubin se syncne i na 60Hz NTSC" (jako ze jo :). -
Pavel Tisnovsky (neregistrovaný)Hmm, to je problem. meli od zacatku mit krystal oscilujici na celem nasobku delky trvani mikroradku a bylo by. Stejne se pocitalo jen s PAL, tak by nebyl vetsi problem.
U Atarka to bylo trosku horsi, tam potrebovali podporovat jak NTSC tak i PAL verzi. Vyresilo se to pouzitim jineho krystalu, takze PALovska Atarka jsou o neco pomalejsi nez NTSC (1,77 MHz, 1,79 MHz). Na obou platformach byl trosku problem s overscanem, takze se nakonec z 312,5 radku zobrazuje pouze 262, z toho 192 standardne (dalsi jdou pridat, ale nekdy se uz rozjede sync).
Jinak to po odecteni synchronizacnich casu vydeleni rozlisenim vychazelo krasne: v nejvyssim grafickem rezimu se za jeden takt musi vykreslit vzdy dva pixely (tam se ovsem nestiha prenaset barvonosny signal, proto je tento rezim monochrom) a v rezimech 160xneco se za jeden takt vykresli vzdy jeden pixel.
Ten horizontalni sync musel byt opravdu tak presnej? Protoze mam dojem, ze ani Atarko nemelo presne 64us -
anonymníOn je problem s frekvencemi. napr. spolecny nasobek 3.5 Mhz a 4.43Mhz se hleda spatne, a pokud se najde, tak je takovy krystal nestandardni. Navic, pocinaje zhruba 20MHz, uz se i spatne rozkmitava, a ma neprijemne elektricomechanicke vlastnosti a zavislosti. A tehdy se na fazove zavesy pro nasobeni kmitoctu jeste moc nehralo.
U televizni normy je 64ys v podsate nejsvatejsi cislo, protoze barevne systemy SECAM i PAL zpozduji o 1 radek signal, a kombinovanim minuleho radku s aktualnim pomahaji synchrodekoderu. A to zpozdeji je delane na 64ys. Pokud by radek trval o neco jinak, bude dekodovani barev o tenhle rozdil posunuty. Tj. kdo ma 64.2 misto 64, bude mit proste jednopixelove barevne tecky spatne obarvene, a s duchem. Proto chceme co mozna nejpresnejsich 64ys.
Naproti tomu vertikala je kazdemu putna, kdyby z ni zx neodvozovalo 50hz inty a nemerilo tim cas, ani by se s temi 311 nenamahali.
Btw. 8bity neprokladasji, tj. nemaji 25 snimku z dvou pulsnimku, ale 50 sobenaprosto podobnych snimku - tj. uz tim trosku znasilnuji tv normu :). -
Pavel Tisnovsky (neregistrovaný)Jasne, ale proc vlastne hledat nasobek techto frekvenci? Kdyz si za zaklad vezmeme pixel clock tak nam po roznasobeni vyjde nejaka frekvence (dejme tomu 2*1,77 MHz, 3*1,77 MHz), na ktere snad Z80 dokaze pracovat ne? Z80 nemel dynamicke registry, takze ten rozsah pracovnich frekvenci mohl byt dost velky.
-
Zilog (neregistrovaný)spis barvonosnou jako zaklad pixelclocku - ta je 4.43MHz. Procesor nemusi mit s pixelclockem nic spolecneho, pokud ULA spravne ohlida jeho pristup do videoram.
Ten problem je jak svazat PAL barvonosnou s pixelclockem, aby pattern 1010101010 nerusil barevnost (primy pomer, maly spolecny nasobek), nebo nevyvolaval zaznejove pruhy (velky spolecny nasobek).
Z80 skutecne nemel dynamicke registry, takze sel provozovat napr. na 1Hz (a pri uzemnene datove sbernici bylo krasne videt, jak adresa cita NOPy, a jak pracuje IR pair v dobe refreshe :). -
Cygnus (neregistrovaný)Speccy VGA výstup nemá a pokud vím, tak zatím neexistuje ani specielní zařízení, které by to uspokojivě řešilo. Ale když už jsem to nakop, tak vysvětlím oč jde.
Mám TV Box Media Tech MT4154, je to externí tuner s kompozitním, S-Video a anténním vstupem. A doufal jsem, že ho použiju s ZX 128k +2 u které mám 5,5" LCD monitor připojený přes RGB. Obraz hezký, ale moc malý.
Tuner s ZX 128k +2 nefunguje a nevím proč.
Vyzkoušel jsem ho se ZX Spectrum 48k (gumákem i pluskem), s Didaktikem Gama 80k (všechny stroje mají stejnou ULA a stejné časování signálu), dále s Atari 800XE a SamCoupe ... (ještě mám hafo osmibitů v zásobě). Tuner fungoval se vším perfektně kromě té +2 a tak pátrám proč vlastně nefunguje. Obraz zobrazí, ale neobnovuje ho, takže obraz trvale zůstane takový jaký byl při připojení kabelu včetně náhodného rozhození ... jsem si jistý, že řádková synchronizace funguje správně.
Dokonce jsem ho rozebral a zkoumal osciloskopem rozdíly, ale nepřišel jsem na nic neobvyklého, ani v datasheetu k čipu atd...
O něco později jsem se doslechl, že někomu dělá stejné problémy nějaká LCD TV, takže možná stejný čip ...
No a když jsem si všiml, že řádků je méně než 312, tak mne napadlo jestli to není příčina, ale jinde se tu zas spekulovalo o Atari, které má TV řádků ještě míň ... což by tuto příčinu vylučovalo.
Budu rád za případnou nápovědu, nicméně zas tak moc mne to nepálí.
Krom toho jsem kdysi zkoušel připojit signály RGB přímo k VGA monitoru a dosáhl jsem nezasynchronizovaného obrazu, možná to někdy zkusím zas, separovat synchro už umím. Jenže 50Hz je na VGA monitor dost málo. -
Pavel Tisnovsky (neregistrovaný)S tim Atarkem vam muzu trosku poradit. NTSC verze Atarka generuje 262 radku, zatimco PAL verze (tu velmi pravdepodobne mate) generuje celych 312 radku. Ovsem "diky" tomu, ze ne vsechny radky jsou videt a soucasne se mohou nektere televize dostat out-of-sync, tak i v PAL verzi dostanete ne-cerny video signal pro 262 radku. Nektere z nich jsou "zakryty" display listem a potom se dostavame ke znamemu cislu 192 radku zobrazitelnych temer na 100 kdekoli.
Pokud se na signal budete divat osciloskopem, tak byste mel mezi kazdym snimkovym synchronizacnim pulsem objevit 312 radkovych syncu. Atarka mely syncy vyvedene na petikolik vzadu, takze s timto by nemel byt problem (je tam i zvuk, ktery je samozrejme kvalitnejsi nez to, co jde do antenniho vystupu).
Jeste k frekvencim (to bude mozna zajimat pana "Ziloga"): NTSC Atarka mely pouze jeden krystal, PAL verze potom zavesny krystal, ktery jel na frekvenci o 5/4 rychlejsi. Tento krystal se pouzival pouze pri cteni video dat.
Trosku presnejsi udaje jsem nasel ve svem rucne psanem (!) sesite:
NTSC: 262 radku (non interlaced)
jeden pixel v hires rezimu (graphics 8)=1/2 hodinoveho signalu
jeden pixel v graphics 15=1 tik hodin
hires rezim Atarka ma teoreticke maximalni rozliseni 352x240
ovsem skutecne se pouziva 320x192
pro jeden radek: 176 tiku hodin => v hires onech 352 pixelu
celkove je dostupnych 228 tiku hodin na jednu radku (protoze syncy a blanky taky neco zaberou, tak pouze 176 se pouziva pro zobrazovani)
pro PAL je to v podstate to same, az na pocet radku
celkove trva vykresleni obrazovky 16684us, vertikalni zatemneni okolo 1400us, horizontalni zatemneni 14us a cela radka onech "svatych" 64us -
Cygnus (neregistrovaný)Pardon .... to jsem to poplet, takže ještě jednou.
Velký omyl, spousta TV má konektor Scart, ale nejméně 3/4 z nich mají jenom S-Video a kompozitní PAL. Některé mají i YUV vstupy a jen pár výjimek má i RGB. A když už, tak to jsou ty dražší. Scart konektor sice má kontakty na RGB, ale ty nejsou často zapojené. -
Pavel Tisnovsky (neregistrovaný)Proc to vlastne takto ULA delala? Z cerne na sedou prepnutim BRIGHT je to logicke, proto bych cekal, ze opak bile bude nejaka "tmavsi seda" (reset BRIGHT), podobne jako je tomu napriklad v zakladni palete VGA. Se ctyrmi stupni sede: cerna-tmave seda-svetle seda-bila uz by se dalo delat vic veci, nez primichavat dalsi barvy.
-
Zilog (neregistrovaný)ULA generuje barvy klasicky jako tvrde syte RGB, a non-brightem jen srazi intenzity slozek na 66% (didiaktik m na 50%). Stare ULA to delaly interne, jeste pred YUV maticovanim, novejsi RGB-uly z 128K pak externe, az na konci retezce (primo zatezovanim slozek dodatecnymi 75 Ohm :).
Jo a protoze cerna zadne aktivni slozky nema, nemuze byt ztmavena, a zustava cernou - proto nema cerna bright.
Ale existuje jev dvou halftone-sedych (sachovnice) - dela to setrvacnost pixeloveho multiplexoru v ULA, ktery o chlup svizneji prechazi z PAPER na INK, nez z INK na PAPER - takze v sachovnici zabiraji inkove pixely vetsi plochu, a tak je p0i7 svetlejsi nez p7i0 :>.
Jo, tehdy jeste davaly pocitace i HW smysl, a melo i smysl se v tom vrtat. Dnes jakoukoli kreativitu ubily tuny lamerskeho bloatu :(. -
Zilog (neregistrovaný)http://members.lycos.co.uk/eightbitula/128kinfo.html
na schematu uplne vpravo :). niormalne to bylo 75:75 z TTl, tj. pulka. pri nebrightu se to stahlo na 75:(75|75), tj. tretina. Suma sumarum 66% :).
Diody a rezistory, to jest to. Jinak jeste hezci je, jak mela Amiga500/500+/600 reseny "DAC" prevodniky - tj. z 4bit TTL nibblu na analogovou hodnotu - tam byla naprosto trivialni proudova sumacni odporova sit :).
Kdyz clovek vidi tahle vycurana technicka reseni, je to parada a blaho. narozdil od konzumnich manazerkych pindu na to, jak je vyrobek progresivni, inovativni a super-duper, ovsem pod podminkou koupe... -
Pavel Tisnovsky (neregistrovaný)Myslite to analogove schema (analogue schematic diagram), kdyz je BRIGHT=0, tak se ty signaly pres diody stahuji smerem k nule? Rozumim, jednoduche a funkcni. Porad mam dojem, ze speccy (mozna i ZX-81 nebo Apple II, protoze Wozniak je opravdu frajer - viz jeho disketova jednotka) je i dnes idealni stroj pro vyuku HW & spol. Ceske pocitace byly sice jeste primitivnejsi (ty nekonecne rady integracu s malou hustotou v IQcku jsou nezapomenutelne), ale ZX je takove dobre vyvazene. Atarko o komous uz jsou slozitejsi na pochopeni - programovani VIC ci Anticu a GTIA atd.
DAC jsem taky resil podobnym zpusobem pri vyrobe COVOXu - 8 stejnych odporu+jeden, spolecny na kterem se vytvarel napetovy potencial pro zesak. Melo to samozrejme silene zasumeni, na me 286 bylo jasne slyset, jak se roztaci disk :-)
To byly casy... Dneska je clovek rad, kdyz ma v pocitaci aspon seriovou linku na ovladani svych udelatek, kdyz uz paralelka je veci minulosti (skoda, vetsinou byly ty vystupni hradla u paralelky tak silny, ze rozsvitily diodu, takze zadne TTL, jak se povidalo - poctivy CMOS :-) -
Roman (neregistrovaný)Ono ziadne ukazky z C64 som tam velmi nevidel takze zopar cerstvych kuskov 2006/2007 od autora Mirage/Focus (Lars Verhoeff): (16 farieb)
http://noname.c64.org/csdb/gfx/releases/53000/53729.png
ttp://noname.c64.org/csdb/gfx/releases/43000/43065.gif
http://noname.c64.org/csdb/gfx/releases/41000/41581.gif
http://noname.c64.org/csdb/gfx/releases/41000/41469.png
http://noname.c64.org/csdb/gfx/releases/40000/40585.gif
http://noname.c64.org/csdb/gfx/releases/40000/40476.gif
http://noname.c64.org/csdb/gfx/releases/39000/39953.gif
a este jedna pomerne znama vec (z wikipedie) od Ptoing(a) (Sven Ruthner)
http://noname.c64.org/csdb/gfx/releases/23000/23596.png
waťch and learň guys ;-)) -
Roman (neregistrovaný)Myslim ze ten Yus Bird je multicolor (je to sirsie) tie Mirageove veci budu mozno FLI on ma vlastny editor na pc (Timanthes) tak sa mu to tam dobre robi. Keby bolo treba mozem vybrat len ciste multicolory alebo hires, chcel som hlavne ukazat ukazky sucasneho Pixel Artu aj na C64 (lebo akosi su tu len same atarka a speccy ;-) Mimochodom Forever 2008 crossplatform computer party (Speccy/Atari/C64), 14-16 Marec 2008 , Trencin, Slovakia. ;-) Vsetkych srdecne pozyvam (web je v priprave na http://forever.zeroteam.sk )
-
Pavel Tisnovsky (neregistrovaný)To je naprosto v poradku, ze jste ty obrazky poslal :-) neco jsem hledal prave na strankach Forever (starsi rocniky, jednou jsem se taky dokopal jednim 128b intrem prispet), ale nakonec nic neprobublalo az do clanku, takze je dobre, ze se ozval nekdo, kdo se C64 scenou aktivne zabyva. Pokud se daji napr. obrazky z www.c64.cz do clanku pouzit (zadne (c) jsem nenasel), budete je mit v dalsim dile.
