Neues OS/GUI für den C64

Quote from DivZero

Wenn du im Texteditor scrollst musst du aber so gut wie den gesamten Bitmapspeicher ständig kopieren.

Wir brauchen hier nicht theoretisch zu diskutieren – ich hatte C64-Apps verlinkt, die Bitmaps scrollen. Ich finde, die SIND ausreichend schnell. Ob die das nun mit "Wundern und Zauberei" machen statt mit nackter Technik (die es ja angeblich nicht kann) weiß ich nicht. Mir reicht die Performance auf jeden Fall. Ganz besonders toll geht es natürlich mit der REU.

Und im Normalfall wird gar nicht (oder nur ganz wenig) gescrollt. Als Extrembeispiel wurde hier zwar ein Text-Editor genannt – aber der gehört ja nicht mal zum OS. Im Desktop oder normalen Anwendungen werden (wenn überhaupt) nur kleine Bereich gescrollt – da geht das ohnehin leichter durch, schließlich ist es ein Unterschied, ob man 9 KB bewegen will oder nur 3 KB.

Quote from DivZero

Ein Atari800XL oder so hat es da schon besser. Ich glaube bei dem kann man wirklich seine fast 1,8MHz nutzen.

Da geht auch einiges flöten. Ich glaube, man spricht so von 1.3 MHz, die "auf der Straße" ankommen. Und guck dir ruhig mal GOS auf YouTube an – das sieht schon recht fluffig aus – auch wenn die "Ausrichtung" meines Erachtens in die falsche Richtung geht.

doch das geht. es macht nur einen unterschied ob man eine demo schreibt wo nur eine bitmap gescrollt wird,

oder man eine bitmap in einem os scrollt, was ja im hintergrund andere dinge machen muss, z.b. irqś abarbeiten.

wenn man das os in dem moment stehen bleibt und man nur scrollt, sollte das kein problem sein.

Quote from DivZero

da wird dann gezeigt wie elend lahm es ist nur wenn man Text per Bitmap scrollen möchte.

Bedaure, aber das Programm, das hier als Beispiel herangezogen wird, ist offensichtlich ziemlich schlecht gemacht. Eine Textausgabe (inklusive Scrolling) auf der Bitmap hat es in vielen Programmen auf dem C64 gegeben, meist bei Portierungen vom AppleII. Als Beispiele seien genannt (unvollständige Liste): Adventures wie "Gremlins", "Borrowed Time" oder "Tass Times in Tonetown", Rollenspiele wie "Ultima IV" und "Ultima V" oder "The Bard's Tale". Bitmapgrafik wurde auch in Actionspielen verwendet wie z. B. "Bandits" (so viele gleichzeitig angezeigte Objekte wären mit Sprites überhaupt nicht möglich), "Drol", "Karateka", "Spellbound", "Prince of Persia", "Wings of Fury", "Cybernoid" oder "The Last Ninja". Bitmapscrolling siehst Du u. a. in den Adventures von Magnetic Scrolls wie "The Pawn", "The Guild of Thieves" oder "Jinxter".

Es ist einfach so, daß die Programmierer den Bitmapmodus des C64 erst sehr spät für sich entdeckt haben. Dabei hätte man ein Spiel wie "Defender of the Crown" schon viel früher haben können.

Quote from DivZero

Wenn es bei diesen Computer im BItmapMode 1 Frame Scrolling gibt, dann muss dort aber z.B. die CPU schneller laufen.

Es gibt auf dem AppleII kein 1 Frame Scrolling. Es gibt auch noch nicht einmal ein Scrollregister zum pixelweisen Verschieben der Anzeige. Trotzdem scrollen Spiele wie "Captain Goodnight" trotz geringerer Framerate schnell genug, um Spaß zu machen. Beim C64 hingegen ist es sogar möglich, eine ganze Bitmap per Softscrolling um einen Pixel sauber und ohne Ruckeln zu scrollen, da 8 Frames ausreichend Zeit bieten für das Umkopieren. Im Unterschied zum AppleII ging es aber vielen Entwicklern auf dem C64 darum, ihre Spiele in einer Kassettenversion ohne Nachladen anzubieten, so daß ein Doublebuffering für zwei Bitmaps vom Speicherverbrauch her zu aufwendig erschien. Das ist aber der Peripherie geschuldet, nicht dem C64 an sich.

Quote from DivZero

Denn nach Pixel 8 kommt nicht Pixel 9 im Speicher, sondern Pixel Pixel 321.

Angenommen, Du willst 8 Zeilen im Kachelraster von 8 Zeilen kopieren, so spielt es keine Rolle, wie der Block von 320 Bytes in sich angeordnet ist. Die krude Organisation der Bitmap auf dem C64 fällt erst dann ins Gewicht, wenn man außerhalb dieses Kachelrasters agieren will. Stell Dir eine Schleife vor, die eine beliebige Zeile umkopieren will. Normalerweise würde man Quellzeile und Zielzeile indirekt ansprechen über zwei Zeiger in der Zeropage:

Beim AppleII liegen die Daten nacheinander im Speicher. Beim C64 hingegen in einem Abstand von 8 Bytes. Daraus ergibt sich beim Apple folgende Schleife:

Beim C64 geht es nicht so einfach. Hier müßte man das Y-Register jeweils um 8 subtrahieren bzw. addieren:

Damit lassen sich die ersten 32 Bytes kopieren. Es fehlen für eine komplette Zeile aber noch 8. Also ergänzt man:

Das ist zunächst umständlicher als beim AppleII und kostet mehr Rechenzeit. Anders sieht es jedoch aus, wenn man die Schleife unrolled:

Ein INY ist genauso schnell wie ein LDY #<konstante>. Im Vergleich zur C64-Version kommt also lediglich die Erhöhung der Zeiger-Highbytes hinzu, was 10 Taktzyklen ausmacht.

Kurz gesagt: Wie schnell die Grafikdarstellung ist, hängt immer davon ab, wieviel Aufwand man darin investieren möchte. Weiß man im voraus, welche Zeilen man scrollen will, kann man die Scrollschleife auch komplett anders, nämlich parallel aufbauen, d. h. alle Zeilen werden gleichzeitig unter Verwendung der absoluten-indexierten Adressierung in einer Schleife gescrollt. Das macht es dann noch einmal viel schneller. Klar, so schnell wie mit einem Textmodus wird es nie, aber ausreichend schnell schon.

(Ich bitte um Entschuldigung für die schamlose Eigenwerbung, aber in meinem Adventure habe ich absichtlich HiRes-Bitmap für die Darstellung eines Proportionalfonts verwendet. Die Ausgabe ist daher langsamer als eine reine Textmodusausgabe, aber - wie ich finde - dadurch schöner lesbar. Wer lieber fettere Schrift oder eine 80-Zeichenausgabe haben möchte, kann das auch per Kommando "font dick" bzw. "font 80".)

Was für das Scrollen gilt, gilt übrigens auch für weitere Malvorgänge wie "Rechteck malen". Die Malroutinen in GEOS sind in dieser Hinsicht wirklich sehr langsam, weil extrem speicherplatzoptimiert geschrieben. Außerdem wird andauernd geprüft, in welche Bitmap gemalt werden soll: Anzeigebitmap, Hintergrundpuffer oder beides. Meiner Ansicht nach hat man hier an der falschen Stelle gespart und so den Eindruck erweckt, Grafik an sich wäre langsam. Dabei haben oben genannte Spiele (und noch einige mehr) längst bewiesen, daß die Verwendung von echter Grafik natürlich auch auf dem C64 in ertragbarer Form möglich ist.

Quote from DivZero

Also wäre so ein Bitmapscrolling möglich wenn man z.B. mit Double Buffering arbeitet, bei dem man dann ca 8 Frames Zeit hat fürs Umkopieren, weil man so lange das Hardwarescrolling um 8 Pixel nutzen kann?

Genau so ist es. Daß es funktioniert kannst Du Dir in den genannten Spielen "The Guild of Thieves" oder "jinxter" ansehen, die eine Multicolour-Bitmap (also inklusive des Farbrams bei $d800) scrollen. Bei diesem Scrollen wird tatsächlich sogar stets das ganze Bild gerollt, d. h. es werden immer alle Zeilen der Bitmap kopiert, auch wenn man sie nicht sieht, und beim Raufscrollen wird die oberste Zeile in die unterste kopiert, beim Runterscrollen die unterste in die oberste. (Gib bei "The Guild of Thieves" die Kommandos "pull at the rope" und dann "jump on the jetty" ein. Danach kannst Du ein wenig frei herumspazieren. Wenn Du dem Mann mit dem Wagen hilfst ("help man"), kannst Du auch ins Schloß gehen. Es lohnt sich, mal die Gegend anzugucken, denn das Spiel hat ein paar hübsche Grafiken.)

