Přejít k navigační liště

Zdroják » Rozhovory » Martin Malý: Osmibity nemizí, podívejte se do MP3 přehrávačů

Martin Malý: Osmibity nemizí, podívejte se do MP3 přehrávačů

Články Rozhovory

Jak obtížné je vytvořit v JavaScriptu emulátor počítače? Jak se takový emulátor testuje? Co byl zač počítač Ondra? Jaké procesory se používaly v raketoplánech? Zeptali jsme se Martina Malého. A nezapomněli jsme ani na autíčka z PMD-85.

Martine, tys nedávno publikoval javascriptový emulátor PMD-85 a já se hned na úvod nemůžu ubránit otázce: Proč to vlastně děláš?

No stejně jako se Hillary nemohl ubránit otázce, proč vlastně leze na Everest – mě to prostě baví. PMD-85 byl první počítač, na který jsem si sáhl, a na kterém jsem napsal legendární nápis AHOJ velkými písmeny. A to v člověku zůstane. Stejně jako první první kolo, první auto, první hypotéka. Proto mám k PMD nostalgický vztah, i když jsem s ním dělal jen krátce, skoro dva roky.

Pak jsem přešel na ZX Spectrum, jako každý pořádný člověk v té době. Jenom zbabělci měli Atari. (smích)

Ano, takto vypadá Martin Malý na počítači ZX Spectrum

Martin Malý na počítači ZX Spectrum (stáhnout TAP soubor)

K PMD jsem se už nikdy nevrátil, ale přesto jsem si ten počítač za tu dobu důkladně osahal i na úrovni volání rutin z monitoru a na úrovni přímého zápisu do obrazovky, resp. do paměti, tam kde byl uložený obsah obrazovky, což mě bavilo, takže už od té doby vím, že PMD je poměrně jednoduchý na ovládání. Ale emulátor PMD vznikl jako vedlejší produkt toho, co dělám jako hlavní.

Hlavní?

Vytvářím online IDE pro vývoj (zatím ve veřejné alfaverzi) programů v assembleru pro osmibity. Assemblery existovaly už od začátku, i na ZX Spectrum sis napsal něco ve strojovém kódu, přeložil a spustil. Jenže ty assemblery i editory byly hodně spartánské a moc věcí neuměly. Třeba takové kopírování textu, jak jsme dnes zvyklí CTRL+C, CTRL+V, to prostě nešlo. Ani includy. Když jsi měl disketovou mechaniku, tak to už trochu šlo, ale s obyčejnou páskou to byla spíš parodie.

Takže je logické, že se později programy už vyvíjely na PC, kde je to pohodlné, rychle to přeložíš a dá se to i emulovat. A protože mám rád webové technologie, řekl jsem si, že nebude marné udělat vývojářské prostředí přímo do prohlížeče.

Navrhl jsem to tak, že můžu překládat kód pro různé procesory, konkrétně procesor 8080, Z80 a 6502. Teď dodělávám motorolský 6809 a další procesory není problém dopsat. Třeba od Atmelu – a budeš moci psát i pro Arduino. Ty starší assemblery jsou jednodušší, takže jsem zůstal u nich.

No a když už jsem měl IDE pro překlad, bylo by dobré si odzkoušet, co v něm vytvoříš. Tak jsem dodělal emulátor pro procesory. V něm si můžeš odkrokovat přeložený program a sledovat, jak se mění registry. A to už byl jen krůček k emulátoru celého počítače.

A tím byl?

Začal jsem s PMI-80, jeho displej ze sedmisegmentovek jsem nasimuloval pomocí tabulek.

Československý mikropočítač PMI-80

Československý mikropočítač PMI-80

To byl první emulátor. A když už bylo PMI, tak jsem řekl, že přidám canvas a vzniklo PMD-85.

Československý mikropočítač PMD-85

Československý mikropočítač PMD-85

A když už jsem měl emulátor PMD-85 s canvasem, řekl jsem si, zda už není použitelné webaudio. A bylo. A tak jsem měl PMD-85, co hraje.

Jistěže emulátory PMD už dlouho existovaly, pár jich je výborných, kupříkladu Martin Bórik s bratrem ze Slovenska připravili emulátor, který emuluje snad úplně všechno včetně disketových mechanik k PMD. To už není můj cíl, tam se dostat nechci. Mně stačí, když si někdo může sednout, napsat si jednoduchý program v assembleru, přeložit si ho a na emulátoru PMD-85 si ho i vyzkouší. A až pak si ho možná zkusí i na tom reálném PMD-85. Takže při psaní nemusí pracovat s kazetami, přetahovat data, všechno si může vyzkoušet přímo v prohlížeči.

