Beiträge von Goodwell

    hänge aber immer noch an Gopher fest, unter anderem weil man vom C64 aus mit einem der verfügbaren Gopher Clients auf Gopher Sites zugreifen kann. Hast du vor einen Gemini Client für den C64 zu bauen?

    Gibts außer geoGopher noch andere Gopher clients am c64?


    Ja ich will was für den c128 am 80 Zeichen Bildschirm machen. Hab noch nicht recherchiert obs schon was gibt, aber selbst wenn: die Kombi aus Wic64 und VDC Chip (evtl mit proportionaler Schrift im Bitmap Modus) ist sicher neu :-)

    Hat mir für den Videotext Viewer mächtig Spaß gemacht

    Aber wenn Gemini (noch?) nicht geht, fang ich einfach mit Gopher an.

    Hallo

    Ich versuche mich gerade am Gemini Protokoll. Das ist der geistige Nachfolger von Gopher.
    Dafür mache ich eine TCP Verbindung auf. Die Daten müssten nun aber TLS verschlüsselt an den Server geschickt werden.

    Das WiC64 kann das ja für HTTPS, richtig? Oder verwechsle ich da was?

    Falls es das gleiche ist, kann ich dem WiC64 sagen, dass blanker TCP Payload TLS verschlüsselt werden soll?

    Danke!

    Ich habe noch nicht die komplette Übersicht über den Speicher, aber ab $9B00 liegt was anderes.

    Genau das wollte ich wissen, danke.

    Goodwell falls du etwas hast, lass es mich bitte wissen.

    Ich hab bislang nur mal das Sonderprogramm (V2) disassembliert, und bin noch dabei, es verstehen zu lernen.

    Hast du das vollständig geschrieben, oder hast du ein existierendes Sonderprogramm angepasst? (sorry, falls das schon wo erwähnt wurde hier)

    Du kannst meinem Verständnis bestimmt auf die Sprünge helfen:
    Meiner Meinung nach sind $91F4 und $9202 die Schlüsselstellen, ist das richtig?

    Bitte melde dich an, um diesen Anhang zu sehen.

    Ich hab's gestern Abend ein einziges Mal geschafft, im Debug-Mode hier einen Breakpoint anzuspringen.

    Danach hat der Tesa-SX den Bildschirm, wo normalerweise nach "Normaldruck" oder "Konturdruck" (oder so ähnlich) immer sofort übersprungen.

    Aber wäre das an $9202 die Stelle, wo die Facit-Daten durchlaufen müssten?


    Danke!

    Am Besten, du lädst dir mal das Mega65 Book runter (Bitte melde dich an, um diesen Link zu sehen.). Das The MEGA65 Complete Compendium, bzw auch die anderen. Es gibt da zwar Überschneidungen, aber trotzdem hat jedes PDF Inhalte, die die anderen nicht haben.

    Darin ist immer wieder mal beschrieben, wo besonders auf Kompatibilität zum C65 geachtet wurde, und wo nicht.

    Die VIC-III Implementierung im Mega65 unterscheidet sich zB darin vom echten VIC-III, als dass es halt kein VIC-III ist, sondern ein VIC-IV, der einen VIC-III Kompatibilitätsmodus hat. Speziell wenns in Richtung Rasterlines geht, gibts glaub ich unterschiede.

    Es ist schon einige Monate her, dass ich mich genauer damit beschäftigt habe. Ich hatte allerdings nie den Eindruck, dass der Mega65 ein fertig verwendbarer C65 im letzten Prototypen Stadium ist. Ob der C65 hardwareseitig fertig war, weiß ich nicht. Auch wenn, dann muss man noch schaun, wie weit der Mega65 das auch nachbildet.

    Der Mega65 ist kein fertiggestellter C65, dessen muss man sich schon bewusst sein.
    Wie ich schon eingangs schrieb, der C65 wäre kein guter Computer geworden.
    Trotzdem: wenn du etwas Pioniergeist verspürst, lass dich ruhig auf den Mega65 ein.

    Ganz grob: es gibt für einige Chips die Möglichkeit, in den "alten" Betriebsmodus des C65 umzuschalten. Der VIC-III verwendet Register dann anders. Und auch der DMA Chip kann dann mit kompatibleren Befehlen gefüttert werden.

    Praktisch sehe ich die Einschränkung darin, dass es keinen definierten "Zustand" gibt, wie sich ein C65 zu verhalten hat, weil alle Prototypen in unterschiedlichen Stadien waren.

    Außerdem ist auch die VIC-III Funktionalität nicht zu 100% abgedeckt (falls sie das beim C65 selber überhaupt schon war), dh auch hier wirst du entweder auf fehlende Doku oder sogar fehlende Funktionalität stoßen.

    Meine Einschätzung ist, dass du isoliert einzelne Problemstellungen umsetzen können wirst. Für ganze Programme wirds aber wahrscheinlich eng.


    EDIT: ich ergänze noch meine persönliche Meinung dazu :-)

    Es war gut, dass der c65 nicht erschienen ist. Die 3,5 MHz klingen gut, waren aber in Verbindung mit dem VIC-III tatsächlich zu lahm, wenn mans im zeitlichen Kontext betrachtet.
    Obs wirklich die 40 MHz vom Mega65 sein mussten, bleibt dahingestellt.
    Wenn du aber generell Interesse und Freude dran hast, am Mega65 was zu machen, kannst du dich auch am Mega65 auf 3,5 MHz beschränken und mit der dokumentierten Funktionalität arbeiten.

    Da noch einiges im Fluss ist, wird das ungefähr so spannend sein, wie mit dem unfertigen c65 zu arbeiten. Aber mit dem Vorteil, dass es hier eine veröffentlichte Platform ist, die auch eine handvoll andere Leute haben.

    Ich hab die letzten Tage wieder mal an einem kleinen Nebenher-Projekt gearbeitet.

    Inspiriert von hier: Bitte melde dich an, um diesen Link zu sehen.

    SeedBlaster 64 ist ein Programm, dass gültige Bip39 Seeds mit 12 Wörtern generieren kann.
    Sowas wie SeedSigner.

    Man kann die Wörter auch manuell eingeben (zB weil man sie wo anders generiert hat, mit absolut sicherem Zufallszahlengenerator oder so) und hier nochmal validieren.
    Darüberhinaus - und das ist vielleicht das Wichtigste - kann man die Seed Words auf Diskette speichern und wieder davon laden.

    Hier zB ein gültiger Schlüssel. Allerdings übermalt, ich will hier ja keine gültigen Schlüssel teilen.
    Am Ende hat den echt wer und die denken dann ich will denen was Böses.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Wenn man die Wörter händisch eingibt, dann gibt es Auto-Complete.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Und wenn die Wörter nicht der Bip-39 Spezifikation entsprechen, gibts auch keinen QR-Code.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Das Programm ist komplett in Assembly geschrieben. AutoComplete Routine und QR-Generator sind von mir selber.
    Ich werd das auch Open Source machen.

    Der SHA-256 Algorithmus wurde hier gefunden: Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Das Programm funktioniert grundsätzlich. Ich würde aber meine Millionen, wenn ich welche hätte, (noch?) nicht damit absichern.
    Dafür ist es noch zu wenig getestet.

    Was noch fehlt, ist außerdem die Möglichkeit, QR-Code und Wörter auch auszudrucken.
    Außerdem will ich noch einen ordentlichen Zufallszahlengenerator einbauen, der zB auch die aktuelle Uhrzeit und Datum von irgendwo holen kann.
    Im Emu merkt man schon, dass da immer wieder sehr ähnliche Zufallszahlen kommen.

    Wer es testen will und wo anders manuelle, gültige Seed-Words generieren will, und sie hiermit validieren will, kann zB Bitte melde dich an, um diesen Link zu sehen.? verwenden.
    Man muss 12 Wörter im Drop Down auswählen.

    Disk-Image mit Preview Version im Anhang.

    Wer mag, gern damit rumexperimentieren und gern Feedback geben.

    In erster Linie seh ich das als Spielerei, weil ich begeistert bin, was der C64 können kann :-)

    Wir nehmen die Bytes, welche gesendet werden, und schreiben diese in einen Buffer, bist die Steuerzeichen für ein CR kommen.
    Nun sollten wir alle Bytes für eine Zeile haben. Diese Zeile muss nun in das Epson-Format gewandelt, und an den Drucker gesendet werden.
    Das wird solange gemacht, bis das Dateiende erreicht ist.
    Das sollte doch funktionieren, oder?

    Das würde ich auch meinen.

    Damit ich deinen Ansatz richtig verstehen:
    Das Sonderprogramm biegt die Vektoren vom Tesa-Druckertreiber so um, dass die Daten im Sonderprogramm landen.
    Bisher hast du nur das Userport-Handling von -FLAG auf PA2 geändert, damit die VICE Emulation was am emulierten Userport ausgibt.

    Das wird jetzt so erweitert, dass die Facit Kommandos um-interpretiert werden und daraus Epson ESC/P Steuersequenzen gemacht werden, so wie von Natas beschrieben.

    Ist das soweit richtig?


    Der kommentierte Hex-Dump zeigt ja, dass jede Zeile mit CR und LF abgeschlossen wird. Und zwar für block0 zb nach genau 440 Bytes, was der Breite von 440 Pixeln entspricht.

    Und auch das Ende der Datei wird mit dem Steuerzeichen 0x16 0x1B eindeutig gekennzeichnet. Man muss sich also nicht einfach auf das Abreissen des Datenstroms verlassen.

    Kommt vom Tesa ein 0x16 0x16, so kann man das wohl einfach ignorieren. Hab das auch gerade im Dump nachgezählt. Wenn 18 mal 0x16 0x16 kommt, dann ist die Zeile statt 440 Bytes 458 Bytes lang.

    Ich hab nun auch die KI bemüht. Und zwar hab ich das Dump-File von ClausS und das Bild, das mit Hilfe des Python Scripts von thierer erstellt wurde, hochgeladen.
    Meine Anweisung an die KI war, den Dump zu analysieren und festzustellen, ob sich daraus das PNG ableiten lässt.

    Kurz zusammengefasst:

    Die Grafikdateien sind vertikal abgebildete Pixel pro Byte. Genau so kriegt zB auch mein Commodore MPS-1250 seine Grafikdaten.
    Dieser Teil des Codes sollte also für andere 9-Nadler problemlos übernommen werden können.
    Alleine die Steuerzeichen sind unterschiedlich, aber das scheint auch keine Hexerei zu sein.
    Der Drucker wird ausschließlich im Grafikmodus angesteuert, das erleichtert die Sache eigentlich.


    Hier die KI-Antwort

    Zitat

    Ich habe die Binärdatei analysiert (physischer Pfad: /mnt/data/print_dump.bin) und daraus drei Grafikblöcke extrahiert. Die Rekonstruktion der Blöcke als Bitmaps bestätigt visuell das von dir gezeigte PNG.

    1) Wichtige Byte-Patterns (genau)

    • Preamble (Beginn eines Grafikblocks)
      0x1B 0x2E 0x4D 0x1B 0x2E 0x38 0x16
      (in Bytes: ESC . M ESC . 8 0x16) — das leitet den FACIT-Grafikmodus ein.
    • Grafikdaten-Interpretation
      • Jedes folgende Daten-Byte repräsentiert eine 8-Pixel-hohe Spalte (bit 0 = oberstes Pixel der 8er-Spalte).
      • Die Daten sind spaltenweise (column-major) angeordnet: man erhält n Spalten für die Breite, dann Steuercodes ändern x/y.
    • Control/Steuerbytes (0x16 = Escape für controls / Byte-Stuffing)
      • 0x16 0x16 → tatsächliches Literal 0x16 im Datenstrom (Byte-Stuffing).
      • 0x16 0x0DCR: setzt x = 0 (horizontale Position zurück).
      • 0x16 0x0ALF: y += 8 (nächster 8-Pixel Block nach unten).
      • 0x16 0x1B → Ende des Grafikblocks (close / page end).
    • Weitere Hinweise
      • Nach dem 0x16 0x1B folgt ggf. ein neuer Block mit derselben Preamble.
      • Die Preamble bytes ESC . M / ESC . 8 sind Teil der Mode-Einstellung (8-dot Mode / Matrix Mode).

    2) Ergebnisse aus dem Dump (Zahlen / Statistik)

    Ich fand 3 Grafikblöcke in der Datei (jeweils durch die Preamble markiert):

    • Block 0
      • Anzahl Daten-Spalten (Bytes): 15 400
      • berechnete Breite (xmax): 440 Spalten
      • Höhe (max y + 8): 280 Pixel
    • Block 1
      • Spalten: 4 760
      • Breite: 280 Spalten
      • Höhe: 136 Pixel
    • Block 2
      • Spalten: 4 760
      • Breite: 280 Spalten
      • Höhe: 136 Pixel

    Kontrollzählungen (in allen Blöcken zusammen):

    • 0x16 0x0D (CR) = 72 Vorkommen
    • 0x16 0x0A (LF) = 72 Vorkommen
    • 0x16 0x16 (Byte-Stuffing) = 18 Vorkommen
    • 0x16 0x1B (Ende) = 3 Vorkommen (je 1 pro Block)

    (Die Kombi von CR/LF Count deutet auf 72 Rasterzeilenblöcke in gewissen Bereichen.)

    Ich habe aus jedem Block ein PNG gerendert — die Bilder stimmen visuell mit deinem angehängten PNG überein (format: 1-Bit monochrome).


    3) Semantik / Interpretation — was das bedeutet für Treiberbau

    • Spaltenprinzip: Der FACIT sendet Raster als Folge von 8-pixel-Spalten. Ein Treiber muss diese Spalten in der X-Reihenfolge verarbeiten und für die Zielplattform in das entsprechende Rasterformat konvertieren.
    • Byte-Stuffing: Jeder 0x16 im Originaldatenstrom ist speziell behandelt — entferne das Stuffing (0x16 0x160x16) beim Parsen.
    • CR/LF im 0x16-Kontext: Diese steuern X/Y. CR setzt die horizontale Position (neue Zeile/Spaltenfolge), LF rückt um eine Rasterhöhe (8 Pixel) nach unten.
    • Grafikende: 0x16 0x1B beendet den Block / Seite — dein Treiber sollte dann Seite abschließen / flushen.

    Daraufhin hab ich noch um eine Kommentierte Version des Hex-Dumps gebeten. Die hänge ich an.
    Bequemlichkeitshalber hier schnell die ersten paar Zeilen daraus:

    Ich werde evtl die Tage mal versuchen, da was anderes draufzubasteln.
    Davon soll sich aber niemand aufhalten zu lassen, selber zu experimentieren (sonst hätt ich das ja hier garnicht reinstellen müssen :-D )

    EDIT: noch die generierten PNGs der KI angehängt

    Andere Frage: funktioniert das WiC64 am Tesa SX?

    Der SX hat ja generell ein Thema mit dem WiC64, da muss was modifiziert werden, wimre.
    Frage wäre nun, ob der Tesa SX da identisch ist oder ob er dem noch ein weiteres „Problem“ draufsetzt.

    Ich hab mich gestern Abend noch durch den Thread durchgearbeitet :-)

    Die Anleitung der Schwestermodelle könntest Du hier einstellen falls nochmal einer auftaucht???

    Die Handbücher für den Facit 4510 und 4512 findet man auf manualslib.

    !!! Mir ist es gelungen in TESA, ueber eine "normale parallele Schnitstelle" etwas mit VICE zu drucken !!!

    Ich versuche, das mal zusammenzufassen, die Zusammenfassung wird nämlich mit einer Frage enden :-D

    Sämtlicher Programmcode ist in den ROMs abgebildet, dafür werden alle ROMs genutzt. Selbst das Char-ROM kann Programmcode enthalten.
    Dein Druckertreiber ist ein nachladbares Sonderprogramm, welches die Druckerroutine ersetzt.

    Frage an ClausS : dein Sonderprogramm hat es ermöglicht, dass man im Vice die Raw-Druckerdaten in eine Datei schreibt, richtig?
    Das Script von thierer kann diese Raw-Datei auslesen und daraus eine PNG Datei erstellen.

    Bedeutet das, dass alle Steuersequenzen der Facit Command Language entschlüsselt sind?
    Oder wurde das ausgedruckte Beispiel so simpel gewählt, dass man mit den bekannten Sequenzen auskommt?

    Dann sollte zumindest für dieses Etikett schon ein Druckertreiber geschrieben werden können, richtig?

    Danke!

    Und die Gesamtwertung. Zwei davon auch schon im vorigen Post bei Hell Beneath, um das 10 Dateien-Anhang-Limit optimal auszunutzen.

    Ich bedanke mich nochmal bei Pat Power fürs Ausrichten der Compo

    Und so viele Urkunden wären nicht so schön Retro-mäßig möglich, ohne die angepasste Printfox Version von ClausS und dem QR-Generator in GoDot von Selbigem.

    Ich Danke euch Allen ganz herzlich.

    Bis zur nächsten Compo :-)

    Orbix.

    Ich hätt gern auch mal eine Runde eingereicht, die Zeit war diesmal aber einfach wirklich zu knapp. Schade

    Außerhalb dieser schönen Konkurrenz hier hab ichs nämlich schon ein Weilchen gespielt, und es macht Spaß.
    Übrigens gibts auch einen Artikel dazu in der ASM Ausgabe 3