Autorem blogu je 
Příběh mikropočítače Tesla Ondra SPO 186, jehož emulaci mám z velké části dokončenu, v porovnání s jiným, daleko známějším Tesla PMD 85, je příběhem v technických oborech nikoli výjimečným. Autor PMDčka Roman Kišš je dnes v určitých kruzích celebritou, jméno Eduarda Smutného, konstruktéra, který vytvořil Ondru, je víceméně zapomenuto.
Přitom by tomu mělo být právě naopak: Kišš byl amatér v nejhorším slova smyslu, technologický chaot
, jehož konstrukce budí dodnes hrůzu (o chybách v návrhu rozhraní k magnetofonu jsme ostatně psali i na tomto blogu). Smutný byl konstruktér-profesionál, autor celé řady mikropočítačových návrhů, který pracoval systematicky, elegantně a čistě. Emulovat podle jeho výkresu bylo i dnes pro mne potěšením, protože vše dávalo smysl a ze schematu bylo na první pohled zřejmé, k čemu který signál slouží a jak to které zapojení funguje.
Kišš byl elektronický barbar, Smutný představoval establishment
. Přesto byla Smutného konstrukce poražena na hlavu nejen piešťanskou variací na thema Hewlett-Packard HP-85, ale z hlediska počtu vyrobených kusů prohrála i s IQ 151, oním exponátem z kabinetu počítačových hrůz.
Důvody, proč tomu tak bylo, sezná každý, kdo se s Ondrou, ať naživo nebo v emulátoru, někdy setkal. Stačila pouhá dvě chybná rozhodnutí a ze stroje, který mohl být kultovním, vznikla kuriosita, mikropočítač tak špatný, že na něj nebyly portovány ani takové základní kameny české programátorské školy jako Hlípa.
 |
