letzter Beitrag von huedrant am
Nee, in ernst: Gibt es (mal abgesehen von akademischen Versuchen), irgend jemanden, der "ernsthaft" noch mit GEOS was macht?
Also regelmässig produktiv und so, Brief/Rechnungsverkehr schreiben, DTP, Bilder malen für Kunden etc. ?
Das war ja quasi meine Ausgangsfrage in meinem ersten Posting. Es hat sich (auch ohne Umfragefunktion) herausgestellt, dass das nicht der Fall ist. Von daher sind wir umgeschwenkt auf eine "rein akademische" Diskussion ohne erhofften Nutzwert.
Ich denke, eine grafische Benutzeroberfläche mit Mausbedienung macht für den C64 durchaus Sinn (wobei "Sinn" hier natürlich sehr weit gefasst werden muss).
Solltest du das nicht auch noch begründen? Warum macht es Sinn?
Das ist ja nun wirklich sehr akademisch - aber die allermeisten Ideen, die einem so einfallen, brauchen irgendeine Form von Netzwerkunterstützung oder würden zumindest stark davon profitieren. Man bräuchte also auf jeden Fall schon mal einen TCP-Stack oder eine Möglichkeit auf fremde Dateisysteme zuzugreifen - damit dürfte GEOS schon ausscheiden. Aber selbst wenn es möglich wäre,dort noch einen TCP-Stack oder Unterstützung für Netzwerklaufwerke einzubauen: wenn ich schon Speicher und CPU-Zyklen für einen TCP-Stack abgeben muss, ist es in meinen Augen unsinnig sich noch eine HIRES-Benutzeroberfläche mit Proportionalschrift ans Bein zu binden.
Dazu kommt, das GEOS ein proprietäres Produkt ist.
GEOS wurde hier ja schon kritisiert: Wegen der langsamen Ausführungs-Geschwindigkeit (kann man mit dem TC64 beheben)
Die Idee war doch, "alte Technik" sinnvoll einzusetzen. Das TC64 ist ja nun beim besten Willen nicht alt.
Ein textbasiertes Minimal-Betriebssystem mit TCP-Stack, PETSCII-Encoding und wahlweise 40- oder 80-Zeichen-Darstellung wäre auch um einiges portabler: Ein Commodore-Treffen als LAN-Party, bei dem die Leute auf CBMs, VICs mit 40-Zeichen-Karte, C128 und C64 eine PETSCII-Variante von "Midi-Maze" spielen 
Solltest du das nicht auch noch begründen? Warum macht es Sinn?
Das ist ja nun wirklich sehr akademisch - aber die allermeisten Ideen, die einem so einfallen, brauchen irgendeine Form von Netzwerkunterstützung oder würden zumindest stark davon profitieren. Man bräuchte also auf jeden Fall schon mal einen TCP-Stack oder eine Möglichkeit auf fremde Dateisysteme zuzugreifen - damit dürfte GEOS schon ausscheiden. Aber selbst wenn es möglich wäre,dort noch einen TCP-Stack oder Unterstützung für Netzwerklaufwerke einzubauen: wenn ich schon Speicher und CPU-Zyklen für einen TCP-Stack abgeben muss, ist es in meinen Augen unsinnig sich noch eine HIRES-Benutzeroberfläche mit Proportionalschrift ans Bein zu binden.
Dazu kommt, das GEOS ein proprietäres Produkt ist.
Die Idee war doch, "alte Technik" sinnvoll einzusetzen. Das TC64 ist ja nun beim besten Willen nicht alt.
Na und ? Die alte Software bekommt durch das TC64 aber nunmal die Power die es eigentlich benötigt.
Die Frage ist nur: Für was?
Um das Geruckel und die hässlichen vertikalen Streifen beim Benutzen abzustellen. Kurzum: Mit der Kombi wird eine Benutzung erträglich.
wenn ich schon Speicher und CPU-Zyklen für einen TCP-Stack abgeben muss, ist es in meinen Augen unsinnig sich noch eine HIRES-Benutzeroberfläche mit Proportionalschrift ans Bein zu binden.
GEOS ist als Betriebssystem ja prinzipiell recht universell. Da war man auf den Hires-Bitmap-Modus angewiesen, um Text und Grafik beliebig gemischt gleichzeitig darstellen zu können. Wenn man eine grafische Benutzeroberfläche neu mit festen Vorgaben/Beschränkungen definiert, könnte man die durchaus im Textmodus umsetzen.
Etwas in der Art hat sogar jemand schon mal gemacht. Da wurde ein an die GEOS-Oberfläche angelehnter Desktop mit Menü und Fenstern im Textmodus nachgebaut. War natürlich nicht GEOS-kompatibel und mehr als Dateien auf Disketten organisieren ging damit auch nicht, wimre. Sah aber nett aus und war flott. Nannte sich, glaube ich, FOBS (vermutlich für Fensterorientiertes Betriebssystem).
Solltest du das nicht auch noch begründen? Warum macht es Sinn?
Es macht Sinn, weil es die Benutzung vereinfacht. Deswegen ist man ja von DOS weg und hat sich mit Windows angefreundet. Und ich bin der Meinung, dass der C64 nicht zu langsam ist für eine grafische Oberfläche. Es kommt natürlich darauf an, wie man es macht. Ich denke, dass GEOS nicht 100% aus dem C64 herausholt und da durchaus noch ein bisschen Luft nach oben ist.
Ein existierendes Problem von GEOS ist ja, dass es die Bedienung des C64 erstmal nicht wesentlich einfacher macht – ein Anfänger also erstmal nichts gewinnt. Ein C64-Grafikprogramm, wie Koala-Paint habe ich ja schneller gestartet als erst GEOS zu laden und dann GeoPaint. Und dann muss man die Programme neu auf den Disketten verteilen (natürlich unter GEOS), damit man überhaupt Bilder abspeichern kann. Oder man braucht halt mehr Hardware. Irgendwie war das eher sperrig als einfach – der Kopierschutz hat da seines zu beigetragen.
Schön wäre halt irgendwas Vorkonfiguriertes auf einem EasyFlash-Modul zum Einstecken oder ein Image, das man einfach auf einen größeren Datenträger (SD-Karte) packen und dann einfach starten könnte.
Aber selbst wenn es möglich wäre,dort noch einen TCP-Stack oder Unterstützung für Netzwerklaufwerke einzubauen: wenn ich schon Speicher und CPU-Zyklen für einen TCP-Stack abgeben muss, ist es in meinen Augen unsinnig sich noch eine HIRES-Benutzeroberfläche mit Proportionalschrift ans Bein zu binden.
Über Proportionalschrift kann man natürlich streiten, die hatten Amiga und ST auch nur in speziellen Anwendungen und nicht in der normalen Oberfläche. Aber den Grafikmodus finde ich nicht schlecht, weil er sehr flexibel ist.
Ich habe ja so einen Servant64, eine Ethernetschnittstelle für den C64 (Hardwarekosten waren was bei 20€, wenn ich mich recht entsinne). Ich meine, dass sich das Dings selbsttätig um den ganzen TCP-Kram kümmert und man auf C64-Seite recht einfach darauf zugreifen kann. Sowas würde ich halt am ehesten nutzen wollen, wenn man eine Internetverbindung herstellen möchte.
Dazu kommt, das GEOS ein proprietäres Produkt ist.
Stimmt, Open Source wäre natürlich besser.
Die Idee war doch, "alte Technik" sinnvoll einzusetzen. Das TC64 ist ja nun beim besten Willen nicht alt.
Ich hatte das nur erwähnt, weil der Einwand sonst ohnehin von Ace gekommen wäre. Ich präferiere aber Lösungen, die mit weniger Hardware-Overkill funktionieren würden – halt nur optional davon profitieren.
Ein textbasiertes Minimal-Betriebssystem mit TCP-Stack, PETSCII-Encoding und wahlweise 40- oder 80-Zeichen-Darstellung wäre auch um einiges portabler
Vielleicht auch ganz nett – aber nicht das, was ich mir wünschen würde. Mir wäre das etwas zu rudimentär – und einen wirklichen Nutzen kann ich darin auch noch nicht erkennen.
Um das Geruckel und die hässlichen vertikalen Streifen beim Benutzen abzustellen. Kurzum: Mit der Kombi wird eine Benutzung erträglich.
Meine Frage ging eigentlich eher in die Richtung, was du mit GEOS machen würdest, wenn denn die Benutzung "dank TC64" erträglich wäre.
Wenn man eine grafische Benutzeroberfläche neu mit festen Vorgaben/Beschränkungen definiert, könnte man die durchaus im Textmodus umsetzen.
An solchen Sachen habe ich ja schon gearbeitet. FIBR oder auch der EasyFlash/Tapecart-Browser haben ja Textmodus-basierte GUIs. Aber man kann damit manche Sachen eben nicht so schön machen, wie mit Bitmaps. Ich kann mir aber durchaus vorstellen, dass man die Modi mischt, also vertikal den Screen per Rasterinterrupt trennt und in einem Teil textbasiert oder in MC-Grafik arbeitet und in einem anderen Teil Hires-Grafik hat.
Gab es nicht sogar mal GEOS auf nem Prom/Eprom für die Hardcor-User
die den langsamen Start von Geos abkürzen wollten.Natürlich mit dem
sonstigen GEOS-Brimborium an Vertriebsweg.Original Boot-Disk einschicken
wegen Kopierschutz und man bekam dann ein Eprom zurück das man auf die
damals üblichen Eprom-Karten stecken konnte?Mich dunkel Erinnerung.
Etwas in der Art hat sogar jemand schon mal gemacht. Da wurde ein an die GEOS-Oberfläche angelehnter Desktop mit Menü und Fenstern im Textmodus nachgebaut. War natürlich nicht GEOS-kompatibel und mehr als Dateien auf Disketten organisieren ging damit auch nicht, wimre. Sah aber nett aus und war flott. Nannte sich, glaube ich, FOBS (vermutlich für Fensterorientiertes Betriebssystem).
Oh, danke - kannte ich noch gar nicht. Werd's mir mal ansehen, aber ein kurzer Blick ins Directory der Diskette zum Sonderheft 74 ergibt folgendes Bild: Kernel 50 Blocks, Desktop 80 Blocks, Eingabetreiber 5 Blocks...
Über Proportionalschrift kann man natürlich streiten, die hatten Amiga und ST auch nur in speziellen Anwendungen und nicht in der normalen Oberfläche. Aber den Grafikmodus finde ich nicht schlecht, weil er sehr flexibel ist.
Man könnte meinen, du bist Grafiker Die Frage ist doch nicht "Kann das auch Porn anzeigen?" sondern "welches Werkzeug ist für meine Aufgabe am besten geeignet?". Ich hänge mal zwei Bilder von typischen, textbasierten C64-Benutzeroberflächen an - das ist ressourcenschonend, übersichtlich und benötigt keine Zusatzhardware (...Maus). Da sicher niemand eine neue Videoschnittsoftware oder ein Büropaket entwickeln wird, wäre eine GUI doch totaler Overkill. Für dein Argument von wegen "einfach zu bedienen" brauche ich erst noch ein Beispiel, bevor ich es glaube...
Ich habe ja so einen Servant64, eine Ethernetschnittstelle für den C64 (Hardwarekosten waren was bei 20€, wenn ich mich recht entsinne).
Der benötigt Server-Software, die auf dem PC läuft - führt also sämtliche "einfach einschalten und loslegen"-Konzepte ad Abdsurdum,
Vielleicht auch ganz nett – aber nicht das, was ich mir wünschen würde. Mir wäre das etwas zu rudimentär – und einen wirklichen Nutzen kann ich darin auch noch nicht erkennen.
Der "Nutzen" wäre ein TCP-Standard, der (hoffentlich) diverse Lösungen und Plattformen unterstützt und auf möglichst vielen Rechner-Typen lauffähig ist - also hoffentlich möglichst viel Unterstützung erhält.
Na und ? Die alte Software bekommt durch das TC64 aber nunmal die Power die es eigentlich benötigt.
Durch meinen i7 auch - aber was hat das mit dem Plan zu tun, alte Software oder Hardware noch sinnvoll einzusetzen?
Den PDF Export hingegen könnte man wahrscheinlich eher noch hinkriegen,
Wäre immerhin etwas, würde den Datentransfer erleichtern.
Hab bis jetzt GW-Dokumente mit GeoDos nach PC konvertiert und dann auf den PC übertragen.
Mit PDF's wäre es leichter.
Der Witz ist ja, dass das heute einfacher ist, als in den vergangenen Jahren.
Da bin ich jetzt aber überrascht.
Hätte erwartet, dass es heute noch schwieriger ist.
Von daher sind wir umgeschwenkt auf eine "rein akademische" Diskussion ohne erhofften Nutzwert.
Ohne Nutzwert, würd ich nicht sagen.
Ob daraus was entsteht oder nicht, wird sich zeigen.
Gruss C=Mac.
Der benötigt Server-Software, die auf dem PC läuft
Das wäre aber kein "muss", zumindest nicht zwingend. Das ist halt an der Stelle etwas murksig konzipiert aber das ist kein Problem der Hardware an sich, soweit ich weiß.
Der "Nutzen" wäre ein TCP-Standard, der (hoffentlich) diverse Lösungen und Plattformen unterstützt und auf möglichst vielen Rechner-Typen lauffähig ist - also hoffentlich möglichst viel Unterstützung erhält.
Ich will dich da nicht ausbremsen. Kann man wahrscheinlich gut gebrauchen – aber ist jetzt für mich nicht so zentral. Man wäre dann da, wo Contiki schon ist, oder? Ich würde halt alles, was Speicher oder Rechenzeit frisst, auf Hardware auslagern, die man über sehr simple, meinetwegen proprietäre Protokolle anspricht. Dann hat der C64 seine Ressourcen frei, um ein GUI, einen Browser oder was auch immer darzustellen. Ich denke, es ist letztlich wurscht, ob das TCP-Prozokoll auf dem C64 gehandled wird (es darf halt nicht zuviel Ressourcen fressen) oder extern – toll, wenn es erstmal geht. Das ist aber nur ein Randbereich dessen, was man als Basis für neue C64-Anwendungen bräuchte.
Ich hänge mal zwei Bilder von typischen, textbasierten C64-Benutzeroberflächen an
Ja, sowas kenne ich. Wie gesagt, ich habe selbst schon textbasierte Oberflächen gestaltet und habe auch jahrelang mit C64 und DOS-Oberflächen gearbeitet. Eigentlich sind solche "DOS"-Oberflächen nichts, wo es mich wieder hintreibt. Modale Dialog-Orgien sind nicht so meines. Nicht ohne Grund haben sich grafische Oberflächen durchgesetzt. Es gibt sicher Fälle, wo die Overkill sind aber im Großen und Ganzen bringen sie die Bedienung von IT-Greräten voran.
Ich sehe ein, dass GEOS nicht immer optimal ist, was die Bedienung angeht, vor allem ohne richtiges Zusatz-Gerät. Es nervt z.B. kolossal, wenn man versuchen muss, mit einem Joystick einen Pfeil auf einen Button zu steuern, wenn man anderswo (in einem Text-Menü) einfach den Anfangsbuchstaben oder eine Zahl tippen kann – das sehe ich ein. Aber erstens ist ein Joystick eine echte Krücke, wenn es um GUIs geht und zweitens müssen sich die Konzepte nicht ausschließen. Eine Tastaturbedienung hat GEOS leider nicht wirklich implementiert, andere Oberflächen aber schon. Maus plus Tab-Sprünge zu den Buttons plus Tastaturkürzel – und schon wäre jeder glücklich.
Man könnte meinen, du bist Grafiker
Zufällig "ist" er Grafiker.
Durch meinen i7 auch - aber was hat das mit dem Plan zu tun, alte Software oder Hardware noch sinnvoll einzusetzen?
Die alte Hardware ist bereits am Limit und wenn man bei den Einschränkungen bleiben "möchte", braucht man in Sachen Geos gar nicht erst weitermachen.
Alte Software + alte Hardware bekommen durch die Zusatzhardware die Power, die es braucht, um mit dem Kram halbwegs vernünftig umzugehen. Oder findest
Du es toll bei der miesen Streifenansicht unter Geos Programme zu bedienen, die Ruckeln und verzögert reagiert ?
Geos an sich ist lange tot und das "Herum machen" ist lediglich Spielerei um zu sehen was geht. Um damit halbwegs vernünftig mit zu arbeiten, bedarf es neben
CPU Power und einer vernünftigen Laufwerksverwaltung neue gescheite Programme.
Gab es nicht sogar mal GEOS auf nem Prom/Eprom für die Hardcor-User
die den langsamen Start von Geos abkürzen wollten.
Da gab es das Modul namens GeoRom für den C64. Genaueres weiß ich dazu aber nicht. Mittlerweile hat jemand GEOS auch für EasyFlash angepasst. Link habe ich nicht zur Hand, war aber definitiv schon mal Thema hier im Forum.
Auch wenn TRW es vielleicht so meint, dass man quasi eine Über-Instanz mit einem GUI versehen sollte und nicht den realen C64 selbst, so säße man dann doch vor seinem C64, um etwas für das Gerät zu entwickeln.
Ich weiß auch nicht, ob ein besseres GEOS (oder ein Über-GEOS/TC/65) wirklich dazu führen würde, dass wieder "auf der Maschine für die Maschine" entwickelt wird – aber das wäre ja wenigstens schon mal ein konkreter Wunsch.
Den Begriff Über-Instanz find ich gut. Er beschreibt das was ich meine sehr gut.
Wenn es für eine solche GUI dann eine entsprechende Entwicklungsumgebung für den 64´er geben würde, wäre das genial. Ich würde es nutzen 
Alte Software + alte Hardware bekommen durch die Zusatzhardware die Power, die es braucht, um mit dem Kram halbwegs vernünftig umzugehen.
So ist es leider.
Nehmen wir mal die SCPU (hab leider nur die 64).
Wheels 128 80Z, ein Fenster verschieben:
- Anklicken -> Fenster wird abgebaut -> ein Rahmen wird gezeichnet, welcher sich an den Mauszeiger heftet -> Rahmen verschieben -> am neuen Ort los lassen -> Fenster wird neu aufgebaut
In der Zwischenzeit könnte man sich ein belegtes Brötchen machen.
Auf dem C64 mit SCPU, kriegt man von dem ganzen kaum was mit, flutscht einfach.
Oder die Startdauer, mit einer RamLink -> was für eine Startdauer? 
Wobei jede Hardware hatte auch wieder ihre Nachteile, wie z.B. Verfügbarkeit, Preis oder Kompatibilität.
Gruss C=Mac.
Das wäre aber kein "muss", zumindest nicht zwingend. Das ist halt an der Stelle etwas murksig konzipiert aber das ist kein Problem der Hardware an sich, soweit ich weiß.
Da der TCP- bzw. USB-Stack in der Hardware läuft, muss irgendwo eine "Gegenstelle" existieren - "C64 Userport" spricht sonst keine gängige Hardware. Keine Ahnung ob auf dem Servant64 noch genug Platz für so etwas vorhanden ist.
Das ist aber nur ein Randbereich dessen, was man als Basis für neue C64-Anwendungen bräuchte.
Wir haben offensichtlich unterschiedliche Vorstellungen davon, was Sinn machen würde.
Dir schwebt ein C64 vor, der mit Maus, CPU-Beschleunigung, zusätzlichem Speicher, Massenspeicher und einer intelligenten (sprich selbstständigen) TCP-Lösung ausgestattet ist und einen Outlook-Klon ausführt. Mir dagegen ein C64 mit einem TCP-Controller den er selbst ansteuert und der mit ein paar Sekunden Verzögerungen nach dem Einschalten im Textmodus nützliche Informationen anzeigt (Wetter? RSS-Feeds? anstehende Termine?), einfache Netzwerkspiele spielen kann und bei einer internetbasierten C64-BBS "anrufen" kann.
Ich glaube nicht, dass wir uns bei dem Thema irgendwie näher kommen
Modale Dialog-Orgien
Ich sehe ein, dass GEOS nicht immer optimal ist, was die Bedienung angeht, vor allem ohne richtiges Zusatz-Gerät. Es nervt z.B. kolossal, wenn man versuchen muss, mit einem Joystick einen Pfeil auf einen Button zu steuern, wenn man anderswo (in einem Text-Menü) einfach den Anfangsbuchstaben oder eine Zahl tippen kann – das sehe ich ein.
Wie ich bereits sagte: Man könnte meinen, du wärst Grafiker Offenbar würdest du gerne eine GUI designen, hast du etwa schon Mockups?
Sieh's doch mal so: Fensterrahmen brauche ich dank fehlendem Multitasking und wegen der geringen Auflösung nicht. Menüs bzw. Dialoge werden auf einem C64 ebenfalls immer modal sein und ob ich das (modale) Hauptmenü jetzt per Klick auf die Menüleiste herunterklappe oder per Funktionstaste aufrufe, schenkt sich in der Praxis nicht viel. Beim Scrollen halte ich Cursortasten und bspw. F1/F7 (für seitenweises Blättern) sogar für überlegen, Mausräder gibt's ja am C64 nicht.
Bei den Einsatzbereichen, die mir vorschweben - nennen wir sie mal "Viewer" im weitesten Sinne, plus vielleicht ein einfacher Texteditor und ein Dateimanager - bleiben dann für Mausbedienung gar nicht mehr so viel Einsatzmöglichkeiten. Von einer "flexiblen", weil HIRES-basierten Benutzeroberfläche ganz zu schweigen.
Wäre immerhin etwas, würde den Datentransfer erleichtern.
Hab bis jetzt GW-Dokumente mit GeoDos nach PC konvertiert und dann auf den PC übertragen.
Mit PDF's wäre es leichter.
On a second thought: Ich weiss nicht, wie realistisch so eine PDF Erstellung wäre und zwar aus folgendem Grund:
Bei Postscript wird das auszudruckende Dokument seitensweise berechnet, AFAIK beim PDF auch. Das und weil es eine Art Beschreibungssprache (also relativ viel Overhead) ist, hat zur Folge, dass die Dateien relativ gross werden können.
Ob das überhaupt Platz hat auf einer Diskette oder im Speicher?
Gut, bei GeoWrite oder GeoPublish wird im Wesentlichen eine ganze Page als Raster gesendet, das sind ja keine 8000x8000px, dann wird vermutlich noch etwas PS Pagedescription Code drumherumgeflanscht, wird dann evt. doch nicht so riesig werden.
Offenbar würdest du gerne eine GUI designen, hast du etwa schon Mockups?
Ich habe IMMER schon Mockups, zumindest im Kopf – ich denke halt in Bildern. Wenn mir jemand etwas über eine gewünschte Software erzählt, dann bekomme ich recht schnell eine Vorstellung davon, wie die dazu passende GUI oder Spielgrafik, die Figuren oder die 3D-Welt aussehen müssten. Oder jemand erzählt mir von seiner Firma und es bildet sich bei mir ein Vorstellung vom optimalem Corporate Design. Die Vorstellung ist natürlich noch vage und muss immer weiter verfeinert, auf Papier oder Bildschirm gebracht und getestet werden – aber ich habe früh ein Bild im Kopf. Anderen schwirrt vielleicht schon sehr früh Code im Kopf herum, oder Musik. Da kann ich auch nichts gegen tun – so funktioniert mein Hirn halt.
Wheels 128 80Z, ein Fenster verschieben:
- Anklicken -> Fenster wird abgebaut -> ein Rahmen wird gezeichnet, welcher sich an den Mauszeiger heftet -> Rahmen verschieben -> am neuen Ort los lassen -> Fenster wird neu aufgebaut
Das ist wohl ein Problem bei GEOS. Aber ich sagte ja auch, dass da noch Platz nach oben ist, was Optimierungen angeht. Die Frage ist doch: Braucht man bei 320 x 200 Pixeln wirklich verschiebbare Fenster? Haben z.B. iOS oder PalmOS skalierbare Fenster?
Wir haben offensichtlich unterschiedliche Vorstellungen davon, was Sinn machen würde.
Das würde ich so nicht sagen. Wir haben unterschiedliche Sichtweisen und fokussieren uns auf unterschiedliche Details des gleichen Problems. Wir würden beide gerne den C64 in eine Richtung bringen, die den "Nutzen" in der heutigen Zeit erhöht.
Mir dagegen ein C64 mit einem TCP-Controller den er selbst ansteuert und der mit ein paar Sekunden Verzögerungen nach dem Einschalten im Textmodus nützliche Informationen anzeigt (Wetter? RSS-Feeds? anstehende Termine?)
Das kann ich (bis auf Textmodus) unterschreiben. Nur sehe ich nicht, warum man das ganze nicht auch im Grafikmodus tun könnte. Ich glaube, der C64 kann das schaffen – und warum sollte man das nicht nutzen? Wenn man das eine MHz nicht ausnutzt, hat keine weitere Task etwas davon – also würde ich immer in die Vollen gehen. Dadurch wird auch nicht mehr Strom verbraucht.
Mir ist der Grafikmodus gar nicht so wichtig, wie es hier vielleicht erscheint. Ich kann auch ansprechende und funktionale UIs im Textmodus entwerfen (ich hoffe zumindest, dass z.B. das Tapecart-Browser-UI (inkl. Tastatur-Steuerung) so gesehen wird)
Mir geht es natürlich auch um die Attraktivität von Software – vieles steht und fällt mit ihr. Aber vor allem schätze ich die Flexibilität beim Bitmap-Modus. Ich möchte je nach Anwendung vielleicht mit 40, 64 oder sogar 80 Zeichen pro Zeile arbeiten – bei allem außer 40 streikt der C64-Char-Modus. Ich möchte vielleicht auch mal Programme (wie bei GEOS oder MacOS oder Windows oder Android) als Icons darstellen. Im Textmodus kostet mich das entweder haufenweise Chars oder ich bin nach 8 Sprites am Ende.
Aber klar, man muss das ja nicht tun wollen. DOS kam auch ohne Icons klar – aber wenigstens hatte man am PC 80 Zeichen (die ein C64 nur im Grafikmodus darstellen kann).
Ich würde sagen, deine Idee braucht den Textmodus nicht – sie ist komplett unabhängig vom Darstellungsmodus. Von daher sehe ich da keine Unvereinbarkeiten mit meinen Vorstellungen. Wir sehen beide: Der C64 muss schnell starten, er soll möglichst sofort sinnvolle Sachen anzeigen, er soll möglichst eine Online-Anbindung haben. Das könnte er erst einmal in jedem beliebigen Modus haben und tun.
Schön wäre halt irgendwas Vorkonfiguriertes auf einem EasyFlash-Modul zum Einstecken oder ein Image, das man einfach auf einen größeren Datenträger (SD-Karte) packen und dann einfach starten könnte.
Ich hab mir damals die Arbeitsdisketten eingerichtet, dann im Konfigurieren Menü alle Laufwerke abgemeldet und das System dann mit
Action Replay gefreezt und mit Warp gespeichert. Wenn ich dann mit GEOS "arbeiten" wollte hab ich meine georam eingesteckt und Geos
geladen. Im Konfigurieren Menü gelandet, Laufwerke angewählt Ram eingerichtet und los gings. Das war flotter als das Original gebootet.
Wie ich bereits sagte: Man könnte meinen, du wärst Grafiker
Ja, wie ich bereits bestätigte, aber wohl nicht ganz ankommt bei Dir :=)
Alles anzeigenSo ist es leider.Nehmen wir mal die SCPU (hab leider nur die 64).
Wheels 128 80Z, ein Fenster verschieben:
- Anklicken -> Fenster wird abgebaut -> ein Rahmen wird gezeichnet, welcher sich an den Mauszeiger heftet -> Rahmen verschieben -> am neuen Ort los lassen -> Fenster wird neu aufgebaut
In der Zwischenzeit könnte man sich ein belegtes Brötchen machen.
Auf dem C64 mit SCPU, kriegt man von dem ganzen kaum was mit, flutscht einfach.
Oder die Startdauer, mit einer RamLink -> was für eine Startdauer?
Wobei jede Hardware hatte auch wieder ihre Nachteile, wie z.B. Verfügbarkeit, Preis oder Kompatibilität.
Gruss C=Mac.
Ich hab hier ein nettes Beispiel für die lahme Gurke Printmaster:
