Názory k článku Kouzlo minimalismu potřetí: vývoj her a dem pro slavné ZX Spectrum

na zx spectru u kamarada jsem spustil svuj prvni program v zivote, bylo to v basicu, a byla to smycka vypisujici cisla.

halelujazx.

V clanku jsou uvedeny konstanty 0×00010000 a 0×5800. To je trochu matouci, protoze prvni je binarni a druha hexadecimalni.
Pasmo rozpozna 0x5800 jako hexadecimalni hodnotu, nejen $5800 nebo #5800.
Binarni zapis je s predponou %, jak je uvedeno v kodu.

Z80 je trosku zvlastni procesor a spousta veci jde delat ruznymi cestami.
org $8000
start:
ld a,%00010000
ld ($5800),a
ret
Jde zapsat se stejnou delkou kodu (2+3+1=6) i takty (7+13+10=30) jako
org $8000
start:
ld hl,$5800
ld (hl),%00010000
ret
3+2+1 = 6 bajtu
10+10+10 = 30 taktu

Jen se pouzije jiny registr. Tohle dokaze byt poradna vyzva uz od par instrukci. Kdyz se budete snazit napsat neco jen trosku mene trivialniho, tak na prvni pohled nebude zrejme, ktera kombinace/varianta je lepsi.

Staci se podivat na vysledky Z80 size programming chalenge, kde i ostrileni programatori se nedostanou na optimalnich 15 bajtu.

http://www.retroprogramming.com/2014/12/z80-size-programming-challenge-1.html

A pokud se pokusite pouzit nejaky prekladac, napr. pro C tak vysledek bude opravdu strasny. Dones neexistuje poradny prekladac u ktereho si nebudete trhat vlasy pri pohledu na vysledny kod.

Z80 neumi efektivne pracovat s parametry ulozenymi na zasobnik, takze to uplne diskvalifikuje C. Pravdepodobne pouzije instrukce typu LD E,(IX+n), ktera ale zabira 3 bajty (jeden pro prefix, dalsi instrukce a treti hodnota n) a trva 19 taktu. Oproti instrukci LD E,(HL), ktera zabira jeden bajt a trva 7 taktu. Takze pri vhodne zvolenem algoritmu, kdy se budeme snazit cist data sekvencne za sebou a pouzijeme k tomu instrukci INC HL (1 bajt a 6 taktu) tak se dostaneme na 2 bajty a 13 taktu.

Ale vetsina prekladacu je jeste horsich budou se snazit neustale ukladat promenne do pameti a opakovane nacitat do registru. Proste bude zapominat co se pred chvili drzel v registrech, protoze uz dela jinou cast programu a nepredava si co si drzi v registrech, zda to bude muset uklidit nebo to muze naopak vyuzit.

Staci se podivat co za hruzu leze z jednoducheho programku co testuje zda retezec je pangram, kdy se pouziva 32 bitove pole pro pouzite znaky.

https://github.com/DW0RKiN/M4_FORTH/blob/master/Benchmark/Pangram.c

https://github.com/DW0RKiN/M4_FORTH/blob/master/Benchmark/Pangram.lst

Misto jednobajtove instrukce o sedmi taktech
or 32
napise sdcc
86 ;Pangram.c:10: c |= 32; // uppercase
004E DD 4E F8 [19] 87 ld c, -8 (ix)
0051 CB E9 [ 8] 88 set 5, c
0053 79 [ 4] 89 ld a, c

Preklad kodu zapsanemu ve FORTHu je nasobne rychlejsi a i ten byva stale 2x horsi nez co napisete primo v assembleru. Protoze Z80 se vlastne nehodi ani na ten FORTH. Chybi mu kratka a rychla instrukce ex SP, HL. Ktera by mu umoznila "zdvojit" zasobnik. Takze si musi druhy zasobnik emulovat pres to inc/dec a ld (HL),register pripadne ld register,(HL). Popripade jinak, protoze to zase existuje vice reseni.

PS: K tomu prekladaci "pasmo" bych podotknul, ze ma nespravne danou prioritu u unarniho znamenka minus. Ma ho misto nejvyssi nejnizsi, takze
ld HL, -100+500
je
ld HL,-600
Ke vsemu uklada pres EQU hodnoty pokazde jako unsigned word (16 bitu, vic neumi). Takze muze byt docela vyzva zapsat vyraz tak aby napriklad dokazal spravne porovnat >,<,>=,<= mezi signed hodnotami.

