C Programmierer für kleine Aufgabe gesucht...EGA converter

    Hallo zusammen,

    Ich habe bei Vogons ein spannendes Projekt in QB64 gestartet. Es geht darum mit einem Logik-Analysator die Ausgabe einer EGA-Grafikkarte darzustellen:


    https://www.vogons.org/viewtop…0sigrok-ega%20ega#p874461


    Leider ist das alles zu langsam. Ich habe aber die Hoffnung, daß es in C ausreichend schnell für eine Darstellung in Echtzeit laufen könnte.


    Kann vielleicht jemand die verlinkten 20 Zeilen QB64 in C++ übersetzen? Ich habe leider keinen Plan wie das funktioniert...werde natürlich denjenigen dort nennen und mich nicht mit fremden Federn schmücken ;) Vielen Dank!!

    Dein Code ist ein bisserl Spaghetti mit den ganzen gotos. Wäre besser mit WHILE Schleifen gewesen. Prinzipiell ist das easy (abgesehen von der Anzeige, da hat C nix eingebaut, würde BMP Dateien raushauen und später mit SDL oder so eine Anzeige einbauen).

    Kannst du kurz umreissen wie das mit dem vsync abgeht? Mein Code ist hier:


    https://www.root42.de/public/sigrok.c


    Und der schmiert ab, weil die Y-koordinate riesig wird, d.h. der bildschirmrefresh wird scheinbar nicht richtig detektiert.


    UPDATE: habe es glaube ich repariert. Ich hatte ein paar Fehler und der goto Dschungel war nicht einfach zu verstehen. :) Jetzt muss man nur SDL einbinden, vermutlich ein 24bit surface generieren und die RGB TTL Daten in 24 bit RGB verwandeln. Aber das ist ja halbwegs einfach. Dann kann man das darstellen, oder als BMP raushauen. Mein Code detektiert auf jeden Fall 597 Frames. Der Code läuft auf meiner virtuellen Maschine, die nicht besonders gut ausgestattet ist in 3.5 Sekunden durch. Man kann das vermutlich alles noch ein wenig optimieren...

    root42 auf YouTube


    80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, GUSar Lite & TNDY & SnarkBarker, PC MIDI Card + SC55 + MT-32, XT CF Lite, OSSC 1.6

    2 Mal editiert, zuletzt von root_42 ()

    coooool 1000 Dank!!!! Ich bin grad unterwegs und werde es heute abend probieren.

    Bei 60 fps waere das ja rasend schnell...!

    Ja ist leider Spaghetti... ;) Wenn es nicht laufen sollte kann ich es aber auch nochmal mit while schleifen umstricken..

    Ok, habe jetzt bemerkt, dass es nicht RGBrgb sondern RGBI ist... d.h. 2 bits sind völlig egal zur Zeit, und daher darf man die nicht verwenden. Code wurde aktualisiert. Jetzt ist das Bild "nur" noch ein wenig unzentriert. Ich glaube deine Heuristiken für den H- und V-Sync habe ich nicht korrekt umgesetzt.

    das sieht schonmal suuupppeer aus, freue mich das zu probieren!!


    Das Restproblem ist die Zeile in meinem Code mit dem PSET. Die legt fest, welche Pixel tatsächlich gezeichnet werden. Es sind ca 1500 aufgezeichnet aber nur 320 werden benötigt. Ich glaube das ist bei dir etwas verrutscht, daher die restlichen Bildfehler.. ,

    Ja, ich werde eventuell später mal alles zeichnen und dann eine Transformation überlegen, um das herunterzuskalieren. Du machst mit dem PSET ja eine Art nearest-neighbor-interpolation. Ich vermute dass da etwas nicht stimmt. Und eventuell auch etwas mit der Heuristik für den Bildstart, da das Bild nach unten verrutscht ist?

    root42 auf YouTube


    80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, GUSar Lite & TNDY & SnarkBarker, PC MIDI Card + SC55 + MT-32, XT CF Lite, OSSC 1.6

    So, wieder zuhause. Zunächst noch einmal 1000 Dank für Deine Mühe, das sieht schonmal toll aus. Ich muss mir aber erst einmal einen C-Compiler installieren (ist GCC ok?) und habe noch ein paar andere Verpflichtungen...


    Hast Du auch so einen Analyser? Eine EGA-Karte könnte ich Dir schicken falls Du noch keine hast, dann kannst Du das auch mal in "echt" ausprobieren...


    Also es ist keine Interpolation. Es werden nur die 320 Pixel aus einer Zeile herausgepickt, die benötigt werden. Der Rest wird verworfen. Ursprünglich sah es so wie unten. Den Code habe ich mit Excel erzeugt, hat nicht soviel Arbeit gemacht wie es aussieht ;)

    Das...

    PSET ((319 / 1070) * (x - 305), y), color1

    ...ist dasselbe wie unten in kurz.



    IF X = 306 THEN PSET (0, Y), color1

    IF X = 309 THEN PSET (1, Y), color1

    IF X = 313 THEN PSET (2, Y), color1

    IF X = 316 THEN PSET (3, Y), color1

    IF X = 319 THEN PSET (4, Y), color1

    IF X = 323 THEN PSET (5, Y), color1

    IF X = 326 THEN PSET (6, Y), color1

    IF X = 329 THEN PSET (7, Y), color1

    IF X = 333 THEN PSET (8, Y), color1

    IF X = 336 THEN PSET (9, Y), color1

    IF X = 340 THEN PSET (10, Y), color1

    IF X = 343 THEN PSET (11, Y), color1

    ......

    IF X = 1332 THEN PSET (306, Y), color1

    IF X = 1335 THEN PSET (307, Y), color1

    IF X = 1338 THEN PSET (308, Y), color1

    IF X = 1342 THEN PSET (309, Y), color1

    IF X = 1345 THEN PSET (310, Y), color1

    IF X = 1349 THEN PSET (311, Y), color1

    IF X = 1352 THEN PSET (312, Y), color1

    IF X = 1355 THEN PSET (313, Y), color1

    IF X = 1359 THEN PSET (314, Y), color1

    IF X = 1362 THEN PSET (315, Y), color1

    IF X = 1365 THEN PSET (316, Y), color1

    IF X = 1369 THEN PSET (317, Y), color1

    IF X = 1372 THEN PSET (318, Y), color1

    IF X = 1375 THEN PSET (319, Y), color1

    Achso, und wegen des HSYNC und VSYNC: Die habe ich auch nicht so 100% implementiert. Der tatsächliche Bildauschnitt liegt irgendwo in der Mitte des Fensters. Deshalb habe ich das Fenster auch nicht als 320x200 definiert sondern als 1700x700. Finde ich erstmal nicht so tragisch zum probieren. Für die Screenshots bei Vogons habe ich das nochmal per Hand angepasst. Es macht auch deshalb Sinn weil der Ausschnitt bei anderen Auflösungen wieder woanders liegt.


    Für die Zukunft würde ich auch eine Erkennung der Auflösung implementieren. Das ist aber gar nicht so einfach, war froh es so hinbekommen zu haben. Bei 640x350 ist zB das VSYNC-Signal gegenüber 320x200 invertiert, das hatte ich anfangs nicht gerafft:

    http://minuszerodegrees.net/mda_cga_ega/mda_cga_ega.htm

    Und das was du da beschreibst ist genau nearest neighbor interpolation. Da können wir auch noch ordentlich dran drehen, momentan werden viel zu viele pixel gesetzt. Aber Optimierungen machen wir später...


    Ich habe derweil grafisches Fenster zugefügt, damit man sich das live anschauen kann. Es ist nicht schnell, muss man sagen, keine 60 Hz. Aber da kommen wir bestimmt noch hin...


    Ich habe ein Github Repo angelegt: https://github.com/root42/sigrok2ega


    Da ist auch keen5b.bin.gz als Testdatensatz drin, bitte nicht noch mehr einchecken, das ist bei git keine gute Idee. :)


    Ein Video habe ich hier mal angefügt. Das Scrolling sieht murks aus, kann aber auch an Keen selber liegen. Der trickst beim Scrolling ja einigermaßen herum...


    Externer Inhalt youtu.be
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    root42 auf YouTube


    80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, GUSar Lite & TNDY & SnarkBarker, PC MIDI Card + SC55 + MT-32, XT CF Lite, OSSC 1.6

    Zitat von gamma

    Achso, und wegen des HSYNC und VSYNC: Die habe ich auch nicht so 100% implementiert. Der tatsächliche Bildauschnitt liegt irgendwo in der Mitte des Fensters. Deshalb habe ich das Fenster auch nicht als 320x200 definiert sondern als 1700x700. Finde ich erstmal nicht so tragisch zum probieren. Für die Screenshots bei Vogons habe ich das nochmal per Hand angepasst. Es macht auch deshalb Sinn weil der Ausschnitt bei anderen Auflösungen wieder woanders liegt.


    Für die Zukunft würde ich auch eine Erkennung der Auflösung implementieren. Das ist aber gar nicht so einfach, war froh es so hinbekommen zu haben. Bei 640x350 ist zB das VSYNC-Signal gegenüber 320x200 invertiert, das hatte ich anfangs nicht gerafft:

    http://minuszerodegrees.net/mda_cga_ega/mda_cga_ega.htm

    Ok, dann verstehe ich warum das bei mir nach murks aussieht. Für das Erkennen des Inhalts gibt es Methoden aus der Computer Vision. In der Tat macht es da mehr Sinn, dass wir den kompletten Inhalt rendern, so wie er ist, und die Skalierung einfach von OpenGL/Metal/whatever machen lassen. Aber lass uns erstmal klein anfangen...

    root42 auf YouTube


    80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, GUSar Lite & TNDY & SnarkBarker, PC MIDI Card + SC55 + MT-32, XT CF Lite, OSSC 1.6

    Wow...mit Video...bin begeistert...! Geschwindigkeit sieht schonmal gut aus, fast wie real? Ja genau, die Scrolling-Fehler kommen von Keen selber, die kannst Du ignorieren. Das kann man in irgendeiner Einstellung ändern, sieht ohne mit einem richtigen Monitor genauso aus.


    Du arbeitest unter Linux, oder? Ich habe leider grad keine Linux-Installation...


    Ich habe versucht unter Windows zu compilieren und bekomme:


    gcc ega.c

    ega.c: In function 'SDL_main':

    ega.c:29:1: error: number of arguments doesn't match prototype

    {

    ^

    In file included from C:\Program Files (x86)\mingw-w64\i686-8.1.0-posix-dwarf-rt_v6-rev0\mingw32\lib\SDL2-2.0.12\i686-w64-mingw32\include\SDL2\SDL.h:32,

    from ega.c:4:

    C:\Program Files (x86)\mingw-w64\i686-8.1.0-posix-dwarf-rt_v6-rev0\mingw32\lib\SDL2-2.0.12\i686-w64-mingw32\include\SDL2\SDL_main.h:121:29: error: prototype declaration

    extern SDLMAIN_DECLSPEC int SDL_main(int argc, char *argv[]);

    Ich arbeite unter Linux und MacOS. Du brauchst SDL2, was du scheinbar hast, und ich empfehle dir das github Repo zu klonen. Ich kenne mich mit mingw32 nicht sonderlich gut aus, daher weiß ich nicht, wo der sein SDL2 herbekommt. Aber das sieht so aus als würde der Header nicht zu was anderem passen... Da müsste mal ein mingw32 / Windows-Experte einspringen.

    root42 auf YouTube


    80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, GUSar Lite & TNDY & SnarkBarker, PC MIDI Card + SC55 + MT-32, XT CF Lite, OSSC 1.6

    Hmm, ja das SDL2 habe ich mir nachträglich runtergeladen und in das Verzeichnis kopiert....ich werde mal schauen.


    Wenn Du den kompletten Inhalt nimmst sieht es so aus wie angehängt...ziemlich viele Störungen im Bild. Die rosa Linie rechts markiert jeweils das Ende der Bildschirmzeile bevor der HSYNC kommt.


    Die Methode mit der "Interpolation" funktioniert bisher auch erst bei 320x200. Bei 640x350 ist es schwieriger (aber nicht unmögich...) weil weniger Daten pro Zeile zur Verfügung stehen.

    Heute muss ich erstmal noch ein Video schneiden, aber in den nächsten Wochen komme ich bestimmt dazu an dem Code weiterzubasteln, wenn es nicht vorher jemand anderes tut. Ich denke das hat Potential. Einen billig 24MHz Analyzer habe ich, der müsste von SIGROK glaube ich auch unterstützt werden (ist Saleae kompatibel). Ich habe auch eine ATI EGA Wonder 800+, ungetestet. Beizeiten, wenn das ganze was flotter läuft werde ich das mal im 286er austesten.

    root42 auf YouTube


    80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, GUSar Lite & TNDY & SnarkBarker, PC MIDI Card + SC55 + MT-32, XT CF Lite, OSSC 1.6

    Ich will ja eher den umgekehrten Weg gehen und die EGA Karte wenn es geht irgendwie an meinen C1084S anschließen. ;) Geht natürlich nur für die 200 Zeilenmodi. 350 Zeilen hat zu hohe Frequenz. Echte EGA CRTs sind ja unbezahlbar...


    Aber eine extrem billige Möglichkeit für die Verwendung von EGA/CGA/Hercules und auch die Bildschirmaufnahme derselben ist schon sehr verlockend.

    root42 auf YouTube


    80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, GUSar Lite & TNDY & SnarkBarker, PC MIDI Card + SC55 + MT-32, XT CF Lite, OSSC 1.6

    Super, dann hast Du ja schon das benötigte Equipment!


    Ja, mit einer guten Software kann man dann seine MCE2VGA oder GBS8200 entsorgen. Zumal ich es auch besser finde die Ausgabe - wenn gewünscht auch nur in einem Fenster - auf seinem normalen Monitor anzusehen ohne immer den Eingang umzuschalten. Sehr gut ist auch die Möglichkeit lange Entfernungen nur mit einem USB-Verlängerungskabel zu überbrücken.


    Und für die unterstützen Auflösungen/Formate ist die Lösung auch sehr flexibel.


    Ein Problem sehe ich im Moment nur darin, dass für 640x350 die 24MHz sehr knapp sind. Ich denke das ist lösbar, ansonsten muss man zu höherwertigen Analyzern gehen. Es gibt welche mit 100 MHz für 30€ z.B....

    Hmm, habe das Compilieren nun hinbekommen.


    Als erstes habe ich noch das in der 3. Zeile hinzugefügt:

    #define SDL_MAIN_HANDLED


    Folgende Kommandos laufen dann durch:

    gcc ega-c.c -lmingw32 -lSDL2main -lSDL2 -o ega-c.o

    ld ega-c.o -o ega-c.exe



    Beim Testen...

    type keen.bin | ega-c.exe


    Schmiert das Programm dann allerdings ab :(

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden