Názory k článku Vývoj her a grafických dem pro oslavovanou i nenáviděnou platformu PC (první kroky)

K tomu M68000, nejde o žádnou nejasnost. V porovnání s 8088 je tu podstatný rozdíl. 8088 byl nativně 16bitové jádro se zúženou externí datovou sběrnicí. Podobný případ byl i386SX, který měl 32 bitové jádro se 16 bitovou datovou sběrnicí. Naproti tomu M68000 byl interně 16 bitová architektura. Instrukční sada, navrhnutá s cílem být "future proof", sice nabízela 32 bitové operace, ale ty byly v podstatě emulované mikrokódem a většinou kvůli tomu zabíraly dvojnásobný počet cyklů. To odstranil až 68020, který měl 32 bitové jádro.

M68000 měl ještě jednu zvláštnost, adresová sběrnice měla sice 32 logických bitů, ale reálně byla odříznutá na 24. Zejména uživatelé Macintoshe o tomhle vědí své...

To jo, adresová sběrnice na M68k byla reálně 24bitová, takže s těmi horními bity šly dělat další věci. Potom to ve vyšších řadách dělalo problémy, pochopitelně.

Ale oproti 86 a jeho systémem segment:offset byla M68k mnohem vyspělejší. Na 86 to už začalo dělat problémy při překročení prvních 64 kB a ne někde u 16 MB (a to byla kapacita, ke kterou se dlouhou dobu ani nepřiblížili).

To jistě, tohle a grafika CGA jsou dva důvody, proč vývojáři her staré IBM PC nenáviděli ;) I když asi zase ne až tak moc, protože 8088/8086 se oběvil v několika arkádních strojích a pokud se nemýlím měla ho používat i nerealizovaná konzole Flare One.

CGA graficke mody prave paradoxne vypadaly slusne jen na cernobilych monitorech. Jakmile k tomu prisly barvy, mohl clovek jit po nejake dobe k ocnimu. Pokud z toho tedy nezesilel. Kazda CGA hra byla jak spatny halucinogenni trip.

Len doplním, že cez kompozitný výstup vedela CGA zobraziť 16 farieb naraz.

Říká se, že IBM udělalo CGA částečně záměrně tak, aby to vypadalo hnusně. Grafika byla tehdy "hračička", IBM dělalo počítače pro profesionály, což, jak známo, znamená výhradně byznys a ten, jak známo, musí být co nejnudnějši a nejmíň uživatelsky přívětivý.

M68k taky měla dvakrát tolik tranzistorů než 86. Problém s šestnáctibitovým offsetem je mnohem subtilnější než problém šířky sběrnice. S těma segmentama je to sice opruz, ale nakonec to jde vyřešit. Když už mi dojdou dráty z procesoru ven, tak už je tam nenaprogramuju. To porovnáváš dvě úplně různý věci.

Intel 8086 měl adresovou sběrnici osekanou na 20 bitů, což trošku odpovídá rozsahu segment:offset, ale těch posledních cca 64kB je problematických, protože buď leží mimo 20 bitů nebo nad nimi. A tady se rodí neslavná A20 Gate, která nás strašila nějakých 30 let (fujtajbl s ní).

Jj, pokud se pamatuju něco podobného měly taky první modely Mac II právě kvůli problému s horním oktetem na adresové sběrnici.

fujtajbl vespolek! No, osekanou. Prostě 20 nožiček. Mně se to v minimal módu líbilo - šestnáct bitů a vidím který ze čtyř segmentů. V maximal módu je sčítání segmentu a offsetu flexibilnější než kdyby se řekněme deset bitů vzalo ze segmentu a deset z offsetu.

No, nevím jestli asembler pro DOS není poněkud out.
Zvlášť když si dosbox nemohu pustit v Termuxu.
Mnohem zajímavější by pro mě byl asembler přímo použitelný v Termuxu.

DOSBox běží přímo v Androidu ne?

