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

last post from steril at the

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

  • unten Source macht ja dann sowieso nicht mehr wirklich Sinn, oder?

    Nein, aber ich kann im Moment den Inhalt des Target-Drives ebenfalls anzeigen, eben indem ich auf den Fußreiter klicke. Das ist also nicht ganz verloren. Ich will doch wahrscheinlich schon wissen, was auf dem Ziellaufwerk drauf ist...

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

    Ja, darüber bin ich auch schon gestolpert!

    Gibt es einen technischen Grund, warum man dazu nicht einfach auf die Laufwerksnummer klicken kann?

    Nein, kann ich auch damit verbinden.

    Die Kringel stehen für mich außerdem eher für "aktualisieren"

    Das ist der GoDot-Listboxkringel, der immer (na, meistens) dann da ist, wenn ein Gadget mehrere Optionen zur Auswahl anbietet. Wie hier die Drives, dachte ich. Aber auf die Laufwerksnummer selbst zu klicken, ist wirklich intuitiver und ich kann mir die Ausgabe des Kringels sparen. Finde ich auch besser.


    Ha! Ich hab inzwischen den Grund für einen über 20 Jahre alten Bug ergründet (und damit gefixt): Das kleine "ü" ist nunmehr über die Tastatur eintippbar... Hehe... (Wenn es um Texteingaben gehen soll - die bisher ja weniger eine Rolle spielten - braucht man wohl das kleine "ü"...) ;-) (Bisher kam immer das große "Ü"!)


    Arndt
    (Und Cyberdyne: Das wünsche ich mir auch und ich sehe das genau wie du: das Dos muss beim Einschalten da sein, sonst macht es keinen Sinn!)

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

    Außerdem: Bei meinem Mac OS Rechner muss ich teilweise wochenlang nicht neu starten.


    Nen C64 schaltet man dauernd ein und aus, da muss ein OS sofort da sein.
    Sonst tu ich lieber LOAD "*",8,1 tippen.

  • Ach, was seid Ihr doch für Weichlinge, früher musste man auch zuerst das "DOS" laden mit LOAD "<-",8,1:RUN, um den Speeder zu laden, der idealerweise auf jeder Diskette daruf war :bgdev


    Ich sehe das bei goDOS auch eher so, dass er als Dateimanager für Fileoperationen was bringt und halt etwas Komfort beim Directory auflisten, was Letzteres aber mit FCIII & co mit DOS"$ (per F-Tasten Druck) genauso gut und schnell geht. Die F-Tasten Belegung finde ich auch sehr wichtig. Norton Commander und Clones waren/sind schnell für Dateioperatione, weil man nicht ewigs wie beim Mac Mausschubsen und Icons treffen muss.


    Dazu kann eben das goDOS in ein CRT/EF oder als alternatives ROM gebrannt werden, oder eben als kleiner Onefiler auf jeder Diskette abgelegt werden.
    Letztes macht aber auch nur Sinn, wenn dieser einen Softspeeder eingebaut hat und klein und schnell geladen ist.


    Apropos, hat schon jemand diese Idee mit dem eingebauten Softschnelllader gebracht?



    Ansonsten soll es auch ein Framework für eigene Text-UI basierende Tools sein, wo man sowas für Menüs und Masken evt. brauchen könnte.

  • Giibt es einen Kopier-Status-Balken oder ähnliches ?


    Da, wo der Copy-Balken läuft, stand vorher, wie lang die Datei ist (102 Blocks). Hier wird gerade von Drive 9 auf Drive 8 ("godos 1.0", noch 526 blocks free) kopiert. Der Balken ist also genauso wie in GoDot, nur dass hier weniger Platz zur Verfügung steht, daher ist die Anzeige vorne verkürzt ("Cp:") und der Balken fängt direkt am Zähler an.


    Der gegenläufige Doppelpfeil rechts soll Quell- und Ziellaufwerk austauschen, die Drivenummern sind bereits aktiv zum Neuauswählen des Drives. Da wo "Tag:" steht, wird die Anzahl der getaggten Dateien angezeigt und darunter die Gesamtzahl der Dateien auf dem Quelllaufwerk (beide noch auf 0, noch nicht implementiert). Die Buttons zum Erstellen eines D64 und zum Formatieren hab ich rausgenommen. Die Anzeige der Dateilängen im großen Fenster fehlt auch noch.


    Arndt


  • Da, wo der Copy-Balken läuft, stand vorher, wie lang die Datei ist (102 Blocks). Hier wird gerade von Drive 9 auf Drive 8 ("godos 1.0", noch 526 blocks free) kopiert. Der Balken ist also genauso wie in GoDot, nur dass hier weniger Platz zur Verfügung steht, daher ist die Anzeige vorne verkürzt ("Cp:") und der Balken fängt direkt am Zähler an.

    Wow :ilikeit:


    Quote

    Die Buttons zum Erstellen eines D64 und zum Formatieren hab ich rausgenommen. Die Anzeige der Dateilängen im großen Fenster fehlt auch noch.


    Arndt

    Kommt die Funktion dort noch hinein ? Fände es wichtig wenn man d64 und d81 Images erstellen könnte.
    In übrigens schliesst dein Dateimanager endlich die Brücke zu allen bekannten Laufwerken. :hammer:

  • Und da wäre auch noch genug Platz um hinter der LW-ID um direkt auch den LW-Typ anzuzeigen.

    Ist doch schon da, hinter der Bytes-Free-Anzeige, die erscheint auch beim Quelllaufwerk, wenn kein File angewählt ist. Der Platz hinter den Laufwerksnummern soll (wie korodny das vorgeschlagen hat) die Partitionsnummer bei CMD-Native-Drives anzeigen.


    Arndt

  • Ist doch schon da, hinter der Bytes-Free-Anzeige

    Ich weiß! Ich fand die Stelle, wo die LW-ID steht einfach logisch sehr passend. Da würde ich spontan nach dieser Info suchen. Außerdem sah der Bereich so leer aus (zur Partitionsnummer komme ich weiter unten) und wirkte für mich deutlich besser als hinter der "Bytes-Free-Anzeige". Wenn sonst noch nichts für den Platz geplant gewesen wäre, hätte ich den Platz ideal gefunden!


    die erscheint auch beim Quelllaufwerk, wenn kein File angewählt ist.

    Das "wenn" ist etwas störend aber das ist alles nicht kriegsentscheident.


    Der Platz hinter den Laufwerksnummern soll (wie korodny das vorgeschlagen hat) die Partitionsnummer bei CMD-Native-Drives anzeigen.

    Das hatte ich überlesen. Ich habe zwar keine CMD Geräte (und deshalb würde mich das Fehlen dieser Information nicht tangieren) aber das passt natürlich auch super an diese Stelle.
    Wozu aber den Platz bei allen anderen Laufwerken verschwenden? Könnte man das nicht kombinieren? Könnte man bei CMD Geräten nicht Typ (RL, FD2, FD4, HD20, ...) und dazu die Partitionsnummer angeben (Wieviel Zeichen Platz ist da?)?


    Wie soll man eigentlich bei einem SD2IEC erkennen, dass man grundsätzlich mit einem SD2IEC arbeitet, man sich aber gerade in einem D81-Image befindet. Würde als LW-Typ dann 1581 angezeigt oder ist die Info irgendwo anders ersichtlich. "SD2IEC(D81)" wäre eine Möglichkeit. Diese Information könnte ja auch bei CMD Geräten neben der Partitionsnummer interessant sein. Die können doch auch Commodore Laufwerke "emulieren", oder?


    Wo "wir" die ganze Zeit über LW-IDs reden. Es passiert nicht oft aber selbst ich hatte schon die Situation, dass ich per Software eine ID temporär umstellen musste. Das passiert z.B. bei einem C128D oder bei einem SX64, wenn man ein externes LW mit ID8 betreiben will/muss. Die Vorgehensweise ist dann so: Rechner einschalten, ID von internem LW von 8 auf 9 ändern und dann externes LW (mit ID8) einschalten. ID ändern ist so eine kryptische Angelegenheit, die ich dann "immer" (2 Mal in meinem Leben) googlen muss. Ich fänd es grundsätzlich praktisch, wenn goDos auch eine Funktion zum temporären ändern der ID bieten würde. Da stellt sich nur zusätzlich das Problem, dass goDos ja nur beim Booten die Laufwerke erkennt und man bei diesem Problemfall oft/meist/immer ein weiteres LW erst nach dem Umstellen der ID einschaltet. Es müsste also mindestens auch noch eine Funktion für einen erneuten LW-Scan geben. Diese Funktion finde ich auch grundsätzlich sehr praktisch!
    Ich weiß nicht, wie wichtig diese Funktion für die User ist?! Wollte es nur mal als Idee gesagt haben.


    Auf die Kopier-Funktion innerhalb eines Laufwerks bin ich schon sehr gespannt (z.B. Dateien aus einem D64-Image in ein D81-Image in einem anderen Verzeichnis auf dem gleichen SD2IEC kopieren).

  • Das hatte ich überlesen. Ich habe zwar keine CMD Geräte (und deshalb würde mich das Fehlen dieser Information nicht tangieren) aber das passt natürlich auch super an diese Stelle.Wozu aber den Platz bei allen anderen Laufwerken verschwenden? Könnte man das nicht kombinieren? Könnte man bei CMD Geräten nicht Typ (RL, FD2, FD4, HD20, ...) und dazu die Partitionsnummer angeben (Wieviel Zeichen Platz ist da?)?

    Die Info sollte immer an der selben Stelle zu finden sein - wenn sie bei CMD-Laufwerken nicht dort stehen kann, sollte sie also grundsätzlich woanders hin. An ein und der selben Stelle mal Information X und mal Information Y anzuzeigen, finde ich ergonomisch nicht gut.


    Wie soll man eigentlich bei einem SD2IEC erkennen, dass man grundsätzlich mit einem SD2IEC arbeitet, man sich aber gerade in einem D81-Image befindet. Würde als LW-Typ dann 1581 angezeigt oder ist die Info irgendwo anders ersichtlich.

    Hm, guter Punkt. Ich würde das aktive Image aber eher als Bestandteil des Pfads betrachten, also sollte die Info m.E. in die Kopfzeile des Verzeichnisfensters. Die könnte je nach Situation folgendes Anzeigen:

    • Name, id 2a (bei einem echten 15x1-Laufwerk, oder wenn man sich im Rootverzeichnis eines Massenspeichers befindet)
    • D81:Name, id 2a (wir befinden uns in einem Disk-Image)
    • pfad/zu/verzeichnis (die letzten X Zeichen des Pfadnamens, wenn wir uns in einem Unterverzeichnis befinden).

    Die Laufwerksbezeichnung wäre dann immer gleich: SD2IEC.


    Diese Information könnte ja auch bei CMD Geräten neben der Partitionsnummer interessant sein. Die können doch auch Commodore Laufwerke "emulieren", oder?

    Nicht wirklich. Du kannst Partitionen anlegen, die exakt die Geometrie einer 1541/1571/1581-Disk haben, um Programme zum Laufen zu bringen, die direkt einzelne Tracks einer Diskette lesen oder schreiben wollen. Das kommt einem Disk-Image zwar relativ nahe, ist aber tatsächlich nur eine Partition wie jede andere auch.


    Ich fänd es grundsätzlich praktisch, wenn goDos auch eine Funktion zum temporären ändern der ID bieten würde.

    Fände ich auch ganz praktisch. Könnte man aber m.E. in die DOS-Wedge ("Terminal", "Kommandozeile" - wie auch immer) mit einbauen, die dann von jeder Anwendung aus gestartet werden kann. Die Syntax dafür übernimmt man von jiffyDOS (oder war's das Action Replay?): @8=9


    Da stellt sich nur zusätzlich das Problem, dass goDos ja nur beim Booten die Laufwerke erkennt und man bei diesem Problemfall oft/meist/immer ein weiteres LW erst nach dem Umstellen der ID einschaltet. Es müsste also mindestens auch noch eine Funktion für einen erneuten LW-Scan geben.

    Das gab es bereits unter GoDot als Modul, ist also bereits vorhanden.

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

    Nachdem Cyberdyne das in seinem Beitrag erwähnt hatte, habe ich darüber auch noch mal nachgedacht. Ich finde das zum einen überflüssig: sämtliche Informationen die du so anzeigst, sind ja bereits dem Dateilister zu entnehmen - und zwar übersichtlicher, weil (a) in einer Zeile und (b) in einem Format dass wir alle seit Jahrzehnten aus Directory-Listings kennen.


    Wichtiger finde ich aber, dass ich, sobald ich mindestens eine Datei markiert habe, nicht mehr sehen kann wo ich mich befinde (Unterverzeichnis? Disk-Image auf einem Massenspeicher?), wie die aktuelle Diskette/Partition heißt (war das jetzt "Work" oder "Work_Backup"?) oder wie viel Platz noch auf dem Datenträger ist ("ich brauche X Blocks frei auf der Disk - reicht es, wenn ich Datei Y lösche?").

  • Die Info sollte immer an der selben Stelle zu finden sein - wenn sie bei CMD-Laufwerken nicht dort stehen kann, sollte sie also grundsätzlich woanders hin. An ein und der selben Stelle mal Information X und mal Information Y anzuzeigen, finde ich ergonomisch nicht gut.

    Du hast mich falsch verstanden! Ich dachte mir (wenn es vom Platz reicht), dass man immer den LW-Typ an der Stelle hat und bei Laufwerken mit Partitionen wird zusätzlich z.B. ein ":" und die Partitionsnummer angehängt. Sähe dann so aus: "1541" oder "SD2IEC" oder "HD20:0" oder "HD100:142" (Die CMD Floppies würde ich FD2 und FD4 abkürzen! ;) ).
    Wie gesagt ist das nur so eine Idee, die nicht wirklich wichtig ist. Ich hab nicht mal geschaut, wieviel Platz da überhaupt ist.


    ist aber tatsächlich nur eine Partition wie jede andere auch.

    Ah, OK! Ich dachte, da hätte CMD sich doch mehr Mühe gegeben.


    Wichtiger finde ich aber, dass ich, sobald ich mindestens eine Datei markiert habe, nicht mehr sehen kann wo ich mich befinde (Unterverzeichnis? Disk-Image auf einem Massenspeicher?), wie die aktuelle Diskette/Partition heißt (war das jetzt "Work" oder "Work_Backup"?) oder wie viel Platz noch auf dem Datenträger ist ("ich brauche X Blocks frei auf der Disk - reicht es, wenn ich Datei Y lösche?").

    Guter Einwand!

  • Könnte man aber m.E. in die DOS-Wedge ("Terminal", "Kommandozeile" - wie auch immer) mit einbauen, die dann von jeder Anwendung aus gestartet werden kann. Die Syntax dafür übernimmt man von jiffyDOS (oder war's das Action Replay?): @8=9

    Da ist dann die Frage, ob goDos die Eingaben in der DOS-Wedge analysiert?! goDos macht ja einen Scan und merkt sich irgendwo, welcher LW-Typ unter welcher ID zu erreichen ist. Entweder muss goDos ein "@<id>=<id>" in der DOS-Wedge erkennen um seine Laufwerkstabelle entsprechend selber anzupassen oder man darf nicht vergessen nach diesem Befehl immer händisch einen LW-Scan anzustoßen. Aus diesem Grund kam ich auf die Idee mit der extra Funktion. Die würde einerseits den entsprechenden Befehl zum LW schickt und gleichzeitig die LW-Tabelle von goDos korrigieren. Wenn man danach dann ein weiteres LW einschaltet, muss man trotzdem noch einen Scan von Hand starten.



    PS: "@8=9" - Echt jetzt? So einfach ist das mit JiffyDOS? Hätte ich das doch damals schon gehabt. Ich hab mir da mit OPEN... einen abgebrochen. Man konnte ja auch nicht eben im Inet suchen, wie das nochmal ging.

  • Oder einfach nur die Ausgabe des Fehlerkanals ein wenig erweitern mit passendem Laufwerkstatus und welchen Mode es läuft.
    Das müsste man halt nur mit nem Parser abfangen und wär soweit Abwärtskompatibel das sich nicht SD2IEC Geräte über unbekannte Kommandos beschweren könnten.
    Nachteil: Unseen muss das in seine Firmware einarbeiten.

  • Ah, OK! Ich dachte, da hätte CMD sich doch mehr Mühe gegeben.

    Wieso mehr Mühe geben? Das System funktioniert im Grunde genau wie ein Diskimage, es ist nur technisch etwas anders implementiert. Ende der Achtziger gab's noch keine dx1-Diskimages, an denen CMD sich hätte orientieren können. Und der gewählte Ansatz hatte den Vorteil, dass man nicht zwischen Partitionen und Diskimages unterscheiden musste - sondern lediglich Partitionen vorhanden waren.


    Da ist dann die Frage, ob goDos die Eingaben in der DOS-Wedge analysiert?!

    Nicht goDos: die DOS-Wegde wäre ein normales Programm bzw. Modul, das unter goDos läuft. Und ja, das müsste man natürlich so implementieren, dass zuerst auf einige DOS-Wedge-interne Befehle geprüft wird: startet der Befehl mit "$", "HELP", "#" (aktuelles Laufwerk wechseln) , Linkspfeil (Laufwerksnummer ändern) oder ^ (nach Laufwerken scannen) wird die zugehörigen interne Routine ausgeführt, ansonsten wird der String an die Floppy geschickt.


    goDos macht ja einen Scan und merkt sich irgendwo, welcher LW-Typ unter welcher ID zu erreichen ist.

    Richtig - die Routine die die Laufwerksnummer ändert, müsste danach eben noch einen Laufwerksscan durchführen.

  • die Stelle, wo die LW-ID steht einfach logisch sehr passend

    Lass ich mir alles mal durch den Kopf gehen, vor allem deswegen:

    sobald ich mindestens eine Datei markiert habe, nicht mehr sehen kann wo ich mich befinde

    ? Könnte man bei CMD Geräten nicht Typ (RL, FD2, FD4, HD20, ...) und dazu die Partitionsnummer angeben

    Ja, so wollte ich das machen: statt "C= 1541" steht dann da z.B. "RL 1541" usw. Platz ist da noch.

    Es müsste also mindestens auch noch eine Funktion für einen erneuten LW-Scan geben

    Ja, die gibt es schon. Aber eure Hinweise auf die Dos Wedge finde ich auch wichtig. Die Wedge hatte ich noch nicht im Blick. Ich bin nebenbei gerade dabei, die Speicheraufteilung für goDos festzulegen. Für den Screen-Cache sind schon 2K im Betrieb, die unter GoDot noch Grafik waren. Langsam entfernt sich das Ganze also von GoDot (was die Sache offener macht).


    Laufwerkstausch (Quelle<>Ziel) ist nun implementiert (sehr praktisch!).


    Arndt

  • Nächster Schritt:



    Hier sieht man in den ersten beiden Screenshots augenfällig den Tauschknopf in Aktion (Button unter "U&I!"). In Drive 8 ist die Disk "godos 1.0" in Drive 9 liegt "clipart2.d64". Die Disknamen stehen jeweils im Kopfreiter, die Diskdaten im Fußreiter. Rechts über "Exit" sieht man, wie viele Files auf dem Source-Drive sind (auf "godos 1.0": 25, auf dem anderen: 5), getaggt sind jeweils 0 (weil die Funktion noch nicht implementiert ist, sonst würde im dritten Bild da eine 1 stehen). Die Dateilängen werden (auf dem Source-Drive) angezeigt, allerdings bin ich da auch noch nicht ganz fertig (Scrollen mit Dateilängenangabe fehlt noch). Die Kopfzeile bleibt dem Disknamen vorbehalten, wie man im dritten Bild sieht. Angeklickte Dateien werden nun im Fußreiter angezeigt und bearbeitet. Hier wird die Datei "scraper.gif" gerade zu "skyscraper.gif" umbenannt. Auch "Cmd" (DOS-Kommandos) führt an diese Stelle, ebenso finden die Fortschrittsanzeigen bei "Copy" und "Move" hier statt. Bei allen Aktionen werden die Ergebnisse angezeigt (also neu eingelesen bei "Del", "Copy", "Ren" und "Move". Wird das Zieldrive-Panel ausgeblendet, sieht man nur die Quelldrive-Informationen. Die Anzeige des Filetyps hab ich mir in der Dateiliste erspart (kommt individuell nach dem Anklicken einer Datei, s. Bild 3), der Filetyp spielt eh keine Rolle, denn auf dem Zieldrive wird beim Kopieren eine Datei gleichen Typs erzeugt. Die korrekte Darstellung des Scrollbalkens soll ins Hauptsystem verlegt werden. Die Implementation dauert daher noch.


    Als nächstes kommt das Scrollen mit Längenausgabe dran, danach das Tagging, danach die noch fehlenden Funktionen, wobei aber der Platz wieder eng zu werden droht, mal sehen, wie ich dem begegnen kann.


    Arndt