Boar, ich bin beeindruckt! Läuft unter Windows 11 in Echtzeit ohne Abbruch!
sigrok2ega schmiert ständig ab (bei 24 MHz)
Mit welcher Samplerate läuft RetroScreen?
Boar, ich bin beeindruckt! Läuft unter Windows 11 in Echtzeit ohne Abbruch!
sigrok2ega schmiert ständig ab (bei 24 MHz)
Mit welcher Samplerate läuft RetroScreen?
Top!
24MHz.
Perfekt!
Ich weiß, das ist nicht Dein Ziel...aber wenn Du die Darstellung bei 320x200 irgendwann noch pixelgenau hinbekommst können wir sigrok2ega begraben....
Meine EGA-Karte war aber beim Test eben falsch eingestellt. Wenn ich die auf 640x350 stelle kommt bei Retroscreen immer noch kein Bild. Wohl derselbe Bug wie in der letzten Datei. sigrok2ega stellt es richtig dar.
Ich habe https://github.com/COMBudda/Re…eleases/tag/v0.0.1-alpha3 hochgeladen.
Die primäre Änderung ist dass es jetzt mit V-Sync Polaritätsänderungen automatisch umgehen kann. Die beiden Dateien modes.bin und 24MHz-350.bin laufen jetzt damit.
Sehr schön, EGA funktioniert mit Umschaltung der Auflösung!
Ich habe es gerade auch mal mit einer Hercules-Karte probiert: Tut nicht.
Du musst mal probieren, hier sollte das Bild mit 16 MHz sogar besser sein als mit 24MHz. Das ist ja genau die Frequenz von MDA/Hercules.
Ich habe auch irgendwie den Eindruck, dass die Darstellung leicht Zeitversetzt ist. Merkt man nur bei Action-Spielen. Gibt der direkt jedes Pixel aus wie es reinkommt? Oder speichert der erstmal einen Frame und stellt ihn danach dar?
Ich habe mir gerade die Datei angesehen. Meines Software hat bis jetzt den Input für MDA dort erwartet wo bei EGA Green und Green Intensity ist. In der Datei habe ich gesehen dass der Input auf den Pins liegt auf denen bei EGA Blue Intensity und Green Intensity ist.
Ich habe es in einer Debug Version mal bei mir auf diese Pins gelegt und dass passt soweit. Ist das ein "Standard" den man sinnvollerweise so beibehält ?
Zu dem Zeitversatz, der Ablauf is wie folgt
- Daten werden gelesen und in eine FiFo Queue als Puffer gesteckt.
- Daten werden aus der FiFo Queue genommen und ein Bild aufgebaut
Bisher wird dieses Bild dann mit 50Hz angezeigt, egal wie schnell die originale Bildfrequenz ist.
Um jetzt näher am Original zu sein schaue ich mir das nochmal an, es sollte an sich kein Problem sein, war aber wegen der CPU Last noch nicht im Fokus.
Ich weiß das jetzt nicht mehr auswendig. Aber der Stecker ist bei CGA/EGA und MDA/Herc genau gleich belegt. Wäre ja auch umständlich verschiedene Kabel vorhalten zu müssen.
Ob das jetzt von der Belegung her sinnvoll gewesen ist kann ich gar nicht mehr sagen. Ist ja schon ein paar Jahre her dass ich mir das überlegt hatte.
Das erklärt dann, warum es einen kleinen Versatz in der Darstellung gibt. Sigrok2EGA gibt alles ohne Zeitverzögerung aus. Probier zB mal Commander Keen aus, da merkst Du, wie die Anzeige leicht hinterher ist. Ich werde mal versuchen Deinen Code zu verstehen und versuchen, das direkte Auslesen über das Saleae SDK in sigrok2ega zu implementieren. Obwohl es eigentlich keinen Sinn macht, beides gleichzeitig weiterzuentwickeln
Wg. Pinout: Ja, wenn man https://minuszerodegrees.net/mda_cga_ega/mda_cga_ega.htm und die erste Seite diese Threads ansieht macht das so Sinn. Ich werde das so dauerhaft für MDA codieren damit man nicht mehr rumbasteln muss.
Ich werde versuchen den Code ein wenig aufzuräumen
Ich habe die MDA kompatible version + ein paar Bugfixes wieder veröffentlicht. Bei dieser Version ist auch die "harte" 50Hz refresh rate dynamisch. Schau mal ob das besser ist:
Die Sources sind im Branch hier:
Ich installiere nachher Commander Keen
Ganz kurz getestet: Funktioniert alles!
EGA geht mit 640x350 und 320x200. Hercules/MDA auch. Alles perfekt!
Wenn ich das Programm starte, passiert erstmal nichts und in dem Textfenster erscheinen nur "." in Endlosschleife, jeweils ein "." pro Zeile. Erst wenn ich das USB-Kabel einmal abziehe und wieder dranmache gehts los. Kann aber auch an meinen Treibern/Installation liegen und ist im Grunde egal.
Das mit dem Versatz ist immer noch unverändert. Und die Bildqualität bei 320x200 ist auch noch nicht schön.
Ansonsten ist Dein Programm schonmal sehr sehr brauchbar, will also nicht motzen
Vielen Dank
Ich muss jetzt dringend mal über den Code gehen, das sind noch viele Hacks drin die eigentlich nicht nötig sind. Evtl finden sich da ja auch ein paar CPU Cycles. Prinzip bedingt muss ich ein wenig mit Queues arbeiten um das Ding auf der GUI Seite responsive zu halten. Insofern ist ein hartes Durchschreiben sicher immer schneller.
Wenn die "." kommen ist der Treiber auf der Suche nach dem Logic Analyzer. Ich kann zumindest den Teil etwas benutzerfreundlicher machen
Moin, ich habe noch ein paar Verbesserungen eingepflegt, z.B. eine Glättung die primär für Textmodi gedacht ist, einstellbare Sample Rate und habe dabei auch ein oder zwei CPU Cycles gefunden
Da ich den Thread nicht mit weiteren Ankündigungen belasten möchte ist das meine letzte Zwischenstandsanzeige hier.
Wenn ihr wollt könnt Ihr ja ab und zu auf https://github.com/COMBudda/RetroScreen schauen ob es was neues gibt.
Gebt gerne Bescheid wo es noch Verbesserungsbedarf gibt!
PS:
Die aktuelle Release ist
Release Picture smoothing and selectable sample rate · COMBudda/RetroScreen
Boar ich in echt beeindruckt was Du da auf die Beine gestellt und aus der Idee gemacht hast!!! Alle, die das bisher noch nicht ausprobiert haben, sollten das _jetzt_ nachholen
Die Verzögerung ist mit der neuen Version auch fast weg.
Das einzige das mir noch fehlt ist die pixelgenaue Darstellung bei 320x200. Das sieht bei sigrok2ega noch deutlich besser aus. Siehst Du eine Möglichkeit das hinzubekommen?
Ansonsten: Wäre es aufwändig für Dich, das direkte Auslesen über das Saleae SDK in unser sigrok2ega einzubauen? Dann könnte man darauf umschalten, wenn man mal in guter Qualität spielen will. Ich habe ehrlich gesagt nicht so den richtigen Plan von C und an dem Programm im Rahmen meiner bescheidenen Möglichkeiten basierend auf der Version von root_42 nur kleinere Änderungen gemacht...
Sehr gerne kannst Du aber weiterhin Updates hier posten...
Bist Du eigentlich bei Vogons? Sonst mache ich da auch nochmal Werbung für Dich
Mir jetzt schon 2x passiert:
Informationen über das Aufrufen von JIT-Debuggen
anstelle dieses Dialogfelds finden Sie am Ende dieser Meldung.
************** Ausnahmetext **************
System.OutOfMemoryException: Out of memory.
at System.Windows.Forms.PictureBox.OnPaint(PaintEventArgs pe)
at System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer)
at System.Windows.Forms.Control.WmPaint(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(HWND hWnd, MessageId msg, WPARAM wparam, LPARAM lparam)
Hey, vielen Dank für das positive Feedback!
Ich bin (noch) nicht bei Vogons, sehe aber viele Referenzen dorthin und werde mich dort wohl anmelden.
Bezüglich Bildqualität: Ich hatte kurz versucht den Ansatz von sigrog2ega zu nutzen und die Pixelclock zu "reiten". Leider funktioniert das nicht zufriedenstellend bei mir. Ich werde weiter schauen wie ich die over- und underscan- Artefakten loswerde, habe aber noch keine Silver Bullet. Zumindest keine die die Performance nicht in den Keller schickt.
Das Saleae SDK ist in C++/C#. Prinzipiell kann man das mit C Code linken aber vermutlich ist es fast leichter den C-Code in C++ zu überführen. Leider muss ich dann noch die SDL-Grafiklibrary auf Windows kompilieren um ein Gesamtpaket zu basteln wovor is auch zeitlichen Beschränkungen gerade zurückschrecke.
Den OOM Fehler hatte ich auch schon ein paar mal aber leider ist der sehr schwer zu debuggen da dieser aus den Tiefen des NET Framework kommt. Wenn jemand eine Situation beschreiben kann in der der Fehler wiederholbar auftritt wäre das genial!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!