Neues OS für C64 (mit Zeichensatz-UI)

  • Retrofan schrieb:

    Naja, ich bin nicht der einzige, den dein ewiges "mit dem TC64 ist alles besser" ein wenig nervt. Und du hast die Kritik daran ja auch schon öfters lesen dürfen.
    ...ja ich weiss. Der böse Ace mal wieder. So kann man natürlich auch eine Diskussion ohne Argumentation abwürgen, ohne mal darauf einzugehen, warum gerade
    ein Programm wie Godot nicht als Framework taugen soll.
    :winke: Wie C64 an TFT? :winke:
    :king: Fulgore ist President! :king:
  • Eben noch getestet: Hatte keine Probleme mit der Maussteuerung in GoDot (in VICE).

    Ich hab ja in dem anderen Thread bereits meine Wünsche/Vorstellungen zu einem neuen OS beschrieben. Mich würde da mal brennend interessieren, was von diesen Wünschen GoDot bereits kann, was mal eben umgesetzt werden könnte, was mit deutlichem Aufwand möglich wäre und was man gleich mal vergessen sollte.

    Hier nochmal die Liste:

    1. Schnelles, unkompliziertes und am besten automatisches Starten des OS -> also als Modul und ich fänd EF am besten.
    2. Offenes Treibermodell um möglich viel Hardware zu erkennen und zu unterstützen (mir reicht eigentlich Punkt 3 und 4).
    3. Unterstützung für 1531 Maus (wenn möglich auch gleich noch ein paar andere).
    4. Unterstützung für 15xx-Laufwerke, IECATA und SD2IEC.
    5. Starten von Programmen.
    6. Integrierte DOS-Funktionen: Kopieren (Dateien und Disketten/Images), Verschieben, Löschen, Umbenennen (am besten gleich ein DIR-Editor), ...7. Punkt 6 bitte per Drag'n'Drop
    8. Datei-Viewer/Player für möglichst viele Formate.
    9. Starten von OS spezifischen Programmen (OS Erweiterungen). Nicht alles, was jetzt noch kommt, muss zwingend fest im OS-Image stecken. Wenn möglich gibt man in einer Konfiguration an, auf welchem LW und wo diese Erweiterungen zu finden sind. Das OS verlinkt gefundene Erweiterungen beim Start und Datenträgerwechsel automatisch.
    10. PIM-Funktionen: Kalender, Adressbuch, ??? (Könnten z.B. zusammen mit ihren Daten auf einem Massenspeicher liegen)
    11. Optisch ansprechend (das Bild von TSB unten auf deiner Seite fand ich schon OK)
    12. BASIC-Editor mit Scrollbalken, Syntax Highlighting, Auto-Zeilennummern, Suchfunktion, ... Für echte Programmierer vielleicht auch ein integrierter Assembler?
    Netzwerk-Funktionalität:
    a) TELNET-Client (SSH wäre noch besser)b) SNTP-Client (damit wird der Kalender brauchbar)
    c) Einen OS spezifischen Suchdienst, der andere C64 (mit diesem OS) im Netzwerk findet.
    d) Ein OS spezifischer Text-Chat
    e) Ein OS spezifischer Datei-Sender/Empfänger
    f) Warpcopy-Client/Server (oder vergleichbares) zum Übertragen von ganzen Disketten zu und von einem PC oder einem anderen C64 mit diesem OS
    g) SMTP-Client (E-Mails verschicken)
    h) Der "Browser" (über den hier im Forum geträumt wird) als OS-Erweiterung nachladbar
    i) Wetter Gadget
    j) C64-Client und Android-Server App um vom C64 über WLAN eine SMS verschicken zu können
    k) C64-Server und Android-Client App um Notifikations des Telefons am C64 anzeigen zu lassen!
    l) Fitz.Box CallMonitor (C64-Server um eingehende Anrufe anzuzeigen).
  • Korodny schrieb:

    Drop-Down-Menüs kann GoDot auch nicht, aber das entspricht ja fast schon wieder modernen Design-Prinzipien ;) Irgendein Dropdown-Gadget o.ä. wäre aber schon sinnvoll, meine ich.
    Ich habe mal das 64Net Copy angeheftet. Ist ein gutes Beispiel wie man eventuell Dateien unter Godot kopieren könnte. Die Auswahlbox
    könnte ich mir neben der Mausbedienung auch als schnelle Tastaturauswahl vorstellen.
    Bilder
    • netcopy.gif

      10,31 kB, 640×400, 44 mal angesehen
    :winke: Wie C64 an TFT? :winke:
    :king: Fulgore ist President! :king:
  • Ich hab mir mal ein bisschen Gedanken gemacht: meiner Meinung nach müssten die folgenden drei Punkte umsetzbar sein, wenn man ein Aufbohren von Godot überhaupt in Betracht ziehen wollte:
    1. Dateiauswahlrequester mit Unterstützung für Partitionen und Verzeichnisse. Bereits hier Kompromisse machen zu müssen (separates Modul, d.h. Verzeichnis- und Partitionswechsel nur außerhalb des Dateiauswahlrequesters) würde m.E. einen Fork oder einen Neuanfang sinnvoller erscheinen lassen
    2. Godot braucht einen Mechanismus, um beim Bildaufbau "einen Schritt zurück gehen" zu können. Ich vermute ein solcher Mechanismus existiert bisher nicht - weil es ja nur ein Hauptfenster gibt, das sehr einfach aufgebaut ist und nach dem Schließen eines Zusatzfensters einfach wieder neu gezeichnet werden kann. Wenn man aber beliebige Anwendungen starten will, sollte man eventuell den aktuellen Bildschirminhalt zwischenspeichern können (bzw. das sollte transparent erledigt werden), bevor man ein zusätzliches Fenster öffnet - damit man das Backup wieder zurück kopieren kann, wenn das Zusatzfenster geschlossen wird.
    3. Kleineres Problem: Man müsste einen globalen "Systempfad" (LW, Partition und Verzeichnis) o.ä. definieren können, in dem GoDot immer nach seinen eigenen Dateien sucht - damit ich die IFF-Bilder auf Partition 3 mit diversen Modifiern bearbeiten und in diversen Formaten speichern kann, ohne jedes Mal auf Partition 1 wechseln zu müssen wenn ich einen anderen Saver oder einen anderen Modifier nutzen will.


    D.h. man müsste den Renderer auslagern, die Bildbearbeitung würde ihn dann nur laden wenn er benötigt wird und müsste ihn gleich hinterher wieder durch den OS-Code ersetzen. Ist das eine realistische Option?

    Gibt es irgendwo eine Memory Map für Godot? Muss mal in den TIefen des Forums suchen gehen.
  • Also ich finde es schon mal sehr gut, wenn das hier alles so weit wie möglich weg geht von den Versuch alles unbedingt in eine grafische Oberfläche zu zwängen.
    Die vielen nützlichen Tools rund für den Cevi machen das doch auch nur ganz schlicht und erfüllen somit ihren Zweck "gut".
    Sie sind im Normalfall alle auf den Punkt gebracht, wozu man sie braucht, nicht mehr und nicht weniger.
    Und so sollte meiner Meinung nach auch eine Basis für ein Benutzer"unterstützendes" OS für den C64 sein. Am besten noch ganz unauffällig wartend unter dem Direkt-Modus.


    GoDot schrieb:

    Und da bringt GoDot schon allerhand mit: Hardware-Erkennung beim Booten, Zugriff auf verschiedenste Laufwerke, Dateimanager, Kopierprogramm, Erweiterbarkeit, RAMDisk-Nutzung, viel Platz (wenn keine Bilder bearbeitet werden, sind plötzlich fast 42 KB frei...)
    Das sind schon mal alles super Sachen auf die es ankommt und man sollte damit dann jegliche Betriebssystem Hardware-Erweiterung, ob alte oder neue ins System auf Wunsch einhängen oder ausblenden können. Und diese dann auch noch zusammen crossover praktisch verwenden und damit arbeiten zu können.
    Und auch wenn GoDot schon eine solche solide Basis hat, würde ich mir trotzdem noch etwas anderes Wünschen, was das ganz unauffällig seine Dienste zeigt.
    So zusagen das ich nicht immer zwangsweise in dem System drin stecke, sondern das es nur abrufbar ist, wenn ich es brauche, dem Rest sollte es im Hintergrund sein.


    ZeHa schrieb:

    Was ich mir vorstellen koennte, waere dass das System das bietet, was einem heute ein Emulator alles so bietet. Also das bequeme Mounten von D64-Images (im SD2IEC), das Hin- und Herkopieren solcher, das Freezen und Speicher-Debuggen, usw. Also alles, was ein Emulator einem heute so "Drumherum" um das eigentliche System bietet. Wenn man sowas auf einem Modul haette, dann koennte man sicherlich ganz anders mit seinem C64 arbeiten.
    Das wär natürlich klasse und dazu ist bisher (Neben an im Thread) glaube ich auch noch gar keine Reaktion gekommen.
    Dazu sollte man auch die Ressourcen der neueren und exklusiveren Hardware (wie Chameleon & U1541) ausreizen.
    Wäre mit dessen Reserve-Speicher eine Art "Multitasking" für das System möglich? Das man gleich zwischen verschiedenen Programmen umschalten kann.
    Natürlich brauchen die nicht Zeitgleich laufen, aber ein Switchen von einem Tool zum anderen, wäre genial.


    Korodny schrieb:

    Dummerweise erkennt GoDot unter VICE meine Maus nicht, Joystick-Benutzung ist grausam
    Joystick-Bedienung ist echt grausam und dann immer extra eine Mouse am Cevi angeschlossen zu haben, ist aber auch nicht meines.
    Für mich wäre eine schlichte Coursor-Bedienung oder Unterstützung in den Menüs schon das aller feinste. Einfach schlicht und schnell.



    Das die Meinungen hier und in dem anderem OS-Thread teilweise stark auseinander gehen, hab ich vernommen,
    aber ich würde es mir für mich halt so in etwa vorstellen und wollte jetzt auch nur meine Sicht kund tun.
    Und keine Angst jetzt (aus Mangel an Programmier-Kunst) fange ich auch nicht an, meine Vorstellung umzusetzen.
    Hebt man den Blick, so sieht man keine Grenzen
  • Maus und Joystick Steuerung darf es schon sein...das sollte auch das kleinste Problem sein. Oder Halt Wahlweise.

    Cyberdyne schrieb:

    Eben noch getestet: Hatte keine Probleme mit der Maussteuerung in GoDot (in VICE).

    Ich hab ja in dem anderen Thread bereits meine Wünsche/Vorstellungen zu einem neuen OS beschrieben. Mich würde da mal brennend interessieren, was von diesen Wünschen GoDot bereits kann, was mal eben umgesetzt werden könnte, was mit deutlichem Aufwand möglich wäre und was man gleich mal vergessen sollte.

    Hier nochmal die Liste:

    1. Schnelles, unkompliziertes und am besten automatisches Starten des OS -> also als Modul und ich fänd EF am besten.
    2. Offenes Treibermodell um möglich viel Hardware zu erkennen und zu unterstützen (mir reicht eigentlich Punkt 3 und 4).
    3. Unterstützung für 1531 Maus (wenn möglich auch gleich noch ein paar andere).
    4. Unterstützung für 15xx-Laufwerke, IECATA und SD2IEC.
    5. Starten von Programmen.
    6. Integrierte DOS-Funktionen: Kopieren (Dateien und Disketten/Images), Verschieben, Löschen, Umbenennen (am besten gleich ein DIR-Editor), ...7. Punkt 6 bitte per Drag'n'Drop
    8. Datei-Viewer/Player für möglichst viele Formate.
    9. Starten von OS spezifischen Programmen (OS Erweiterungen). Nicht alles, was jetzt noch kommt, muss zwingend fest im OS-Image stecken. Wenn möglich gibt man in einer Konfiguration an, auf welchem LW und wo diese Erweiterungen zu finden sind. Das OS verlinkt gefundene Erweiterungen beim Start und Datenträgerwechsel automatisch.
    10. PIM-Funktionen: Kalender, Adressbuch, ??? (Könnten z.B. zusammen mit ihren Daten auf einem Massenspeicher liegen)
    11. Optisch ansprechend (das Bild von TSB unten auf deiner Seite fand ich schon OK)
    12. BASIC-Editor mit Scrollbalken, Syntax Highlighting, Auto-Zeilennummern, Suchfunktion, ... Für echte Programmierer vielleicht auch ein integrierter Assembler?
    Netzwerk-Funktionalität:
    a) TELNET-Client (SSH wäre noch besser)b) SNTP-Client (damit wird der Kalender brauchbar)
    c) Einen OS spezifischen Suchdienst, der andere C64 (mit diesem OS) im Netzwerk findet.
    d) Ein OS spezifischer Text-Chat
    e) Ein OS spezifischer Datei-Sender/Empfänger
    f) Warpcopy-Client/Server (oder vergleichbares) zum Übertragen von ganzen Disketten zu und von einem PC oder einem anderen C64 mit diesem OS
    g) SMTP-Client (E-Mails verschicken)
    h) Der "Browser" (über den hier im Forum geträumt wird) als OS-Erweiterung nachladbar
    i) Wetter Gadget
    j) C64-Client und Android-Server App um vom C64 über WLAN eine SMS verschicken zu können
    k) C64-Server und Android-Client App um Notifikations des Telefons am C64 anzeigen zu lassen!
    l) Fitz.Box CallMonitor (C64-Server um eingehende Anrufe anzuzeigen).

    Der Liste kann ich mich nur anschließen.
  • Ace schrieb:

    Ist ein gutes Beispiel wie man eventuell Dateien unter Godot kopieren könnte.
    Da gefällt mir das eigentliche Kopiermodul besser:



    Korodny schrieb:

    Godot braucht einen Mechanismus, um beim Bildaufbau "einen Schritt zurück gehen" zu können.
    Den hat es meiner Meinung nach. Jeder Requester besteht aus einem Record, der festlegt, was wo wie (Buttons, Beschriftungen) erscheinen soll und welche Dinge dort getan werden können (nennt sich ScreenList), er hat einen definierten Aufruf und er wird definiert wieder verlassen. Danach übernimmt der vorherige Requester die Steuerung, zum Schluss der Startbildschirm. Verschachtelungen hab ich bisher entweder über den Stack oder per Requester-Tabelle geregelt (Liste von Aufrufvektoren). Wiederholte Selbstaufrufe eines Moduls regelt ein Diskriminator-Flag (alles Nachgeladene in GoDot läuft an $c000, der Execution Area, wird ansatzweise auf der Homepage erläutert).

    Cyberdyne schrieb:

    3. Unterstützung für 1531 Maus (wenn möglich auch gleich noch ein paar andere).
    Ja. Maus 1351. Joystick und Tastatur sind parallel gleichzeitig aktiv und wenn nötig nutzbar. Mit dem Joystick geht's nach meinem Dafürhalten eigentlich ganz gut. Nur Tastatur ist eher was für den Notfall. (Keine Shortcuts.)

    Cyberdyne schrieb:

    4. Unterstützung für 15xx-Laufwerke, IECATA und SD2IEC.
    Ja. Einschließlich CMD jeder Art. IECATA glaub ich nicht, SD2IEC muss ausprobiert werden, sieht in der Beschreibung so aus, als wenn das so lufen würde.

    Cyberdyne schrieb:

    5. Starten von Programmen.
    Sowas lässt sich immer einbauen.

    Cyberdyne schrieb:

    6. Integrierte DOS-Funktionen: Kopieren (Dateien und Disketten/Images), Verschieben, Löschen, Umbenennen (am besten gleich ein DIR-Editor),
    Siehe oben. Ein DIR-Editor ist eine gute Idee! Hab ich wieder was zum Basteln, hehe... ;)


    Cyberdyne schrieb:

    8. Datei-Viewer/Player für möglichst viele Formate.
    Ein Erkennungsmechanismus für Formate ist ja schon mal da: FileType.

    Zum Rest sag ich später was, muss jetzt was anderes machen.

    Arndt
    GoDot C64 Image Processing
    www.godot64.de
    GoDot on Github
  • GoDot schrieb:

    Den hat es meiner Meinung nach. Jeder Requester besteht aus einem Record, der festlegt, was wo wie (Buttons, Beschriftungen) erscheinen soll und welche Dinge dort getan werden können (nennt sich ScreenList), er hat einen definierten Aufruf und er wird definiert wieder verlassen.
    Aber das funktioniert ja nur, weil bisher keiner der Requester, der eventuell überdeckt werden könnte, etwas anderes als GUI-Widgets (oder eventuell einen Verzeichnisinhalt?) enthält - oder?

    Wenn wir von einer universellen Benutzeroberfläche ausgehen, muss ja auch der Fall abgedeckt werden, dass ein Requester vor einem Texteditor voller handgeschriebenem Text eingeblendet wird, oder beispielsweise vor deinem Dir-Editor (etwa weil ich ein geiles Dir-Logo erstellt habe und das abspeichern will). Solche Daten müsste dann das Programm selbst zwischenspeichern, oder verstehe ich das falsch?
  • Wow .. I like it! :thumbup:

    Nebenbei meine Meinung:
    Mit einem Oldtimer (C64) fährt man nicht beim Formel-Eins-Rennen (modernes grafisches OS-GUI) mit, auch wenn man evtl. einen Ferrari V12 (SuperCPU) irgendwie dranfrickelt. Eine schöne Oldtimerrallye oder eine Sonntagsausfahrt ist der richtige Einsatzzweck.

    Es muss nicht 1:1 wie Windows aussehen und bedienbar sein, es soll seinen Zweck als OS ("Operating System" - sic!) erfüllen und nicht zum Selbstzweck oder als Machbarkeitsstudie (schön aber schnarchlangsam) dienen. Sch**ß auf Proportionalschrift und WYSIWYG. Die Liste von Cyberdyne bringt es auf den Punkt.

    Just my 2 cents.

    P. S.: Als "Windows"-Taste dient "C=" und das Startmenü ziert das C=-Logo? :)
    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten."
    (Quelle unbekannt)

    "Lege dich nie mit einem Idioten an! Er zieht dich auf sein Niveau hinunter und schlägt dich dann mit seiner Erfahrung!"
    (Volksmund)
  • GoDot schrieb:

    Nein, korrekt. Bei jedem Rücksturz in die vorherige Screenlist musst diese dann neu aufgebaut werden. Aber: Ist das überhaupt ein Problem?
    "Problem" ist ein großes Wort, aber dass ein Anwendungsentwickler nach jedem Requester selbst noch mal einen Screen-Refresh besorgen und sich dabei ggfs. um eigene Inhalte selbst kümmern muss, fände ich zumindest unglücklich - so etwas sollte zentral gelöst werden. So wie ich GEOS verstehe, setzt man dort darauf dass immer nur eine Anwendung läuft, und zwar als Vollbild. Davor kann maximal ein Requester (weil modal) angezeigt werden, es reicht also ein Backup des Screens um den Ursprungszustand zuverlässig wiederherzustellen. Das müsste doch auch hier umsetzbar sein, das wären IMHO zwei gut angelegte KB.

    GoDot schrieb:

    Hier mal ein Schnellschuss, was das Aussehen angeht:
    Hehe, sehr schön ;)

    Allerdings würde ich mich Kinzis Meinung anschließen und nicht sklavisch Konzepte aus dem PC-Bereich übernehmen - ein C64 hat deutlich weniger Platz auf dem Schirm, also statt den Schirm mit zusätzlichen Buttons zu füllen würde ich mir was anderes einfallen lassen. Ich kann mich nicht erinnern, ob Godot die rechte Maustaste genutzt hat - ich meine nicht (mein Mausproblem besteht noch, ist aber ein VICE-Problem unter Linux). In dem Fall würde ich den rechten Mausknopf zum Menü-Knopf umdefinieren, der zu jedem Zeitpunkt ein von der aktuellen Anwendung zu definierendes bzw. ergänzendes Menü mittig auf dem Bildschirm anzeigt. Die Punkte "GoDos" (Info zur Anwendung, "Hilfsmittel" laden (analog zu GEOS), direkt zu anderer Anwendung wechseln, Anwendung beenden) und falls nötig "Datei" wären immer drin, den Rest ergänzt die Anwendung.

    Soll das rechts oben ein Systray sein?
  • GoDot schrieb:

    Ich hab's mal umbenannt. Ist ja kein OS, sondern nur ein UI
    Ui! :) Mag korrekt sein, ist aber maximal unsexy. goDos klingt doch super! Und das "go to" im "Startmenü" ist auch angenehmer als "U&I will ..." Dann lieber eine Info-Box oben rechts aufklappbar, in der nur ein Satz steht: "goDos ist eine UI für ... " oder so.
    Greetings, Starfighter. You have been recruited by the Star League to defend the frontier against Xur and the Ko-Dan armada.


    Kilobyte Magazine - The PDF-Mag for everything 8bit
    KBMag on Twitter
    KBMag on Facebook
  • Zu den DOS-Funktionen hätte ich noch fragen. Das klingt ja recht zuversichtlich von dir Arndt aber kann man auch schon:
    - Unterverzeichnisse erstellen/löschen/umbenennen
    - Image-Dateien (D64, D71, D81, ...) erstellen/löschen/umbenennen
    - wenn man in ein Image gewechselt hat (es gemountet hat), dieses Image und nicht die kpl. Karte formatieren
    - Diskcopy von einer Diskette in ein Image und umgekehrt (SD2IEC ist ja keine 1541U und emuliert nicht alles)
    - innerhalb eines Laufwerks (z.B. SD2IEC) von einem Verzeichnis oder Image in ein anderes Verzeichnis oder Image kopieren oder verschieben

    Schön wäre die Ansicht von Quell- und Ziel-Laufwerk/Verzeichnis/Image und Funktionalität wie bei Copy64 (oder heißt es 64Copy?). Halt Funktionalität an NortonCommander angelehnt aber aufgehübscht und (auch) per Maus steuerbar.

    PS: Der Startbutton ist schon zu sehen aber wo ist die Startleiste mit Uhr und laufenden Programmen und so? ;) ;) ;)