A NASM by v Termuxu běžet mohl (nevím, ten systém nemám :-)

Dosbox neběží v termuxu, ale v termuxu běží qemu. Jenže jsem si s tím neporadil.

Zkoušel jsem:

#!/bin/sh

# Vytvoření jednoduchého x86 assemblerového kódu
cat << 'EOF' > test.asm
section .text
   global _start     ;must be declared for linker (ld)

_start:             ;tells linker entry point
   mov  edx,len     ;message lenght
   mov  ecx,msg     ;message to write
   mov  ebx,1       ;file descriptor (stdout)
   mov  eax,4       ;system call number (sys_write)
   int  0x80        ;call kernel

   mov  eax,1       ;system call number (sys_exit)
   int  0x80        ;call kernel

section .data
msg db 'Hello, world!', 0xa  ;our dear string
len equ $ - msg     ;lenght of our dear string
EOF

# Překlad assemblerového kódu do objektového souboru ve formátu ELF
nasm -f elf -o test.o test.asm

# Slinkování objektového souboru do spustitelného souboru
ld.lld -m elf_i386 -s -o test test.o

# Spuštění programu v QEMU
qemu-i386 test

Ale dostávám:

~/W/asm/hello $ bash test.sh
Error while loading /storage/emulated/0/DROPBOX/WORK/asm/hello/test: Exec format error
~/W/asm/hello $ file test
test: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped

A nevím si s tím rady.

Neberte to ako rypanie. Naozaj ma to zaujima. Aky ma tento clakok vyznam? K comu je dobre zapodievat sa vyvojom pre archaicke platformy?
(Okrem nostalgie)

je lepsi kdyz clovek rozumi i historii a jak se to vyvijelo az do dneska a vedet o assembleru nemuze skodit.

Tak asi se dnes programováním v assembleru bude živit opravdu jen málo lidí. Nicméně odpověď je snad už v názvu seriálu - tento článek je úvodní díl.
Nebo jinak - asi budu za pošuka, ale já si občas nakódím v assembleru něco pro 8bit Atari 800XL, resp. pro experimentální počítač s 65C02. Ono je docela výzva nacpat nějakou funkcionalitu do těch pár kiB paměti a přitom dosáhnout rozumné rychlosti. Je to, myslím, dobré cvičení algoritmizace a optimalizace. A přesně o tom dema jsou. Na druhém konci spektra programátorů (no flame, pls) stojí "moderní" a "korporátní" jedinci, kteří, než aby se zamysleli a napsali si vlastní metodu na pár řádků, raději použijí cizí knihovnu co je závislá na dalších knihovnách. A pak to končívá tak, že vývoj trvá ještě déle, nároky na paměť rostou a rychlost klesá a třeba úplně zbytečně.
Snad jste pochopil, co jsem tím chtěl říct.

Pro embedaky je porad asm kdyz ne denni tak tydenni chleba. A obcas i pro vyvojare driveru. Pracuji ale spis s fragmenty asm kodu v kombinaci s high-level jazyky.
Pokud tedy neudrzujete stary kod ktery kdysi davno nekdo napsal v MASM. I takove veci jsou. Proste tu 30 let starou codebase tahate v korporatu jak lejno na bote.

Pouziti cizich knihoven muze byt zradne. Stava se ze z licencnich duvodu si radeji firma napise vlastni knihovnu nez aby ze sebou nechala vytirat.

real mode je na většině procesorů řady x86(-64) stále dostupnej, takže je to vlastně i popis nejmodernějších architektur (a real mode s vypnutou A20 gate je vlastně krok k původnímu Intelu 8086). Tedy existuje standard x86s od Intelu, který ho odstraňuje, ale ten ještě není (IMHO) používanej.

Za mě - kromě nostalgie, ta tady hraje roli - to má i řekněme edukativní význam. Hardware IBM PC a vlastně i samotný BIOS a DOS je doslova přehlídkou toho, jak se nedomyšlenosti a různá ad-hoc řešení musela kvůli zpětné kompatibilitě ohýbat několik desítek let a kazit tak radost minimálně ještě celé jedné další generaci programátorů.

