letzter Beitrag von Shodan am
Das dürfte ziemlich ausgeschlossen sein, da auch beim VIC-I das Character Raster fest ist, jedes Zeichen ist 8 Pixel breit. IIRC ist es möglich, ein paar wenige Spalten mehr anzuzeigen, glaube aber nicht, dass das Standard ROM damit vernünftig umgehen kann 
Ansonsten müsste es ja eine Proportionalschrift sein.
Was dann eigentlich einen Bitmap-Modus voraussetzt, den der VIC-I im Gegensatz zum VIC-II gar nicht bietet. Vom ROM-Editor ist man mit sowas ohnehin schon meilenweit entfernt.
Aber nein, es muss nicht proportional sein, auf dem C64 gibt's ja einige 80-Spalten Darstellungen bei denen jedes Zeichen eben 4 Pixel breit ist. Da wird aber entweder mit Interlace-Geflimmer oder eben auch mit Bitmap gearbeitet, und wenn der Editor damit klarkommen soll muss er gepatcht werden.
Okay. Dann werde ich mit der Situation wohl leben müssen.
Mein erster Kontakt mit einem Computer von Commodore war damals der VC20 eines Schulkameraden.
Ich hatte die breiten Zeichen garnicht mehr in Erinnerung.
Aufgrund der recht breiten Buchstaben des VC20, leidet die Übersicht beim Anzeigen der Direktorys. Die Zeilen erhalten einen Zeilenumbruch und werden zweizeilig dargestellt.
Gibt es die Möglichkeit für einen alternativen, schmaleren Systemfont des VC20?
Oder man geht einen anderen Weg und patched den Kernal dahingehend, dass er kürzere Directory-Zeilen ausgibt. Oder man verwendet ein Directory-Programm – siehe hier.
Was dann eigentlich einen Bitmap-Modus voraussetzt, den der VIC-I im Gegensatz zum VIC-II gar nicht bietet.
Allerdings gibt es ja VC20-Programme, die Proportionalschrift darstellen. Wenn die das nicht im Bitmap-Mode machen, wie denn dann? On-the-fly Char-Manipulation?
Das Vic20 Disk Menu ist ein guter Tip. 
Damit werde ich mich mal näher beschäftigen.
Allerdings gibt es ja VC20-Programme, die Proportionalschrift darstellen. Wenn die das nicht im Bitmap-Mode machen, wie denn dann? On-the-fly Char-Manipulation?
Habe selbst nie VC20 programmiert, aber meines Wissens wird ein "Grafikmodus" hier tatsächlich realisiert, indem man ein Charset (wahlweise mit 8x8 oder 8x16 characters) als Bitmap umfunktioniert, das Screenram wird dann quasi mit fortlaufenden Pointern gefüllt.
Ich habe letztes Jahr mal ein kleines Programm geschrieben, dass den dargestellten Bildschirm vergrößert von 22x23 Zeichen auf 26x32 Zeichen bzw. 28x35 Zeichen (wenn der Monitor das mitmacht). Es wird dazu der Overscan-Bereich ausgenutzt und der Bildschirmeditor entsprechend ins RAM kopiert und gepatched für die neue Auflösung. Mehr dazu im Denial-Forum:
http://sleepingelephant.com/ip…viewtopic.php?f=2&p=92294
Das ganze ist natürlich eher eine Spielerei, bestehende Software ist natürlich erstmal nicht auf die neuen Bildschirmdimensionen angepasst.
[...] meines Wissens wird ein "Grafikmodus" hier tatsächlich realisiert, indem [...]
Du kannst die Anführungszeichen ruhig weglassen, das funktioniert auf dem VC-20 tatsächlich ganz prima.
Mit dem speziell präparierten Textbildschirm als Adreßgenerator ist das auch eine echte Bitmap, mit 1:1-Korrespondenz zwischen Pixeln auf den Schirm und Bits im Speicher, ganz egal wie das jetzt tatsächlich realisiert ist.
Und seit ein paar Jahren hab' ich auch schon 40-Zeichen(-pro-Zeile)-Display-Routinen am Start und in diversen meiner Programme in Gebrauch, ohne daß das irgendwie langsam wäre.
Oh. Mini Grafik benutzt gar nicht ein Äquivalent zu „Hi Res“, weil der VC20 diesen Modus gar nicht kennt?
D.h. dass man in deinen Programmen überhaupt Linien und Kreise am VC20 als Bitmap „sieht“, macht eine Besonderheit in Minigrafik und nicht ein gesetztes Register Bit? „GRON“ macht also mehr als ich annahm.
Will mal so sagen: auf dem VC-20 muß man ein wenig mehr Aufwand betreiben, bis eine Bitmap auf dem Bildschirm 'steht'. Wie beim C64 müssen ein paar Videochip-Register umprogrammiert werden, dazu zusätzlich muß dann noch der Textbildschirm mit einem ausgesuchten Zeichenraster präpariert werden (da hat man ein paar Freiheiten, aber dazu später mehr).
Das war's dann aber auch: der Speicherbereich von $1100 bis $1FFF wird dann vom Videochip als Bitmap dargestellt, BASIC- und Maschinenprogramme können da ganz einfach - wie es ja bei einer Bitmap so gedacht ist! - bitweise drauf zugreifen und einzelne Pixel wahlweise setzen oder löschen. In der Funktion gibt es also absolut keinen Unterschied zwischen VC-20 und C64 und jedem anderen Rechner, der in irgendeiner Art und Weise eine Bitmap auf dem Bildschirm bringt.
Die Anordnung der Zeichen kann nun noch verschieden gewählt werden, entweder horizontal fortlaufend (was eine ähnlich komplizierte Adreßfunktion ergäbe wie beim C64) oder vertikal fortlaufend. Mit letzterer Anordnung läßt sich die Adresse des Bytes, in dem ein Pixel liegt, recht easy ausrechnen mit: AD=4352+192*INT(X/8)+Y - den vorderen Teil für die X-Koordinate macht man über einen Tabellenzugriff und die Y-Koordinate übernimmt ganz locker die (),Y-Adressierungsart des 6502. 
Du kannst die Anführungszeichen ruhig weglassen, das funktioniert auf dem VC-20 tatsächlich ganz prima.
Dass es funktioniert habe ich ja nicht bezweifelt, die Anführungszeichen sind hier aber trotzdem ganz richtig: Ein Grafik- bzw Bitmapmodus ist es eben nicht. Vermutlich eine bewusste Designentscheidung da bei den normalen Bildschirmdimensionen ein 8x16 Charset ja tatsächlich reicht, um den ganzen Bildschirm zu füllen -- was beim C64 auch nicht mehr machbar wäre. Bleibt aber der Nachteil, dass man das RAM für den Textbildschirm zusätzlich braucht, bei einem echten Bitmap-Modus wäre das nicht der Fall.
Und seit ein paar Jahren hab' ich auch schon 40-Zeichen(-pro-Zeile)-Display-Routinen am Start und in diversen meiner Programme in Gebrauch, ohne daß das irgendwie langsam wäre.
Auch von "langsam" habe ich nie was geschrieben... hatte nur angemerkt, dass der normale Editor wohl kaum mit sowas klarkommen würde
Mit 4 Charsets, die sich per Rasterzeilenabfrage abwechseln hätte man theoretisch einen Bitmap Vollbildschirm am C64 im Textmodus. Aber schneller wäre das Finden und Setzen von Punkten vermutlich nicht, evt. doch wenn vertikal fortlaufend.
Man könnte aber bestimmte kleinere Bereiche eines Textbildschirms zu „Grafikbereichen“ machen und Text und Grafik bequem beieinander in derselben Rasterzeile unterbringen.
Das wären aber wirklich experimentelle Sonderfälle. Linien in Chars schreiben und $d020 und $d021 für Effekte nutzen wäre dann wieder eher was für Demos und Intros.
Aus experimenteller Sicht finde ich das sehr interessant.
[...] Ein Grafik- bzw Bitmapmodus ist es eben nicht. [...]
Och jo, wenn Du das sagst ...
Sowas am C64 muss doch bedeuten, dass man beim Zeichnen schneller ist als mit einer Hires Bitmap. D.h. Wenn man in ein Charset schreibt mit dem man den Textbildschirm gefüllt hat. [...] Mit 4 Charsets, die sich per Rasterzeilenabfrage abwechseln hätte man theoretisch einen Bitmap Vollbildschirm am C64 im Textmodus.
Ich hab' das auch praktisch schon mal gemacht.
Jetzt nicht speziell wegen einer einfacheren Adreßberechnung, sondern weil man dann den Multicolor-Text-Modus verwenden kann und so (wie auch beim VC), Bereiche in Hires und Multicolor mischen kann:
Bitmap mit Multicolour-Textmodus
P.S. ein Glück, daß der erste Teil des Beitrags schon drin war. Beim Edit (um die URL zu ergänzen) hat Cloudflare erstmal auch wieder zugeschlagen. 
Sowas am C64 muss doch bedeuten, dass man beim Zeichnen schneller ist als mit einer Hires Bitmap. D.h. Wenn man in ein Charset schreibt mit dem man den Textbildschirm gefüllt hat.
Jein. Das ist nur der Fall, wenn man die Zeichen wie Mike schrieb, senkrecht anordnet. Dadurch entsteht aber automatisch eine Begrenzung der Anzeigefläche in X-Richtung. Beispiel: Wenn die Bitmap 16 Zeichen hoch ist, ist die maximale Breite nur noch 16, da ein Zeichensatz nur 16x16 Zeichen enthalten kann. Wie Du richtig schriebst, müßte man dann mehrere Zeichensätze verwenden, was die Adreßberechnung aber wieder verkompliziert, so daß man endlich nicht viel gewonnen hat, eher im Gegenteil, denn die dann nötigen Rasterinterrupts kosten recht viel Zeit.
Trotzdem hat solch ein Modus seine Berechtigung, um - wie Mike anmerkte - HiRes und Multicolour zu mischen. Hier mal drei Beispiele für die Verwendung eines solchen Modus:
forum64.de/wcf/index.php?attachment/161595/The Empire Strikes Back (Mischung von HiRes und Multicolour)
forum64.de/wcf/index.php?attachment/161596/Gruds in Space (Verwendung von Zeichensatz für mehr Farben pro 8x8-Block)
forum64.de/wcf/index.php?attachment/161597/Masquerade (Mischung von HiRes und Multicolour)
hat Cloudflare erstmal auch wieder zugeschlagen.
Passiert mir andauernd. 
Hier mal drei Beispiele für die Verwendung eines solchen Modus:
forum64.de/wcf/index.php?attachment/161595/The Empire Strikes Back (Mischung von HiRes und Multicolour)
forum64.de/wcf/index.php?attachment/161596/Gruds in Space (Verwendung von Zeichensatz für mehr Farben pro 8x8-Block)
forum64.de/wcf/index.php?attachment/161597/Masquerade (Mischung von HiRes und Multicolour)
Die Links funktionieren nicht.
Mit 4 Charsets, die sich per Rasterzeilenabfrage abwechseln hätte man theoretisch einen Bitmap Vollbildschirm am C64 im Textmodus.
Ich hab sowas ähnliches schon mal gemacht, allerdings um eine anders geformte "Bitmap" zu erreichen -- alle zwei Zeichenreihen wird der Zeichensatz umgeschaltet, damit hat man eine 128x8 = 1024 Pixel breite Grafik, die sich dann problemlos scrollen lässt 
Die Links funktionieren nicht.
Na toll, da hat wohl Cloudflare wieder zugeschlagen. Das Komische daran: Bei mir werden die Bilder angezeigt. Also noch ein Versuch:The Empire Strikes Back (Mischung von HiRes und Multicolour)
Gruds in Space (Verwendung von Zeichensatz für mehr Farben pro 8x8-Block)
The Sentinel (Verwendung von Zeichensatz für schnelles Bitmap-Scrollen der Anzeige)