Napriklad potrebujete zapsat:
ld HL, m <= n
aby se to zkompilovalo jako
ld HL, 0x0000
nebo
ld HL, 0xFFFF

nebo chcete aby to spravne nasobilo nebo delilo signed hodnoty jako
ld HL,m/n
popripade zbytek
ld HL,m % n

Napsat floor divison uz je dost narocne jako vyraz pomoci toho co Pasmo umi.

Kde za m a n si dosadte pres makro nejakou konstantu 16 bitovou signed.

Popripade 32 bit/16 bit, pokud je vysledek 16 bitovy tak s omezenim Pasma na 16 bitu to zapsat sice jde, ale je to na celou obrazovku.
ld HL, 32bit_m/16bit_n

PPS: FUSE emulator ma sice debugger, ale ten je prakticky nepouzitelny, je tezke se vubec dostat k informacim jake zkratky muzete pouzit. Jak zmenit hodnoty registru atd. Ale na linuxu je bohuzel to nejlepsi co muzete mit pokud nechcete pouzivat wine.

Budete pouzivat jen:

breakpoint 0x6000
br 0x8000

ignore id count
ig id count

delete id
del id

Popripadne dvouklik na zasobnik vytvori breakpoint na jedno pouziti na adrese co v nem lezi.

A uz se nedostanete k:

Neco se snazi cist z adresy 0x6000:
breakpoint read $6000
br re $6000

Neco se snazi zapsat na adresu 0x6000:
breakpoint write $6000
br w $6000

break 0xa000 if z80:bc >= 0x8000 && z80:de < 0x1234

set z80:a 0xff
set z80:de 0x1234

7. 2. 2023, 03:49 editováno autorem komentáře

Jaký software pro windows bys doporučil?

hmm to jsem myslel, ze je na tom SDCC o dost lip. Hodne lidi ho do doporucuje.

tyjo moc ne, ty původní osmibitové procesory (snad až na 6809 od Motoroly, kde aspoň běžel FORTH) nebyly na céčko připraveny. Takže assembler vyhrává.

6809 byl super, jen asi přišel moc pozdě (a byl drahý). Nicméně technicky paráda.

IMHO to bude tym ze jak unix a C, tak aj vznik 6800 sa tak nejako tocili okolo PDP-11

Díky za doplnění. Tu konstantu jsem v textu opravil na binární, aby to nemátlo.

A to, že je programování na Z80 výzva namísto tupého zápisu instrukcí (jako na RISCech, které mám jinak rád :-) to se mi právě líbí. I 6502 byla výzva, pokud se dělalo cokoli se šestnáctibitovými hodnotami, hlavně se signed. Z cc65 (céčka) taky lezou hrozné věci, protože 6502 neumí zásobníkové rámce (tady je na tom Z80 líp).

Jo, je to výzva :) Nicméně na moderních “Z80”, co tak koukám, na to vývojáři kašlou, například eZ80 je superskalární a běží na 50 MHz, takže se vesele používá C a fakt, že výsledek je řádově pomalejší, nikdo moc neřeší.

Staré dobré osmibity, to byl jiný level. Ach ta nostalgie, člověk by i slzu zamáčkl.

jo protoze eZ80 ma zhruba 3x rychlejsi instrukce (1/3 taktu puvodnich instrukci) a navic to taktuji na tech 50 MHz, tak se muze prasit v C a jsme na tom porad tak nejak stejne :/ (a to jeste budme radi za cecko)

Copak asi používali na někdejším legendárním superpočítači s 256 procesory Z80? To byl tuším začátek 80. let. Pokud se dobře pamatuju, měli tam nějaké koprocesory pro výpočty. Možná Fortran? Musím se znovu podívat po dobovém článku.

To je teda neuvěřitelnej doomsaying :) Je sice pravda, že kompiler typicky přistupuje k proměnným na zásobníku pomocí LD r, (ii+NN), což je pomalejší než indexace přes HL, ale na druhou stranu ne vždy se podaří data seřadit tak, aby opravdu stačilo hejbat indexem jen jednou. A HL je jediným plnohodnotným 16-bitovym akumulátorem který máte a někdy je prostě nemožné používat ho jen jako index, takže se musí někam uložit, pak zase obnovit atd.
V praxi se ruční alokace registrů vyplatí jen u časově kritických části programů, v okamžiku kdy řešíte nějakou logiku a potřebujete struktury bude i ručně psaný assembler vypadat tak, že se podprogramu ("metodě") předá pointer na strukturu v indexovém registru a na členy se přistupuje přes index.
A časově kritickou části je u Spectra téměř vždy výstup na obrazovku a to je přesně ta věc, na kterou třeba použijete už hotovou knihovnu, která je napsaná v asm.