Noch ein kleiner Hinweis: Drückt man bei Erscheinen der Eingabeaufforderung ('>') die Taste <F5>, wird die Grafik um 2 Textzeilen nach oben gescrollt. Bei Druck auf <F7> um 2 Textzeilen runter. Wenn man aufpaßt, bemerkt man, daß beim Runterscrollen (<F7>) eine kleine Verzögerung vorhanden ist, bevor sich das Bild in Bewegung setzt. Das liegt daran, daß aufgrund der Stellung des Scrollregisters zuerst das Umkopieren erfolgen muß, bevor das Hardwarescrolling zum Einsatz kommen kann. Beim Raufscrollen (<F5>) ist jedoch keine Verzögerung bemerkbar, da hier direkt mit dem Hardwarescrollen begonnen wird, während im Hintergrund der Kopierprozeß läuft.

Quote from DivZero

Das scheint ja wirklich übel programmiert worden sein von der Grafikperformance her.

Die Entwickler von GEOS waren keine schlechten Programmierer. SIe haben ihren Job sogar ganz gut erledigt, nur hat man damals halt andere Prioritäten gesetzt. Da GEOS anders als bei Retrofans Vorschlag allein mit 64 kb auskommen mußte und das Nachladen von Diskette äußerst zäh war, hatte man einen großen Teil des Arbeitsspeichers mit Systemroutinen belegt. Da außerdem damals die Idee der Fenstertechnik aktuell war, wollte man solch ein Verhalten gerne imitieren. Aus diesem Grunde wurden für eine zweite Bitmap 8 kb zusätzlich belegt, um dort entweder unsichtbar für den Benutzer Grafiken zu erstellen, oder um die bisher angezeigte Bitmap dorthin zu sichern, wenn z. B. ein Dateirequester die Anzeigegrafik eines Programms übermalen mußte.

Retrofans Konzept basiert jedoch nicht auf der Fenstertechnik von damals, sondern auf der Bedienung von Smartphones heute. Aus diesem Grunde kann z. B. auf eine zweite Bitmap verzichtet werden. Die eingesparten 8 kb lassen sich dann zum Teil nutzen, um die Grafikroutinen zu beschleunigen, sei es durch unrolled Code oder die Verwendung von Tabellen (z. B. für die Anfangsadresse einer Bildschirmzeile).

Von daher herrschten bei GEOS ganz andere Anforderungen, die wohl in so manchem Fall zu einem schmerzhaften Kompromiß geführt haben zwischen Speicheraufwand und Effizienz. Man sollte es daher eher im Kontext seiner Zeit betrachten, und in dieser Hinsicht haben die Programmierer damals einen recht guten Job gemacht.

Quote from M. J.

Von daher herrschten bei GEOS ganz andere Anforderungen, die wohl in so manchem Fall zu einem schmerzhaften Kompromiß geführt haben zwischen Speicheraufwand und Effizienz. Man sollte es daher eher im Kontext seiner Zeit betrachten, und in dieser Hinsicht haben die Programmierer damals einen recht guten Job gemacht.

Danke, Du hast es verstanden

Wenn man auf das arme "GEOS" einprügelt, dann sollte man auch bedenken das z.B. die Textroutinen universell sind. Es braucht keinen extra Font für "Kursiv" oder "Fett" oder "Unterstrichen", auch kann die Routine mit Fonts in verschiedenen Größen umgehen. Der Programmierer übergibt nur ein WORD mit der Adresse des Fonts/Größe an eine Systemroutine, danach wird Text, der wieder nur über ein WORD (+X,Y) an die PRINT-Routine übergeben wird, im neuen Font ausgegeben. Steuercodes regeln KURSIV oder FETT. Zahlen, können Links- oder Rechtsbündig ausgegeben werden, mit oder ohne führende Nullen.

P.S. Optimierungen solcher Grafikroutinen sind unter GEOS mit Vorsicht zu genießen, da existierende Anwendungen äußerst empfindlich auf veränderte Speicherbereiche, insbesondere ZeroPage, reagieren. Die Routinen dürfen auch nicht größer sein als die bisherigen Routinen.

