Umwandlung Bildschirmcodes in Ascii

Es gibt 101 Antworten in diesem Thema, welches 18.086 mal aufgerufen wurde. Der letzte Beitrag (13. Oktober 2013 um 20:44) ist von sauhund.

  • An Tom Baxton:


    Ich habe noch einmal in meiner Sammlung geguckt und hier diese Formel für die Wandlung Bildschirm nach ASCII-Code gefunden, die ich entwickelt habe.

    Code
    10 :rem---bildschirm nach ascii-code
    11 :deffna(a)=(aand127)+(aand64)+2*(a+32and32)
    19 :
    20 :fori=.to255:printchr$(fna(i));:next

    Schönen Gruß

  • An Tom Baxton:
    Ich habe noch einmal in meiner Sammlung geguckt und hier diese Formel für die Wandlung Bildschirm nach ASCII-Code gefunden, die ich entwickelt habe.

    Code
    [..]
    11 :deffna(a)=(aand127)+(aand64)+2*(a+32and32)
    [..]


    Meines Erachtens eine sehr elegante Lösung, die nun den gesamten Codebereich vollständig abdeckt und korrekt wiedergibt (soweit ich das im Rahmenprogramm des folgenden Beispiels sehe kann).
    Eine kleine Ergänzung wäre noch den Reverse-Status aus dem Bildschirmcode mitzunehmen bzw. zu erhalten:

    Code
    10 RN$(0)="":RN$(1)=CHR$(18)
    11 RF$(0)="":RF$(1)=CHR$(146)
    50 PRINT "{home}{cursordown}x23";
    100 FORC=0TO255
    110 A=(CAND127)+(CAND64)+2*(C+32AND32)
    120 POKE1024+24*40,C
    130 PRINT"{cursorright}x3"RN$(1-(C<128))CHR$(A)RF$(1-(C<128)),C,A
    140 NEXT
  • Hallo, nach der Schirm-ASCII-Formel kommt hier
    die Farbcode - ASCII -Formel:


    Code
    10 :rem---farbcode nach ASCII-code
    11 :deffnf(a)=peek(59610+(aand15))
    19 :
    20 :fori=0to15:j=fnf(i):printi,j,chr$(34)chr$(j):next

    Hierbei wird die interne Farbcode-Tabelle des ROMS ausgelesen.


    Schönen Gruß.

  • Code
    10 :rem---bildschirm nach ascii-code
    11 :deffna(a)=(aand127)+(aand64)+2*(a+32and32)


    Danke, das ist eine schöne Formel - und sie gibt nicht einfach nur passende Codes zurück, sondern funktioniert auch bei den Mehrfachmöglichkeiten: Die PetSCII-Codes 96 bis 127 sowie 224 bis 254 sind z.B. über die Tastatur nicht zu erreichen, erzeugen bei Ausgabe per CHR$() aber die gleichen Zeichen wie die Codes 192 bis 223 sowie 160 bis 190. Für die Rückkonvertierung sind also zwei (im Falle von Pi sogar drei) Ergebnisse möglich, aber die Formal erzeugt immer den Wert, den auch die Tastatur liefern würde. Sauber! :thumbup:

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Hallo Leute,

    Danke für die vielen Postings zu meinem Thema. Die vielen Beispiele waren für mich eine gute Anregung, aber richtig funktioniert hatte es nirgendwo. Weil das Bild aus Textelementen, Farben und inversen Zeichen besteht, reichte eine Formel nicht richtig aus. Habe mir aber auf Basis Eurer Anregungen meine eigene Routine gestrickt, die natürlich auch entsprechend lange braucht. Das Programm habe ich auf dem C128 geschrieben und die 25 Zeilen-Strings dann in eine sequentielle Datei gespeichert. Im C128-Modus kann ich die Datei öffnen, das Feld einlesen und auf den Bildschirm printen. Auch gut... Läuft super!
    Wenn ich das Ganze auf einem C64 darstellen möchte, dann steigt dieser mit der Fehlermeldung aus, dass einige Strings zu lang sind. Mist!
    Einige Bildschirmzeilen sind inkl. Farben und Revers-Steuerzeichen dann bis zu 91 Zeichen lang. Das ist für den C64 zu viel. Beim C128 aber kein Problem.
    Da dachte ich mir, wenn ich die langen Strings in jeweils zwei kurze Strings zerlege und diese dann in eine sequentielle Datei speichere, dann müsste das doch gehen. Also, erster Stringteil auf 30 Zeichen Breite und den zweiten Stringteil auf Restlänge. Somit immer unter 88 Zeichen.
    Wenn ich diese Strings dann am C64 auslese und wieder zwei Teilstrings zusammen setze, dann hat der eine String mal die Originallänge und andere wiederum ein Zeichen zu wenig.
    Kann mir das Problem vielleicht jemand von Euch erklären... Warum lassen sich manche Strings ohne Verluste zusammen flicken und bei anderen fehlt etwas?
    Ich setzte die Strings mit z$(i)=a1$+a2$ wieder zusammen. Manchmal klappt das, dann wiederum fehlen Zeichen... Hat jemand ne Idee?

  • Jetzt noch mal die Frage: was für einen Vorteil siehst Du darin, den Bildschirm im PETSCII-Format mit Farbsteuercodes, {RVS ON} und {RVS OFF} abzuspeichern, wenn's genauso gut tut den Textschirm + Farb-RAM in einer Datei abzuspeichern und wieder einzulesen wie ich es Bitte melde dich an, um diesen Link zu sehen. schon beschrieben hab?

  • Ich schreibe gerade an einem Konvertierungstool für einen Bekannten, damit er schon fertig gespeicherte Bilder umwandeln kann, um sie schneller anzeigen zu lassen. Die Bilder sind sequentiell gespeichert und können nicht so schnell auf den Bildschirm geschrieben werden.
    Also lese ich die Bild- und Farbdaten ein und wandel die um und ordne sie zeilenweise zu Stringketten, die man dann per Print-Schleife auf den Bildschirm schreiben lassen kann. Da das Laden von 2000 Zeichen per Get-Befehl länger dauert, als 25 Strings einzulesen.
    Da der C64 aber beim Input#-Befehlt eine max. Länge von 88 Zeichen besitzt, sind einige Zeilen inkl. Farb- und Revers-Codes zu lang. Deshalb habe ich einen Bildschirmzeilenstring in zwei Teile geschnitten und diese dann gespeichert. Beim Zusammensetzen fehlt aber ab und zu ein Zeichen. Das kann ich mir nicht erklären...

  • Dir ist schon klar, daß der INPUT# Befehl für diese Anwendung Schrott ist?

    Sobald die Datei Kommata, Doppelpunkte, Anführungszeichen oder Leerzeichen am Anfang oder Ende einer Zeile aufweist, liefert INPUT# garantiert nicht das zurück, was Du haben wolltest.

  • wenn es darum geht die bilder so umzuwandeln das sie später möglichst schnell angezeigt werden können, dann gibts eigentlich garkeine alternative zum speichern von bildschirm und farbram als block. das einladen/anzeigen geht dann bequem mit load fast ohne zusätzlichen code und ein eventueller fastloader greift als bonus auch noch.

  • @Sauhund: Wem stimmst Du jetzt zu? Mir, mit meinem Programm, die Zeilen als Stringkette zusammen zufassen?

    Mike: Auf diesen Hinweis habe ich gehofft! Dass der InputBitte melde dich an, um diesen Link zu sehen. Probleme mit diversen Zeichen hat. Genau das habe ich vermutet. Deshalb werde ich im nächsten Schritt vor und nach jedem Teilstring ein "+" dranhängen, dass ich dann nach dem Zurücklesen wieder entferne. Vielleicht kann ich den InputBitte melde dich an, um diesen Link zu sehen. damit überlisten... Danke für den Hinweis. Diese Beschränkung auf 88 Zeichen hat der C128 nicht. Mal wieder das bessere Basic....

    Gruß!
    ThomBraxton :thnks:

  • Vorne und hinten (irgendein unproblematisches) Zeichen anzuhängen hilft nur bei den Leerzeichen vorn und hinten.

    Ein Komma in der Datei schließt für INPUT# die aktuelle Eingabe in eine Variable ab. Du liest zwar vermutlich bis zum Dateiende ein, trotzdem fehlt anschließend das Komma. Ähnlich läuft es mit dem Doppelpunkt - hier wird gleich der ganze Rest der Eingabe bis zum Zeilenende verworfen. Wird eine Zeile komplett mit Anführungszeichen eingeschlossen, hat man zwar keine Probleme mit Kommata und Doppelpunkten innendrin, aber die Anführungszeichen drumherum werden explizit entfernt und es hilft auch alles nichts wenn sonst noch in der Eingabe Anführungszeichen drin sind. Also, alles kompletter Murks.

    Zitat von ThomBraxton

    Diese Beschränkung auf 88 Zeichen hat der C128 nicht.


    Ja, es ist hier halt eine Beschränkung auf 160 Zeichen, damit man auch im 80-Zeichen-Bildschirm wenigstens zwei physikalische Bildschirmzeilen zu einer logischen Zeile verbinden kann.

    Ich könnte hier ja eine kleine Routine beisteuern, die mit minimalem zusätzlichen ML Support aus einer offenen Datei eine Zeichenkette bis zum nächsten Zeilenende (maximal 255 Zeichen mit 'gutmütiger' Behandlung von überlangem Input) einlesen kann und sonst nicht über irgendwelche speziellen Zeichen stolpert - wenn, ja, wenn ...

  • Zitat

    @Sauhund: Wem stimmst Du jetzt zu? Mir, mit meinem Programm, die Zeilen als Stringkette zusammen zufassen?


    nein, das halte ich ehrlichgesagt für humbug :) ich bezweifle auch das das am ende schneller sein kann als byte-für-byte aus der seq datei zu lesen, das was du durch lesen ganzer strings gewinnst das verschenkst du wieder durch das aufwendige umbauen und tricksen das es überhaupt geht. man will daher in basic wenn es geht immer und ausschliesslich komplette files per LOAD einladen, das geht ungebremst und selbst ohne fastloader dürfte der geschwindigkeitsgewinn deutlich sein. ich würe daher:

    - das bild wie auch immer auf den bildschirm bringen
    - ab $400 (bildschirmspeicher) und $d800 (farbram) jeweils 1000 bytes (den ganzen screen) jeweils in eine datei speichern. (ich würde dazu einen ml monitor bemühen, geht mit irgendwelchen poke/sys geschichten aber auch ohne, sollte sich finden lassen wie)

    das anzeigen des bildes geht dann trivial, einfach durch einladen beider files: (was auch, da das insgesamt nur 8 blöcke sind, vergleichsweise fix geht)
    10 LOAD "screen",8,1
    20 LOAD "farben",8,1
    30 poke198,0:wait198,1:poke198,0:rem auf taste warten

  • @sauhund: In der Form funktioniert das nicht so ganz, da der LOAD-Befehl ja die (hier unerwünschte) Eigenart hat, das Programm - ohne Löschen der Variablen - von vorne zu starten.

    Klassisch geht das halt besser über SYS57812, was die Parameter für die KERNAL Load/Save-Routinen aus dem BASIC-Text ausliest, und dem anschließenden Aufruf von KERNAL Load:

    Code
    1 DN=PEEK(186)
    2 SYS57812"SCREEN",DN,1:POKE780,0:SYS65493
    3 SYS57812"FARBEN",DN,1:POKE780,0:SYS65493
    4 GETA$:IFA$=""THEN4


    Das ist aber hier (und Bitte melde dich an, um diesen Link zu sehen.) alles schon mehrfach vorgeschlagen worden und die Diskussion dreht sich hier im Kreis wenn ThomBraxton diese und andere Lösungsmöglichkeiten irgendwie nicht ins Konzept zu passen scheinen. :(

  • Hallo, Tom:
    --------------
    Das Problem mit dem fehlenden letzten Zeichen kann man damit lösen, indem man das Feld numerisch mit peek liest.
    Oder man muß die Zeilenlänge in 213 um ein Zeichen verlängern mit poke213,peek(213)+1.

    Natürlich produziert die Schirm-Code zu Ascii-Code Formel keine reversen Zeichen.
    Da mußt du dann ein chr$(18) oder ein chr$(18+128) zufügen, für REV an und REV aus.

    Die Idee mit den zwei Strings für eine Zeile ist übrigens schon richtig.

    Schönen Gruß.

  • Zitat

    @sauhund: In der Form funktioniert das nicht so ganz, da der LOAD-Befehl ja die (hier unerwünschte) Eigenart hat, das Programm - ohne Löschen der Variablen - von vorne zu starten.


    ahja, verpeilt. das sind die gründe wegen denen ich nicht mehr mit basic rummache, wenn man schon bei sowas simplem wie files einladen rumtricksen muss.... bäh :)

  • @Braxton:
    Der INPUT#-Kram hat seine Tücken und GET# bringt es eigentlich nur mit Strings und dann Byte für Byte kostet unnötig viel Zeit.

    Schau Dir das hier mal an, so kann man auch in BASIC ohne LOAD/SAVE Speicherbereiche laden und speichern und zwar genau dorthin/von dort, wo man möchte:
    Bitte melde dich an, um diesen Link zu sehen. <- Disk-Operationen

    Das Ergebnis von KERNEL-Save entspricht in etwa dem hier im Maschinensprache Monitor

    Code
    S "SCR.PRG" 08 $0400 $07e7
    S "COL.PRG" 08 $d800 $dbe7


    Genau so leicht kriegt man es mit KERNEL-Load wieder ins Screen.

    Edit: Ah, sorry, gesehen, dass Mike das eigentlich gestern auch schon vorgeschlagen hat :rotwerd:

  • Hier noch einmal ein Demolisting zur Wandlung eines Bildschirminhalts in Strings:


    Code
    10 :j=0:l=40:m=25:fr=55296:br=peek(648)*256:dimd$(99)
    20 :fori=1tom:a$="":forj=jtoj+l-1:b=peek(j+br):c=fna(b):f=fnf(peek(j+fr)):
    21 :a$=a$+chr$(18-128*(b<128))chr$(f)chr$(c):ifc=34then:a$=a$+chr$(34)+"[links]"
    22 :next:d$(i)=a$:next:return:

    Falls man Halbzeilen haben möchte muß man l=20:m=50: setzen.


    Schönen Gruß.

  • Mir passen Lösungsvorschläge gut ins Konzept. Das Problem ist nur, dass die Vorschläge in meinem Fall irgendwie nicht funktionieren....
    Bei dem oberen Programm beispielsweise funzt das Programm nicht. Habe die Screen-Datei mit den PETASCII-Zeichen gefüllt und als sequentielle Datei gespeichert. Lief nicht. Dann als PRG-Datei gespeichert.... Lief nicht.
    Die Farben habe ich als Zahlenwerte gespeichert. Auch in einer PRG-Datei. Somit 2 Dateien "test1-b" und "test1-f". Das Programm will aber nicht...
    Außerdem sind die beiden Dateien wesentlich größer als die Quelldatei... Die Originaldatei hat eine Größe von 8 Blöcken und die beiden gesplitteten Dateien eine Größe von 4 bzw. 16 Blöcken....
    Wäre vielleicht hilfreich, wenn ich wüsste, in welchem Format die Zieldateien vorliegen müssten? PRG? SEQ? USR? Und wie sollen die Daten darin abgelegt sein? String? Integer? Float?
    Ich probier mir hier schon fast nen Wolf... :wink:

    Also: ein kleiner Hilfs-Schubbs wäre nett.... :thumbsup:

    Gruß!
    ThomBraxton

    [Edit:] Auch ja, und wofür ist der Peek-Befehl??? Laufwerksnummer ermitteln?