Na 3.5MHz procesoru, kde nejkratší instrukce trvá 4T a nejdelší přes 20T a těch T mám za 1/50s jen 70800 je skoro každý kód časově kritický.

Proto se např. obrazovka maže pomocí rozvinuté smyčky instrukcí push místo ldir, proto je modifikace operandů instrukcí v podprogramech volajícím kódem docela běžná praxe, stejně tak nejrůznější přehazování hodnot mezi 8 bit registry ld R,R (místo pushování na zásobník) atd...

Ano, na ZXS se dá programovat i jinak než v ASM, ale jenom s ASM lze dosáhnout nejlepších výsledků.

Holt jiný svět. ZXS není PC, kde se časem i pamětí plýtvá.

Když jsme u toho plýtvání časem, jaká je asi produktivita někoho, kdo píše v C a kdo píše v asm ?
Jen potvrzuješ moje slova, že úzké hrdlo bude výstup na displej a na to se použije existující knihovna.
Mimochodem, memfill pomocí zásobníku je signaturou her napsaných až tak po roce 85. Knightlore si maže backbuffer prostým LD (HL),A a Manic Miner kopíruje backbuffer jednoduše LDIRem. Kupodivu to funguje.

Hobby vs práce

U hobby si můžu dovolit být méně efektivní, abych dosáhl výsledku, který mě bude víc těšit. (a třeba slepit Karlštejn ze zápalek... ukrutně neefektivní :))

Na 8bit Z80 s 16bit adresním prostorem je psaní v assembleru ještě docela dobře zvládnutelné, na modernějších CPU samozřejmě čím dál méně a jen když není vyhnutí.

Na osmibity existuje za ta desetiletí mnoho ustálených postupů jak věci dělat efektivně i v tom assembleru - zvuk, kreslit sprity, hýbat obrazem (scroll), číst klávesnici, číst soubory... leccos lze recyklovat a použít jinde.

Nepotvrzuji tvoje slova (zcela). Jen se shodujeme v tom, že grafické operace musí běhat rychle. Já k tomu ale říkám NEJENOM grafické operace. Každý ušetřený takt (nebo bajt) je dobrý.

Jasně, programátorské triky se vyvíjejí... ldir na mazání a přenosy se samozřejmě používat nepřestal (resp. ldi v částečně rozvinuté smyčce), je to jen o prioritách rychlost vs obsazená paměť.

Dekuji, moc hezke vzpominky!

Prometheus byl super. Pamatuju si, jak jsem v něm napsal takové malé "demo", co jsem obšlehl z nějakého cractra na Amize. Šlo jen o rotující text nad obrázkem. A bez hudby. Jo, to byly časy...

Prometheus je malá pokladnice špeků, co se tenkrát s programy dělaly. Pár příkladů.

Prometheus na začátku zkopíruje část kódu, která je potřeba jen jednou (nastavení + relokátor), do video RAM (díky nastavení atributů není vidět) a po použití je zahozena.

Program je relokovatelný. Neznamená to, že by byl napsán s pomocí jen relativních skoků. Používá tabulku míst v programu, které je potřeba upravit tak, aby odpovídala cílové adrese. Tato tabulka se generovala při kompilaci.

Prometheus masivně používá sebemodifikující se kód. Nejběžnější příklad je využití paměťového místa s výchozí hodnotou proměnné k uchování její změněné hodnoty.

variableX:
    ld b,001h
 ...
   ld (variableX+1),a

Nastavení se také zhusta dělá tak, že se prostě přepíše příslušný kus programu tak, aby dělal, co má - ušetří se místo a nemusí se testovat hodnoty proměnných a dělat skoky. Třeba nastavení toho, jestli se písmena mají zobrazovat jako malá, velká či nezměněná

caseModificationCodeOptions:
    and 0ffh  ; normal
    or 020h   ; lowercase
    and 0dfh  ; uppercase