Das sind alles die von M.J. (richtig) genannten Systemroutinen, die einen Teil des Speichers "verschwenden". Die stehen dann aber auch anderen Programmen zur Verfügung. Das ist der Kompromiss zwischen Flexibilität und Effizienz. Die Nutzung von Makros oder diverser "Denkfehler" mal außen vor gelassen... Mein GeoDesk ist auch in vielen Bereichen der Fenstertechnik schneller als TopDesk von 1991 (eben nochmal verglichen, da liegen schon Welten dazwischen). Also nicht immer Äpfel(GEOS von 198x) mit Birnen(BitmapScroll von 2020) vergleichen...

Scrolling wird überbewertet, Grafikroutinen an sich auch. Ein OS besteht aus mehr als nur "Grafik". Die Bildschirm-Aus-/Eingabe ist nur ein kleiner Teil eines OS...

P.S.2. So auf die Schnelle... MegaPatch+GeoDesk, das sind ca., 110.000 Zeilen Code (ohne Kommentarzeilen). Der Code steht frei zur Verfügung. Wer will darf da gerne prüfen wie viel Code davon der Bildschirmausgabe dient.

Wenn wir schon beim Speicher sind... was wäre denn ein optimales Speicher-Layout? Bei GEOS liegt die Bitmap bei $A000. Ist das so "brauchbar"?

Quote from M. J.

Was für das Scrollen gilt, gilt übrigens auch für weitere Malvorgänge wie "Rechteck malen". Die Malroutinen in GEOS sind in dieser Hinsicht wirklich sehr langsam, weil extrem speicherplatzoptimiert geschrieben. [...] Meiner Ansicht nach hat man hier an der falschen Stelle gespart und so den Eindruck erweckt, Grafik an sich wäre langsam. Dabei haben oben genannte Spiele (und noch einige mehr) längst bewiesen, daß die Verwendung von echter Grafik natürlich auch auf dem C64 in ertragbarer Form möglich ist.

Vielen Dank für die Erläuterungen aus berufenem Mund. Es ist halt schwierig für mich allein, Behauptungen der Marke "geht nicht, weil geht nicht" entgegenzutreten, wenn ich nur mit Indizien versuche, das Gegenteil zu beweisen. Da ist so eine technik-orientierte Aussage mit Beispielcode doch schon deutlich wirkungsvoller.

Quote from darkvision

Wenn man auf das arme "GEOS" einprügelt

Niemand will hier auf GEOS einprügeln. Nur hat es halt (aus heutiger Sicht) viele Nachteile (die sich nur mühsam beseitigen ließen) und war damals auch nicht so optimiert, wie viele meinen. Gerade am Anfang des Threads wurde noch das Hohelied auf GEOS gesungen, weil es aus Sicht mancher die absolute Sperrspitze dessen darstellt, was auf dem C64 möglich IST. Das konnte ja nun in mehrfacher Hinsicht gerade gerückt werden. Für die damalige Zeit war GEOS 2.0 (und Abwandlungen) natürlich eine tolle Sache – nur bräuchten wir heutzutage halt etwas ganz anderes auf dem C64. Niemand will mehr auf der Kiste wirklich "arbeiten" und 100-Seitige Dokumente, Druckgrafiken, Datenbanken und ellenlange Tabellen erstellen. Auch wird niemand z.B. seine Adressen im C64 verwalten wollen, wenn man sie da nicht wieder herausbekommt. Wenn man den Fan noch vor den alten C64 locken will, muss er meines Erachtens andere Tasks beherrschen, damit das ganze noch Spaß macht.

Also: Für damals eine tolle Leistung, wenn auch vielleicht den C64 nicht optimal ausgereizt (man muss ja auch bedenken, dass es ein Produkt sein sollte, was möglichst schnell in die Läden musste, bevor die C64-User alle zu den neuen 16-Bit-Maschinen überliefen). Und heute ist es von der Ausrichtung her schlicht veraltet (deckt Nutzerwünsche zu wenig ab) und technisch, wie von der Benutzerführung her, hat man halt auch dazu gelernt. (Mal abgesehen davon, dass die heutigen Entwicklungswerkzeuge besser geworden sind und wir auch keinen wirtschaftlichen Druck mehr haben).

Quote from darkvision

Es braucht keinen extra Font für "Kursiv" oder "Fett"

