Ich habe 2 Fonts für das 8-Bit-Browser-Projekt gepixelt. Die sind aufgebaut, wie klassische C64-Monospaced-Fonts, allerdings mit ISO-8859-15 Encoding – und angedacht war, die Breitentabellen in die ersten 16 (platzsparend) bzw. 32 (schneller) Chars (sonst frei für Steuerzeichen) zu schreiben.
Was ich noch vergessen hatte, dazu zu schreiben: Das tolle daran wäre, dass man zum Verändern von New-OS Fonts die alten Char-Editoren weiterverwenden kann. Selbst das wilde Pixelmuster in den ersten 16 oder 32 Zeichen könnte man mit ein wenig Geschick umpixeln, um die Zeichenbreiten zu verändern.
Bezüglich der EFx noch einmal der Hinweis: Die Verwendung der Roms ist alles andere als trivial!
Im Char-Nachbarthread klingt das aber irgendwie simpler als hier.
Mit FAT16 meinte ich nichts Spezielles. Das war nur ein aus dem Ärmel geschütteltes Beispiel für ein anderes Dateisystem. Man hätte auch jedes andere nehmen können: CP/M, ProDOS, AmigaDos oder was auch immer. Wer Spaß daran hat, kann den passenden Treiber dafür schreiben und meinetwegen auch die dafür notwendigen Diskettenroutinen.
Für ein PC-OS mögen ja nachladbare Treiber für fremde Dateisysteme zum guten Ton gehören aber wird hier nicht mit Kanonen auf Spatzen geschossen? Es reicht doch, die üblichen, vorhandenen Massenspeicher, allen voran das SD2IEC (nativ), zu unterstützen. Wenn der normale Kernal ein natives SD2IEC Verzeichnis öffnen kann, warum sollte das auf einmal für ein neues OS ein Problem darstellen? Die Arbeit, die Daten dem C64 verständlich zu präsentieren, tut doch die externe Hardware (bzw. dessen Firmware) selber.
Hat mal jemand darüber nachgedacht, dass bei REL-Dateien $FF und/oder $00 in bestimmter Kombination vom DOS der Laufwerke als ein Hinweis auf einen nur teilweise gefüllten oder gar vollständig leeren Datensatz interpretiert werden?
Ganz ehrlich: Ich sehe auch immer noch keinen Grund, REL oder andere, noch zu erfindende Dateitypen, zwingend zu verwenden. Warum soll der C64 auf einmal mit "übergroßen" Dateien zurechtkommen? Es wird ihm doch grundsätzlich schon nicht zugetraut, ein GUI-System zu fahren und dann soll er zusätzlich mit Dateien über 64 KB klarkommen. Wofür? Ich denke nicht, das man so schnell Programme für das neue OS schreiben wird, die über 64 KB Code und Ressourcen hinausgehen – die Programme werden eher kleiner als bisher, da weniger freier Speicher und dafür Zugriff auf Systemroutinen. Und wenn's doch eng wird, gäbe es sicherlich eine Lösung, wie man sowas per Bankswitching etc. auf dem EF zum Laufen bekommt (wie die 512K-Modul-Games (Ocean-Schema)).
Und ich glaube auch nicht, dass es sehr schnell Programme geben wird, die deutlich über 64 KB Daten speichern müssen. Klar, es wäre sicherlich toll, mit einer C64-Textverarbeitung 1 MB Text in Häppchen bearbeiten zu können – aber wer macht das denn wirklich? Ich denke, wenn das neue OS mit dem klar kommt, mit dem auch der jetzige Kernal klarkommt, dann reicht das erstmal. Ein NeoPublish wird es nicht geben und ein RSS-Reader oder Wetter-Widget speichern erstmal gar nichts.
Das Erkennen von "neuen" Programmen könnte man dadurch erreichen, indem
1.) , wie RetroFan beschrieben hat, die Namen der neuen PRG-Dateien eine besondere Kennung erhalten.
2.) die ersten 256 Bytes des Programms geladen werden und geguckt wird, ob sich darin ein bestimmter noch zu definierender Header zeigt.
Der Vorteil der Namenslösung wäre allerdings, dass es deutlich schneller ginge, weil man nicht in jedes einzelne PRG hineingucken muss. (Das ist ein Grund, warum FIBR nicht zu den schnellsten Dateibrowsern gehört – er liest alle Dateien kurz an, um die Startadressen zur Dateitypen-Erkennung zu ermitteln)
Welche elementaren Dateiroutinen soll das OS überhaupt bereitstellen? (Dateikopieren z. B. gehört nicht dazu, da es sich aus mindestens zwei anderen Routinen zusammensetzt und den Programmen nicht resident zur Verfügung gestellt werden muß.)
Dateikopieren gehört in den Desktop, Namensänderungen auch. Programme sollten Dokumente laden und speichern können, vielleicht auch Ordner anlegen, wenn es das Dateisystem unterstützt (wäre aber auch verzichtbar). Einheitliche Datei-Auswahl-Dialoge gehören auch ins System.
es reicht doch wenn neue programme alle mit $ffff oder $0000 anfangen. Man muss es ja nun nicht ueberkomplizieren.
Ich habe das Gefühl, dass Überkomplizieren hier manchmal sehr geliebt wird. So, wie ich vielleicht bei der Darstellung (zu?) vieles umkrempeln möchte, so wollen andere am liebsten einen kompletten Linux-Kernel auf den 6510 packen.
Erfundene Startadresse $FFFF oder 0000 ist aber nicht abwärtskompatibel und könnte auf bisherigen C64 zu Abstürzen führen.
Das wäre natürlich ein Drama, wenn ein C64-Programm nicht absturzfrei läuft und das ganze System in die Tiefe reist. Dann muss man erst wieder 3 Minuten booten und alle Programme starten und die ganzen Tabs und Fenster reorganisieren.
Hey, es ist ein C64 und den starte ich am Tag 20 mal neu (wenn ich ihn benutze).