Podobně se řeší to, jestli se fonty mají vykreslovat tučně. Nebo když chcete tisknout nějaký řetězec, umístí se literál s jeho obsahem přímo za volání tiskové rutiny (pomocí CALL). Ta si ze zásobníku vyzvedne adresu, která odpovídá začátku řetězce, a po vytištění skočí za jeho konec (JP, nikoliv RET), kde program vesele pokračuje.

Jeho Monitor má úsporně řešené provázání kódů kláves (či klávesových zkratek) s akcemi, které se při jejich stisknutí mají provést. Používá k tomu tabulku, která obsahuje pro každou položku dva byty. Druhý je kód stisknuté klávesy, první je rozdíl adres dané operace a operace svázané s předcházející klávesou (přičemž adresa první takové operace je známá). To ušetří místo, protože místo dvojbytové adresy každé operace (je jich celkem 40) stačí jeden byte, a navíc to zkrátí relokační tabulku. Kód pak vypadá nějak takto:

defb monShowAddresses - monExecutionMode
defb 0x63 ; c       - show addresses
defb monAddressPrintingMode - monShowAddresses
defb 0x3f ; SS + c  - addresses printing mode

Pro dekompilaci takového kódu to znamená, že adresám příslušných operací nejsou v kódu automaticky přiřazena vůbec žádná návěští, ta je teprve nutné dopočítat. Rovněž ona tabulka vypadá na první pohled jako posloupnost bytů bez zjevného smyslu. Aby toho nebylo málo, na příslušné operace se neskáče pomocí CALL nebo JP, ale tak, že se požadovaná adresa vloží na zásobník a pak se provede RET.

Komu sa paci vyvoj na stare pocitace, tak odporucam si kupit ESP32, k nemu farebny dsiplay a malu klavesnicu.

A clovek sa moze hrat s Ceckovym kodom.

To není to stejné. Kromě nostalgické hodnoty (tímto zdravím majitele veteránů) máš prostě na speccy jasně nastavené zrcadlo a povědomost o tom, co z toho HW dokázali vytáhnout jiní.

Tedy například Elite, což je doslova pokladnice nápadů a algoritmů. Navíc ta orientace přimo na HW má taky něco do sebe.