Jak obtížné je programování emulátoru? Já si to představuju jednoduše, pár registrů procesoru, to bude nějaká datová struktura, výpis na obrazovku bude jen mapování paměti, pak ten zvukový výstup a nějaký časovač, aby to běželo správně rychle. Celkem jednoduché, jen strašná piplačka. Jak to vidíš ty, po tom, cos to absolvoval?

Kupodivu to ani piplačka není. Já nemám rád piplačku, když člověk sedí a píše furt dokola ten samý kód. Správně líný programátor si to zautomatizuje. Třeba takový procesor 8080, u něj třeba čtvrtinu instrukcí činí jen přesuny mezi registry. Nebudeš je psát znovu a znovu, napíšeš si v PHP jednoduchý skript, který ti ten JavaScript vygeneruje. Pak vidíš osm instrukcí, které dělají to samé, liší se jen v registru, tak si je taky vygeneruješ.

To už máme metaprogramování.

Přesně! Ty si naprogramuješ generátor, který ti vytvoří kód emulátoru pro procesor a…

Emulátor 6502 jsem napsal, u 8080 jsem přepsal a poladil to, co bylo pod volnou licencí, pro Z80 ho taky asi psát nebudu, vezmu nějaký pod licencí MIT a hotovo.

Vzpomínám, že jsi psal na Twitteru, když si emulátor dokončil, tak ti v něm neběžel program, tuším autíčka. Cos pak dělal? Máš svůj procesor, máš nějaký cizí kód, jak hledáš, kde je problém?

Naprosto empiricky. Ale co autíčka, nejhorší byl Basic G! Když jsem totiž emulátor zapnul, napsal jsem BASIC G a on se objevil. To byla obrovská radost, protože to znamenalo, že mi to celé funguje. Zobrazování funguje, časování funguje, přístup do paměti funguje, všechno to funguje. Pak jsem ale napsal 10 PRINT 1 a objevil se SYNTAX ERROR, což znamenalo, že to nefunguje.

Přemýšlel jsem, zda si to pamatuju dobře. Zda se opravdu psalo 10 PRINT 1 – a taky že psalo. I mezery jsem měl, kde měly být. Všechno jsem měl, jak mělo být. Ale nefungovalo to. Chvilku jsem se koukal do zdrojáků a sledoval, co se kde děje. On ten Basic není až tak úplně snadný. I když máš výpis, který je dokumentovaný, tak to stejně není úplně průzračné, aby sis sedl a hned viděl, jak to funguje. Potože když to psali, tak to potřebovali dostat do co nejmenšího prostoru, takže je tam hack na hacku. Po chvíli studování jsem si říkal, že je jasně problém v emulaci procesoru, otázka byla: kde přesně.

A tak jsem si naprogramoval standalone debugger, kde jsem si jel jednotlivé intrukce, stáhl jsem si testovací program, který vyzkouší všechny instrukce procesoru a když je nějaká špatná, tak to nahlásí. Pomocí něj jsem jel a dobrý, dobrý dobrý a tahleta instrukce dělá potíže. Koukl jsem do zdrojáku a opravdu, prohodil jsem dvě hodnoty. Začlo to fungovat. Napsal jsem 10 PRINT 1 a RUN a fungovalo to. To jsem už spustil i ta autíčka.

Tak jsem to poslal Martinu Bórikovi, ať se na to podívá. Pochválil mi to, ale 3*3 mi prý vyjde 9.04688.

Znovu jsem testoval všechny instrukce, objevil další chyby, opravil je, ale nepomohlo to. A ještě jednou. Zoufalství největší. Přepsal jsem celý algoritmus pro dekadické upravení po sčítání instrukce DAA, to taky nepomohlo. Nakonec jsem přišel na to, že jedna instrukce nastavuje na onom křemíkovém procesoru příznaky jinak, než bylo popsáno v šesti dokumentacích, které jsem měl k dispozici. Až v sedmé to bylo správně. Prohodil jsem příznaky a začalo to fungovat.

Dokumentace už je taková. V datasheetu někdy možná někdo udělal chybu a ta se šíří a šíří a šíří. Ti, kdo s tím tehdy pracovali, už empiricky věděli, že to je jinak, jen se ta informace tehdy šířila spíš nahodile. Dneska je toho na internetu spousta, ale jeden opisuje od druhého, takže dojít k prapůvodnímu problému je docela těžké. Naštěstí nadšenci, právě typu pánů z RM týmu, mají originální čipy stále funkční, mohou otestovat jejich chování a výsledky dávají k dispozici na web.

Takže tys to zprvu neměl dle TDD a unit testy na všechny instrukce?

TDD samozřejmě používám, na většinu součástí IDE mám jednotkové testy. Až tady jsem si zbaběle řekl, že to napřed udělám a až pak napíšu pangram, což je program, který používá všechny instrukce. V tu chvíli jsem byl ale ponořen v JavaScriptu a nechtěl jsem nad tím pangramem v assembleru přemýšlet.

