Jak jsem se již zmínil v minulém příspěvku o opravě mého Ondry, Martin K. napsal velmi šikovný prográmek na otestování různých funkcí Ondry. Co je na něm super, je to, že ho můžete jak nahrát do Ondry klasickou cestou, což Vám ale asi u vadného Ondry moc nepůjde, nebo naprogramovat do ROM a testovací program funguje i při nefunkční RAM.
Já pro testování používám AT28C16, která se dá snadno přeprogramovat a tak měnit obsah dle potřeby. Martin totiž zveřejnil i zdrojové kódy a můžete si tak prográmek případně i upravit na jemnější dotrasování konkrétního problému. Na druhou stranu musím konstatovat, že Martin postupně prográmek natolik vymazlil, že to snad už ani nebude potřeba 
.
Pro plnohodnotný provoz programu je dobré mít možnost přijímat znaky ze sériové linky rychlostí 57600 Bd, jako u programu OndraLink, ale celkem dobře si vystačíte i bez ní. Program probíhá v následujících krocích:
- Test videa – je generován obraz, kde by se měly postupně posouvat střídající se bílé a černé pruhy. Pokud jsou pruhy „více pruhované“ je pravděpodobně vadný nějaký bit paměti, pokud pruhy nejsou vůbec, můžou být vadné čítače, případně procesor vůbec neprovádí program z ROM. Tímto se detekují hned dvě na Ondrovi poměrně časté závady – vadná RAM a vadné čítače.
- Test zvukového výstupu – postupně zahraje všechny tři základní tóny Ondry.
- Test LED a relátka – 5× blikne oběma LED a při tom cvaká relátkem.
- Dump ROM (0000h-4000h) na sériovou linku. Výstup je binární, je tedy dobré mít terminálový program, který se s tím srovná, případně ukládat obsah ROM rovnou do souboru a pak srovnat s předpokládaným obsahem ROM. Mně se osvědčil RealTerm.
- Test jednoho bytu paměti na adrese 55AAh. Na tuto adresu je zapsána hodnota 00h a následuje 8 postupných pípnutí pro každý bit, počínaje 0. bitem. Nízký tón znamená, že byla přečtena 0, tedy správná hodnota, vysoký tón znamená přečtenou 1, tedy špatnou hodnotu a problém s daným bitem. Následně je na tu samou adresu zapsána hodnota FFh a opět 8 postupnými pípnutím hlášena správná (nízký tón) nebo špatná (vysoký tón) načtená hodnota.
- RAM na adresách 5000h-9000h je vyplněna hodnotu 00h a následně je tato oblast vyčtena a vypsána na sériovou linku.
- Stejný test jako v bodu 6, ale s hodnotou FFh.
- Test klávesnice – program pípá a čeká na stisk mezerníku. Po jeho stlačení je program restartován od začátku.
Program si můžete stáhnout z Download sekce Martinových stránek.
2. Test zvukového výstupu – postupně zahraje všechny tři základní tóny Ondry.
Ondra má 7 tónů.
Ale tri tony jsou zakladni tvorene tremi fyzickymi odpory. Ostatni jsou kombinace tech 3 bitu. Testem tech 3 zakladnich tonu se overi, ze vsechny odpory, diody a ovladajici K555TL8 (74LS175) jsou OK.
Je to vec pohladu, muzikant by povedal, ze zakladny tam nie je ani jeden. V kazdom pripade tu ton vznika kombinaciou troch bitov, ktore syntezou menia frekvenciu AKO.
No jo, ja nemyslel hudebne zakladni, ale hardwarove zakladni 😉 Proste neslozene.
Z pohladu HW su zakladne tri tony,
z pohladu frekvencie sedem tonov,
z pohladu hudobneho ziadny.
Ja suhlasim s Tebou (v sulade s ucelom testu), ze zakladne su tri.
Zkoušel jsem to, v emulaci jde tónů libovolně, temperované ladění nevyjímaje, něco jsem napsal, ale bohužel nemám Ondru ani repliku, že to chodí v emulaci ještě nic neznamená. Zkuste někdo nahrát přes ondralink Toy symphony do Ondry (BIN soubor je to, na MZF se nedívejte), jak to hraje. Odvážlivcům díky.
Parada Bohousi, Ondra hraje melodicky a pak, ze to nejde 😉 A to odpocitavani na zacatku ala Sharp BASIC demo mne rozsekalo.
Ze toto bezi v emulatore, tak to je zazrak. To riesenie je silne zavisle na HW. V reali pri zlom odhade spustenia AKO su generovane skreslene tony a repro pri niekorych vyssich tonoch kolabuje.
Napriek tomu to na realnom Ondrovi hra perfektne. Az by som neveril, ze to mohlo vzniknut bez HW.
Sice Ondru nemám, ale mám schéma, a emulaci teď dělám až na úroveň aktuálního napětí na kondenzátorech v emulovaném AKO. Trošku jemnější krok by už byl SPICE model 🙂 Tak jsem se doemuloval (možná se dá už mluvit o simulaci vzhledem k podrobnosti modelu) k poznání, že zvýšení hodnot (třeba jen výrobní odchylkou) RC článků až o 40% by mělo způsobit jen snížení hlasitosti výstupu (snížení střídy, frekvence zůstanou) a snížení hodnot až o 40% nezpůsobí změnu žádnou (no dobře, začne to hrát o pár mikrosekund dřív 🙂 ). Příjemným zjištěním bylo, že už první nástřel emulace (jen strobovaný generátor tónu) výsledný kód přehraje velmi podobně. Výsledek na Ondrovi mohla zhatit odchylka od oficiálního schématu, naštěstí se tak zdá se nestalo.
Ked som pisal SW na generovanie tonov, narazil som na zvlastne chovanie pri urcitych frekvenciach – napr. po piatich spravnych kmitoch nasledovali tri nespravne. Odskenoval som to analyzatorom, mozem poslat, kontakt na mna je na stranke spomenutej na zaciatku clanku…