Diky za clanek …
Spise pro pametniky, ne ze by na tom dneska uz nejak zalezelo, ale nazvy tech her si fakt nepametuji, treba nekdo pomuze…
1. Kocka, ktera na uvodni obrz. behala po zemi a delala cerne tapoti,pak skakala po sudech a z nich na jedouci snury s pradlem a okna, kde byly mysi,kdyz je chytla tak se dostala jinak, treba do obriho ementalu nebo akvarka.
2. Upir, takova „plosinovka“, byl jste upir a musel jste vysavat z lidi krev, aby jste prezil, umel se zmenit ve vlkodlaka nebo netopira a pak litat. Bylo to dost zmatene, chodilo se do baraku, sbiralo klice atd…
3. „Hrobarik“, takovy maly hrdina v brneni, ktery umel strilet ruzne veci mece, diky, sekery…, bojoval proti zombii, plosinovka.
To první je odkázáno zde: http://www.dosgamesarchive.com/…d/alley-cat/, to ostatní nevím.
Jojo Alley cat, to byla parba.
Kdyz sme u tech plosinovek, tak jsem si vzpomel na Commander keen. Kdopak z vas dohral vsech (tusim) 7 dilu? Jesli ne, tak se o to muzete pokusit… http://www.commander-keen.com/ :D
ten upir jen nejspise Blood Omen: Legacy of Kain
http://www.mobygames.com/…gacy-of-kain
AlleyCat – kočka na sudech :-)
Běhala spolehlivě na 286 a pak už obtížně.
Ale DNES jí mám ve sbírce a pod DOSBOXem jede i v XP spolehlivě…
To mi připomíná první firemní školení na PC AT (286):
Spustit Nortona, pochopit strukturu adresářů (dnes složek) a přípony souborů. A to byla celá věda.
Když to uživatel pochopil, byl schopen už druhou hodinu sám nalistovat PRINCE.EXE a s parametrem MEGAHIT (pokud mu ho někdo poradil) přeskočit kola, která nezvládal…
Díky za pěkný článek – vlastně zatím za všechny v této sekci.
q.
Organizace po bitových rovinách mě v té době jako teenagera zaskočila… (píšu v té době, ale nesmíme zapomenout, že k nám se grafické adaptery EGA/VGA dostali až po roce 1989 a já osobně jsem začínal z 386DX, kde už byla paradajska, která uměla i 256 barev). Bylo to první setkání s I/O mapovanými do paměti, kdy najednou paměť se nechovala tak jak by se chovat měla, tedy co do ní uložím, to z ní vytáhnu.
Do paměti bitových rovin se dalo zapisovat různě, jsou tam tři zápisové a dva čtecí řežimy. Zapisovat lze buď tak, že zapisuju bitovou masku bodů, které se mají nastavit na předem určenou barvu, nebo že nejprve vyberu body, které se mají nastavit a pak zapíšu barvu do paměti.
Důležité pro programování je nutnost vědět, že existují Latch-registry, ty se plní vždy čtecí operací procesoru. Je v danou chvíli jedno, co se přečte, důležitá je adresa čtení, která způsobí naplnění registrů. Při zápisu se pak podle zvolené operace provede zkombinování zapsaného bajtu s latch-registry a přepsání registrů zpět do videopaměti.
Problém v pomalosti je zejména v pomalých I/O operací. Nevím proč, ale i dodnes se mi I/O operace jeví vždy pomalejší, než mapovat framebuffer do paměti. Pokud jsem někde generoval obrázek do back-bufferu, vykresloval jsem jej na obrazovku pomocí čtyř blokových operací, pro každou bitovou rovinu jeden. Ale bohužel to blikání bylo dost vidět i na rychlých PCI kartách. TurboPascalovská funkce putImage (tuším) ukládala obrázek po řádkách, vždy 4 bitové roviny na jeden řádek. Zobrazení pak probíhalo tak, že se blokově přenesl čtyřikrát 1 řádek, a pak 4× druhý, atd…
Další nevýhodou pro zápis je nemožnost použít 16bitových a 32bitových přesunů. Jak už bylo řečeno, latch registry se musí před zápisem přečíst, což vyřazuje ze hry blokové operace pomocí MOVSB. Pro zápis jsem používal ALU operaci OR, případně XCHG, obě nejprve operandy přečtou a pak zapíší. U OR se přitom musel nastavit takový čtecí režim, na který adapter odpověděl za všech okolností nulou. XCHG je obecně pomalejší, protože od 386 drží procesor během XCHG příznak LOCK a navíc je to serializační operace (tuším).
Zápisový režim 1 (blokové přesuny) byl dobrý možná pro ukládání pozadí (podklady oken) ve videopaměti, pokud jí bylo dost. (v režimu EGA 256kB byla k dispozici celá jedna stránka). Nevýhodou tohoto režimu je opět nemožnost použít 16-bitové přesuny, protože latch registry se prostě načtou a zapíši. Pokud by se provedlo dvakrát čtení a dvakrát zápis, byl by výsledek jiný (nepoužitelný). Mimochodem od 386 byly 32-bitové blokové operace rychlejší, než adekvátní přesun dat po osmi bitech přes latch registry, ale nebylo je možné prostě použít.
Ještě k tomu zapisování po bitových rovinách. Pokud se dostaneme k VGA a XMODE, tak třeba zajímavý postřeh, pokud jste někdo hrál DOOMa, v těch první verzích. XMODE obsahoval 4 stránky a bitové roviny byly mapovány vedle sebe, tedy na jedné adrese leželi čtyři body vedle sebe. DOOM generoval obraz po sloupcích algoritmem ray-casting. Vždy nastavil pomocí adapteru bitovou rovinu (pozn, naprosto stejným způsobem jako na EGA/VGA) a vygeneroval celý sloupec. V režimu LOWres přitom zapisoval do dvou bitových rovin naráz a generoval obraz s polovičním horizontálním rozlišením. Geniální využití šíleně navrženého systému vedlo k rozmachu 3D, byť se velice záhy začaly používat akcelerátory. Tento způsob však byl podkladem pro vznik poptávku po takovýchto hrách.
No nostalgia pochytila aj mna. Spominam ako som jeden z prvych na slovensku vytvoril prvy 256-farebny VGA driver pouzitelny pre TurboPascal – ono to trochu trvalo kym ich vychyrene 256 farebne BGI doslo az do nasich koncin (roky 88–98).
Neda mi spomenut, na ten cas slusnu knihu, z ktorej sa dalo vela priucit:
Ferraro: Programmer's Guide To Ega & Vga Cards.
Blikanie – to si niekto nedaval pozor na synchronizaciu, ze ano. Zapisovat sa nemalo kedykolvek a akokolvek. Bol tam register, ktory obsahoval informaciu o synchronizacnych impulzoch. Na druhej strane sa dala vyuzivat podpora dvoch stranok, pricom iba z jednej sa vykresloval obraz; aj samotny TurboPascal to podporoval.
To mi pripomelo historku, jak muj sef v prvni praci (nekdy v praveku), resil problem s cestinou na pocitaci jedne kolegyne. Po hodine neuspesneho reseni si ulevil slovy: „Zatracenej Hus, proc ho neupalili driv!?“ Smula byla, ze ta kolegyne byla clenkou Cirkve Husitske, takze dostal facku :-)
Tybrdo to je nostalgie. Pro EGA jsem programoval uz v te dobe par veci v assembleru a ty bitove roviny me stvaly uplne nehorazne. Jsem prvne vubec nevedel jak to funguje dokud jsem si to neprecetl v jedne chytre knizce co vydalo jedno ceske nakladatelstvi. BTW kdyz jsem se tehdy u kamarada sem tam byl mrknout na jeho VGA 320×200×256 barev.. tise jsem zavidel :) se svymi 320×200×16 na me EGA :)
Kdyz je tu tolik pametniku, tak mi snad mozna nekdo potvrdi jestli je tohle opravdu IBM EGA karta nebo ne. Jeden clovicek na netu mi potvrdil ze by to mela byt original IBM s 64kB pameti bez pridavneho modulu s dalsi pameti navic. Takze kdyby to nahodou jeste nekdo pamatoval tak na
http://82.114.193.227/…ni/egafb.jpg
je fotka a kdo neco vycte i z biosu (ja jen datum) tak muze overit i bios
http://82.114.193.227/…atni/ega.zip
Predem diky…
Diky moc za pozitivni identifikaci. Na wiki se sice casto divam, ale nemecka variace mne fakt nenapadla. Ted jeste jestli bude nekdo te dobroty a rekne mi jestli na te karte existuje cip, ktery by se dal oznacit jako hlavni puvodce signalu :) Ramdac od hlavniho cipu jeste na starsich kartach poznam, ale tady co je moc, to je moc.
Díky za článek i za celý seriál. O některých věceh mě poučil, v případě EGA jsem si také zavzpomínal, jak se do ní psalo (v Turbo Pascalu).
Jen jedna připomínka k jazyku: Opakovaně mě „tahá za uši“ bezmyšlenkovité používání spojení „ve své podstatě“. Dnes konkrétně o desce Hercules, o které se praví, že „firma IBM tuto konkurenční kartu ve své podstatě ignorovala.“ V čí podstatě, prosím pěkně?
Tento nešvar se začal rozmáhat před několika lety, a dnes už někteří mluvčí asi ani nevnímají, že mohou říkat nesmysl. Není to tak dávno, co se říkalo jen „v podstatě“ a bylo jasné, co to znamená. Tedy ono je to jasné dodnes, naopak často není jasné, co by měla/mohla znamenat ta „svoje“ podstata. :-)))