Nebo si zkusit "obejít" barevné atributy a zkusit nějaký pixel art na stroji, kde to má smysl (http://xtremeretro.com/wp-content/uploads/2016/09/ZX-Spectrum-Pixel-Art-Girl-Xtreme-Retro.png)

Branim vam snad niekto pri tvorbe na moderne SOC pouzivat algoritmy a napady, alebo sa oreintovat na HW?

Nie, ESP-cko to genialne umoznuje.

Nojo, tak máte rád ESP, ale jiný důvod, proč ho použít na emulaci Z80 nevidím... To už můžu rovnou použít RP2040, resp. RPi Pico s vývojovou deskou za poloviční cenu, přímo procesor za třetinovou cenu...

Jakou logiku má psát "retro kód" v assembleru na čipu/desce s násobně vyšším výkonem, násobně větší pamětí, která mě vůbec nijak neomezuje a s plnohodnotným ekosystémem včetně kompilátoru z C/C++?

Z80 je procesor, na ktorý som napísal najviac kódu v asembleri. Najprv to bol Hisoft, neskôr Prometheus.
Oproti 8080A som najviac využíval relatívne skoky, samozrejme aj djnz (nad registrom B). Konečne som mohol písať realokovateľné rutiny bez opakovanej kompilácie. Využívali sme to hlavne pri vkladaní rutín do BASICovského riadku. Štandardný začiatok BASICu bol na 23755, prvý riadok za REM príkazom začínal na 23760, ale ZX Spectrum vedel začiatok BASICu posunúť, napríklad pri disketovej mechanike zo Skalice celý BASIC posúvalo otvorenie kanála, kde každý kanál posunul začiatok BASICu a buffer (512bytov) + nejaká réžia.
Index registre boli pomalšie, využíval som ich v špecifických prípadoch. V tom čase som mal v hlave počet bajtov aj taktov procesora na každú inštrukciu a využíval som ich keď to bolo výhodnejšie pamäťovo alebo rýchlejšie. Bolo to celkom často. IX bol úplne voľný, používal ho tuším iba HISOFT Pascal na lokálne premenné, ale IY som mohol využívať iba pri zakázanom prerušení, prípadne keď som prerušenie obsluhoval ja a keď som vedel, že už sa program nevráti späť do Basicu. Inak som ho pri návrate musel vrátiť.
Staré zlaté časy. Ďakujem za článok.

Registr IY používá Sinclair BASIC k indexování svých proměnných. Když program ve strojáku nezakáže na začátku svého běhu přerušení instrukcí di, tak poběží režim IM1 pro obsluhu klávesnice a to je ten důvod, proč nelze IY používat s povoleným přerušením. Se zakázaným lze, jen je potřeba před povolením vrátit do registru IY adresu 23610.

Záleží na programu, většina programů asi přerušení zakazuje, resp. používá IM2 (pro přehrávání hudby na AY např.), jen málo programů spoléhá na obsluhu klávesnice pomocí Sinclair ROM. Ale existují.

Další registr, který je dobré při návratu do BASICu zachovat, je sekundární HL.

Samozrejme s registrom IY je to tak. Nie vždy ale využívali na systémové premenné IY, takže sa premenné nedali presunúť. Dôvod bol jednoduchý. Napríklad na načítanie 2-bytovej hodnoty do HL využívali:
LD HL, (ADRESA) - zabralo 3 byty a trvalo 16 taktov
LD L,(IX +0)
LD H,(IX+1) - tento kód zabral 6 bytov a trval 2x19 taktov.
Osobne som často využíval IM2, jeho súčasťou bola väčšinou obsluha klávesnice cez ROM. Samozrejme registre som mal vtedy v poriadku.
Ak si dobre pamätám, tak v HL' bol uložený vrchol kalkulátora Spectra (RST#28).
Všetko je to už moc dávno, môj poslený počin bol že som si v 90-tych rokoch pripojil vyradenú klávesnicu. Bola to nejaká Consul, mala klasický DIN(5-kolík) a obsahovala tuším 8048. Bola pripojená na jeden pin 8085, nejaký riadiaci signál mi spustil nemaskované prerušenie a obsluha bolo pár riadkov v assembleri.
Samozrejme som mal "opravenú" ROM ktorá to umožňovala, nepoužíval som magnetofón (mal som D40(5 1/4') a bokom pripojenú ďalšiu 3,5' mechaniku a nehral som s ňou hry. Klávesnica bola na písanie kódu, prípadne textu a podobne.

Díky!

O tom, jak vypadal dobový vývoj pro ZX Spectrum (konverze R-Type) a jaké poměry vládly v britském herním průmyslu koncem osmdesátých let, se rozepisuje Bob Pape ve skvělé knize: It's Behind You: the making of a computer game.

K dispozici ke stažení zde: https://bizzley.42web.io/download.html

Stručný popis knihy: https://www.abclinuxu.cz/blog/squeaker/2018/11/hernim-vyvojarem-koncem-osmdesatych-let

Diky Pavle za doplnění.

Tyjo docela drsny a zrovna u Activision, kteri zacinali jako ciste nadseneckej SW house (kdyz utekli od Atari).

Activision nebyl jeho přímý zaměstnavatel, ti si pouze zadali výrobu u dané "seriózní" společnosti. Ale i u nich to vypadalo všelijak...

Dakujem Pavle,
nadherny clanok, pochopitelny aj pre cisteho ZX usera ako som ja :)
Chcem sa opytat ci by si nebol ochotny pripravit clanok o naprogramovani jednoduchej hry na zx spectru bez grafiky (staci pouzit ascii) napr. nieco ako Space invaders s 1 invaderom a 1 raketou ktora vie strielat? Pripadne s miestom na experimentacie a pod.

Urcite by som sa do toho pustil.

Diky. Zkusim to dat dohromady. U Atari 2600 i NESu jsme se prakticky k necemu podobnemu dostali, tak tady by to taky slo,

Jak se prosím jmenuje ta hra na obrázku 11? Bych si chtěl zase zahrát, ale nemůžu si vzpomenout.

Highway Encounter
https://worldofspectrum.org/archive/software/games/highway-encounter-vortex-software

btw to predelali i pro osmibitove Atarko a vypada to dost dobre i v porovnani s originalem https://a8.fandal.cz/detail.php?files_id=7619

(co mi na Atari chybi, jsou Filmation hry, predelana je asi jen Knight Lore, a taky skvela a hodne nedocenena Nether Earth by se sikla)

Já jsem se na Spectru vyučil. Používal jsem assmbler, bohužel už si nepamatuju jméno, který měl na obrazovce myslím 42 sloupců místo 32. Vypadalo to mimochodem výborně. Font (8 bytů na znak) by sežral docela dost vzácné paměti, tak jsem to disassembloval, a oni měli 1 byte na znak. Byla to bitová maska, který sloupeček bitů z ROM fontu se použije a který ne. Použilo se 5 z 8. Potom byl skvělý debugger od Aleše Martiníka, takový předchůdce dnešní virtualizace, schoval se myslím nad RAMTOP, jestli si dobře vzpomínám, vyvolával se dvěma shifty. Uměl spustit i boot Spectra, a nebylo to zase tak drasticky pomalé, jak by se mohlo zdát.
Jinak jsem autor Lady Copy, pokud to někomu něco řekne, a taky jsem portoval zde již zmíněnou hru Highway Encounter na Sharp MZ-800. To byl docela boj, protože nebylo snadné rozeznat kód a data, a videodata byly průšvih, protože Sharp a Spectrum měly naopak bity ve videoRAM (jeden měl bit 7 vlevo a bit 0 vpravo a druhý naopak). A pak se ta hra musela hrát přes všechny úrovně, aby se zjistilo, že se všechno zobrazuje správně. Noční služby jako pomocník dozorčího na městské vojenské správě Praha (dnešní hotel Esplanade), tlustý sešit a propiska, asi tak rok 1986...

O pár desítek let opožděné díky, Lady Copy jsem používal jako kluk a obdivoval, jak se nahrával do obrazové paměti a schopnost kopírovat věci, které jiné kopíráky nezvládaly.

Hezky je to zdokumentované zde:
https://spectrumcomputing.co.uk/alt/8326/ZX-Spectrum/Lady_Copy

njn, nostalgia, diky :)

K tej pamati, mozno by sa hodilo spomenut aky sposobom bola "pomalsia". Z hladiska procesoru bola stale rovnako rychla, len v okamihoch ked sa ULA a Z80 dostali do kolizie na adresnej zbernici pre rozsah 4000-4FFF, tak zastavila procesoru hodiny, cize procesor ani tak nezpomaloval ale skor vynechaval. Preto boli kriticke rutiny mimo video pamat. Ak totiz do tejto pamati ukazoval aj citac instrukcii, tak zmeny v casovani sa stavali dost nepredvidatelne.

Jj dostaneme se doufam i k tomu, stejně jako k funkci portů ULA atd. Zajimave by bylo konecne vysvetlit, kdy a jak presne se updatuje registr R.

8. 2. 2023, 14:33 editováno autorem komentáře

Refresh register, inkrementuje sa ked procesor siahne do pamate pre opcode alebo prefix.

no ano, ale potom tam mame LDIR a podobne instrukce, ktere vlastne porad (?) nacitaji svuj opkod, jestli to chapu dobre (proto jsou nerychle), tam se R taky zvysuje nebo cykluje?

(hmm vlastne si to vyzkousim v debuggeru, ale lidi od speccy o tom kdysi mluvili jako o nejake magii - sam jsem spis opravdu atarista, tam takove vychytavky jako DRAM nemame ;)

no,

LDI vykona tmp := (hl), (de) := tmp, de += 1, hl += 1, bc -= 1, xf := [tmp + a].1, yf = [tmp + a].3

LDIR vykona LDI, a ak je bc rozne od nuly, tak nastavi pc sam na seba (dekrementuje ho o 2). Je to vlastne blokove kopirovanie pamati src adresa v HL, dst adresav DE, pocet bajtov ktore sa skopiruju je v BC.

LDD a LDDR robia v podstate to iste len sa HL a DE dektementuju, cize sa kopiruje pospiatky.

A ano R sa inkrementuje, PC sa znizi o 2 a nacita sa znova LDIR.

Pomale su preto ze zastresuju viacero operacii, ked sa to ale rozpise do instrukcii, tak je to stale rychlejsie.

Ked tak je to dobre vysvetlene v knizke Bity do bytu, L. Zajicek strana 51.

8. 2. 2023, 19:01 editováno autorem komentáře

V kapitole The R Register je to popsáno: https://worldofspectrum.org/faq/reference/z80reference.htm

Více detailů zde ;-)
http://www.visual6502.org/JSSim/expert-z80.html
https://www.righto.com/2014/10/how-z80s-registers-are-implemented-down.html
https://github.com/gdevic/Z80Explorer

