soodan sivut

arkisto

237 kirjotelmaa.

avainsanat

DOT järkkää silloin tällöin mm. koulutusiltoja erinäisistä demoihin ja muuhun koodiseen mediaan liittyvistä asioista. Itse erehdyin jossain kokouksessa lupautumaan että kerron jotain avr-soodailun perusteista ja niiden soveltamisesta demoihin. Höpisin siis vähän aikaa sitten flunssassa jotain satunnaista niistä perusteista, näytin videotykiltä mm. lft:n Phasor:n ja näytin jotain tyhmää demoalkua mitä itse koodailin myös Atmelin ATmega8-mikrokontrollerille.

Sille vanhalle pikkutelkulle jonka aiemmin ostin voi syöttää videosignaalia PAL:na ja ääntä ihan normaalisti monona, molempia RCA-liittimistä takana. Ookoo, josko tuohon saisi vaikka jotain kuvaa. Googlaamaan. Aiheesta kannattaa lukea mm. seuraavat:

Joissain on pikkasen redundanttia tietoa ja joidenkin välillä info menee vähän ristiin (esim. wikipedian mukaan front ja back porch ovat erikseen mutta monet sivut speksaavat vain kerran tuonne alkuun), mutta riittävästi lueskelemalla ja tulkitsemalla ja kokeilemalla oikeat temput kyllä löytyvät. Suht simppeli juttu kuitenkin on kyseessä: Kuvadata on lomitettu ("interlacing"), yksi scanline alkaa ~4 mikrosekunnin synkkauspulssilla, seuraa 8µs tyhjää ja sitten 52µs kuvadataa vasemmalta oikealle; yksi scanline kestää siis 64 mikrosekuntia. Framejen välillä on pystysuuntaista synkronointia varten taikapulsseja joilla kuva saadaan pysymään paikallaan pystysuuntaisesti.

Jännitetaso vaihtelee nollasta yhteen volttiin siten, että nolla volttia on varattu synkkipulsseille, 0.3V on mustaa ja 1V valkoista; nollan ja mustan välillä on kai joku kielletty alue. Tuon voi generoida triviaalisti vaikka vastuksilla tehtävällä DAC:lla epätarkasti (kuten yo. linkeissä) mutta riittävästi tällaiseen pikkupurkkaamiseen. Värisignaaliakin kuvaan saa, mutta se on monimutkaisempaa eikä tuo telkkuni osaa. Väreistä voi lukea jostain noista ylemmistä linkeistä.

Mikrokontrolleri saa tehdä aika paljon töitä jotta yhtään tarkkaa kuvaa sais näkymään. Erityisesti tuon 52 mikrosekunnin aikana saa olla tarkkana ajastuksen kanssa että pikselit olisivat siellä mihin ne kuuluvat; tietysti mitä isompia pikseleitä tai epätarkempaa kuvaa niin sitä enemmän sielläkin voi tehdä laskentaa. Olennaisesti kuitenkin kuvadatan aikana on vähän vaikeaa tehdä muuta kuin hoitaa sopivat jännitetasot ulos.

Scanlinejen synkronointipulssien ja backporchien aikana taas ei tarvitse muuta kuin odottaa, joten niissä voi laskeakin juttuja. Lisäksi voi olettaa että ihan ylimmät ja ihan alimmat kuvarivit tuskin näkyvät koska vanhat telkkarit olivat kovin huonoja ja uudemmat taas kompensoivat tuota huonoutta olemalla näyttämättä rivejä tahallaan jotta kuva näyttäisi samalta kuin ennen, tai jotain yhtä hölmöä. Jos kuvaan taas aikoo tiettyihin kohtiin tasan tarkkaan yksiväristä riviä, niin sielläkin voi tosiaan laskea asioita korkeintaan sen 52 µs. Vertikaalisynkkien aikana on 30 µs mittaisia tyhjiä jaksoja, joissa ehtii tehdä hommia.

