Gathering of Tweakers

Ik heb wat dingen uitgeprobeerd met een Atmega32 en een gitaarsample (geen hele mods nog dus). Resultaat is deze gezellige warboel:
Plaatje op imageshack (popups!)

Het ding draait op 16MHz en een van de timers wordt in fast PWM mode gebruikt. Omdat de timer bij 256 overloopt betekent dit een D/A rate van 62,5kHz. Uiteindelijk zal dit waarschijnlijk verlaagd worden naar de helft om wat meer tijd te hebben voor het maken van de output maar met alleen een sample afspelen kon het wel.

De sample zit in het program memory en kan op elke gewenste frequentie worden afgespeeld. En dat klinkt zo:
guitar.mp3: opgenomen van de AVR

Ik heb ook de sample even bekeken toen ie opgenomen was, hij doet het wel aardig:

De orginele sample:

De output:


Omdat het geheel AC gekoppeld is verschuift de boel natuurlijk wat naar het midden. Er zit wel vervorming in, maar het klinkt al best aardig en de testopstelling is verre van ideaal. Toch misschien wel een echte D/A converter gebruiken in het definitieve ontwerp, nu zit je wel dat het updaten van de pulsbreedte voor het PWMen altijd wat tijd kost en dat kan problemen geven met kleine pulsen. Misschien dat daarom het volume ook wat hoger blijft, de PWM wordt nu wel geupdate op het overflow interrupt, niet op het moment dat de output verandert, wat voor kleinere pulsen beter zou zijn.

edit: Oja de hardware is dus vrij simpel. AVR met aan de timer compare output een low-pass filter (1k + 10nF en nog een 1k over de 10nF om het niveau op de helft te krijgen voor de opamp), daarachter een LM358 opamp als voltage follower en via een grote elco naar de output. Ik zie nu trouwens dat op het moment van de foto (en waarschijnlijk ook tijdens het meten) de 10nF er niet in zit. Het geluid verschilde vrij weinig met en zonder, waarschijnlijk haalt het hoge 62,5kHz signaal het zowieso niet door al die draden.

madwizard wijzigde dit bericht 04-02-2006 21:10 (15%)

Mooi, Bedankt voor de informatie, even kijken wat ik nodig heb allemaal.

Heb al inkopen gedaan op internet en ben al beginnetje gemaakt van de specs wat ik wil gaan doen.
Ik heb in ieder geval een ATmega128 (of als de samples zijn geaccepteert een ATmega1280) 64K SRAM een 2K dualport ram voor de grafische processor. 2 maal 64K Framebuffers of sprite memories.
288Macrocell CPLD voor VGA, of misschien toch een FPGA gebruiken. Even kijken wat ik heb liggen of kan winnen op E-bay. Misschien hardware sprites, en blending ala de Supernintendo.

O nog een vraagje. Is het misschien mogelijk een aparte pagina te maken met de inzendingen en wie er mee doen, of zal ik dit topic af moeten gaan en F5 constant drukken

Halloohee... overdrijf je niet een beetje? Denk aan het motto 'meer is minder en minder is meer'. Begrijp me niet verkeerd, ik vind het heel gaaf klinken en om het resultaat dan ook te zien lijkt me retecool, maar het is de sport niet met zoveel hardware een goed VGA signaal met sprites en blending te krijgen. De clou is dat je elke cycle uit je chipje perst om wat leuks voor elkaar te krijgen!

sebastius wijzigde dit bericht 04-02-2006 22:35 (20%)

quote:

sebastius schreef op zaterdag 04 februari 2006 @ 22:35:
Halloohee... overdrijf je niet een beetje? Denk aan het motto 'meer is minder en minder is meer'. Begrijp me niet verkeerd, ik vind het heel gaaf klinken en om het resultaat dan ook te zien lijkt me retecool, maar het is de sport niet met zoveel hardware een goed VGA signaal met sprites en blending te krijgen. De clou is dat je elke cycle uit je chipje perst om wat leuks voor elkaar te krijgen!

