Vice 3.4

Zitat von angryking

Ja schön, nur ist er ja gar nicht mehr hier seit längerem.

Und ich kann es aber leider nicht beantworten und auch nichts machen, wenn er schon länger nicht mehr online ist. Vielleicht hat er momentan auch andere Sorgen, wäre ja nicht so ganz verwunderlich, bei dem was gerade so abgeht.

Zitat von angryking

Damit habe ich ja kein Problem, ich versuche nur zu verstehen, warum dann anstelle von Faktor 0.9975 der Faktor 0.99751534638994446068401052323882 verwendet wird. (Siehe https://github.com/andresteine…0e30cb7b6194ac7f3a2a4f92d)

Keine Ahnung. Aber warum nicht, ist doch ne schön anzuschauende Zahl.

Zitat von angryking

Zugegeben, das tue ich schon ein wenig, und ich bin bestimmt nicht der einzige hier. Selbst Lipti schreibt ja:
"...is REALLY dirty at the moment!".

Aber alles ist besser als nichts, um hier zu versuchen, eine Verbesserung zu erzielen, die es ja viele Jahre lang nicht gab. Den Testbuild nehme ich jetzt jedenfalls lieber als die normale Version, die ich ja immer mit 101% Speed und 51Hz laufenlassen musste, um den Soundbug wegzubekommen. Beim Testbuild ist das nicht nötig, der kann mit Normalspeed (in dem Fall eben 99,75%) laufen und ich hab trotzdem kein Soundproblem, was natürlich die Performance schonmal verbessert im Vergleich zur normalen Version.

So, ich war jetzt bisschen über eine Stunde weg und habe meinen PC folgendes machen lassen, während ich TV schaute, denn das Ergebnis von dem hier

Zitat von AW182

Wegen PAL nochmal. Ich werde jetzt mal folgendes machen mit der normalen Version des WinVICE V3.2, um zu sehen, ob ich auch wirklich immer zu 100% Fullspeed habe, wenn ich den WinVICE im 50Hz Vollbild laufenlasse (also mit dem Soundkratzen). Es gibt ja mehrere Uhren-Tools, wie etwa das hier

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

Das lasse ich jetzt mal 10 Minuten laufen unter 50Hz Vollbild und stoppe nebenbei mit einer Digital-Uhr mit.

stand ja noch aus.

Zunächst nahm ich also die normale WinVICE V3.2 Version, ließ sie mit 100% Speed laufen (also mit 50,125Hz) und ließ dann dieses Clock Tool eine halbe Stunde lang laufen und stoppte nebenbei mit.

Es war so, und das stimmt wirklich, dass es keine einzige Sekunde Abweichung gab, am Ende dieser 30 mitgestoppten Minuten. Keine einzige Sekunde. Mein Eindruck des dauerhaft weichen Scrollings hat mich also nicht getäuscht. Wenn es anders wäre, hätte ich auch kein Problem das zu schreiben, war es aber nicht. Das KANN doch dann nur bedeuten, dass ich mit 50Hz Vollbild hier keinerlei Speedeinbrüche habe, denn sonst hätten hier doch Abweichungen rauskommen müssen, aber es blieb wirklich bis auf die Sekunde stabil in 30 Minuten. Am liebsten würde ich dich zu mir einladen "Angryking", dann könnte ich dir das direkt selbst mal vorführen unter 50Hz Vollbild. Es ist also wie ich es mir, aufgrund des weichen Scrollings, eh schon gedacht hatte, der Speed bricht hier nicht ein, auch nicht ein bisschen, also keine Speedschwankungen.

Aber im WinVICE Fenster, wenn ein 50Hz Screenmode im Windows läuft, schwankt der Speed dann manchmal auch bei mir zwischen 94 und 100%. Im Vollbild aber keinerlei Speedeinbruch. Wo da jetzt der genaue Unterschied ist, kann ich mir auch nicht erklären, aber so äussert es sich der Praxis und nicht nur auf meinem PC.

Was ich mich hier jetzt frage ist - wer sagt denn eigentlich, dass die Speedanzeige im WinVICE Fenster noch wirklich genau stimmt, wenn man den Emulator unter 50Hz im Fenstermodus laufenlässt? Vielleicht haben die sich in die Quere kommenden Syncs darauf auch irgendeinen Einfluss und sie stimmt einfach nicht mehr richtig? Wäre das möglich?

Eines wäre noch interessant zu wissen - könntest du mal folgendes ausprobieren bei dir, "Angryking"? Schalte mal "Render to DX primary surface" aus, stell im WinVICE ein 50Hz Vollbild ein, lade dann mal dieses Clock Tool und stoppe nebenher mal eine halbe Stunde lang die Zeit mit einer externen Uhr mit. Danach wissen wir ganz sicher, ob dein Speed im Vollbild wirklich richtig einbricht oder nicht, denn es müssten sich ja dann bei dir Abweichungen ergeben in den beiden Zeiten.

Und ich hab noch was gemacht, weil es mich interessiert hat. Als Zweites nahm ich dann noch den Testbuild, um einmal in Sekunden zu sehen, was denn diese 0,25% weniger Speed so ausmachen auf etwas längere Sicht gesehen. Also ließ ich das Clock Tool damit auch wieder 30 Minuten laufen und die Abweichung am Schluss war gerade mal irgendetwas zwischen 4 und 5 Sekunden (die Zehntelsekunden konnte ich jetzt nicht genau mitstoppen, aber auch nicht nötig). Also das merkt wirklich kein Mensch, weder in SID's beim Sound anhören, noch beim spielen eines Games, wenn der C64 hier dann mit 50,000Hz läuft anstatt mit 50,125Hz.

NACHTRAG (paar Minuten später)

Auch in der Theorie jetzt nochmal kurz nachgerechnet, um die halbstündige Messung mit den 50,00Hz Speed zu bestätigen:

30 Minuten sind 1800 Sekunden, davon ein Vierhundertstel (0,25%) = 4,5 Sekunden. Passt.

Zitat von AW182

Aber warum nicht, ist doch ne schön anzuschauende Zahl.

Wie diese Zahl zustande kommt, ist ja bekannt (50 / C64_PAL_RFSH_PER_SEC). Deshalb nahm mich ja Wunder, ob der ganze Test nur für x64 mit PAL gilt. Denn der PAL-N z.B. läuft nicht mehr mit demselben Refresh. Wenn das stimmt, was im Code von VICE steht, so mit ~50.465Hz

Aber offenbar hat Lipti ja dazu nichts gesagt.

Und bei mir kommt noch hinzu, dass der Monitor nicht mit 50, sondern mit 50.125Hz läuft, stimmt dann alles irgendwie auch nicht mehr so richtig für mich.

Zitat von AW182

Aber alles ist besser als nichts, um hier zu versuchen, eine Verbesserung zu erzielen, die es ja viele Jahre lang nicht gab

Schon. Die Frage ist aber auch, ob und welche Nebenwirkungen das hat. Kann ja sein, dass das Timing nicht mehr stimmt wenn man externe Hardware anhängt?

Zumindest die Speedanzeige stimmt nicht mehr zu 100%, ist natürlich eher unwichtig bei der minimalen Differenz.

Zitat von AW182

Was ich mich hier jetzt frage ist - wer sagt denn eigentlich, dass die Speedanzeige im WinVICE Fenster noch wirklich genau stimmt, wenn man den Emulator unter 50Hz im Fenstermodus laufenlässt? Vielleicht haben die sich in die Quere kommenden Syncs darauf auch irgendeinen Einfluss und sie stimmt einfach nicht mehr richtig? Wäre das möglich?

Also ich würde mal sagen, die passt schon, Fraps zeigt mir immer sehr ähnliche Werte an für die FPS.

Den Test muss ich irgendwann mal wiederholen, blöderweise hatte ich einen Fehler gemacht, und der "Lipti-Fix" war aktiviert und die Uhr lief dann natürlich falsch.

Zitat von angryking

Schon. Die Frage ist aber auch, ob und welche Nebenwirkungen das hat. Kann ja sein, dass das Timing nicht mehr stimmt wenn man externe Hardware anhängt?

Genau. Deswegen ist es ja auch immernoch nur ein Testbuild, um vor dem ersten richtigen Release erstmal einigermaßen abzuklären, ob der kleine Geschwindigkeitsunterschied nicht doch noch irgendwelche grösseren Nebenwirkungen hat. Deshalb probiere ich seit Wochen damit Software durch, anstatt dass man es gleich veröffentlicht hat. Sieht bislang aber ganz gut aus.

Und selbst wenn es bei einigen Programmen Nebenwirkungen hätte, dann könnte man den 50,000Hz Modus ja als zuschaltbare Option anbieten. Könnte man beispielsweise in den bereits jetzt schon vorgegebenen Custom-Speeds (10%, 20%, 50%...) mit hinzufügen, etwa als 99,75% (50,0Hz). Trifft man dann auf ein Programm, welches das nicht verträgt, schaltet man dafür einfach wieder in den 50,125Hz Modus um und muss dann halt wieder das Soundkratzen in Kauf nehmen. Aber eigentlich gehe ich davon aus, dass diese -0,25% Speed nur ganz ganz selten ein Problem verursachen werden, denn schließlich läuft mein normaler WinVICE Build schon seit längerem mit 101% Custom-Speed und 51Hz Vollbild, um den Soundbug zu umgehen, und bislang hat damit noch kein einziges Programm gezickt. Vielleicht bei externer Hardware, aber dann könnte man ja immernoch zurückschalten auf 50,125Hz.

Zitat von angryking

Zitat von AW182

Was ich mich hier jetzt frage ist - wer sagt denn eigentlich, dass die Speedanzeige im WinVICE Fenster noch wirklich genau stimmt, wenn man den Emulator unter 50Hz im Fenstermodus laufenlässt? Vielleicht haben die sich in die Quere kommenden Syncs darauf auch irgendeinen Einfluss und sie stimmt einfach nicht mehr richtig? Wäre das möglich?

Also ich würde mal sagen, die passt schon, Fraps zeigt mir immer sehr ähnliche Werte an für die FPS.

Naja, etwas merkwürdig ist es schon, dass der 50FPS Fenstermodus Speedschwankungen anzeigt, im Vollbild aber keinerlei auftreten bei mir und auch bei drei weiteren PC's auf denen ich das probierte. Oder er synct im VICE Vollbild irgendwie anders als im Windows Vollbild? Ich werde den Test mit der Uhr auch mal im 50FPS Fenstermodus nachstellen, ob das echte Speedeinbrüche auf 94% sind, oder ob nur die Anzeige etwas spinnt, wenn sich die Sync Codes zu nahe sind. Falls es echte sind, müsste es dann nach einer halben Stunde ja doch sichtlich abweichen von der echten Uhr und die Emulation hinterherhinken.

Zitat von angryking

Wie diese Zahl zustande kommt, ist ja bekannt (50 / C64_PAL_RFSH_PER_SEC).

Eben nicht, das hatte ich schon nachgerechnet. Da käme dann 0,9975062344139651 raus, statt dieser 0,99751534638994446068401052323882. Deshalb ist mir momentan auch nicht klar, wie man auf diese Nachkommastellen kommt. Aber eigentlich auch egal, Hauptsache es funktioniert.

Zitat von angryking

Den Test muss ich irgendwann mal wiederholen, blöderweise hatte ich einen Fehler gemacht, und der "Lipti-Fix" war aktiviert und die Uhr lief dann natürlich falsch.

Das wäre nicht schlimm gewesen, denn du weisst ja durch meinen Post, dass die Abweichung dann 4 bis 5 Sekunden sein müsste, bei einer halben Stunde mitstoppen.

Zitat von AW182

Ich werde den Test mit der Uhr auch mal im 50FPS Fenstermodus nachstellen, ob das echte Speedeinbrüche auf 94% sind, oder ob nur die Anzeige etwas spinnt, wenn sich die Sync Codes zu nahe sind. Falls es echte sind, müsste es dann nach einer halben Stunde ja doch sichtlich abweichen von der echten Uhr und die Emulation hinterherhinken.

Das habe ich jetzt eben durchgeführt. Es sieht folgendermaßen aus.

Lasse ich das Clock Programm im 50FPS Fenstermodus des normalen WinVICE (50,125Hz) laufen, habe ich nach einer halben Stunden eine Abweichung von circa 6 Sekunden, die der Emulator der echten Uhr hinterherhinkt. Die Speed-Anzeige im WinVICE schwankte dabei meistens irgendwo zwischen 94% und 100% hin und her.

Das zeigt mir zwei Sachen:

- es gibt tatsächlich, wie ich es mir schon dachte, einen klaren Unterschied zwischen 50FPS Fenstermodus und 50FPS Vollbild, wo der Emulator ja sekundengenau lief

- die Speedanzeige des WinVICE kann trotzdem nicht richtig stimmen unter 50FPS Fenstermodus, denn diese Anzeige schwankte bei mir hier während des Tests zumeist zwischen 94% als niedrigstem Wert und 100% hin und her. Gehen wir nun mal, wegen des häufigen Schwankens, von einem Mittelwert von 97% aus, in dem VICE hier dann nun lief. Dann müsste die Abweichung bei einer halben Stunde, die ja 1800 Sekunden entspricht, um die 54 Sekunden sein (kann man ja ausrechnen), also fast eine Minute. Letztendlich waren es aber nur 6 Sekunden. Also unter einem 50Hz Bild kann man sich auf die WinVICE Speedanzeige des Fensters, nicht mehr wirklich verlassen. Da funkt dann wahrscheinlich irgendetwas mit rein, was wohl mit den beiden sich in die Quere kommenden Syncs zu tun hat. Diese Speed-Anzeige zeigt dann scheinbar grössere Schwankungen an, als tatsächlich auftreten, denn wie erklärt sich sonst der Unterschied zwischen den ausgerechneten 54 Sekunden und den gemessenen 6 Sekunden? Diese 6 Sekunden Abweichung würden umgerechnet nämlich bedeuten, dass der Emulator in dieser halben Stunde, dann mit einem Speed von durchschnittlich 99,667% lief, während die Speedanzeige aber zumeist irgendwo zwischen 94% und 100% hin und her schwankte.

Jedoch muss man eines auch sagen. Diese 6 Sekunden Abweichung zeigen auch, dass der Emulator im 50FPS Fenstermodus nicht ganz 100% richtig läuft und das reicht schon, um in einigen scrollenden Spielen ab und zu mal einen kleinen Ruckler zu haben, den man auch merkt. Dazu hab ich mir auch nochmal den "Giana Sisters" Intro Scroller angesehen und man sieht das im Fenstermodus dann dort auch. Im 50FPS Vollbild des WinVICE hingegen, sehe ich keinen einzigen Ruckler im Giana Scroller und der Test mit der Uhr bestätigt es ja auch, dass es da im Vollbild keinerlei Speedeinbrüche bei mir gibt. Aber das Soundkratzen alle 30 Sekunden (bei Soundbuffergröße 100ms) habe ich trotzdem, sowohl unter 50FPS Vollbild, als auch im 50FPS Fenstermodus. So verhält es sich auf meiner Hardware und ebenso auf der einiger Kumpels von mir.

Zitat von AW182

mit 101% Custom-Speed und 51Hz Vollbild

Ich verstehe noch immer nicht. wirklich. Ziel war es doch, daß Emulator und Monitor Freuquenz etwas weiter auseinander liegen (siehe altbekanntes Zitat gleich unten). Wenn du beides erhöhst, ist doch gar nicht viel gewonnen.

In deinem Fall gäbe das ja dann 51Hz - 50.62625Hz

Ließe man den Monitor auf 50Hz, wäre die Differenz größer. Oder man hätte die Monitor Frequenz auf 49Hz stellen können ohne VICE was rumzubasteln?

Zitat

This problem occures in Windows build when emulator frequence and monitor frequence are (nearly) the same and the emulators sync code fights with the DirectX VBlanc feature

Und jetzt kommt's noch härter: Der Lipti Patch macht ja eigentlich genau das Gegenteil: Durch Drosselung von VICE laufen ja dann beide praktisch gleich schnell, mit 50Hz (50.125 *.997451 = 50)

Zitat von AW182

Eben nicht, das hatte ich schon nachgerechnet. Da käme dann 0,9975062344139651 raus, statt dieser 0,99751534638994446068401052323882. Deshalb ist mir momentan auch nicht klar, wie man auf diese Nachkommastellen kommt.

Auch wenn es keine Rolle spielt: Du rechnest wohl nicht mit den korrekten Werten, die stehen in https://github.com/Classicmods…master/vice/src/c64/c64.h

50 / (985248 / (63 * 312)) = 0.99751534638994446068401052323882

Sagt mein Win 7 taschenrechner.

Zitat von angryking

Ich verstehe noch immer nicht. wirklich. Ziel war es doch, daß Emulator und Monitor Freuquenz etwas weiter auseinander liegen (siehe altbekanntes Zitat gleich unten). Wenn du beides erhöhst, ist doch gar nicht viel gewonnen.

In deinem Fall gäbe das ja dann 51Hz - 50.62625Hz

Ließe man den Monitor auf 50Hz, wäre die Differenz größer. Oder man hätte die Monitor Frequenz auf 49Hz stellen können ohne VICE was rumzubasteln?

Genau das hatte ich aber schon mehrfach erläutert, weil ich dies durch viel herumtesten herausfand. Ich schreibe es nochmal.

Nicht unbedingt muss gelten "daß Emulator und Monitor Frequenz etwas weiter auseinander liegen müssen", sie KÖNNEN SICH EBEN SCHON ANNÄHERN, WENN DER HZ-WERT DES EMULIERTEN C64 SICH VON UNTEN HER KOMMEND, DER MONITOR-FREQUENZ ANNÄHERT. Denn der Soundbug im WinVICE tritt immer nur dann auf, wenn der Hz-Wert des emulierten C64 größer ist als der Hz-Wert der Monitor-Frequenz. Und das ist ja beim normalen WinVICE Betrieb unter 50Hz leider der Fall, weil der emulierte C64 mit 50,125Hz läuft, während der Vollbildmodus bei irgendwas um die 50,00Hz herum läuft. Jedenfalls ist er etwas kleiner und das reicht schon, um das Soundkratzen auszulösen.

Lässt man nun entweder

- den WinVICE mit Custom-Speed 99% laufen (was dann circa 49,62Hz entspricht) und einen 50Hz Vollbildmodus dazu

- oder den WinVICE mit Custom-Speed 101% laufen (ist dann 50,63Hz) und nutzt dazu dann einen 51Hz Vollbildmodus

dann ist jeweils immer gegeben, dass der emulierte C64 vom Hz-Wert her kleiner ist, als der des verwendeten Vollbildmodus und somit tritt dann kein Soundkratzen auf. Das habe ich auf mehreren Rechnern ausprobiert und es war auf JEDEM so. Ich bevorzuge die Variante mit 101% und 51Hz Vollbild, weil da bei mir der kleine Ruckler im Scrolling noch etwas seltener kommt, als bei 99% und 50Hz Vollbild. Da kommt wohl der Monitor dann noch etwas besser damit klar.

Zitat von angryking

Und jetzt kommt's noch härter: Der Lipti Patch macht ja eigentlich genau das Gegenteil: Durch Drosselung von VICE laufen ja dann beide praktisch gleich schnell, mit 50Hz (50.125 *.997451 = 50)

Eben nicht. Der Lipti Patch erreicht, dass der Hz-Wert des emulierten C64 dann EBEN NICHT MEHR größer ist, als der des 50Hz Vollbildmodus. Man sieht, dass sich der Hz-Wert des emulierten C64 von unten her kommend, so nah an die 50Hz des Vollbildmodus annähern kann, bis die beiden Werte beinahe gleich gross sind, wie es nun beim Tesstbuild ist, und noch immer tritt kein Soundkratzen auf. Und der Vorteil ist nun, dass das Scrolling nicht mehr alle 5 Sekunden einmal ruckelt, wie es noch bei Custom-Speed 99% der Fall war.

Darauf werde ich jetzt aber nicht nochmals eingehen, falls nochmal eine Frage dazu kommt, weil ich nicht einsehe, immer wieder das Gleiche schreiben zu müssen. Ich kann nur sagen, was ich durch viel rumtesten auf verschiedenen PC's zu der Thematik herausfand und das ist eben genau das hier. So verhielt es sich auf diesen Rechnern.

Zitat von angryking

Zitat von AW182

Eben nicht, das hatte ich schon nachgerechnet. Da käme dann 0,9975062344139651 raus, statt dieser 0,99751534638994446068401052323882. Deshalb ist mir momentan auch nicht klar, wie man auf diese Nachkommastellen kommt.

Auch wenn es keine Rolle spielt: Du rechnest wohl nicht mit den korrekten Werten, die stehen in https://github.com/Classicmods…master/vice/src/c64/c64.h

50 / (985248 / (63 * 312)) = 0.99751534638994446068401052323882

Sagt mein Win 7 taschenrechner.

Ah okay. Ich hatte zum Nachrechnen immer 50,125 benutzt und nicht "50,123432124542124" mit all diesen Nachkommastellen als PAL Frequenz. Gut, damit ist dann auch klar, wie dieser genaue Wert ensteht in "Lipti's" Testbuild, auch wenn das jetzt für die allgemeine Problematik keine Rolle spielt.

Zitat von AW182

Eben nicht. Der Lipti Patch erreicht, dass der Hz-Wert des emulierten C64 dann EBEN NICHT MEHR größer ist, als der des 50Hz Vollbildmodus. Man sieht, dass sich der Hz-Wert des emulierten C64 von unten her kommend, so nah an die 50Hz des Vollbildmodus annähern kann,

Gut, er ist nicht mehr größer, sondern einfach exakt gleich groß. Nimm doch mal den Taschenrechner zur Hand und mach die Rechnung: Der Emulierte C64 läuft mit dem Patch genau mit 50Hz, aber sowas von exakt. Da kann sich von keiner Seite her was nähern.

Würde ja auch bedeuten, daß Leute mit 50.125Hz Monitor keine Probleme haben, ist aber (soweit ich weiß) nicht so.

Aber ok, ich geb's jetzt definitiv auf, das verstehen zu wollen, irgendwie entbehrt das alles jeglicher Logik.

Aber wenn es in der Praxis so taugt, ist es ja gut.

Zitat von angryking

Gut, er ist nicht mehr größer, sondern einfach exakt gleich groß. Nimm doch mal den Taschenrechner zur Hand und mach die Rechnung: Der Emulierte C64 läuft mit dem Patch genau mit 50Hz, aber sowas von exakt. Da kann sich von keiner Seite her was nähern.

Naja dann DARF ER EBEN MAXIMAL AUCH GLEICH GROSS SEIN, NUR EBEN NICHT GRÖSSER!!!! Die ganze Zeit sprach ich immer von "DARF NICHT GRÖSSER SEIN". Das hat sich in den verschiedenen Testbuilds eben so herausgestellt, dass man maximal sogar so nah herangehen kann dass es nahezu gleichgroß ist. Warum hatte ich denn den Vorschlag damals gemacht, Kommastellen im Custom-Speed einzuführen? Dann hätte genau das nämlich jeder User individuell auf seinem System anpassen können und die Werte eben genau soweit annähern können, dass der Soundbug gerade NOCH NICHT auftritt, das Scrolling dann aber bestmöglich ist.

Zitat von angryking

Würde ja auch bedeuten, daß Leute mit 50.125Hz Monitor keine Probleme haben, ist aber (soweit ich weiß) nicht so.

Mein Monitor läuft nicht mit 50,125Hz wenn ich einen 50Hz Modus laufenlasse und die Monitore meiner Freunde, bei denen ich das getestet habe, auch nicht.

Zitat von angryking

Aber ok, ich geb's jetzt definitiv auf, das verstehen zu wollen, irgendwie entbehrt das alles jeglicher Logik.

Aber wenn es in der Praxis so taugt, ist es ja gut.

Ich sehe da sehr wohl eine Logik drin. Nämlich die, dass einfach die Regel gelten muss: "emulierter C64 darf im WinVICE nicht mit einer schnelleren Frequenz laufen als es der verwendete Vollbildmodus macht".

Was sagst du eigentlich zu meinen Mess-Ergebnissen mit dem Clock Tool? Es stellte sich dadurch heraus, dass die Speedanzeige im WinVICE Fenstermodus dann eben doch nicht mehr richtig anzeigt, wenn ein 50Hz Modus im Windows verwendet wird. Es sieht im Endeffekt dann so aus, als würde der Speed im WinVICE Fenster einfach auf 50,00Hz (also der Monitorfrequenz) runtergebremst werden, denn darauf deuten diese knapp 6 Sekunden Abweichung in der Messung ja hin. Die Speedanzeige spinnt dann anscheinend, wenn das Fenster auf 50,00Hz runtergebremst wird und nicht mehr mit 50,125Hz läuft und schwankt dann bei mir zwischen 94% und 100% hin und her.

Hast du jetzt eigentlich mal gemessen bei dir mit dem Uhren-Tool und einer echten Uhr dazu? Der Autoframe-Skip muss dazu natürlich ausgeschaltet werden und es muss Refresh-Rate 1/1 gewählt werden, sonst ist der Test sinnlos.

Und dass es naheliegend ist, dass es mit dieser Regel

Zitat von AW182

Ich sehe da sehr wohl eine Logik drin. Nämlich die, dass einfach die Regel gelten muss: "emulierter C64 darf im WinVICE nicht mit einer schnelleren Frequenz laufen als es der verwendete Vollbildmodus macht".

irgendwie zusammenhängt, darauf deutet ja auch folgender Satz in der HOXS64 Emulator Historie hin

Hier zu finden:

http://www.hoxs64.net/files/history.txt

Auch dort gab es Probleme, wenn GENAU DIESE REGEL nicht gegeben war. Es wurde dann aber in der im HOXS64 zuschaltbaren "Audio Clock Sync" Funktion gefixt und nun ist es dort im Emu egal, ob man sich an diese Regel hält oder nicht. Im WinVICE aber nicht.

Zitat von AW182

Was sagst du eigentlich zu meinen Mess-Ergebnissen mit dem Clock Tool? Es stellte sich dadurch heraus, dass die Speedanzeige im WinVICE Fenstermodus dann eben doch nicht mehr richtig anzeigt, wenn ein 50Hz Modus im Windows verwendet wird. Es sieht im Endeffekt dann so aus, als würde der Speed im WinVICE Fenster einfach auf 50,00Hz (also der Monitorfrequenz) runtergebremst werden, denn darauf deuten diese knapp 6 Sekunden Abweichung in der Messung ja hin. Die Speedanzeige spinnt dann anscheinend, wenn das Fenster auf 50,00Hz runtergebremst wird und nicht mehr mit 50,125Hz läuft und schwankt dann bei mir zwischen 94% und 100% hin und her.

Ich sage nix dazu, weil bei mir die Schwankungen sowohl nach oben als auch nach unten da sind, im Endeffekt lief bei mir die Uhr nur ca. 0.5 Sekunden zu langsam in 32 Minuten.

Scheinbar gleichen sich die Up/Downs irgendwie recht gut aus, der Emu selber ist natürlich trotzdem unbrauchbar mit solchen Schwankungen.

Zitat von AW182

Der Autoframe-Skip muss dazu natürlich ausgeschaltet werden und es muss Refresh-Rate 1/1 gewählt werden, sonst ist der Test sinnlos.

Mit solchem Zeug hantiere ich nicht herum, das war/ist und wird auch immer bei 100% / Auto sein hier.

Zitat von AW182

Auch dort gab es Probleme, wenn GENAU DIESE REGEL nicht gegeben war. Es wurde dann aber in der im HOXS64 zuschaltbaren "Audio Clock Sync" Funktion gefixt und nun ist es dort im Emu egal, ob man sich an diese Regel hält oder nicht. Im WinVICE aber nicht.

Dazu kann ich nichts sagen, aber der Code von HOXS ist nicht wirklich derselbe wie der von VICE...

https://github.com/davidhorroc…cc85601908923532aeeca7045

Soll sich jemand dazu äussern der was versteht.

Zitat von angryking

Ich sage nix dazu, weil bei mir die Schwankungen sowohl nach oben als auch nach unten da sind, im Endeffekt lief bei mir die Uhr nur ca. 0.5 Sekunden zu langsam in 32 Minuten.

Scheinbar gleichen sich die Up/Downs irgendwie recht gut aus, der Emu selber ist natürlich trotzdem unbrauchbar mit solchen Schwankungen.

Diese Aussage dass bei dir die Abweichung nur 0,5 Sekunden war, reicht ja auch schon, um zu bestätigen, dass man sich auf die Speedanzeige im WinVICE Fenster nicht mehr verlassen kann, wenn man einen 50Hz Vollbildmodus verwendet.

Zitat von angryking

Mit solchem Zeug hantiere ich nicht herum, das war/ist und wird auch immer bei 100% / Auto sein hier.

Dann sind aber die ganzen Messungen mit einer externen Uhr nutzlos, weil der automatische Frameskip es ja dann immer ausgleicht, wenn der Speed abweichen würde, weil dann eben in solch einem Fall einfach Frames ausgelassen werden, nur um den 100% Speed halten zu können.

Zitat von angryking

Dazu kann ich nichts sagen, aber der Code von HOXS ist nicht wirklich derselbe wie der von VICE...

Das hat auch keiner behauptet, dass der Code derselbe wäre. Aber dass im HOXS Emulator genau solch ein ähnliches Soundproblem EBENFALLS auftrat, nachdem der Hz-Wert des emulierten C64 dem des verwendeten Vollbildmodus übertraf, kann einfach kein Zufall sein.

I almost never had a sound problem with 3.3 or 3.4 on Windows, though with certain monitor/TV frequencies it helped to use the 'wmm' driver rather than the 'dx' driver, the dx driver blocks when a buffer is full, wmm won't. When I drag the x64sc Window to my 50Hz TV, it runs very smooth, though obviously with a little tearing, on Linux. Windows doesn't seem to understand the moving of the Window from the 60Hz monitor, using nvidia, to the 50Hz TV, using Intel.

As for comparing VICE code to other emulators: most of them are written for Windows and emulate the C64 and perhaps the C128. VICE works on a crapload of OS's and doesn't just emulate the C64 but quite a few other Commodore machines.

As a result our sync code has to deal with a lot of systems, not just Windows. Of course there is the option of writing arch-dependent sync code, but in the four years I've been a VICE dev, we didn't have a single Windows dev. At least we got the nightlies back up, but we're still looking for Windows devs.

Funny how our largest user-base doesn't produce a single dev.

Zitat von compyx

I almost never had a sound problem with 3.3 or 3.4 on Windows, though with certain monitor/TV frequencies it helped to use the 'wmm' driver rather than the 'dx' driver, the dx driver blocks when a buffer is full, wmm won't.

With GTK3 VICE V3.3, i also don't have this 50Hz soundbug, for example when i use DX sounddriver. But the bad thing is, that the whole screen don't scrolls smooth and i can not do anything, to prevent this. Missing frames or i dont know what exactly is the problem of this GTK3 port.

In the SDL2 VICE V3.3, when i use wmm sounddriver, i have exactly the same soundbug under 50Hz like in the WinVICE versions, which means, every 30 seconds interferenz-noise or whatever, which stays around 10 seconds, then goes away and then after the next 30 seconds comes again. When i switch to the SDL sounddriver in the SDL2 version, these noise is gone, but then instead of this noise, i have a short soundbreak (half a second or so) around every 30 seconds. Then it's silent for a very short moment, before sound comes again. Better then 10 seconds noise, but also hearable and striking. It's like, that in this short silence the soundbuffer is emptied or something similar. Overall performance of SDL2 version is good on my PC, runs as smooth as WinVICE.

Zitat von compyx

As a result our sync code has to deal with a lot of systems, not just Windows.

I can understand, that it is not easy to deal with, when it should run perfect on all different operating systems. Windows is the one, by far the most people uses, therefore it would be great, when it would run good on especially this system.

Zitat von compyx

Of course there is the option of writing arch-dependent sync code, but in the four years I've been a VICE dev, we didn't have a single Windows dev. At least we got the nightlies back up, but we're still looking for Windows devs.

When "Lipti's" WinVICE version improves the problem with the soundbuffer when using 50Hz screenmodes, then it's good that such a version exists, i would say. And when maybe in this version, in the future also other newer things could be integrated, also. I dont say, that going on with the older WinVICE build and GUI solves all problems these versions had, but this version gives better performance (much smoother scrolling) on most Windows-machines than the GTK3 port does, therefore it makes sense that they still exist and maybe get some updates. And this is what i hope, when i heard that "Lipti" is working on an updated version.

Gut, habe nochmals ein wenig getestet.

Einstellungen: Fenstermodus, Standard-PAL, ohne DX primary..., Wiederholrate 1/1, Monitor auf 50.125Hz

Clock Tool: Nach 47 Minuten sehr geringfügige Abweichung, maximal 0.2 Sekunden würde ich mal sagen. Speedanzeige definitiv falsch, da meist nur zwischen 90% und 98% angezeigt wird.

FRAPS Messung (lief allerdings nur kurz mit, am Ende):

Gianna Scroller: Ohne Soundprobleme, Speedanzeige aber natürlich ebenso falsch.

FRAPS Messung:

Tuneful Eight Demo: Ohne Soundprobleme, Speedanzeige aber natürlich ebenso falsch.

FRAPS Messung:

Dann habe ich noch die Clock 20 Minuten laufen lassen mit denselben Einstellungen aber mit PAL-N: Ging schon nach 20 Minuten 8 Sekunden falsch, PAL-N hat (laut VICE Source) 50.465483234714003944773175542406 Hz

Danach dasselbe aber mit "DX primary..." aktiv, dann lief die Uhr synchron 20 Minuten lang mit PAL-N

Also möglicherweise läuft WinVICE gut wenn Emu und Monitor exakt dieselbe Anzahl Hz haben, bei mir eben beide 50.125

Und mit dem Lipti Patch läuft WinVICE nur mit 50.000 Hz, und zusammen mit einem 50.000 Hz Monitor scheint das dann ja auch gut zu klappen.

Spedanzeige kann man in beiden Fällen Knicken.

Mit dem Lipti Patch hat man das Problem, dass der vermutlich nur mit Standard-PAL funktioniert. Für andere VIC-II Modelle müsste man jeweils andere Werte verwenden. Und dann läuft wohl z.B. ein PAL-N dann doch einiges neben der Uhr.

Auch andere Emus haben natürlich andere Werte, Plus4 PAL z.B. läuft mit 49.860745614035087719298245614035 Hz

Interessante Ergebnisse, auf jedenfall.

Wie vermutet, bekommt diese Speedanzeige Probleme, wenn sich die Syncs sehr annähern und sie spinnt dann herum mit großen Schwankungen. Viel größer als letztendlich dann die eigentlichen Speed-Abweichungen sind. Aber man sieht auch, dass bereits die kleinsten Speed-Schwankungen ausreichen, dass der Emu dann nicht mehr ganz astrein läuft, wenn diese Anzeige spinnt, zumindest im Fenstermodus hat das bei mir dann Auswirkungen.

Zitat von angryking

Also möglicherweise läuft WinVICE gut wenn Emu und Monitor exakt dieselbe Anzahl Hz haben, bei mir eben beide 50.125

Und mit dem Lipti Patch läuft WinVICE nur mit 50.000 Hz, und zusammen mit einem 50.000 Hz Monitor scheint das dann ja auch gut zu klappen.

Speedanzeige kann man in beiden Fällen Knicken.

So scheint es sich zu verhalten. Am besten wäre demnach eine Umschaltfunktion, damit der User sich entscheiden kann zwischen 100% (50,125Hz) und 99,75% Speed (50,0Hz), denn dann liefe diese Version auf den allermeisten User-PC's bestmöglich.

Ganz klar ist mir nur eine Sache noch nicht bislang. Warum scrollt der Emu perfekt bei mir im 50Hz Vollbild, selbst wenn der WinVICE mit 50,125Hz läuft. Denn das tut er, nur kommt dann eben der Soundbug alle 30 Sekunden. Und er wird ja auch nicht auf 50,000Hz heruntergebremst, denn das habe ich ja nachgemessen mit dem Clock Tool und es war sekundengleich nach 30 Minuten. Im Fenstermodus des WinVICE muss also irgendwie anders gesynct werden als im Vollbild des Emulators, oder? Ich kann da aber nichts umstellen in den Grafikkartentreibern.

Interessant ist es auch im HOXS64, in dem man ja umstellen kann zwischen "50Hz und 50,12Hz". Auch dort habe ich schonmal gemessen mit dem Tool und der HOXS läuft dann auch immer genau so schnell, wie im Emu eingestellt ist. Also Abweichung von der Uhr um circa 4 Sekunden bei 50Hz bei 30 mitgestoppten Minuten und keinerlei Abweichung bei 50,12Hz. Aber auch dort, sehe ich, was das Scrolling betrifft, so gut wie keinerlei Unterschiede, ob ich den HOXS nun in 50Hz oder 50,12Hz im Vollbild laufenlasse. Wie kann das eigentlich sein? Oder nimmt der BenQ Monitor diese 0,125Hz Abweichung dann vielleicht einfach nicht mehr wahr, weil zu klein? Bei 0,38Hz Abweichung gibt es noch einen kleinen Ruckler circa alle 5 Sekunden.

Zitat von AW182

When i switch to the SDL sounddriver in the SDL2 version, these noise is gone, but then instead of this noise, i have a short soundbreak (half a second or so) around every 30 seconds. Then it's silent for a very short moment, before sound comes again.

Kannst du das mal mit einem zweiten PC oder einem Handy aufnehmen und als MP3 irgendwo hochladen, am besten eine mehrere Minuten lange Sequenz wo die Störung mehrfach vorkommt? Mich würde mal das genaue Timing von Soundlänge zu Aussetzerlänge interessieren. Eine Aufnahme am gleichen Rechner könnte das Ergebnis verfälschen.

Zitat von Unseen

Kannst du das mal mit einem zweiten PC oder einem Handy aufnehmen und als MP3 irgendwo hochladen, am besten eine mehrere Minuten lange Sequenz wo die Störung mehrfach vorkommt? Mich würde mal das genaue Timing von Soundlänge zu Aussetzerlänge interessieren. Eine Aufnahme am gleichen Rechner könnte das Ergebnis verfälschen.

Ich überlege gerade, wie ich das aufnehme? Handy habe ich, so blöd es klingt, momentan keines hier. Mal sehen, was mir einfällt?

Vorab kann ich aber schonmal sagen, dass diese Aussetzer ganz kurz sind, also unter einer Sekunde. Sie sind aber wahrnehmbar, also man merkt, dass ganz kurz einmal der Sound weg ist und (vielleicht?) in dieser Zeit der Puffer entleert wird.

Bin gerade dabei, unter dem Schreibtisch ein Audiokabel vom neuen zum alten PC durchzuziehen, dann kann ich den Ton vom neuen PC am alten Rechner samplen im "Sound Forge" Programm. Voll die Aktion, der alte Rechner steht ganz hinten unterm Tisch und ihr wisst nicht, wie schlecht man da hinten dran kommt. Danach wird es wieder ein Riesenzirkus das aus der Stereoanlage rausgezogene Audiokabel dort wieder reinzubringen, denn da kommt man genauso schlecht hin, weil die in einem Schrank steht. Hoffentlich lohnt sich der Aufwand und man kann dann wenigstens was anfangen mit den Daten. Aber in ein paar Minuten sollte ich eine Aufnahme haben.

So, hier im Anhang nun also der aufgenommene "Giana Sisters" Sound aus dem SDL2-VICE unter Verwendung des SDL-Soundtreibers. Gesamplet am zweiten PC mit "Sound Forge" und dann umgewandelt in ein MP3. Weil das Forum nur Files bis maximal 4MB zulässt, musste ich eine geringere Bitrate nehmen (192), aber sollte ausreichen. Erst hatte ich zwei Files mit höherer Bitrate bei einem Filehoster hochgeladen, aber deren Links konnte ich hier dann nicht posten, weil immer die Meldung "unerwünscht" der Forensoftware kam. Deshalb hab ich dann die Files verkleinert, um sie direkt posten zu können.

Das angesprochene Problem mit der ganz kurzen Pause ist im SDL2 File zu hören bei:

- Min. 0:50

- Min. 1:20

- Min. 1:51

- Min. 2:20

Wie man sieht, tritt es fast immer genau in Abständen von 30 Sekunden auf (bei der hier gewählten Soundbuffergröße), nur ganz am Anfang dauerte es mit 50 Sekunden etwas länger, bis es das erste Mal kam.

Und da ich schonmal dabei war und dieses Kabel durchgezogen habe hinter Schrank und Schreibtisch, samplete ich dann auch gleich noch das Soundkratzen im WinVICE, wie es sich bei mir hier am PC anhört, wenn ich den Emulator mit 100% Speed (also 50,125Hz) laufenlasse und dazu einen 50Hz Vollbildmodus verwende. Das ist das zweite File hier im Anhang.

Das Soundkratzen tritt dort, wie man klar heraushört, an folgenden Stellen am deutlichsten auf:

- von Min. 0:25 bis 0:35

- von Min. 1:02 bis 1:12

- von Min. 1:20 bis 1:28

- von Min. 1:36 bis 1:41

- von Min. 2:12 bis 2:22

Hier lässt sich keine ganz eindeutige Struktur der Abstände, wann das Kratzen immer auftritt, definieren. Manchmal nach circa 30 Sekunden, aber manchmal auch schon früher. Auch die Länge wie lange die Probleme anhalten sind nicht immer genau gleich scheinbar. Meistens dauerte es um die 10 Sekunden bis das Problem wieder weg war, aber etwa bei Minute 1:36 bis 1:41 war es dann etwas kürzer.

Als Soundbuffer Größe war bei beiden Emulatoren jeweils "100 msec" eingestellt. Was nicht unwichtig ist, da man mit der Buffer-Size die Abstände, wann die Probleme auftreten, vergrößern oder verkleinern kann. Ganz weg bringe ich sie damit aber nicht.