Kaiken kaikkiaan kuvanmuodostus PAL-signaaliin AVR:llä on aika kinkkistä, kun itse kuvan piirtämistä joutuu hoitelemaan silloin tällöin kun ehtii aiemmin selitetyllä tavalla. AVR:issä on lisäksi kovin vähän RAM-muistia, eli minkäänlaista fiksun kokoista framebufferia ei normimuistiin mahdu. Joko on resoluutiota mutta kikkailua tai ei resoluutiota ja järkevämpää koodia. Jos näyttöä päivitetään vaan kunhan ehtii eikä kovin järjestelmällisesti niin olisi kiva olla tuplapuskuroitu ettei katkeilisi.

Eikä siinä vielä kaikki! Demoihin liittyy keskeisesti myös ääntä. Mikrokontrollerissani ei yllättäen ole mitään rautaa äänen generointiin, vaan koko aaltomuoto on puljattava itse. Paras tapa tähän lie ulkoinen DAC-piiri tai vastusverkko, mutta ajanpuutteen takia puuhasin edellisenä iltana pwm:llä ja lowpassfiltterillä jotain ääntä etäisesti muistuttavaa rätinää. Ääni telkkarille annetaan ihan normaalisti jännitevaihteluina jotka vastaavat suoraan ääniaaltoja. Jännitetason voi approksimoida tuolla pwm-lowpass-purkkaviritelmällä välille 0..5 V ja avr:stäkin kuluu vain yksi nasta tähän. Lowpass vaimentaa pwm:n pohjataajuutta niin että sen korkeataajuinen ininä ei tule turhaan mukaan (tässä se oli kyllä niin korkea ettei ole edes korvan alueella). Vaan mitenkäs sen ääniaallon muodostus?

Kun scanlinen pituus on 64µs, niin niitä on sekunnissa 1/64µ = 15625 kappaletta. Aika hyvin riittäisi laskea joka rivin alussa uusi äänisamplen volyymi; äänestä tulisi aika karua ja siihen saisi maksimissaan 8KHz taajuuksia mutta se nyt kuuluisi tässä asiaan. Itse tuossa testikoodissani päivitän ääntä useamman kerran scanlinellä kun piirtelin isoneliöistä ruudukkoa, mutta riippuu aina toteutuksesta ja tarpeista että miten se pitäisi tehdä. Testiksi tuossa generoin vaan vähän kolmioaaltoa; meinasin tehdä kyllä jotain hienompaa, mutta koodausaika (yksi ilta) loppui kesken. Oikeastihan joku SID:n kaltainen temppu softalla voisi olla aika hyvä ratkaisu. Yksinkertaisia ihan hyvältä kuulostavia pätkiä voi tehdä tosi lyhyellä koodillakin kyllä, siinä pitää sitten leikkiä ja tutkia vähän että saa jotain fiksun kuuloista aikaiseksi. Pienen softasynan jos tekee niin voi puljata sitten ihan instrumenttien pohjalta pc:llä ääniraidan ensin. Mutta äänestä pohdintoja joskus myöhemmin.

Ylläolevan ruudukkokuvan luo seuraava koodi: pal.c. Koodi on kammottavaa parin illan testailua, eikä siitä kannata ottaa oppia. Pitäis tehdä keskeiset osat asmilla ja laskea kellojaksot tarkkaan että voisi olla ylpeä.

1 kommentti

Oma kommenttisi

Mielipide tämän sivun asiasta? Kirjoita toki. Älä raapusta kuitenkaan ihan asiattomia juttuja.

Jos on yksityisempää asiaa, tarkkaa kysyttävää tai aihetta pidemmälle keskustelulle, käytä yhteydenottolomaketta kommentoinnin sijaan.

Hölmöt kommentit saatetaan moderoida pois jälkikäteen.

Nimimerkki:

Spammibottiesto: Mikä on neljän ja neljän summa? (vastaus numeroina)