Spiel in Arbeit: 8192

  • Neu

    So, inzwischen gibt's Code, der Musik abspielt, jetzt doch komplett "zu Fuß" gebaut. Bei der Musik mache ich sehr gern ungewöhnliches, entsprechend finden es sicher manche furchtbar. Wer schon mal reinhören will, ich hänge mal einen aktuellen debug-build an (mit "sichtbarem" IRQ). Das Tune ist noch lange nicht fertig, daher wird es sicher relativ schnell nervtötend (wiederholt sich viel zu früh) :)

    Bin am überlegen, ob ich doch 3 Channels nutze, das würde bestimmt organischer klingen -- im Moment sind es nur 2. Irgendwann später sollen noch Soundeffekte rein und dann muss man abwägen -- solange einen Channel der Musik "klauen" oder von vorneherein einen freilassen ... hmmmm.

    edit: blöden Bug gefixt. Jetzt muss ich mir noch überlegen ob ich mit dem Sound vielleicht doch auf "nur" 1x gehe...
    Dateien
    • 8192_DEBUG.prg

      (3,52 kB, 7 mal heruntergeladen, zuletzt: )

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von zrs1 () aus folgendem Grund: Bugfix

  • Neu

    Nicht schlecht. Der Song kommt mir bekannt vor. Wie hast Du die Abspielroutine gestaltet? Einen Notensatz genommen/geschrieben und dann halt die Noten nach Vorlage abgespielt, oder so mehr die SID-Register, oder wie man das in asm nennt, direkt angesprochen?
  • Neu

    Dankesehr!

    lemon03 schrieb:

    Der Song kommt mir bekannt vor.
    uhhh... ich hoffe ich habe nicht etwas "nachkomponiert" was ich unterbewusst kenne :o sowas kommt vor...

    lemon03 schrieb:

    Einen Notensatz genommen/geschrieben und dann halt die Noten nach Vorlage abgespielt, oder so mehr die SID-Register, oder wie man das in asm nennt, direkt angesprochen?
    Die Frage ist mir jetzt nicht so ganz klar, man bekommt ja immer nur Töne aus dem SID indem man in seine Register schreibt ;) Man überlegt sich, wie man die Song-Daten im Speicher ablegt und schreibt eine Routine die aus den Daten bei jedem Aufruf berechnet, wie die Register geändert werden müssen.

    Ursprünglich wollte ich goattracker verwenden, dachte dann mein geplanter 9/8 takt würde damit nicht gehen --- wurde hier im Forum eines besseren belehrt, aber da ich schonmal angefangen hatte hat es mich dann gepackt, den Player-code doch selbst zu schreiben. Bei den Songdaten habe ich mich grob daran orientiert, was goattracker macht, aber ohne in den Source zu schauen :)

    Vom Vorgehen her hab ich den Player-code parallel zum Musik schreiben gebaut und erste Tests schon durchgeführt sobald das abarbeiten einer "wavetable" für die Instrumente implementiert war.
  • Neu

    Die Begleit-Arpeggios waren mir etwas zu dominant und ich wollte sie filtern -- natürlich leider mit inakzeptal unterschiedlich klingendem Ergebnis je nach verwendetem SID (6581 oder 8580). Also musste eine SID-Erkennung mit rein. Wäre nett, wenn das mal noch jemand checken könnte; ich bin mir nicht sicher, ob das absolut zuverlässig funktioniert. Der angehängte DEBUG build zeigt das erkannte SID Modell auf dem Bildschirm an.
    Dateien
  • Neu

    Noch ein kleines Update: Soundeffekte ;)

    Die SID-Erkennung habe ich nochmal ein wenig vereinfacht. Zum Einsatz kommt die klassische Methode, die Oszillator-Ausgabe von Triangle + Sawtooth zu checken, die beim 6581 sehr "leise" ist. Oszillator 3 wird 2048 mal ausgelesen, sobald dabei mindestens 9 mal ein Wert > 0x7f auftritt wird ein 8580 erkannt, ansonsten ein 6581. Im Vice mit ReSID funktioniert das hier absolut zuverlässig -- über Hinweise, ob es auf echter Hardware Fehler gibt, wäre ich dankbar :)

    Quellcode

    1. ldx #$18
    2. lda #$0
    3. si_clearsid: sta SID_FREQLO1,x
    4. dex
    5. bpl si_clearsid
    6. lda #$02
    7. sta SID_FREQHI3
    8. lda #$30
    9. sta SID_CR3
    10. ldy #$08
    11. sty tmp
    12. ldx #$0
    13. si_testloop: lda SID_OSC3
    14. bpl si_nopeak
    15. dec tmp
    16. bmi si_is8580
    17. si_nopeak: dex
    18. bne si_testloop
    19. dey
    20. bne si_testloop
    Alles anzeigen
    Dateien

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von zrs1 ()

  • Neu

    Lynx(TRIAD) schrieb:

    Ich hoffe,man kann es erkennen?
    Ja, danke! Ist das im VICE? Und das Modell vor dem Start eingestellt? Ist bei mir nie passiert :o dann muss ich vielleicht den Grenzwert raufsetzen -- beim 8580 würde ich ja erwarten, dass ca. die Hälfte der OSC3 reads > 0x7f ist -- beim 6581 sollten eigentlich alle werte darunter liegen, aber hatte schon irgendwo gelesen, dass auch der 6581 hin und wieder einen Wert >0x7f produziert.
  • Neu

    Ein Missverständnis: ich meinte alte VICE-Versionen. Könnte natürlich schlicht und einfach eine fehlerhafte Detektion sein. Gegentest wäre die Detektion aus meinem Link auf Deiner Konstellation auszuprobieren...
    Sokrates - das F steht für Philosoph!
  • Neu

    Also falls es nur wegen einer ungenauen Emulation in nem alten VICE schiefgeht passe ich nichts an. Um sicherzugehen habe ich mal schnell die detect-Routine in ein separates Progrämmchen gesteckt, das auch die Anzahl der gelesenen Werte über $7f ausgibt, vielleicht mag das mal jemand ausprobieren?

    Sieht bei mir im VICE so aus (zwischendurch Modell geändert) -- sind beim 8580 deutlich weniger als ich vermutet habe:
    hw.png

    Eine Lehre hab ich schon aus dem Progrämmchen, es macht zumindest im VICE den "umgekehrten" Fehler. Anscheinend sind 2048 Testwerte nicht ausreichend, wenn ich das vervierfache scheint es stabil, im VICE. (edit: entsprechend verbesserte Version angehängt)

    Sokrates schrieb:

    Gegentest wäre die Detektion aus meinem Link auf Deiner Konstellation auszuprobieren...
    Da bin ich mir nicht sicher, da das eine ganz andere Methode ist. Wenn die auf der Emulation versagt lässt das wohl keinen klaren Rückschluss zu...
    Dateien
    • siddetect.prg

      (181 Byte, 1 mal heruntergeladen, zuletzt: )

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von zrs1 ()

  • Neu

    zrs1 schrieb:

    Da bin ich mir nicht sicher, da das eine ganz andere Methode ist. Wenn die auf der Emulation versagt lässt das wohl keinen klaren Rückschluss zu...
    Wenn die andere Detektion funktioniert könntest Du dann auf diese umschwenken. Aber ich merke schon: Du bist hoch motiviert Deine Variante stabil zu machen, was ja schön ist!
    Sokrates - das F steht für Philosoph!
  • Neu

    Sokrates schrieb:

    Aber ich merke schon: Du bist hoch motiviert Deine Variante stabil zu machen
    Die prinzipielle Idee hier war, dass die vermutlich "emulationsfreundlicher" ist. Beim 6581 kommt recht wenig raus, wenn man Triangle und Sawtooth kombiniert; da das etwas hörbares ist, sollte es in einer gescheiten Emulation genauso sein. Die von dir verlinkte Variante ist wesentlich eleganter und schneller, hängt aber von Cycle-genauem Verhalten des Chips ab, da würde ich eher mehr Emu-Probleme erwarten. Falls es sich am Ende sowieso nichts nimmt könnte ich mir durchaus vorstellen, doch diese neuere Variante zu nehmen. Erste Priorität hat sowieso die korrekte Erkennung echter Hardware, das kann ich leider gerade nicht ausprobieren (habe nur einen Brotkasten mit 6581 zur Verfügung und den müsste ich erst mal wieder in Betrieb nehmen). Daher bin ich hier recht froh über Feedback!
  • Neu

    zrs1 schrieb:

    Die prinzipielle Idee hier war, dass die vermutlich "emulationsfreundlicher" ist.
    Wenn Deine Methode auch mit FastSID funktioniert, wäre das in der Tat eine Verbesserung!

    zrs1 schrieb:

    Daher bin ich hier recht froh über Feedback!
    Ich könnte es für Dich an realen C64 ausprobieren...
    Sokrates - das F steht für Philosoph!
  • Neu

    Sokrates schrieb:

    Wenn Deine Methode auch mit FastSID funktioniert, wäre das in der Tat eine Verbesserung!
    Das nun leider nicht (gerade getestet, da war meine Annahme von oben wohl leider falsch), ist auch nicht "meine" Methode sondern eine kleine Anpassung einer recht alten Methode ... nunja

    Sokrates schrieb:

    Ich könnte es für Dich an realen C64 ausprobieren...
    Vielen Dank! Wird wohl nicht mehr nötig sein, ein anderer User hat mir per PM erklärt, dass diese alte Methode selbst auf manchen echten Maschinen versagt. Daher wird's dann wohl doch der cycle-genaue Check aus codebase64. Ich poste ein neues D64 wenn's fertig ist. Das sollte dann zumindest auf realer Hardware absolut zuverlässig sein und immerhin mit aktuellem ReSID tun.
  • Benutzer online 1

    1 Besucher