Hello, Guest the thread was called2.8k times and contains 61 replays

last post from Korodny at the

Modul (Flash-Speicher, WiFi ...) und passendes grafisches OS

  • Aber was ist mit dem EasyFlash und seine einblendbaren 8/16K-Blöcke – wäre das nicht eine Technik, die man erweitern könnte für beschreibbaren Flash-Speicher?


    Vielleicht wäre es möglich, das EasyFlash mit statischen RAMs zu erweitern. Die hierfür benötigten Signale, insbesondere WE, sind beim EF vorhanden und werden z.B. zur Programmierung des Flash-Speichers vom C64 aus genutzt.



    Wenn man wenig Aufwand betreiben will, ergänzt man zu jedem der beiden Flash-Chips jeweils ein statisches RAM. Das LED-Bit (Adresse $DE02 Bit 7) könnte man zur Umschaltung zwischen der Flash- und der RAM-Betriebsart verwenden.

    Allerdings wäre hier die Umschaltung zwischen Flash und RAM starr und unflexibel. Für ein OS wäre es besser, wenn man die Umschaltung von Flash und RAM für den Lo- und Hi-Adressbereich getrennt einstellen könnte.



    Ich gehe hier kurz auf die Funtionsweise des EF ein, um die angedachten Änderungen für ein neues Speichermodul im Vergleich zu erläutern. Das EF nutzt 6 Bit als Bankregister. Mit 6 Bit lassen sich 64 Speicherbänke adressieren. So erhält man mit 64 * 8 KByte Zugriff auf die vollen 512 KByte eines Flash Chips. Da beim EF je ein Flash Chip fest dem Lo- und dem Hi-Adressbereich zugeordnet ist, kann man insgesamt 1MByte nutzen. Das Bank-Register wird für beide Flash-Bausteine gemeinsam verwendet.



    Für eine Nutzung als OS-Speichererweiterung sollte man das Bank-Select Register von 6 auf 8 Bit erweitern und doppelt ausführen, für den Lo-Adressbereich $8000-$9FFF und den Hi-Adressbereich $A000-$BFFF getrennt. Somit könnte man 256 Speicherbänke zu je 8 KByte adressieren, und zwar für den Lo- und Hi-Adressbereich einzeln wählbar.


    Die beiden zusätzlichen Bank-Select Bits können genutzt werden, um einen von maximal vier Chips zu je 512 KByte anzusteuern (CS0..CS3). Die Speicherchips sind nicht mehr fest einem Adressbereich zugeordnet, stattdessen hat der Lo- und Hi-Speicherbereich sein eigenes Bankregister und kann somit auf eine beliebige Speicherbank zugreifen.



    Nehmen wir also an, es gäbe so ein Speichermodul, dann hätte es folgende Register:


    Config: Auswahl Modus (Aus, 8K Mode, 16K Mode, ...)

    BankLo: Speicherbank im Lo-Bereich $8000

    BankHi: Speicherbank im Hi-Bereich $A000


    Bei dem Beispielmodul können bis zu vier Speicherchips genutzt werden.

    CS0: Bank $00 - $3F: 512K Flash, hier bootet das Modul

    CS1: Bank $40 - $7F: 512K Flash oder RAM möglich

    CS2: Bank $80 - $BF: 512K Flash oder RAM möglich

    CS3: Bank $C0 - $FF: 512K Flash oder RAM möglich



    Nach einem Reset ist der 8K Mode aktiv und BankLo enthält den Wert Null und adressiert damit Bank $00, die erste Bank des Flash Chips.

    Hier ist das Bootprogramm des Moduls / OS abgelegt.


    Der Anwender könnte hier eine Auswahl treffen, ob er das OS starten möchte, oder eine 8K oder 16K ROM Modul Emulation, oder ob er die Speichererweiterung abschalten möchte, dann gelangt er ins BASIC.



    Die 8K Flash Bänke könnten unterschiedliche OS-Bestandteile (Libraries) enthalten, die ohne jede Kopier- oder Ladeaktion direkt im Flash ohne Verzögerung gestartet werden können.

    Dies würde sich anbieten für Grafikfunktionen, Menüdarstellung, Dialoge, Unterschiedliche Zeichensätze mit passendem Treiberprogramm zur Textausgabe, Dateiverwaltung, Bilderanzeige, etc.


    Programmteile, die eigenen RAM benötigen, die aber nicht auf den Hauptspeicher zugreifen sollen, können zu Beginn in eine RAM-Bank kopiert werden und sie laufen dann dort ab. Vorausgesetzt, dass 8 KByte ausreichen für Programmcode und Daten.

    Das würde sich für Programme anbieten, die nebenbei mal im Hintergrund laufen, wie z.B. Kalender, Timer / Wecker, Notizblock, Forum64 Newsticker...


    Größere Programme können im 16K Mode laufen. Dabei kann in einem Adressbereich z.B. ein Programmteil laufen und im anderen können die Daten liegen.

    So ließe sich ein aufwändigerer Texteditor oder eine Programmierumgebung mit Editor / Compiler oder ein Malprogramm realisieren. Das Programm wird dabei in 8 K Blöcke unterteilt, z.B. Dateioperationen, Texteingabe, Compiler, Kontexthilfe. Die bearbeiteten Daten können den kompletten freien RAM (512K) belegen, davon sind dann jeweils 8 K gleichzeitig im Zugriff, z.B. ein Bild aus einer Animationssequenz oder der Teil eines Programmquelltextes.



    Auszug der EF Betriebsarten:

    ..... 8K Mode: 8 KiB at $8000, ----- at $A000

    .... 16K Mode: 8 KiB at $8000, 8 KiB at $A000

    (Quelle: EasyFlash-ProgRef.pdf, Abschnitt 2.1 Flash Memory Configuration)

  • Finde ich persönlich zu einschränkend. Jedes Mal, wenn man eine andere Utility haben möchte, muß dafür extra ein Menü der OS-Oberfläche aufgerufen werden.

    Verstehe ich nicht, wie willst du denn sonst zwischen Utilities wechseln, wenn nicht per Menü?

    DIe Frage ist, ob es für einen reinen Textmodus überhaupt genügend Anwendungen gibt. Typische Spiele (bis auf harmlose Vertreter wie Minesweeper und Superhirn) fallen da schon komplett heraus.

    Spiele brauchen (von ganz wenigen Ausnahmen abgesehen) beim besten Willen kein OS. Und bei bestehenden C64-Anwendungen liegt der
    Anteil der Software, die im Grafikmodus läuft, irgendwo bei... 5 Prozent?


    (Edit: im Übrigen laufen 99% aller Spiele - von Kleinigkeiten wie Titelbildschirm abgesehen - im Textmodus)


    Der Textmodus ist optimal für alle Diskettenoperationen und Dateimanagement, einen "Launcher", Textbearbeitung im weitesten Sinne, Chat, Anzeige großer Textmengen (Mailbox, einfacher, C64-gerechter Online-DIenst/"Konverter"), Char- und Sprite-Editoren usw. Also im Grunde das, was man heute so brauchen könnte.


    Was nicht geht, ist die Kategorie "Ich will einen Windows-PC imitieren" - also Sachen wie Browser, Twitter und WYSIWYGPYHWA1TO ("What You See Is What You Get Provided You're Happy With A 1965 Typewriter's Output").

    Meine persönliche Ansicht ist ohnehin, daß der Fensteransatz heutzutage nicht mehr aktuell ist. Soll heißen: Fenster sind auf dem C64 eher überflüssig.

    Sehe ich genauso. Fenster brauche ich nur für (a) Multitasking oder (b) Anwendungen die mehrere Projektdateien gleichzeitig offen haben. Also auf dem C64 maximal, wenn ich unbedingt einen Explorer-ähnlichen Dateimanager implementieren will - wer das will, soll Fenster im Dateimanager implementieren, nicht im OS: GEOS TopDesk hat das bspw. so gemacht.


    Nur dass "heutzutage nicht mehr" die falsche Wortwahl ist - GEOS (und m.W. auch sonst niemand) hat je Fenster implementiert. GEOS kann Dialogboxen, das ist was anderes. Fenster einzubauen ist eine ziemlich neue Idee.

    Laufwerkstreiber sollte man m.E. tunlichst vermeiden

    Sehe ich nicht so. Auf Systemen ohne Jiffy (ja, die gibt es) sind Laufwerkzugriffe ohne Schnellader einfach nur quälend langsam. Daher sollte man sowas weiterhin optional halten.

    Das ist der Punkt, wo mir jegliches Verständnis für deinen Ansatz verloren geht. Du willst, dass dein theoretisches OS neue Hardware voraussetzt - aber das Kernel ROM soll unverändert bleiben, weswegen du die Laufwerkstreiber selber implementieren willst? Das macht doch überhaupt keinen Sinn. Wenn ich in einem Modul schon RAM und Massenspeicher unterbringe, dann natürlich auch neue ROMs.

    Aber dann bist du ja wieder bei einer Speicherverwaltung angelangt, die wolltest du doch vermeiden?

    Nur für Programme, aber nicht für das OS selbst. [...] Wenn z. B. ein Dateiauswahlfenster am Bildschirm erscheinen soll [...]

    Ein Dateiauswahlfenster ist Bestandteil des OS, nicht der Anwendung. Nenn doch mal ein Beispiel für einen Anwendungsfall für eine (echte) Speicherverwaltung innerhalb einer Anwendung. Mir fällt nichts ein.