Aan een kant heb je gelijk, Aan de andere kant wil ik graag VGA gebruiken.
Voor de timing kan ik niet anders, we hebben te maken met een pixelclock van 25.175MHz en daar kom je niet omheen. Ik kan ook aan de andere kant een zwerm Attiny2313's gebruiken. De timing door de CPLD laten doen, en dan wanneer die CPLD een pixel wil hebben een Interrupt op die tiny geven, zo wordt het ook gedaan op de atari 2600. (okay tegenwoordig kun je veel beter doen dan dat).

Het is gewoon afwegen. De een zal er flink wat hardware tegenaansmijten (minpunten) maar gave effecten creeren (pluspunten). Ik stel voor soort punten verdeling, Ieder simpel effect (Copper bars, starfields, sprites) of complex effect (3d, sine plasma's) Heeft zijn eigen puntenwaardering. Van deze punten wordt dus afgetrokken welke componenten hij heeft gebruikt, simpel (Sram's, rom's) of complex (Controller, CPLD, FPGA).

Hoewel ik niet mee doe met deze contest, wil ik me er wel even tegenaan bemoeien

Zelfs met een pic kun je rechtstreeks VGA signalen genereren

Klopt, maarrrrrr: zoals je uit dat artikel kan lezen is het al een hell om de relatief simpele task van FFT-bars genereren te doen. Als je daar ook nog eens grafische effecten bij wilt regelen heb je toch echt wel een enorm zware processor nodig om iets gaafs te doen. Dat is wel mogelijk (ik zit er nog steeds aan te denken om een 32bit arm op 50MHz in te zetten) maar met een simpele PIC red je het niet.

quote:

Squantmuts schreef op zaterdag 04 februari 2006 @ 23:40:
[...]


Aan een kant heb je gelijk, Aan de andere kant wil ik graag VGA gebruiken.
Voor de timing kan ik niet anders, we hebben te maken met een pixelclock van 25.175MHz en daar kom je niet omheen. Ik kan ook aan de andere kant een zwerm Attiny2313's gebruiken. De timing door de CPLD laten doen, en dan wanneer die CPLD een pixel wil hebben een Interrupt op die tiny geven, zo wordt het ook gedaan op de atari 2600. (okay tegenwoordig kun je veel beter doen dan dat).

Het is gewoon afwegen. De een zal er flink wat hardware tegenaansmijten (minpunten) maar gave effecten creeren (pluspunten). Ik stel voor soort punten verdeling, Ieder simpel effect (Copper bars, starfields, sprites) of complex effect (3d, sine plasma's) Heeft zijn eigen puntenwaardering. Van deze punten wordt dus afgetrokken welke componenten hij heeft gebruikt, simpel (Sram's, rom's) of complex (Controller, CPLD, FPGA).

Allemaal heel leuk en aardig wat je wilt gaan maken, en het zal er ook vast en zeker allemaal prachtig uit zien...
Maar is het niet een beetje boven het "hobby" niveau

* virus.elektro heeft van stage een lichtkrant over gehouden van 20 *100 leds. mag ik die gebruiken als display. ze hebben me namelijk alles gegeven, blauwdrukken en zelfs het hex bestand voor een microcontroller. helaas is die microcontroller niet meer te krijgen. dus moet ik zelf aan de slag.

mag ik zo ook meedoen of vinden jullie van niet

Natuurlijk Zeker als je alles zelf gaat aansturen is het geen enkel probleem.

quote:

Sprite_tm schreef op zondag 05 februari 2006 @ 01:12:
Klopt, maarrrrrr: zoals je uit dat artikel kan lezen is het al een hell om de relatief simpele task van FFT-bars genereren te doen. Als je daar ook nog eens grafische effecten bij wilt regelen heb je toch echt wel een enorm zware processor nodig om iets gaafs te doen. Dat is wel mogelijk (ik zit er nog steeds aan te denken om een 32bit arm op 50MHz in te zetten) maar met een simpele PIC red je het niet.

Was het niet zo dat een AVR met dezelfde kloksnelheid 4 keer zo veel kan doen? Dus misschien dat het dan al iets haalbaarder is.

Klopt (hoewel deze meneer z'n pic op 33MHz laat draaien en AVRs maar tot 20MHz gaan; 4 keer haal je met die snelheden dus niet) maar je blijft zitten met het probleem dat je tijdens het outputten van een lijn niets anders kan doen (taskswitching zou namelijk teveel tijd innemen) en je dus alle berekeningen tijdens de hsync en vsync moet doen. De vsync kan niet; je hebt namelijk niet genoeg ram om een compleet beeld in op te slaan; daarom moet je het tijdens de hsync doen en daar heb je maar een instructie of 20 voor. Te weinig om meer dan een bardisplay of chargen te doen dus.

Misschien nog een alternatief voor VGA, hoewel een stuk kleiner: Grafische kleuren LCDs voor nokia's: http://www.sparkfun.com/c..._info.php?products_id=569 . Ze zijn ook via e-bay te vinden.

quote:

madwizard schreef op maandag 06 februari 2006 @ 10:27:
Misschien nog een alternatief voor VGA, hoewel een stuk kleiner: Grafische kleuren LCDs voor nokia's: http://www.sparkfun.com/c..._info.php?products_id=569 . Ze zijn ook via e-bay te vinden.

Dat is ook een leuk idee, bespaart op de componenten. Maar wel iets leuks mee te maken. Probleem is dat er veel vraag naar is dan zal je flink moeten opbieden.

Zo beetje gesoldeerd en een beetje een opzetje gemaakt hoe alles op de "demoplank" (zo noem ik hem nu even). Dit is nu het resultaat, alle sockets zitten er nu op, behalve die DIP40 zit nog niet vast, moet ieder moment de atmega128 binnenkrijgen, maar weet niet of me TQFP adapter deze accepteert.



Ik ga morgen de CPLD's voorzien van power en JTAG aansluitingen zodat ze te programmeren zijn en de weerstandsdeler voor de VGA aansluiten zodat ik alvast een testsignaal kan genereren. Daarna komt de RAM erop en kijken of ik de AVR kan aansluiten.

Ook weer een update van mij, heb de AVR nu zo ver dat hij uit het program memory 1 pattern kan spelen, en daarvan dan maar 1 channel nog. Sample loops zitten er al wel in voor de rest nog helemaal niets behalve het pattern afwerken, maar het werkt

Technisch zit er een 256 byte buffer in het RAM die de PWM timer 62500 keer per seconde uitleest terwijl het hoofdprogramma de buffer zo snel mogelijk probeert te vullen (terwijl de ene 128 byte helft wordt gelezen wordt de andere geschreven).

M'n plan is voorlopig om een 32KB AVR te gebruiken, het programma kan waarschijnlijk wel in 16KB maar de 2KB RAM van de 32 is toch wel handiger dan 1KB voor het geval er dingen gecached moeten worden voor de snelheid (de player zit nu op 340 bytes RAM maar er is ook nog heel weinig geimplementeerd). Voor de MOD ga ik extern flash ram gebruiken, waarschijnlijk 256KB of 512KB (KBytes). Misschien wat ruim vergeleken met grootte van chiptunes maar samples nemen nou eenmaal veel ruimte in. Omdat een serieel flash geheugen eigenlijk geen optie is vanwege de samples die continu afgespeeld moeten worden uit het flash (er is bij lange na niet genoeg RAM om samples te cachen), zal het een parallele moeten worden. Vervelende daarvan is dat je enorm veel pinnen nodig hebt (18 of 19 adrespinnen + 8 datapinnen), waarschijnlijk wordt het dus een Atmega325 die praktisch hetzelfde is als de 32 maar dan met 54 datapinnen ipv 32. Een externe DAC zou weer eens een berg pinnen nodig hebben, ik denk dat ik het houdt bij de PWM methode van genereren. Als het lukt wordt het ook stereo, in de zin van links en rechts elk 2 channels afspelen, net als op de amiga. Dat geeft een voller geluid dan 2 speakers met mono geluid, terwijl er eigenlijk niet 'meer' muziek is. De 16-bit timer van de AVR heeft 2 PWM kanalen dus dat moet het probleem niet zijn.

Maar goed, hoe het nu dus klinkt, een kanaal tegelijk van hetzelfde pattern
channel0.mp3 de lage tonen
channel1.mp3 hoge tonen, rare loopen komt omdat het volume-uit effect genegeerd wordt en de sample te lang doorspeelt
channel2.mp3 drums
channel3.mp3 nog een hoog melodietje

Dit is met een lowpass-condensator van 100nF, de 10nF gaf een rimpel over praktisch het hele bereik. De 100nF klinkt een stuk doffer hoewel het meer op het orgineel lijkt, maar ik vermoed dat een RC filter gewoon niet stijl genoeg is om tegelijkertijd het PWM signaal weg te halen maar de hoge tonen te behouden. Misschien een ander soort filter voor verzinnen dus.

Voor de leuk nog wat scopeplaatjes (wat nabewerkt en blauwgekleurd voor de duidelijkheid).
Channel 3 (met 100nF cap):

De dikke lijn is dus de rimpel van de PWM, met een wat kleinere tijdbasis kun je dit zien:

(Onscherp omdat het signaal zich reset om de zoveel tijd (hij speelde 1 row af continu), wat lastig triggeren is, en de camera niet helemaal stil wilde staan )

quote:

madwizard schreef op dinsdag 07 februari 2006 @ 21:44:
Ook weer een update van mij, heb de AVR nu zo ver dat hij uit het program memory 1 pattern kan spelen, en daarvan dan maar 1 channel nog. Sample loops zitten er al wel in voor de rest nog helemaal niets behalve het pattern afwerken, maar het werkt

Technisch zit er een 256 byte buffer in het RAM die de PWM timer 62500 keer per seconde uitleest terwijl het hoofdprogramma de buffer zo snel mogelijk probeert te vullen (terwijl de ene 128 byte helft wordt gelezen wordt de andere geschreven).

M'n plan is voorlopig om een 32KB AVR te gebruiken, het programma kan waarschijnlijk wel in 16KB maar de 2KB RAM van de 32 is toch wel handiger dan 1KB voor het geval er dingen gecached moeten worden voor de snelheid (de player zit nu op 340 bytes RAM maar er is ook nog heel weinig geimplementeerd). Voor de MOD ga ik extern flash ram gebruiken, waarschijnlijk 256KB of 512KB (KBytes). Misschien wat ruim vergeleken met grootte van chiptunes maar samples nemen nou eenmaal veel ruimte in.

Misschien niet een idee om een atmega162 te gebruiken? Deze heeft een geintegreerde XRAM interface voor externe ram's/rom's. Hij heeft iets van 19 pinnen geloof ik, maar je kan alles in een array plaatsen in plaats van speciale routines om het geheel uit te lezen. Misschien een 512Kb ram chip gebruiken als de buffer voor de samples? En de mod laden uit een MMC kaartje?
Dan kun je een soort mod-pod maken .

Of wat dacht je van dit project voor een hele bak ram te krijgen om de samples te bufferen: http://www.myplace.nu/avr/dram/

Voor de rest, klinkt goed. Zou je de originele mod erbij kunnen zetten? Als vergelijkings materiaal?

quote:

Squantmuts schreef op dinsdag 07 februari 2006 @ 22:10:
Misschien niet een idee om een atmega162 te gebruiken? Deze heeft een geintegreerde XRAM interface voor externe ram's/rom's. Hij heeft iets van 19 pinnen geloof ik, maar je kan alles in een array plaatsen in plaats van speciale routines om het geheel uit te lezen. Misschien een 512Kb ram chip gebruiken als de buffer voor de samples? En de mod laden uit een MMC kaartje?
Dan kun je een soort mod-pod maken .

De vraag is of je met zo'n RAM iets opschiet, alleen als de hele mod erin past eigenlijk. De hele mod wordt vrij random gelezen, je kunt zo tussen samples heen en weer springen. Dat RAM is natuurlijk wel sneller en op zich weet je per 'tick' (meestal zo'n 3ms) wel ongeveer welke data je nodig hebt, maar je samples moeten dan wel binnen 64KB passen, terwijl in principe 1 sample al die grootte mag hebben. Natuurlijk kan ik kleinere mods gebruiken maar het leuke van die mods is juist de echte (meestal niet kleine) samples. De mod die er nu in zit is dan ook een slecht voorbeeld eigenlijk maar veel past er niet in die 32KB . Overigens is de MOD nu wel gepre-processed door m'n C# programma naar een handiger (en iets compacter) formaat, een mod player in de zin van 'lees de mod van een MMC' is het dus niet maar elke mod kan natuurlijk omgezet worden (formaat is grotendeels hetzelfde, indeling alleen anders).

Flash lezen vertraagt de boel natuurlijk wel, je zit toch al aan 3 poorten schrijven voor het adres, control bits setten, poort uitlezen, control bits terug. Maar ik heb nu al het leeswerk uit het program memory expres in een subroutine gezet van ongeveer 20 cycles, om al een beetje rekening te houden met wat vertraging.

quote:

Of wat dacht je van dit project voor een hele bak ram te krijgen om de samples te bufferen: http://www.myplace.nu/avr/dram/

Leuk gedaan maar ook niet erg snel zo te zien, in 3.6uS kun je een hoop doen op 16Mhz

quote:

Voor de rest, klinkt goed. Zou je de originele mod erbij kunnen zetten? Als vergelijkings materiaal?

Hier istie. De mp3s van net waren van pattern 0, maar het liedje begint op een ander pattern, het 3e pattern dat ie speelt is hetzelfde.

Met alleen volume effecten klinkt ie zoals de mp3 die ik eerder al gaf: endagpazoo.mp3, maar dat is nog op de PC natuurlijk.

Eigenlijk zou voor het geheugen een soort van hardware pointer-array handig zijn, dus dat je een IC tussen geheugen en AVR zet je vanuit de AVR een index geeft (kleine waarde dus, snel door te geven), en dat het IC dan een geheugenadres aan z'n output geeft, gebaseerd op de index (gewoon een array dus). Om sneller te zijn dan gewoon direct adresseren zouden de adressen in het IC opgehoogd moeten kunnen worden, wat ik dus eigenlijk zoek is een counter IC met meerdere counters die adresseerbaar en programmeerbaar (op bepaalde waarde in te stellen) zijn. Bestaat er zoiets?

De geheugenadressen die gelezen worden worden wel vrij sequentieel gelezen, alleen wordt er af en toe dus naar een totaal andere plek gesprongen. Met een berg counters (voor elke sample 1 bijvoorbeeld en dan nog wat voor het pattern) zou je dan direct het goede adres kunnen doorgeven.

quote:

madwizard schreef op donderdag 09 februari 2006 @ 00:32:
Eigenlijk zou voor het geheugen een soort van hardware pointer-array handig zijn, dus dat je een IC tussen geheugen en AVR zet je vanuit de AVR een index geeft (kleine waarde dus, snel door te geven), en dat het IC dan een geheugenadres aan z'n output geeft, gebaseerd op de index (gewoon een array dus). Om sneller te zijn dan gewoon direct adresseren zouden de adressen in het IC opgehoogd moeten kunnen worden, wat ik dus eigenlijk zoek is een counter IC met meerdere counters die adresseerbaar en programmeerbaar (op bepaalde waarde in te stellen) zijn. Bestaat er zoiets?

De geheugenadressen die gelezen worden worden wel vrij sequentieel gelezen, alleen wordt er af en toe dus naar een totaal andere plek gesprongen. Met een berg counters (voor elke sample 1 bijvoorbeeld en dan nog wat voor het pattern) zou je dan direct het goede adres kunnen doorgeven.

Hiervoor zou je opzich ook best een extra PICje ofzo voor kunnen gebruiken..

Dat schiet niet op, ik kan ook gewoon direct van de AVR adressen doorgeven en die in het RAM zetten, dat is waarschijnlijk nog sneller dan een externe PIC/AVR. Die zou dan namelijk gewoon hetzelfde gaan doen maar dan als tussenstap. Met een hardware counter zou het wel sneller kunnen. Maar goed het is niet direct nodig nog, het is op dit moment nog snel genoeg zo.

Hmm, gezien de drukte dat het komende project op school met zich mee brengt denk ik niet dat ik het voor elkaar ga krijgen om ook maar iets van RGB-leds aan te sturen zoals ik van plan was
Maar dat wil niet zeggen dat het hele idee van de baan is het gaat er hoe dan ook komen, waarschijnlijk alleen niet op tijd voor de deadline van deze compo.

Jullie krijgen mijn respecta nu al ziet er geinig uit allemaal en ik doe het zeerzeker niet na
Ik ben benieuwd naar het eindresultaat, vooral die van sprite is al wat aan het worden zie ik

quote:

madwizard schreef op donderdag 09 februari 2006 @ 00:32:
Eigenlijk zou voor het geheugen een soort van hardware pointer-array handig zijn, dus dat je een IC tussen geheugen en AVR zet je vanuit de AVR een index geeft (kleine waarde dus, snel door te geven), en dat het IC dan een geheugenadres aan z'n output geeft, gebaseerd op de index (gewoon een array dus). Om sneller te zijn dan gewoon direct adresseren zouden de adressen in het IC opgehoogd moeten kunnen worden, wat ik dus eigenlijk zoek is een counter IC met meerdere counters die adresseerbaar en programmeerbaar (op bepaalde waarde in te stellen) zijn. Bestaat er zoiets?

De geheugenadressen die gelezen worden worden wel vrij sequentieel gelezen, alleen wordt er af en toe dus naar een totaal andere plek gesprongen. Met een berg counters (voor elke sample 1 bijvoorbeeld en dan nog wat voor het pattern) zou je dan direct het goede adres kunnen doorgeven.

En dat principe gebruik ik voor me videokaart. Alleen is een extra AVR te traag om de externe ram interface van een AVR bij te houden, ding kan op 8Mbytes per seconde data produceren. Ik heb zelf voor een XilinX CPLD gekozen.
Om gegevens naar het videoram te schrijven van de VGA generator stuur ik het volgende naar een poort van de CPLD.
Commando, Lowadress, Hiadress, data0, data1, dataN tot ik de chip deselecteer.
Een teller in de CPLD wordt geladen met lowadress hiadress en van daaruit gaat de AVR bytes sturen naar dat adres en de volgende.
Ik kan ook met behulp van een soort configuratie commando het gedrag aanpassen.
Een leuk effect lijkt me dat in plaats van het domweg overschrijven van de locatie is de pixelwaarde van de AVR erbij op te tellen (transparantie)
Of controleren of de pixel 0 is, is dat niet het geval Dan niet schrijven (sprites).
Een ander commando waar ik aan werk maar misschien niet de ruimte ervoor heb in de CPLD is dat ik het volgende commando stuur:
Commando, Lowadress, Hiadress, color, length.
Op deze manier een horizontale lijn kan tekenen. Uitstekend voor polygonen en daarna 3d objecten.

Trouwens heb wat vooruitgang geboekt, rottige is met 8bits dat me demo waarschijnlijk 8 bits zwart wit wordt.

Met 8 bits kun je best kleur maken hoor! 3 bits voor rood (3 verschillende weerstandjes (bijv 660, 330 en 150 ohm ofzo? Dat zul je zelf moeten bedenken), 3 voor groen en 2 voor blauw!

Met 8 bits zou ik met een pallet werken, kun je hele coole dingen doen (palletwissel bijvoorbeeld).
Kijk maar eens naar de Geiss (niet versie 2) plugin voor Winamp. Die werkt ook met 8-bits kleur en 'vreemde' palletten om best gave effecten te krijgen. Als z'n visualisatiepatroon wisselt switched ie ook gelijk het pallet.

Als je dus een pallet based engine kan maken kun je best ver komen om de illusie te wekken dat je met 16 of 24 bits kleuren werkt.

Edit:
Zie ook http://www.geisswerks.com/geiss/shots.html voor screenies. Let wel op: onderaan staan een aantal screens van 16 of 24 bits kleurweergave. De kleine plaatjes zijn in ieder geval allemaal 8-bits kleur! Zou je niet zeggen toch?

ShadowLord wijzigde dit bericht 10-02-2006 12:13 (23%)