letzter Beitrag von Retrofan am
Ich hatte ja mal die geplante Hi-DPI-Darstellung des C128 erwähnt. [...] Wie gesagt, da durch die 640 Pixel in der Breite gegenüber den 320 Pixeln des C64 die Fläche nicht wirklich größer wird (der Bildschirm bleibt gleich groß),
Der VDC hat einen Linebuffer von 2 * 82 Byte, man kann die Farbgrafik also durchaus auch 656 Pixel breit machen. Sobald man aber per Register 27 mit virtuellen Desktops o.ä. rummacht, sind 648 Pixel das Maximum.
Ich habe hier mal eine Memory Map der Standard-Speicher-Aufteilung angelegt, die Basis für meine weiteren Überlegungen ist. Ich kann das halt besser, wenn ich es grafisch vor mir sehe und mir nicht blanke Hex-Adressen merken muss.
Ein Quadrat entspricht einer Page (256 Byte). 16 x 16 Pages x 256 Bytes ergeben 65536 Bytes.
Da benötig der C64 ja bald so etwas wie Himem und/oder quemm /emm um den Speicher zu verwalten. Oder bekommt das alles eine feste Adresse?
Der VDC hat einen Linebuffer von 2 * 82 Byte, man kann die Farbgrafik also durchaus auch 656 Pixel breit machen.
Ich denke, aus Kompatibilitätsgründen zum C64 (per Verdoppelung) verzichten wir einfach auf die 16 zusätzlichen Pixel und bleiben bei 640.
Da benötig der C64 ja bald so etwas wie Himem und/oder quemm /emm um den Speicher zu verwalten.
Ich bin noch nicht soweit, sagen zu können, wie es genau funktioniert und wie man es einsetzen kann – aber man kann in bestimmte Adressblöcke (ich denke da an $8000 bis $9FFF) 64 verschiedene Bänke aus dem EasyFlash einblenden. Wenn man damit geschickt umgeht, kann man sicherlich was daraus machen. Das erweitert zwar nur den ROM-Speicher um 1024 KB und das RAM bliebe so klein, wie es ist – aber der C128 würde ja z.B. doppelt so viel RAM zur Verfügung stellen.
Andere favorisieren die NeoRAM als Erweiterung aber ich möchte erst einmal gucken, was mit dem EF möglich wäre.
Da benötig der C64 ja bald so etwas wie Himem und/oder quemm /emm um den Speicher zu verwalten. Oder bekommt das alles eine feste Adresse?
Bitte nicht 
Ich habe hier mal einen ersten Schritt getan. Was hat sich hier gegenüber der Standard-Belegung geändert? Die 1 KB Char-Screen-RAM benötigen wir nicht, daher habe ich das dem freien RAM zugeschlagen. 4 KB für 2 Fonts (inkl. Breitentabellen) habe ich ab $C000 reserviert. Meine ersten Überlegungen gehen dahin, das EF Modul zum Laden von Speicherblöcken temporär zu aktivieren und dann wieder auszuschalten. Wenn das EF aktiv ist, dann wird über den 16 KB RAM ab $8000 eine der 64 EF-ROM-Bänke eingeblendet (welche, wird über den EF-Bereich innerhalb des i/O-Bereichs geregelt, dort kann man auch auf die 256 Byte EF-RAM zugreifen). Solange das CRT-ROM eingeblendet ist, ist auch das Kernal-ROM eingeblendet, das wir für Massenspeicherzugriffe benötigen. Die 8 KB des Kernal-ROMs nutzen wir parallel als Screen-RAM für die Bitmap-Darstellung. Den können wir jederzeit beschreiben und der VIC kann ihn auch zur Darstellung auslesen. Das einzige, was nicht geht, während CRT-ROM und Kernal eingeblendet ist, ist das Lesen über die CPU, d.h. wir können keine Bereiche buffern, wenn wir Dialoge oder Menüs einblenden wollen. Also müssen wir trennen, wann wir die Kernal-Routinen für Disk-Zugriffe benötigen und wann wir GUI-Interaktion vornehmen müssen. Ich glaube, dass sich das gut trennen lässt.
Was interessant wäre, sind Überlegungen, was man mit den (zeitweise) eingeblendeten CRT-ROM-Bänken anstellt. Kopiert man sie einfach in den RAM-Bereich darunter, damit sie erhalten bleiben, wenn man das ROM ausschaltet oder verschiebt man das woanders hin und nutzt dem RAM-Bereich darunter anderweitig?
Oder welche schwerwiegenden Gedankenfehler haben sich bei mir eingeschlichen, die das Geplante komplett unmöglich machen? (wie gesagt, ich bin neu in dem Geschäft – aber einer muss es ja tun)
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.
Alles anzeigenBezüglich der EFx noch einmal der Hinweis: Die Verwendung der Roms ist alles andere als trivial! Zwar ließe sich relativ einfach eine Funktion bereitstellen, die in der Lage ist, Programme aus dem Rom in das Ram zu laden, aber mal eben so ganze Programme einzublenden funktioniert genauso wenig wie mal eben so ein System fürs Rom zu entwickeln. Alles, was direkt eingeblendet werden soll, muß in Bänken organisiert sein gebündelt mit den Leaf-Prozeduren und Tabellen, die gerade benötigt werden. Bitte beachten: Will eine Routine im Rom eine Routine aus einer anderen Rom-Bank aufrufen, so muß folgendes durchlaufen werden:
1.) Irgendwie muß die Zieladresse der aufzurufenden Routine übergeben werden. Hierfür gibt es mehrere Möglichkeiten:
a) eine 24-Bit-Adresse, die dann auf die Bank umgerechnet wird (der Adreßraum ist größer als 64kb!)
b) ein Index in eine 24-Bit-Adress-Tabelle, die im Arbeitsspeicher liegt und dort Platz verbraucht.
c) eine Sprungliste mit Wrapper-Code im Arbeitsspeicher (verbraucht wahnsinnig viel Speicherplatz!)
2.) Dann muß eine (im Arbeitsspeicher befindliche) Routine aufgerufen werden, die die Bank umschaltet und sich neben der Rücksprungadresse auch die alte Banknummer merkt. Zusätzlich werden noch 2 Bytes einer künstlichen Rücksprungadresse auf den Stack geschoben.
3.) Die eigentliche Routine wird mit einem indirekten Sprung aufgerufen.
4.) Nach Beendigung der Routine wird diese mit einem RTS verlassen, springt jedoch wegen der künstlichen Rücksprungadresse nicht direkt in den Aufrufer zurück, sondern
5.) in die Wrapper-Routine zum Rückschalten der Bank. Diese wird danach ebenfalls mit RTS beendet, und dann ist man endlich zurück beim Aufrufer.
Daneben gibt es aber immer noch das bereits erwähnte Problem mit der Speicheraufteilung: Wenn die Roms von $8000..$9fff und $e000..$ffff sowie IO von $d000..$dfff eingeblendet sind: Wo bitteschön befindet sich der Graphikspeicher? Bei $6000..$7fff etwa? Mit Farbram bei $5c00? Wie wenig Arbeitsspeicher soll denn am Ende übrig bleiben? Will man tatsächlich den Arbeitsspeicher unter den Roms nutzen (zumal der sonst völlig unnütz wäre), muß man zwingend Routinen im Arbeitsspeicher haben, die die Zugriffe nach Ausblenden der Roms erledigen, z. B. sämtliche Graphikroutinen oder auch der Zeichensatz.
Mit anderen Worten: Die Verwendung der Roms zum Nachladen von Programmen in den Arbeitsspeicher stellt kein Problem dar, aber das "hot"-Einblenden von Routinen im laufenden Betrieb ist ein ziemliches Gefrickel mit super Overhead. Wer's mag, darf sich gerne dran versuchen. Für mich persönlich wäre das nichts.
Die 8 KB des Kernal-ROMs nutzen wir parallel als Screen-RAM für die Bitmap-Darstellung. Den können wir jederzeit beschreiben
Nein. So funktioniert das nicht. Das Screen-RAM muß unbedingt auch gelesen werden können. Ansonsten kannst Du den Proportionalfont und vieles andere mehr in den Mülleimer schmeißen.
Oder welche schwerwiegenden Gedankenfehler haben sich bei mir eingeschlichen
Dein größter Gedankenfehler ist es leider zu meinen, andere Posts ignorieren zu können.
Wäre es evtl. schlau, dass man das, was ich jetzt mal als OS bezeichne, in den 16K-RAM-Bereich unterhalb des Cartridge-ROMs (ab $8000) zu packen? Also inkl. 3 KB Screen-Buffer, 4 KB Fonts, GUI-Routinen und die ganze andere Verwaltung? Oder verbaut man sich dann was?
Wenn das ginge, dann könnte man über das mehrfache Einblenden des CRT-ROMs Programme in 16 KB-Blöcken ins RAM holen. Dafür ständen dann (also für App und Daten) 31 KB bis zum OS/CRT-ROM und die weiteren 4 KB oberhalb dessen zur Verfügung, also insgesamt 35 KB. Das fände ich nicht wenig, wenn man bedenkt, dass ja vieles (z.B. alle Bildschirmausgaben, Zeichensätze, I/O-Routinen) schon über das OS geregelt wird.
Das Screen-RAM muß unbedingt auch gelesen werden können. Ansonsten kannst Du den Proportionalfont und vieles andere mehr in den Mülleimer schmeißen.
Kannst du das genauer erläutern? Und außerdem kann ja der Screen-RAM sichtbar sein – bis auf die Momente, in denen man das ROM einblendet, um Bänke ins RAM zu schieben oder wenn man Disk-Operationen durchführt. Oder wo steckt da der Knoten?
Dein größter Gedankenfehler ist es leider zu meinen, andere Posts ignorieren zu können.
Geht's vielleicht auch ein bisschen freundlicher?
Zu der memory map: Da hatte ich irgendwo hier ja schon mal meine Aufteilung gepostet. Hier aber nochmal:
Was da noch nicht berücksichtigt war, ist der zweite Font, der dann halt bei $c000 oder $c400 hin müsste.
Den Rest der 'aktuellen Geschehnisse' muss ich erst noch mal komplett lesen...
Kannst du das genauer erläutern?
Um einen Proportionalfont, bei dem ein Zeichen nicht genau einem Byte entspricht, in das Screen-RAM schreiben zu können, muß man zunächst das alte Screenbyte holen, das neue Zeichen darin hinodern und dann in den Bildschirm zurückschreiben:
Außerdem soll der Bildschirm auch gescrollt werden können. Und dafür muß ebenfalls das Ram gelesen werden. Nicht zuletzt macht es keinen Sinn, Bitmapgraphik zu verwenden, aber keine Routinen oder wenigstens die Möglichkeit für die Anwender bereitzustellen, einzelne Pixel setzen zu können.
Die sich daraus ergebenen Probleme fürs Programm habe ich bereits genannt. Aber bitte hier noch einmal (und zum letzten Mal):
Wenn Du auf das Screen-Ram lesend zugreifen willst, muß die Speicherkonfiguration auf Ram-Ram-Ram (für Zugriffe aufs Farbram) gestellt sein, d. h. alle Roms sind ausgeblendet inklusive Dein Easyflashrom. Es bringt also gar nichts, Rom einzublenden, wenn Du das Rom nicht verwenden kannst. Damit Du aber von einer Rom-Routine heraus lesend aufs Screen-Ram zugreifen kannst, brauchst Du einen Wrapper-Code, der sich im Ram befindet und vor Benutzung der Graphikroutinen jedes Mal die Roms aus- und nachher wieder einblendet. (Und nebenbei trifft das dann auch für die IRQ-Routine zu, die ansonsten kräftig crashen würde, wenn mal eben so das Rom nicht mehr da ist.) Also brauchst Du im Ram einen Bereich, um diesen ganzen Wrappercode abzulegen sowie weiteren Wrappercode für Sprünge von Rombank nach Rombank wie oben beschrieben.
Deine Speicheraufteilung sieht bislang aber so aus:
- $0 .. $3ff = Systemspeicher
- $400- $7fff = Angeblich frei für Applikationen
- $8000 - $bfff = Rom
- $c000 - $cfff = 2 Zeichensätze
- $d000 - $dfff = IO
- $e000 - $ffff = Rom
Wo bitte hast Du hier Platz für den Rombank-Wrappercode, den IRQ-Wrapper, den Graphikwrapper mitsamt Routinen usw.? Antwort: Nirgendwo.
Da die Programmier-kundigen hier ja keine Lust haben, mal ein Konzept vorzulegen, wie man z.B. den Speicher unter Verwendung des EasyFlashs aufteilen könnte [...]
Geht's vielleicht auch ein bisschen freundlicher?
Wie hättest Du es denn gerne? Soll ich Dir auch noch Beifall klatschen dafür, daß Du meine alten Posts überliest und jetzt über Sachen stolperst, auf die ich bereits vor geraumer Zeit hingewiesen habe?
aber keine Routinen oder wenigstens die Möglichkeit für die Anwender bereitzustellen, einzelne Pixel setzen zu können.
Setzen geht doch auch im ROM-Modus – nur lesen nicht. Oder habe ich wieder was übersehen? Der Rest des Problems (Proportional-Zeichensatz, Scrolling und so) leuchtet mir aber ein.
Wenn Du auf das Screen-Ram lesend zugreifen willst, muß die Speicherkonfiguration auf Ram-Ram-Ram (für Zugriffe aufs Farbram) gestellt sein, d. h. alle Roms sind ausgeblendet inklusive Dein Easyflashrom.
Das gleiche habe ich doch auch geschrieben. Ich wollte, dass du mich auf die Sachen hinweist, die ich nicht weiß – nicht auf die, die ich weiß.
Damit Du aber von einer Rom-Routine heraus lesend aufs Screen-Ram zugreifen kannst
Wer spricht von einer "ROM"-Routine? Ich bin bisher davon ausgegangen, dass ich das CRT-ROM ins RAM (z.B. ab $0400) kopiere. So habe ich das doch auch geschrieben. Ich habe in meinem obigen Ansatz (der ja nur einer von vielen möglichen ist) geplant, das ROM nur einzublenden, wenn ich Apps/Routinen aus dem EF hole oder wenn ich das Kernal benötige, um auf Laufwerke zuzugreifen. Was geht daran nicht?
Wo bitte hast Du hier Platz für den Rombank-Wrappercode, den IRQ-Wrapper, den Graphikwrapper mitsamt Routinen usw.? Antwort: Nirgendwo.
Z.B. ab $C000 (in Abweichung zu meiner ersten Zeichnung hatte ich ja vorsichtig angedacht, die Fonts mit unters (meist ausgeblendete) CRT-ROM zu packen). Außerdem verstehe ich noch nicht, was du alles wrappen willst. Stehst du auf mexikanische Küche? 
Wie hättest Du es denn gerne? Soll ich Dir auch noch Beifall klatschen dafür, daß Du meine alten Posts überliest und jetzt über Sachen stolperst, auf die ich bereits vor geraumer Zeit hingewiesen habe?
Beifall verlange ich sicherlich nicht. Nur ein normales Maß an freundlichen Umgangsformen. Wenn ich hier schon den Job anderer Leute mache – trotz aller Probleme damit, will ich dafür nicht noch blöde von der Seite angemacht werde. Ich sehe auch nicht, wo du berücksichtigt hast, wie man mit dem EF sinnvoll umgehen könnte außer: "Lass mal bleiben, macht nur Arbeit". Und das will ich (erstmal) so nicht stehen lassen. Und wieder zeigt sich, dass ...
... ich hier offensichtlich von einigen technisch versierten Forumskollegen ignoriert werde – außer wenn es was zu moppern (Anm.: meckern, nicht mobben) gibt.
Zu der memory map: Da hatte ich irgendwo hier ja schon mal meine Aufteilung gepostet. Hier aber nochmal:
Die habe ich wohl gesehen. Aber mir fehlte da, wie auch in M.J.s Überlegungen, die mögliche Einbeziehung von 1024 KB EF-ROM.
Ich hatte ja auch M.J.s Speicherbelegungs-Liste (für mich persönlich) in einen Übersichtsplan umgesetzt – aber die Aufteilung nützte mir nichts, weil das EF (oder eine RAM-Disk) darin nicht vorkam. Klar, man kann so relativ frei über das RAM des C64 verfügen – aber zum einen verschenkt man doch die Möglichkeit, 2 Speicher (ROM und RAM) zum Preis von einem zu bekommen* und zum anderen fehlt mir das schnelle Nachladen von Code aus irgend einer Quelle (außer über normales, serielles Laden).
*) Wenn es schon Lese- und Schreibroutinen für gängige Speichermedien (inkl. SD2IEC) im (ein- und aus-blendbaren) Kernal gibt (der sich den Platz mit dem nötigen Screen-RAM teilen kann), warum die dann dauerhaft ausschalten und Platz (und Entwicklungszeit) mit eigenen Routinen "verschwenden"?
----
Ich würde die ganze Speicher-Sache gerne weiter diskutieren – weil es mich langsam echt interessiert – aber bitte in einem höflichen Ton und mit dem Verständnis, dass nicht alle auf dem gleichen technischen Level sind (was ich ja von Anfang an unumwunden zugegeben habe). Also Ball flach halten, was die Technik – und auch, was den Stil – angeht. Dann freue ich mich über weitere Infos und vielleicht kommen wir ja zusammen zu einer probaten, vielleicht sogar innovativen, Lösung.
Hier eine aktualisierte Fassung meines zur Diskussion gestellten Speicherplans und zur Vervollständigung den von M. J. (ich hoffe, keine Fehler dabei gemacht zu haben).
Edit: Grafik-Fehler behoben. Bleiben unter dem CRT-ROM abzgl. Fonts und Buffer 9 KB für Grafik-Routinen. Keine Ahnung, ob das reicht.
Und vor allem weiß ich nicht, ob man wirklich solche Routinen unter das CRT-ROM packen darf. Das bedeutet ja, dass man während des Ladens und Speicherns (dafür benötig man das Kernal und das wird zusammen mit dem CRT-ROM eingeblendet) keine Grafik-Aktualisierungen durchführen kann.
Aber deswegen will ich das hier ja diskutieren.
Zum EF kann ich aktuell auch wenig bis gar nix beitragen. Ich seh aber bislang auch gar keine (zwingende) Notwendigkeit für EF/irgendein RAM.
Die bislang angedachten Apps dürften auch mit normalem Nachladen erträglich sein, da vielleicht bis 10K oder so. Vorgenannte 'Nachladeorgien' sehe ich da jedenfalls nicht. EF möchte ich aber natürlich nicht ausschließen, wenn machbar. Gerne.
Ich bin seit gestern (vorgestern) auch an einer witzigen Lösung für user-eigene Apps dran. Tests vom Abend waren jedenfalls absolut positiv. Das würde die bislang angedachte 'Script-Sprache' wohl obsolet machen. Steckt aber noch in den Kinderschuhen.
Hier eine aktualisierte Fassung meines zur Diskussion gestellten Speicherplans und zur Vervollständigung den von M. J. (ich hoffe, keine Fehler dabei gemacht zu haben).
Da sehe ich die Diskussion nicht. Nur Bitmap und Screen-(Col-)RAM müssen ja in einer Bank liegen. Der Rest kann ja lustig verteilt werden. $8000- war bei mir ja auch frei verfügbar, falls für EF o. ä. nötig.
Ich seh aber bislang auch gar keine (zwingende) Notwendigkeit für EF/irgendein RAM.
Die Sache ist die: Das hier geplante System soll möglichst sofort auf dem Screen erscheinen, wenn man den C64 einschaltet. Dafür benötigt man eine Lösung – und das EF ist eine billige wie auch gut verfügbare (da sogar von anderen Erweiterungen emulierte) Erweiterung. Aber da hat man dann auf einmal 64 Bänke á 16 KB zur Verfügung – soll man die etwa brach liegen lassen?
Die bislang angedachten Apps dürften auch mit normalem Nachladen erträglich sein, da vielleicht bis 10K oder so.
Auch wenn es reine Utopie ist, sollte man an die Zukunft denken. Es wäre doch zu schade, wenn das neue System umgesetzt und genutzt würde und man feststellt, dass man sich ohne Not die Zukunft (wieder mal) verbaut hat. Die Mehrheit meint ohnehin, dass der C64-Speicher für unsere Idee nicht annähernd ausreichend ist – da sollte man dann doch das rausholen, was irgendwie geht.
Das würde die bislang angedachte 'Script-Sprache' wohl obsolet machen.
Klingt spannend. Halte uns auf dem Laufenden.
Solange keine Antworten bzgl. meines ersten EF-Nutzungs-Vorschlags kommen, schiebe ich gleich noch einen weiteren hinterher. Danke schon mal für den Hinweis, dass ich (natürlich) Code im permanent verfügbaren RAM benötige, der sich um das Speicher-Management (MM in meiner Map) kümmert. Da es zwei Stati [korrigiert: Status] gibt, habe ich die mal in 2 Maps aufgeteilt (man kann sich das auch als 2 Ebenen vorstellen).
Den einen Status nenne ich "Work", den anderen "Load". Das Memory Management blendet bei Bedarf eine Bank des EF in den Speicher ein und verschiebt dann den geladenen Inhalt in das Free RAM. In diesem Status können auch Disk-Routinen aus dem Kernal genutzt werden. Benötigt man beides nicht, schaltet das MM wieder in den Work-Modus.
(Laut M.J. und anderen Quellen schaltet sich der Bereich ab $D000 auch von RAM auf ROM, wenn man das EF einblenden will. Bisher habe ich das nicht berücksichtigt, weil ich über diesen Bereich einfach noch zu wenig weiß. Der (blaue) Bereich, in den sich das EF einklinkt, muss doch immer sichtbar sein, sonst könnte man ja das EF nicht aktivieren, oder?)
Ich hoffe, aus Text und Zeichnungen geht hervor, wie ich mir das vorstelle. Jetzt die Frage an alle Programmierer, inkl. M. J.: Geht das? Oder steckt da ein riesiger Fehler drin? Und wenn ein Fehler drinsteckt: Gibt es eine bessere Lösung zur Nutzung des EasyFlashs?
Da es zwei Stati gibt
kurze Klugscheisserei am Rande 
der korrekte Plural von "Status" ist uebrigens "Status" (mit langem "u" gesprochen) 
Danke, werde ich in Zukunft beachten.
Sollte das oben skizzierte Schema grundsätzlich funktionieren können, dann wäre natürlich die nächste Überlegung, welche OS-Routinen zwingend permanent existieren müssen und welche man auch mal zwischendurch ausblenden kann, um ROM-Inhalte zu laden bzw. das Kernal zu nutzen. Und dann könnte man mal versuchen, abzuschätzen, wie viel RAM jede OS/GUI-Funktion ungefähr benötigen würde, um die Gesamtgröße abzuschätzen. Hexworx hatte mal davon gesprochen, dass seine Text-Engine bisher rund 2 KB benötigt – stimmt das? (Gerade in der Memory-Map nachgesehen: 2,5 KB)
Hat mal jemand eine Speicher-Verteilungs-Übersicht von GEOS oder einem anderen 8-Bit-GUI-System zur Hand? Ich habe da so schnell nichts gefunden. Und ich bitte weiterhin um Korrektur, um nicht zu lange in die falsche Richtung zu laufen.