| Svítí-li obě LEDky, bude se psát velkými písmeny. Jak intuitivní… |
Za prvé byl Ondra vybaven naprosto nevhodnou membránovou klávesnicí se 37 tlačítky, jež by možná postačovala pro obsluhu NC soustruhu nebo průmyslového čerpadla, rozhodně ne pro mikropočítač, se kterým by měl uživatel jejím prostřednictvím skutečně interagovat. Jestliže byla klávesnice PMD 85 v první versi špatná a klávesnice IQ 151 ve všech versích tragická, ta Ondrova byla prostě od počátku nepoužitelná. Systém pěti shiftů, jejichž stav se (ještě k tomu neúplně) zobrazuje dvěma LEDkami, opravdu není něčím, na co bychom si za dva-tři dny používání zvykli, jak optimisticky naznačuje manuál – mimochodem, imposantní dílo o celkovém rozsahu cca 360 stran.
Druhým hřebíčkem do Ondrovy rakve
se stalo řešení videoprocesoru. Zapojení se dvěma obvody PIT s datovou sběrnicí připojenou k adresové je jednoduché, levné a svým způsobem geniální, ale jeho autoři si neuvědomili, co to bude znamenat v praxi, totiž snížení výpočetního výkonu na 23 % (resp. na 18 %, pokud se využívalo všech 255 dostupných mikrořádků a ne pouze 240 jako u originálního monitoru). Vypneme-li videoprocesor, počítáme plnou rychlostí (Z80 @ 2 MHz), ale zase nic nevidíme, a kompromis s jedním zobrazovaným řádkem, na kterém můžeme sledovat stavové informace, je použitelný jen u nemnohých aplikací.
Důsledkem snížené rychlosti procesoru, a to si Smutný zřejmě neuvědomil, je, že má-li obrazovka odrolovat o jeden řádek nahoru, bude to trvat bezmála sekundu. Kombinace plně grafického vykreslování znaků a zpomaleného CPU se pro Ondru ukázala být smrtícím cocktailem, a je otázkou, proč má počítač vůbec vstup pro joystick, jestliže při této efektivní rychlosti žádná rozumná grafická hra nebude fungovat a Ondra tak bude odkázán na hry textové, případně ty nejjednodušší plošinovky.
PMDčko bylo naproti tomu navrženo daleko velkoryseji, na čtyřech deskách s plochou proti Ondrovi odhadem trojnásobnou, a co bylo rozhodující, jeho procesor 8080A pracoval plnou rychlostí 2,048/2,000 MHz, videoprocesor ho nijak nebrzdil.
PMD 85 proto zcela právem Ondru u uživatelů převálcovalo: barbaři zvítězili nad kultivovanými Římany na celé čáře.
Komentáře
Neviem, či sa dá Roman Kišš takto radikálne označiť za "barbara", či "chaota"...
Kišš bol doslova samouk a zrejme aj z toho plynuli rôzne, nie vždy ideálne riešenia. Naviac, musel "improvizovať" aj so súčiastkami, napriek tomu, že pracoval vo fabrike, ktorá tie súčiastky vyrábala. Mohol by som menovať niekoľko vecí, ktoré sa mi na PMD 85 a spol. nepáčia (HW i SW), a ktoré by sa dali urobiť inak/lepšie/efektívnejšie. I napriek tomu si myslím, že navrhol/vytvoril, na svoju dobu a možnosti, dobrý počítač, ktorý bol pre mnohých "zázrakom", i keď sa k nemu dostali iba v škole alebo v počítačových krúžkoch.
Pokiaľ by sme sa mali pozrieť na to, čo sa Kiššovi fakt podarilo, tak je to práve video-procesor v PMD 85, na ktorom podľa mňa stojí aj úspech PMD 85. Je to veľmi dômyselné a jednoduché riešenie spolupráce procesora a video-procesora. A aj to bude zrejme dôvod, prečo sa vyrábali "klony" PMD 85 - Didaktik Alfa (Alfa 2, Beta), Consul 2717 - Zbrojováček a Maťo.
Na PMD 85 je procesor 8080A video-procesorom samozrejme brzdený. Ak potrebuje k pamäti pristupovať procesor i video-procesor, prednosť má video-procesor a procesor je "pozastavený" zhodením jeho signálu READY. V tomto čase vkladá procesor tzv. Wait stavy, čo trvá, kým video-procesor znovu neaktivuje signál READY. Toto je ale pomerne zriedkavý stav a podľa užívateľskej príručky je brzdenie procesora asi 8%.
O fungování zpomalování procesoru v PMD videoprocesorem jsem se zajímal, protože emulátor by měl toto zpomalování věrně napodobovat, ale bohužel jsem zatím neporozuměl, jak interakce mezi CPU a videoprocesorem funguje. Vím jen tolik, na výstupu FF by měl být signál /WO (odvozený z D1), a ten se po XORování se signálem VIDEO přivádí na READY; signál VIDEO je připojen přímo i na SBEN u 8228.
Jestliže je procesor skutečně videoprocesorem zpomalován (což by být rozhodně měl), pak je mi záhadou, jak je možné, že Šuhajdovi fungují správně hodiny v Hlípě, když, jak jsem si ověřil, z 8253 nečte. Jeho hodiny by měly logicky jít v emulátoru rychleji, ale ve skutečnosti ukazují čas přesně.
Prostě je mi to celé záhadou a něž emulátor dokončím, budu se s tím muset poprat.
Je jasné, že VIDEO je signál se střídou 50 % a frekvencí phi2/2 (tj. cca 1 MHz), což odpovídá tomu, že videoprocesor musí generovat jednu šestici pixelů každou mikrosekundu. Procesor v každé stavum T3 potřebuje sběrnici, proto je v případě, že by tento přístup kolidoval s činností videoprocesoru, o jeden Tw zpomalen. Logiku by tedy dávalo, kdyby byl na /READY, který se testuje v T2, přiveden přímo signál VIDEO, ne VIDEO xor /WO.
Kdybych měl tento problém řešit já, zřejmě bych na to šel opačně a testoval, zda mohu použít sběrnici. Pokud ano, přečtu byte a uložím ho do latche, pokud ne, počkám na další mikrosekundový slot. Tím bych procesor nezpomaloval vůbec a z hlediska počtu integrovaných obvodů by to vyšlo nastejno.
Nicméně, pokud jde o míru zpomalení, bez ohledu na to, že logice zapojení nerozumím, zdá se, že se, v průměru, vkládá jeden Tw do každého druhého M-cyklu. Instrukce tedy budou mít dvě různá trvání v závislosti na tom, zda začínají v lichou nebo sudou periodu systémových hodin. Až přijdu na to, jak je to s tím /WO, se skřípěním zubů to implementuji (budu muset subclassovat procesor a změnit mu časování).
Pravdu povediac, aj v technickej príručke je funkcia toho klopného obvodu, ktorý vytvára signál READY popísaná pre mňa nelogicky, ale beriem ako fakt to 8% brzdenie.
V našom emulátore sme "brzdenie" procesora riešili tak, že sa za jednotku času skrátka vykoná o 8% taktov menej, ako by sa do toho času vošlo. Nemôžem tvrdiť, že je to najideálnejšie riešenie, je ale prijateľné a funkčné.
V Hlípe je presné časovanie riešené jednoduchým fígľom. PIT 8253 je inicializovaný rovnako, ako pri zápise na magnetofón. Ale podstatné je, že sa na USART 8251 vyšle byte. Odoslanie tohto bytu trvá vždy rovnakú dobu. V slučke sa vykonáva kód (hodiny, obsluha udalostí a spritov, muzika, atd.), ktorý vždy trvá kratšie ako, odoslanie bytu USARTom. Následne sa testuje stavové slovo 8251 a čaká sa na ukončenie odosielania bytu (to je už iba zlomok času). Potom sa opäť odošle byte na USART a tak dookola.
Všiml jsem si
1) Tw se vkládá pouze do M-cyklů, které zapisují do paměti nebo na port a kolidovaly by se čtením paměti videoprocesorem. V ostatních případech se čtení VideoRAM i normální čtecí cyklus vejdou do jediného T-stavu. To má logiku, ale neodpovídá to zapojení 7474 a 7486.
2) Tw se vkládá i do M-cyklu, který není zapisový a přitom nekoliduje s videoprocesorem. To logiku nemá, ale zapojení podle schematu to přesně odpovídá.
Ani v jednom případě, mimochodem, není zpožďování vyjádřitelné konstantou, ale variuje podle prováděného kodu, v případě 1) značně (např. zpožďovací smyčky pracující pouze s registry se nezapmalují vůbec), v případě 2) méně.
Kontroloval jsem leccos, včetně správnosti překreslení schematu z originálu, ale protože fysicky PMDčko nemám, nemohu si signál READY prohlédnout osciloskopem. Mám rozepsaný program v BASICu, který by časování otestoval a vypsal výsledek. Teď hledám dobrovolného dárce strojového času, který by ho pro mě na fysickém stroji provedl
V Hlípe je presné časovanie riešené jednoduchým fígľom.
Díky, tohle jsem netestoval. Je trochu divné, že Šuhajda nečte přímo 8253, to by měl přesné časování i u těch PMD 85-1, kde se 1200 baud generuje autonomně (psal jsem o tom jako o možnosti, nevím, jestli některá PMD opravdu takto šíleně zapojena byla), ale rozhodně se tím vysvětluje záhada, že se zpomalování na jeho "hodinách s budíkem" neprojeví.
Vidím, že PMD znáte velmi detailně.
Počítač zvláda aj hry, musia byť však písané priamo pre tento počítač a nie iba portované (ako to bolo pri hrách JetPac, Galaxians a pod. zo ZX Spectra, ktoré sú strašne pomalé). Samozrejme pri niektorých efektoch (ako skrolovanie) chýba počítaču výkon. Treba vždy mať na pamäti dizajn počítača a tomu perfektne prispôsobiť návrh algoritmov. Ak je na počítači niečo ale naozaj tragické, tak je to zvukový výstup, ktorý pri zapnutom zobrazovaní dokáže vylúdiť iba 8 divných tónov.
Osobne počítač Ondra považujem za dobrý počítač, ktorému chýbala politická vôľa, aby došlo k jeho rozšíreniu.
Martin
sites.google.com/site/ondraspo186/
RSS kanál komentářů k tomuto článku