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

Es gibt 313 Antworten in diesem Thema, welches 59.483 mal aufgerufen wurde. Der letzte Beitrag (8. Mai 2018 um 09:34) ist von steril.

  • Nein. Vorschläge?

    Wie sieht es aber mit einer Menüleiste wie beim alten MacOS aus. Wäre schön, wenn sich alle OS-Apps an diese "Vorgabe" halten würden: Links ein Button (z.B. "Go") zum Anzeigen eines GoDos Infoscreen, zum Anzeigen eines Infoscreen zur aktuell laufenden OS-App, zum beenden der App, und zum starten einer beliebigen anderen OS-App (das schließt natürlich auch die gerade laufende App); Ganz rechts eine Uhr (ohne Sekunden - wir wollen ja nicht die geballte CPU-Power für die Sekundenanzeige verballern ); Dazwischen ein App spezifisches Menü. Wäre so etwas (ohne zu viel Aufwand) möglich? Nachteil wäre natürlich, dass alle Apps eine Zeile weniger Platz haben.

    Ich mag Menüleisten, wo immer alles an seinem Platz ist und man nicht suchen muss egal in welchem Programm man gerade ist. Dazu finde ich einen "Startbutton" sehr praktisch, über den man z.B. Programme startet. Da wir nicht über ein Multitasking OS sprechen, brauchen wir keine Startleiste, um laufende Programme zu sehen und zwischen ihnen zu wechseln. Ich fände die Kombination von beidem jetzt gar nicht schlecht. Das muss dann natürlich eine Funktionalität sein, die das OS den OS-Apps zur Verfügung stellt. War halt nur mal so ne Idee genau wie das integrieren einer Uhr.


    Zugang zum Netz

    Sowas? Bitte melde dich an, um diesen Link zu sehen.

    Zugang zu Sensoren

    Extrem unnütz bei einem stationären Computer aber ich find es extrem cool:
    Bitte melde dich an, um diesen Link zu sehen.

    Retrofans CPU Temperatur fand ich extrem witzig! Es hat sofort ein "Das ist so unnütz, dass ich es haben muss"-Gefühl ausgelöst. Spontan würde ich das über einen Sensor an der Joystickbuchse (Paddle-Eingang) lösen wollen. Ich habe mich aber noch nie wirklich mit so Temperaturfühlern auseinander gesetzt.

    Zugang zu *Aktoren*

    Zählt sowas auch dazu?
    Bitte melde dich an, um diesen Link zu sehen.

    Und TSB: Verstehe ich das richtig, es soll dazu dienen, goDos direkt zu programmieren? Ich dachte da eher an sowas wie einen APP-Builder, also ein TSB-*Programm*, das all die lästige Arbeit verkürzt, die ein Coder sonst tun müsste. Man bastelt sich im Builder eine Oberfläche und der Builder füllt den dazu erforderlichen Code gleich mit rein. Das, was die APP dann spezifisch machen soll, ist aber wieder Aufgabe des Coders. Es gibt für Spezifisches ja keine Bausteine. Der Builder liefert also irgendwann Quellcode, das Gerüst für die endgültige APP. - Soll das so sein? (Das kann ich mir vorstellen.) Oder anders? Dann: wie anders?

    Auch ich weiß nicht genau, ob ich dich richtig verstehe. Deine Beschreibung klingt irgendwie ein bisschen nach VB.
    An einen Builder hatte ich noch gar nicht gedacht. Meine Vorstellung war bisher so, dass es zusätzliche Befehle geben sollte wie "button", "radiobutton", "checkbox", "menubar", "menuitem", "infobox", "filedialog", ..., die halt dem Look von goDos entsprechen. Außerdem sollten die Programme nach dem Compilieren nativ unter goDos laufen, ohne dass man erst noch TSB oder irgend etwas anderes von Hand laden muss. Bei Diskettenbetrieb müsste man damit leben, dass goDos die Laufzeitumgebung automatisch nachläd. Besser wäre es natürlich mit einem Modul. Ob die Befehle jetzt durch das OS zur Verfügung stehen (so DLL mäßig) oder ob der Compiler den entsprechenden Code für diese Funktionen dazu packt, wäre mir vollkommen egal. Ein Builder für die App-UIs wäre natürlich noch einfacher aber der müsste ja auch erstmal programmiert werden.

    Hier ist aber wirklich die Frage, ob der Nutzen den Aufwand rechtfertigt. Ich fänd es endgeil und hätte voll Spaß meine alte Adressdatenbank neu zu schreiben und eine goDos-App zur Steuerung eines SVI-2000 Roboterarms und so unnützes Zeug. Ein Minesweeper für goDos hätte ich wahrscheinlich auch schnell! Ich weiß aber nicht, ob es noch mehr so Spinner wie mich gibt, die in BASIC direkt am C64 programmieren wollen?!

  • Hier ist aber wirklich die Frage, ob der Nutzen den Aufwand rechtfertigt. Ich fänd es endgeil und hätte voll Spaß meine alte Adressdatenbank neu zu schreiben und eine goDos-App zur Steuerung eines SVI-2000 Roboterarms und so unnützes Zeug. Ein Minesweeper für goDos hätte ich wahrscheinlich auch schnell! Ich weiß aber nicht, ob es noch mehr so Spinner wie mich gibt, die in BASIC direkt am C64 programmieren wollen?!

    Da kann ich Dich beruhigen. Geht mir genauso ^^

    Auch ich weiß nicht genau, ob ich dich richtig verstehe. Deine Beschreibung klingt irgendwie ein bisschen nach VB.An einen Builder hatte ich noch gar nicht gedacht. Meine Vorstellung war bisher so, dass es zusätzliche Befehle geben sollte wie "button", "radiobutton", "checkbox", "menubar", "menuitem", "infobox", "filedialog", ..., die halt dem Look von goDos entsprechen. Außerdem sollten die Programme nach dem Compilieren nativ unter goDos laufen, ohne dass man erst noch TSB oder irgend etwas anderes von Hand laden muss. Bei Diskettenbetrieb müsste man damit leben, dass goDos die Laufzeitumgebung automatisch nachläd. Besser wäre es natürlich mit einem Modul. Ob die Befehle jetzt durch das OS zur Verfügung stehen (so DLL mäßig) oder ob der Compiler den entsprechenden Code für diese Funktionen dazu packt, wäre mir vollkommen egal. Ein Builder für die App-UIs wäre natürlich noch einfacher aber der müsste ja auch erstmal programmiert werden.

    Hier ist aber wirklich die Frage, ob der Nutzen den Aufwand rechtfertigt. Ich fänd es endgeil und hätte voll Spaß meine alte Adressdatenbank neu zu schreiben und eine goDos-App zur Steuerung eines SVI-2000 Roboterarms und so unnützes Zeug. Ein Minesweeper für goDos hätte ich wahrscheinlich auch schnell! Ich weiß aber nicht, ob es noch mehr so Spinner wie mich gibt, die in BASIC direkt am C64 programmieren wollen?!

    So eine Art Powerbasic im VB Stil hätte schon was. Einfache Menüprogrammierung unter Godos :)

  • Also neu drin: Screen-Cache und FileInfo. Die Routinen dafür sind im Slot4. Idealer Ort dafür. :smile:
    [...]
    Korodny: Ich hab einen Weg gefunden, die Routine, die Screenlists aufbereitet, zu erweitern. Das bedeutet, dass Screenlists selber nun erweitert werden können. Bin dabei, darüber nachzudenken, wie. Deine Vorschläge sind sehr fruchtbar... :winke:

    Super, bin schon gespannt!

    Ich schaue mir dauernd Retrofans Mockups an. Wär ja schön, wenn zu sowas die entsprechende Hardware schon da wäre: Zugang zum Netz, Zugang zu Sensoren, Zugang zu *Aktoren*

    Ich bin davon ausgegangen, dass er die in den Widgets dargestellten Information auch aus dem Netz holen will.

    Wie funktioniert denn die Kopierausgabe ? Quellaufwerk ist in einem Fenster sichtbar. Das Zieldrive
    hat kein Fenster ?

    Nochmal: Mit den Doppelpfeilen kannst du das zweite Fenster kleiner/größer machen bzw. ganz verstecken. Im Screenshot ist es eben ganz versteckt.

    Ich hoffe ja immer noch auf ein goDos-EF-ROM, wo dann TSB wenn benötigt (also wenn man versucht eine goDos/TSB-APP zu laden) so als Laufzeitumgebung eingeblendet wird.

    Das ist technisch nicht möglich. Möglich und sinnvoll wird lediglich sein, eine Art goDos-Snapshot (inklusive aktuellen Settings und einer Wunschanwendung - so als würdest du mit einem Action Replay o.ä. einen "Freeze" von einem Programm machen) im EF zu speichern, so dass es direkt nach dem Einschalten verfügbar ist. Die einzige andere Möglichkeit (EF als eine Art ROM-Disk zu unterstützen), wäre viel zu umständlich und aufwendig.

    Ist dir klar, dass TSB in erster Linie ein Simon's-Basic-Klon ist? Es enthält keine Routinen zur Darstellung schöner GUIs (das hat Arndt einfach von Hand implementiert) , und die goDos-Routinen nutzt es auch nicht. TSB wäre unter goDos also ein kompletter Fremdkörper, das so zu nutzen ist m.E. sinnlos. Ein BASIC-Program, das TSB nutzt, sollte dieses eigenständig nachladen (falls das möglich ist, keine Ahnung), damit ist es aus goDos-Sicht eine Anwendung wie jede andere auch.

    Man könnte ja als erstes versuchen zum Basic 2.0 noch Befehle für das goDos UI hinzuzufügen. Dann könnte man schauen, was man vielleicht noch aus SB bzw. TSB übernehmen (klauen) könnte.
    Interessant wären die drei Komponenten Editor, Compiler und Laufzeitumgebung, die nach Bedarf eingeblendet werden. Ja, es macht Spaß so ein bisschen zu träumen! ;)

    Und dann kommt die Wonder-Woman-Darstellerin vorbei und bietet Orals... sorry, ich schweife ab.

    Dank Endurions GUI-Builder kann man sich goDos-Oberflächen bereits per Maus zusammenklicken. Sollten BASIC-Programmierer an goDos Interesse haben, wäre es vermutlich deutlich sinnvoller einen der alten Mini-Compiler (TinyBasic oder so?) zu nehmen, die nur ein deutlich reduziertes Basic (peek, poke, if/then, goto/gosub - nur Integer Zahlen) aber dafür echten Assemblercode erzeugen - und so anzupassen, das er die mit dem GUI-Builder erzeugten GUIs unterstützt und goDos-Programme erzeugt.

  • Nein. Vorschläge?


    Eine Menüleiste kostet immer gleich zwei bis drei Bildschirmzeilen - hätte Explorer eine Menüzeile, könnte er gleich drei oder vier Dateien weniger anzeigen...

    Alternative wäre ein Menü-Knopf, wie bei Smartphone-UIs. Der erfordert dann halt einen Mausklick mehr (Menu->File->Save statt File->Save), und da er immer an der selben Stelle liegen muss schränkt er die Programmierer beim GUI-Design ebenfalls ein.

    Beide Varianten benötigen dazu komplett neuen Code und eine noch zu definierende Logik zum Übergeben von Menü-Inhalten.

    Mein Vorschlag wäre deswegen ein "Menü-Window": STOP, Rechte Maustaste oder was auch immer, öffnet über dem aktuellen Fenster ein in einer zweiten Screenlist definiertes Window mit mehreren Karteikartenreitern o.ä., wovon anfänglich immer der meistbenutzte geöffnet ist:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Der erste Reiter/Abschnitt/wasauchimmer ("goDos", "File", Project" o.ä.) enthält:

    • Laden/Speichern/Exportieren u.ä.
    • DOS-Wedge starten (kann man als Modul implementieren)
    • Aufruf der Programm-Settings (falls vorhanden)
    • "Über Explorer"
    • "Hilfe anzeigen" (falls ein Hilfstext für das aktuelle Programm gefunden wurde)
    • Möglichkeit ein Modul auszuführen.
    • Quit

    Der zweite Reiter ("Edit", "Commands" o.ä.) enthält die wichtigsten Funktionen die ich zur Arbeit mit dem Programm brauche, die sich direkt auf den gerade bearbeiteten oder markierten Inhalt beziehen. Ein oder zwei weitere Reiter kann jedes Programm nach Belieben definieren.

    Vorteile, in meinen Augen:

    • Implementation kann weitgehend mit bestehendem GUI-Code erledigt werden.
    • Benötigt nur Platz auf dem Schirm, wenn man auf einem Menü-Knopf besteht - ich würde wie gesagt auf den verzichten.
    • Kompliziertere Interface-Elemente lassen sich direkt einbauen, ohne dass ein weiterer Requester benötigt wird (bspw. ein Dropdown- oder String-Gadget)
    • Könnte auch unabhängig vom aktuellen Screen-Mode genutzt werden (bspw. Bildanzeiger, Malprogramm...)
  • Neue Version 0.7 liegt auf dem Link

    Danke!

    Es enthält keine Routinen zur Darstellung schöner GUIs (das hat Arndt einfach von Hand implementiert) , und die goDos-Routinen nutzt es auch nicht.

    Das ist exakt so, wie es ist. Daher meine Frage nach dem APP-Builder. Den stell ich mir gar nicht so schwer zu programmieren vor. Wenn ich dann soweit bin, dass ich - wie korodny das vorschlägt - für bestimmte Dinge eigene Routinen mit je definierter Schnittstelle habe, dann wäre es schließlich nur so eine Art Baukasten-System.

    Die Frage nach den Sensoren und Aktoren finde ich viel weitreichender, da liegt doch viel spannendes Will-Haben-Zeugs drin! :smile:

    Mit den Doppelpfeilen kannst du das zweite Fenster kleiner/größer machen

    Genau. Ich will ja nicht die Seiten hier mit Screenshots zumüllen..

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Mein Vorschlag wäre deswegen ein "Menü-Window":

    Ah! Das ist ja cool!

    Das gefällt mir!

    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Genau. Ich will ja nicht die Seiten hier mit Screenshots zumüllen..

    Wäre vielleicht ab und an sehr hilfreich. Nicht jeder Gedankengang lässt sich von euch beiden aus den Zeilen nachvollziehen. Da wäre ein Bild
    manchmal verständlicher.

  • Sowas? tinyurl.com/ydxojanm

    Ein WiFi-Modem, genau. Hier im Wiki: Bitte melde dich an, um diesen Link zu sehen..

    extrem cool:
    tinyurl.com/olvpmhx

    Ein GPS-Empfänger. Nicht schlecht, wenn es beim Surfen um Informationen geht, die sich auf den Standort beziehen. Läuft das Teil auch hier in Europa?

    Zählt sowas auch dazu?
    tinyurl.com/bmozvv6

    Radio! Ja, klar! Super!

    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Ein Minesweeper für goDos hätte ich wahrscheinlich auch schnell!

    Schon da! (Klein, aber fein!) Ist auf der GoDot-Disk a.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Hehe... :smile:

    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Damit ist das OS komplett :) der Rest ist jetzt nur noch Fleissarbeit 8)

    - neue Spiele für den C64 -
    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.

  • Damit ist das OS komplett :) der Rest ist jetzt nur noch Fleissarbeit 8)

    Halt, Stopp! Solitaire, Hearts (netzwerkfähig) und Freecell fehlen noch :D

  • Das ist technisch nicht möglich. Möglich und sinnvoll wird lediglich sein, eine Art goDos-Snapshot (inklusive aktuellen Settings und einer Wunschanwendung - so als würdest du mit einem Action Replay o.ä. einen "Freeze" von einem Programm machen) im EF zu speichern, so dass es direkt nach dem Einschalten verfügbar ist. Die einzige andere Möglichkeit (EF als eine Art ROM-Disk zu unterstützen), wäre viel zu umständlich und aufwendig.

    Das klingt nicht gut! Ich hoffe, dass ist jetzt nur auf TSB bezogen! Wie gesagt bin ich nicht auf TSB fixiert (obwohl es eine super BASIC Erweiterung ist). Ich benutze es zwar aber BASIC 2.0 ist echt scheiße! Ich hatte damals GEOS-BASIC und so etwas fänd ich halt auch für goDos super. Größter Nachteil bei GEOS-Basic war (aus meiner sicht), dass mir GEOS auf den Sack ging.
    Wie schaut es denn grundsätzlich mit goDos und EF aus? Könnte man etwas wie hier beschrieben umsetzen?
    Bitte melde dich an, um diesen Link zu sehen.

    Eine Menüleiste kostet immer gleich zwei bis drei Bildschirmzeilen

    Nein, nicht zwingend. Wenn man auf einen 3D-Effekt verzichtet, könnte man einfach eine einzelne Zeile mit anderer Hintergrundfarbe nutzen. Würde mir vollkommen reichen. Deine Idee mit dem Menü-Fenster (per rechter Maustaste) gefällt mir aber auch. Was meinst du mit Modul ausführen? Ich fänd es gut, wenn man von dort aus auch gleich die OS eigenen Apps starten könnte. Dann bräuchte man auf dem "Desktop" auch kein Startmenü.

    Schon da! (Klein, aber fein!) Ist auf der GoDot-Disk a.

    Du bist genau so bescheuert wie ich! ;)
    Dann programmier ich das halt nicht! Wollte eh immer mal ein 3D Minsweeper schreiben! ;)

  • Wie schaut es denn grundsätzlich mit goDos und EF aus? Könnte man etwas wie hier beschrieben umsetzen?
    Bitte melde dich an, um diesen Link zu sehen.

    M.E.: Theoretisch ja, praktisch nein. Das was dort beschrieben wird, hatte ich mit "ROM-Disk" gemeint: Man blendet ein oder zwei 8 KB große ROM-Bereiche des EF im Speicher des C64 ein und kopiert die Inhalte an die Stellen, wo man sie haben will (dort wo sie eingeblendet werden, nutzen sie uns nämlich nichts), dann blendet man die ROM-Bereich wieder aus. Man nutzt die EF also quasi wie eine ROM-Floppy. Neben der eigentlichen Lade-Routine bräuchte es dann noch eine weitere Routine, die das EF nach goDos-Programmen und Modulen absucht. Außerdem müsste man ein Konvertierprogramm schreiben, was die Disk.basierten goDos-Teile und -Anwendungen auf die 8KB großen Bänke des EF verteilt.

    Das Problem ist, dass die Lade- und Directory-Routinen immer vorhanden sein müssen - egal ob nun ein EF angeschlossen ist und benutzt wird oder nicht - zusätzlich zu den normalen Lade- und Speicherroutinen. D.h. sie verbrauchen prinzipiell Speicherplatz. Eine spezielle EF-Variante kannst du auch nicht machen, weil die für Anwendungsprogramme weniger Platz hätte als die normale Version. IMHO ist es das nicht wert.

    Es gibt scheinbar Tools, die ein Programm oder eine ganze Disk ins EF packen und gleich mit einem Pseudo-Dateisystem versehen, so dass man von BASIC aus ganz normal aus der EF laden kann. Die blenden dafür ein zusätzliches ROM ein und verbiegen die Ladevektoren (nehme ich an). Das wird mit goDos aber nicht funktionieren, weil goDos zeichenweise einliest und nicht die normale LOAD-Routine des Kernels benutzt.

    Ich hatte damals GEOS-BASIC und so etwas fänd ich halt auch für goDos super.

    Versteh mich nicht falsch - ich wollte keineswegs die Idee runtermachen - klar wäre das cool. Ich fürchte nur, das ist heutzutage zu ambitioniert. Aber Arndts Idee von einem App-Builder hat doch auch was? Du kannst die graphische Benutzeroberfläche mit der Maus zusammenklicken und als fertige Textdatei speichern. Wie man da noch Programmlogik dahinter bekommt, müsste man sich dann noch überlegen, "Compiler" und "Laufzeitumgebung" dürften da aber ein paar Nummern zu groß sein.

    Was meinst du mit Modul ausführen?

    goDos kann kleine, bis zu 4KB große Hilfsprogramme ausführen (bspw. Minesweeper ;) ), ohne dass man das laufende Programm beenden müsste - so wie GEOS das auch konnte. Ich weiß nicht, wie Arndt diese Hilfsprogramme nennen will ("Utilities" vielleicht?), in goDot hießen sie eben schlicht "Module".

    Ich fänd es gut, wenn man von dort aus auch gleich die OS eigenen Apps starten könnte.

    Stimmt, das macht natürlich Sinn - sollte da auch noch rein.

  • Das klingt nicht so doll! Wenn ich das OS immer erst laden muss, dann werde ich es wohl ehr selten nutzen. Ich finde es zwar immer noch extrem cool, dass das hier umgesetzt wird, aber ich kenne mich. Hab mir auf meine SD-Karte schon den aller aller kleinsten SD-Browser kopiert, weil ich nach dem Einschalten (oder Reset) nicht erst Minuten warten will, bis ich das Programm/Spiel auswähle, um dann wieder Minuten warten zu müssen. Ein OS vom Modul gestartet wäre die Lösung für mich. Schade!

  • Das klingt nicht so doll! Wenn ich das OS immer erst laden muss, dann werde ich es wohl ehr selten nutzen [...] Ein OS vom Modul gestartet wäre die Lösung für mich.

    goDos vom EF zu starten, geht natürlich - das hatte ich ja gesagt. Dazu braucht goDos das EF gar nicht unterstützen: man lädt goDos, konfiguriert es wie man lustig ist, lädt die bevorzugte Anwendung (Desktop? Dateimanager?) und wenn alles im Speicher ist, erstellt man daraus eine einzelne ausführbare Datei. Diese ausführbare Datei kannst du dann wie jedes andere Programm auch im EF unterbringen und beim Einschalten starten lassen.

    Nur das Nachladen weiterer Anwendungen vom EF scheint mir zu kompliziert zu sein als das eine Umsetzung Sinn machen würde.

  • goDos vom EF zu starten, geht natürlich - das hatte ich ja gesagt. Dazu braucht goDos das EF gar nicht unterstützen: man lädt goDos, konfiguriert es wie man lustig ist, lädt die bevorzugte Anwendung (Desktop? Dateimanager?) und wenn alles im Speicher ist, erstellt man daraus eine einzelne ausführbare Datei. Diese ausführbare Datei kannst du dann wie jedes andere Programm auch im EF unterbringen und beim Einschalten starten lassen.

    Du meinst so Freezer mäßig? goDos checkt doch (nur) beim Laden welche Laufwerke angeschlossen sind. Ein Freezer-Image starten würde dann vorraussetzen, dass die LW-Konfiguration sich nicht ändert.
    Ich fänd es aber auch praktisch, wenn man alle Module und OS-Apps (die nicht alle gleichzeitig in den Speicher passen) vom Modul "nachladen" könnte. Also entsprechende 16kb vom EF einblenden, ins RAM kopieren (bzw. entpacken) und ausführen. Man sollte sich überlegen, welche Teile immer dem OS zur Verfügung stehen müssen und was man nur gelegentlich braucht. Ich würde das ganze nicht so "modular" machen, dass man beliegig Module und OS-Apps ins EF ROM packen kann und das OS erst schauen muss, was wo ist. Vor dem Flashen sollte man das Paket packen und eine Konfig generieren lassen, wo drin steht, wo was ist. Mann könnte sich ja zwei Laderoutinen vorstellen. Die eine blendet zum laden die entsprechende Bank ein (steht in der Konfig) und kopiert/entpackt den entsprechende Inhalt ins RAM. Die andere Laderoutine ist für Leute ohne EF und läd die Module von Datenträger nach. Auch hier könnte man eine Konfig nutzen, um auch unterschiedliche Speicherorte nutzen zu können. Für das OS sollte das nachladen transparent sein. Die gewählte Laderoutine kümmert sich alleine darum, wie das Programm in den Speicher kommt. Man könnte es entsprechend weiterspinnen, dass man auch eine Laderoutine für NeoRAM, für REU und für TapeCart entwickeln könnte.
    Es gäbe also fest implementierte Module und OS-Apps, die dem OS über eine Konfig immer bekannt sind (Speicherort, Name, ???). Die würde man auch immer im "Startmenü" sehen. Und dann kann man natürlich auch beliebig Programme über den Browser laden von welchem Datenträger auch immer. Da könnte man z.B. am Namen eine OS-App oder ein Modul erkennen (z.B. "app.name" oder "mod.name" oder was auch immer) bei dem der Loader dann weiß, dass es eine OS-App oder ein Modul ist und wie man damit umgeht. OS fremde Apps sollte man ja auch starten können, wo sich das OS aber verabschiedet.
    Ist diese Idee wirklich zu abgehoben?

  • Du meinst so Freezer mäßig? goDos checkt doch (nur) beim Laden welche Laufwerke angeschlossen sind. Ein Freezer-Image starten würde dann vorraussetzen, dass die LW-Konfiguration sich nicht ändert.

    Guter Punkt, hatte ich gar nicht bedacht. Allerdings kann man das lösen. Sollte der Code nicht mehr im Speicher sein, wenn goDos fertig geladen ist, gibt es auch ein separates Modul, das diese Aufgabe erledigt. Könnte man beides als Einsprungpunkt für den "Freeze" nutzen.

    Mann könnte sich ja zwei Laderoutinen vorstellen. Die eine blendet zum laden die entsprechende Bank ein (steht in der Konfig) und kopiert/entpackt den entsprechende Inhalt ins RAM. Die andere Laderoutine ist für Leute ohne EF und läd die Module von Datenträger nach.

    Für das Laden von Datenträgern nutzt goDos die Kernal-Routinen, d.h. diese Laderoutine besteht vereinfacht ausgedrückt aus "Hier ist der Dateiname, gib mir die Daten". Diese Routine wird aber m.E. nicht mit dem virtuellen Dateisystem funktionieren, dass einige EF-Tools bereitstellen. Und das ist der Haken, den ich angesprochen habe: Man müsste ein eigenes virtuelles Dateisystem schreiben, dass *immer* Speicherplatz verbraucht - auch wenn gar kein EasyFlash verbaut ist. Und das ist in meinen Augen ein No-Go. Abgesehen davon: wenn du diesen Nachteil für das EF in Kauf nimmst, dann müsstest du auch Tapecart, oder Batterie-gepufferte REUs/GEO-RAMs mit virtuellem Dateisystem unterstützen. Wo willst du da die Grenze ziehen?

    Oder anders ausgedrückt: Wenn du einen Massenspeicher gewollt hättest, hättest du einen kaufen sollen - und keine Cartridge ;)

    Es wird höchstwahrscheinlich möglich sein, goDos samt einer Anwendung und einem Modul deiner Wahl in das Easyflash zu packen. Bei über 40 KB oder mehr freiem Anwendungsspeicher hast du also Im Zweifelsfall ein FastFormat-DirMaster-DiskCopy-D64Handler-Megatool (muss "nur" jemand schreiben) und einen kleinen Dateimanager sofort beim Einschalten des Rechners zur Verfügung, samt der Möglichkeit in einem komfortablen Dateidialog ein weitere Programme deiner Wahl zu starten. Oder du erstellst dir einfach mehrere goDos-Setups und wählst zwischen denen nach einem Reset ("starte ich jetzt goDos-Write, goDos-Basic oder goDos-Firefox?").

    Es gäbe also fest implementierte Module und OS-Apps, die dem OS über eine Konfig immer bekannt sind (Speicherort, Name, ???). Die würde man auch immer im "Startmenü" sehen. Und dann kann man natürlich auch beliebig Programme über den Browser laden von welchem Datenträger auch immer. Da könnte man z.B. am Namen eine OS-App oder ein Modul erkennen (z.B. "app.name" oder "mod.name" oder was auch immer) bei dem der Loader dann weiß, dass es eine OS-App oder ein Modul ist und wie man damit umgeht. OS fremde Apps sollte man ja auch starten können, wo sich das OS aber verabschiedet.
    Ist diese Idee wirklich zu abgehoben?

    Nö - so würde ich das auch handhaben, nur sehe ich eben keine Möglichkeit das Easyflash da mit einzubinden.

  • Man müsste ein eigenes virtuelles Dateisystem schreiben

    Nein! Schau doch mal in den anderen Thread. Vielleich (bestimmt) haben die es besser erklärt.

    nur sehe ich eben keine Möglichkeit das Easyflash da mit einzubinden.

    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.