Display MoreÜber Geschmack kann man ja nur streiten. Was ich an Gregs Ansatz mag (allen Vorbehalten – vor allem zu Textmode und Fenstern – zum Trotz), ist, dass er versucht, eine eigenständige Lösung zu finden. Man kann nicht behaupten, dass er versucht, einen Mac- oder Windows- oder Amiga-Clone auf dem C64 zu bauen. Es ist halt eine C64-eigene Lösung geworden, die den C64-Eigenheiten Rechnung trägt und versucht, aus den beschränkten Möglichkeiten möglichst viel herauszuholen. Mein persönlicher Ansatz wäre ein anderer, weil ich denke, dass der Textmode eine Sackgasse ist – trotzdem gratuliere ich zum Ergebnis.
- über Geschmack streiten: Definitiv, niemand hat den besten gepachtet
- eigenständige Lösung: Es gab in der Vergangenheit und gibt sogar aktuell soviele GUI-Lösungen für den C64, egal, ob, die jetzt an Mac-, Windows- oder was auch immer angelehnt waren. Ich persönliche finde quasi jede besser gelungen als die von C64 OS; das Argument mit der eigenständigen Lösung geht da eher nach hinten los
- für mich gehören die Clips64-Mockups immer noch zu den geilsten 8bit GUI Entwürfen aller Zeiten (auch wenn's ein Konzept für ein 16bit System war, denn die GUI selbst wäre ja auf dem VIC2 realisierbar)
Was ich nie verstanden habe ist, warum man auf dem C64 nach GEOS meistens der Meinung war, eine schnelle GUI könnte man nur noch im Textmode realisieren.
- der C64 muß nur gut 8KB im Bitmap Modus verwalten; halb sowenig wie der CPC mit seinen 16KB bei gleicher Auflösung
- der 6510 ist ja nicht weniger als halb so schnell wie der Z80 im CPC, oder? Also was ist das Problem, 8KB zu verwalten? (früher hieß es mal, die wären gleich schnell)
- die Atari 8bit schaffen ja auch eine superschnelle Bitmap GUI mit 320x200x2 (8KB; siehe "A8GOS"). Na gut, sie haben einen etwas schnelleren 6502; allerdings ist der Unterschied marginal
- oder liegt es alleine daran, daß man die ca. 6K oder so noch sparen will für Code beim C64, wenn man den Textmode nimmt? (könnte ich ein bischen nachvollziehen, weil der C64 kein brachbares RAM-Bankswitching für Code hat).
Der C64 hat im Gegensatz zu anderen Systemen einen sehr leistungsfähigen (Multicolor) "Text" Modus. Sehr viele 64 Spiele benutzen wieder erwarten nicht den Grafikmodus sondern tatsächlich den Multicolor Textmodus.
Wobei der Zeichensatz nur eine Handvoll Buchstaben oder gar nur Zahlen enthält und alle anderen Zeichen den Hintergrund bilden.
Dieses Konzept kommt von den Arcademaschinen die das exzessiv benutzen,dort heißt es Tilebased.
Bei Hires Grafik mit 320x200 Pixeln hat man pro 8x8 Pixel eine Vordergrund und eine Hintergrundfarbe die Farben anzusprechen ist etwas Frickelei aber in schwarz weiß sollte das recht zügig gehen.
Aufgrund des Designs müsste A8GOS eigentlich ziemlich ähnlich schnell auf dem C64 laufen da beim Atari die CPU ständig ausgebremst wird.
Bankswitching ist beim C64 über das was die PLA mit den ROMs "hinter dem RAM und oder IO" eigentlich nicht vorgesehen. Deshalb arbeitet auch die REU mit DMA statt Banking.
Ich bin zwar der Meinung es müsste möglich sein dem C64 ein Atari like Banking beizubringen es hat aber wohl noch keiner in folgender Form versucht geschaft:
Man baut ein 16K Modul welches RAM statt ROM im Bereich von $8000-BFFF einblendet.
Damit man in dieses RAM schreiben kann muss sobald am Adressbus eine Adresse in diesem Bereich anliegt der Ultimax Modus aktiviert werden.
Das problematische dabei ist der VIC-II entweder muss man dem extern ebenfalls RAM unterschieben und dafür sorgen das die CPU den Speicher an der richtigen stelle sieht oder dafür sorgen das der Bildschirmspeicher
günstig liegt und dieser in den VIC-II Zyklen aktiv ist, was wohl ohne ein paar extra Leitungen zum Cartridge-Port nicht möglich ist.
Da Speicher im Gegensatz zu damals recht billig wäre es wohl das einfachste den C64 Speicher bis auf die ersten 4K extern zu ersetzen und im Bereich $E000-FFFF wahlweise ein externes Kernal ROM oder RAM einzublenden.
Der Bereich $D000-$DFFF wäre dann fest I/O. Ein RAM Banking könnte man dan wie beim Atari im Bereich $4000-7FFF durchführen.