Hello, Guest the thread was viewed43k times and contains 313 replies

last post from steril at the

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

    Ich lese beide Threads mit allerhöchstem Interesse. Bei GoDot waren wir davon ausgegangen, dass es das Beste wäre, wenn wir uns vollkommen auf das mitgebrachte OS einlassen, denn dann kann man ja nichts verkehrt machen. Hat auch bisher so hingehauen. Sogar unsere REU-Einbindung "übersetzt" die Directorydaten so, dass sie C=-konform sind und vom Filerequester so hingenommen werden. Jetzt höre ich (ich kenne es nicht und habe auch noch nichts dazu gelesen, das kommt noch), dass das EF anders funktioniert. Sollte das tatsächlich so sein, dann ist das mit dem Einbinden gegessen. Da wäre der Overhead mehr als das das ganze goDos umfasst. Dann müsste ich Cyberdyne enttäuschen...


    Arndt

    Quote from Cyberdyne

    Wie gesagt: Der andere "Neues OS" Thread hat zur Zeit das gleiche Thema. Ich glaube, du verstehst nur nicht, wie ich es meine. Und leider bin ich mir ziemlich sicher, dass es an meiner Erklärung liegt. In dem Thread wurde es verständlicher erklärt.

    Sie wollen Daten aus dem EF-Rom nachladen. Das ist exakt das, wovon ich spreche - ich nenne es einfach nur virtuelles Dateisystem. Exakt so wie dort beschrieben wäre das auch unter goDos machbar - ich sage schlicht, dass ich den Aufwand für unzulässig halte. M.J. sieht das offenbar anders, das ist sein gutes Recht. Aber ich hab mich jetzt genug übers EasyFlash ausgelassen, für mich war's das mit dem Thema.



    Quote from GoDot

    Jetzt höre ich (ich kenne es nicht und habe auch noch nichts dazu gelesen, das kommt noch), dass das EF anders funktioniert.

    Laut Programming Manual blendet das EasyFlash einfach ein oder zwei 8KB-RAM-Bänke (von bis zu 7 MB) bei $8000/A000 ein, das kannst du über zwei oder drei Register bei $DExx steuern. Es gibt alternativ auch ein Tool, das ganze Disks samt passendem Lader in zwei Dutzend solcher Bänke unterbringt, die (heftigen) Einschränkungen dieses zweiten Ansatzes sind im C64-Wiki beschrieben.

    Quote from Korodny

    M.J. sieht das offenbar anders

    Nee, der sieht das schon ähnlich wie Du mit einem Unterschied: Nachdem es nun nicht mehr darum geht, Module per Hot-Plugin direkt auf dem Rom aufzurufen, sondern allein, Dateien vom Rom ins Ram zu kopieren, wird die Sache erheblich einfacher. Wofür man in der Tat sorgen muß, ist,
    - alle Routinen, die das Rom betreffen, auf eben diesem auszulagern (Rom Bank 1 bietet sich an) und nur bei Bedarf ins Ram zu kopieren, damit diese ansonsten keinen Platz verbrauchen. Dazu gehört z. B. auch die Routine, die das Dateisystem der EasyFlash umwandelt in das, was von GoDos verlangt wird (C=-konform),
    - der EasyFlash eine bestimmte Gerätenummer zuzuordnen, anhand der das System erkennt, daß es jetzt auf EasyFlash umschalten muß. Der Code dafür sollte aber nicht so aufwendig sein. Einem auf EasyFlash gepatchtes GoDos sollte das keine Probleme bereiten.

    Quote from M. J.

    Wofür man in der Tat sorgen muß, ist,- alle Routinen, die das Rom betreffen, auf eben diesem auszulagern (Rom Bank 1 bietet sich an) und nur bei Bedarf ins Ram zu kopieren

    Hm... mir kommt gerade erst, dass man sich das mit dem ins RAM kopieren bei goDos eventuell sogar schenken kann, da das Ausführen von ROM-Code in den betroffenen Bereichen unter goDos kein Problem sein sollte. Damit würde sich der Platzbedarf für die EF-Unterstützung tatsächlich dramatisch verringern: EF-Zugriff erkennen, ROM einblenden, EF-spezifische Version von LOAD/OPEN/etc. ausführen, ROM ausblenden.


    Wäre allerdings immer noch reichlich Arbeit - und Read-Only wär's auch. Ich bleibe dabei: wer einen Massenspeicher will, soll sich einen kaufen ;)

    Quote from Korodny

    Ich bleibe dabei: wer einen Massenspeicher will, soll sich einen kaufen

    Ich habe Massenspeicher in allen Formen und Farben. Was ich gerne hätte ist Geschwindigkeit (und am besten Autostart). Gibt es da was schnelleres als ein Modul?
    Wird eigentlich bei den REU Emulationen von TC64 und 1541U auch der ROM-Sockel emuliert?


    Sehr schade! Trotzdem wünsche ich viel Erfolg!

    Quote from Cyberdyne

    Was ich gerne hätte ist Geschwindigkeit (und am besten Autostart).

    Bisher gehe ich eigentlich davon aus, dass das erreichbar ist, meinetwegen als Cartridge oder so. Ein Boot-Loader, der das System nach Reset wieder hochzieht, und gut.


    Wie ihr merkt, lebe ich noch. Zum Beweis meine letzten Taten:



    Dies hier ist die Standard-Ansicht mit einem Panel. Die Angaben der Dateilängen fehlen noch (kommt als nächstes). Oben die beiden Reiter für das Quelllaufwerk, wenn sie gehilightet sind, ist das der momentan aktive Drive, hier Drive 8, Disk "godos 1.0" (ohne ID, aber mit Kennung 2a). Unten am Fußreiter (oder wie sagt man da?) weitere Informationen zur Disk (525 blocks free) und zum Drive (eine 1541). Der Scrollbalken ist ebenfalls noch eine reine Hier-bin-ich-Anzeige (die aber ihre Funktion - das Scrollen - bereits erfüllt). Von den Buttons unter der Drivenummer (linke Button-Spalte) funktionieren bis auf "Run" alle wie sie sollen. Die Kringel in den Drive-Reitern erläutere ich beim nächsten Screenshot:



    Die sind nämlich für die Drive-Auswahl, oben für den Source-Drive, unten für Destination. Klickt man auf einen Kringel, erscheint das Auswahlfenster (das schon im FileCopy drin war), der jeweils (src oder dst) zugeordnete Drive ist hervorgehoben, klickt man auf eine andere Drivenummer, ist dieser Drive ausgewählt (und dessen Directory wird sofort angezeigt). Source ist hier Drive 8 (gerade aktiv), Destination Drive 9 (noch inaktiv, wenn ich die 9 in der Auswahlbox anklicke, ist dieser Drive aktiv und wird gehilightet). Im Screenshot wurde der Doppelpfeil nach oben geklickt, was das zweite Panel hervorholt und das obere Panel verkleinert. Im zweiten Panel steht nur der Name der Destination-Disk und der darauf verbleibende Platz (plus Drivetyp). Diese Anzeige ändert sich nur, wenn man einen anderen Destination-Drive anwählt (oder das Panel wieder ausschaltet mit dem Doppelpfeil nach unten).


    Ich bleibe hier dabei, dass ich - anders als im FileCopy - nur mit einem Dateifenster arbeite. Ich finde, es reicht, wenn man darüber informiert ist, welche Zieldisk einliegt und wie viel Platz dort noch ist. Den Inhalt kann man sich ja jederzeit mit dem Destination-Reiter rechts unten zeigen lassen. Zu dieser Einstellung gehört auch, dass nur auf der Quelldisk Dateien ausgewählt werden können, nicht auf der Zieldisk, es geht also immer nur in eine Richtung (genau wie bei FileCopy). Letzter Screenshot:



    Hier sieht man das Tagging mit Unterlegung. Die angewählte Datei wird oben und unten in den Reitern näher beschrieben (hier "sys.Explorer", 15 blocks lang, eine PRG-Datei) . In diesem Screenshot wurde auch noch der Info-Button betätigt und das System-Info-Fenster eingeblendet, das die genauen Daten des Moduls auswirft. Hier beachtet bitte, dass die Beschränkung der Modullänge auf 3500 Bytes wie unter GoDot aufgehoben ist, ein Modul kann jetzt problemlos 4 KB lang werden. Dazu ist der goDos-Kernel geändert worden. Ebenso enthält Slot4 inzwischen völlig andere Funktionen als unter GoDot (z.B. Screen-Caching und die Drive-Auswahl).


    Die Buttons "APPs" und "MODs" funktionieren ebenfalls. Mit ihnen wählt man ebendiese per File-Requester aus, wobei ich app.4BitViewer jetzt so verändert habe, dass die Grafik-Renderroutinen ihre gerenderten Farben nicht mehr abspeichern (das schafft eben die 500-soundsoviel Bytes mehr pro Modul). Als MODs taugen alle GoDot-Module mit einem System-Punkt als Kennzeichen (wie bei "mod..FileCopy"). Beide Typen (APPs und MODs) werden noch über den Hauptschirm aktiviert (soll aber anders werden). Die übrigen Buttons (außer Exit) sind noch ohne Funktion).


    Als nächstes also (wie gesagt) die Dateilängen (aber auch nur jeweils auf dem Quelldrive) und das Tagging. Ob die übrigen angedachten Funktionen noch Platz haben werden, sehe ich dann.


    Ist das fertig, bohre ich die Screenlists auf, damit korodnys Vorschläge realisiert werden können (Listbox, Radiobutton usw.) Krieg ich das hin, kann man langsam an ein API denken, damit man mit dem System schon mal herumprobieren kann. Für sowas wie ein RSS-Feed stell ich mir vor, dass das auf dem Hauptschirm mit einem anderen (kleineren) Zeichensatz realisiert wird. Die Texte werden ja dort nicht vollständig angezeigt, sondern immer nur Textanfänge, die könnte man doch in Klein in nicht benutzte Zeichen hineinrendern, vielleicht in 4x4 Zeichen, in die dann aber 6 Zeilen zu vielleicht je 8 Buchstaben geschrieben werden, mit nachgeladenen Zeichendefinitionen, der Zeichensatz muss für so einen Zweck ja nicht resident sein. Klickt man so ein "Widget" dann an, könnte ja in Normalschrift in Groß angezeigt werden. Nur so eine Idee...


    Arndt

    Quote from Ace

    Dann habe ich deine Screenshots ja bisher richtig interpretiert gehabt.

    Ah, nicht ganz, denn es gibt ja doch ein zweites Panel. Das halte ich auch für wichtig. Um das zu realisieren, musste ich auch erstmal die geeignete Idee entwickeln... ;-) (Eine Screenlist ist ja eigentlich nicht dynamisch.)


    Arndt

    Quote from GoDot

    Wie ihr merkt, lebe ich noch. Zum Beweis meine letzten Taten:

    Sehr schön ;)


    Quote from GoDot

    Oben die beiden Reiter für das Quelllaufwerk, wenn sie gehilightet sind, ist das der momentan aktive Drive

    Wenn das zweite Drive nur noch maximal als zwei Info-Zeilen angezeigt wird, und man im unteren Laufwerk sowieso keine Dateien mehr selektieren kann, würde ich einfach festlegen dass das obere, groß angezeigte Drive immer Source ist, und unten immer Target - unten Source macht ja dann sowieso nicht mehr wirklich Sinn, oder? Dann spart man sich das Hervorheben der Reiter, was als visuelle Rückmeldung sowieso eine Minimallösung gewesen wäre.


    Ein "Swap"-Knopf zum Tausch von Source und Target wäre dann noch ganz nett.


    Quote from GoDot

    Die Kringel in den Drive-Reitern erläutere ich beim nächsten Screenshot:
    [...]
    Die sind nämlich für die Drive-Auswahl, oben für den Source-Drive, unten für Destination.

    Gibt es einen technischen Grund, warum man dazu nicht einfach auf die Laufwerksnummer klicken kann? Fände ich intuitiver: ich will Element X ändern, also klicke ich drauf. Die Kringel stehen für mich außerdem eher für "aktualisieren" - was man aber als Funktion durchaus auch drin lassen könnte (Verzeichnisinhalt neu einlesen).


    Quote

    Hier sieht man das Tagging mit Unterlegung. Die angewählte Datei wird oben und unten in den Reitern näher beschrieben (hier "sys.Explorer", 15 blocks lang, eine PRG-Datei)

    Bei Unterstützung für Verzeichnisse, müsste man den aktuellen Pfad (bzw. Teile davon) im oberen Reiter anzeigen (bspw. Header der Disk/Partition wenn in Root, aktueller Pfad wenn in einem Unterverzeichnis?) - diese Information würde bei deinem Ansatz verloren gehen... Die Informationen wie Größe und Dateityp stehen ja sowieso direkt neben dem Dateinamen, den ich anklicke - reicht das nicht?


    Quote

    Für sowas wie ein RSS-Feed stell ich mir vor, dass das auf dem Hauptschirm mit einem anderen (kleineren) Zeichensatz realisiert wird. Die Texte werden ja dort nicht vollständig angezeigt, sondern immer nur Textanfänge, die könnte man doch in Klein in nicht benutzte Zeichen hineinrendern, vielleicht in 4x4 Zeichen, in die dann aber 6 Zeilen zu vielleicht je 8 Buchstaben geschrieben werden, mit nachgeladenen Zeichendefinitionen, der Zeichensatz muss für so einen Zweck ja nicht resident sein. Klickt man so ein "Widget" dann an, könnte ja in Normalschrift in Groß angezeigt werden. Nur so eine Idee...

    Hehe, witzige Idee! Ich hatte mir sowas ähnliches auch schon überlegt, um einen "Home"-Screen wie beim Smartphone zu realisieren - mit Icons. Bin bei meinen "Recherchen" (*hüstel*) zu dem Thema auf was witziges gestoßen: Youtube (mir geht's um die Anzeige, nicht um den Touchscreen).

    Quote from Cyberdyne

    Sehr schade! Trotzdem wünsche ich viel Erfolg!

    Hatte deinen Beitrag ganz übersehen: Ich bin wie du auch bloß Arndt-Bewunderer - meine Meinung zum Thema EF war deshalb sicher keine offizielle Absage - insofern war deine Abreise vielleicht etwas überstürzt ;)


    Aber wenn dein Interesse nur vorhanden ist, wenn eine Anwendung (du weißt ja noch gar nicht ob bzw. welche es geben wird) 1 oder 2 Sekunden schneller geladen ist als von einem Massenspeicher, kann es ja prinzipiell nicht sooo groß gewesen sein?

    Quote from Korodny

    Laut Programming Manual blendet das EasyFlash einfach ein oder zwei 8KB-RAM-Bänke

    Flash, nicht RAM. Drastischer Unterschied bei Schreibzugriffen.


    Quote

    (von bis zu 7 MB)

    1 MB. Das Easyflash 3 hat zwar genug Speicher um 7 Easyflash-Module abzulegen, aber die sind unabhängig voneinander und immer nur 1 MB gross.

    Quote from GoDot

    Ich bleibe hier dabei, dass ich - anders als im FileCopy - nur mit einem Dateifenster arbeite. Ich finde, es reicht, wenn man darüber informiert ist, welche Zieldisk einliegt und wie viel Platz dort noch ist.

    Ich bin mir nicht sicher, ob ich dich richtig verstanden habe. Kann man als Ziel jetzt nur das Laufwerk aussuchen? Was ist mit Unterverzeichnissen oder Disk-Images? Wie wechselt man man beim Ziel-Laufwerk in Unterverzeichnisse/Images?


    Eine Lösung, die ich mir vorstellen könnte, um nur ein Verzeichnisfenster zu nutzen, wäre so: Man sucht sich zuerst das Ziellaufwerk und Zielverzeichnis/Image im Verzeichnisfenster aus. Dann klickt man auf "Target" und das aktuelle LW und Verzeichnis/Image wird als Ziel festgelegt (Infozeile unter dem Verzeichnisfenster). Dann kann man im Verzeichnisfenster ein neues LW und/oder Verzeichnis/Image als Quelle auswählen. Gut wäre es, wenn man über den "Target"-Button Quelle und Ziel tauschen würde. Also das aktuelle Lw und Verzeichnis wird zum Ziel und das bisher als Ziel gespeicherte LW und Verzeichnis werden wieder als Quelle im Verzeichnisfenster angezeigt. So brauch man nur eine Verzeichnisfenster (Dateiliste) und man kann trotzdem schnell hin und her kopieren. Es passiert mir schon mal, dass ich ausversehen eine falsche Datei kopiere, sie wieder löschen will und dann die richtige Datei kopieren will. Das wäre so sehr schnell und einfach möglich und man hat immer nur eine große Dateiliste in der Anzeige. Die LW-Auswahl für das Ziel würde man sich damit auch sparen.
    Hab ich das verständlich genug beschrieben?


    Quote from Korodny

    Aber wenn dein Interesse nur vorhanden ist, wenn eine Anwendung (du weißt ja noch gar nicht ob bzw. welche es geben wird) 1 oder 2 Sekunden schneller geladen ist als von einem Massenspeicher, kann es ja prinzipiell nicht sooo groß gewesen sein?

    Eine Anwendung? Was redest du? Das neue OS (die GUI) sollte so schnell wie möglich und wenn möglich auch automatisch zur Verfügung stehen, sobald man den Rechner einschaltet oder einen Reset auslöst. Wenn ich nach jedem Reset (oft die einzige Möglichkeit ein Programm zu beenden) das OS immer erst von einem Massenspeichermedium nachladen muss, weiß ich jetzt schon, dass ich mir das sparen werde. Mein Interesse ist sehr groß aber das ist für mich ein Key-Feature und ein Showstopper wenn es nicht umgesetzt wird. Wenn du andere Prioritäten hast, dann ist das schön für dich. Du must deswegen aber Anderen kein mangelndes Interesse unterstellen. Du hast nur andere Prioritäten und ich kenne mich gut genug, um zu wissen, was ich am C64 benutze und was nicht.

    Quote from Unseen

    Flash, nicht RAM. Drastischer Unterschied bei Schreibzugriffen.

    Schreibzugriffe? Das dürfte sowieso nicht zur Debatte stehen. M.E. ginge das nur als ROM-Disk, d.h. was goDos angeht gäbe es maximal ein Tool, dass aus mehreren Dateien ein großes Binary zusammenstellt, welches dann mit einem existierenden EasyFlash-Tool auf die Cartridge geschrieben wird.


    Quote from Unseen

    1 MB. Das Easyflash 3 hat zwar genug Speicher um 7 Easyflash-Module abzulegen, aber die sind unabhängig voneinander und immer nur 1 MB gross.

    Kann man die nicht im Betrieb per Software wechseln? Aber selbst wenn nicht, 1 MB sollte auch reichen.


    Quote from Cyberdyne

    Eine Anwendung? Was redest du? Das neue OS (die GUI) sollte so schnell wie möglich und wenn möglich auch automatisch zur Verfügung stehen, sobald man den Rechner einschaltet

    Das ist ja auch kein bzw. ein vergleichsweise kleines Problem - einen Quasi-Freeze des gestarteten goDos samt deiner Lieblingsanwendung ins EasyFlash zu packen geht u.U. sogar mit bereits existierenden Werkzeugen. Nur das Nachladen weiterer Anwendungen aus dem EasyFlash wäre m.E. unverhältnismäßig viel Aufwand. Offenbar hast du da was missverstanden.

    Quote from Brotbox64

    ist ja bei windows und osx nicht anders, wenn ich den Rechner einschalten ist das Betriebssystem sofort da.

    Ha ha, du bist ja ein echt super witziges Kerlchen!
    Was interessiert mich Windows und OSX in diesem Zusammenhang? Beim C64 ist das (textbasierte) OS sofort da nach dem einschalten. Eine Alternative muss mit diesem original OS konkurieren und nicht mit einem Windows oder OSX! Wenn ich die Auswahl zwischen einschalten und per Texteingabe loslegen und einschalten, per Texteingabe die GUI laden, warten und dann erst loslegen habe, dann weiß ich, was ich machen werde.


    Korodny:
    Wenn goDos alle Bestandteile immer im Speicher hätte (und auch das Problem mit der LW-Erkennung beim Laden gelöst wäre) dann wäre das eine Möglichkeit. Ich will nicht jede App im EF haben aber das kpl. OS und das ist mehr als nur die GUI. Ich kann damit leben, dass goDos nicht mein OS werden wird. Wieso kanns du das nicht?