Hallo zusammen, ich bin gerade über www.embedds.com auf die folgende Seite gestoßen: http://www.linusakesson.net/scene/craft/index.php Da hat einer eine VGA-Demo mit Soundausgabe auf einem ATmega88 programmiert. Schon erstaunlich, was mit einem ATmega so möglich ist. Gruß Christoph
Es gab ja schon riesen Diskussionen hier im Forum, ob der C64-Sid auf dem Atmega8 zu realisieren sei, und siehe da es war: http://www.roboterclub-freiburg.de/atmega_sound/atmegaSID.html Das was die auf www.embedds.com geleistet haben, ist schlicht weg unglaublich! Der Hammer, wenn das stimmt! Das sprengt wirklich alle Grenzen. Hochachtung!
Die lange Videosequenz und der Sound kann doch unmöglich in einen mega88 passen.
Das meiste ist Algorithmik - da sind keine Video im AVR drin, sondern nur Funktionen, die das berechnen.
>Die lange Videosequenz und der Sound kann doch unmöglich in einen mega88 >passen. Noch nie ne Demo programmiert ? ;-)
Glaub, dass das garnicht so schwierig ist, wenn man sich demos für den z.B. 286er oder sowas sucht und die auf einen AVR portiert - also natürlich die Algorithmen. Die sind ja schon gut optimiert ...
Robotnik wrote: >>Die lange Videosequenz und der Sound kann doch unmöglich in einen mega88 >>passen. > > Noch nie ne Demo programmiert ? ;-) Ne ;) Ich würd ja auch gern mal meinen alten Bildschirm hier mitm AVR ansteuern. Kennt jemand ne Seite wo das gut erklärt ist wie das geht? Oder ein Beispiel Programm in C. Gruß Robin T.
Die Demo mit dem Hammer-Mega88 wurde schon vor einiger Zeit hier behandelt. Beitrag "Craft " Gruß, Magnetus
Eine berechtigte Frage: >Die lange Videosequenz und der Sound kann doch unmöglich in einen mega88 >passen. Und eine scheinbar logische Antwort, die alle Mysterien erklärt: >Das meiste ist Algorithmik - da sind keine Video im AVR drin, sondern >nur Funktionen, die das berechnen. Selbst wenn man weis, dass vieles algorithmisch erzeugt wird, ist es höchst erstaunlich, wie die Leute das geschafft haben, in einen Atmega88 mit nur 8KFlash und 1KRam unterzubringen. Die Musik dürfte aus einem C64 File kopiert sein. So wie es sich anhört, ist sie aber irgendwann von Hand gespielt worden und kann deshalb schlecht algorithmisch erzeugt werden. Die Noten müssen also ziemlich gut komprimiert sein. Erstaunlich. Und einem Gast, der überhaupt keine Ahnung hat: >Glaub, dass das garnicht so schwierig ist, wenn man sich demos für den >z.B. 286er oder sowas sucht und die auf einen AVR portiert - also >natürlich die Algorithmen. Die sind ja schon gut optimiert ... z.B. ein 268 PC mit 16 Bit Prozessor, 640K Ram und externer Grafikkarte. Hier ist es bestimmt ein leichtes, die Algorithmen auf eine Prozessor mit 8KFlash und 1KRam ohne Grafikkarte zu übertragen.
Mhh irgenwie ist der CRAFT sourcede lost odeR? Gruß Jens
cornu wrote: > Die Musik dürfte aus einem C64 > File kopiert sein. So wie es sich anhört, ist sie aber irgendwann von > Hand gespielt worden und kann deshalb schlecht algorithmisch erzeugt > werden. Die Noten müssen also ziemlich gut komprimiert sein. > Erstaunlich. Die Musik wird natürlich nicht algorithmisch erzeugt. Aber es muß ja nur gespeichert werden, welche Noten wann und in welcher Höhe ein- bzw. ausgeschaltet werden. Bei vier Stimmen und der Länge des Demos sind das nicht besonders viele Daten. Eine MIDI-Datei eines komplexen Musikstücks mit 16 Spuren und einer Länge von 4-5 Minuten ist auch ja relativ klein. Da werden ja auch nicht die Sounds, sondern vereinfacht dargestellt Note on/Note off Befehle gespeichert. Gruß Christoph
>Eine MIDI-Datei eines komplexen Musikstücks >mit 16 Spuren und einer Länge von 4-5 Minuten ist auch ja relativ klein. Wie groß ist relativ klein? 8KByte? Dann ist das Flash des Atmega88 voll.
cornu wrote: >>Eine MIDI-Datei eines komplexen Musikstücks >>mit 16 Spuren und einer Länge von 4-5 Minuten ist auch ja relativ klein. > > Wie groß ist relativ klein? 8KByte? Dann ist das Flash des Atmega88 > voll. Die kleinste MIDI-Datei, die ich auf die schnelle auf meiner Platte gefunden habe besteht aus einer Klavierspur, Streichern, Bass und Schlagzeug. Insgesamt 4 Minuten lang und 18KByte groß. Das in der Demo verwendete Musikstück ist 3:30 Minuten lang und hat maximal 1/15-1/10 des Notenaufkommens des MIDI-Stücks => mehr als 2KByte sollten es also nicht sein. Gruß Christoph
OK, ich versuche es auch mal abzuschätzen: 4 Noten/Sek 210 Sekunden =820 Noten * 3 Stimmen ( ich schätze, bei dem Demo sind es 3 Stimmen ) =2460 Noten Die 2KByte ( bei 1Byte=1Note, Kodierung: 2 Bit Notenlänge, 6 Bit Tonhöhe ) könnten also stimmen. Bleibt allerdings zu erwähnen, dass der Programmcode mit Synthesizer+Grafikausgabe auch noch rein muss.
Kleiner Tip: Einfach mal in den Sourcecode schauen, das erspart viel Rumraterei...
Vielleicht versteht ja jemand den Code, das einzige was ich erkenne ist, dass er die Daten anscheinend aus dem EEPROM läd und dass die Daten anscheinend irgendwie komprimiert sind.
> Synthesizer+Grafikausgabe
Die Klänge werden wohl nicht synthetisiert, sondern sind Samples, die
abgespielt werden. Wie auch immer... alles in allem (Musik + Grafik) ist
das schon eine Leistung das alles in einem ATmega88 unterzubringen. Ich
wüßte schon gerne welche Tricks und Kniffe da eingesetzt werden.
@Benedikt
Hab leider keine Zeit mir den Sourcecode anzusehen. Davon abgesehen kann
ich kein Assembler :(
Gruß
Christoph
Christoph Borowski wrote: >> Synthesizer+Grafikausgabe > > Die Klänge werden wohl nicht synthetisiert, sondern sind Samples, die > abgespielt werden. Denk mal drüber nach, wie groß 3:30 Minuten bei sagen wir mal 8kHz Samplrate sind...
@Benedikt Ich meinte eher sehr, sehr kurze Samples und nicht ein 3:30 Minuten langes Sample. Ist aber auch egal... auch sehr kurze Samples würden den Rahmen sprengen. Auf der Website steht zum Sound folgendes: "There are four sound channels in total, each with its own fixed waveform. The waveforms are 4-bit triangle, 50% pulse, 75% pulse and white noise. The noise is generated by means of a 15-bit shift register. The volume of each channel can be individually controlled, except for the triangle channel, which is always playing at full volume. This minimalistic softsynth was of course inspired by the NES sound chip." Es werden also Wellenformen (triangle, pulse, white noise) generiert. Also Basiswellenformen eines subtraktiven Synths. Gruß Christoph
cornu wrote: > OK, ich versuche es auch mal abzuschätzen: > > 4 Noten/Sek > 210 Sekunden > =820 Noten > * 3 Stimmen ( ich schätze, bei dem Demo sind es 3 Stimmen ) > =2460 Noten > > 2KByte ( bei 1Byte=1Note, Kodierung: 2 Bit Notenlänge, 6 Bit Tonhöhe) Machen wir mal eine Abschätzung für DVDs: 2 Byte/Pixel * 720*576 Pixel (PAL) * 25 Bilder/Sekunde * 2 Stunden = 140GB pro Film Tolle Abschätzung >Die Klänge werden wohl nicht synthetisiert, sondern sind Samples, die >abgespielt werden. Sicher nicht, die Samples würden zu viel Platz brauchen
>Tolle Abschätzung
Hast Du Dir schon mal überlegt, welche Komprimieralgorithmen in einem
DVD-Player sind? Hast Du Dir den Source Code für den Atmega8 schon mal
angeschaut?
Ich würde mal sagen: eher nicht!
>>Die Klänge werden wohl nicht synthetisiert, sondern sind Samples, die >>abgespielt werden. >Sicher nicht, die Samples würden zu viel Platz brauchen Es ist ein mehrstimmiger DDS-Synthesizer implementiert.
Die Codierung der Tracks dürfte folgende sein: resource 0 = song resource 1 = instrument 1 ... resource 15 = instrument 15 resource 16 = track 1 ... resource table: xxxxxxxxxxxxx = byte offset into songdata (for each resource) song: 0xxxxxx = track x, transp 0 1xxxxxxyyyy = track x, transp y (signed) (times four, for each line) instrument: 00000000 = end 0000ccccpppppppp = command c, parameter p (for each cmd) track: 000 = blank line 100xxxxxxx = note x, instr 0 (last) 110xxxxxxxiiii = note x, instr i 001ccccpppppppp = cmd c, param p 101xxxxxxxccccpppppppp = note x, instr 0 (last), cmd c, param p 111xxxxxxxiiiiccccpppppppp = note x, instr i, cmd c, param p (for each line) Sehr sparsam ....
Bestimmte Melodieteile wiederholen sich immer wieder -> müssen nur einmal gespeichert werden. Die Demo ist super, Das Optimum aus dem Chip geholt - keine Chance in C oder Bascom :-)
cornu wrote: >>Tolle Abschätzung > > Hast Du Dir schon mal überlegt, welche Komprimieralgorithmen in einem > DVD-Player sind? Hast Du Dir den Source Code für den Atmega8 schon mal > angeschaut? Bei 130 Pixel vertikal und 170 Pixel horizontal bei 64 Farben
1 | 130 * 170 * 6 Bit * 60 (Hertz) * 3:40 min = 208 MB |
bei tatsächlichen 8 kB ist das immerhin ein Verhältnis von 26.000.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.