Předchozí verze přehrávače dvouhlasé hudby pracovala s děličkami s rozlišením 8 bitů. To se v praxi ukázalo jako celkem dost omezující faktor, neboť již v oblasti malé dvoučárkované oktávy zely díry po nepokrytých tónech. A z tříčárkované malé oktávy zbylo jen torzo.
Nová verze přehrávače využívá techniku, použitou u DDS (přímé digitální syntézy), kdy k základnímu akumulátoru se opakovaně přičítá konstanta, přímo úměrná požadované frekvenci. A při přetečení akumulátoru se neguje hrana výstupního generovaného signálu. Procesor i8080 má hardwarovou podporu pro 16-bitové sčítání, proto i uvedený přehrávač pracuje s tímto rozlišením. Přesněji řečeno, konstanty, určující frekvence jednotlivých not mají rozlišení 16 bitů. A jak se ukázalo v praxi, pomocí tohoto mechanismu lze bez problémů pokrýt rozsah 88-klávesového klavíru, tzn. rozsah A2(subkontra/velká dvoučárkovaná) až c5(malá pětičárkovaná oktáva). Použitá technika zvládá i větší rozsah, je otázkou, kam až je zapotřebí zajít.
Uvedený příklad obsahuje i skladbu, z jejíhož zápisu je vidět struktura definičních dat této skladby. Struktura dat a interní mechanismus přehrávače byl upraven tak, aby umožňoval transpozici celé skladby (pro případ, že přebereme data z jiného systému a nechce se nám ručně přepočítávat čísla not) a také umožňuje v rozsahu 1..7 měnit globální tempo skladby (lepší než nic).
Při přenosu dat na jiné systémy (třebaže na bázi i8080 – ovšem záleží taky na poměrném počtu vkládaných WAIT stavů od hardware počítače!) je třeba pamatovat ještě na jedno hardwarově závislé řešení. Tím, že má PMD-85 pověšen speaker na bitu PC2, má jednu výhodu. Zapíšu-li hodnotu 04h na výstupní port PC služební 8255-ky, nahodím tím speaker do log. 1. Pokud stejnou hodnotu 04h zapíšu do řídicího registru téže 8255-ky, nuluju výstupní pin na portu PC2 a tím na speaker zapíšu log. 0. Takže mohu trvale držet v akumulátoru hodnotu 04h a nemusím měnit jeho obsah a tím zpomalovat smyčku přehrávače. Tento efekt funguje jen pro některé pozice bitů. S tím je zapotřebí se při portaci na jiné systémy buď vypořádat, nebo zapisovat pouze na port PC a před patřičnou instrukci OUT zařadit instrukci MVI A,pozice_bitu_speakru. Pak se ovšem natáhne délka hrací smyčky a bude nutno přepočítat děličky not.
Zde je tedy slíbený příklad:
Příklad s použitím knihovny přehrávače (assembler)
Příklad ve formě virtuální MGF nahrávky pro emulátor PMD-85 od RM-Teamu
Zvukový záznam skladby (formát WMA)
Použité řešení má kromě většího rozlišení ještě další výhodu v tom, že algoritmus má pořád stejnou délku (vyjma měření doby trvání tónu při přetečení registru C – ale tam to nevadí). Takže když generátor 1. tónu překlopí logickou úroveň, neprojeví se to na délce generované vlny tónu č.2.
Další fajnovostí, kterou se tato verze může pochlubit, je čtyřnásobný počet těl vlastního generátoru. Každá z těchto čtyř instancí předpokládá určitou kombinaci logických hodnot obou zvukových generátorů: 0/0, 0/1, 1/0 nebo 1/1. Každé tělo se stará o tu svou kombinaci a při potřebě změnit logickou hodnotu na výstupu některého kanálu se přejde na jiné tělo.
Oproti původnímu přehrávači s osmibitovým rozlišením má tento poněkud „zastřenější“ projev. Asi je to tím, že z nějakých 40T/kanál se délka algoritmu protáhla na ca 51,5T/kanál a tím se výstupní signál hůř synchronizuje se vzorkovací frekvencí zvukové karty na PC, která je fixně nastavena na 44100Hz.
Ještě jedna poznámka. Vypočtené konstanty pro generátor tónů jsem původně počítal pro zpomalení procesoru (od vkládaných WAIT stavů od videoprocesoru) na úrovni 15-16%. Nakonec jsem podle měření skutečných generovaných frekvencí na čítači zpětně propočetl, že zpomalení této konkrétní sekvence instrukcí činí asi jen 10%. Nějak hlouběji jsem se v tom nešťoural, pokud se někomu bude přeci jen chtít, tak jeden průchod smyčkou má 103 taktů CPU a pro vygenerování celé vlny je tedy třeba 2×103 = 206 taktů CPU.
Do článku jsem doplnil i odkaz na WMA soubor se zvukovým záznamem použité skladby, přehrávané ve výše uvedeném přehrávači dvouhlasé hudby.
Pokračující pokusy s tříhlasým přehrávačem ukazují, že již při třech hlasech je poměrná energie, kterou lze během 1/3 doby předat na speaker už tak malá, že zvuk každého jednoho hlasu zní značně slabě a nevýrazně. Za ten efekt tříhlasé melodie ta nízká kvalita zřejmě již nemá smysl. U čtyřech hlasů se již nedá mluvit o použitelném zvukovém výstupu. A to jsem u těch tří a čtyřhlasých přehrávačů použil techniku předpočítání samplu do buferu a až následně jeho optimálně rychlé přehrávání.
Oproti tomu se o dvouhlasého přehrávače objevila možnost „relativně jednoduše“ doplnit možnost ca 4-stupňové (ne 4-bitové!) regulace hlasitosti pro oba hlasy nezávisle. Jedná se o metodu, kdy změnou střídy výstupního obdélníku lze měnit energii (=hlasitost) zvukového výstupu. Trochu se samozřejmě vlivem změny složení harmonických složek mění i „barva“ zvuku, ale je to řešení. Mimochodem toto řešení je použito právě u Trailblazeru při postupném ztišování cinkání při ztrátě míče.
Dnes přišel nápad, jak udělat tříhlasou hudbu. Tedy další z řady nápadů na toto téma. Ovšem tentokrát se to podařilo dotáhnout do stádia poslouchatelnosti. Ještě musím dodělat nějaké tělo, které bude lovit tóny z notového zápisu a regulovat rychlost přehrávání ale první výsledky znějí slibně. A protože je program opět na samé hranici rychlosti, pro počítání délky tónů je použito „Limitní časování pomocí UARTu“. Naštěstí se v okolí „lidských“ délek tónů nalézá celá řada časových konstant UARTu, takže regulace rychlosti přehrávače by mohla být celkem jemná. Jen to musím doladit..
Ten nápad na tříhlasou hudbu měl celkem velký vývojový potenciál. Nyní už ani nepotřebuji časování UARTem a tóny dokonce nejsou ani více zkreslené (oproti dvojhlasé verzi). Momentálně ladím čtyřhlasou variantu ale to už je opravdu strop. Minimálně z důvodu poklesu relativní hlasitosti jednotlivých zvukových kanálů. Přeci jen se elektrický výkon BEEPru dělí mezi čtyři provozovatele. Ale zní to celkem ještě dobře. Na skutečném železe problémy s přehrávači ani tak nemám, tam platí „čím rychlejší, tím lepší“. Problém je v emulátoru, či spíše v systému vzorkování 44100Hz pro zvukový výstup na PC. Vzhledem k faktu, že se jedná o dominantní platformu k šíření programů pro PMD-85 je však třeba tento fenomén respektovat, či lépe řečeno, přehrávač hudby pro PMD-85 pro emulátor přímo optimalizovat. Prozatím se mi několikrát potvrdilo, že optimálního zvuku lze dosáhnout tehdy, když doba, vyčleněná na jeden vzorek zvuku (myšlen zápis hodnoty na port 0F6h na PMD-85) je některou z „vyvolených“ hodnot. Určitě platí, že nesmím podkročit čas jednoho vzorku 44100Hz na zvukové kartě PC (to odpovídá asi 39T jmenovitým! taktům CPU i8080 na PMD-85). Kupodivu zní dobře varianta 62-66T CPU i8080, což odpovídá zhruba 1,6 násobku vzorkovací frekvence 44100Hz . To odpovídá výpočetním nárokům pro tříhlasý přehrávač, který zní opravdu čistě. Čtyřhlas mám naladěn na 75T/vzorek a jsou tam slyšet nějaké vysoké parazitní frekvence. Ale zkusím jej zpomalit mírně nad dvojnásobek vzorkovací frekvence 44100Hz (někde kolem 78T CPU i8080 na PMD-85). Ten tříhlasý přehrávač má dokonce takovou strukturu, že by šlo teoreticky dodělat zhruba 5-7 stupňovou regulaci hlasitosti pro jednotlivé kanály nezávisle. Ale po zkušenostech z Trailblazeru vím, že se při pulsně šířkové modulaci rapidně „zanáší“ zvuk vysokými partazitními složkami a nezní to moc dobře.
Ty řeči o násobcích vzorkovacích frekvencí uváděných v počtech taktů i8080 je třeba brát s rezervou. Ono totiž záleží na tom, jak je interní časování instrukcí i8080 proloženo výskytem signálu VIDEO, který na PMD-85 brzdí procesor. Některé sekvence jsou brzděny minimálně a jinde to jako na potvoru vychází pořád v kolizi s videoprocesorem. Takže 1,6 násobek vzorkovací frekvence může klidně být dvojnásobkem..
Vůbec tomu nerozumím :), ale držím palce a těším se na nějakou tu ukázku…
Ukázka bude, jen ještě doladím ten čtyřhlas, ať je co srovnávat. Ten přehrávač vylepšuji kvůli Funny Fruits, ať tam je na konci nějaké to překvapení.. Taky jsem v určité fázi vývoje zmíněné hry potřeboval matematické operace dělení a násobení nad 16-bitovými čísly a tak jako vedlejší produkt vznikly knihovny s těmito matematickými operacemi, které později hodím rovněž do sekce „Jak na to“.