Třeba když jsem dělal assembler, tak k němu mám testovací zdrojové kódy, a jak udělám nějakou úpravu assembleru, znovu je přeložím a musí mi vyjít stejný hexasoubor jako je ten referenční. Až budu ladit příští procesor, pojedu takhle od začátku, protože to ušetří spoustu práce.

Problém je, když je ten test nedokonalý. Kdybych ho napsal já podle dokumentace, kterou mám, tak ho napíšu špatně – a on projde. Takže je to TDD, ale stejně testuješ na reálných starých hrách s autíčky apod.

Trápily tě rychlostní optimalizace? Anebo vše běželo dostatečně rychle?

Popisoval jsem to v nedávném článku, měl jsem problémy s rychlostí ve Firefoxu. Já normálně používám Chrome, v něm vyvíjím, ten je téměř ve všem, co dělá, extrémně rychlý. Takže tam nenarazíš.

Čistě pro pořádek, v emulátoru je smyčka, která běží 50krát za vteřinu. A 50krát za vteřinu se provede zhruba 40 000 kroků procesoru (toho virtuálního). Když si spustíš v prohlížeči profiler, je to jen takové blik, blik, skoro nic, je to okamžité.

U emulátoru PMD-85 se obrazovka vykresluje do canvasu. Pro to existuje standardní postup, který jsem našel v článku na Zdrojáku, který jsem shodou okolností sám napsal: vezmeš canvas, vytáhneš z něj bitmapu, tu dáš do pole, v tom poli změníš hodnoty a výsledek vložíš zpátky do canvasu. A tohle Chrome zvládnul. IE taky. Ale ve Firefoxu to bylo pomalé. Tak jsem postupně optimalizoval. Klasická pole jsem nahradil bajtovými poli, ta už jsou podporovaná ve všech prohlížečích, takže se dá použít místo klasického Array jako buffer. Je to takový návrat ke kořenům, založíš pole s 65536 prvky typu byte a je to opravdu 65536 bytů, nejsou u toho služební věci jako u normálních polí. To bylo první zrychlení, ale nepomohlo. Tak jsem zrychloval ještě dál, ale pořád to nepomáhalo. Nakonec jsem si řekl, že problém bude pravděpodobně v canvasu a taky že ano. Firefoxu to, co mělo trvat 1/50 vteřiny, trvalo 6/50 vteřiny, pak byla pauza a pokračovalo se dál, to bylo nepoužitelný.

Googlil jsem a první, co vypadlo u těchto operací, byly zmínky: terrible performance. Nakonec jsem použil bajtové pole, ale speciální typ určený pro práci s canvasem, v něm pro každý bod nemusíš dělat čtyři přiřazení RGBA, ale vystačíš si s jedním přiřazením, konstanty jsem si všechny předpočítal před cyklem a problém s výkonem byl vyřešen. Nebyla to ale optimalizace vlastní emulace, jen grafického výstupu.

Jak si získal zdrojové kódy tehdejších programů? Musel jsi něco importovat ze starých pásek? Nebo se dá vše najít na Internetu?

Já bych strašně rád importoval z pásek, ale víš, jaký je problém koupit kazetový magnetofon? Zkoušel jsem to na Aukru, ale nic nemělo dobrý výstup. Pásky mi leží ve skříni, občas je přetočím, aby se trošku hnuly a buď seženu kazeťák, nebo je nechám a jednou se třeba objeví technologie, která dokáže staré pásky rekonstruovat, jinak je budu muset oželet. Takže odpověď zní ne, všechno jsem našel na internetu.

Můžeme čekat, že se brzy celý projekt objeví na GitHubu, bude možné si ho forknout a třeba i přidat emulaci dalších procesorů?

Ano, tam směřuji. Nechci z toho dělat úplně komunitní open source, protože bych asi nepřežil dohady s dalšími komentátory/přispěvateli. Spíš zvolím takový ten přístup source available.

Rád bych ale zdokumentoval rozhraní, kde se můžeme potkat. Emulace procesoru je v podstatě javascriptový objekt, který vystavuje několik metod. Stačí je popsat, a když je implementujete, můžeme fungovat dohromady. Podobně by šlo vytvořit moduly pro další assemblery. Takže projekt rozhodně půjde na GitHub. A hlavně dokumentace, jak přidat další modul, jak si udělat vlastní procesor apod.

Tys kdysi napsal článek API je nové open source, to je tvůj zvláštní, ne úplně zaběhnutý, přístup v open source světě?

Protože já open source svět respektuji, rozumím pohnutkám oněch lidí, ale narážím na velké množství fanatiků, kteří jsou posedlí tím, že open source je jediné správné řešení. A dost často to spojují s tím, že open source = musíte být nekomerční. Pardon, já potřebuji platit složenky a hypotéku.

