Posts by Lipti

    Lipti

    Wie ist denn mit Deiner Version der aktuelle Stand der Dinge?

    Was hast Du denn gefixed, damit Deine Version nicht mehr diese Probleme hat?


    Wäre sehr interessant zu wissen und wäre auch schön, wenn Du Deine "Proof Of Concept"-Version veröffentlichen könntest.

    Hatte mich die letzten Monate nicht mehr mit diesem Teil des Hobbys beschäftigt (viel beruflich zu tun und ansonsten anderen Hobbys nachgegangen).


    Macht das nach der Veröffentlichung von Angrykings Version überhaupt noch Sinn, wenn ich da Arbeit rein investiere? Wenn ich den Thread richtig deute, scheint die GTK-VICE-Version auch geschmeidiger unter Windows geworden zu sein?


    Hätte ich mehr Zeit für andere Hobby-Themen, auch nicht schlecht :-)

    Mal was zum testen.


    Eig. dasselbe wie in #161, aber mit Lipti Patch... eventuell. :D


    http://vicebuilds3.bplaced.net…er_mai_2020_plus_lipti.7z

    Das zeigt doch mal den Vorteil von Open Source :-)


    Bin die letzten Monate überhaupt nicht diesem Teil des Hobbys nachgegangen, beruflich viel zu tun und habe mich in meiner Freizeit einfach mit anderen Dingen beschäftigt.


    Ich hatte vor Veröffentlichung von Binaries der von mir modifizierten Version (inkl. der Modifikationen anderer) noch auf der Agenda, den About-Dialog zu überarbeiten, um die Arbeit des VICE-Teams und der anderen Modifikationen zu würdigen, sowie eine exakte Versionsangabe zu integrieren, so dass man genau zu dem Sourcecode-Stand im Repo kommt, mit dem das Binary erstellt wurde. Nicht wirklich viel Arbeit, hatte aber andere Prioritäten, deshalb noch kein Binary von mir.


    Wäre es meinerseits überhaupt noch sinnvoll, jene Version zur Veröffentlichung zu ergänzen und da noch Arbeit reinzustecken? Hätte auch genug andere Themen mit denen ich mich gerne beschäftigen würde, falls das eh keinem mehr was bringt.

    Ohne unbescheiden wirken zu wollen (na ja - ein bißchen vielleicht ;) ) Hast Du eventuell auch über eine Implementierung des Dink-Mods mit etwaiger Einbindung in die UI nachgedacht?

    :) ... Da du schon der Zweite bist, der danach fragt, könnte das die Priorisierung meinerseits erhöhen ;) Bin allerdings schon froh, wenn ich erstmal für mich Grundsatzfragen geklärt, realisiert und damit die erste Version fertig habe, bis ich dann in weitere neue Themen einsteige. Wenn man doch nur mehr Freizeit und weniger Interessensgebiete hätte... :D

    Aber es gibt ja inzwischen Abspaltungen und Erweiterungen, "WinVICE improved", "WinVICE+" und eventuell noch andere.

    Aber die sind wohl dann ab v3.2, bestimmt nicht v2.4

    Hast Du zu WinVICE+ einen Link? Finde dazu nichts (liegt verm. daran, daß ein abschließendes "+" als Suchbegriff suboptimal ist).

    Kommt bald die erste Version, hatte nur unverhofft die Einladung zu einem Alpha-Test eines Spiels erhalten, in das ich die Tage die Stunden meiner Freizeit (mittlerweile >15 Std.) investiert habe.


    Kurz gesagt: Basis ist die letzte WinVICE-Version (3.2), mit der Option die Weiterentwicklungen ohne Entfernung der nativen Oberfläche zu überführen. ReSID-Backport ist vorhanden, deshalb auch nicht die Filterproblematik der 3.2er. Dazu weitere Modifikationen, wie z.B. der 8-SID-Mod von markusC64 ... Und Quick-Fix für den Fehler, den einige bei 50-Hz-Bildfrequenz im Vollbild erhalten (kaputter Sound alle ca. 30 Sekunden und ca. 10 Sekunden lang).


    Wenn ich etwas als Binary veröffentliche, möchte ich eine ordentliche Versionsangabe drin haben, die auf die exakte Version des Sourcecode-Stands schließen lässt. Ist nicht ganz so trivial, wie es erscheint. Anzeigen möchte ich sie inkl. Würdigung der Originalversion über einen modifizierten About-Dialog. Wenn ich das drin habe, kann ich gerne eine Alpha-Version als Binary für Interessierte erstellen, bis ich Sachen wie den Quick-Fix optional schaltbar und nicht nur für PAL einsetzbar für Beta und anschließende erste finale Version implementiert habe.


    Ich plane, zumindest die finalen Versionen unter "release" abrufbar unter folgendem Link abzulegen (kannst du dir ja schon einmal merken ;) )

    https://github.com/andresteinert/WinVICE-plus

    Die Speedanzeige habe ich in meiner internen Testbuild erst mal dirngelassen - im Moment habe ich das Gefühl, es wäre gut, wenn man Toolchains damit vergleichen könnte, was die leisten. Zum Bsp. durch Vergleich, was in Warpmodus an Geschwindigkeit rauskommt.

    Nach einem Revert des pauschalen Ausblendens habe ich es nun folgendermaßen für die Windows-Version gelöst:

    1. Geschwindigkeitsanzeige in die Statuszeile verschoben
    2. Temporäre Anzeigen wie "Attached xyz.d64 to device#8" in der Statuszeile übersteuern die Anzeige der Geschwindigkeit
    3. Workaround: Geschwindigkeitsanzeige nur im Warp-Mode, um Benchmarks zu ermöglichen; sobald die Geschwindigkeitsanzeige bei absolut ruckelfreier Anzeige konstante Zahlen anzeigt, werde ich sie ggf. generell wieder aktivieren

    Separate Commits: Revert, Kombination aus 1&2, Workaround aus 3.

    Wobei ein versierter Programmierer da wohl schlauer zu Werke geht als ich mit Notepad++ :P

    Ich bin derzeit Fan von Visual Studio Code. Ist mein Standardeditor geworden, ge-build-et wird in diesem Fall direkt in der MinGW/MSYS2-Konsole. Für Git die Git Bash. Mache dies ja unter Windows, da kann ich auch mehrere Windows nutzen. ;)


    Ggf. probiere ich mal interessehalber aus, ob ich das ins Visual Studio 2019 kriege. Bzgl. Buildsystem wäre es eher der Horror, könnte aber punktuell für die UI-Entwicklung interessant sein. Ansonsten geht das wie oben geschrieben schon sehr angenehm über die Bühne...

    Ist auch nicht schlimm... Dann muss das Versionsschema eben den offensichtlichen Unterschied hergeben. Jahr.Monat.Nr - die Nummer am Ende auf 0, es sei denn, in dem Monat sind mehrere Releases nötig, wäre eine Idee.

    Genau, das war einer der Gründe, warum die aktuelle Version "pre-2020.1" ist, um zum Einen keine Möglichkeit der Verwirrung mit 3.4 etc. zu bieten, zum Anderen mag ich irgendwie eine datumsbezogene Version. Genau deinen Vorschlag hatte ich auch überlegt, aber da würde man die Nummer mit dem Tag verwechseln. Derzeit dürfte ich nur eine Releaseversion im Monat machen ;)


    Wenn ich bspw. in diesem Monat ein Release schaffe, wäre "pre-2020.2" die nächste Entwicklungsversion. Auch wenn ich übliche Versionierungsschemas durchaus kenne, finde ich es unlogisch, wenn die Version erst mit einer neueren Nummer beginnt, und danach "rückwärts" durch alpha, beta, RC etc. eingeschränkt wird. Eigentlich möchte ich direkt am Anfang sehen, dass es sich noch nicht um die danach folgende Version handelt, deshalb das "pre-".


    Damit ich nicht zu viele Mergekonflikte bekomme, werde ich wohl erst einmal nicht direkt an der Version drehen, die durch das bestehende Buildsystem geht. Da müsste ich auch die Berechnung der "einzahligen" Versionsnummer ran, die derzeit je nach Position der Zahl multipliziert und dieses aufaddiert. Bei 2020 als Majorversion käme eine irre einzahlige Versionsnummer raus.

    Die Speedanzeige habe ich in meiner internen Testbuild erst mal dirngelassen - im Moment habe ich das Gefühl, es wäre gut, wenn man Toolchains damit vergleichen könnte, was die leisten. Zum Bsp. durch Vergleich, was in Warpmodus an Geschwindigkeit rauskommt.

    Guter Punkt. Ich hatte eben mal geschaut, ob ich die relativ einfach nur im Warp-Modus aktivieren kann. Aktivieren ist kein Problem, allerdings das anschließende Deaktivieren. Dort müsste ich den Titel zurücksetzen, aber die Implementierung lässt dies ohne Refactoring nicht zu. Der Titel wird nämlich direkt in den ui_display_speed-Methoden (ui.c) gesetzt, statt dass diese eine set_title-Methode aufrufen, die ich zum Löschen verwenden könnte. Und diese Methoden sind arch-spezifisch (müsste dann also alle umbauen); dies wäre ja noch machbar, jedoch hätte ich dann heftige Mergekonflikte wenn ich aus vanilla-vice sukzessive Weiterentwicklungen weiter reinmerge. Und genau die Geschwindigkeitsanzeige hat sich ja (zumindest bei GTK3) scheinbar von 3.2 zu 3.4 von Titelzeile zu Statusbar bewegt. Da macht es mehr Sinn, wenn ich die auch in der nativen Oberfläche in die Statusbar verschiebe (und ggf. erstmal nur im Warp aktiviere, bis die auch im nicht-Warp stabil ist, sofern die angezeigte Emulation selbst stabil ist).


    PS: Ich sehe gerade: Im konvertierten git (aus dem svn) gibt es jede Menge Branches "viceplus/<versionskennung>" - vielleicht ist "WINVICE+" demnach als Name doch verwechslungsgefährdeter als gedacht.

    Ist nun leider zu spät, sonst fange ich mit dem Repo wieder von vorne an, außerdem hatte ich lange mit AW182 über Namen philosophiert und auf wirklich bessere sind wir nicht gekommen. WinVICE soll ja gerade für die native Oberfläche stehen wie sie früher vorhanden war und es sie nicht mehr gibt; das "+" für Ergänzungen ggü. auch aktuellen vanilla-VICE-Versionen. Außerdem soll es auch die Arbeit des offiziellen VICE-Teams würdigen, statt dass ich etwas unter komplett anderem Namen laufen lasse wo der User keine Rückschlüsse mehr auf das Projekt zieht, welches die fantastische Leistung eines so guten Emulators hervorgebracht hat.


    Allerdings sehe ich auch nicht wirklich ein Problem: Ich nutze keine zusätzlichen Branches vom vanilla-VICE. Ich nehme nur den Code als Basis, der im "trunk" ist. Bei dir sind sie (zumindest im öffentlichen Bitbucket) auch nicht vorhanden. Da ist eigentlich eine gute Entkopplung vorhanden. Egal welchen Namen ich wählen würde, theoretisch könnte den auch jemand im Subversion als Branch-Namen vergeben. Irgendwo muss man eine Entkopplung machen, und bei mir ist die genau dort.

    Ich habe mir Deine eingecheckten Branches heute mal angesehen: Ich bin begeistert. Die SID-Backports ergänzen sich mit meinen SID-Backports gegenseitig. So wird das bestimtm ein Genuss für die Ohren.

    Danke, das tut gut zu hören. :)


    Im Hintergrund informiere ich mich in der mir zur Verfügung stehenden Freizeit gerade leider so viel über für Änderungen benötigte Grundlagen, dass ich mit meinem Code-Output (quantitativ) noch nicht zufrieden bin. Was ich mir gerade nebenbei in der Freizeit aneigne:

    • Win32API, um native Dialoge, Menüs etc. nicht nur im trial & error bearbeiten zu können (erster sehr wichtiger Schritt ist die About-Box, um trotz eigener Versionsinformationen Credits für die Originalversion vom VICE-Team geben zu können)
    • Autotools (habe mir das Buch "Autotools, 2nd Edition: A Practitioner's Guide to GNU Autoconf, Automake, and Libtool" von John Calcote gekauft), um auch bei Anpassungen des Build-Systems mehr als trial & error machen zu können
    • Git über Basiswissen hinaus (ich konnte wie die meisten mit Git umgehen, aber wie es denn wirklich funktioniert und welche Ansätze in dieser besonderen Umgebung und Problemstellung welche Vor- und Nachteile haben, so tief steckte ich bisher nicht drin); ich mache alles per Kommandozeile, um es wirklich zu verstehen und die volle Kontrolle darüber zu haben.
    • Innerer Aufbau von VICE. Klingt für bereits beteiligte Entwickler vielleicht lächerlich trivial, aber wie die Kette der Aufrufe und verschiedene Gegebenheiten realisiert sind, muss ich nun einmal für weitere Änderungen wissen. Beispiel: Ich möchte meinen Quick-Fix per Option schaltbar machen. Dafür brauche ich Änderungen am nativen UI (Win32API, siehe oben), muss die Option in den Einstellungen speichern, muss sie dann an den entsprechenden Stellen wirksam werden lassen und ggf. den Build ergänzen (im Falle neuer Dateien). Ebenso die Informationen für die Quick-Fix-Berechnung durch die Kette durchzureichen (Parameter vs. #DEFINE vs. ...).

    Naja, ich kämpfe mich weiter durch... :D

    Das würde ich nicht machen - dann führen neue Commits der Entwickler von VICE nämlich direkt zu nicht mehr per FF in die "vanilla-.vice" übernehmbaren Commits... ich würde das nicht wollen.

    Sehr guter Punkt, vor allem weil die .gitignore durch das automatische Mapping häufig angepasst wird. Danke für den Hinweis.


    Es gäbe noch die Möglichkeit, über den (ggf. nur global verfügbaren) Git-Config-Parameter "core.excludesfile" eine Art svnignore-File einzubinden, welches die default-Ignores von Subversion enthält. Wobei ich sowas nur nehmen würde, wenn sich das auf das Repo begrenzen lässt (also nicht nur global).


    Ich tendiere zur Ergänzung im von "vanilla-vice" abgeleiteten "win-still-in"-Branch, da ich dort zum einen eh massiv Änderungen direkt am Anfang habe (natives UI soll ja drin bleiben), und damit auch kein FF [auch künftig] möglich sein sollte, und zum anderen die Änderungen Committen muss (da würden die vielen fälschlicherweise als untracked [statt ignore] Files massiv die Übersicht stören.

    Zur Info: Die weitere Analyse deutet darauf hin, dass SVN-Mirror nicht die Default-Ignores von Subversion in die .gitignore übernimmt, sondern nur die Repo-spezifischen (wodurch sich praktisch aber das Verhalten unterscheidet). Standard-Ignores bei Subversion sind scheinbar:

    Code
    1. *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo __pycache__ *.rej *~ #*# .#* .*.swp .DS_Store [Tt]humbs.db

    Mal hier in die .gitignore klöppeln :) Bin mir nur unschlüssig, welche Position im File für anschließende automatische Merges besser ist: Anfang des Files, Ende des Files, irgendwo dazwischen...

    Die ".gitignore" ist eine maschinelle Umsetzung der svnignore-Eigenschaft - und der Algorithmus dazu ein Geheimnis des Herstelelrs der Umsetzungssoftware. Deswegen kann ich Dir nicht mehr dazu sagen.

    Scheint/schien zumindest bei dem Mirrorstand von Revision 34842 nicht dasselbe Verhalten zu zeigen, auch wenn ich noch nicht genau geschaut habe, warum.


    Bei deiner git-Version mit Hash 3930b09da5f60d5d27909f4e455d5f84bd187bcf (entspricht obiger Revision), wird nach ./autogen.sh und ./configure angezeigt:

    Code
    1. Untracked files:
    2. (use "git add <file>..." to include in what will be committed)
    3. vice/libvicetest.a
    4. vice/vicetest.o

    Nach einem make noch viel mehr...


    Bei der offiziellen svn-Version der Revision 34842 erscheint nach ./autogen.sh und ./configure bei svn status keine Datei als nicht getracked.


    Ein erster flüchtiger Blick u.a. auf svn-ignores mittels...

    Code
    1. svn proplist -v -R

    ...konnte keine entsprechenden Eigenschaften zeigen, die von der .gitignore abwichen.


    Ich schaue da aus Interesse nochmal genauer nach...

    Auf der anderen Seite sind erwartbare Mergekonflikte in der .gitignore auf jeden Fall überschaubar, so dass man die durchaus anpassen kann.

    Sehe ich auch so. Ich schaue gerade nur, in welchem Branch ich das bei mir anpasse. Im "vanilla-vice" möchte ich eigentlich genau das Verhalten des offiziellen svn-Repos nachbilden. Sollte sich obiges Verhalten als schon dort unterschiedlich bewahrheiten, werde ich direkt dort die .gitignore anpassen. Ansonsten erst in einem abgeleiteten Branch. Möchte das möglichst sauber halten.

    markusC64

    Nachdem ich mit dem ermittelten Aufsetzpunkt zufrieden bin, der wohl der Binärdistribution von WinVICE 3.2 am besten entspricht, folgende Frage:


    Wie wird deine .gitignore erzeugt? Hat es einen Grund, warum die .o-Objektdateien nicht enthalten sind? Würde sie dann lokal bei mir aufnehmen, um sie nach einem "make" nicht als untracked files angezeigt zu bekommen...

    Könnte es denn sein, dass die alten Revisionsnummern abwichen, vom nativen WinVICE zum VICE allgemein?

    Möglich, vielleicht wurde die Windows-Version vor anderen (und den dazwischen erfolgten Änderungen) gebaut... Aber das erklärt mir noch nicht, warum das Verzeichnis, in dem die Binärdistribution enthalten ist, eine niedrigere Revision als der kompilierte Inhalt hat.


    Stell dir vor, du schreibst einen Brief (analog zum Compiler, der aus dem Sourcecode im Falle von Windows die EXE baut) und nutzt dafür Briefpapier, auf das dir automatisch das aktuelle Datum gedruckt wird. Später verpackst du diesen Brief in einen Umschlag (analog zu "make bindist", der die kompilierten Dateien inkl. Hilfsdateien "zusammenschnürt"), der wird auch mit einem Datum versehen.


    Das Datum des Briefs kann eigentlich nicht neuer sein als das Datum des Umschlags.

    Könnte Sinn machen, wenn ich für die aus Git gebauten Versionen im About-Dialog statt der SVN-Revision folgendes Anzeige, was zum Zeitpunkt des Builds gültig war:

    • Git-Hash, der im lokalen Verzeichnis während des Builds die Basis war
    • Info, ob es Änderungen ggü. obigem Hash-Stand gab (analog modified-Marker von SVN)
    • ggf. Git-Branch (master wäre dann Releases während z.B. develop nightly o.ä. wären)
    • ggf. Anzahl Commits in jenem Branch, da es keine fortlaufenden Revisionen in solch verteilten Versionskontrollsystemen gibt; wäre allerdings zwischen unterschiedlichen Personen nicht kollisionsfrei, sofern Änderungen noch nicht gepusht wurden

    Im Zweifel nimm die ältere, ein Rebase auf eine neuere Version ist leicht - umgekehrt um ist de Aufwand größer.

    Guter Tipp!


    Ich finde es außerdem schräg, dass die im .7z enthaltene Version im About-Dialog eine neuere Revision inkl. "modified working copy"-Marker hat als der Verzeichnisname des Builds, in dem alles enthalten ist.


    Die Revision im About-Dialog kommt aus der subversion.h, der Inhalt wird allerdings automatisch generiert und dafür das SVN-Programm "svnversion" herangezogen. Wie die Revision in den Verzeichnisnamen kommt, konnte ich bisher nicht nachvollziehen; bisher haben die von mir betrachteten Codepfade nur die reine Version (also z.B. "3.2" in das bindist-Verzeichnis) aufgenommen, aber ohne ergänzenden Bindestrich und folgender Revision. Ggf. gab es ein umgebendes Build-Skript des Erstellers, der den Verzeichnisnamen um die SVN-Revision ergänzt; allerdings würde ich dann noch weniger die Abweichung in diese Richtung verstehen. Umgekehrt könnte ich es eher nachvollziehen, wenn die SVN-Revision zum Zeitpunkt des Verpackens neuer ist als die des Builds selbst.


    Wenn du unter Linux einen Cross-Compile machst, hat das resultierende Verzeichnis nach bindist die SVN-Revisionsnummer im Verzeichnisnamen? Wobei du da selbstverständlich aus einem Verzeichnis heraus kompilieren müsstest, welches unter Subversion-Versionskontrolle steht.


    Scheinbar kommt das .7z von vice.pokefinder.org, zumindest sagt das die enthaltene buildnote. Auch die neusten Builds dort haben noch genau dieses Format der Bezeichnung.

    Etwas Merkwürdiges hat mich an anderer Stelle forschen lassen: Die bei Sourceforge gespeicherte WinVICE-3.2-x86.7z unter https://sourceforge.net/projec…eleases/binaries/windows/ scheint nicht genau dem Codestand vom Sourcecode-Tag "v3.2" zu entsprechen:


    Der "v3.2"-Tag, der unter Revision 34854 eingecheckt wurde, enthält Änderungen des "trunk"-Branches bis Revision 34852. Die Revision im entpackten Verzeichnisnamen lautet 34842, die des About-Dialogs im VICE die Revision "34843M". Schaut man sich im Hilfe-Menü in der deutschen Spracheinstellung die Kommandozeilen-Parameter an, bemerkt man die fehlende Übersetzung bei "-silent" ("Disable verbose log output."), die u.a. scheinbar zwischen den fehlenden Revisionen eingecheckt wurde.


    Nun frage ich mich, ob bei Sourceforge-Files eine veraltete 3.2er-Version abgelegt wurde, oder ob das wirklich die war, die auf der VICE-Website zum Download angeboten wurde. Ggf. gab es dort ja eine aktualisierte Version, die nur nicht bei Sourceforge abgelegt wurde.


    Und ich überlege, was logisch korrekter wäre, von welcher Revision ich den neuen Branch (auf Basis Version 3.2) ableiten soll; ich weiß, dass es im Endeffekt egal ist, aber ich denke trotzdem drüber nach. :) Logisch sinnvoller wäre ja die Version, die die User unter Windows wirklich hatten. Dann wäre selbst die fehlende Übersetzung eine Änderung ggü. der denen bekannte Version.

    Normalerweise würde ich bei Release-Tags aufsetzen, aber das setzt auch wirklich eine Synchronität zwischen Release-Tag und Release-Bindist voraus. ;)

    Auf C: wird ein Logfile geschrieben, wenn man es an der Kommandozeile mit angibt.

    Auf D: nicht, es entsteht gar kein File, es gibt keine Fehlermeldung und auch sonst keine Reaktion (die Taskliste ist auch leer).

    Lass VICE von D: mal das Logfile auf das Laufwerk C: in den Ordner schreiben, aus dem du VICE erfolgreich starten kannst. Inkl. verbose-Logging. Etwa so (das Ziel - hier D:\test.txt - bitte auf C: mit funktionierendem Verzeichnis anpassen):

    Code
    1. x64sc -logfile d:\test.txt -verbose