Hallo Besucher, der Thread wurde 2,6k mal aufgerufen und enthält 55 Antworten

letzter Beitrag von atomcode am

Vorstellung einer Idee: PAL-Musik auf NTSC.

    Ich will hier mal eine Idee vorstellen, die ich für mein "Stoneage64" Spiel umgesetzt habe, und eventuell "fortspinnen"...


    Vorher aber zum Hintergrund: Der SID leidet ja am vermutlich allseits bekannten ADSR-Bug: Wenn man einen neuen Ton (gate-bit) startet, ist der Hüllkurven-Generator noch in "irgendeinem" Zustand, was dann herauskommt ist mehr zufällig als sonst was (man kann es ganz sicher berechnen, und frühe Composer haben sich ja damit herumgeschlagen, ihre "Instrumente" so zu bauen, dass das irgendwie passt und nach was klingt). Man hat dann herausgefunden, dass man als Workaround "gate" mehrere Frames auf 0 lassen kann (quasi eine Mikro-Pause) und so lange ADSR auch auf 0000 lässt. Danach startet es wieder sauber. Der Workaround nennt sich "Hard Restart".


    Nun gibt es ja auch die "moderne" Form das "Hard Restart", bei der ADSR während der Pause (2 Frames) auf einen anderen Wert (oft 0F00) gesetzt wird, gefolgt von einem Frame mit aktiviertem Test-Bit und den tatsächlichen ADSR-Werten des Instruments. Was da intern im SID passiert weiß ich nicht :nixwiss: (kann vielleicht ein SID Experte erklären), aber Resultat ist, dass man auf die Art ungeahnt "scharfe" Starts von Sounds hinbekommt, insbesondere für glaubwürdige Drums natürlich sehr hilfreich. Der Pferdefuß dabei: DAS funktioniert nur mit "PAL-Timing" (also 50 SID-Writes pro Sekunde) korrekt.


    Sollte ich bis hierhin Mist verzapft haben, bitte gerne korrigieren. 8|


    Nun zur Idee: Warum nicht auch auf einer NTSC-Maschine diese Technik anwenden, und die Musik "einfach" mit "PAL-Timing" abspielen? Da ich oft meinen eigenen Player-Code (also keinen Tracker) verwende, war es in der Tat nicht SO kompliziert:


    Der eigentliche Player schreibt in Shadow-Register, wird wie gehabt ein mal pro Frame aufgerufen, wertet aber zusätzlich ein Flag aus, in dem steht, ob die zuletzt berechneten Werte schon "rausgeschrieben" wurden. Wenn nicht, tut er nichts:

    Code
    1. snd_step:
    2. lda stepdone
    3. bne play_done
    4. lda #1
    5. sta stepdone
    6.                 [..., eigentlicher player-code]

    Dazu gibt es eine Routine nur fürs rausschreiben der Shadow-Register, die wird 5 mal pro Frame aufgerufen, und zwar an Raster-Positionen, die auf NTSC gleich weit voneinander entfernt sind. DIE hat einen Counter, so dass sie nur bei jedem 5. Aufruf etwas tut:

    Code
    1. snd_out:
    2. dec outcount
    3. bmi so_do
    4. so_dont: rts
    5. so_count = *+1
    6. so_do: lda #4
    7. sta outcount
    8. lda #0
    9. sta stepdone

    Das einzige was dann noch nötig ist: NTSC detecten, wenn auf NTSC, den Counter per self-mod so erhöhen, dass die Routine nur bei jedem 6. Aufruf etwas tut (also hier: lda #5; sta so_count).


    Das ganze funktioniert wirklich hervorragend :thumbsup: ... kostet natürlich ein wenig zusätzlich "rastertime".


    Ich habe mich nun gefragt, ob es sich lohnen könnte, so etwas auch um das "übliche" Interface (ne play-routine die eben einmal pro Frame aufgerufen wird und "alles" macht) herum zu basteln? Das würde natürlich NOCH mehr extra Rastertime kosten, aber vielleicht könnte es im ein oder anderen Fall lohnenswert sein? Allzu komplex sollte das nicht werden, man nutzt im Prinzip den Code oben, "wrappt" aber die originale Play-Routine so, dass die Writes im RAM statt in den echten Registern landen, dann kann man sie direkt danach woanders hin kopieren und mit snd_out schließlich ausgeben. Man könnte damit aber im Tracker seiner Wahl Musik schreiben, die EIGENTLICH nur für PAL ist, und trotzdem auf NTSC verwenden ...

    Der "überwältigenden Resonanz" entnehme ich eines von zwei möglichen Dingen:

    • Ich hab hier ein Problem gelöst, das in der Praxis keines ist? Also, in die Richtung, wer hat schon NTSC, bzw wenn mein Tune beides supporten soll verzichte ich halt auf den "hard restart mit test bit"?
    • Meine Lösung ist zu kompliziert oder unpraktisch für viele Anwendungsfälle?

    Könnt ihr mich vielleicht noch aufklären, was davon zutrifft? :/

    Zitat von Zirias/Excess

    Ich HÄTTE jetzt mal so naiv angenommen, dass das im (ASM) coding Bereich eines C64 Forums nicht so GANZ repräsentativ ist :D

    Viele User sind 50+ und müssen noch min. einen Tag arbeiten. Danach sieht es mit der Beteiligung bestimmt besser aus. ;)

    Ja, ist ein bisschen speziell das Thema. Ich habe zwar schon Musik auf PAL und NTSC programmiert, aber nie mit eigener Playerroutine. Das Thema würde im csdb-Forum vermutlich mehr Resonanz finden.

    Okay ... vielleicht hab ich es nicht gut genug erklärt :huh::(


    In a nutshell ging es mir darum, diese super-scharfen Sounds, die man mit dem "modernen Hard-Restart" (den übrigens auch der Goattracker per default macht) haben kann, auch auf NTSC haben zu können :nixwiss:


    Und da die halt nur mit "PAL-timing" (also, genau 50 mal pro Sekunde die SID-Register schreiben) wirklich klappen, war dann die Idee, dieses Timing auf NTSC zu faken, indem man eben an verschiedenen Raster-Positionen schreibt.


    Ich fürchte fast es ist jetzt nicht so viel klarer geworden? Vermutlich bin ich echt schlecht im erklären :-(

    Okay, ich sag noch so viel dazu: Meine Idee ist eigentlich massiv banal (die Hintergründe wozu sie überhaupt gut ist sind es allerdings in der Tat nicht). Ich hab wenig Lust, das ins csdb Forum zu tragen, und ich würde mich auch nicht wundern, wenn schon jemand anders genau das gleiche gemacht hätte 8o

    Zitat von Parser

    P.S.: Dann müsstest du aber schon sehr, sehr tief in das C64 Mapping einsteigen.

    Eigentlich nicht. Alles was grafisch nicht GANZ trivial ist, ist auf Interrupts vom VIC angewiesen. Und wenn du dann ne zweite Interrupt-Quelle (CIA timer) hast, zerschießt dir das alles. Ja, auch wenn du das sauber behandelst und differenzierst. Es hilft ja nix, es wird immer dafür sorgen, dass der ein oder andere IRQ vom VIC "zu spät" behandelt wird, damit ist die Grafik kaputt :nixwiss:


    Daher: Musik spielen MUSS über Interrupts vom VIC gesteuert werden. Und da muss man sich dann halt was einfallen lassen, wenn man "PAL-timing" auf NTSC will. Das ist gar nicht so besonders komplex, aber nur genau darum ging es mir hier :-D

    Zitat von Zirias/Excess
    Zitat von Parser

    P.S.: Dann müsstest du aber schon sehr, sehr tief in das C64 Mapping einsteigen.

    Eigentlich nicht. Alles was grafisch nicht GANZ trivial ist, ist auf Interrupts vom VIC angewiesen. Und wenn du dann ne zweite Interrupt-Quelle (CIA timer) hast, zerschießt dir das alles. Ja, auch wenn du das sauber behandelst und differenzierst. Es hilft ja nix, es wird immer dafür sorgen, dass der ein oder andere IRQ vom VIC "zu spät" behandelt wird, damit ist die Grafik kaputt :nixwiss:


    Daher: Musik spielen MUSS über Interrupts vom VIC gesteuert werden. Und da muss man sich dann halt was einfallen lassen, wenn man "PAL-timing" auf NTSC will. Das ist gar nicht so besonders komplex, aber nur genau darum ging es mir hier :-D

    Einfach den VIC und die Grafik ausschalten ... das geht am C64 meines Wissens. :D

    Zirias/Excess: Bist Du Dir sicher, dass die Grundannahme "Hard-Restart geht nicht mit 60-Hz-Rasterung" zutrifft?


    Immerhin gibt die ja eine höhere Auflösung als die 50 Hz bei PAL, und der Hard-Restart hat, soweit ich weiß, eine Mindestdauer, aber keine Obergrenze der Dauer.


    Unb bei Artefacts (existiert in PAL- und NTSC-Inkarnationen) hat Fanta, soweit ich das sehe, auch das "Testbit" für Hard-Restart in einigen Instrumenten benutzt. =)

    (Und auf NTSC wird da auch nur ganz billig der Player bei jedem 6. Videoframe einfach nicht aufgerufen.)

    Ich habe leider vom SID 6569 so gut wie keine Ahnung, ich glaube, so geht es den meisten hier. Es ist heute relative selten, das sich ein Coder auch gut mit SID/CO auskennt, umgekehrt die Musik/FX Leute mit dem Coding selber auskennen. Aber BeRo der Programmierer des Micro64 Emulator, könnte bestimmt viel zum Thema schreiben. Hätte damals kurz mit ihm über das Forum hier Kontakt als er noch aktive beim Entwickeln des Emulator war. Dabei ging es unter anderen um die Titelmusik von Wizball, die mit einer späteren Version des Emulator etwas schräg klang. Daraufhin baute er im Emulator die Option SID brightness ein, damit klingt der Tune bei 75% wieder OK. Wenn ich mich nicht irre hat er auch Beruflich mit Musik zu tun, leider ist er nicht mehr aktive. Aber der Coder PiCiJi von Denise hier im Forum, könnte bestimmt etwas dazu schreiben. Verlink doch mal deine Frage hier.


    Denise 1.0.x Emulator

    Zitat von Zirias/Excess

    Und da die halt nur mit "PAL-timing" (also, genau 50 mal pro Sekunde die SID-Register schreiben) wirklich klappen, war dann die Idee, dieses Timing auf NTSC zu faken, indem man eben an verschiedenen Raster-Positionen schreibt.

    Damit noch ein bisschen Resonanz zusammenkommt (ja, es soll berufstätige geben ;-)): ich habe im SIDKick-Config Tool ähnliches gemacht wie Du: es gibt ein paar Rasterbereiche im Frame in denen Zeit ist für den Player, und bei NTSC springt der Aufruf zwischen diesen Slots so, dass es zu Aufrufen nach einigermaßen stabilen 20ms auch bei NTSC kommt (es ist hier eben nur der ganze Player, nicht ausgewähltes wie bei Deinem Vorschlag).