Hello, Guest the thread was viewed86k times and contains 624 replies

last post from Retrofan at the

Neues C64 OS: "C64 OS"

  • 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.

  • 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.

    GEOS hat bei C64-Usern zu der falschen Erkenntnis geführt, dass Bitmap-Darstellung grundsätzlich langsam sein muss. Weil GEOS nunmal recht langsam war. Das lag aber nur zum Teil an der Hardware, sondern eben auch an GEOS. Es gibt ja einige Threads, in denen ich und andere uns diesem Thema widmen. Linien zeichnen und Flächen füllen geht z.B. rund 4 mal schneller als bei GEOS umgesetzt. Auch Textdarstellung (Bitmap, proportional) geht weitaus schneller als in GEOS, zumindest wenn man Einschränkungen bei der Schriftgröße in Kauf nimmt. Auch das Prinzip, Elemente erst mit Linien zu umranden um sie danach noch mit Farbe zu füllen oder Menüs/Buttons bei Klick zu invertieren, statt das über Hintergrundfarbe zu lösen, bremst die Darstellung aus.


    Also bin ich deiner Meinung, dass man auch auf dem C64 (und nicht nur auf dem Atari XL/XE) ein performantes Bitmap-GUI/OS hinbekommen könnte. Vorschläge, wie sowas aussehen (und wie man erweiterten Speicher intelligent nutzen) könnte, habe ich ja schon gepostet und Routinen für Grafik-Primitive und Proportional-Text gibt es dank einiger guter Programmierer aus dem Forum auch schon. Im Gegensatz zu C64-OS oder auch GUI64 hat sich nur noch niemand "herangetraut", dass von Grund auf und vollständig umzusetzen. Denn natürlich wäre das ein ganzer Arsch voll Arbeit. ;)


    Wobei der Zeichensatz nur eine Handvoll Buchstaben oder gar nur Zahlen enthält und alle anderen Zeichen den Hintergrund bilden.

    Und das ist mE auch ein Haupt-Problem bei den Char-Mode-GUIs. In einem "modernen" OS/GUI erwarte zumindest ich eigentlich, dass möglichst viele Zeichen dargestellt werden können – neben Klein- (hier schwächelt TEOS schon) und Großbuchstaben und auch den PETSCII-Characters sollten mE auch die wichtigsten internationalen Zeichen (wie z.B. Umlaute und Akzentbuchstaben) angezeigt werden können. Im Charmode wird aber von jedem modifizierten GUI-Element (z.B. Fensterumrandungen, Icons usw.) ein Zeichen verbraucht, dass dann für etwas "sinnvolleres" fehlt. Im Bitmap-Mode wäre noch nicht einmal bei ISO-8859 (8 Bit Encoding) Schluss, denn man könnte beliebige Mengen von Fonts nacheinander in den gleichen Speicherbereich laden, ohne schon Geschriebenes zu verändern. Möglich – neben internationaler Belegung, Proportionalschrift, mehr Text pro Zeile und zusätzlichem PETSCII – wären damit z.B. auch Text-Auszeichnungen, wie bold oder kursiv.

  • GEOS hat bei C64-Usern zu der falschen Erkenntnis geführt, dass Bitmap-Darstellung grundsätzlich langsam sein muss.

    Das stimmt. Das Final Catridge hat das Gegenteil bewiesen. Sah nicht nur besser aus, war auch deutlich schneller - und das mit verschiebbaren Fenstern.

    Schade das da niemand Programme für gemacht hat. Es gibt doch so was wie eine Developer Disk. Ich hab da erst vor ein paar Jahren erfahren.

  • Im Gegensatz zu C64-OS oder auch GUI64 hat sich nur noch niemand "herangetraut", dass von Grund auf und vollständig umzusetzen. Denn natürlich wäre das ein ganzer Arsch voll Arbeit. ;)

    Wenn GUI64 (von meiner Seite aus) fertig ist, würde ich das gerne mit dir zusammen (und evtl. anderen) starten. :-) Dabei könntest du dich voll grafisch austoben, denn ich hätte ja dann mit GUI64 bereits meine Vorstellungen umgesetzt.

  • Sah nicht nur besser aus, war auch deutlich schneller - und das mit verschiebbaren Fenstern.

    Über das "besser aussehen" kann sich streiten. Ich finde es nicht. Die Bedienelemente sehen genauso altbacken aus wie in GEOS*. Und ab GEOS 2.5 kann man auch Fenster verschieben. Gut, war dann nicht mehr original Berkeley Softworks.


    *) Dazu muss man natürlich sagen, dass es damals noch keine (unausgesprochenen) Standards für GUIs gab. Jeder hat irgendwie sein Ding gemacht.

  • Über das "besser aussehen" kann sich streiten.

    Das stimmt. Ich bin halt Workbench Fan. Ist für mich kreatives Chaos. Alleine wenn ich an die überdimensionalen Piktogramme denke.:rolleyes:

    Und ab GEOS 2.5 kann man auch Fenster verschieben. Gut, war dann nicht mehr original Berkeley Softworks.

    Da haste auch wieder wahr. Die Oberfläche sieht da schon sehr viel besser aus. Hab da unter GEOS65 mit rum gespielt.

    Ist da sehr schnell. Mit dem TC64 wird man eine vergleichbare Performance haben.:thumbup:

  • Wenn GUI64 (von meiner Seite aus) fertig ist, würde ich das gerne mit dir zusammen (und evtl. anderen) starten.

    Das würde mich natürlich freuen. :thumbsup: Und wie gesagt, es gibt schon einiges, was man evtl. integrieren könnte. Wäre zu schade, wenn das ungenutzt bliebe.


    Und ab GEOS 2.5 kann man auch Fenster verschieben.

    Allerdings finde ich, dass die festen "Fenster" von GEOS gar nicht so doof (nur zu klein) waren. Eines der wenigen Features, das ich (natürlich lange nach iOS und Android) für mein Konzept übernommen habe.


    Dazu muss man natürlich sagen, dass es damals noch keine (unausgesprochenen) Standards für GUIs gab. Jeder hat irgendwie sein Ding gemacht.

    Es gibt heutzutage natürlich "Standards" (vieles dürfte auf Apples Human Interface Guidelines basieren) aber trotzdem sieht Android anders aus als Windows 10. Weil es natürlich auch Freiheiten und unterschiedliche Anforderungen/Beschränkungen gibt.


    GEOS sieht man in vielen Details an, dass es dem Mac System nachempfunden wurde (soweit das in 320 x 200 px auf einem 1 MHz-Rechner möglich war) – aber das war quasi bei allen bekannten Systemen aus den 80ern der Fall (AmigaOS noch am wenigsten). Und in den 90ern eiferten "alle" NeXTStep nach – ganz besonders AmigaOS 2.0 und Windows 95. Das waren halt auch immer Mode-Erscheinungen: Windows 7 mit seinen ganzen Transparenz-Effekten und Schatten (OSX nacheifernd und "übertreffend") und danach dann der kantige, flächige Windows 8/10-Look (der vom Smartphone kam). Vieles lässt sich mit Usability alleine nicht erklären, da ist schon viel Lifestyle drin. Finde ich auch nicht schlimm, muss den Kunden ja gefallen.

  • Vieles lässt sich mit Usability alleine nicht erklären, da ist schon viel Lifestyle drin. Finde ich auch nicht schlimm, muss den Kunden ja gefallen.

    Richtig. Irgendwann waren die Standards ja gesetzt.


    Bzgl. GEOS und Standards: Zum Beispiel ist es in GEOS einfach nur kagge, dass die Menüs einfach zugehen, wenn man den Mauszeiger daraus entfernt.


    Bzgl. GEOS und Mac: Die GEOS-Grafik kommt nicht im Geringsten an die des Mac von damals ran. Ja, die Grundsätze sind ähnlich, aber das war's auch schon. Ist natürlich auch schwierig mit der geringen Auflösung.

  • War das was Offizielles?

    Weiß ich nicht. Ich habe auch nur das Directory der Disk mal irgendwo gesehen.

    Das sah mir offiziell aus, muss es aber nicht.

    Nein, dass war nichts offizielles. Gab es im Rahmen eines Programmiercontest von Riska B.V..



    Ich war damals schon und bin nach wie vor ein großer Fan der GUI der FCIII.

  • Zum Beispiel ist es in GEOS einfach nur kagge, dass die Menüs einfach zugehen, wenn man den Mauszeiger daraus entfernt.

    Wieso ist das die Schuld von GEOS? GEOS kann das verlassen von Menüs nach links/rechts/unten unterbinden, in dem es den Bewegungsradius des Mauszeigers einschränkt. Es waren schlichtweg die Anwendungs-Programmierer die das damals (und ich heute auch) nicht wollten. Ja, das ist etwas anderes als Klick - öffnen und das Menü bleibt geöffnet auch wenn ich den Mauszeiger aus dem Menü bewege. Bei letzterem Frage ich mich aber: Wozu?


    Wie ist das bei C64OS? Oder wie war das damals bei Apple? (Rein aus Interesse, hab beides nie genutzt)

  • Ja, das ist etwas anderes als Klick - öffnen und das Menü bleibt geöffnet auch wenn ich den Mauszeiger aus dem Menü bewege. Bei letzterem Frage ich mich aber: Wozu?

    Ernsthaft jetzt? Weil man auch mal zu schnell über das Menü fährt und so das Menü verlässt. Das passiert ziemlich häufig. Bei jeder halbwegs modernen GUI bleibt das Menü offen bis zum nächsten Klick.


    Wie ist das bei C64OS?

    Siehe dazu diese beiden Videos:

  • Ernsthaft jetzt? Weil man auch mal zu schnell über das Menü fährt und so das Menü verlässt. Das passiert ziemlich häufig. Bei jeder halbwegs modernen GUI bleibt das Menü offen bis zum nächsten Klick.

    Nochmal: Das muss man dem Programmierer der Anwendung in die Schuhe schieben, GEOS bietet die Möglichkeit das zu begrenzen (zumindest auf drei Seiten). Schon vor 30 Jahren. Die Anwendungs-Programmierer wollten das damals halt nicht. Und ich würde das auch heute nicht so zwangsweise vorgeben wollen.


    Aber es hat mich nur 5min gekostet um bei einem meiner GEOS-Programme das Optional einzubauen: Ist die Option aktiviert kann man keines der Menüs mehr versehentlich nach links/rechts/unten verlassen, weil ich GEOS sage "begrenze den Mauszeiger".


    Die Möglichkeit scheint es damals sogar bei Apple gegeben zu haben, wenn man den Hitchhikers Guide to GEOS glaubt...

  • Bzgl. GEOS und Standards: Zum Beispiel ist es in GEOS einfach nur kagge, dass die Menüs einfach zugehen, wenn man den Mauszeiger daraus entfernt.

    GEOS kann das verlassen von Menüs nach links/rechts/unten unterbinden, in dem es den Bewegungsradius des Mauszeigers einschränkt. Es waren schlichtweg die Anwendungs-Programmierer die das damals (und ich heute auch) nicht wollten.

    Also, ich kann verstehen, dass die Programmierer das Verhalten nicht eingebaut haben. Ich denke, der User hätte sich irgendwie gefangen genommen gefühlt, wenn er das Menü nur nach oben oder durch Auslösen eines Menüpunktes hätte verlassen können. Da war die Variante mit Verlassen und Zuklappen noch eleganter – trotzdem nicht wirklich gut.


    Es gab damals natürlich noch keinen wirklichen Standard. Apple, als Erfinder der Menüleiste (Der Xerox Alto und Smalltalk hatten keine) mit Pulldown-Menüs hatte natürlich ein (für das eigene OS standardisiertes) Verhalten definiert. Das war aber anders, und zwar hielt man die Maustaste nach dem Anklicken eines Menüpunktes gedrückt und ließ dann über dem entsprechenden Unterpunkt los. Dabei konnte man beliebig den Menü-Bereich verlassen – solange man die Taste gedrückt hielt, blieb das Menü offen und reagierte mit Highlighting auf Mouseover. Ließ man außerhalb des Menüs los, klappte das Menü ein, ohne dass eine Funktion ausgelöst wurde.


    Windows hat sich später für ein anderes Verhalten entschieden: Hier hat man einmal geklickt, um ein Menü zu öffnen und ein weiteres Mal zum Auslösen eines Menüpunktes. Und ich glaube, das Menü blieb dann auch solange geöffnet, bis man das zweite Mal (irgendwo hin) geklickt hat. Man benötigte also zwei Klicks (wie bei GEOS), während der Mac mit einem auskam. Ich glaube, der Amiga hat das Mac-Verhalten übernommen, nur dass man die rechte Maustaste nutzte und vor dem Drücken der Maustaste die Menüleiste unsichtbar war.


    Mac OS hat mit Version 8 das Windows-Verhalten zusätzlich übernommen, es geht seitdem beides – einmal klicken, gedrückt halten, loslassen oder eben loslassen und mit einem zweiten Klick den Menüpunkt auslösen. Zusätzlich hat man das Verhalten auf beide Maustasten gelegt (sofern eine Zweitasten-Maus angeschlossen war), sodass auch Amiga-sozialisierte damit glücklich geworden sein dürften.

  • Mac OS hat mit Version 8 das Windows-Verhalten zusätzlich übernommen, es geht seitdem beides – einmal klicken, gedrückt halten, loslassen oder eben loslassen und mit einem zweiten Klick den Menüpunkt auslösen.

    Windows kann auch beides; hab ich aber gerade erst festgestellt, daß es auch die Mac-Methode mitmacht :D

    Den Mauszeiger in einen Bereich zu "sperren" war ja bei GEOS eher aus der Not geboren. Würde ich bei den Menus super unpraktisch finden, gerade wenn noch Untermenus mitaufklappen, dann hat man ja nicht nur ein einfaches Rectangle.


    Kommt eigentlich hier jemand zur Classic Computing dieses Wochenende? Ich frag mich, ob man da irgendwo "C64OS" live sehen kann.

  • Man benötigte also zwei Klicks (wie bei GEOS), während der Mac mit einem auskam.

    ...mit einem unnötig langen Halten der Maustaste. Weil früher die Mäuse noch per Kugel gesteuert wurden und man oftmals nachziehen musste, halte ich das für kein gutes Verhalten - gerade bei etwas längeren Menüs. Da klicke ich lieber zweimal kurz anstatt krampfhaft darauf zu achten, dass der Mausknopf gedrückt bleibt. Aber ist alles Geschmacksache. Heute geht unter Windows und Mac beides.

  • halte ich das für kein gutes Verhalten - gerade bei etwas längeren Menüs.

    Ist halt Geschmacksache. Zum einen war es das erste und originale Verhalten von Menüzeilen mit Pulldown-Menüs und zum anderen waren Anfangs die Menüs noch keine solchen "Romane", wie später. Und später waren ja beide (herauskristalisierten) Möglichkeiten nutzbar.