Doch, eigentlich schon. Wenn man schon typografische Feinheiten unterstützt, dann sollte man auch getrennte Fonts für bold und kursiv verwenden, denn fette und kursive Schriftschnitte sind mitnichten einfach schräg gestellt oder "dick gemacht". Das SIND eigenständige Fonts mit eigenständigen Formen, bzw. sollten es sein. Aber aus einer gewissen Speicher-Not heraus kann man akzeptieren, dass GEOS da gespart hat.

Quote from darkvision

Scrolling wird überbewertet, Grafikroutinen an sich auch. Ein OS besteht aus mehr als nur "Grafik". Die Bildschirm-Aus-/Eingabe ist nur ein kleiner Teil eines OS...

Das wissen wir hier alle. Wir haben ja auch schon öfters über andere Merkmale gesprochen, z.B. auch ein Speicher-Layout konzipiert. Nur ist das wahrscheinlich nicht mehr ganz aktuell, weil nicht mehr feststeht, dass das EasyFlash 1 als einzige Speichererweiterung in Frage kommt. Wir haben auch darüber gesprochen, inwieweit z.B. Multitasking wichtig wäre oder die Unterstützung verschiedener Massenspeicher, Netzwerk etc. Alles Dinge, die mit dem GUI nichts zu tun haben.

Die Grafikroutinen sind für ein OS mit GUI aber schon ein wichtiger Teil. Darüber wird letztendlich entschieden, wie "snappy" dem User das ganze System vorkommt. Das GUI kann Schwächen des Systems verstärken oder abmildern. GEOS (inkl. Nachkommen und Patches) bzw. ein C64-GUI allgemein könnte deutlich schneller aussehen, wenn man einiges anders machen würde. Das ruckelige "Scrolling" bzw. Umschalten von Seiten z.B. in GeoWrite wirkt schon recht betagt. Der langsame Aufbau von Dialogen, wie z.B. dem File-Requester, wirkt auch nicht gerade performant.

Und ich hatte den Thread jetzt wiedergestartet, nachdem ich einiges darüber erfahren habe, wie bzw. dass man auch Bitmaps auf den C64 ausreichend schnell scrollen kann. M. J. hat glücklicherweise noch ein paar Beispiele genannt, die ich mir auch nochmal zu Gemüte führen werden. Der Witz ist, dass sich Scrolling doppelt auf die "gefühlte" Geschwindigkeit auswirkt. Zum einen gilt es als fast unmöglich (trotz der vielen Gegenbeispiele) und macht allein deshalb was her, zum anderen muss aber wesentlich weniger Text auf einmal gerendert werden als bei einer kompletten Seiten-Umschaltung. D.H. das Scrolling hilft sogar dabei, die Schwächen des Systems zu überdecken – wenn man es denn gut macht.

Quote from darkvision

Wenn wir schon beim Speicher sind... was wäre denn ein optimales Speicher-Layout?

Für das hier geplante OS?:

Wobei das noch zwingend von einem EasyFlash ausging. Es gibt einen Arbeitsmodus (work), der zu 99% der Zeit eingeschaltet ist – und einen Lade-Modus (load), der verwendet wird, um auf das 1 MB des EF-Carts (und andere Massenspeicher) zuzugreifen. Und was die restliche Verteilung angeht, würde man da bei einer Überarbeitung sicherlich noch einiges finden, was neu bedacht werden sollte.

[Posting-Split]

Quote from DivZero

Wenn man jetzt, wie beim Texteditor üblich, an dem Scrollbalken anfasst

Jetzt erwartest du aber vielleicht ein wenig zu viel vom C64. Ich sehe den "Scrollbalken" momentan nur als Positions-Anzeiger, wie man es auch von Mobile-Systemen kennt/kannte (in iOS kann man ihn seit kürzerer Zeit auch direkt anfassen, wie sich das bei Android entwickelt hat, habe ich nicht überprüft, müsste die Geräte-Akkus erst laden). Also nicht gleich zu viel erwarten. Gescrollt wird hier erst einmal nur mit den Scroll-Pfeilen in fester Geschwindigkeit.

Quote from DivZero

Oder ist das alles hier erstmal sowas wie ein Brainstorming? Wenn ja wann geht es los? Geht es überhaupt irgendwann los?