Btw, ak najdete niekde v zozname instrukcii zapis alebo citanie z registra R, tak to neznamena R register ale zastupny znak pre normalny register (a, b, c, d, e, h, l).

jj to je jasny :)

Přesně - byl rozdíl mezi tím, jestli program ze zpomalené paměti jen bere data, nebo jestli v ní program běží.

Během zpracování každé instrukce Z80 sáhne do RAM i několikrát. Běží-li program ve zpomalené RAM, tak běží "nepravidelně" a výkonově to velmi zhruba odpovídá 2.5 MHz? Nějak tak... rozhodně nevhodné i pro pípnutí na speaker.

Ale když program do zpomalené RAM jen sahá pro data, tj. většina přístupů do RAM (čtení instrukcí a jejich operandů) je stále v rychlé, tak se ze zpomalené RAM dají přehrávat i audio samply. Zpomalení se na zvuku projeví, zní to trochu zkresleně, ale není to katastrofa. V případě mnoha konverzí Amiga MODů pro DA převodník to taky jinak nejde, protože ZXS128k má zpomalených 64kB (čtyři 16k stránky, do dvou je mapovaná videoram) a 64kB je na samplovanou hudbu málo.

Zpomalení však neznamená, že by se tam programy neumísťovaly. Musely, ZX Spectrum 16k jinou než zpomalenou RAM nemá, celá RAM, kterou má k dispozici je právě jen těch zpomalených 16kB od 16384 do 32767. Všechno pípání se tak musí řešit využitím podprogramů v ROM (stejně jako LOAD, SAVE a jiné časově náročné věci).