Těch nedomyšleností a ad-hoc řešení je celá řada a na mnohé z nich postupně narazíme. Je to zmíněná A20 gate, funkce BIOSu přestávající stačit při poněkud vyšší kapacitě RAM, dvojí přístup k souborům v DOSu, několikrát "nastavované" adresování bloků na disku, aby se vyhovělo původním návrhům adresování, snaha nacpat celou video RAM do 64 kB adresového prostoru atd. atd. A nepřeberné množství bitů v různých řídicích registrech, které buď postupně ztratily význam, nebo se k nim přidávaly další bity umístěné někde jinde.

(a to vůbec nepíšu o omezení operačních systémů pro PC)

Takže - poučení pro další generace?

K čemu je dobré umět používat vodovky, když mi dnes obrázek "namaluje" AI rychleji a lépe než já?

Protože v životě nejde jen o profit, to možná tak na Vulkánu. Lidé s emocemi chtějí někdy i zážitky sami sebou tvořené :-)

Ze stejného důvodu, jako např mě baví hrát na piáno, i když je samozřejmě snažší a rychlejší si pustit skladbu na nějakém streamu.

Odpoved je: aby si AI maliarovi mohol povedat ze vodovky sa na tuto pracu nehodia a ani tempery. Ze chces nerozmazany uhlik alebo laserove gravirovanie.

Spravna otazka je: Ked ma AI nedostatok informacii o starych platformach, ako mam napisat alebo udrzovat kod pre takuto platformu bez jeho pomoci?

Pripadne inak: ak ta historia PC nezaujima, moze sa stat, ze budes opakovat jej chyby na softwarovej urovni aj dnes. Stretavam sa s tym bezne aj dnes, ze niekto si povie, ze stlpec Mesto ma v databaze max. 32 znakov.. a pritom mame na Slovensku aj mesta s dlhsim nazvom, vo svete nehovoriac.

Hezká odpověď, snad si jí Aas přečte.

A já si mezitím zajedu na Retrogaming do Dvora Králové ;-)

Ja musim podakovat za podobne clanky, autora citam velmi rad a komplexnost a hlbku jeho clankou obdivujem. Citam ich dokonca aj ked je tema mimo mna, clovek nemoze stale zit vo svojej bubline.

Díky, potěšilo.

Diky za clanek, hezke vzpominky na dobu kdy jsem psal veci v assembleru a nikdo z meho okoli nechapal jak tomu muzu vubec rozumet a proc nepouziji nejakou knihovnu… dnesni programatori v naproste vetsine jsou lepici kodu volajiciho 3rd party knihovny bez hlubsich znalosti a tak vysledne aplikace zerou gigabajty RAM a jsou neefektivni i z pohledu rychlosti. Mame sice tisickrat vykonnejsi hw ale rychlost aplikaci je vicemene stejna.

2. 7. 2024, 11:06 editováno autorem komentáře

Mám to podobně, pomocí assembleru jsem svého času rozsvítil téměř jakoukoli LEDku, která byla k počítači nějakým způsobem připojená.

Jak ty aplikace jdou všechny směrem web, tak mi připadá, že pro řadu lidí i z řad programátorů je takový ekvivalent assembleru dneška i obyčejné HTML.

Včera se nás ve firmě nějaká holčina z HR, co to organizuje, ptala, jestli se plánujeme zúčastnit TeamBuildingu. Použila na tuhle jedinou prachobyčejnou otázku nejdřív nějaký Google Forms či co to bylo, a když jsme ji poslali do patřičných mezí, že se kvůli takové blbosti nebudeme hlásit přes naše soukromé Google účty, tak použila Microsoft Forms. Přijde mi to úplně stejně uhozený jako zneužívání výkonu dnešních strojů současným stylem tvorby aplikací.

