PlayEm64

So, nachdem ich lange alle Musik-Collection Freaks vertröstet habe, ist hier jetzt endlich mal wieder was in Sachen SID von mir, und zwar ein real hardware player, der es dem User erlaubt, sich selbst Collections direct mit Drag & Drop (Zwischenschritt: .SID in .PRG umbenennen) aus der HVSC zu erstellen, so gesehen ein Music Collection Construction Kit, so dass es eigentlich fast gar nicht mehr nötig ist, Collections zu releasen. Ihr findet trotzdem einige ready to use Collections, besonders die Inhaber von SD2IEC, 1581 & Co dürfen sich auf drei Collections mit jeweils 128 Files freuen, um das durchzuhören, braucht man schon ein paar Tage.

In den Docs wird so ziemlich alles erklärt, hoffe ich.

Viel Spaß!
http://csdb.dk/release/?id=130072

Edit: hier ein Screenshot

Es wird aktuell an einem Software-Update gearbeitet. Ich werde weitgehend wieder egoistisch vorgehen, d.h. so an der Software feilen, dass ich selbst sie praktischer finde. Aber ich bin natürlich - ohne was versprechen zu können - auch offen für Wünsche von Usern.

Schrecklich viel wird nicht gehen, da wegen Universalitätsanspruch (auch möglichst viele sehr große SIDs, die wo-auch-immer-im-RAM rangieren, abspielen können) nicht unendlich RAM zur Verfügung steht, sondern vermutlich nach Entrümpelung des 1.0 Wurstcodes eher 100 +/- X zusätzliche Bytes oder so.

Um Enttäuschungen oder unrealistischen Wünschen vorzubeugen, erstmal...
Was eher nicht angedacht ist:
- einschneidende Änderungen bei Controls, wird wohl bei der Tastaturecke links oben bleiben, ist schön billig via CIA1 abzufragen
- Eingriffe in die Headerstruktur der Custom-Files (die mit dem "!" als 4. Character im Filename, SFX-exomized Files mit vorgeschaltetem SID-Header, der noch erweitert wird um 30 bytes für mx 15 Songlengths, 1 range byte und 1 hardcoded speed-byte, falls CIA-Register mit meiner Formel keinen plausiblen Wert ausspucken), die einen Gebrauch von 1.0 Custom Files unmöglich machen
- Anpassung für NTSC Maschinen, NTSC tunes werden zwar auf PAL in so-gut-wie-richtiger Geschwindigkeit abgespielt, aber eine Version für Übersee, die das auch umgekehrt tut, ist aktuell nicht geplant
- Reines Gedöns wie Customize Color Scheme oder sowas wird es nicht geben, klar ist das toller Spielkram, frisst aber unnötig RAM.
- Software-Speeder-Kram oder gar Trackloading oder Fancy Hardware Support, es bleibt definitiv ausschließlich bei KERNAL-Load, fluppt entsprechend 1-A auf einem Haufen Hardware wie real drives, SD2IEC, Action Replay, Jiffy DOS. Mit REU-Support oder so kann und will ich mich nicht aufhalten momentan.

Bisher weit oben auf dem Zettel für "1.1":
- Optimierungen zwecks RAM-Ersparnis, ohne wird auch von den nachfolgenden Punkten nichts gehen
- Control-Bremse für Multispeed-Tunes anpassen (im Moment geht das Menu bei 16x tunes eher ab wie Schmitz Katz, wenn man browst)
- Shuffle verbessern, ist aktuell vieles, aber nicht zufällig
- Derzeitige Holzhammer-Lösung überarbeiten, die verhindert, dass der Player sich selbst laden will (last 3 Characters of Filename Quersumme "MYD" führt natürlich auch bei anderen Kombinationen zu Trouble, hehehe)
- Directory Handling verbessen, mehr als 128 Files behandeln können (bei .D81 durchaus sinnvoll), Option sich Directory genauer ansehen zu können als im Menu
- kleinere Fixes bzgl Sonderzeichen in Whatever Language -> PETSCII Display (sehr vieles wird bereits lesbar gefixt, aber so bei 2 bis 3 Zeichen in skandinavischen und slawischen Sprachen kommt noch Gemüse, gern berichten, falls Euch was auffällt)

Eher für übernächsten Release zu überlegen:
- Self-Relocating des Players, um ne noch größere Range im unteren Speicher abzudecken (aktuell geht afair reines .SID-File ab $1000, Custom File ab $0F60, wäre natürlich geil, wenn da auch Kram bei $0800 oder $0400 ginge, aber ob das dieses Mal schon was wird, seh ich noch nicht, dank SidReloc hat das aber auch stark an Bedeutung verloren)