Wir können das hier wahrscheinlich unter Brainstorming mit ein ganz klein wenig Konzeption zusammenfassen. Ob es irgendwann losgeht, hängt davon ab, ob sich ein oder mehrere Programmierer finden, die Bock auf so ein Projekt haben. Und die werden dann auch im Endeffekt entscheiden, was und wie sie (es) umsetzen wollen. Ich würde natürlich gerne beim GUI und der Gesamtausrichtung mithelfen aber auch das liegt natürlich im Entscheidungsbereich der Programmierer.

Quote from DivZero

Das mit dem Scrollregister und DoubleBuffering klappt nur solange mit einer bestimmten Geschwindigkeit gescrollt wird in einem Frame. Wenn man jetzt, wie beim Texteditor üblich, an dem Scrollbalken anfasst und hin und her durch seine Textdatei scrollt, dann trifft man wieder auf die 3 Frames pro Bildschirmkopie. Oder liege ich hier falsch?

Dann noch eine Frage: Wenn man Doublebuffering im HiresBitmapMode nutzt, dann sind doch 16K auf jeden Fall weg vom RAM oder?

1.) Wenn man Softscrolling im Texteditor verwenden würde, benötigt man mehr als 16 kb Ram, denn in eine VIC-Bank paßt nur eine vollständige Bitmap mit 1 kb Farbram. Die verbleibenden 7 kb der VIC-Bank reichen für eine zweite Bitmap leider nicht aus. Beim Scrollen der gesamten Bitmap (25 Textzeilen) müßte daher der zweite Puffer in einer anderen VIC-Bank angelegt werden, was es nötig macht, auch das Farbram zu verdoppeln. Man braucht also 9 kb extra.

2.) Ein Softscrolling im Texteditor hat jedoch noch einen weiteren gravierenden Nachteil: Die Anzahl der dargestellten Textzeilen muß für das Scrollen (im Register $d011) von 25 auf 24 herabgesetzt werden. Dadurch verliert man Anzeigefläche. Möchte man außerdem eine Statuszeile auf dem Bildschirm hinzufügen, die beim Scrollen des Textes nicht mitbewegt wird, so muß zwischen Scrollfläche und Statuszeile eine leere Zeile eingefügt werden, was die Anzahl der Textzeilen erneut vermindert.

Letztlich ist das Softscrollen nur ein netter Effekt, der für die Arbeit mit dem Texteditor nicht erforderlich ist, dafür aber wichtigen Arbeitsspeicher wegnimmt, der besser für Text aufgehoben sein sollte.

3.) Möchte man willkürlich durch den Text scrollen, d. h. den Anfang der Textanzeige auf einen beliebigen Wert setzen, ist es ohnehin besser, die gesamte Anzeige neu aufzubauen. Gleiches gilt für einen Textmodus. Auch dort ist der Aufwand, einen bestimmten Anzeigebereich x Zeilen zu scrollen (hoch und runter) und dann die frei werdenden Zeilen mit neuem Text aufzufüllen, zu groß, als daß es sich lohnen könnte.

Um auf einem C64 in einem Text zu navigieren, sollte man sich vielleicht auf Zeile rauf/runter sowie Seite rauf/runter beschränken, vielleicht noch Sprung an den Anfang bzw. Ende des Textes und natürlich Wortsuche. Gemessen am maximal möglichen Textumfang wäre dies ausreichend.

[Posting-Split]

[Posting-Split]

Quote from Korodny

Das setzt m.E. zwingend die Möglichkeit voraus, auch PETSCII anzeigen zu können - völlig unabhängig vom gewählten Darstellungsmodus. Wenn du also nicht zwei Zeichensätze im Speicher halten willst, wirst du um ein bisschen Codepage-Gehacke nicht herumkommen.

Richtig. Für die Anzeige eines 1541-Verzeichnisses wäre ein PETSCII-Zeichensatz sinnvoll. Aber warum soll man dafür keine zwei Zeichensätze im Speicher halten? Genau darin liegt doch der große Vorteil der Bitmap: Man kann mit so vielen Zeichensätzen gleichzeitig herummalen, wie man will. Da das Desktop-Programm auch nur eine Applikation ist, stören die zusätzlichen 2 kb für den PETSCII-Zeichensatz nicht. Der Trick besteht ja gerade darin, daß es keinen festen Systemfont gibt, und daß kein Zeichensatz dauerhaft an einer bestimmten Stelle liegt. Mit anderen Worten: Hier kann man ruhig von GEOS lernen, so wie es darkvision beschrieben hat. Neu könnte sein, daß auch die Lage der Bitmap unbestimmt ist, obwohl sich $a000..$bfff anbieten würde, wenn auch mit dem Nachteil verbunden, daß das Farbram bei $8c00..$8fff liegt und der freie Raum von $9000..$9fff irgendwie gefüllt werden muß.

Quote from Matthias

Was mich bei der ganzen Diskussion interessiert wäre eine Source-Library, mit vielen Beispielen die man selbst mal in den Assembler laden und ausprobieren kann.

Was genau sollte die Source-Library enthalten?

Quote from DivZero

Gibt es überhaupt eine Planung, wenn ja wie ist der Stand?

Ich würde sagen, der Stand ist so weit, wie ihn Retrofan in seinen Mockups dargestellt hat. Zeichensätze hat er auch schon gepixelt, und die dargestellten Icons bieten ebenso eine Grundlage fürs Austesten. Es gilt zunächst diesen Vorlagen programmtechnisch Leben einzuhauchen. Darunter fallen z. B. Routinen zum Zeichenmalen, Setzen eines Zeichensatzes, Iconmalen usw. Dann muß man schauen, wie lang diese Routinen sind, wie man sie bündelt, wohin man sie in den Speicher packt etc. Hinweis: Der Bereich zwischen $c000..$cfff sollte Treibern vorbehalten sein z. B. fürs Laden über den Kernal oder Verwendung einer EasyFlash. Mein Vorschlag wäre, den Interrupt über $fffe laufen zu lassen, auf das Kernal im Normalbetrieb zu verzichten und lediglich fürs Laden auf Kernal umzuschalten. Das ermöglicht z. B. die volle Nutzung der 64 kb Ram, die Benutzung von Beschleunigern sowie angepaßten Keyboardroutinen und natürlich die uneingeschränkte Verwendung der Zeropage.

[Posting-Split]

Quote from M. J.

Beim Scrollen der gesamten Bitmap (25 Textzeilen) müßte daher der zweite Puffer in einer anderen VIC-Bank angelegt werden, was es nötig macht, auch das Farbram zu verdoppeln. Man braucht also 9 kb extra.

Grundsätzlich stimmt das natürlich. Allerdings könnte man überlegen, ob man in einem Text unbedingt Farbe benötigt.

Quote from M. J.

Möchte man außerdem eine Statuszeile auf dem Bildschirm hinzufügen, die beim Scrollen des Textes nicht mitbewegt wird, so muß zwischen Scrollfläche und Statuszeile eine leere Zeile eingefügt werden, was die Anzahl der Textzeilen erneut vermindert.

Ich hatte darüber auch schonmal nachgedacht. Alternativ kann man das allerdings auch anders machen. Zum einen gäbe es doch die Möglichkeit, die Scrollfläche von der Statuszeile mittels Raster-Interrupt zu trennen, oder? So wird das in Games (ich weiß, schlechtes Beispiel) doch auch oft gemacht. Oder benötigst du genau für diese Trennung die leere Zeile?

Zum anderen könnte man (analog zu iOS) beim Scrollen die Statusleisten mit aus dem Screen herausschieben um möglichst viel Text anzuzeigen und erst nach dem Scrollen wieder einblenden.

Quote from M. J.

Letztlich ist das Softscrollen nur ein netter Effekt, der für die Arbeit mit dem Texteditor nicht erforderlich ist, dafür aber wichtigen Arbeitsspeicher wegnimmt, der besser für Text aufgehoben sein sollte.

Da hast du natürlich recht.

Quote from M. J.

Dieser Thread versucht nun auszuloten, wie man das leere Papier am besten bemalen kann, so daß Geschwindigkeit und Benutzerfreundlichkeit akzeptabel sind. Dazu gehört die Verwendung von ISO-8859 als Zeichencodierung, da sie platzsparend ist und alle wesentlichen im Rahmen eines C64-OS zu erwartenden Zeichen abdeckt. Daher verstehe ich - wie gesagt - die Diskussion darum nicht.

Die Sache mit dem leeren Blatt Papier gefällt mir. Vielleicht macht die große Freiheit aber auch manchen Angst, die lieber alles in 40 x 25 Kästen denken wollen. Denen möchte ich sagen: keine Angst, es soll standardisierte GUI-Elemente für Formular- und Textfelder, Checkboxen etc. geben, was ein Riesenvorteil gegenüber immer wieder selbstgebastelten Eingabe- und Ausgaberoutinen wäre. Letztendlich soll das GUI die Entwicklung von Anwendungen beschleunigen, nicht verkomplizieren.