3. 7. 2024, 16:53 editováno autorem komentáře

Dival jsem se jak hello world vypada v asm na linux, a porad je to dost podobny (misto int syscall). Docela mam nutkani to zacit zkouset, i kdyz jsem na asm nesahl od dob ZX Spectra (Z80). V kazdym pripade diky za clanek, je dobry si ozivovat co se deje tam dole. Jestli vymizi lidi co to vi a umi tak jsme v haji, co se dnesnich digitalnich PC tyce. Jedine ze by to prevzala AI :)

jj ten samotnej kód v assembleru bude +- stejnej, i když v Linuxu jsou řetězce přece jen pojaty rozumněji (pokud tedy považujeme za rozumné mít ASCIIZ řetězce). Rozdíl bude ve výsledné binárce, protože COM je prostě jen ona sekvence instrukcí + řetězec, kdežto pro ELF nebo PE to docela naroste (bylo by zajímavé zjistit, na kolik se to dá stáhnout, když už nemáme a.out, ale stejně to pár desítek bajtů navíc bude IMHO).

Cekam ze az prijdou "hudbicky", tak si soundblasteraci a gravisaci vjedou do vlasu. Uz se poprali?

Covox

IBM PC - takze PC speaker^Wsqueezer ;) daji se z toho vytahnout i nekolikabitovy samply s rozumnou frekvenci, ale samozrejme je to humus nejvetsi.

Inspirace u Sinclaira? Já vlastně ani nevím, zda C64 a Atari měli nějakou cestu k odposlechu z datasetů, ale díky Beeperu jsem prožil mládí na jednobitových samplech :-)

Kdyz si clovek zvysil hlasitost TV na maximum tak mohl potichu slyset kazetak.
Co se tyce 1bitovych samplu tak u SIDu to byl opruz. Byl taky rozdil mezi starym a novym SIDem.
SID nemel sam o sobe podporu pro generovani zvuku primo cyklem v sw jako treba zx, pc speaker, vase kvakadlo zapojene na outy v arduinu. Existovalo nekolik hacku pricemz ten jeden zpusoboval to ze noveho SIDa (daval se do C64 II) byl problem ze to bylo dost potichu. Sazel bych na trik s volume registrem. Ty ostatni snad pouzivaly kopani do sumoveho generatoru a filtru.

3. 7. 2024, 13:01 editováno autorem komentáře

Krasa :).
Nadsen z knizek Programming Boot Sector Games, jsem
se zmohl jen na:

https://github.com/marmolak/ticasmtoe

Nektere triky jsem slohl i z legendarniho diskmagu Vyhen :).

Moc hezké. Jen dodám, že hardcore dema se nepíší v ASM ale přímo ve strojovém kódu.

to uz je uplne sado-maso, protoze nemas zadnou pomoc s adresama, delkou instrukci a opkody, to slo na 8bitech, ale i tak bych radsi pouzil cross-kompiler.

Neměl byste nějaký příklad? Tomu se mi moc nechce věřit. :-)

Priamo stroják kedysi používali kámoši na ZX Spectre, ale nie aby to bolo HC, ale myslím že to tam bola nevyhnutnosť, asi kôli nedostatku ramky (?). Aspoň myslím, ale bol som chvalabohu atarista :-) . Ináč nevidím žiaden praktický význam, prečo by som mal obísť assembler. Asi by to potom bol hneď prvý program, ktorý by som sa pokúsil spraviť, aby som už nemusel použiť stroják :-) .

Tak je pravda, že v BASIC pomoce POKE a PEEK je to vlastně psaní ve strojáku :-)

V tomto kontexte sa hodi pripomenut minimalne dve dema:

- https://www.youtube.com/watch?v=hNRO7lno_DM (linky na technicky popis: https://demozoo.org/productions/136167)

- https://www.youtube.com/watch?v=fWDxdoRTZPc

