Spiel in Arbeit: 8192

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...

Mal zum Vergleich die Variante mit nur 1x Sound player -- gefällt mir persönlich besser :o

Dankesehr!

Zitat von lemon03

Der Song kommt mir bekannt vor.

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

Zitat von lemon03

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.

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.

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

Zitat von Lynx(TRIAD)

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.

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)

Zitat von Sokrates

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...

Zitat von Sokrates

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!

Zitat von Sokrates

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

Zitat von Sokrates

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.