Quote from Korodny

Es waren sich m.E. mal alle einig, dass "Datei-Management" im weitesten Sinn eine der Hauptaufgaben eines noch zu entwickelnden OS sein würde. Das setzt m.E. zwingend die Möglichkeit voraus, auch PETSCII anzeigen zu können - völlig unabhängig vom gewählten Darstellungsmodus. Wenn du also nicht zwei Zeichensätze im Speicher halten willst, wirst du um ein bisschen Codepage-Gehacke nicht herumkommen.

Ich würde das dynamisch anlegen. Der Hauptzeichensatz des Systems sollte ISO 8859 (oder CP1252) sein. PETSCII würde man doch nur benötigen, wenn man auf echte Disketten (1541) bzw. D64/D81-Images treffen würde. Genau dann, wenn das z.B. in einem File-Requester passiert, kann man einen PETSCII-Zeichensatz laden. Und zwar sogar notfalls über den vorhandenen System-Zeichensatz drüber-bügeln – denn innerhalb der Box benötigen wir zu dem Zeitpunkt NUR PETSCII. Und alles, was schon gerendert auf dem Screen zu sehen ist, wird bei Bitmap ja nicht "umgeschaltet". Sobald man aus dem D64 wieder in ein "normales" Verzeichnis herausspringt, wird wieder der Systemzeichensatz geladen.

Wie gesagt, wir können sogar innerhalb eines langen Textes jederzeit, z.B. kapitelweise (notfalls auch buchstabenweise), zwischen Zeichensätzen wechseln und trotzdem immer nur EINEN geladen haben – und zwar den, mit dem wir gerade rendern wollen. Ob das praktikabel ist, hängt alleine davon ab, wie schnell wir 2 KB Zeichensatz aus der ROM- oder RAM-Erweiterung holen können. Ich denke aber, dass das beim Laden/Anzeigen eines D64-Verzeichnisses keine große Rolle spielen wird.

Wir haben im Bitmap-Mode zwei Möglichkeiten, mit mehreren Zeichensätzen umzugehen: Zum einen können wir mehrere Charsets im Speicher halten und parallel auf dem Screen nutzen, zum anderen können wir sie auch (speicherplatz-sparend) gegeneinander austauschen, ohne auf dem Bildschirm vorhandenes zu zerstören. Beides ginge z.B. im Char-Mode nicht.

Quote from M. J.

auf das Kernal im Normalbetrieb zu verzichten und lediglich fürs Laden auf Kernal umzuschalten. Das ermöglicht z. B. die volle Nutzung der 64 kb Ram

Das ist auch eine der Grundideen bei dem "NaxOS" Work/Load-Speichermodell.

Noch ein kleiner Nachtrag: Auch der kommende Retro-Rechner Commander X16 vom 8-Bit-Guy wird (natürlich neben PETSCII) ISO 8859-15 unterstützen. Ich denke, es ist einfach der beste Kompromiss zwischen Zeichenvorrat, Kompatibilität und Machbarkeit auf einer 8-Bit-Kiste. Mir persönlich fehlen bei Latin-9 zwar ein paar Zeichen, die in CP1252 enthalten sind – allerdings würde ich die zugunsten eines echten ISO-Standards verschmerzen können.

Quote

x16-emulator-r31 - Main differences:

ISO mode: hit Ctrl+o to switch to ISO mode: the character encoding is now ASCII/ISO-8859-15, and you can enter and print the following characters: "¡¢£€¥Š§š©ª«¬®¯°±²³Žµ¶·ž¹º»ŒœŸ¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ". You will need to enter BASIC keywords in upper case!

Quelle

(Und auch dem Mega65 würde es gut zu Gesicht stehen, zusätzlich zu PETSCII einen ISO-Zeichensatz zu integrieren, denn der C65-Prototyp war von 1991 und der Amiga mit seinem Fast-ISO-Zeichensatz kam schon 1985 auf den Markt. Man kann sich damit (bis vielleicht auf die Keycaps) diese lokalen Sonderserien für jedes Land Europas, wie es sie noch beim C128 gab, sparen)