Velký chaos do toho pak vnesl Amstrad se svými modely +2A, +2B, +3, které mají zpomalené jiné paměťové stránky než originální ZXS 128k+ toastrack a šedá 128k +2 (která má sice taky cedulku Amstrad, ale konstrukčně se shoduje se 128k+ toastrack).

Pod linuxom je pro ZX spousta dalsich moznosti jak debugovat, i bez wine.

Pokud nevadi VSC, tak VSC + debugger plugin DeZog (ma vlastni vstaveny neuplny emulator ZX, nebo se muze pripojit na externi - aktualne nejlip asi s CSpect ktery je vsak closed source a potrebuje mono a neni taky uplne nejpresnejsi, spis se specializuje na emulaci ZX Next).

Nebo ZEsarUX (jeho UI mi sice nesedi, ale ma i debugger a milion dalsich veci a pocitacu ktere emuluje), Xpeccy ma taky vstaveny debugger.

V kazdem pripade bych jako assembler spis doporucil z00muv fork sjasmplus (v1.20.1), ktory jsem za poslednich par let dost opravil a vylepsil. Nenajdete ho v oficialnych repozitarich, ale git clone --recursive https://github.com/z00m128/sjasmplus.git && cd sjasmplus && make mi neprijde az tak slozite. :)

Nebo taky debuggovat stejně, jako na reálném hardwaru změnou barvy okraje, podobně jako na MCU, když podle situace blikáme LEDkou :)

ld a,barva
out (254),a

Se dá vecpat skoro kamkoli, když je potřeba vědět, že program tím místem prošel, jak zhruba dlouho běh trval (od změny, ke změně šířka pruhu) a pod.

V kombinaci s občasným krokováním disassemblerem (Devast+, nebo .mon v ESXDOSu např.) je to překvapivě často dostačující metoda. Alespoň pro jednodušší programy.

Do ZX-80 a možná i pozdějších existovala alternativní ROM, kde po zavedení naběhl jiný jazyk než BASIC. Byla tady o tom někdy zmínka, nemůžu to najít.
Doplněno: tuším že to byla speciální verze s Forth ;-)

9. 2. 2023, 16:54 editováno autorem komentáře

Neuveriteľné, že ešte v dnešnej dobe vychádzajú o ZX takéto kvalitné články.

Veľká vďaka za to!

Pred asi 10 rokmi som buildoval Pasmo2 do dll - potreboval som vygenerovaný "bytecode" aby som ho vedel rovno šlahnúť do pamäte. Vtedy som robil cross assembler pre ZXMak emulátor.
Prekvapilo ma, že pasmo je v repozitároch. Wau...
Teším sa na ďalší článok.

10. 2. 2023, 08:29 editováno autorem komentáře

a co trprve hra castle master 1 to byla pro me revoluce na zxspectru ;-)
a ted koukam ze to bylo i na amigu 1200