Unschlüssig bin ich mir aktuell, was Samples/Digis ("Play $0000") Files angeht. Klar ist es geil, die abspielen zu können, aber auf Images, die mit Funktionen Shuf/List genutzt werden sollen, stören diese Files eh nur in der Playlist, da die Spieldauer nicht richtig zuverlässig berechtigt werden kann bzw sogar jegliche Kontrolle verloren geht und die Abspielroutine nur noch über RESTORE/Pseudo Soft Reset abgebrochen werden kann. Im Verhältnis zu ihrer Häufigkeit sind diese Files eigentlich ein ziemlicher Pain in the Ass, da selbst ihre rudimentäre Behandlung durch mich RAM frisst, das ich persönlich für sinnvolleres gebrauchen könnte. Und um z.B. auf ner Party auf die Schnelle irgendein Sample/Digi abzuspielen (was nachher sowieso in seiner eigenen Playroutine festhängt) kann man ja auch immer noch PlayIt nehmen.

Eure Ideen und Wünsche sind - jenseits des oben stehenden - wie gesagt willkommen!

tulan und SID-Spieler bzgl Barbarian/List Mode
Das läuft grundsätzlich wie es soll, und zwar im Listmode wie folgt:
Bis zu 15 subtunes werden jeweils beginnend bei 1 und endend beim höchsten (mx 15) entsprechend der individuellen Playing Length abgespielt.
Warum ist das bei Barbarian spooky?
Weil die Init des SID-Files 3 subtunes und eine Menge Jingles aufweist. Die 3 Subtunes sind aber immer das gleiche Lied, nur an unterschiedlichen Stellen begonnen. Wenn einen das stört oder wenn man z.B. das Abspielen von Jingles verhindern will, müsste man z.B. per SID-Edit die Zahl der Subtunes manipulieren.
Im Shuf Mode läuft das anders, dort wird nur der Default Tune durchgespielt, bevor in das nächste File gesprungen wird.
Richtig ist der Hinweis, dass Samples (Play Address $0000) z.T. hängen bzw. zu Problemen führen, große Ausnahme sind die SoundMon/RockMon Dinger.
Trifft aber auf Barbarian nicht zu, multi speed tunes machen keine Probleme, selbst dieser Multispeed Tune hier
http://hvsc.perff.dk/MUSICIANS/L/Linus/Winterland_Hades.sid
wird fehlerfrei gehändelt inklusive richtig tickender Uhr, obwohl er kaum Rasterzeit ungenutzt lässt.

@Onebitman/Wie Playing Time reinkriegen...
Ich poste hier mal Source, wie man die Custom Files erstellt inklusive Special Header. Mich wundert eigentlich selbst, dass ich das noch nicht bei Release im ZIP hatte, egal hier ist es.
Wer damit rumspielen mag, möge dieses hier nehmen
http://hvsc.perff.dk/MUSICIANS/C/Clarke_Peter/Gunstar.sid
Das ist mein verbesserter Hack des großartigen Game tunes für die letzte HVSC (um etliches kürzer als älterer RIP und kein Out-of-Bonds-Schreibzugriff mehr)
Die Playing Time erhält man aus Songlengths.TXT in den Documents der möglichst aktuellen HVSC (an den Daten wird permanent optimiert)

Einfach ist anders, man muss schon ein paar Schritte hier händisch durchführen, jeweils mit der Möglichkeit Fehler reinzupfuschen, das ist klar, evtl wird dafür mittelfristig mal eine GUI gebaut.

Mal wieder eine Wasserstandsmeldung...

VCFB Party ist vorbei. Die war ja nunmal der Anlass fürs Update. Die V1.1 kam dort bereits zum Einsatz und tat ihren Dienst einwandfrei. Allzu viel Feedback von Userseite kam ja leider nicht. Ist aber auch nicht tragisch, da ich nur sehr limitiert Bytes gefunden habe, konnte ich mich fast nur um echte Probleme der V1.0 kümmern. Hauptsächlich machten .SID-Files Probleme, deren Subtunes teilweise multi-speed/CIA und teilweise 1xspeed/VIC timed sind. Diesbzgl bin ich zufrieden mit dem, was ich geschafft hab. Zumindest indirekt damit zusammenhängend konnte ich meine sogenannte Clock auch noch mal fixen (frame-counter-based). Die anderen Punkte betrafen mehr oder weniger Optimierung (Spaghetti-Shice entwuseln) und Display.

