warum sollte man die Keyboard-Abfrage-Routine ändern?
Kommt drauf an, wie gut die ist. Auf den ersten Blick würde ich sagen, daß da einige Sachen rausfliegen oder geändert werden können. 1:1 würde ich die nicht übernehmen.
Auch deine Vorstellung, das Dateisystem komplett umzuwerfen
Ich bitte um Verzeihung, aber das hatte ich nie gefordert. Ich hatte gemeint, daß das Dateisystem der 1541 unzulänglich ist (ist nun mal so), aber deswegen ein neues Dateisystem einzuführen und zigtausend Disketten dann nicht mehr lesen zu können, macht keinen Sinn. Der anfangs erwähnte Treiber fürs Dateisystem ist die Ebene, die zweierlei leisten kann: 1.) Man könnte auf einem Datenträger ein anderes Dateisystem verwenden (z. B. FAT16) und der Dateisystemtreiber würde garantieren, daß ein Zugriff möglich ist, aber das wäre nur eine Ergänzung (, sofern man das wirklich will). 2.) Der Dateisystemtreiber kann in bezug auf das alte Dateisystem (1541 etc) Dateizugriffe bei logischen Dateien über 64kb umleiten auf einzelne Häppchendateien. Dabei bleibt aber das ursprüngliche Dateisystem erhalten, und alle Dateien können wie gehabt kopiert und gelöscht werden.
Nebenbei: Das wäre auf der ToDo-Liste sicherlich nicht ganz oben zu finden.
Meines Erachtens will doch ohnehin niemand mehr direkt auf dem C64 programmieren. Eine neue Programmiersprache oder IDE sollte daher, wenn überhaupt, außerhalb des C64 angeboten werden. Am besten Plattform-unabhängig.
Was mich anbelangt, so entwickle ich nur noch auf dem PC, aber es scheint auch immer noch Leute zu geben, die tatsächlich auf dem C64 programmieren, z. B. in BASIC. Abgesehen davon, egal ob auf dem C64 oder PC, müßte man solch eine Sprache definieren und dafür den Compiler schreiben. Ob jemand eine ganze IDE dafür basteln kann, sei dahingestellt. Und plattform-unabhängig? Hmmm... An welche Plattformen denkst Du da? Windows, Linux, Mac, Android... ? Und wer soll das leisten?
Allerdings wäre es aber schick, eine (Skript-)Sprache zu haben
Eine (langsame) Skriptsprache sollte sich ermöglichen lassen.
Das GUI evtl. von BASIC aus anzusprechen, hatte ich noch gar nicht bedacht. Wäre aber mit einer kleinen BASIC-Erweiterung (quasi wie die Skriptsprache) tatsächlich auch nutzbar.
Das halte ich für eher schwer umsetzbar. Dazu müßte man das BASIC-Rom und das Kernal-Rom einblenden und die Zeropage-Belegung sowie den Bereich von $200-$3ff komplett auf das alte Kernal ausrichten. Ich befürchte, das gäbe nur eine große Konfusion. Da würde ich persönlich eine neue Skriptsprache bevorzugen.
Sieht in Teilen meinem sehr ähnlich
Du hast es aber besser gemacht und auch den Zeichensatz in den Bereich $d000-$dfff verlegt.
Apropos Zeichensatz: Wie soll eigentlich eine Fontdatei für einen Proportionalfont mit 256 Zeichen aufgebaut sein?
Wofür Graphikroutinen?
Naja, da es sich um eine GUI handeln soll, muß das System Graphikprimitive (wie die von Dir erwähnte Linienroutien) zur Verfügung stellen, um überhaupt etwas auf dem Bildschirm anzeigen zu können.
Normalerweise wäre das sowas wie:
- Punkt malen
- Linien malen
- ausgefülltes Rechteck malen
- Kreis malen (notwendig?)
- Zeichen aus dem Zeichensatz malen
- Blitten von Icons
Beim Malen muß dann wieder geschaut werden, ob man nur mit zwei Stiftfarben (an/aus) plottet oder auch Mischmuster erlaubt, was bei einer monochromen Auflösung von 320x200 ratsam wäre.
Vielleicht sollte man sich mal die Bibliotheken der frühen "Konkurrenz" (GEOS, GEM, Windows 1.0, Mac System 1-6) angucken
Wer hat Ahnung davon und kann das bewerkstelligen?
Außerdem finde ich klasse, dass man quasi unendlich viel Platz für Systemroutinen hat und sie ganz schnell in den C64-Speicher einblenden (und damit andere ersetzen) kann.
Stell Dir das bitte nicht so einfach vor. Mit der Einblendung von Roms ab $8000 senkt man automatisch die Menge des zur Verfügung stehenden freien Speichers ab auf maximal 31 KB ($400 - $7fff). Außerdem muß der Code bankweise organisiert sein. Und wenn ich das auf codebase richtig gelesen habe, setzt die Einblendung des Roms voraus, daß $1 auf #$37 oder #$33 gesetzt ist, was auch gleichzeitig den alten Kernal sowie den IO-Bereich bzw. das VIC-Charrom aktiviert, so daß ein Zugriff auf das Ram bei $d000-$dfff aus dem Rom heraus nicht möglich ist, der Bereich von $e000-$ffff nur beschrieben werden kann und alle Interrupts über den Kernalvektor bei $fffe laufen. Blendet man nur den Lo-Teil ein ($8000-$9fff) liegt damit der Arbeitsspeicher von $8000-$9fff sowie $d000-$ffff brach. Wählt man die 16kb-Variante zusätzlich auch noch $a000-$bfff. Dadurch ergeben sich massive Einschränkungen in der Speicherorganisation. Abgesehen davon halte ich 1MB fürs System auch für ein wenig übertrieben. Daher frage ich mich persönlich, ob nicht eine Ram-Karte wie die GeoRam oder die REU hier mehr leisten könnte. Bei der gepufferten NeoRam hätte man dann zusätzlich den Vorteil, daß die Systemprogramme wie bei einem ROM erhalten blieben. Vorteil bei allen RAM-Karten: Sie würden den sehr knappen Arbeitsspeicher deutlich entlasten, und es wären Sachen möglich wie die früher erwähnten Diskettencaches, um Zugriffe auf Wechseldatenträger (1541,1581...) erheblich zu beschleunigen.