Je mi sympatičtější zveřejňovat pod licencí BSD, MIT apod. Tam říkám, že tohle jsem udělal já a opravdu je to open source, dělejte si s tím, co chcete. Nevyžaduji po někom, aby to svoje také otevřel, aby to odvozené vrátil zpět nějaké komunitě. Z tohodle hlediska je pro mě ta ideologie GNU hnutí nepříjemná.

Když narazím na věc, která je uzavřená, je pro mě popsané API mnohem cennější než přístup ke zdrojovým kódům. Jsem třeba rád, že můžu použít např. API od Google map, protože je dokážu integrovat a mě nezajímá, jestli Google otevře zdrojáky. Po pravdě řečeno, i kdyby je otevřel, jsou mi k ničemu. Pro mě je mnohem cennější, že s tím můžu pracovat, nemusím se měsíce bořit ve zdrojácích někoho jiného a něco tam dopsat, když to můžu udělat přes API. A to jsem vzal Google jen jako příklad, platí to pro libovolnou jinou firmu.

Zmiňuješ, že základem tvého projektu je dvouprůchodový assembler. Proč dvouprůchodový? Co to znamená?

Ty jsi holt mladý chlapec a nepamatuješ staré assemblery. (smích)

Assembler jako takový je velmi jednoduchý jazyk, nemá žádné složité syntaktické konstrukce, lexikální jednotkou je řádek, na něm vždy jen jedna instrukce s přesně danou syntaxí. Před ní může být návěstí, za ní může být poznámka, to je celé.

Když takový program sestavuješ dohromady, u starých osmibitů se programy překládaly na konkrétní adresy v paměti. V programu bylo použito symbolické návěstí, např. jako jump ZACATEK, ale do kódu bylo nutné zapsat konkrétní adresu. A když se skákalo dopředu, ještě si nevěděl, na jakou adresu ten skok bude. Dělá se to tak, že napřed projdeš celý kód jednou a vše, co můžeš, přeložíš. Až při druhém průchodu, kdy už víš, jak je která instrukce dlouhá, a na jaké adrese bude jaké návěstí, doplníš skutečné adresy. Takže proto to jsou dvouprůchodové assemblery. Podrobněji jsem to rozepsal v článku Trocha assemblerové teorie. Ten je součástí mého kurzu osmibitového assembleru, který jsem vytvořil, vlastně jako vedlejší produkt toho IDE, na doméně strojak.cz.

V podstatě to ale není zcela přesné, můj assembler je totiž dvou a půl průchodový, protože má před sebou ještě preprocesor. Před vlastním překladem se zpracují a rozvinou makra použitá v kódu a také všechny includy, teprve pak se spustí onen klasický dvouprůchodový assembler. Na strojích s lepší pamětí, než je kazeta, tedy třeba CP/M nebo všechny dnešní, se používá rozdělení na assembler a linker, kde assembler udělá vlastně ten první průchod (do objektového kódu) a až linker ten druhý. S páskou by to bylo nepohodlné.

Já jsem dobu osmibitů považoval za dávno mrtvou a překvapilo mně, že jsou skupiny lidí, kteří třeba pro ZX Spectrum stále programují nové hry. Jaká tam může být motivace?

Motivace je úplně jednoduchá, je to prostě jejich koníček. Někdo sbírá známky, jiný staré mince, někdo si hraje s normálním počítačem další si zaleze do své dílničky a vytáhne ZX Spectrum, které je dnes většinou ve stádiu veterána. To znamená, že se o něj musí starat, trošku ho opečovávat a vylepšovat. Je fascinující, že věci, o kterých před 30 lety snil, že by k tomu měl třeba opravdu velkou paměťovou kartu, tak si je dnes už k tomu můžeš připojit. I dneska k ZX Spectru vznikají nové periferie. V takové periferii je třeba procesor, který má větší výkon než 26 ZX Specter a slouží jen k tomu, abys do něj zastrčil SD kartu a nahrál do paměti. Takže pokrok jde dopředu a spousta lidí používá nové technologie proto, aby si s těmi starými užili.

Pozn.: Zhruba v době konání rozhovoru byl zveřejněn zajímavý kickstart projekt Bluetooth ZX Spectrum.

Tehdy když člověk programoval, tak si opravdu sáhnul “na každé hradlo a tranzistor”. Počítače tehdy byly hrozně jednoduchý. Takové ZX Spectrum, když pomineš paměti, bylo jen nějakých 8 integrovaných obvodů.

A byla i kompletní dokumentace, takže člověk si ho teoreticky mohl ze součástek postavit.

Pozor, to nebyla.

Já měl Didaktik M a s ním dodávali kompletní schéma.

