Hallo Besucher, der Thread wurde 10k mal aufgerufen und enthält 76 Antworten

letzter Beitrag von Lipti am

Eigene WinVICE-Änderungen

  • Hallo,


    ich mache derzeit eigene Änderungen an WinVICE auf Basis v3.2 (ich kann derzeit noch nicht abschätzen, ob ich da Erkenntnisse gewinne, die für das VICE-Team auch bei aktueller Version sinnvoll sind) mit eingebundenen Patches von anderen Personen (8-SID von markusC64 ) und derzeit erst wenigen Backports (resid, potenziell aber später mehr).


    Scheinbar ist die kompilierte Version auch für andere Windows-User sinnvoll (laut AW182 der testet, ob damit die Probleme behoben sind, die bei anderen WinVICE-Versionen existieren).


    Selbstverständlich würde ich dann den Sourcecode verfügbar machen, genau dafür suche ich eine passende Lösung (z.B. GitHub), um am besten beides (Sourcecode und Binärdownloads) anbieten zu können, aber für mich selber auch den Code unter Versionskontrolle zu haben. Nicht nur wegen GPLv2, sondern weil ich eigentlich nur bei dem akuten Problem helfen wollte und mich die Herausforderung reizte.


    Ich möchte aber auch niemanden auf den Schlips treten, ich wollte einfach nur (derzeit unter WinVICE) helfen, um möglichst schnell eine Version für die User anbieten zu können, die z.B. den Soundfehler bei 50 Hz haben, bei denen die GTK-Version derzeit extrem ruckelt und denen die SDL-Version wegen fehlender Menüs stört.


    Weder soll das Denise schaden (wo die Weiterentwicklung eh rasant geht [Hochachtung vor PiCiJi ], bei WinVICE reizte mich eher die akute Problemlösung), noch VICE selbst (die User, die das akute Problem haben, würden wohl eh praktisch eine Alternative nutzen bzw. sieht zumindest die GTK-Version gar nicht die Möglichkeit wie Umschaltung der Framerate und Auflösung im Vollbild vor, was aber praktisch ist, wenn man wie normal mit 60 Hz arbeitet, aber für den Emulator nicht immer manuell auf 50 Hz in den Windows-Einstellungen umschalten möchte). Es wird wohl eher (zumindest anfangs) ein "dreckiger" Fix, der aber den Usern helfen könnte; später wäre es gut möglich, dass Erkenntnisse auch für neuere Versionen relevant sein könnten (Sync-Code).


    Wenn ich damit eine Revolution heraufbeschwöre, lasse ich das natürlich sein. Ich wollte nur helfen und möchte keinen Streit erzeugen... Also sagt mir bitte, wenn ich es lassen soll; es ist ein Hobby, da brauche ich keinen Stress - ansonsten mache ich lieber etwas anderes mit meiner Zeit. Es wäre nur schade für die User, die damit ggf. direkt eine Verbesserung haben. Oder soll ich besser nur auf direkte Nachfrage ein ZIP-Bundle aus Binärversion und entsprechendem Sourcecode rausgeben, um zumindest den akut Betroffenen helfen zu können?


    Bin mir echt unschlüssig derzeit... Immerhin macht die Herausforderung des Codes Spaß ;) Und Hobbys sollen ja dafür sein, dies zu tun. :)

  • Selbstverständlich würde ich dann den Sourcecode verfügbar machen, genau dafür suche ich eine passende Lösung (z.B. GitHub), um am besten beides (Sourcecode und Binärdownloads) anbieten zu können, aber für mich selber auch den Code unter Versionskontrolle zu haben.

    Falls du eine eigene Webseite hast, dann stell die Datei doch einfach dort zum Download zur Verfügung. Ich würde das ganz unkompliziert machen.

  • Immerhin macht die Herausforderung des Codes Spaß ;) Und Hobbys sollen ja dafür sein, dies zu tun. :)

    Mit dem letzten Satz hast Du die Antwort auf Deine Frage selbst geschrieben. ;)

  • Ich habe meine VICE-Version ja bei Bitbucket liegen - ist auch kostenlos, genau wie Github auch. Dort ist das Subversion-Repository auch nach Git umgewandelt - hat sicherlich Vorteile, wenn man dadurch die Patches extrahieren kann.


    Aktuell ist bei mir die "10sid"-Branch. Und ich habe bereits neue Patches in der Pipeline... zum Bedauern von so manchen aber ohne Prio, so dass ein Releasedatum unbekannt ist. Ich bin ja bisher noch nichteinmal dazu gekommen, jene auszuprobieren.


    Edit: Jedenfalls könntest Du meinetwegen auch die aktuell (unfertige, weil ungetestete) Branch haben - dort sind hauptsächlich Verebsserungen am Monitor zu finden (Backports und eigene).

  • und derzeit erst wenigen Backports (resid, potenziell aber später mehr).

    Ich habe auch einiges am SID backported, es mag aber auch was fehlen... https://bitbucket.org/markusC64/vice_3.2/


    Wäre gut, wenn wir beide die selbe nach Git konvertierte Version des Repositories nutzen könnten - kannst die ja "clone"n. Das macht einen ggf. notwendigen Austausch von Patches erheblich einfacher - man kann die dann einfach per "git cherrypick" übernehmen.


    Ich habe mich durchgerungen, gerade mal meinen aktuellen Stand zu compillieren (das mache ich per Crosscompiler von Ubuntu aus).



    Edit: Ich habe die Änderungen nun doch in der "10sids"-Branch committed... Gemäß einen Quicktest scheinen die zu laufen.

  • Dort ist das Subversion-Repository auch nach Git umgewandelt - hat sicherlich Vorteile, wenn man dadurch die Patches extrahieren kann.

    Definitiv. Nutzt du sowas wie SubGit von TMate für eine automatische Synchronisation (one-way)? Oder wie ziehst du da immer wieder die neuesten Commits vom SVN rein?

    Ich habe meine VICE-Version ja bei Bitbucket liegen - ist auch kostenlos, genau wie Github auch.

    Da hatte ich bereits einen Account, weil ich mal für den T80-Lötkolben was an der Firmware geändert hatte und dies in einem privaten Repo machen wollte; zu der Zeit gab es bei GitHub keine kostenlosen privaten Repos.

    Aktuell ist bei mir die "10sid"-Branch. [...] Jedenfalls könntest Du meinetwegen auch die aktuell (unfertige, weil ungetestete) Branch haben - dort sind hauptsächlich Verebsserungen am Monitor zu finden (Backports und eigene).

    Deine Branches habe ich offen gesagt noch nicht ganz verstanden: master ist der automatische SVN-zu-Git-Sync des offiziellen Repos? In der Bitbucket-Weboberfläche steht bei deinem 8sids-Branch "Main, Development, Production" und beim 10sids-Branch nicht. Andererseits sieht man, dass der 10er vom 8er abgeleitet wurde. :)

    Ich habe auch einiges am SID backported, es mag aber auch was fehlen...

    Der resid-Backport war eigentlich nur, um die Filter der 3.2er zu korrigieren. Wobei Backport vielleicht meinerseits zu übertrieben ausgedrückt ist, wenn ich einfach nur das resid-Verzeichnis aus der neuesten Revision genommen habe; aber es hat funktioniert. ;)

    Wäre gut, wenn wir beide die selbe nach Git konvertierte Version des Repositories nutzen könnten - kannst die ja "clone"n. Das macht einen ggf. notwendigen Austausch von Patches erheblich einfacher - man kann die dann einfach per "git cherrypick" übernehmen.

    Gerne, muss aber nochmal genau nachfragen: Meinst du damit, dass ich bspw. dein Git-Repo bei GitHub unter meinem Usernamen importiere? Git clone kenne ich bisher nur zum anschließenden pushen ins gleiche Repo, und das wäre dann ja deins. Schätze mal dass du Ersteres meinst...

    Ich habe mich durchgerungen, gerade mal meinen aktuellen Stand zu compillieren (das mache ich per Crosscompiler von Ubuntu aus).

    Erfolgreich? ;) Ich habe meine Version über MSYS2 64-bit mit MinGW 32-bit (damit sie AW182 testen konnte, da nur 32-bit) kompiliert. Muss mich aber nochmal damit beschäftigen, warum nicht die benötigten DLLs ins bindist-Verzeichnis kommen...

  • Vielleicht könnt ihr eure gemeinsamen Verbesserungen, beziehungsweise Weiterentwicklungen am normalen WinVICE V3.2, ja auch zusammenfließen lassen in eine Version, "Lipti" und "markusC64"?


    Dann würde sich der Weg der nativen WinVICE Versionen nicht noch weiter abspalten und zumindest diese beiden Pfade, würden einen gemeinsamen Weg der Updates, neuen Features und Verbesserungen gehen. Wäre zu überlegen.


    Ich kann schonmal sagen, dass es in "Lipti's" Version schon sehr vorangegangen ist, was die Behebung des überlaufenden Soundpuffers bei 50Hz Vollbild betrifft. Sieht alles gut aus, ich hab ausführlich damit rumgetestet. Da es Sinn macht, kam natürlich auch der SID-Filter der WinVICE V2.4 Version wieder mit rein, den ja "Angryking" schonmal reingebastelt hatte. Und noch ein paar andere sinnvolle Sachen werden voraussichtlich Einzug halten, in diese neue Version.


    Weder soll das Denise schaden ...

    Da muss man sich keine Sorgen machen, denke ich. Die Verbesserung ALLER C64-Emulatoren muss ja das übergeordnete Ziel sein. So sehe ich das zumindest und wenn es irgendwie geht, bringe ich Vorschläge für neue Funktionen in alle C64 Emulatoren ein, die ich gerne nutze, und melde Bugs zu all diesen Emu's, sei es nun HOXS, DENISE oder WinVICE. Je besser jeder Einzelne davon wird, umso besser dann letztendlich für alle User, dann hat man die Wahl aus lauter immer besser werdenden Produkten, die sich vielleicht sogar durch ihre Verbesserungen gegenseitig weiter hochtreiben in der Qualität, ist doch super. :)


    Wenn ich damit eine Revolution heraufbeschwöre, lasse ich das natürlich sein. Ich wollte nur helfen und möchte keinen Streit erzeugen... Also sagt mir bitte, wenn ich es lassen soll

    Auf keinen Fall lassen, warum auch, es ist Open Source. Innerhalb von zwei Tagen hat sich am WinVICE Soundpuffer 50Hz Problem jetzt schon mehr verbessert, als davor in etlichen Jahren. Ich sehe es ja hier direkt, weil ich diese Versionen teste. Je mehr gute Programmierer bei etwas mitwirken, und das scheint bei "Lipti" definitiv der Fall zu sein, und Verbesserungen in die Software reinbringen können, umso besser für die Endnutzer. Wenn so gravierende Verbesserungen dann im Nachhinein zu Streitereien führen sollten, dann verstehe ich es aber wirklich nicht mehr. Meine Meinung dazu.

  • Weder soll das Denise schaden (wo die Weiterentwicklung eh rasant geht [Hochachtung vor PiCiJi ], bei WinVICE reizte mich eher die akute Problemlösung), noch VICE selbst

    Mach dir darüber keine Sorgen. Jeder hat das Recht seine Freizeit mit dem Thema auszufüllen. Meine Motivation ist in erster Linie zu verstehen, wie alles funktioniert. Da ist es mir egal, dass es schon zahlreiche C64 Emulatoren gibt die im Grunde der Sache alle das Gleiche tun.

  • Definitiv. Nutzt du sowas wie SubGit von TMate für eine automatische Synchronisation (one-way)? Oder wie ziehst du da immer wieder die neuesten Commits vom SVN rein?

    Ich benutze Bitbucket Server ( $10 ) mit dem Plugin "SVN Mirror" ($ 5) - beides bei mir zu Hause in einer VM installiert. Da brauche ich nur ein "git pull upstream" zu machen - und anschließend ein "git push bitbucket".

    Vielleicht könnt ihr eure gemeinsamen Verbesserungen, beziehungsweise Weiterentwicklungen am normalen WinVICE V3.2, ja auch zusammenfließen lassen in eine Version, "Lipti" und "markusC64"?

    Ist also halbautomatisch - ich muss die Commits von einen Gitrepository auf ein anderes übertragen. Aber das ist ok, es muss ja nicht topaktuell sein, wenn man eh auf Version 3.2 arbeitet,

    Da hatte ich bereits einen Account, weil ich mal für den T80-Lötkolben was an der Firmware geändert hatte und dies in einem privaten Repo machen wollte

    Würde sagen, der ist top qualifiziert.

    Deine Branches habe ich offen gesagt noch nicht ganz verstanden: master ist der automatische SVN-zu-Git-Sync des offiziellen Repos?

    "master" ist der automatisch konvertierte und manuell übertragene SVN von upstream. "8sids" ist die 8sid-Version wie released. 10sids ist deren Nachfolger - irgendwie habe ich die Metadaten wohl nicht ganz aktuell, aber ich habe 8sids zu Gunsten von 10sids aufgegeben.

    Gerne, muss aber nochmal genau nachfragen: Meinst du damit, dass ich bspw. dein Git-Repo bei GitHub unter meinem Usernamen importiere? Git clone kenne ich bisher nur zum anschließenden pushen ins gleiche Repo, und das wäre dann ja deins. Schätze mal dass du Ersteres meinst...

    "git remote" erlaubt es Dir, anschließend weitere Git remote-Reposities hinzuzunehmen und dahin dann zu pushen...

    Vielleicht könnt ihr eure gemeinsamen Verbesserungen, beziehungsweise Weiterentwicklungen am normalen WinVICE V3.2, ja auch zusammenfließen lassen in eine Version, "Lipti" und "markusC64"?


    Dann würde sich der Weg der nativen WinVICE Versionen nicht noch weiter abspalten und zumindest diese beiden Pfade, würden einen gemeinsamen Weg der Updates, neuen Features und Verbesserungen gehen. Wäre zu überlegen.

    Dem kann ich auch was abgewinnen - natürlich ausgenommen Vorabversionen, um irgendwelche Neuerungen getestet zu bekommen. Bei Releases würde das in der Tat helfen.




    Edit: Mach mal ein "git fetch origin refs/notes/commits:refs/notes/commits" - anschließend wird Dir bei einen Clone von meinen Repo "git log master" so etwas liefern:


    Cool, oder? So hat man immer die direkte Zuordnung zu den SVN.

  • Ich benutze Bitbucket Server ( $10 ) mit dem Plugin "SVN Mirror" ($ 5) - beides bei mir zu Hause in einer VM installiert. Da brauche ich nur ein "git pull upstream" zu machen - und anschließend ein "git push bitbucket".

    Dann verstehe ich zumindest, warum Commits von "subgit" auftauchen, "SVN Mirror" scheint ja quasi "SubGit" als Bitbucket-Addon zu sein, beides vom selben Hersteller.

    Ist also halbautomatisch - ich muss die Commits von einen Gitrepository auf ein anderes übertragen. Aber das ist ok, es muss ja nicht topaktuell sein, wenn man eh auf Version 3.2 arbeitet

    Du arbeitest aber hauptsächlich über deinen eigenen Bitbucket-Server, oder? Das folgere ich daraus, dass nur wenige deiner eigenen Commits einem Atlassian-Account zugeordnet werden können (bei den übertragenen Commits aus dem Subversion ist es hingegen logisch, dass kein Bitbucket-User dazu gefunden werden kann).

    "master" ist der automatisch konvertierte und manuell übertragene SVN von upstream. "8sids" ist die 8sid-Version wie released. 10sids ist deren Nachfolger - irgendwie habe ich die Metadaten wohl nicht ganz aktuell, aber ich habe 8sids zu Gunsten von 10sids aufgegeben.

    Wie die Commits deines "master"-Branches habe ich nun verstanden, aber warum ist jeder dieser Commits (zumindest derzeit) noch einmal in veränderter Form scheinbar im "8sids"-Branch vorhanden? Dort sind sie alle als "Translated-from: SVN" von "subgit" committed worden, scheinbar mit einer Datei, die in einem Verzeichnis der ersten beiden Zeichen des Hashes des eigentlichen Commits, mit den restlichen Zeichen des Hashes als Dateinamen, gespeichert. Finde ich im Moment ein wenig verwirrend, schließlich haben die doch erstmal nichts mit dem Branch zu tun? Denke nicht, dass die Originaländerungen auch in den Branch übernommen wurden, dort liegt ja Version 3.2 von VICE, ergänzt um Patches etc.

    "git remote" erlaubt es Dir, anschließend weitere Git remote-Reposities hinzuzunehmen und dahin dann zu pushen...

    Damit hatte ich tatsächlich bisher keine Berührungspunkte. Bisher hatte ich nur die klassischen Anwendungsfälle über origin. Klingt aber praktisch!

    Dem kann ich auch was abgewinnen - natürlich ausgenommen Vorabversionen, um irgendwelche Neuerungen getestet zu bekommen. Bei Releases würde das in der Tat helfen.

    Richtig, gerade das Rumprobieren und Debuggen mit Vorabversionen sind für mich die Gründe für ein eigenes Repo. Ich gehöre zu den Leuten, die gerne oft den Arbeitsstand committen, so kann ich einfacher zu unterschiedlichen vorigen Ständen zurückkehren bzw. einfacher an einem anderen Gerät weiterarbeiten. Und dezentrales Versionskontrollsystem wie Git statt Subversion, um sowohl schnell als auch ohne Internetverbindung (z.B. vom Laptop aus) auf die kompletten vorigen Commits inkl. Beibehaltung der eigenen Commit-Vorgehensweise weiterarbeiten zu können. Ich kriege immer die Krise, in großen Subversion-Repos in der gesamten Historie etwas zu suchen und dafür (teilweise langsame) Server bemühen muss.


    Mach mal ein "git fetch origin refs/notes/commits:refs/notes/commits" - anschließend wird Dir bei einen Clone von meinen Repo "git log master" so etwas liefern:

    [...]

    Cool, oder? So hat man immer die direkte Zuordnung zu den SVN.

    Deine Beispielausgabe sieht echt sinnvoll aus! Revision und Branch in den Notes in Verbindung mit Commit message und Hash.


    Ich schaue mir morgen (äh, mittlerweile heute) das mal genauer an, insbesondere:

    • was das "refs/notes/commits:refs/notes/commits" beim fetch bewirkt
    • wie ich die zwei Quellen (dein Repo und meins) für effizientes Arbeiten am besten festlege (ich werde ja ständig mein Repo nehmen und nur von Zeit zu Zeit aus deinem pullen); was dann als origin und zusätzliches Remote sinnvoll ist, da muss ich mich erst einlesen
    • bin mir noch unschlüssig, ob bei meinem Repo dann "master" als Inhalt des offiziellen Repos (über deinen konvertierten "master"-Branch mit dem offiziellen Subversion-Repo als Ursprung) sinnvoll wäre, schließlich enthält der ja normalerweise den Hauptzweig der eigenen Entwicklung. So müsste ich ja einen künstlichen eigenen anders benannten Master-Branch nehmen? Von Branch zu Branch zu Branch ohne Rückführung auf einen eigenen Hauptentwicklungszweig wäre glaube ich nicht so meins. Ich weiß aber auch noch nicht, wie man das für so einen Fall am schlausten machen könnte, ich hatte den Fall noch nicht. Muss da auch nochmal recherchieren.
    • wo ich am besten aufsetze. Entweder auf einen gemeinsamen "offiziellen" Stand mit deinem "master" als Ursprung (damit wir auf jeden Fall einen gemeinsamen Nenner für folgende Patches haben), oder ob ich direkt auf deinem "10sids" aufsetze, wobei ich die seit dem letzten offiziellen Stand eingeflossenen Patches etc. wohl nur in der Theorie erfassen könnte (praktisch wäre es ggf. zu viel Aufwand, sämtliche Commits seitdem nachzuvollziehen)
    • von vorigem Punkt abgeleitet, was ich mit deinen Branches mache, wenn durch den clone dann alle auch bei mir vorhanden sind (ich aber vielleicht direkt auf der 3.2er Revision vom "master" aufsetze). Wobei ich dann wieder schauen müsste, dass ich keinen guten Austauschweg für Patches ungewollt verhindere

    Möchte halt vorher alles logisch verstanden haben, bevor ich etwas mache. Insbesondere wenn es ja auch meinerseits ein öffentliches Repo ist.

  • aber warum ist jeder dieser Commits (zumindest derzeit) noch einmal in veränderter Form scheinbar im "8sids"-Branch vorhanden?

    Zum einen ist die 8sids Branch als Branch von master entstanden (natürlich an der genau passenden Stelle, nämlich die allerletzte Version, wo noch der Win32-Code drin ist). Deswegen sieht man jene Commits als zeitlich älteste auch in jenen Branches alle.


    Hier kann ich keine Dummydateien finden. In der Tat gibt es einige fehelrhafte Tools (wie z. B. gitk), welche die "Notes" von git al s Branch anzeigen.. das es Notes gibt, habe ich erwähnt ("refs/notes/commits") - diese Daten benutzt SubGit und SVN Mirror intern - und man kann die im Git-Client eben auch zur Zuordnung der Versionen nutzen. Jene "Pseudobranch" muss man ignorieren.

    was das "refs/notes/commits:refs/notes/commits" beim fetch bewirkt

    Sollte iegentlich nur das "git log" erweitern - ich habe mich noch nicht wirklich mit "notes" beim Git beschäftigt - aber siehe einfach mal beim Kommando "git note" nach...


    wie ich die zwei Quellen (dein Repo und meins) für effizientes Arbeiten am besten festlege (ich werde ja ständig mein Repo nehmen und nur von Zeit zu Zeit aus deinem pullen); was dann als origin und zusätzliches Remote sinnvoll ist, da muss ich mich erst einlesen

    Tipp: Wenn das klappen soll, musst Du Dein Repository von meinen per Clone erstellen, weil man ansonsten unterschiedliche SHA1 für gleiche Commits hat. Wenn Du dann Dein Repository hast, einfach neu ausschcken, so dass jenes "origin" wird.


    bin mir noch unschlüssig, ob bei meinem Repo dann "master" als Inhalt des offiziellen Repos (über deinen konvertierten "master"-Branch mit dem offiziellen Subversion-Repo als Ursprung) sinnvoll wäre, schließlich enthält der ja normalerweise den Hauptzweig der eigenen Entwicklung. So müsste ich ja einen künstlichen eigenen anders benannten Master-Branch nehmen? Von Branch zu Branch zu Branch ohne Rückführung auf einen eigenen Hauptentwicklungszweig wäre glaube ich nicht so meins. Ich weiß aber auch noch nicht, wie man das für so einen Fall am schlausten machen könnte, ich hatte den Fall noch nicht. Muss da auch nochmal recherchieren.

    Du wirst dich wundern, aber den brauch ich in der Tat öfter - nämlich für "git cherry-pick" als Quelle. Das ist für mich Sinn und Grund genug.


    von vorigem Punkt abgeleitet, was ich mit deinen Branches mache, wenn durch den clone dann alle auch bei mir vorhanden sind (ich aber vielleicht direkt auf der 3.2er Revision vom "master" aufsetze). Wobei ich dann wieder schauen müsste, dass ich keinen guten Austauschweg für Patches ungewollt verhindere

    Alles, was Du nicht willst, solltest Du nicht in Dein Github "push"en. S. o., wenn Du dann Dein Repo neu auscheckst, um origin passend zu haben, hast Du dann nur noch die angenehmen Branches. Und ein späterer "git pull" bzw. "git fetch" (git pull ist lediglich eine Kurzform für git fetch gefolgt von git merge) holt die unerwünschten Branches nicht wirklich rein - die sind dann lediglich in remotes/<remotename>/... verfügbar - und werden per "git branch" nicht angezeigt, sondern nur bei "git branch -a" und "git branch -r". Und ge"push"ed werden die sowieso nicht. Sind also für fast alle Zwecke nicht da - aber man hat die als Quelle für MErges und Cherrypicks.



    Du arbeitest aber hauptsächlich über deinen eigenen Bitbucket-Server, oder?

    Das "SVN Mirror" (genauso ist aber auch Subgit) sind für Read-Only-SVN-Quellen nicght wirklich ausgelegt, weil die aich zurück syncen wollen. Ich muss das Repository auf meinen Server also als "pull only" betreiben. Arbeiten tue ich quasi ausschleißlich im git client von git-scm.com

  • Ich habe mal da eine Frage zu den Sourcen vom Originalen VICE vs Eurem Forks.

    Es sind doch sicherlich viele UI unabhängigen Source Dateien in der neuesten Versionen drin, die man (z.B. bei Eurem Fork) zurückportieren könnte, oder?


    Ich denke mal, wenn z.B. eine Verbesserung in der Floppy Emulation oder ein neues Disk/Cartridge Format hinzukommt, müsste das rückportierbar sein, weil hier das UI vermutlich wenn überhaupt nur unwesentlich angepasst wird.


    Oder ist das eher schwierig und naiv wie ich mir das so zusammenreime?

  • Das hängt natürlich davon ab, ob die Änderungen Ausschnitte von Dateien betreffen, die unverändert in der alten Version verhanden sind. Wenn ja, kann der Patch automatisch übernommen werden.

    Wenn nicht, kann man Glück haben und die Probleme betreffen nur die GUI-Teile. Im Falle von den Beispiel neuer Cartridges würde das bedeuten, dass man die zwar im CRT einladen kann, im Menü aber der Eintrag fehlt, um die als .bin einzuladen. Nicht optimal, aber mindestens eine gute Grundlage.

    Und ium schlechtesten Fall wirft Git beim Versuch, die Änderung zu übernehmen nur Konflikte raus. In dem Fall kann das von leicht behebbar bis schwierig variieren.

  • Alles, was Du nicht willst, solltest Du nicht in Dein Github "push"en. S. o., wenn Du dann Dein Repo neu auscheckst, um origin passend zu haben, hast Du dann nur noch die angenehmen Branches. Und ein späterer "git pull" bzw. "git fetch" (git pull ist lediglich eine Kurzform für git fetch gefolgt von git merge) holt die unerwünschten Branches nicht wirklich rein - die sind dann lediglich in remotes/<remotename>/... verfügbar - und werden per "git branch" nicht angezeigt, sondern nur bei "git branch -a" und "git branch -r". Und ge"push"ed werden die sowieso nicht. Sind also für fast alle Zwecke nicht da - aber man hat die als Quelle für MErges und Cherrypicks.

    Danke für die vielen Tipps, für die ich exemplarisch obiges Zitat rausgesucht habe! In meinem Kopf formt sich so langsam ein Bild, wie ich das dann in meinem Repo gerne haben wollen würde und werde morgen erstmal lokal schauen ob ich das so wie gewünscht hinkriege.


    Selbst wenn ich nur deinen "master"-Branch in mein Repo als remote aufnehme, müssten doch aufgrund der identischen Hashes der Commits, von denen alle eigenen Commits in anderen Branches abgeleitet sind, möglich sein? Gibt da wohl die Möglichkeit über git init und anschließendem git remote nur einen spezifischen Remote-Branch ins eigene Repo aufzunehmen. Muss aber noch testen, ob da wirklich die Hashes gleich sind.

    Bei einem normalen clone selbst mit single-branch wären sämtliche andere Branches dennoch gefetcht; muss prüfen, ob die dann wenigstens nicht in mein GitHub-Repo gepusht werden würden, denke aber schon.


    Was derzeit mein Vorhaben bei aktuellem Kenntnisstand bzgl. Vor- und Nachteile ist:

    • den "master"-Branch aus deinem Bitbucket-Repo als meinen Branch der offiziellen Version nehmen, damit wir dort dieselben Hashes für die folgende Ableitung eigener Branches zu haben
    • Cherrypicking und Merging sollten dadurch dann hoffentlich möglich sein, selbst wenn wir die jeweiligen Branches des Anderen nicht im eigenen Repo haben
    • dein Repo würde ich ggf. als "upstream" statt "origin" remote einbinden
    • deinen "master"-Branch würde ich gerne anders nennen, weil ich meinen "master" tatsächlich für den Hauptentwicklungszweig nutzen möchte, von dem ich meine eigenen Feature-Branches ableite
    • wenn ich das lokal so eingerichtet bekommen und erfolgreich mal cherrypicking/merging in mein lokales Repo testen konnte, würde ich ein so eingerichtetes frisches Repo erzeugen und auf GitHub pushen
    • danach könnte ich dann sauber unter Versionskontrolle meine eigentlichen Versuche an WinVICE fortsetzen

    Es sind doch sicherlich viele UI unabhängigen Source Dateien in der neuesten Versionen drin, die man (z.B. bei Eurem Fork) zurückportieren könnte, oder?

    Ich habe noch nicht einmal den Gedanken komplett verworfen, sukzessive ausgehend von VICE 3.2 die nachfolgenden Weiterentwicklungen zu mergen (und nicht nur einzelne Cherrypicks), die native Oberfläche (also WinVICE) dabei aber beizubehalten. Ich vermute aber, ich lande damit in der Merge-Hölle :D

  • Selbst wenn ich nur deinen "master"-Branch in mein Repo als remote aufnehme, müssten doch aufgrund der identischen Hashes der Commits, von denen alle eigenen Commits in anderen Branches abgeleitet sind, möglich sein? Gibt da wohl die Möglichkeit über git init und anschließendem git remote nur einen spezifischen Remote-Branch ins eigene Repo aufzunehmen. Muss aber noch testen, ob da wirklich die Hashes gleich sind.

    Wenn man das richtig macht, reicht es in der Tat, alles auf "master" zu basieren.


    Da das aber eine sehr wichtige Stelle ist, muss ich da ausführlicher drauf eingehen: Wenn man bereits ein Repository mit abweichenden SHA1 hat, so kann man mit einen zweiten remote nicht direkt auf einen "grünen Zweig" kommen. Das durfte ich in der Praxis auch schon mal ausprobieren, für die 1541 Ultimate 2 (nicht Plus!) gibt es im Internet inoffizielel Patches als Git Repo, die leider nicht zu meinen SHA1 gepasst haben. Folgendes hat funktioniert:


    1. Aus dem Repository, welches die SHA1 hat, die man nicht mehr benutzen will: Per "git format-patch" die Änderungen als Patch zu exportieren.

    2. In dem anderen Repository die Patches dann IIRC per "git apply" die Patches wieder reinzuholen.


    Dadurch werden die Commits an die anderen SHA1s angepasst.


    In der Tat ist das für viele praktische Zwecke gleich wie auf "10sids" ausetzen - denn einfach ein "rebase" auf 10sids im git durchführen und man hat den anderen Ansatz auch... Kann man sogar mit einer extra Branch machen, so dass die Entwicklungsbranch nicht beeinträchtigt wird.

    Selbst wenn ich nur deinen "master"-Branch in mein Repo als remote aufnehme, müssten doch aufgrund der identischen Hashes der Commits, von denen alle eigenen Commits in anderen Branches abgeleitet sind, möglich sein? Gibt da wohl die Möglichkeit über git init und anschließendem git remote nur einen spezifischen Remote-Branch ins eigene Repo aufzunehmen. Muss aber noch testen, ob da wirklich die Hashes gleich sind.

    Werden die nicht - in meinen 1541 Ultimate Repository Worktree habe ich remotes von allen wichtigen Contributoren drin. Und im Guthub siehst Du davon nichts.

    den "master"-Branch aus deinem Bitbucket-Repo als meinen Branch der offiziellen Version nehmen, damit wir dort dieselben Hashes für die folgende Ableitung eigener Branches zu haben

    s. o.

    Cherrypicking und Merging sollten dadurch dann hoffentlich möglich sein, selbst wenn wir die jeweiligen Branches des Anderen nicht im eigenen Repo haben

    Sind dann defintiv möglich

    dein Repo würde ich ggf. als "upstream" statt "origin" remote einbinden

    Kein Problem - wenn Du es nicht live geändert bekommst, einfach deins neu auschecken und meins als Remote "upstream" hinzufügen.

    deinen "master"-Branch würde ich gerne anders nennen, weil ich meinen "master" tatsächlich für den Hauptentwicklungszweig nutzen möchte, von dem ich meine eigenen Feature-Branches ableite

    Auch das wird kein Problem darstelllen - in dem Fall gönnst Du Dir einfach eine Branch "upstream". Kannst Du einfach als Branch von master erstellen - Initial (d. h. bevor Du Deine Commits eingespielt hast) werden die ja gleich sein. Siehe die Bemerkung am Anfang dieses Postings.

    wenn ich das lokal so eingerichtet bekommen und erfolgreich mal cherrypicking/merging in mein lokales Repo testen konnte, würde ich ein so eingerichtetes frisches Repo erzeugen und auf GitHub pushen

    Github ist auch super geeignet. Es hat Vorteile, wenn die Repos etwas gestreut sind. Wenn ein Dienst Probleme welcher Art auch immer hat, sind noch die anderen da...


    Wenn es soweit ist, binde ich das bei mir auch ein.

    danach könnte ich dann sauber unter Versionskontrolle meine eigentlichen Versuche an WinVICE fortsetzen

    :-)

  • Mir ist hier eben was komisches aufgefallen, als ich versucht habe, dieses neue Spiel hier


    https://csdb.dk/release/?id=186849


    mit der x64sc.exe und der x64.exe des WinVICE V3.2 zu spielen. Während im HOXS und im DENISE die Autos in diesem Spiel ganz normal platziert sind und dann auch losfahren nachdem man F1 gedrückt hat, hängen sie im WinVICE V3.2 (egal welche Version, also ob die mit 8SID Support oder die mit V2.4 SID-Filter) irgendwie in der oberen linken Ecke fest und die vom Computer gesteuerten Autos fahren erst gar nicht los.


    Sehr komisches Fehlerbild. Kann das mal jemand nachstellen auf seinem PC mit WinVICE V3.2, ob es sich da genauso äussert? Oder ob das vielleicht mit irgendeiner Konfigurationseinstellunge bei mir hier zu tun hat. Wobei ich momentan nicht wüsste, welche hier das Problem verursachen könnte. So ein merkwürdiges Fehlerbild in einem Emulator, also dass Sprites nicht das tun was sie sollten, hatte ich auch noch nicht. :)


    Dachte, ich melde das gleich mal hier im Thread, denn vielleicht ist das ja ein Bug der normalen WinVICE V3.2 Version, dann kann das, wenn man das Problem analysieren kann, vielleicht auch gleich mit gefixt werden.

  • Das Game funzt bei mir ohne Probleme in WinVICE.


    Leerschlag zum beschleunigen, Steuerung mit dem Joystick.


    Hm, das ist echt verrückt. Bei mir sieht es so aus, wenn ich drei CPU-Gegner und mich als Fahrer einstelle:



    Die Autos befinden sich alle vier am selben Punkt, das blaue überlagert die darunterliegenden anderen Autos. Ich kann nun zwar rumlenken, aber die CPU Gegner hängen alle in der oberen linken Ecke fest und fahren nicht los. Der Sound stockt auch merkwürdig.


    Dann ist es also doch irgendeine Einstellung in meinem WinVICE, die das verursacht. Ich probier mal etwas rum und schau mal, wie ich das Problem lösen kann.

  • Hab jetzt rausgefunden, was dieses komische Problem in diesem Spiel verursacht, "Angryking".


    Wenn gleichzeitig zu "True Drive Emulation" auch noch "Virtual Device Traps" eingeschaltet ist, dann passiert genau das, was ich beschrieb. Dass sich zusätzlich eingeschaltete "Virtual Device Traps" dann auf so eine merkwürdige Art äussern, hatte ich auch noch nie.


    Okay, dann ist diese Sache kein WinVICE Bug und somit erledigt. Hätte wirklich keinesfalls gedacht, dass es mit den "Virtual Device Traps" zusammenhängen könnte. Bislang war meine Erfahrung immer die, dass sich manche Software dann gar nicht laden lässt, wenn beides an ist, also "True Drive" und "Virtual DT". Aber dass ein Spiel zunächst mal ganz normal lädt und startet und dann im Gameplay plötzlich derartige Fehler sind, war mir noch neu. Musst du mal nachstellen bei dir, "Angryking".


    Das Game läuft nur richtig, wenn lediglich "True Drive Emulation" eingeschaltet ist. Nur mit "Virtual Device Traps" lässt es sich erst gar nicht laden und wenn beides an ist, dann gibt's eben beschriebenes Fehlerbild. Gibt ja mehrere Fälle von Demos oder Games, die nur mit "True Drive Em" korrekt laufen, aber ich kenne keinen weiteren Fall, der dann wie hier jetzt Fehler wie komisches Spriteverhalten usw im Gameplay hat, wenn zusätzlich noch "Virtual Device Traps" an ist.

  • Wenn gleichzeitig zu "True Drive Emulation" auch noch "Virtual Device Traps" eingeschaltet ist, dann passiert genau das, was ich beschrieb.

    Merkwürdig, kannst du es mal mit VICE 2.4 ausprobieren? Bei mir hat es da mit aktivierten beiden Optionen bei einem Schnelltest funktioniert. Wäre eine coole Sache gewesen, wenn es dort auch nur durch "Virtual Device Traps" in Verbindung mit "True Drive Emulation" auftreten würde, da man das Spiel dann mit Accurate-Disk-Option (die wohl "True Drive Emulation" entsprechen dürfte) zum Prüfen des TheC64 bzgl. ausgeschalteter "Virtual Device Traps"-Option verwenden könnte. Mit der Option gibt es nämlich auch mit Ultima V Probleme (anderer Thread hier im Forum), und ich denke dass beim TheC64 diese Option aktiviert ist; habe denen sogar diesbezüglich geschrieben.

    Werden die nicht - in meinen 1541 Ultimate Repository Worktree habe ich remotes von allen wichtigen Contributoren drin. Und im Guthub siehst Du davon nichts.

    Habe deinen master-Branch nun bei mir als "vanilla-vice"-Branch im GitHub, die Hashes der dortigen Commits sind identisch. :thumbup: Optimal, um eine gemeinsame Basis zu haben, auf die man Fixes/Erweiterungen/... zurückführen und somit gegenseitig mergen kann.


    Ist zumindest die umfangreichste .git/config, die ich für mich je für so eine Art Projekt hatte. Vorteile bei mir lokal:

    • git pull (ohne Parameter) zieht im "vanilla-vice"-Branch den master deines Bitbucket-Repos
    • ...es werden automatisch auch deine svn-mirror-Notes mit den Revision/Branch-Angaben gezogen
    • ...diese werden bei mir automatisch unter refs/notes/svn-mirror/commits abgelegt (damit ich im Standard-refs/notes/commits völlig getrennt eigene machen könnte)
    • ...die mittels displayRef zusätzlich zu ggf. eigenen getrennten Notes automatisch im Log folgendermaßen angezeigt werden: "Notes (svn-mirror/commits): (rev) (branch)"
    • ...Tags merge ich nicht in den "vanilla-vice"-Branch (falls du welche anlegen solltest), damit die nicht in Konflikt mit meinen eigenen Tags geraten würden
    • ...beim automatisierten Merge lasse ich im "vanilla-vice"-Branch nur fast-forward-Merges zu, weil ich durch die Ableitung der anderen Branches (siehe unten) sonst ganz andere Probleme bekommen würde, und so lieber manuell interagieren muss
    • git push (ohne Parameter) schiebt im "vanilla-vice"-Branch jenen unter gleichem Namen auf mein GitHub-Repo
    • ...deine Notes vom SVN-Mirror pushe ich dabei bisher nicht; ob ich das mal machen werde, weiß ich noch nicht, da das automatisierte "mit-Pushen" auf mein origin (GitHub) andere Implikationen hätte (git scheint bisher dafür nur wenig Möglichkeiten zu bieten, die aber wieder andere Abläufe [ggf. negativ] beeinflussen könnten). Manuelle zusätzliche Pushes für Notes, die man auch direkt aus deinem Repo ziehen könnte, habe ich deshalb nicht vor. Da man das noch (inkl. der ganzen Überlegungen über Implikationen) ohne Probleme nachziehen könnte, mache ich erst einmal an anderer Stelle weiter.

    Als Branches habe ich geplant:

    • vanilla-vice (gibt es bereits, master [SVN-Mirror des offiziellen Subversion-Repos] aus deinem Bitbucket-Repo)
    • win-still-in (sukzessive Merges aus vanilla-vice mit angepassten [natives Win-UI nicht entfernt und manuelle Behebung dadurch auftretender Merge-Konflikte] Commits)
    • feature/[Feature-Name 1..n] (Feature-Branches, sowohl von eigenen Fixes/Erweiterungen, als auch für Integrationsvorbereitung der Patches von anderen Entwicklern [z.B. dein 8-/10-SID])
    • develop (Entwicklungsstand der Integration aus "win-still-in", bereits integrierbaren Feature-Branches sowie kleinen direkten Änderungen [Programmname, Versionsnummer, ...]; Basis für ggf. spätere nightly builds)
    • master (Releasestand [jeder Commit ein Release, später ggf. Basis für automatisierte Release-Builds per GitHub-Actions/AppVeyor/...])

    Ist für mich eher ein interessantes Experiment und Sammeln weiterer Erfahrungen. Wie lange mich das Thema ggü. anderen interessanten Themen, die ich in meiner Freizeit noch machen möchte und werde, motiviert hält, kann und will ich nicht abschätzen (es ist ein Hobby). Ich würde jedoch gerne zumindest eine Version bereitstellen, die anderen wie AW182 schon einmal enorm weiterhilft. Was danach passiert, wird die Zeit zeigen...