Hallo Besucher, der Thread wurde 1,7k mal aufgerufen und enthält 9 Antworten

letzter Beitrag von thE rZA am

Denkansatz benötigt

    Moisen.


    Also. Ich habe ja seit ein paar Tagen das $9 ESP8266 Modem. Läuft super. Ich vermisse aber einige Tools, die mit RS232 Modems laufen. Z. B. ein nativer IRC Client. Ich habe die COMMLIB2.BIN gefunden. Die macht was sie soll. Einschließlich 4800bd auch problemlos. Sie hat nun einge Einsprünge, die ich aus C64studio auch locker anspringen kann.


    So. Nun tum Thema. Ein IRC Client hat eine asynchrone Eingabe und Anzeige von Daten bzw. Texten. D. h. im oberen Teil wird ja meistens der Chattext ausgegeben. Unten kann ich den zu sendenden Text eingeben. D. h. beides muss jautark laufen. Meine Idee ist, dass ich das irgendwie mit Raster IRQ regele. D. h. das Einlesen des RS232 Puffer in einer Schleife. Das einlesen des Textes und positionieren des Cursors pro Zeichen per IRQ oder anderem Interrupt.


    Meint ihr, dass das so klappen könnte? Oder: was wäre eine andere Möglichkeit das asynchron hinzubekommen?


    Ich danke Euch für Ideen, anregungen usw. p. p.


    Angenehmen Abend noch,

    mit "autark" meinst du zwei autonom ablaufende Threads.


    Die beide Bildschirmausgaben vornehmen.


    Falls sie das per $FFD2 machen, diese Routine käme wohl durcheinander (2 Auftraggeber, nicht re-entrant / wiedereintrittsfest). Dass die eine Routine auf Hauptprogramm-Ebene FFD2 aufruft und die andere aus dem Interrupt heraus zu beliebigen nicht vorhersehbaren Zeiten dasselbe tut, scheint mir bedenklich und sehr fehleranfällig.


    Nötig wäre eine Art Jobschleife, die abwechselnd beide Fenster betreut und zwischen den Aufrufen den Kontext des Bildschirms tauscht bzw. "rettet", da beide Sub-Fenster verschiedene unabh. Cursor-Positionen haben


    Der Kernel führt bereits einen Ringpuffer für Tastatureingaben.
    Diesen, und als 2. Input den RS232-Empfangspuffer, könnte die Hauptschleife des Programms als "Input" abfragen, Byte für Byte leeren und auf die beiden Bildschirmbereiche schaufeln.


    Im IRQ müsste dann nichts eigenes laufen; nur die Zeiger/Zähler für die Puffer nachgeführt werden.


    Nachtrag: Es müsste auch geklärt werden, wo die Bytes für den Bildschirm genau herkommen. Serielle Schnittstelle mit "Fern-Echo" oder mit "Nah-Echo"?

    Jo, Raster Interrupt scheint auch mir mit Kanonen auf Spatzen geschossen bzw. löst das Problem gar nicht (da FFD2 und Konsorten nicht re-entrant). Pseudocode:

    Code
    1. while keep_running {
    2. if char in keybuffer
    3. handle_key()
    4. if char in rs232input buffer
    5. handle_incoming_byte()
    6. }

    Mehr muss die Hauptschleife eigentlich nicht machen. Die Tastatur wird vom IRQ abgefragt, RS232 wird per NMI erledigt, man muss also nur beide Eingabestreams bearbeiten. Ausgaben können innerhalb von "handle_key()" und "handle_incoming_byte()" ganz normal gemacht werden, sowohl zum Bildschirm als auch zur RS232-Schnittstelle.
    Die zwei separaten Bildschirmfenster für Chat-Ausgabe und Eingabezeile sind ein eigenes Problem, das ist aber über die Kernalfunktion zum Lesen/Setzen des Cursors einfach lösbar.

    Moinsen.


    Bis hierhin danke. Ok. Das werde ich mal begjnnen umzusetzen. Das mit dem Screensplit habe ich dann so gedacht, dass ich den Ausgabetext in $0400 und Co. mache, und den Eingabetext in drei Zeilen (120 Zeichen. IRC kann max. inklusive allem 512.) in $0C00 umbiege. Das nun in einem Rasterinterrupt. Macht das Sinn? Klar kann ich den Cursor auch wie irre hin- und herschalten. Aber: wie bekäme ich es dann hin die drei Zeilen hart zu blocken, nur für den Eingabetext? Ich komme da nur auf Screenspitting... Ohne irgendeine RI Routine komme ich nicht drauf...


    Mein Hirn rödelt...

    Problem eingrenzen:


    typischerweise wird doch der Bildschirm um 1 Zeile gescrollt.
    Falls dieser Fall (am Zeilenende eines der beiden Sub-Fenster) eintritt, einfach im Fall des oberen Sub-Fensters
    1.) ...den gesamten Bildschirm um 1 Zeile nach oben scrollen lassen - dafür gibt es IMHO eine Kernel-Routine - und danach
    2.) ... wenn die 22. Zeile die letzte des ersten Sub-Fensters ist, diese löschen (oder gleich die 4 Zeilen bis Ende ab hier)
    3.) ... und zuletzt die letzten 3 Zeilen (2. Sub-Fenster) aus einem Puffer neu aufbauen bzw. rekonstruieren.
    Den letztgenannten Puffer müsste halt das Programm verwalten. Aber 3 * 40 = 120 Zeichen sind wohl kein großer Aufwand. Der Zähler der Kopierschleife bliebe auf 8 bit beschränkt. Im Fall des zweiten Sub-Fensters verschiebt man den Zusatzpuffer um 40 Zeichen und steigt erst bei Schritt 2 in o.g. Ablauf ein.


    Sehr viel einfacher ginge es vermutlich mit dem C16 /116 /plus4, mit dem WINDOW-Befehl in BASIC 3.5 ;)

    Ja. Ganz nebenbei moin moin :). Danke für den Empfang.


    Ich bin dank Eurer Anregungen einen ganzen Schritt weiter. RS232>Buffer>Bildschirm. Nun geht es an das Parsen usw. usf.


    Frage: weiß jemand wie ich den VICE dazu bekomme per RS232 dauerhaft an einem Host conected zu sein? Momentan stellt sich der Test echt nervig heraus.
    Workflow ist: C64studio>*.prg>Wibridge>C64 mit Terminalprogramm>schreiben auf Diskette... *NERV*


    Besser wäre, wenn ich den Vice mit IRC servern verbinden könnte... Weiß jemand wie auf dem Windows????