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

    @Retrofan & @all
    ich hab den Thread nicht von Anfang an gelesen. Könnte man nicht mal eine Zusammenstellung der Leistungen die erwartet werden
    erstellen, damit sich interessierte Leute finden die im Team ausklabustern wer von was Ahnung hat und beisteuern kann?
    Ich persönlich brauche kein neues OS oder GUI. Aber zusteuern bzw. einbringen würde ich mich.

    Zitat von Rapid Eraser

    Leute, verärgert doch den M. J. nicht! [...] Scheint er mir doch einer der wenigen hier zu sein die eine Ahnung von dem zur Disposition stehenden Thema haben.

    Ich hoffe nicht, dass "wir" ihn verärgert haben. Ich schätze seine anscheinend (ich kann es nicht bewerten) sachkundigen Äußerungen sehr. Ich würde mir nur wünschen, dass es nicht bei Äußerungen bliebe. Denn was nützt es, wenn er der Allgemeinheit erklärt, wie mam die Sache anfassen muss. Davon bekommen wir immer noch keinen, der es tut. Und wer es vielleicht tun will, hat womöglich wenig Bock darauf, dass ihm jemand anderes vorschreibt, wie man den Job zu machen hat. Das, was M.J. schreibt, ist sicherlich alles soweit richtig – aber meines Erachtens müsste genau das, was er sagt, der potentielle Entwickler des Systems/Aufsatz/GUI/Dateimanagers/Desktop (whatever) sagen. Ich hoffe ja darauf, dass er sich noch mehr einbringt und vielleicht mit hexworx zusammen die Eckpfeiler absteckt und das Projekt konkret plant/umsetzt.


    Zitat von Rapid Eraser

    Ganz ehrlich, ein Betriebssystem ist sehr, sehr viel mehr als ein reiner Anwender vermuten mag.

    Da gehe ich stark von aus. Das ist ja bei fast jeder Software so und ein OS ist halt ein großes Stück Software, auch bei nur 64 KB RAM. Ich arbeite ja nun schon über die Hälfte meines Lebens in Software-Projekten und ich weiß, dass ich immer den netteren Teil des Jobs abbekomme. Ich mache halt das, was der Kunde sieht und bekomme (wenn's gut läuft) die Aahs und Oohs ab (und nach Vorstellung des Designs geht der Kunde ja auch davon aus, dass "der Rest" fix gemacht ist) und die Programmierer dürfen sich dann um die 90% des Eisberges kümmern, die unter der Wasser-Oberfläche (sic!) liegen.


    Zitat von Rapid Eraser

    so mögen die zitierten Abschnitte doch vielleicht dazu beitragen das mancher Diskutant bisweilen lieber mal die Füße stillhält und "die Profis"* machen lässt. Das sind auch keine Dummköpfe, und sie haben die - mittlerweile zahlreich geäußerten - Wünsche/Vorstellungen bezüglich eines neuen Betriebssystems durchaus vernommen. Jetzt wäre es doch einfach mal an der Zeit den fachkundigen Leuten das Feld zu überlassen.

    Gerne, also los, Leute ...


    Zitat von Rapid Eraser

    Unabhängig davon was "die Fachleute" unter einem OS verstehen können und sollten sich natürlich auch die anderen Gruppen mal zusammensetzen und sich überlegen was genau sie haben möchten und wie dies realisierbar wäre. Möglicherweise tut es ja - wie schon mal erwähnt - auch ein flexibler Dateimanager, oder halt irgendetwas anderes, das eine Nummer kleiner ist als ein Betriebssystem.

    Dann will ich mal (als Zugehöriger der "anderen"):
    Tja, ab wann ist es ein Betriebssystem? Der Laie guckt dann natürlich erstmal bei Wikipedia:


    "Ein Betriebssystem ist eine Zusammenstellung von Computerprogrammen, die die Systemressourcen eines Computers wie Arbeitsspeicher, Festplatten, Ein- und Ausgabegeräte verwaltet und diese Anwendungsprogrammen zur Verfügung stellt. Das Betriebssystem bildet dadurch die Schnittstelle zwischen den Hardware-Komponenten und der Anwendungssoftware des Benutzers. Betriebssysteme bestehen in der Regel aus einem Kernel, der die Hardware des Computers verwaltet, sowie speziellen Programmen, die beim Start unterschiedliche Aufgaben übernehmen. Zu diesen Aufgaben gehört unter anderem das Laden von Gerätetreibern. [...] Die Aufgaben eines Betriebssystems lassen sich wie folgt zusammenfassen: Benutzerkommunikation; Laden, Ausführen, Unterbrechen und Beenden von Programmen; Verwaltung und Zuteilung der Prozessorzeit; Verwaltung des internen Speicherplatzes für Anwendungen; Verwaltung und Betrieb der angeschlossenen Geräte; Schutzfunktionen z. B. durch Zugriffsbeschränkungen."


    Wollen wir nun ein Betriebssystem? Einen Großteil davon wird man brauchen aber manches ist ja auch schon im C64-Kernal vorhanden (und muss man das neu machen, damit man wirklich ein OS und nicht nur einen Betriebssystem-Aufsatz bekommt?)


    Sicherlich muss das neue OS (whatever) den Arbeitsspeicher verwalten. Da sich wenig Gegenwehr gebildet hat bzgl. des Wunsches von Cyberdyne und mir, dass ein neues System sofort nach dem Einschalten zu Verfügung stehen sollte (sonst jetzt schreien), würde ich das erstmal als "gesetzt" annehmen. Es muss also neben dem RAM des C64 zusätzlich der Speicher (ROM beim EF oder RAM bei der NeoRAM) der angeschlossenen Erweiterung verwaltet werden. Ich würde schon sagen, dass ein Programm, dass dieses leistet und die Ressourcen dann weiteren Programmen zur Verfügung stellt, ein OS (in meinem Verständnis) ist.


    Natürlich soll ein neues OS auch alle modernen Massenspeicher ansprechen und verwalten können, die man an einem C64 angeschlossen haben kann. Muss man dafür Treiber selber schreiben? In meinem laienhaften Verständnis nicht, weil die Geräte sich mit eigener Firmware so dem C64 zeigen, dass er sie mit seinen alten Kernal-Routinen ansprechen kann. Man muss das nicht neu machen, oder? Wenn man sich also auf den C64-Kernal (original oder besser JiffyDOS) verlässt und keine eigenen Treiber für Geräte vorsieht, weil die auch so funktionieren – ist das neue Stück Software dann automatisch kein Betriebssystem mehr? Wenn ja, dann reicht mir eine Art "Windows 3.11 DOS-Aufsatz" vollkommen aus.


    JIffyDOS ist übrigens ein wichtiges Thema. Es ersetzt schon den C64-Kernal und wird sehr gerne (und viel) verwendet, um original Diskettenlaufwerke aber auch das SD2IEC zu beschleunigen. Sollte der Kernal ersetzt werden, dann ist es meines Erachtens zwingend erforderlich, ebensolche, möglichst kompatible Beschleunigungsroutinen einzubauen. Es müsste also im Prinzip nicht der Original-Kernal optimiert werden, sondern ein JiffyDOS-Kernal (der allerdings nicht frei ist). Will sich das wirklich jemand antun?


    Die weiteren Wikipedia-Punkte: Benutzerkommunikation (ja, das soll das neue OS leisten, am Besten mit einem GUI); Laden, Ausführen, Unterbrechen und Beenden von Programmen; (ja, soll es können) Verwaltung und Zuteilung der Prozessorzeit; (ja, eingeschränkt sollte das möglich sein) Verwaltung des internen Speicherplatzes für Anwendungen; (ja, Grundvoraussetzung) Verwaltung und Betrieb der angeschlossenen Geräte; (mit Hilfe der Kernalroutinen, ja) Schutzfunktionen z. B. durch Zugriffsbeschränkungen (das können wir auf dem C64 wohl vergessen).


    ----


    Von der Anwenderseite her gedacht, stelle ich mir das darauf aufsetzende GUI und den sofort verfügbaren Desktop so vor, dass das nach dem Start eine Art Schaltzentrale und gleichzeitig "Wohnzimmer" abbildet, ähnlich wie man es von modernen Mobile-GUIs (und auch vom GEOS Desktop) kennt. Man sollte vor allem weitere Anwendungen starten können – und zwar die, die auf dem neuen System aufsetzen (ich nenne sie zur Unterscheidung mal Apps), wie auch klassische C64-PRGs. So war GEOS (bzw. der Desktop) schon sortiert und so sind es viele GUIs noch heute. Es sollten also Icons der verfügbaren Programme angezeigt werden.


    GEOS verschwendet aber auf dem Desktop viel Platz, den man besser nutzen kann, wenn man sich in der Geschichte der Betriebssysteme (ja, natürlich der GUIs und Desktops) umsieht. Windows Vista war zwar nicht das erste OS mit Widgets (hier Gadgets genannt) aber ich finde dessen Screen-Aufteilung für einen Low-Tec-Rechner sehr geeignet. Man hat hier eine Randspalte, in der Zusatz-Infos und -Funktionalitäten angezeigt werden. Auf modernen Systemen werden Widgets auf einem getrennten Screen (iOS) oder frei mit den App-Icons vermischt (Android) dargestellt. Für einen C64 fände ich aber die Vista-Darstellung am Angenehmsten. Bei einem Offline-Rechner kann man hier klassische Desk-Accessories, wie den Taschenrechner oder einen lokalen Kalender oder eine Uhr (wenn angeschlossen) anzeigen lassen, mit Zusatzhardware/Treibern vielleicht auch die Temperatur(en) im Inneren des Rechners oder die Daten einer am Userport angeschlossenen Wetterstation. Vielleicht könnte man auch eine Datei-Suche implementieren.


    Mit Online-Anbindung wären so Widgets denkbar, wie Datum/Uhrzeit (per Time-Server), Online-Kalender, RSS-Feeds, Wetterdaten, Chat und noch hunderte weitere Dinge. Ich stelle mir vor, dass das System eine Art API anbietet, die man als 3rd-Party-Entwickler nutzen kann, um eine Kombination aus lokaler Darstellung und einem externen Webdienst für den C64 zu ermöglichen. Natürlich wäre eine Randspalte vom Platz her sehr eingeschränkt, sodass ich mir vorstellen könnte, dass ein Widget bei Bedarf auch das "Hauptfenster" nutzen kann. Was den knappen Speicher angeht: Die meisten Widgets müssen nur ab und zu mal die Darstellung refreshen, sodass sie sich quasi einen Speicher-Slot teilen und vom System durchgeschaltet (also geladen und überschrieben) werden könnten. Es währen mehrere gleichzeitig sichtbar aber nur jeweils eines wirklich aktiv)


    Im Gegensatz zu GEOS (und Mac OS und Windows ..) würde ich den Programm-Starter etwas mehr von der Datei- und Systemverwaltung trennen. Das alte Windows bis Version 3.x hatte ja auch einen Programm- und einen Datei-Manager – und auch bei Android und iOS gibt es eigenständige Apps, um Dateien zu verwalten. Ich plädiere für eine Aufteilung des Hauptscreens in "App-Launcher", "Datei-Verwaltung" und "System-Verwaltung/Einstellungen".


    Insgesamt stelle ich mir also die Oberfläche des Systems so vor, dass sie sofort erscheint, die Möglichkeit bietet, Programme zu starten (die wichtigste Fähigkeit des "Desktops") und weitere Dienste zur Verfügung stellt, die sofort verfügbar sind. Über die Dateiverwaltung kann man das tun, was man üblicherweise damit tut: Dateien sortieren, verschieben, kopieren, umbenennen und löschen. In der System-Verwaltung kann man Treiber (für Mäuse und andere Geräte) einbinden, konfigurieren, Einstellungen vornehmen usw.


    Das soll natürlich nicht das endgültige Stadium der Funktionalitäten sein aber alles weitere würde dann über zusätzliche Widgets und vor allem "Apps" zur Verfügung gestellt werden. Denn es ist, wie bei anderen Systemen auch: man startet auch nicht jeden Tag Windows, nur um Dateien von A nach B zu schieben. In erster Linie wird man zusätzliche Programme starten wollen, mit denen man dann spezifische Aufgaben erledigt. Das könnte ein Browser sein oder ein Grafikprogramm oder ein Spiel.


    Das also zu meinen Vorstellungen als potentieller Nutzer.


    Zitat von Rapid Eraser

    Ich selber halte mich nicht für unbedarft, hätte aber noch eine Menge zu lernen bevor ich mich in der Lage sähe ein (meiner Ansicht nach) vernünftiges OS zu entwerfen.

    Schade. Aber wenn man die Anforderungen an ein "System" etwas reduzieren würde, könntest du dir dann evtl. vorstellen, mitzuwirken?


    Zitat von Rapid Eraser

    "Besser" als GEOS würden wir vielleicht werden können, dabei dann aber nicht auch noch "schneller" als GEOS. Tatsächlich würde mich persönlich die Planung eines neues OS+GUI eigentlich auch nur dann reizen wenn man dafür eine SCPU+SuperRAM oder vergleichbares voraussetzen könnte.

    Dazu meine 2 ct.: ich glaube, es könnte auch schneller sein. Gut, bestimmte Sachen werden natürlich kaum zu beschleunigen sein. Aber vieles eben doch. Der Grafik-Aufbau ließe sich beschleunigen (z.B. statt Linien, Flächen und Schatten nur noch Flächen im 8-Pixel-Raster) und das hat einiges mit der "gefühlten Performance" eines Systems zu tun. Bei Nutzung von JiffyDOS wären wahrscheinlich auch die Dateiroutinen schneller. Und keiner hier setzt einen komplett unveränderten C64 voraus – jeder geht von zwingend vorgeschriebener Zusatz-Hardware aus, nur der Umfang unterscheidet sich.


    Sollte sich herausstellen, dass ein neues OS zwingend eine SCPU oder ein TC64 oder eine andere Hardware voraussetzt, die sich in der 300€-plus-X-Region bewegt, dann würde ich dem Projekt alles Gute wünschen, wäre dann aber raus, weil ich nicht bereit bin, soviel Geld auszugeben, nur um ein anderes OS laufen lassen zu können.


    Zitat von Rapid Eraser

    Alles andere wird lediglich ein Krampf und überhaupt vergebliche Liebesmüh sein - wie die zahlreichen bereits existieren Betriebssysteme für den C64, für die sich keine Sau jemals interessiert hat, wohl nahelegen.

    Vor allem haben sich ja auch die Lösungen nicht durchgesetzt, die teure Hardware-Aufrüstungen (allem voraus die SuperCPU) verlangten, wie Wheels oder CLiPS. Im Vergleich dagegen war GEOS eine Erfolgsgeschichte.

    Zitat von Paradroid

    Könnte man nicht mal eine Zusammenstellung der Leistungen die erwartet werden erstellen


    Ich fasse mal die Punkte (auf Basis von Cyberdynes Wünschen) zusammen, die schon Mehrfachnennungen hatten (bei Unterstützung durch mich, habe ich mich einfach mit eingetragen, selbst wenn ich den Punkt zuvor noch nicht selbst genannt hatte):


    1. Schneller, automatischer System-Start (EF/GeoRAM) (CD/RF)
    2. Unterstützung für gängige Maustypen (CD/RF)
    3. Unterstützung für 15xx-Laufwerke und SD2IEC (CD/RF), gerne auch CMD-HD, IECATA, Tapecart ...
    4. Starten von normalen C64-Programmen (CD/BB/RF)
    5. Starten von New-OS-spezifischen Apps. Das OS verlinkt gefundene Erweiterungen beim Start und Datenträgerwechsel automatisch. (CD/RF)
    6. DOS-Funktionen per Drag&Drop: Kopieren (Dateien und Disketten/Images), Verschieben, Löschen, Umbenennen (CD/RF)
    7. Datei-Viewer/Player für möglichst viele Formate (CD/BB/RF)
    8. PIM-Funktionen: Kalender, Adressbuch ... (CD/RF)
    9. Optisch ansprechend (CD/RF)


    Netzwerk/Online-Funktionen:
    1. SNTP-Unterstützung (Timeserver) für Datum/Uhr/Kalender (CD/RF)
    2. Systemspezifische Netzwerk-Dateiübertragung (CD/RF)
    3. Wetter-Widget (CD/WW/RF)


    New-OS-Programme (Apps):
    1. Systemspezifischer Text-Chat (CD/BB/RF)
    2. Mini-Webbrowser (eher als eigenständige App, allerdings im New-OS-Look&Feel) (CD/BB/RF)
    3. Spezielle Clients, die Kommunikation mit Smartphones (und anderen Geräten) im WLAN ermöglichen (CD/RF)
    4. Texteditor (BB/RF)


    Die Liste kann gerne erweitert, zusammengestrichen oder diskutiert werden.

    Ich habe mal ein paar Fragen zum Dateisystem und hoffe, dass die Leute, die sich mit sowas auskennen, hier noch mitlesen und ganz neutral die Fragen beantworten können.

    Zitat von M. J.

    Ein modernes OS bedeutet, mit Dateien umgehen zu können, die größer sind als 64kb.

    Das sehen einige hier ja durchaus anders – und ich glaube auch nicht, dass man unbedingt größere Dateien benötigt (da die wahrscheinlich entstehenden Programme eher klein sein werden und auch keine großen Dateien erzeugen werden müssen).


    Aber mich interessiert doch, was du mit "umgehen" meinst. Im Directory angezeigt werden sie ja, wenn die Firmware des Massenspeichers das entsprechend unterstützt. Wenn ich also auf einem SD2IEC ein D64 liegen habe, zeigt mir das Directory ein PRG mit einer Größe von 689 Blöcken (oder bei FIBR 171 KB) an. Meinst du mit "umgehen", dass der C64 solche Dateien (also z.B. Diskimages) nicht erzeugen oder darin lesen kann?


    Ich finde die Nachteile bei b) sehr gravierend und habe die Befürchtung, dass "setzt eine Speichererweiterung voraus, immenser Programmieraufwand, macht eigene Schnellader notwendig" doch viele potentielle Entwickler abschrecken könnte, während ich bei a) "klein, kompakt, Man braucht nicht viel Neues zu entwickeln" sofort glänzende Augen bekomme.


    Wenn ich der (natürlich nicht professionellen) Betriebssystem-Definition aus der Wikipedia folge (siehe Posting 224), dann stellt "die Verwaltung und der Betrieb der angeschlossenen Geräte" nur einen Teilaspekt eines Betriebssystem dar, wie auch die Zugriffsbeschränkungen (auf die wir ja wohl auch verzichten müssen). Von daher finde ich es etwas unfair, wenn du behauptest, ohne Neuprogrammierung der Kernal-Routinen hätten wir nur einen GUI-Aufsatz. (Wobei ich selbst das nicht verwerflich fände und sich auch Microsoft in den Windows-Frühzeiten nicht zu schade dafür war).

    Zitat von M. J.

    "Neues OS" kann aus meiner Sicht heute nur heißen, Kernal und Co über Bord zu werfen, eigene Dateisystembehandlung (mit Dateien > 64kb) verwenden und Hardwarezugriffe nur noch auf Blockebene (mit Zwischenschaltung von Caches) zu realisieren.


    Aber weil mich die Sache mit den Lade- und Speicherroutinen nicht loslässt: Das Final Cartridge III ist ja eine beliebte Erweiterung für den C64 und bietet neben Freezer und Basic-Erweiterung auch Schnell-Ladefunktionen, die ähnlich kompatibel sind, wie die von JiffyDOS. Die wahrscheinlichste Annahme von mir lautet, dass das FCIII u.a. den Kernal des C64 ersetzt (wie es JD ja auch tut). Stimmt das?


    Falls ja, stimmt meine Annahme auch, dass man eine solche Funktionalität mit dem EasyFlash 1 (nicht 3) nicht nachbilden kann? (Im EF3 gibt es ja extra Funktionen, um den Kernal zu ersetzen, die dem ersten EF wahrscheinlich fehlen).


    Falls meine zweite Annahme nicht stimmen sollte, könnte man dann nicht (sofern wir die Rechte abklären könnten) die FCIII-Routinen als Basis für unser System nehmen? Auf große Dateien könnte ich gut verzichten aber es wäre natürlich klasse, wenn man nicht auf JiffyDOS angewiesen wäre, um Dateizugriffe zu beschleunigen.

    Ich haette uebrigens noch eine Idee fuer ein Feature, das echt praktisch sein koennte. Und zwar fuer diejenigen, die keine "echte" Maus fuer ihren C64 haben. Es waere praktisch, wenn man das OS auch komplett per Tastatur bedienen koennte, oder per Joystick in einer "bequemen" Variante. Es gab z.B. mal im Opera-Browser eine tolle Funktion, die ich heute vermisse, naemlich per Strg + Pfeiltasten konnte man sich durch saemtliche Links auf einer Website hangeln. Und zwar nicht so wie bei anderen Browsern oder GUIs, wo man sich per "Tab"-Taste durch alle Steuerelemente "durchcyclet", sondern man konnte tatsaechlich durch die Verwendung der Pfeiltasten schnell zum gewuenschten Button / Feld / Link etc kommen.


    Also im Grunde eine Art "intelligenter Mauspfeil", der beim Druecken von z.B. CTRL + nach links auf das naechstgelegene Steuerelement springt, welches sich links vom derzeitigen Element befindet. Sowas koennte durchaus hilfreich sein. Ist vielleicht nicht das wichtigste Feature, aber wenn man eben keine "echte" Maus hat, sondern nur so eine Pseudo-Maus oder einen Joystick, dann kann es echt aetzend sein, damit einen Mauspfeil bewegen zu muessen.

    Zitat von ZeHa

    Es waere praktisch, wenn man das OS auch komplett per Tastatur bedienen koennte

    Das sollte man auf jeden Fall im Hinterkopf behalten.


    Meine Fragen von oben darf übrigens jeder beantworten, der sich dazu in der Lage sieht. Es muss nicht unbedingt der Zitierte sein, falls er sich hier nicht mehr zu Wort melden möchte.


    Auch wenn es jetzt wieder komplett untechnisch wird, möchte ich doch kurz den Stand der Dinge beim Mockup-Basteln mitteilen: Mit den Verzeichnislisten bin ich gut weitergekommen, jetzt sitze ich erstmal an einem Speichern-Dialog. Echt interessant, was man zu sehen bekommt, wenn man sich Datei-Dialoge aus 40 Jahren IT-Geschichte anguckt, um sich inspirieren zu lassen.


    Auch wenn es noch keine GUIs zu sehen gibt, so kann ich euch das Warten vielleicht mit einem Splash-Screen versüßen:



    (mein Arbeitstitel des fiktiven Betriebssystems, für das ich ein GUI entwerfe – jedes Kind braucht ja einen Namen)

    Schick. Angelehnt an "Nexus"? Auf das Wort war ich kürzlich durch den gleichnamigen Werkzeughersteller gestoßen.


    Zum FC III: https://github.com/mist64/final_cartridge


    Genauer angeschaut hatte ich mir es aber noch nie. Ich hab ja auch ein FC III hier am Laufen, aber wann sich da wie/wo/was einblendet habe ich auch noch nicht geblickt.

    Zitat von Hexworx

    Angelehnt an "Nexus"?

    Da spielten verschiedene Sachen rein. Zu aller erst, dass ich Griechenland-Fan bin. Und da fällt natürlich auf, dass viele griechische Wörter/Namen auf "os" enden. NaxOS klingt (auch dank des Xs) gut und man hat (auch international) keine Probleme mit der Aussprache. Das Wahrzeichen der größten Kykladen-Insel ist die (abgebildete) Portara, ein symbolisches Tor. Tor ... zu einer neuen Welt, Tor vs. Fenster/Windows ... Naja, ist ja nur ein Arbeitstitel, irgendwie muss man die Dokumente ja nennen.


    Zitat von Hexworx

    Zum FC III: github.com/mist64/final_cartridge

    Klingt eigentlich ganz gut: "This project is the reverse-engineered and documented Commodore 64 cc65/ca65/cl65 assembly source code of the first bank of the "Final Cartridge III". [...] Bank 0 contains the BASIC and editor extensions, the floppy and tape speeder, fast format, the centronics printer driver, and the monitor. The original code is (c) Uwe Stahl and Riska B.V. Home & Personal Computers. The assembly version, the comments, the partitioning into separate files and the linker configuration was done by Michael Steil mist64@mac.com; this work is in the public domain."


    Da hätten wir doch unsere beschleunigten Disk-Routinen. Jetzt stellt sich die Frage, ob es eine Technik gibt, die z.B. in einem EasyFlash 1 zum Laufen zu bekommen (um meine Frage von oben etwas zu simplifizieren).

    Zitat von Cyberdyne

    Welche Betriebssysteme meinst du? JiffyDOS, SpeedDOS+, DolphinDOS, ...?

    Nein, ich meinte keine Floppyspeeder sondern Ace/Asterix/Contiki/CPM/CS-DOS/DOS-65/GeckOS/GEOS/Lunix/NT-DOS/ShadOS/Unix 128/Wings/JOS/Clips/Workbench/ost/smos/bos/commix* und wie sie alle heissen. Und da gibt's noch mehr; pico]os z.B. schaut mir interessant aus.


    Zitat von Retrofan

    Aber wenn man die Anforderungen an ein "System" etwas reduzieren würde, könntest du dir dann evtl. vorstellen, mitzuwirken?

    Nein, denn bisher halte ich diesen Thread für ein Paradebeispiel für sowirddasnix. Sorry.



    PS: Versucht doch mal eure Wunschzettel an die Entwickler der o.a. Systeme zu schicken. Die freuen sich bestimmt über Feedback. ^^



    * Liste mal blind aus http://www.lemon64.com/forum/v…ic.php?t=38060&highlight= übernomen

    Mir gefällts. "Nexus": Verbindung, Verknüpfung, Gefüge, Zusammenhang etc. Passt ja auch schön.


    Irgendwas mit "hub" würde ansonsten vielleicht auch noch gehen, à la "bizhub" (Konica Minolta). Aber erst mal sollte es vielleicht ein laufendes Programm geben... :) .


    Hab die letzten beiden Tage meinen Bitmap-Code mal komplett umgestrickt/umgeschichtet/neu organisiert und bzw. um auch eine Sprung-Tabelle anzulegen. Dann lief es natürlich nicht mehr ^^ . Es läuft aber nun zumindest *fast* wieder. Ein Problem muss ich noch suchen... Nun ja...


    EDIT by FXXS: Posting geteilt wegen Threadsplit.

    Zitat von Retrofan

    kann vielleicht mal wer meine eher technischen Fragen (zum Thema FCIII und Dateien >64KB) aus Post 224 beantworten

    Da ja hier keiner in der Lage zu sein scheint (komisch, einige behaupten ja, technisch Ahnung zu haben – aber wollen ihr Wissen dann wohl doch nicht teilen), konnte mir ALeX telefonisch auf die Sprünge helfen. Also, seiner Meinung nach hat das FCIII keinen eigenen Kernal (wäre wohl technisch auch eher schwierig zu realisieren), sondern modifiziert die Laderoutinen (des Computers, wie auch der Floppy) on-the-fly (lädt also wohl auch temporär Code ins Floppy-RAM, während das SD2IEC das FCIII direkt unterstützt), um die Übertragung zu beschleunigen (wenn ich das falsch verstanden habe, bitte ich um Berichtigung). Das hat den Nachteil, dass das ganze nicht so kompatibel ist, wie JiffyDOS – aber den Vorteil, dass man die Technik für ein eigenes OS auf EF-Basis missbrauchen könnte.


    Denn das konnte mir ALeX auch bestätigen: das EF1 kann keinen Kernal ersetzen. Aber da das FCIII das auch gar nicht tut, könnte man dessen Routinen für eigene Zwecke im EF verwenden. Zudem scheinen sie Public Domain zu sein.


    Und hier hat ALeX die verschiedenen Modul-Modi zusammengegefasst. Wenn man sich z.B. beim EasyFlash für den 3. Modus 7 entscheidet, dann wäre das Original Kernal nutzbar und man hätte einen flexiblen 16 KB Bereich, den man 64-fach (aus den 1000 KB) in Sekundenbruchteilen umschalten kann. Man könnte also z.B. die API-Routinen außerhalb des Bereichs anlegen und in die 16 KB jeweils Desktop und andere Apps einblenden, die auf die permanente Toolbox für IO, GUI etc. zugreifen könnten. Da wäre dann (ja nach Systemgröße) auch noch einiges an RAM-Speicher für Dokumente etc. frei. Einige hier sind ja immer noch skeptisch, was das EasyFlash als Lösung angeht aber ich finde es weiterhin recht interessant.

    Zitat von Retrofan

    seiner Meinung nach hat das FCIII keinen eigenen Kernal

    Deswegen konnte ich wohl auch keinen finden...


    Ich hab auch noch nicht begriffen, wie/wo die zusätzlichen BASIC-Befehle abgegriffen werden. Merkwürden Teil...


    Zitat von Retrofan

    sondern modifiziert die Laderoutinen (des Computers, wie auch der Floppy) on-the-fly

    Und wie geht das nun wieder?


    Kann uns eigentlich auch (fast) egal sein.



    Zitat von Hexworx

    Es läuft aber nun zumindest *fast* wieder. Ein Problem muss ich noch suchen... Nun ja...

    Läuft wieder.


    Bzw. lief... ^^


    Wollte vorhin noch was optimieren, was noch mal richtig Speed bringen könnte/sollte, nu is' es wieder voll kaputt :D . Wieder was zum suchen.... :search: . Halbe Stunde guck ich mir das Theater noch an, dann :zzz: .


    Ansonsten: Maus-Zeiger gebastelt und ist drin, aber hat noch keine wirkliche Funktion. Das ist aber ja auch schon ein (erstes) GUI-Feature. Der Bitmap-Anzeige-"Typewriter"-Part soll eh völlig autark bleiben. Ein paar Kleinigkeiten sind da aber noch dran zu machen und eine weitere sinnvolle (fehlende) Funktion ist mir vorhin noch eingefallen, die ich (demnächst) da noch einpflegen werde.


    Dann geht's jetzt also erst mal an den "Brocken" Maus-/Tastatur-Steuerung/-abfrage. Muss ich mich aber erstmal noch reindenken :roll: .

    Mauszeiger läuft (erstmal nur im Joystick-Modus). War nun auch keine Kunst.


    Gestern und heute aber erstmal noch einen Code-Teil arg verbessert:


    Beim Verarbeiten/Überlesen der Steuerzeiten hatte ich, je nach Länge, mehrfaches 'INC $xxxx' drin (teils bis zu 6x). Dann wurde 'LDA/CLC/ADC/STA' draus, was schon mal einiges besser war (z. B. 18 vs. 9 Bytes). Dabei war die ganze Zeit auch 'y' frei -> 1 Byte! Hat insgesamt >120 Bytes Ersparnis gebraucht. Musste aber einiges für umgestrickt werden (und die Fehlersuche... <X ). Egal - läuft nun. Somit ist der ganze Anzeige-Part auf ziemlich genau 2,2K geschrumpft (ohne Test-Text). Da ist wohl auch langsam das Ende der Fahnenstange erreicht. Zumindest seh ich nix mehr. Ein paar Bytes werden aber noch dazu kommen, wenn ich noch die ein/zwei (fehlenden) Features reinbastele. Dürften aber max. vielleicht 100-200 Bytes werden.


    Jetzt ist erstmal nächste Baustelle, die 'Buttons' anklickbar/ausführbar zu machen. Vom Prinzip her ist es simpel. Ich muss bloß erstmal gucken, wie ich das schick verwalte, da jede 'APP' ja mit anderen Buttons um die Ecke kommen kann (und die Position ja auch übergeben werden muss). Noch keine richtige Idee... :silly: , aber wird schon kommen ;) .