Opět kousek historie, kterou jsem měl možnost si osobně vyzkoušet. Vzpomínám i na různé DOSové "VESA rezidenty" suplující ten VBE.
Moje první grafika byla OAK cosi do ISA slotu s 512 kB paměti, když jsem do toho kdysi slavnostně přidal ještě jednou tolik, mohl jsem vykreslit obrázek v 1024×768×256, ale trvalo to dlouho, bylo to viditelně pomalé. I ve Win3.x, když se tomu dal driver, to kreslilo pohyb kurzoru "viditelně", o přesunu a kreslení oken ani nemluvě. Bylo to typické demo typu "jde to, ale dře to, pročež jsem pochopil, proč se tam srandardně dávalo jen 512k (a často jen 256k). Ale možnost dát tam 1M byla.
Na 2/386 sme si nekdy v roce 92 (+-) hrali s 3D animacema. Samozrejme ze pokud se to vykreslovalo "SW" cestou, bylo to pomale a videl si jak se to prekresluje. Ale uz od dob 8mibitu existuje figl, ze se to nejdriv vykresli, a pak se prepne pametova banka. Coz je "instantni" vec (stihne se to za 1 refresh zobrazovadla).
Osobne sem si s podobnejma volovinama hral na atarku. Slo udelat zcela plynulou animaci.
Samo to vyzadovalo znat ten HW, a primo do nej zapisovat, zadny ovladace nebo apicka na to nebyly.
Ta defaultni ramka na tech kartach bohate stacila pro rozliseni ktery se pouzivaly i nekolikrat. Dneska ti soudruzi prodaji grafarnu co ma 24GB, gamesa si to klidne zkousne cely (D4 napr) ale videt to nikde neni.
V době, o které je řeč v článku, toho karty zase tak moc neuměly, takže paměť karty k ničemu jinému ani využít nešlo. Ale ono jí ze začátku až takový přebytek nebyl, např. v novém počítači z prosince 1992 jsem měl 1MB, takže rozlišení 1024x768 šlo používat jen v osmitibovém barevném režimu (a tím myslím 8 bitů dohromady, ne 8 na kanál). I později s už o trochu lepší kartou, která měla 2MB, jsem musel snížit rozlišení na 800x600, pokud bych chtěl 24-bitové barvy.
Ses mimo, chybi ti v tom treti cislo. Ono to taky muze byt B&W. A dokonce ani to neni omezeni. Kdyz vemes, ze zobrazovadlo ti davat 50Hz, a budes prepinat jednobarevny obrazky, tak se tobe slozej jako jeden vicebarevnej.
Presne takhle se na tom atarku dalo barevne kreslit pri maximalnim rozliseni. (tzn mimo vsechny standardni rezimy). Standardne byl totiz ten rezim jen monochromatickej.
Double buffering - to je to prepinanie "pamatovych baniek" (teda v mode x len zmena plane, z ktoreho sa zobrazoval buffer) sa ako technika pouziva dodnes. Pouziju sa dva buffre, do jedneho sa kresli, druhy sa zobrazuje, ked dokreslim, prehodim. Napr. vo Vulkane sa to dnes nazyva "swap chain". Gnome je dnes ochotne pouzivat na pomalsom hardveri aj tripple buffer, aby to moc nesklbalo ked sa nestihne dokreslit vcas, ale to samozrejme zvysuje latenciu.
Dalsia optimalizacia bola minimalizovat prenos medzi systemovou ram a videoram, ked isa, ale aj neskor vlb a pci boli uzke miesta, takze vo videoram sa menilo len to, co bolo treba. Kvoli tomu sa sledovali "dirty rectangles" (zmeny voci predoslemu stavu) a kopirovali sa iba tie. Jedna z prvych hw akceleracii bola bitblt (a odvodene stretchblt), ktore prehodili starost o prenos z ram do videoram na grafiku.
Kopírování SystemRAM --> VRAM bylo na prvních PC, jako 286, pomalé. Nicméně techniky byly (viz uvedené dirty rectangles). Známá je v tomto hra Stunt Island, kde autor renderingu drží shadow buffer v SystemRAM a vůči němu porovná pixely v novém obraze v SystemRAM a po sběrnici pošle do VRAM jen ty nutné. Hra tak byla zcela plynulá i na 286. Grafika hry je totiž flat-shaded, jednoduchý stupňovitý gradient na obloze a letadla zabírají jen zlomek pixelů (měla na tu dobu ohromující smooth-shading, plynulé gradienty).
Uvážíme-li, že přenosová rychlost 16bitové ISA sběrnice byla 16 MB za sekundu, jeden snímek zabere 0.75 megabajtu, tak to vychází maximálně na 21 plných snímků za vteřinu, a to je počítané bez jakékoliv režie. Není divu, že se Win 3.X vykreslovala pomalu. Systém neměl na takovou porci obrazových dat dostatečnou propustnost.
Režim 640x480x256 byl na dané sestavě asi mnohem použitelnější.
Taky bych nechtěl vidět ostrost obrazu v 1024x768.
10. 6. 2025, 16:55 editováno autorem komentáře
Ne, nebylo. Na 8mibitech byla cast ramky namapovana na nejaky zobrazovani, a co se do ty casti zapsalo se instantne zobrazilo. Kdyz se objevily extra grafiky se svoji pameti, tak ta byla namapovana do adresniho prostoru, takze se dala primo adresovat, potazmo se dala adresovat neprimo pres nejaky prepinani ruznych bitu ale nikdy se nic nikam nekopirovalo.
To by to totiz vubec nefungovalo.
Taky byla RAMka ku_evsky drahá. A je jedno, jestli ty RAM čipy byly na desce nebo grafické kartě. Double buffering se tak používal jen ve hrách, kde ale i z důvodu rychlosti kreslily v menším rozlišení, než se pracovalo, např. plocha Windows. Kreslení bylo přímý zápis pixelů do VRAM (později ještě akcelerovaných operací, jako blitter).
Už jsem se setkal i s tím, že si někdo myslel, že už Windows 3.x si držel bitmapy otevřených oken. Tehdy byla paměť drahá, ale CPU stačil (protože neběžely operace v pozadí jako dnes, lidi taky byly trpělivější - furt byl vidět rozdíl rychlosti oproti analogovému světu). Takže se jen řeklo oknům při každé příležitosti, aby obsah znovu vykreslily.
Přesně tohle si pamatuji z jednoho ze svých několika programů pro Windows 3.x.
Jako na potvoru to kreslení byla hlavní část programu, navíc nijak efektivně napsaná, čili pomalá. A stačilo pohnout oknem nebo kousek překrýt - a kreslilo se to celé znova!
Řešením bylo po vykreslení sejmout bitmapu, a pokud se neměnila velikost okna, tak při každé výzvě k překreslení ji položit zpět. Žralo to cennou RAMku, překreslení bylo vidět, ale i tak to bylo stokrát rychlejší, než to celé počítat a kreslit znova.
2panelový správce souborů Salamander 1.52, nebo jaká to verze byla strašně dlouho free (dnes už je asi i ta mnohem novější free), má dokonce v nastavení checkbox, zda má kreslit double buffered (aby postupné kreslení "neblikalo"). Váš program tedy taky mohl mít takové nastavení, případně autodetekce podle velikosti RAM 😉
12. 6. 2025, 22:05 editováno autorem komentáře
Windows posielaju WM_PAINT, resp X11 posiela XExposeEvent a v parametroch je, ktoru cast prekreslit. Teda nie je treba kreslit vsetko, ale staci tu cast, ktora bola "poskodena". Ked zacali aplikacie uploadovat na X server pixmapy namiesto pouzivania X primitiv, tak X server potom este isiel o kus dalej s XDamage extension.
Pruser je, ked sa to neda kreslit po castiach a treba cely buffer. Na to je potom dobre nakresleny buffer cachovat. Neskor to zacal aj Windows, aj X server cachovat na svojej strane. Programy renderovali svoje data do textury ktore nikdy neboli poskodene prekrytim inym oknom, takze display server si to vzdy vedel skomponovat sam.
Přecházel jsem z EGA na Paradise VGA 1024 (co měla jen půlmegabajt paměti, co si pamatuji...) někdy v roce 1992, a byl to docela citelný rozdíl.
Ta karta měla (asi dodatečně) nějaké VESA drivery, ale tak nějak si jela všechno po svým. Nikdy jsem se ji nepokoušel programovat, v podstatě jsem si ji pořídil kvůli Windows (3.0 CE, později 3.1).
Měl jsem ji schovanou vcelku donedávna - před cca 5 lety (těsně před koronavirem
) skončila v jakémsi obráběcím stroji, jehož mechanická část je podstatně bytelnější, než okolní elektronika. (Tedy: obrábět to bude ještě za dalších 20 let, pokud se seženou dobové ISA karty a díly na opravy.)
Jenže ten problém je jinde. Pokud stroj má vstup dat pomocí disket, tak na sobě žádné USB asi mít nebude. Kdyby USB měl (a pak by byl pravděpodobně vybaven WIN XP embeded), tak by pravděpodobně uměl načítat data z Flash disku.
Pokud vím, tak pro takovéto starší stroje se nabízí simulátory disketové mechaniky do kterých se zapojí Flash disk s obrazy jednotlivých disket. Jestli ty diskety fungují tak proč to řešit? Max si pořídím disketovku do USB k počítači na kterém budu připravovat data. Stroj je určený k tomu aby pracoval a vydělával....
ISA sběrnice bude potřeba na připojení karet pro ovládání vlastního stroje, které byly vyrobeny současně s tím strojem. Myslím že se bude těžko shánět řídící karta pro ohraňovák z devadesátých let do sběrnice PCIe.
Jeden z těch obráběcích strojů jsem měl možnost vidět (neptejte se mne, co to bylo - tohle jde daleko mimo můj obor).
Na té řídící jednotce mne zaujala jedna věc: data/programy to četlo z diskety, ale kdysi (podle stavu zažloutnutí už dost dávno) někdo provedl upgrade z disket 5.25" na 3.5". (Menší mechanika byla v obyčejném mezikusu, jaký jsem míval i na svém desktopu.) ;-D
Takže soudím, že nějaký upgrade na zcela jiný typ média by asi možný byl.
Jenže: s těmi disketami se velmi snadno manipuluje - mnohem snadněji, než s mnohagigabajtovou flaskhkou.
Ono se mj. delaji i emulatory disketovek, kdyz se resi tahle strana. I to ma stejny konektor. Takze stejne jako retrofit z te 5.25" na 3.5" se da udelat tohle. Ostatne na neco podobneho tu mame vedle i clanek, byt se to tyka Amigy. Ve finale to muze byt v tom vybrujicim stroji i spolehlivejsi - disketa ma svoje mouchy - ale kdyz se tam nic nehybe/netoci...
Dokonce existují i emulátory disket samotných. Něco na způsob kazetového adaptéru do auta.
https://en.wikipedia.org/wiki/FlashPath
"Jeden z těch obráběcích strojů jsem měl možnost vidět"
Jenze ta velka mechanika se zapojila na stejny kabel na ktery byla pozdeji pripojene ta mala. Vymen to za USBcko nebo CDcko ...
U tehle stroju budes mit problem i s HDD (pokud tam je) ... nejen ze to nebude sata, ono to bude limitovano velikosti a kdyz do toho das neco vetsho nez (a tech limitu byla historicky cela rada) tak to proste nepojede.
Kdyz budes mit velkou klliku, tak to aspon na ten nekonecne velkej disk dovoli udelat malou partysnu.
8051 se pořád vyrábějí a pořád jsou lidi, kteří s tím dovedou. Ostatně jednodušší je naučit se programovat 8051 než vyvíjet a ladit nový HW a SW, jen protože to někomu připadá staré a je to mimo možnosti jeho slepičího mozečku. Ale je to všeobecně poněkud zvrácený trend dnešní doby - raději nefunkční, ale nové, než staré a osvědčené. Nemám nic proti novým věcem. Bohužel poslední dobou se stále častěji stává, že kvalit svých předchůdců nedosahují.
Ja ale nikde nerekl, ze lidi nejsou. Ja rekl, ze se hure shaneji. Ja se s tim potkal na stredni - ale vim ze dnes uz to tam nevyucuji a nahradilo to neco jineho. Coz zrovnatak neimplikuje, ze se to nejde naucit - jen se musi chtit. A samozrejme "mladi" jdou casto radeji delat neco... pohodlnejsiho, nez programovani ve strojaku.
Ostatně jednodušší je naučit se programovat 8051 než vyvíjet a ladit nový HW a SW, jen protože to někomu připadá staré a je to mimo možnosti jeho slepičího mozečku.
To není o "slepičím mozečku", to je o tom, že lidí, kteří to s novějšími procesory už umějí, je prostě víc. A čas potřebný k tomu, aby se naučili i s 8051, pro firmu znamená peníze navíc, stejně jako čas, o který bude naprogramování 8051 trvat déle než totéž naprogramovat na nějakém novějším procesoru. A často to holt vyjde tak, že úspora za hardware nevyváží to, o co víc by stál vývoj software. Pokud tam tedy vůbec nějaká úspora bude, klidně se totiž může stát, že složitější a modernější procesor bude oproti tomu starému díky větší produkci nakonec i levnější.
Už je na čase si konečně odvyknout socialistické filosofii, že věci jsou drahé (zejména elektronika) a práce je "zadarmo". V dnešní ekonomice je to spíš naopak, práce kvalifikovaného specialisty bývá to nejdražší. Pokud jde o specializaci, která není úplně běžná, platí to dvojnásob.
práce kvalifikovaného specialisty bývá to nejdražší
Jenže oproti socialistické ekonomice se procento kvalifikovaných specialistů v IT neustále snižuje. Zato roste počet přeplácených fachidiotů, kteří místo aby během jednoho dne pronikli do tajů tak "složitého" obvodu jako je 8051, během dalšího dne zjistili, jak daný firmware funguje a během třetího dne implementovali požadovanou změnu, tak prohlásí nějaký žvást, který se dá volně přeložit ve smyslu, že to je nad jeho skromné intelektuální schopnosti, nadřízený, který je na tom mentálně podobně, sezná, že problém nemá řešení a začne se vyvíjet nový HW pro nový procesor, který zvládá vývoji po frikulínsku. Po pár letech vývoje dostanete něco, co při troše štěstí dělá skoro totéž, co starší verze. Celé to zaměstná násobně více lidí, trvá to řádově více času a stojí řádově více peněz, ale prý je to takto levnější.
Tahle mantra o tom, jak se tento přístup vyplácí, je jen tisíc krát opakovaná lež.
Fachidiocie (pokud uz teda ne zcela spravne uzijeme tento termin) je spis snaha "udelat vsecko" systemem "a ja to tam nejak dolepim" a neschopnost (ci neochota) rict, ze neco neumim ci proste nedelam. Nezijeme v devadesatkach, ajtak v rezimu "devky pro vsechno" sice dela hromadu veci, ale nic z toho co dela ve finale nedela poradne. V popisovanem modelu by to zakonite vedlo k nejakemu bastlu.
Aneb pokud se nekomu nelibi, ze do te jeho 8051 uz pozadovanou funkci nedolepim, tak muze proste zkusit sve stesti jinde. A pak muze priijit s referatem, jestli to bylo hotove za tri dny a jestli opravdu usetril.
Nevím, čím se živíte, ale když tu padla zmínka o 8051, tak je zřejmé, že se bavíme o embedded a průmyslových aplikacích. Zatímco smartfouny dnes lidi střídají jak ponožky, tyto systémy musejí vydržet spolehlivě fungovat klidně 20 let a předpokládá se, že nová verze bude nějak kompatibilní s tou starou. Cena komponent těchto systémů je cca o dva řády vyšší, než kdyby šlo o běžné spotřební zboží. Během jejich životnosti se dá předpokládat, že bude nezbytné tu a tam provést nějaký upgrade nebo customizaci. Prohlášením, že nějaká prkotina nejde udělat, a že kvůli tomu bude nezbytné přejít na zbrusu nový systém, což investora přijde na mnoho milionů plus komplikace při výrobě kvůli migraci, během níž se zjistí, že nový, super moderní systém už si nevystačí s RS-485, ale kvůli přenosu pár povelů a údajů z čidel potřebuje gigabitový ethernet, takže kvůli náhradě půlkilometrové sběrnice se musejí svolávat konsilia s výrobcem, protože na to při vývoji toho nového, super moderního šrotu, jehož plastové díly se v průmyslových podmínkách do 5 let rozpadnou a jehož super moderní nanometrové procesory se zapotácejí, kdykoli poblíž sepne nějaký stykač, nikdo nepomyslel, akorát neskutečně na...te, přičemž tento se bude snažit pro další etapy hledat pokud možno jiného dodavatele, tedy pokud v tom nebude hrát roli u nás všudypřítomná korupce. Nicméně, stačí, když se najde jeden človíček, který ukáže, že ten zdánlivě neřešitelný problém se dá vyřešit za týden. Pak dodavateli nepomůže ani tisíc referátů o tom, že něco nejde, nebo by se to nevyplatilo. Při podobných úvahách byste se měli občas vcítit také do role objednatele, co se mu vyplatí a co ne. Důvěra se buduje mnohem hůře a déle, než se ztrácívá.
Ale ono i prumyslove aplikace se vyviji. Z tech driv par cislicek se to dnes casto pomerne precizni a detailni telemetrie. Taky je vetsi tlak na integritu, na kterou se driv tak trosku kaslalo (nebo byla jen primitivni). RS485 ma sve limity, mj. v poctu pripojenych zarizeni a treba i v tom, ze vysilat muze jen jeden a samozrejme na vyssich rychlostech to je i nachylnejsi na chyby. Jasne, par povelu... ale co kdyz je chcete predat opravdu spolehlive? To neni jen o tech rychlostech. A to pak narazite i na blbosti, ze jen na blbe vycitani "telemetrickych" dat z tech cidel se na te RS485 se z vice mist ani nemuzete zeptat... resp. zacnou se dit ponekud skarede veci. Ve finale to muze byt problem i v te fabrice, kdyz chcete na konec "puvodni" linky pripojit neco noveho a stoje mezi sebou provazat (a nebo mate paralelni snimace tehoz, jen aby i nove pripojovana vec taky mela data... no proste bastly) - a to pomijim, ze casto zrovna ty historicky cenne bastly ala 8051 maji proprietarni a casto neprilis dokumentovane komunikacni rozhrani, protoze holt se vyrobce chtel skrze obskuritu "pojistit", aby mu nekdo nelezl do zeli, proste klasicky vendor-lock. V momente, kdy zacnete pouzivat standardni protokoly ta komunikace take "nakyne", zeano ;-)
Ak je nad RS485 použitý príčetný protokol, napr. Modbus, vie to byť hodne robustné. Rámce sú CRC16 checksumované, keď nesedí (alebo slave nereaguje prípadne vracia chybu), prenos sa opakuje, ideálne s exponenciálnym backoff. Integrita rozsiahlejších dát, ktoré je potrebné čítať na viac rámcov a stále je žiadúca atomicita (v zmysle, že slave žiadnu časť počas čítania nezmenil), je riešiteľná revision countrom, ktorý sa prečíta pred a potom znova po prenose a ak sa líši, celý blok sa prečíta znova (obdobne sa dá commitovať aj zápis bloku). Sémantika registrov sa spravidla navrhuje tak, aby boli zápisy idempotentné. V praxi tomu pri trochu rozumnom návrhu a realizácii nevadí takmer nič, ani rušenie, ani odpájanie/pripájanie zariadení za behu, ani sporadické súbežné čítanie/zápisy viacerými mastrami, napr. v rámci diagnostiky. Mieru obskurity na strane pripájaných zariadení to rovnako hodne redukuje, keďže protokol je dosť striktný.
Ne, Modbus RTU rozhodne neni staven na to, aby tam pristupovalo vice masteru
...súbežne. Ak je akokoľvek systematicky zabezpečená bezkolíznosť, tzn. že v roli mastra bude v každom momente vystupovať len jedno zariadenie (vrátane pokrytia odpovede ním osloveného slave), môžeš tam mať mastrov, koľko len sieť impedančne znesie.
Prevádzka bez explicitného riešenia bezkolíznosti už úplne čistá nie je, väčšina budičov ale má ochrany - prúdovú aj tepelnú a už som videl riešenia, kde sa s nejakým percentom kolízií počítalo. A aj v takom režime to desaťročia spoľahlivo funguje.
Všetko sú to len hračky v porovnaní s Geometry Engine. https://www.electronicdesign.com/technologies/embedded/article/21149941/jon-peddie-research-geometry-engine-the-legendary-chip-that-launched-sgi
IN PIXELS WE TRUST