Hello, Guest the thread was viewed2.6k times and contains 55 replies

last post from Retrofan at the

40 Zeichen pro Zeile-Darstellung auf Softwarebasis für den VC20?

    Ich versuche mich kurz zu fassen: :D


    Gibt es für den VC20 eine Möglichkeit, ihm Software mäßig 40 Zeichen (oder 44) abzuringen?


    Beim C64 sind ja einige solcher Lösungen bekannt, meistens "halbieren" sie die Zeichenbreite und geben die schmaleren Zeichen aus.



    Hintergrund der Frage:


    Ich würde den Geldkoffer, der mit reinen Textausgaben arbeitet, gerne auf möglichst vielen Plattformen zum Laufen bringen.


    Bei 40 Zeichen passt alles pro Seite schön rein,



    bei 80 Zeichen sowieso,



    aber die 22 beim VC20 "sprengen" die Seite.



    Und ich will jetzt nicht extra für ihn Texte kürzen oder händisch trennen, um alles auf eine Seite zu bekommen.


    Irgendeine Idee, wie ich "paar Zeichen" mehr pro Zeile hinbekomme? Hardwarelösungen scheiden aus, es soll ja im VICE laufen.

    Man kann ja mit VIC-Möglichkeiten bereits die Anzahl Zeichen pro Zeile erhöhen, das Bild wird halt entsprechend breiter. Ist nur ein bisschen mehr, aber reicht vielleicht schon? Sonst müsste man zu Zeichensatz-Spielereien wechseln.


    Da gibt's eine Post mit zahlreichen Tricksereien: https://www.sleepingelephant.c…944133456fe0365a62fbc400c

    Quote from Endurion

    Da gibt's eine[n] Post mit zahlreichen Tricksereien: [...]

    :D


    ... wobei ich dazu sagen muß, daß all diese neuen Grafikmodi auf dem Reißbrett konstruiert wurden. Es werden tatsächlich keine schrägen Sachen mit dem VIC angestellt, die CPU arbeitet allerdings kräftig als Datenschaufel, damit die Daten in der Bitmap oder im Farb-RAM rechtzeitig zur Stelle sind.


    Quote from Snoopy

    Gibt es für den VC20 eine Möglichkeit, ihm Software mäßig 40 Zeichen (oder 44) abzuringen?

    Ja, das geht, auf die gleiche Weise wie man beim C64 eine "80-Zeichen-Karte" hinbekommt: mit einem 4x8-Pixel-Font. Der Font "lebt" dann auf einer 160x192-Pixel-Bitmap und damit hast Du dann 40x24 Zeichen.


    Sowas hab' ich vor langer Zeit auch schon implementiert, und mich dabei im wesentlichen auf die Ausgabe konzentriert. Die Routine gibt immer gleich ganze Textzeilen aus und ist dabei dann sogar doppelt so schnell wie die Standard-KERNAL-Zeichenausgabe!


    MG BROWSE, a 40 column ASCII text viewer - Denial (sleepingelephant.com)


    Standardanwendung ist, wie oben verlinkt, ein scrollender Text-Displayer. Ich hab' mich beim Font auf 7-Bit-ASCII beschränkt, aus zwei Gründen: 1. 99,999% der Textdateien, so man so vorfindet, sind in ASCII kodiert, und 2. da der Font in eine Bitmap gerendert wird, brauche ich die "Grafik"-Zeichen aus PETSCII nicht, ich kann jede Art von grafischer Dekoration auch so realisieren.


    Diese Bibliothek ist auch schon von anderen Leuten verwendet worden, z.B. von Davide Bucci in einigen Text-Adventures: Silk Dust - Collector's Edition - VIC-20 (polyplay.xyz)


    Viele Grüße,


    Michael

    Quote from Endurion

    Nicht schlecht! Das zwackt aber einiges an Speicher ab, oder? Immerhin muss ja da der geänderte Zeichensatz (eigentlich zwei sogar) irgendwo abgelegt werden.

    Laut der verlinkten Seite:

    Quote from https://techtinkering.com/articles/40-columns-in-basic-on-the-commodore-vic-20/

    With an 8K RAM expansion it leaves 4466 bytes free for your Basic programs.

    Für meine Zwecke reicht es jedenfalls mehr als aus.


    Mein kleines BASIC-Programm lädt pro Seite eine Textdatei und stellt den Text dann mit Wortumbrüchen dar. Und eine Inputabfrage für die Auswahl. Das passt gefühlt "in paar Bytes" rein. :D

    Quote from Endurion

    Nicht schlecht! Das zwackt aber einiges an Speicher ab, oder? Immerhin muss ja da der geänderte Zeichensatz (eigentlich zwei sogar) irgendwo abgelegt werden.

    Der Zeichensatz ist da das geringste Problem. FAT-40 baut den kompletten Screen-Editor (halbwegs passabel) nach, d.h. es können in dem 40-Zeichen-Bildschirm die Programme auch editiert werden. Allein diese Routinen (ohne die weitere Anpassung an das Bitmap-Rendering!) schlagen mit ca. 1,5 KB zu Buche.


    Man erkauft sich diesen Komfort eines kompletten Screen-Editors mit schnarch-langsamer Performance: alles muß sich durch die 1-Zeichen-pro-Aufruf-Schnittstelle mittels CHROUT (und CHRIN) zwängen. Jedes Bitmap-Byte wird im Schnitt zweimal 'angefaßt', einmal um den linken Buchstaben zu schreiben (mit sorgfältiger Ausmaskierung der rechten Hälfte) und später dann wieder um den rechten Buchstaben zu schreiben (mit sorgfältiger Ausmaskierung der linken Hälfte). Meine Routinen schreiben immer 2 Buchstaben gleichzeitig, was diesen zuvor genannten Unsinn vermeidet.


    Ich habe auf den Nachbau des Screen-Editors auch noch aus anderem Grund verzichtet: die meiste Entwicklung findet auf dem PC statt, in einem Editor meiner Wahl. Die Möglichkeit, auf einem echten VC-20 das Programm in 40 Zeichen/Zeile editieren zu können ist für mich verzichtbar.


    ...


    Ansonsten müssen eben auch die Bitmap (4 KB, zwingend im internen RAM!) und der "Ersatz"-Textbildschirm (1000 Byte) noch irgendwo untergebracht werden, von nichts kommt nichts. Eine Speichererweiterung ist da zwingend erforderlich.

    Quote from Mike

    ... mit schnarch-langsamer Performance: alles muß sich durch die 1-Zeichen-pro-Aufruf-Schnittstelle mittels CHROUT (und CHRIN) zwängen.

    In meinem konkreten Fall kommt mir das sogar zugute: Die Texte werden buchstabenweise ausgegeben, das erzeugt im "sterilen Textumfeld" noch einen Hauch von Atmosphäre (Fernschreiber ...). :D


    Ich bin echt beeindruckt, wie viele Lösungen es für den VC20 gibt und ganz allgemein gesehen, bin immer wieder erstaunt, wieviel auch aktuell immer noch mit dem VC20 los ist. Wenn man sich - wie ich - auf C64 (und MEGA65) konzentiert, dann bekomme ich den VC20 eher sporadisch mit. Ich hatte damalstm halt keinen VC20 und deshalb wenig persönlichen Bezug dazu. Deshalb bin ich hier nicht so aktuell mit Wissenstand. Schön, dass der VC20 so immer noch was zu tun bekommt und er geschätzt wird! :thumbup:


    Danke für alle Tipps und Hinweise hier! :thnks:

    Quote from Mike

    Ich hab' mich beim Font auf 7-Bit-ASCII beschränkt, aus zwei Gründen: 1. 99,999% der Textdateien, so man so vorfindet, sind in ASCII kodiert, und 2. da der Font in eine Bitmap gerendert wird, brauche ich die "Grafik"-Zeichen aus PETSCII nicht, ich kann jede Art von grafischer Dekoration auch so realisieren.

    Hallo Michael, ich weiß nicht, ob Bedarf besteht und ob du Lust hast, den mal einzubauen aber ich habe meinen 80-Zeichen-Font für den C64 auf die von dir hier verwendete 7px-Höhe angepasst. Ich könnte mir vorstellen, dass er noch etwas besser zu lesen ist, u.a. weil er größer wirkt, da ich für die x-Höhe 1px mehr verwendet habe.


    Ich weiß auch nicht, wie ich dir den Font am Besten zukommen lassen soll – ich habe hier einfach mal ein PNG generiert: 4x7-Raster. Und noch einmal in groß/breit, damit man sich die Zeichen hier angucken kann.


    VC20-40CPL.png


    Hi, Retrofan,


    evtl. verwechselst Du jetzt den Font, den FAT-40 verwendet mit dem in meinem MG BROWSE.


    FAT-40 verwendet in der Tat nur 7 Pixel vertikal insgesamt für jeden Buchstaben, eine Pixelzeile bleibt (meistens) leer damit die Buchstaben oben und unten nicht ankleben und damit sind die Versalien 6 Pixel hoch. Der Grafikmodus hat 176 Pixel Höhe, das reicht dann gerade so für 25 Zeilen: 7 x 25 = 175.


    MG BROWSE verwendet ebenfalls 6 Pixel hohe Versalien, die aber in einem 8 Pixel Raster, mit je einer Leerpixel-Zeile oben und unten. Der Zeilenabstand ist also etwas höher, damit ist die Schrift automatisch besser lesbar. Der Grafikmodus hat hier 192 Pixel Höhe, etwas mehr also als bei FAT-40, trotzdem gehen dann nur 24 Textzeilen. Weiterhin habe ich genau darauf geachtet, daß die Leselinie bei allen Kleinbuchstaben gleich ist, hier ist mein Font:



    Gibt natürlich nur so und soviele Möglichkeiten, einen Font mit 4 Pixel Breite zu designen, das ist dann Geschmackssache. ;)


    Ich hab z.B. noch vermieden, 2x2 große Pixelblöcke drin zu haben (mit Ausnahme des "&"-Zeichens), die fallen einem nämlich sofort ins Auge. Das große O wollte ich rund haben, deshalb ist die 0 eckig und insgesamt sind alle Ziffern von einer 7-Segment-Anzeige abgeleitet, etc. pp.


    Viele Grüße,


    Michael

    Quote from Mike

    evtl. verwechselst Du jetzt den Font, den FAT-40 verwendet mit dem in meinem MG BROWSE.

    Ich hatte mich an diesem Screenshot orientiert:



    Quote from Mike

    FAT-40 verwendet in der Tat nur 7 Pixel vertikal insgesamt für jeden Buchstaben, eine Pixelzeile bleibt (meistens) leer damit die Buchstaben oben und unten nicht ankleben und damit sind die Versalien 6 Pixel hoch.

    Genau dafür hatte ich meinen Font angepasst. Das war allerdings nur bei 2 Zeichen nötig, nämlich i und j, weil die Punkte in die oberste Zeile reichten.


    Quote from Mike

    MG BROWSE verwendet ebenfalls 6 Pixel hohe Versalien, die aber in einem 8 Pixel Raster, mit je einer Leerpixel-Zeile oben und unten. Der Zeilenabstand ist also etwas höher, damit ist die Schrift automatisch besser lesbar.

    So ist auch mein ursprünglicher 80-Zeichen-Font aufgebaut, also 4x8 px, 6 px Versalhöhe – aber 5 px x-Höhe, wodurch die Kleinbuchstaben mMn etwas besser zu lesen sind. Und wie bei dir (aber im Gegensatz zum original C64/Atari-Charset) sind sie auch bei mir einheitlich hoch. Ein Grundprinzip bei mir.


    Quote from Mike

    Gibt natürlich nur so und soviele Möglichkeiten, einen Font mit 4 Pixel Breite zu designen, das ist dann Geschmackssache.

    Korrekt. Wobei man natürlich aufwändige Lesetests auf unterschiedlichen Bildschirmen (CRT, TFT) durchführen könnte – was ich mir aber auch gespart habe.


    Eine Besonderheit in meinem Font: Mir ist aufgefallen, dass viele Zeichen in den typischen 4x8-Charsets etwas "auseinanderfallen", weil man versucht, mit 3 Pixeln Rundungen zu simulieren. Die Zeichen werden dadurch etwas dünn und je nach Farbkombination lösen sie sich etwas auf, wodurch das Auge dann wiederum Schwierigkeiten bekommt, Buchstaben und Freiräume zu trennen. Außerdem wirken diese dünnen 1px-Rundungen den einheitlichen Höhen entgegen. Daher habe ich oft auf "Rundungen" verzichtet und die Zeichen lieber eckiger aber dafür gefüllter/stabiler angelegt. Das ist sozusagen der Stil, durch den sich mein Font auszeichnet. Kann man mögen oder bleiben lassen, hängt vielleicht auch ein wenig vom Ausgabegerät ab (auf meinem 1084s sieht es so besser lesbar aus).

    Der Screenshot ist von FAT-40. ;)


    Quote from Retrofan

    Mir ist aufgefallen, dass viele Zeichen in den typischen 4x8-Charsets etwas "auseinanderfallen", weil man versucht, mit 3 Pixeln Rundungen zu simulieren. Die Zeichen werden dadurch etwas dünn und je nach Farbkombination lösen sie sich etwas auf, wodurch das Auge dann wiederum Schwierigkeiten bekommt, Buchstaben und Freiräume zu trennen.

    Das ist am VC-20 nicht so arg das Problem, da die Pixel breiter sind (bei PAL exakt eine Periode des Farbträgers!). Trotzdem hält man sich besser an eine kontrastreiche Farbkombination, blau auf rot z.B. ist de-facto unlesbar. In MINIPAINT, wo ich den Font ebenfalls verwende und Teile der UI mit der Hintergrundfarbe "mitgehen", setze ich z.B. die Zeichenfarbe wahlweise auf weiß oder schwarz, je nachdem was den größten Kontrast hat:




    Noch dazu "sprengt" das Composite-Signal beim PAL VIC-20 alle Pixel in rot, grün, violett, cyan und orange (sowie deren helle Varianten) auseinander. Brauchbar sind eigentlich nur die Kombinationen weiß/gelb mit blau/schwarz.


    Snoopy, das auch als Hinweis für dein Textadventure: grün auf schwarz führt aus dem Grund auf echter Hardware zu komplettem Pixelmatsch. Das ist zwar nett um auf einem Farbgerät den Grün-auf-Schwarz-Stil zu simulieren, tatsächlich ist aber Weiß auf Schwarz das was Du verwenden möchtest. Nicht jeder User hat seinen VC-20 mit einem S-Video Mod umgebaut.

    Quote from Mike

    tatsächlich ist aber Weiß auf Schwarz das was Du verwenden möchtest.

    Ich wäre da nicht so sicher. PAL-Weiß überstrahlt einfach extrem heftig, weswegen ich auf das (wie auch schwarz, wegen black-bleed) auf dem C64 nie zur Hires-Textdarstellung (oder als Hintergrund) verwende. Das normale Grün ist allerdings auch nicht perfekt, da unnötig dunkel. Ich verwende gerne das helle Grün auf schwarz (oder bei Positiv-Darstellung – z.B. GEOS – dunkelblau auf hellgrau).


    Wie gesagt, alles bezogen auf (Farb-)CRT, also 1084s o.ä. Bei scharfer TFT-Darstellung oder im Emu ist das alles kein so großes Thema, da funktionieren selbst kritische Kombinationen noch recht gut.


    Optimal wäre es, wenn man in Programmen z.B. per F-Tasten durch Vorder- und Hintergrund-Farben durchschalten könnte oder es die Möglichkeit gäbe, Prefs zu definieren und abzuspeichern.

    So sieht das beim VC-20 auf echter Hardware ohne S-Video mod mit Grün Cyan auf Schwarz aus:



    Das wohlgemerkt auf einem Grünmonitor - auf einem Farbmonitor mit Lochmaske wird das noch schlimmer!

    Quote from Retrofan

    PAL-Weiß überstrahlt einfach extrem heftig [...]

    Das sollte sich beheben lassen, indem man die Helligkeit leicht abregelt.


    Allerdings hast Du im Grundsatz recht, daß Weiß zum Überstrahlen neigt. Aus diesem Grund verwendet mein Textdisplayer auch nicht Weiß auf Schwarz sondern standardmäßig Weiß auf Blau, damit ist der Kontrast nicht zu arg.


    (Gibt übrigens das Buch "Wie Farben wirken?" von Eva Heller, da wird dies Thema auch genau ausdiskutiert - die Paarungen Weiß auf Blau und Schwarz auf Gelb sind danach optimal für Hinweisschilder, etc., geeignet)

    Quote from Mike

    [...] mit Grün auf Schwarz [...]

    Kleine Korrektur - laut zugehörigem Thread in Denial ist das tatsächlich Cyan auf Schwarz. Grün auf Schwarz (ohne S-Video mod) zerreißt die Pixel aber genauso.


    Ein paar Posts später hatte Davide dann die Ausgabe auf mein Anraten in Weiß auf Schwarz umgeändert, mit diesem Ergebnis (wieder auf einem Grünmonitor):



    (ein Streifen auf mittlerer Höhe von "ceiling. The wall [...]" bis "[...] in delicate colours; a" ist doppelt belichtet).


    ...


    Noch dazu:

    Quote from Retrofan

    Optimal wäre es, wenn man in Programmen z.B. per F-Tasten durch Vorder- und Hintergrund-Farben durchschalten könnte oder es die Möglichkeit gäbe, Prefs zu definieren und abzuspeichern.

    Das ist ja z.B. in MINIPAINT implizit schon drin - der Pixelkünstler möchte ja nun alle möglichen Hintergrundfarben im Bild verwenden können (Durchschalten der Farbquellen geht im Programm mit Ctrl + 1..4). Da aber wie oben bereits erwähnt auch die UI davon "betroffen" ist, sah ich es schon für notwendig an, die in der UI verwendete Schriftfarbe auf optimalen Kontrast zum Hintergrund anzupassen.


    Das löst aber immer noch nicht ganz das Problem der zerrissenen Pixel, es tritt auch dann auf, wenn die Schriftfarbe weiß oder schwarz ist und die Hintergrundfarbe eine der kritischen Farben (Rot, Cyan, Purpur, Grün, Orange bzw. deren hellere Varianten) ist. Da hilft wie gesagt nur der S-Video mod.

    Quote from Mike

    Das wohlgemerkt auf einem Grünmonitor

    Auf einem Grünmonitor ist ja auch grün auf schwarz einfach nur "schlechter Kontrast". DA würde ich auch immer auf maximalen Kontrast und keine Farbe (also schwarz und weiß) gehen. Aber wer hat schon einen Grünmonitor an seinem C64 oder VC20? Und zumindest auf dem C64 ist Composite-Verbindung doch allmählich auch eher selten anzutreffen. Ich mache aber zu wenig auf dem VC20, um die Situation dort beurteilen zu können. Ich kann mich nur daran erinnern, dass die Standard-Darstellungsqualität grundsätzlich eher gruselig war/ist.


    Quote from Mike

    Allerdings hast Du im Grundsatz recht

    Ich weiß, ich habe das gelernt. Aber ich sehe, ihr kommt hier zurecht und ich will auch gar nicht weiter stören. Wer sich von meinen Sachen etwas annehmen möchte, kann es tun und wer nicht, der eben nicht. Weiterhin viel Spaß ...