Děkuji za tento článek, člověk si připomene vývoj počítačů za poslední 40 let. Vždycky se na příspěvky Pavla Tišnovského těším a rád zavzpomínám na PMD 85, IQ 151, Commodore Plus/4, 386 SX, DOS, Windows 3.1, Novell NetWare, Linux, OS/2 Warp, Windows 95, Windows NT, ...

3. 7. 2024, 14:42 editováno autorem komentáře

Díky za připomenutí Sysmana. Zdravím Ládínka, jeho autora. S tímto programem jsem si užil. Před třiceti lety jsem ho používal denně. Na jednu stranu to byly zlaté časy. Ale byly to i časy nočních můr. V dosu si člověk musel všechno ošetřit sám. Navíc, 640KiB přece musí stačit každému. Vzpomínám si, jak jsme museli z programu vyhazovat méně používané funkce, abychom se po přidání nové funkce ještě vešli do paměti. Nightmare.
Ještě se vrátím k Sysmanovi. Když dojdeš na stránku s informacemi o programu, najdeš tam i moje jméno. Speciální poděkování za mnoho informací a bugfixů :-)

Ahojte,
Pavle na úvod ti chcem veľmi poďakovať nielen za tento článok, ale všeobecne za všetky tvoje príspevky komunite. Niekedy ma až prekvapuje, že nie som s mojimi záujmami na svete jedným z posledných exotov a ty ma vždy presvedčíš, že to tak nie je. Čo sa týka porovnania programovania v assembleri a "programovania" pomocou LLM, tak to vychádza asi z nepochopenia, prečo mnohí z nás v 80/90 rokoch programovali. Išlo práve o prehľadávanie všetkých nepoznaných zákutí, hľadanie spôsobov, ako to spraviť rýchlejšie, lepšie, stabilnejšie ... Nechať si vygenerovať neurónkou kusy Python kódu a potom ich lepiť nie je to programovanie, ktoré formovalo nielen môj život. Vôbec nechcem odsudzovať súčasné potreby firiem a to, že mnoho ľudí ich splní. No čaro programovania je skutočne v niečom, čo sa veľmi ťažko opisuje niekomu, kto to nezažil. Ako dieťa som samozrejme začínal na Atari s Basic-om, no v tej dobe bola priam nutnosť prejsť nižšie, pokiaľ chcel človek niektoré veci spoznať a zároveň slobodne tvoriť. Neskôr som tiež skončil pri všetkých tých Borland Pascaloch, Visual Basicoch, či C++. No moja romantická duša sa aj tak vždy najviac poteší, keď môžem skúmať, ako to funguje "tam dole" a rýpať sa v tom, čomu nie, že väčšina ľudí nerozumie, no ani ich to nezaujíma. Assembler a k tomu Céčko, to je proste slasť a celý život ľutujem, že som sa v tom nedostal ďalej. Dcéra nedávno doštudovala na Masarykovej univerzite informatiku a tiež som bol prekvapený, že naprostá väčšina študentov si vystačila s Pythonom, Javou, či C# a samozrejme veľkou kopou knižníc a pomáhajúcich nástrojov. Rozhodne na tom nevidím nič zlé, no je pre mňa ťažko pochopiteľné, kde zmizla tá vášeň, ktorú sme mali v drevných časoch PC, aby sme veci spoznali až na dreň. Ale proti gustu žiaden dišputát. MEGA VĎAKA ZA ČLÁNKY PT. Bodaj by som mal viac času na štúdium od úplného spodku postupne nahor, no práca a povinnosti už človeka nepustí.

díky, moc pěkná zpětná vazba!

Osobne, kebyže sa mám učiť inštrukčnú sadu všetkých architektúr a všetky syscally, prerušenia a whatever, tak by mi vybuchla hlava. Viem tak armhf a to zle.

Keď zajtra za mnou príjde šéf, že chce niečo pre architektúru wompačambo s bumba OS, tak sa spýtam, aká java na tom beží.