Changelog (sieht nach wenig aus, kostete aber gefühlt schon die Abende/Nächte mehrerer Wochen, bis nix mehr schepperte)

Aktuell testen Thunder.Bird und ich die Version 1.1 noch, daher halte ich die Version noch unter Verschluss.

Bisher stellte sich nur raus, dass es auf irgendeinem "Super(?)"-JiffyDos-KERNAL Probleme gibt. Mit JiffyDOS 6.01 läuft es tadellos. Da mir Thunder jenes KERNAL so beschrieben hat, dass dort Tape Support gänzlich rausgeflogen ist, dürfte die Inkompatibilität mit TapeBuffer Usage zusammenhängen, nichts, wofür ich nun unbedingt begeistert einen Finger krumm machen würde, auch wenn ich Ideen hätte, wie... Für 12 oder mehr Hardware Settings jeweils Einzelversionen raushauen wie die "Konkurrenz" werde ich nicht machen.

In Sachen User-Friendliness wird wohl außer einem Manual Update nicht viel passieren in der V1.1. Ich hatte mir ursprünglich mehr vorgenommen, könnte sicher noch Wochen und Monate weiter fixen oder alles platt machen und from scratch neu coden (mittlerweile erscheint das sinnvoller, weil mittlerweile selbst durch Optimierung Probleme entstehen, weil Routinen oder Tabellen über Page-Grenzen rutschen), aber wahrscheinlicher ist, dass ich in den nächsten Tagen und Wochen eher mal wieder geile Images zusammenstelle für die User, die das Teil einfach nur als Music Collection nutzen (dürfte die Mehrheit sein), und - wenn das Testing keine ganz schlimmen Probleme offenbart - die V1.1 im VCFB-Party-Status irgendwann im Oktober raushaue und mich dann erstmal wieder anderem in der Projekt-Pipeline widmen werde. Also stay tuned...

Paar Gedanken mit Blick auf künftige (wie gesagt evtl from scratch neu zu codende) Versionen
- Crunching-Optionen kommen aus ner Zeit, als ich selbst noch überwiegend mit Vanilla-Setting rumhing. Ich habe immer noch ein Herz für real disk drives, aber auf unreal hardware (SD2IEC etc) geht das Laden eh blitzschnell mit entsprechendem Speeder und so'n .D81 soll man erstmal voll kriegen. Das Decrunching dagegen dauert je nach Filesize Sekunden, stört also fast mehr, als es nutzt, mal abgesehen davon, dass es für User ohne viel Erfahrung mit Exomizer ne weitere Hürde darstellt. Evtl führe ich zusätzlich zum "!" Custom File noch ein "#" Custom-File ein und rotze dafür auch noch nen nativen (auf C64 lauffähigen) Editor raus, den man nur mit .SID-Files füttert und dann die 30 bytes PlayingTime reinhämmern darf (vgl. den Editor von PlayIT)
- JSR $0000 aka Sample Files sind so oder so "a pain in the ass". Für deren Handling habe ich viel zu viel RAM geopfert, würde ich zukünftig eher zurückfahren oder sogar ganz rausschmeißen, der Trend wird bestätigt durch GRG's SidPlay64, dort gibt es bereits die Option "Ignore all JSR $0000".
- Andere jetzt noch nicht erledigte Punkte aus Posting #2 lassen sich vmtl besser from scratch realisieren als in weitere Patches/Fixes des aktuellen Sourcecodes einpflegen.

@GenCBM: Gegen other platform tools kann ich natürlich innerhalb von weniger paar Tausend Byte auf real C64 nur bedingt anstinken. Zurückspulen ist aufgrund der Struktur eines .SID-Files nicht trivial, kann meines Wissens auch ein per PSID64 (other platform tool) generiertes File nicht. Vorspulen i.S.v. "Fast Forward" ist schon eher denkbar. Hab ich auch schon mal drüber nachgedacht, einfach so i.S.v. KeyPress->Innerhalb des Frames Frame Counter Hochzählen und nochmal in die Playroutine springen.

Tom-Cat:

Zitat

What is better

Nothing. GRG's tool is indeed great and - among other reasons due to self-relocating - has a higher rate of files it can play, so in terms of universal player and all the special hardware support SidPlay is superior to PlayEm and probably always will be. In fact I did not know of SidPlay64 at all when I started coding PlayEm but finished it nevertheless, btw GRG himself encouraged me to do so. I am aware that not a great group of people use PlayEm64, however. As I made it mainly for myself, user friendliness is really an issue.