To sice ano, jenže když se do něj podíváš, tam byl procesor Z80 a pak tam bylo něco, co mělo 40 vývodů a jmenovalo se to ULA, což byl zákaznický obvod, který si Sinclair tehdy navrhl a nechal vyrobit u firmy Ferranti. A tenhle obvod nebyl dokumentován, resp. jeho dokumentace nebyla veřejně k dispozici. A tak vznikaly různé pololegální klony. Ono se vědělo, jak ten obvod pracuje, našla se řada šikovných lidí, kteří odměřovali pomocí osciloskopu, co se uvnitř děje, a sestavili vlastně funkční ekvivalent. A až před nedávnem, jsou to tuším 2 roky, vyšla konečně knížka, jejíž autor opravdu ULA rozebral do posledního klopného obvodu a přesně popsal, jak funguje. Takže si můžeš konečně opravdu přesně naemulovat to, co tehdy v tom siliconu bylo.

Až budeš mít své IDE hotové, plánuješ pro osmibity vytvořit nějaký užitečný projekt?

Něco rozhodně ano. Třeba můj zaměstnavatel (IHNED.cz) měl před nedávnem reklamu, kde byl počítač ZX Spectrum a nápis Na tomto zařízení si naše noviny nepřečtete, ale na všech ostatních ano. Což je jasná výzva! Napsat program, který dokáže přečíst Hospodářské noviny na ZX Spectrum. (smích)

hn-spektrum-480x300_spir

Ale chtěl bych hlavně zkontaktovat lidi, kteří pro tohle prostředí stále ještě vyvíjí a dát jim tuhletu novou možnost. A kdyby se můj nástroj téhle komunitě líbil a byl jí k užitku, bylo by to pro mě asi zajímavější, než abych si já sám něco psal.

Takže to je tvůj plán? Vybudovat si svou osmibitovou komunitu?

Ano, já mám, moc se o tom neví, blog o součástkách a mikroelektronice se čtenářskou základnou v řádech tisíců až desetiticíců lidí z celého světa. Těm jako prvním nabídnu tohle IDE a oni se třeba chytnou. Je pravda, že moc lidí ze světa PMD-85 nezná, ale chystám i další emulátory, další jednodeskáče, Altaira 8800, KIM 1, IQ 151…

A nejen to, mě třeba fascinuje počítač Ondra, což byl český pokus udělat něco jako ZX 81. Tehdy Eduard Smutný, který udělal počítač JPR- 1 a potom SAPI-1, navrhl tenhle malý a jednoduchý počítač pro svého syna, aby se s ním naučil programovat. Vzniklo ho pár set kusů a je to dnes poměrně zajímavá rarita.

Takže osmibity postupně všechny mizí…

Pozor, osmibitové procesory nemizí. Já měl třeba před pár lety MP3 přehrávač, který měl nějaký čip na dekódování MP3 a vedle něj druhý čip, který se staral o komunikaci s ovládacími tlačítky, a to jsem si zjišťoval, to byla Z80.

To se prosím zjišťuje jak?

Prostě jsem to rozebral. Uvnitř byl čip od známého výrobce, ten jsme si dohledal a byla to vylepšená Z80. Ta se stále vyrábí.

A taky slavný procesor 6502 se dodnes vyrábí a používá. To protože ty procesory jsou jednoduché a predikovatelné, v každou chvíli víš, co se v nich děje. Ostatně, to je i důvod, proč ve vesmírných lodích a raketoplánech nebyly použité nové procesory a vystačili si s 8085, protože ty procesory jsou robustní, poměrně odolné, nerozhodí je tak moc vesmírné záření a jsou levné. Když máš udělat zařízení pro nějakou jednoduchou činnost, je jednodušší použít 8bitový procesor nebo jednočip, který přijde ve vetších sériích na 20 centů za kus, než tam dávat opravdu složitý procesor. Takže osmibitové procesory neumírají a dnes je pro ně mnohem víc aplikací a implementací než tehdy.

Teď zažíváme takové menší retro, poslední dobou se objevují zařízení jako Arduino, což může přilákat i dnešní mladé programátory

To bylo podobné i v 80. letech. Tehdy byl počítač moc drahý a Velká Británie díky iniciativě BBC a ministerstva školství vypsala tendr na počítač do škol. Z toho vzešel tehdy známý BBC Micro.

Pozn.: Historie počítače BBC Micro a jeho soupeření se ZX Spectrem je pěkně ztvárněna ve filmu Micro Men s Martinem Freemanem v hlavní roli.

Byl levný, použitelný v domácnosti a děti se na něm mohly začít učit. Kdyby ti dnes bylo 10-12 let a chtěl by ses naučit pracovat s počítačem a programovat ho, tak nemáš moc možností. Prostě táta má doma PC, na něm nějaké hry, Internet, Facebook, ale nemáš v základu třeba BASIC.

Před časem jsem se o tom bavil s Patrickem Zandlem, který má dospívající dcery a ty zajímalo, jak počítač funguje. Dlouho nemohl najít nic vhodného, k čemu by je posadil a nechal je vyzkoušet, jak se s tím pracuje. Nakonec našel Scratch, který vznikl na MIT, v něm je třeba kočička, která jde doprava a ty zařídíš, aby před zdí zahnula doleva apod. A la robot Karel nebo Baltík. Ale to už jsi odstíněn od elektroniky. Když sis tehdy koupil ZX Spectrum a chtěl sis vyrobit joystick, chvilku sis hrál se spínači a bylo to jeden na jednoho – člověk vs počítač. Dneska jsi už odstíněn spoustou vrstev.

Raspberry Pi vzniklo z podobného důvodu, opět si v Anglii někdo usmyslel, že by bylo fajn mít levné zařízení, které si může pořídit dospívající kluk, začne si s ním hrát, rozbliká si ledku a třeba ho to začne bavit.

Ale to už jsme se od osmibitů posunuli, v Arduinu je 8bitový procesor AVR a v Raspberry Pi je 32bitový ARM procesor. Ale našel bys i kity s osmibitovými jednočipy.

Ten můj emulátor je do určité míry modulární, takže si teoreticky můžu vzít displej z PMI, klávesnici z PMD, poskládat si to dohromady a vytvořit tak nový počítač, který vůbec nikdy neexistoval.

Teď jsem udělal debugovací modul, ten umožňuje live ladění, což tehdy nebylo bez extra hardware možné, totiž že zmáčknu tlačítko, v tu chvíli se onen emulovaný počítač zastaví a já si osahám registry. A můžu to pak trasovat a debugovat za běhu.

To je úžasný!

A když zjistím, kde hledaný problém je, tak to dál spustím a emulátor zas jede původní rychlostí. Šlo to samozřejmě i tehdy, ale vždy to běželo na tom procesoru, takže nešlo doopravdy “zastavit”.

Tak tohle je komfort, který mi u osmibitů chyběl. Jsi první, kdo něco takového dělá?

První určitě nejsem, emulátory existovaly od začátků počítačů. Co se týče online, vím že existuje třeba online assembler pro Z80, jeho autor ho udělal podobně, jako vznikala má první verze. Máš HTML editor a když dáš compile, vše se odešle na server. Na tom běží standardní linuxový překladač, který ti vrátí výsledek.

To bylo pěkné, ale nelíbilo se mi, že když chceš něco includovat, musíš pak posílat řadu souborů, tak jsem to nakonec napsal celé v JavaScriptu. Z těch stávajících online assemblerů mám pocit, že slouží většinou k tomu, když máš zdroják, potřebuješ ho přeložit a nechce se ti stahovat compiler. Tak ho tím assemblerem přeložíš a tím to končí.

Pak vím, že existuje obdoba jsFiddle, takové úložiště kódu, do kterého napíšeš kus kódu v nějakém jazyce, ten se na serveru přeloží a vykoná, od Algolu po Pascal a myslím, že podporuje i assembler x86.

Ale to jsou všechno takové ojedinělé věci. Myslím, že spojení IDE, debuggeru, emulátoru a nějakého pozadí, který umožňuje pracovat se soubory, to celé v prohlížeči, to jsem zatím nikde neviděl, takže možná jsem první.

Děkuji za rozhovor a přeji hodně zdaru.

Komentáře

Subscribe
Upozornit na
guest
19 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
A.

Ne Squeak, ale Scratch ;)

Martin

V Arduinu není 16 bitový procesor, ale 8 bitový. Atmel totiž dělá pouze 8 bitové a pár 32 bitových jednočipů řady AVR. Jediné, co je v procesoru 16 bitové, je čítač (counter).

adent

Moje chyba, za kterou se omlouvám. Smotal jsem to dohromady. Jasně, AVRka jsou osmibitová.

Tomáš Smutný

Jsem bratr, dvojče Eduarda Smutného, který mi bohužel před 20 lety zemřel. Děkuji že jsi vzpoměl.

adent

Dobrý den, zprávu o smrti Vašeho bratra jsem zachytil, je mi to líto, byl pro mne opravdu tím, kdo mne postrčil k počítačům. Ale já si pamatuju i Vás, Vy jste psal pro JPR MikroBASIC, že? Právě teď o víkendu budu rozcházet emulátor JPR-1, tak jestli se podaří, dám vědět.

J-dro

Pěkný rozhovor, díky, tu práci tedy obdivuji :)

Jestli si to dobře pamatuju, tak ladění běžícího programu by bylo možné na ZX Spectru vyvolat pomocí NMI? Což se tuším dalo řešit připojením tlačítka na sběrnici (tuším pravda jen mlhavě), nebo to bylo složitější?

Podmínkou by bylo, že debugger by musel být v paměti spolu s programem a po vyvolání nemaskovatelného přerušení by CPU přeskočil na adresu debuggeru. Ještě mám pocit, že tabulky pro adresaci obsluhy NMI byly poněkud zběsilé – alespoň, co se týkalo Didaktiku M, na který se mi práší už cca 20let, co jsem ho nepustil…:) Zběhnul jsem holt k silnějším strojům…:)

