Hallo Besucher, der Thread wurde 111k mal aufgerufen und enthält 953 Antworten

letzter Beitrag von Retrofan am

Neues OS/GUI für den C64

  • 1. Welche Anwendungen brauchen/wollen wir eigentlich?

    Die gleiche Frage stelle ich seit Monaten aber anscheinend wollen einfach zu wenige überhaupt etwas mit ihrem C64 machen – außer spielen und Demos gucken. Das ist auch vollkommen ok und deshalb mache ich mir keine großen Hoffnungen mehr, dass ein neues System eine große Anhängerschaft finden würde, selbst wenn es gut wäre. (Vielleicht lockt mein Pessimismus ja doch noch ein paar Leute aus ihren Ecken) ;)


    Was ich persönlich mit einem neuen OS machen wollen würde: Ich würde damit gerne Programme und Daten verwalten, die auf unterschiedlichen Datenträgern herumliegen (also kopieren, verschieben, umbenennen, löschen, öffnen, starten ....), das wäre also der klassische Desktop. Dann würde ich gerne diverse Informationen in Widget-Form sehen, wie Datum, Uhrzeit (gerne auch als Bildschirmschoner), Kalendereinträge (syncbar über Caldav), abonnierte Feeds, Notifications (z.B. aus dem Forum hier). Dann wären ein paar kleine Tools, wie Taschenrechner, Notizen etc. ganz schön. Einen eingebauten Viewer für Texte und Bilder (C64-Formate) fände ich auch nicht schlecht. Als größere App würde ich mir eine Textverarbeitung wünschen, die Markdown unterstützt. Damit könnte man formatierte Texte, weil man gerade bock darauf hat, mit dem C64 vor-schreiben und am PC weiterverarbeiten (dafür sollte dann auch für Umlaute etc. ISO 8859-15 o.ä. unterstützt werden und nicht PETSCII). Witzig (aber nicht unbedingt notwendig) fände ich eine Art Mini-PowerPoint, mit dem man sehr einfach Präsentationen und Ankündigungen für Retro-Computerteffen machen könnte, die dann vor Ort per Beamer angezeigt werden.


    Der einzige Vorteil (wenn man das so nennen will, angesichts der damit verbundenen Nachteile) war WYSIWYG - aber "Drucken" ist in 2017 kein sinnvoller Anwendungsbereich für einen C64.

    Richtig, WYSIWYG ist nicht mehr in der Art vonnöten, wie es früher mal war, da eh kaum noch gedruckt wird (selbst am PC). Wichtiger ist heute ein reibungsloser Datenaustausch, daher Unterstützung von SD-Karten-Lösungen und WiFi/LAN. Mit dem C64 wird man nur selten direkt etwas ausgeben, sondern eher zu einem anderen Gerät übertragen und dann weiterverarbeiten, gegebenenfalls auch darüber drucken.


    Also entwickeln "wir" entweder einen Webbrowser, oder ein neues Betriebssystem - beides gleichzeitig dürfte mit der Zielsetzung "keine teure Zusatzhardware" kaum machbar sein.

    Ich bin auch nicht dafür, hier Betriebssystem und Browser zu verschmelzen, sondern würde das als zwei komplett unabhängige Projekte und Programme ansehen, die sich höchstens ein wenig Optik und Bedienungsphilosophie teilen.


    E-Mail fällt auch weg, da ein C64 nicht genug CPU-Ressourcen für eine sichere Übertragung mitbringt (von den Datenmengen ganz zu schweigen: die drei neuesten Mails in meinem Posteingang haben Größen von 14, 21 und 64 KB).

    Richtig, sichere Übertragung = Verschlüsselung ist hier das KO-Argument für den C64. Wenn es auf Sicherheit nicht ankäme (und bisher hat ja auch kaum jemanden gestört, dass eMails ungeschützt über die Leitungen gingen), könnte man sich einen speziellen iMAP-Mail-Server oder Webmailer vorstellen, von dem sich der C64 die eMail-Texte in kleinen Häppchen abrufen könnte.


    ein einfaches Manifest ("Ergonomische, einheitliche Benutzerführung in einer C64-Anwendung") und eventuell ein paar vorgefertigte, freie Bibliotheken (I/O-Routinen mit Unterstützung für beliebige Laufwerke/Partitionen etc. mit komfortabler DOS-Wedge? Mausunterstützung? Cursor-Menüs? Zugriff auf den TCP-Stack?) aus denen ein Programmierer rauspicken kann was er braucht, würden da m.E. schon reichen.

    Ich sehe das durchaus als Alternative für größere Programme an. Also, dass die GUI- und anderen Funktionen nicht geshared werden, sondern man Bibliotheken zur Verfügung stellt, die die Entwickler in ihre Produkte einbauen können. Die einzigen Nachteile, die sich darüber ergeben, wären längere Ladezeiten (vernachlässigbar beim easyFlash) und die Tatsache, dass man bei einem Betriebssystem-Update die neuen APIs auch in die bestehenden Programme kompilieren müsste. Ich glaube aber nicht, dass wirklich große Systemupdates ohne Anpassung bestehender Apps vonstatten gingen, von daher wäre auch das egal. Dafür würde man evtl. RAM sparen, weil nur nötige Routinen im Programm stecken würden. Zwischenablage könnte man notfalls über Massenspeicher/RAM-Disk abwickeln, sodass sogar C&P möglich wäre, ohne dass sich System und Programm den Speicher teilen müssten.


    Ja, aber solche Stacks sind aus Sicht eines C64 ja nur ein Modem oder Nullmodem, richtig? D.h. sofern nicht für jeden Dienst ein extra Proxy für die C64-Anwender geschrieben wird, ginge damit nur Telnet/SSH - also Mailboxen "anrufen".

    Ich meine, gesehen zu haben, dass HTTP-Zugriffe auf Webserver möglich sind.

  • @ Ace


    Wenn jemand starten wollen würde und ihm eventuell Geld dafür fehlt er aber beispielsweise eine Croudfounding Kampagne oder ähnliches starten will ( oder Patreon oder dergleichen ) wäre ich durchaus bereit dies zu unterstützen. Ich wäre auch einer der ersten der so was kaufen würde zu einem gerechtfertigtem Preis.

  • Ich denke das ganze Vorhaben hat die gleichen Probleme wie der Browser, nur noch in staerkerer Ausfuehrung: Das Verhaeltnis zwischen Aufwand und Nutzen, genauer gesagt: Es sind beides ziemliche Mammutprojekte (und zwar allein schon aus der Tatsache heraus, dass man nicht einfach drauflos coden kann, sondern dass man staendig im Hinterkopf behalten muss, dass alles moeglichst flexibel bleiben sollte, damit das auch in ein paar Jahren noch Relevanz hat und erweitert werden kann), und die Anzahl der potentiell tatsaechlichen Nutzer scheint letztendlich sehr gering. Mit tatsaechlichen Nutzern meine ich mehr, als das Ding zu kaufen und 2-3x zu starten und zu zeigen wie toll es ist, sondern dass es eben WIRKLICH genutzt wird.


    Diese beiden Dinge stehen hier meiner Meinung nach in einer sehr unguenstigen Relation, weswegen vermutlich die meisten Coder nicht "hier!" schreien. So zumindest meine Einschaetzung. Wenn man nun aber an diesem Verhaeltnis schrauben kann, und es sich abzeichnet, dass auch mit wenig Aufwand bereits ein guter Start hingelegt werden kann, und auf der anderen Seite, dass es tatsaechlich reale Anwendungszwecke fuer das gesamte Projekt geben koennte, dann kann sich das natuerlich aendern.

  • Nö. Das war zu dieser Zeit passend und daher mit der heutigen Zeit auch nicht wirklich zu vergleichen.

    Ich sprach von GOS (Atari XL/XE), nicht von GEOS. GOS ist von 2015, kopiert aber ein GUI von 1984.


    - Wozu taugt Geos heutzutage noch und mit welch Anwendungen hätte der heutige Benutzer einen Vorteil ?
    Vorteile: Anwendungen schon vorhanden

    Mein Problem damit ist, dass die meisten GEOS-Programme entweder versuchen, GEOS zu pimpen (was mit einem komplett neuen System erstmal nicht nötig wäre) oder aber Anwendungsfälle abdecken, die Leute vor 20 oder 30 Jahren hatten. Die meisten Programme nützen also nicht mehr viel.


    Was meint ihr genau ?

    Wir sprachen von Contiki.


    Sowas haben bereits einige Leute versucht. Nannte sich "Clips", später"Wings".

    Wings benötigt eine SuperCPU. Die ist noch seltener und teuerer als das TC64. kein Wunder, dass das niemand genutzt hat.


    Würde ich jetzt nicht unbedingt behaupten. Wenn das MK3 und die neue Charge an TC64 heraus kommt, werden die Karten eh neu gemischt.

    Wenn es dann nur noch die Hälfte kostet, könnte ich dir sogar beipflichten. Aber bislang wurde das TC doch bei jedem neuen Release sogar teurer. Also von daher glaube ich nicht daran, dass sich die Userbase stark vergrößern wird.


    Ich bin aber gar nicht nur wegen des Preises gegen das TC64 als Grundvoraussetzung, sondern eher, weil ich finde, dass das cheaten auf hohem Niveau ist. Dann können wir auch gleich sagen, wir lassen das ganze auf dem C64 und warten auf den Mega65.


    Warum also nicht möglich viel Ram nutzen, was ja eh in der Ultimate und dem TC64 steckt und bei Bedarf auf Turbo und Co. zurück greifen ?

    Du hast mich wohl falsch verstanden. Ich bin überhaupt nicht gegen die Nutzung von mehr RAM und mehr MHz. Ich möchte es nur nicht als Mindestvoraussetzung haben. So, wie alle anderen Programme schneller werden, wenn man den TC64-Turbo startet, so kann auch das neue OS schneller werden. Aber dafür muss ich das nicht als zwingend voraussetzen. Toll, wenn man sowas hat – aber es soll auch ohne gehen.


    Du möchtest Powerhardware ausgrenzen ?

    Wie gesagt, das ist nicht der Fall und das habe ich auch nie gesagt. Ganz im Gegenteil: DU willst Geräte ohne Powerhardware ausgrenzen!


    Wird der FIBR eigentlich noch weiter entwickelt ?

    Wurde schon oben beantwortet.


    Ich hatte hierzu Godot ja vorgeschlagen. Es ist in seiner jetzigen Form ein gutes Beispiel, was man mit modularer Software alles machen kann. Dazu ist es super dokumentiert und lässt sich in jeder Richtung problemlos erweitern.

    Godot ist ein Grafikkonverter. Was hat das mit einem OS zu tun? Photoshop ist auch modular und trotzdem würde ich daraus kein OS bauen wollen.

  • Ich denke das ganze Vorhaben hat die gleichen Probleme wie der Browser, nur noch in staerkerer Ausfuehrung: Das Verhaeltnis zwischen Aufwand und Nutzen, genauer gesagt: Es sind beides ziemliche Mammutprojekte (und zwar allein schon aus der Tatsache heraus, dass man nicht einfach drauflos coden kann, sondern dass man staendig im Hinterkopf behalten muss, dass alles moeglichst flexibel bleiben sollte, damit das auch in ein paar Jahren noch Relevanz hat und erweitert werden kann), und die Anzahl der potentiell tatsaechlichen Nutzer scheint letztendlich sehr gering. Mit tatsaechlichen Nutzern meine ich mehr, als das Ding zu kaufen und 2-3x zu starten und zu zeigen wie toll es ist, sondern dass es eben WIRKLICH genutzt wird.


    Diese beiden Dinge stehen hier meiner Meinung nach in einer sehr unguenstigen Relation, weswegen vermutlich die meisten Coder nicht "hier!" schreien. So zumindest meine Einschaetzung. Wenn man nun aber an diesem Verhaeltnis schrauben kann, und es sich abzeichnet, dass auch mit wenig Aufwand bereits ein guter Start hingelegt werden kann, und auf der anderen Seite, dass es tatsaechlich reale Anwendungszwecke fuer das gesamte Projekt geben koennte, dann kann sich das natuerlich aendern.

    Das ist durchaus ein Argument ZeHa. Aber manche erschaffen einfach auch etwas manchmal nur aus einem Grund : Weil Sie es können :D:D:D


    Nein im ernst, mir und allen anderen dürfte bewusst sein, dass solch ein Projekt mal nicht eben nebenbei Programmiert werden kann. Es ist auch schon was anderes als ein kleine Spielchen. Damit sind jetzt keineswegs Deine gemeint, die ich zum einen sehr gut finde und zum anderen die Leistung auch nicht herabsetzen möchte.

  • Ich denke halt, diejenigen Programmierer, die sowas wirklich drauf haben, die wissen gleichzeitig auch, wie gross der Aufwand WIRKLICH ist ;) weil sie halt auch sofort an die zig Punkte denken, an die ein "Durchschnitts-Programmierer" vielleicht nicht sofort denkt. Und aus diesem Grund sinkt dann halt auch gleich die Motivation, sowas wirklich anzugehen :) (im Hinblick darauf, dass es dann am Ende kaum einer einsetzt natuerlich)

  • Zitat

    Mein Problem damit ist, dass die meisten GEOS-Programme entweder versuchen, GEOS zu pimpen (was mit einem komplett neuen System erstmal nicht nötig wäre) oder aber Anwendungsfälle abdecken, die Leute vor 20 oder 30 Jahren hatten. Die meisten Programme nützen also nicht mehr viel.

    Ein Grossteil der Anwendungen fallen sogar schon bei dem neuen Geos "Megapatch" und "Wheels64" weg, da bereits integriert. Meiner Meinung nach
    wären diese beiden Versionen überhaupt der Ansatzpunkt, wenn man Geos anpassen möchte.


    Zitat

    Wings benötigt eine SuperCPU. Die ist noch seltener und teuerer als das TC64. kein Wunder, dass das niemand genutzt hat.

    Dennoch der Ansatz sowas aufzubauen. Ausserdem zeigt es sehr gut, dass man , egal was für ein OS man denn auch aufbauen möchte, auf externer Hardware angewiesen ist. Gerade auf Ramerweiterungen kommst Du so gut wie nicht drum herum. Wings wäre eventuell ein Ansatz und liesse sich vielleicht auf anderer Hardware anpassen. Der SuperCPU Einsatz wird sich da wahrscheinlich eh nur aufs Ram beschränkt haben. Doku fliegt irgendwo auch noch rum.
    Vielleicht kann Chester dazu was sagen...


    Zitat

    Wenn es dann nur noch die Hälfte kostet, könnte ich dir sogar beipflichten. Aber bislang wurde das TC doch bei jedem neuen Release sogar teurer. Also von daher glaube ich nicht daran, dass sich die Userbase stark vergrößern wird.
    Ich bin aber gar nicht nur wegen des Preises gegen das TC64 als Grundvoraussetzung, sondern eher, weil ich finde, dass das cheaten auf hohem Niveau ist. Dann können wir auch gleich sagen, wir lassen das ganze auf dem C64 und warten auf den Mega65.

    Mega65 wäre ein Argument was ich verstehen würde. Solange aber nicht real zu kaufen, beschränken wir uns doch auf die Hardware, die so zum Einsatz kommt.

    Zitat

    Du hast mich wohl falsch verstanden. Ich bin überhaupt nicht gegen die Nutzung von mehr RAM und mehr MHz. Ich möchte es nur nicht als Mindestvoraussetzung haben. So, wie alle anderen Programme schneller werden, wenn man den TC64-Turbo startet, so kann auch das neue OS schneller werden. Aber dafür muss ich das nicht als zwingend voraussetzen. Toll, wenn man sowas hat – aber es soll auch ohne gehen.


    Ja, dazu bedarf es aber Software, die eben minimal- und Maximalhardware erkennt und auch unterstützt. Wie man sowas umsetzen könnte, hat der PC ja unter Dos bereits in den Anfangszeiten gezeigt.


    Zitat

    Wie gesagt, das ist nicht der Fall und das habe ich auch nie gesagt. Ganz im Gegenteil: DU willst Geräte ohne Powerhardware ausgrenzen!


    Ich möchte mal Fortschritt in der Software erleben. Es wurde lang genug auf 1 Mhz und popeligen 16 Farben herum geritten und sich jegliche externe Hardware wie zB. der REU oder der 1581 verweigert. Mittlerweile ist genug optimierte c64 Software unterwegs und man könnte ja mal "langsam" auch etwas in die andere Richtung machen, ohne gleich dabei seinen Geldbeutel oder seine Frau als Grund vorzuschieben, warum das ausgerechnet nicht sein sollte.



    Zitat

    Godot ist ein Grafikkonverter. Was hat das mit einem OS zu tun? Photoshop ist auch modular und trotzdem würde ich daraus kein OS bauen wollen.

    Godot kann viel mehr als nur Grafik. Es hat Module für 64Net Copy, CMD Echtzeituhr, einen Spriteeditor und einiges mehr. Dazu ist das System super dokumentiert und läuft problemlos von jede Art von Datenträgern. Eben, weil es sich beliebig konfigurieren lässt.
    Ich bin mir sicher, dass sich das Grundgerüst von Godot mit der Dokumentation nutzen lässt , um daraus ein modulares OS zu bauen.

  • Die gleiche Frage stelle ich seit Monaten aber anscheinend wollen einfach zu wenige überhaupt etwas mit ihrem C64 machen – außer spielen und Demos gucken.

    Den Eindruck habe ich auch, echten Bedarf scheint niemand zu haben. Daraus müsste man jetzt noch die richtigen Schlüsse ziehen ;)


    Was ich persönlich mit einem neuen OS machen wollen würde: Ich würde damit gerne Programme und Daten verwalten, die auf unterschiedlichen Datenträgern herumliegen (also kopieren, verschieben, umbenennen, löschen, öffnen, starten ....), das wäre also der klassische Desktop.

    Ein Desktop kann das nicht leisten, dazu sind die Aufgaben auf einem C64 zu vielfältig. Dazu nimmt man eine Reihe spezialisierter Anwendungen, die dann ihre jeweilige Aufgabe optimal erledigen: File-Copy, Disk-Copy, FastFormat, DirWizard, D64/ZipDisk Creator, D64/ZipDisk Extractor, Unlynx... Diese Anwendungen existieren bereits alle.


    Dann würde ich gerne diverse Informationen in Widget-Form sehen, wie Datum, Uhrzeit (gerne auch als Bildschirmschoner), Kalendereinträge (syncbar über Caldav), abonnierte Feeds, Notifications (z.B. aus dem Forum hier). Dann wären ein paar kleine Tools, wie Taschenrechner, Notizen etc. ganz schön. Einen eingebauten Viewer für Texte und Bilder (C64-Formate) fände ich auch nicht schlecht.

    Alles "nice to have", wenn man bereits ein OS und einen Anwendszweck für dieses OS hat ;)


    könnte man sich einen speziellen iMAP-Mail-Server oder Webmailer vorstellen, von dem sich der C64 die eMail-Texte in kleinen Häppchen abrufen könnte.

    Ähm, nein. Wer bereit ist seine privaten Mails durch den Proxy eines Drittanbieters zu leiten, verdient einfach keinen C64-Mailer.


    Ich sehe das durchaus als Alternative für größere Programme an. Also, dass die GUI- und anderen Funktionen nicht geshared werden, sondern man Bibliotheken zur Verfügung stellt, die die Entwickler in ihre Produkte einbauen können. Die einzigen Nachteile, die sich darüber ergeben, wären längere Ladezeiten (vernachlässigbar beim easyFlash) und die Tatsache, dass man bei einem Betriebssystem-Update [...]

    Nix "Betriebssystem-Upgrade". Die Bibliotheken wären der Ersatz für ein neues Betriebssystem. Beides zusammen macht ja nun gar keinen Sinn, zumindest nicht auf einem C64.


    Zwischenablage könnte man notfalls über Massenspeicher/RAM-Disk abwickeln, sodass sogar C&P möglich wäre, ohne dass sich System und Programm den Speicher teilen müssten.

    Kein neues Betriebssystem, keine Zwischenablage, kein Task-Switching.


    Ich meine, gesehen zu haben, dass HTTP-Zugriffe auf Webserver möglich sind.

    Oh? Muss mich mal zu den Dingern ein bisschen schlau machen.


    Godot ist ein Grafikkonverter. Was hat das mit einem OS zu tun? Photoshop ist auch modular und trotzdem würde ich daraus kein OS bauen wollen.

    Godot bringt eine 'graphische' (Textmodus) Benutzeroberfläche sowie eigene Laufwerks- und Eingabe-Treiber mit, ist also beinahe so viel OS wie GEOS. Nur das nicht in einen Desktop gebootet wird, sondern in den Grafikkonverter.

  • Meiner Meinung nach wären diese beiden Versionen überhaupt der Ansatzpunkt, wenn man Geos anpassen möchte.

    Kann sein. Nur sehe ich nicht, warum man das tun sollte. Da ist meines Erachtens doch zu viel Legacy-Kram drin. Und wenn man den rauswirft, hat man wahrscheinlich eine Handvoll Grafikroutinen übrig, die man selber schneller selbst programmieren kann. Ich sehe da keinen Ansatzpunkt ( ... mehr, nach dem 1. langen Thread)


    Ausserdem zeigt es sehr gut, dass man , egal was für ein OS man denn auch aufbauen möchte, auf externer Hardware angewiesen ist.

    Ich sehe das doch selbst so. Externe Hardware ist nötig – nur möchte ich den Einstieg möglichst niedrig ansetzen. Erstens, weil es cooler ist und zweitens, weil das (über den kleineren Preis) die mögliche Userbase größer hält.


    Gerade auf Ramerweiterungen kommst Du so gut wie nicht drum herum.

    Das sehe ich anders. Die Programme, die andere und ich genannt haben, benötigen gar nicht viel RAM – und GeoPublish wollen wir ja nicht mehr. Wenn man Programmteile schnell aus den EasyFlash holen kann, kann man eine Menge des RAMs für Daten freihalten. Und wer eine REU oder einen C128 hat, der soll natürlich auch davon profitieren – nur, wie sonst auch: Ich würde es nicht voraussetzen wollen.


    Mega65 wäre ein Argument was ich verstehen würde.

    Den finde ich genau so uninteressant, wie das TC64. Da kann man dann auch gleich Amiga-Software programmieren.


    Ja, dazu bedarf es aber Software, die eben minimal- und Maximalhardware erkennt und auch unterstützt.

    Ja, das sollte ein modernes OS tun.


    Ich bin mir sicher, dass sich das Grundgerüst von Godot mit der Dokumentation nutzen lässt , um daraus ein modulares OS zu bauen.

    Ist mir eigentlich egal, meinetwegen kann der Programmierer auch Hi-Eddi oder Koala-Paint als Basis nehmen, wenn er darin Routinen findet, die er gebrauchen kann. Wenn irgendwer Bock hat, ein neues OS für den C64 zu proggen, wird er schon die richtigen Werkzeuge kennen oder finden. Ich glaube aber eher nicht, dass Godot die perfekte Grundlage für ein OS wäre – aber dazu kann uns sicherlich der Entwickler etwas mehr sagen.

  • Den Eindruck habe ich auch, echten Bedarf scheint niemand zu haben. Daraus müsste man jetzt noch die richtigen Schlüsse ziehen

    Ja, ich neige ja auch langsam dazu. Ist halt schade. Ich würde es nutzen – aber einer oder zwei sind halt nicht genug. (Wobei ich immer noch ein wenig auf eine "schweigende Mehrheit" hoffe)


    Ein Desktop kann das nicht leisten, dazu sind die Aufgaben auf einem C64 zu vielfältig.

    Warum sollte ein Desktop nicht die üblichen Desktop-Tasks machen können? Solange sich die Massenspeicher einigermaßen sauber ansprechen lassen (die meisten zwar nicht nativ, sondern nur in Form von D64 und Co.), sollte das doch lösbar sein.


    Diese Anwendungen existieren bereits alle.

    ... und machen keinen Spaß. Der Vorteil einer grafischen Oberfläche ist doch der, dass das alles mehr oder weniger selbsterklärend ist.


    Alles "nice to have", wenn man bereits ein OS und einen Anwendszweck für dieses OS hat

    Ich sehe die Gesamtheit als Anwendungszweck. Oder kurz zusammengefasst: Der C64 als PIM (Personal Information Manager), kombiniert mit einem Datei-Multitool und Programm-Launcher. Wenn einem das als "Zweck" nicht reicht, dann braucht man auch kein Smartphone. Das ist das gleiche, nur in mobil und schnell und modern.


    Wer bereit ist seine privaten Mails durch den Proxy eines Drittanbieters zu leiten, verdient einfach keinen C64-Mailer.

    Mag sein, störte aber die Millionen (Google-) Mail Nutzer jahrelang kein bisschen. Mails waren immer auf allen Mailservern klartextlich lesbar und Google hat daraus sogar ein Geschäftsmodell geformt.


    Nix "Betriebssystem-Upgrade". Die Bibliotheken wären der Ersatz für ein neues Betriebssystem. Beides zusammen macht ja nun gar keinen Sinn, zumindest nicht auf einem C64.

    Jein. So, wie ich es geschildert habe, wäre das Betriebssystem keines mehr (da hast du recht), sondern der Desktop/Laucher/Widget-Player. das wäre halt eine Anwendung, die dann gegebenenfalls Programme mit der gleichen Codebasis starten würde. Die mehrfach verwendeten Codeteile müsste man also mehrfach updaten, falls nötig.


    Oh? Muss mich mal zu den Dingern ein bisschen schlau machen.

    Wenn du schlauer bist, dann bitte ich auch um Infos. Ich habe das alles auch erst überflogen, weil die Infos in verschiedenen Threads stecken.


    Godot bringt eine 'graphische' (Textmodus) Benutzeroberfläche

    Das wäre dann auch auch schon das KO-Kriterium für mich. Ich würde mir eine grafische Oberfläche (ohne Anführungsstriche), wie bei GEOS, wünschen – nur halt moderner.

  • Warum sollte ein Desktop nicht die üblichen Desktop-Tasks machen können? Solange sich die Massenspeicher einigermaßen sauber ansprechen lassen (die meisten zwar nicht nativ, sondern nur in Form von D64 und Co.), sollte das doch lösbar sein.

    Sicher ist das lösbar, aber nicht vom Desktop selbst Die genannten Programm (UnzipDisk, Unlynx...) müssten alle neu implementiert werden - und dein theoretisches OS müsste in der Lage sein, beim Start von Anwendungen auch Parameter mit zu übergeben, damit der Desktop Unlynx aufrufen und ihm gleichzeitig Sourcefile und Zieldirectory mitgeben kann.


    ... und machen keinen Spaß. Der Vorteil einer grafischen Oberfläche ist doch der, dass das alles mehr oder weniger selbsterklärend ist.

    Alle C64-Anwendungen haben eine Benutzeroberfläche, der C64 ist ja im Gegensatz zu MS-DOS oder Unix kein Kommandozeilen-basiertes System. Und das hier...

    Zitat

    F1 - Set source device
    F3 - Set target device
    F5 - Settings
    F7 - Backup disk

    ...ist eine absolut "selbsterklärende" Benutzeroberfläche. Es mach keinen Sinn, die komplette Software noch mal neu zu schreiben (und dabei 28 KB Speicher im Klo herunterzuspülen) nur damit du mit der Maus klicken kannst anstatt F1 zu drücken.


    Das wäre dann auch auch schon das KO-Kriterium für mich. Ich würde mir eine grafische Oberfläche (ohne Anführungsstriche), wie bei GEOS, wünschen – nur halt moderner.

    Schon klar. Das ist vermutlich ein verbreitetes Leiden bei Grafikern :D

  • Ich sehe, du hast kein Interesse an einem grafischen Betriebsystem à la GEOS, nur eben aus dem neuen Jahrtausend. Das ist ja nicht schlimm, ich frage mich aber, was dich antreibt, hier mitzumischen? Ich habe verstanden, dass du weder der Meinung bist, dass man für die gewünschten Tasks ein neues OS benötigt (man kann das ja mit 20 kleinen Progrämmchen auch alles machen), noch dass ein grafisches (meint Bitmap-) GUI irgendwie Sinn macht (F-Tasten tun ja das gleiche).


    Ich sehe, obwohl ich das Thema nicht angestoßen habe, aber durchaus Potential. Wenn andere keine Wünsche formulieren können/mögen – ich habe welche genannt und kann mir Lösungen dafür in einem einheitlichen G-OS auf einer 1 MHz-Kiste durchaus vorstellen. Vielleicht stehe ich damit weitgehend allein – dann habe ich eben Pech gehabt. Die Wahrscheinlichkeit, einen Programmierer zu finden, der Zeit, die gleichen Ansichten und die Skills hat, das umzusetzen, stehen ohnehin unglaublich schlecht. Von daher mache ich mir ohnehin keine Hoffnungen, dass die Sache irgendwie realisiert wird. Trotzdem fand ich die Diskussion, bis auf ein paar nutzlose Einwürfe, ganz interessant und erfrischend.

  • @Korodny Ich habe gerade nochmal im alten Thread nachgesehen. Die ersten Einträge dort sind ja auch schon ein paar Tage alt. Da warst du auch schon ganz efrig und wolltest mir Textmenus mit F-Tastenbedienung (als ob ich das nicht kennen würde) und einen TCP/IP-Stack (der in WiFi-Adaptern schon drinsteckt) verkaufen, während ich ein modernes GEOS (bedeutet für mich: grafisches Betriebssystem) präferierte. Jetzt wurde (gegen meinen Wunsch) hier ein neuer Thread mit dem Titel "Neues OS/GUI" aufgemacht und du hast nichts besseres zu tun, als weiter gegen GUIs zu wettern – obwohl GUIs hier DAS Thema sind – und nicht textbasierte Bedienung, F-Tasten oder Progrämmchen, die im Textmodus arbeiten. Ich muss es dir leider sagen: Du bist hier falsch.

  • Ohne jetzt alles ins Detail gelesen zuhaben.


    Was ist eigentlich die Aufgabe oder der Sinn eines Grafischen-OS?


    Aus meiner Sicht:
    Das bedienen des Computers zu vereinfachen bzw. überhaupt zu ermöglichen, jedenfalls für normal doofe Anwender wie mich :rolleyes:


    Nehme mal ein Beispiel:


    Das SD2IEC hat viel Speicher und Möglichkeiten, z.B. das verwenden verschiedener Images.


    Wenn ich in einen Ordner/Image wechseln will kann ich das mit JiffyDos relativ einfach, Befehl: @cd:Name.
    Ohne JD wird die Sache schon komplizierter: open und hab hier wird es schon kompliziert.
    Ein Grafisches-OS soll die Sache noch weiter vereinfachen, ich brauch gar kein Befehl zu kennen.
    Ich sehe es, ich kann es einfach anklicken, denn Rest erledigt die Software.


    Das ganze kann eigentlich GEOS schon, nur nicht mit neueren Hardware.


    Wheels und MP3 können wenigstens mit CMD-Hardware umgehen, unterstützen den Native-Mode der jeweiligen Geräte.
    Wheels kann auch Verzeichnis erstellen, bei MP3 ist ein Zusatzprogramm von Nöten.


    Mit neuerer Hardware (SD2IEC, Easyflash, Ultimate etc.) sieht es auch bei denen Mau aus.
    Man kann zwar mit rick dem jeweiligen OS eine Floppy/HD vorgaukeln, aber ein direkter Zugriff ist nicht möglich.


    Somit ist auch das kopieren/verschieben zwischen den verschiedenen Datenträger nicht möglich.


    Und das ist das was ich am meisten vermisse.


    Ein neues OS, oder auch Anpassungen der Bestehenden, sollte dies ermöglichen.
    Jedes LW optimal unterstützen.


    Die Frage dabei, was ist als Ressource Voraussetzung?
    Wieviele LW werden mind. benötigt, wieviel zusätzliches RAM, welcher Speed?


    Welche Programme wären zusätzlich nötig?


    Eigentlich das schon gesagte: Internet, Mail, Reeder, Office-Paket wird auch nötig sein (so ein OpenOffice auf em C64/128 :D ) etc.


    Was überhaupt mit der alten Maschine machbar ist, ist eine andere Frage.


    Gruss C=Mac.

  • ich frage mich aber, was dich antreibt, hier mitzumischen?

    Die Bemerkung ist ziemlich daneben. Dass Voraussetzung zur Teilnahme an der Diskussion der absolute Wille zu einer im Hires-Modus implementierten GUI ist, hat niemand erwähnt - insofern nehme ich mir das Recht heraus, gegen eine solche Hires-GUI zu argumentieren.


    Ich habe verstanden, dass du weder der Meinung bist, dass man für die gewünschten Tasks ein neues OS benötigt

    Ich habe lediglich illustriert, dass du direkt nach dem OS gleich noch 5-10 Anwendungen portieren bzw. aufgrund der rechtlichen Situation neu schreiben müsstest, nur um deine gewünschte Desktop-Funktionalität zu erhalten - Funktionalität die bereits in vielfacher Ausführung und über Jahrzehnte gereift zur Verfügung steht. Wer soll das alles programmieren - und mit welcher Motivation? Der von dir genannte Grund war - überspitzt ausgedrückt - "ich will klicken, nicht F1 drücken", das reicht m.E. nicht.


    Nur mal so als Brainstorming: Ein paar existierende Programme aus dem Bereich "Dateimanagement" zu patchen, so dass sie sich in der Bedienung und im Aussehen ähneln, von einem gemeinsamen "Starter" aufgerufen werden und auch wieder dorthin zurück wechseln können, wäre dagegen beispielsweise eine machbare Aufgabe, die die Ergonomie deutlich verbessern und den C64 optimal ausnutzen würde. So etwas verstehe ich unter "modern" oder "Software-Evolution" (auch wenn's jetzt mit Betriebssystemen nichts zu tun hat).


    noch dass ein grafisches (meint Bitmap-) GUI irgendwie Sinn macht (F-Tasten tun ja das gleiche).

    Ich habe zu meiner aktiven C64-Zeit sowohl GEOS als auch Godot aktiv benutzt bzw. zu nutzen versucht. In meinen Augen hat GEOS bewiesen, dass der C64 mit einer HIRES-GUI überfordert ist. Mit der SCPU war's dann erträglich - aber dann ist einem sehr schnell aufgefallen, wie arm an Funktionalität die GEOS-Anwendungen tatsächlich waren.


    kann mir Lösungen dafür in einem einheitlichen G-OS auf einer 1 MHz-Kiste durchaus vorstellen.

    Hast du denn Erfahrungen mit graphischen Betriebssystemen auf 8-Bit-Rechnern?

  • @ C=Mac


    Was wünschenswerte die Voraussetzung wäre wurde ja bereits geschrieben. Am besten die Basisausstattung ( C64, Floppy, Joystick ). Damit sollte das "OS" funktionieren. Wobei das ganze mit EasyFlash halt am meisten Sinn machen würde. Jede zusätzliche Hardware würde dem System nur mehr Leistung und weitere Eigenschaften geben. Für Online Geschichten brauch es dann natürlich die passende Zusatzhardware.

  • Zur Klarstellung:

    Godot ist ein Grafikkonverter. Was hat das mit einem OS zu tun? Photoshop ist auch modular und trotzdem würde ich daraus kein OS bauen wollen.

    GoDot ist weder ein Grafikkonverter noch ein OS. Es ist schlicht eine Benutzeroberfläche.


    Praktischerweise ist es modular angelegt, so dass es eigentlich keine Anwendungsidee geben dürfte, die nicht mittels GoDot auf den Bildschirm gebracht werden könnte. Beispiele: Minesweeper, Textreader, Kopierprogramm (übrigens für beliebig große Files), CMD-Geräte-Navigator, Uhr (wie schon erwähnt), Datei-Erkennungstool, Druckertreiber. Dass der ganze Rest sich mit Grafik beschäftigt, ist halt mein besonderes Interesse (und es gibt da viel zu tun...)

    Ich glaube aber eher nicht, dass Godot die perfekte Grundlage für ein OS wäre – aber dazu kann uns sicherlich der Entwickler etwas mehr sagen.

    Grundlage für ein OS. Hm. Es erkennt beim Start automatisch alles, was angeschlossen ist, und bindet das ein. Und was nicht erkannt wird, lässt sich nachträglich ins System einklinken, siehe das Prinzip der Devices. Nein, es ist kein OS. Es ist eine Benutzeroberfläche. "Grafisch", aber auf Zeichenbasis (wegen der Geschwindigkeit). Diese Art von Grafik für diesen Zweck reicht mir. Es soll schließlich nur dazu dienen, nicht alles wissen zu müssen, damit man etwas tun kann. Es zeigt an, was man tun kann, und zwar genau das und nicht mehr. Bedienbar ist es gleichzeitig mit Maus, Joystick oder Tastatur. Allerdings sind die Fenster modal (sie sind nicht bewegbar).


    Tja...


    Arndt

  • Zur Klarstellung:
    GoDot ist weder ein Grafikkonverter noch ein OS. Es ist schlicht eine Benutzeroberfläche.
    Praktischerweise ist es modular angelegt, so dass es eigentlich keine Anwendungsidee geben dürfte, die nicht mittels GoDot auf den Bildschirm gebracht werden könnte. Beispiele: Minesweeper, Textreader, Kopierprogramm (übrigens für beliebig große Files), CMD-Geräte-Navigator, Uhr (wie schon erwähnt), Datei-Erkennungstool, Druckertreiber. Dass der ganze Rest sich mit Grafik beschäftigt, ist halt mein besonderes Interesse (und es gibt da viel zu tun...)

    Ganz genau. Daher hatte ich es auch als besonderes Beispiel gebracht, gerade weil es so universell erweiterbar ist. Gerade die damals erhältlichen Erweiterungen zu CMD Geräten und/oder Drucker (HP Deskjet, Epson und Bubblejet) haben doch gezeigt, wie universell sich das Programm an neue Hardware anpassen lässt.

    Zitat

    Grundlage für ein OS. Hm. Es erkennt beim Start automatisch alles, was angeschlossen ist, und bindet das ein. Und was nicht erkannt wird, lässt sich nachträglich ins System einklinken, siehe das Prinzip der Devices. Nein, es ist kein OS. Es ist eine Benutzeroberfläche. "Grafisch", aber auf Zeichenbasis (wegen der Geschwindigkeit). Diese Art von Grafik für diesen Zweck reicht mir. Es soll schließlich nur dazu dienen, nicht alles wissen zu müssen, damit man etwas tun kann. Es zeigt an, was man tun kann, und zwar genau das und nicht mehr. Bedienbar ist es gleichzeitig mit Maus, Joystick oder Tastatur. Allerdings sind die Fenster modal (sie sind nicht bewegbar).
    Tja...


    Arndt

    Gerade die Oberfläche auf Zeichenbasis macht doch einiges her wie ich finde. Das sich die Fenster nicht bewegen lassen, vermisst man hier nicht wirklich.

  • Man koennte doch die Gelegenheit nutzen und die Sache mal rumdrehen, und @GoDot fragen, wie er den Aufwand einschaetzt, ein voellig neues grafisches OS aus der Taufe zu heben? Vermutlich hat er einen relativ guten Ueberblick ueber dieses ganze Vorhaben.