What's different is that you can use customized crunch files and fill up to 15 subtunes' playing time from HVSC-Songlengths.TXT and thus, make disks or images with your favorite music played either tune by tune or at random. I also know people who wouldn't use PlayEm as their favourite real hw SID-Player but like using the ready-to-use .D81 or .D64 Images as music collections. Check those out and select List or Shuf Mode via CTRL and you see the difference.

I would never talk anyone out of preferring GRG's SidPlay, though. But since I made an update and trust that a fistful of people beside myself might use it, why should I keep the update for myself.

Okay, V1.1 Beta (Vgl Posting #9) wird nicht releast, sondern bleibt unter Verschluss/"rar"/exklusiv für VCFB/wird sicher mal Zillionen Quatlos wert sein, wenn es jemand auf einem Datenträger findet. Aber kein Grund zur Panik, das sind aber für PlayEm-Nutzer bzw -Interessierte gute Nachrichten:

Denn V1.2 hat heute Pre-Alpha-Status erreicht. Hauptunterschied gegenüber V1.1: Es wird

Zitat von oneBitman

einen einfachen weg [geben,] songlengths da rein zu kriegen

Damit schlage ich mehrere Fliegen mit einer Klappe.
a) User Friendliness:
Mir ist außer meinem Kumpel spider-j niemand bekannt, der wirklich jemals den fummeligen Weg gegangen ist, ein Image mit den "XYZ!"-Custom-Files zu erstellen (Source zur Generierung siehe Posting #8). oneBitman schlug in die gleiche Kerbe. Was für den Entwickler nach Erstellung knapp 1.000 solcher Files total klar ist, ist für den User womöglich böhmischer Wald oder zumindest elender Fummelkram.
b) Alternative zu Exomizer-crunched Files:
Da das Crunchen und anschließende Header-linken und Hacken einerseits einen Umweg darstellt, der viele abschrecken dürfte, und wie gesagt die Decrunching Time z.T. (z.B. auf SD2IEC/JiffyDOS-Combo) mehr nervt als Loading Time (vgl. Posting #9),

Zitat von TheRyk

führe ich zusätzlich zum "!" Custom File [<- d.h. die alten "!"-Files sind nach wie vor nutzbar und werden ordnungsgemäß decruncht] noch ein "#" Custom-File ein

für Leute, die wie Thunder und ich froh über möglichst schnelle Tunewechsel/jeden Sekundenbruchteil ohne Stille sind.

Aufbau eines #-Custom-Files
- ganz normales .SID-File inklusive Header, lediglich am PC/whatever umbenannt in .PRG
- Footer mit 31 bytes, im wesentlichen mit den gleichen Informationen, die beim !-Custom-File zwischen SID-Header und crunched DAT gezimmert wurden, hauptsächlich die 30 bytes für bis zu 15 tunes MM:SS Spieldauer. Klar, Range braucht man nicht mehr, da nicht decruncht wird, kann ich die Range über Zeropage nach dem Ladevorgang auslesen und den Footer subtrahieren. Speed-Byte halte ich weiterhin für nützlich, falls meine Speed-Berechnung durch wirre CIA-Settings nicht zu einem plausiblen Ergebnis führt (v.a. ältere Tunes, sehr geringer Prozentsatz).

Status:
- Funktioniert nach ersten Tests bereits alles, wie es soll.
- Vorhersehbare Inkompatibilität: Files, die bereits ohne Footer zu weit in Page $FF hineinragen, so dass Platz für 31 Footerbytes fehlt, wäre im Editor, s.u. abzufangen.
- Was noch fehlt für Release:

Zitat von TheRyk

native[r] (auf C64 lauffähige[r]) Editor [für die #-Files...], den man nur mit .SID-Files füttert und dann die 30 bytes PlayingTime reinhämmern darf

Kleinigkeit eigentlich für ca. 42 kB große Files, die man stupide nach $5350 speichern könnte. Bei größeren brauche ich noch einen Weg, Startadress-Bytes entweder ganz wegzusägen (etwas Gehacke im eigentlichen Tool erforderlich) oder aber ne Möglichkeit, den Kram $IRGENDWOHIN zu speichern und hinterher mit irgend nem wilden Code die Startadresse wieder auf $5350 ($50 $53 im Monitor) zu verbiegen (die Buchstaben "P" und "S" von "PSID" aus dem Header). Vielleicht unfummeliger, als ich Moment denke.

Fazit:
Werde wohl während des Beta-Testens von 1.2 am besagten Editor stricken, idealerweise würde ich natürlich gern beides gemeinsam releasen. Bald etwas Urlaub, könnte also noch im Oktober was werden