adent

V originálním Spectru byla v ROMce chyba, která způsobila, že NMI buď nedělal nic, nebo RESET. Určitě by šlo připravit upravenou ROMku, která by obsahovala debugger, spouštěný NMI (a možná taková i existovala, já o ní nevím, v oblasti alternativních ROMek nejsem moc znalý, znám jen pár, co rozšiřovaly BASIC a editaci).

S těmi tabulkami – to si asi pletete NMI a přerušení v interrupt modu 2 (IM 2), tam se používaly tabulky, aby si člověk mohl obsloužit přerušení ve vlastní režii.

J-dro

Díky za upřesnění – pravda, popletl jsem si to s IM2… 20 let je 20 let…:) Zajímavé, o této chybě jsem nevěděl, sám jsem nikdy NMI v reálu nezkusil použít – s přerušeními obecně jsem experimentoval jen krátce…:)

Co jsem k tomu našel, je toto: „Adresa obslužné rutiny NMI (výkonné) musí být uložena v systémové proměnné na adresách 23728 a 23729 (5CB0H a 5CB1H).“ (http://zxmagazin.80.cz/2000_06_01_archive.html) Takže se správnou ROM by to mělo být poměrně jednoduché? :) A navíc obsluha NMI + debugger by klidně mohl být i v RAM – což by ale fungovalo pouze s programy, kde bychom měli jistotu, že nějaká (a dostatečně velká) oblast paměti bude volná.

Opět trochu vařím z vody, ale mám pocit, že disketová mechanika D40 používala k uložení snapshotu RAM na disketu právě NMI – kamarád měl D40 u svého Didaktiku Gama – takže minimálně v této konkrétní ROMce asi ta chyba už nebyla (zdá se, že se nepletu, podle informací z http://ci5.speccy.cz/docs/d40d80/)

adent

Ten popis je v pořádku, to ano, ale funguje to s ROM, co má opravenou chybu. Debugger může být klidně v RAM, ale ani tak nezaručí to, co zvládne emulátor – opravdu zastavit procesor, přitom ukázat stav jeho registrů, a pak třeba krokovat. (Samozřejmě, emulátor má zase spoustu jiných nevýhod.)

Disketová mechanika D40 (a další podobná zařízení, jako třeba ZXIF1 nebo Betadisk) měla svou vlastní ROMku, která se v nějakém konkrétním případě, když procesor prošel určitou adresou, přimapovala místo té původní. U D40 to bylo (a teď já lovím z paměti) právě na adresách 8 (obsluha chyby) a 0066h (NMI). To nebyla „opravená ROM“, to byla „úplně navíc ROM“ a byly v ní uloženy právě rutiny pro obsluhu diskety, pro načítání a zapisování, pro rozšíření těch BASICových příkazů…

EC1045.01

Omluvte mou cestinu
Nazev SAPI (Sistem Automatickeho Porizovani Informaci) vznikl az v dobe vyjovoje JPR-1 (v te dobe jiz ekzitovalo nekolik minipocitacu s nazvem JPR a to JPR-12, JPR-12R, JPR-80, …) do te doby procesorova deska a vlastni pocitac meli stejny nazev tj. JPR-xx (systemy byli vice deskove). Po zavedeni nazvu SAPI-xx doslo formalne i k prejmenovani vsech stavajicich minipocitacu JPR-xx na SAPI-xx a nazev JPR (Jednotka Programoveho Rizeni) bila ponechana jen procesorove desce. takze:
JPR-1 = SAPI-1 (8bit 8080A pozdeji Z80, mam pocit ze JPR-1 jako pocitac se nikdy oficiane neprodavalo)
JPR-12 = SAPI-12 (12bit na TTL)
JPR-12R = SAPI-12R (16bit na TTL rozsirena verze SAPI-12 klicka jak obejit omezeni RVHP pro CSR kdy mohla delat pouze minipocitace do 12bit, SSR do 16bit)
JPR-80 = SAPI=80 (8bit na 8080A)

jinak hezky clanek

pokut nekkoho zajima „zelezo“ starych CS minipocitacu zde http://www.sapi.cz a zde konkretne SAPI-1 http://www.sapi.cz/sapi/sapi.php

adent

Ano, je to tak, díky za doplnění. Jenom dodám, že JPR-1 s procesorem Z80 bylo označováno jako JPR-1Z. Mimochodem, zrovna dneska odpoledne jsem udělal první verzi emulátoru SAPI-1 (v sestavě JPR-1, AND-1, ANK-1, REM-1 a DSM-1) a Vám patří velký dík za materiály na Vašich stránkách, jinak bych ručně přepisoval MIKRO BASIC EPROM ještě teď :) Ten emulátor je k dispozici na http://www.asm80.com/jpr.html – ale jak říkám: je to alfaverze, není tam zrcadlení paměti ani další věci.

jirka

Zdravím Martine.Ohledně 8bitových počítačů existovala též skupina nadšencú okolo počítače Sharp MZ 800 a jeho verzí. Vzniklo několik klubů jeden z nich byl v Brně a ještě nedávno se počítačem zabývali- http://mz-800.xf.cz/mz2vga.htm.
Prodával se v Tuzexu a proti Commodoru,PMD a Spectru byl neskutečně rychlý.Nechtěl byste se podívat i na tento přístroj. Někde ho mám uložený i s orig.tiskárnou. Mám k němu i spoustu technické literatury v češtině. Uživatelský Manuál je anglický

adent

Zdravím Vás, Jirko. O počítačích Sharp MZ 800 vím poměrně málo. V 80. letech tu nějaké byly, ale v časopisech o nich moc informací nevycházelo, takže člověk byl odkázán asi hlavně na kluby a komunitu. Vím, že jsem tehdy jednou na vlastní oči viděl MZ821 a zdál se mi neskutečně „dospělý“ (proti tomu Spectru): mělo to zabudovanou kazetovou mechaniku, tříkanálový zvuk, skvělou klávesnici… Hrozně jsem po něm tehdy toužil. Pamatuju se, že se občas světy Sharpa a Specter překryly a že snad nějací nadšenci portovali programy tam a zpátky, ale víc o tom nevím.

Ostatně podobných počítačů bylo víc. Pár lidí mělo Sord m5, někdo prý měl i MSX (kompatibilní), občas člověk potkal Amstrad CPC… Všechno nádherné stroje, a na všechny bych se chtěl podívat, samozřejmě! :)

jirka

Ano ano.Spoustu programů tehdejší nadšenci upravovali ze Spectra na Sharpa a bylo jich relativně málo,jelikož byly k sehnání přes Tuzex.Jednou se objevily i v jedné Elektře,kde múj známý a neobyčejně schopný vedoucí,je prodával za 7800kč.Vidím,že jste se o Sharpy opravdu zajímal.Tříkanál ve zvuku na úrovni tehdejších syntezátorů z něho dělal i zvukový nástroj. V programu VOICE uměl mluvit. Na povel kreslení náhodných různobarevných čtverců-tuším příkaz Randomize- se obrazovka málem rozsypala rychlostí vykreslování.Kamarád,který si z Rakouska dovezl Commodora málem oněměl a ihned ho chtěl koupit. Jeho přístroj kreslil 1 štvereček asi za vteřinu. Jedna verze Sharpa měla místo té kazetové mechaniky něco jako FDD.Sharp byla vždy dobrá firma a tehdy vyráběla i kvalitní kakulačky.Pídili jsme se tehdy po dalších informacích a zjistili jsme,že se úspěšně prodával MZ80 a další MZ 700,ale řada MZ 820,21,23 která předchozí modely měla zdokonalit a nahradit se již na trhu neujala.Údajně je měl čs zahraniční obchod nakoupit v době,kdy už se nabízelo ATARI, za 50 dolarů.To bylo tehdy1000 kč.V tobě nástupu drahých počítačů s 20 MHz procesorem je dokoce vykupovala komerční banka,za původní cenu.To jsem zaváhal.No konec plkání.Kdybyste o tu MZ821 měl zájem mám ho doma. Nechtělo se mi ho vyhodit.Asi před 10ti lety jsem ho poutěl a naběhl. Dnes již nemám televizi Miniteslu,na které jsem to sledoval.Mám nejen schema ,ale i softwarovou dokumetaci.Tehdy to bylo nesehnatelné.Na silvestra jsem šel do důchodu a již se tím nebudu zabývat. Jsem na mailu-pan.tech@seznam.cz

adent

Díky, odpověděl jsem mailem.

covex

Nevim nevim.. to co me na modernich PC stve, je pomalost. A spusteni stranky s IDE i emulatorem moje PC naprosto umrtvilo, firefox jsem zabil kdyz si vzal 1.5GB RAMky a stale to rostlo. Co na to rict…pocin zajimavym, ale naprosto proti myslence 8mi bitu.

adent

Mohu znát verzi Firefoxu? Protože v tom, co mám k dispozici já, si to „v plné palbě“ řekne o 250MB. Nepochybuju o tom, že tam někde může být chyba, která u starého FF vede k memory leakům, na druhou stranu si vzpomínám, že jsem FF přestal používat nějak v té době, kdy si náhodně na různých stránkách začal brát veškerou dostupnou RAMku.

1cestovni

úžasný rozhovor, zavzpomínal jsem si na PMDčko, programování jsem nerozuměl, ale hry jsem na tom hrál :) To autíčko mě bavilo :)

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.