letzter Beitrag von -trb- am
Wenn man was speziell für die REU programmiert, dann wird das schnelle Kopieren und Löschen nützlich sein, z.B. für schöne Bitmap-Scroller.
Wenn es dann aber nicht REU-only sein soll, dann wird doch wieder auf andere Geräte Rücksicht genommen, dann scheidet sowas wohl aus.
Auf Anhieb hab ich auch "wtf" gedacht, aber gemeint sind vermutlich die REU-Kommandos STASH, FETCH und SWAP. Diese begrenzen die externe Bank-Nummer aus mir unbekannten Gründen auf vier Bits.
Hmm ... unter "ansprechen" stell(t)e ich mir was anderes vor, als Speicherseiten auszutauschen. 
Mit den internen Banks und der MMU etc. hat das also gar nichts zu tun. Da sagt das Handbuch zwar auch was von einem Megabyte Gesamtspeicher, aber die real vorhandene MMU gibt das nicht her.
Die kann vom internen Aufbau 256 kByte wurde aber künstlich auf 128 kB verkrüppelt, um sich nicht selbst Konkurrenz zu den CBMs zu machen, nur um dann noch vor Veröffentlichung doch wieder mit "Expandable to 512 kByte" zu werben, die dann mit dem REU-Murks realisiert wurden. Selbst der vorgesehene DMA wurde nicht realisiert (siehe Schaltplan).
Woran könnte es liegen? Ist es für Entwickler nicht reizvoll genug?
Ein Teil des Spaßes ist halt auch, sich mit anderen zu messen, ähnlich wie bei Demos. Ein Spiel zu machen, dass es mit kommerziellen Produktionen aus früheren Tagen aufnehmen kann (dank moderner Cross-Entwicklungstools) ist ungemein befriedigend. Und um sich zu messen, braucht es gleiche Voraussetzungen.
Man muss hierzu auch die Größe des (REU)Spiels in Relation zur Ladegeschwindigkeit beachten. Hat ein Game nun massig Grafikanimation, könnte dass Laden von einer 1541, auch mit einem Schnelllader,
recht lange dauern. Bei 1MB währen das 5 Diskseiten. Ob das mittels Burstmode beim C128 und einer 1571 funktioniert und man richtig superfast laden kann, weiß ich nicht.
Der C128 kann ab Werk 15 Bänke und somit ein 1mb ansprechen.
DAS hört sich interessant an, war mir noch gar nicht bekannt. Wie werden da denn die 1 MB eingeblendet?
Auf Anhieb hab ich auch "wtf" gedacht, aber gemeint sind vermutlich die REU-Kommandos STASH, FETCH und SWAP. Diese begrenzen die externe Bank-Nummer aus mir unbekannten Gründen auf vier Bits.
Mit den internen Banks und der MMU etc. hat das also gar nichts zu tun. Da sagt das Handbuch zwar auch was von einem Megabyte Gesamtspeicher, aber die real vorhandene MMU gibt das nicht her.
von den internen banks hab ich auch nicht gesprochen. hätte das ausführlicher sagen sollen. es können vom c128 basic die bänke 0-15 in der reu angesprochen werden.
hatte das nur erwähnt, da es ja von cbm offiziell nur 512k erweiterungen gab. ich hab einen nachbau mit 1mb.
gut wäre wenn der dma chip im 128er stecken würde und so für den gesamtspeicher verfügbar wäre. aber es stimmt, die funktionsvielfalt ist schon recht eingeschränkt.
Wenn die CPU des C128 per DMA die REU als Arbeitsspeicher einbinden könnte, wäre das ein Meilenstein gewesen.
Hätte man den zusätzlichen Speicher mittels Beschreiben von $FF00, $D506 oder $C7 umschalten können, wie beim C64 durch das Beschreiben der Adresse $01 geschieht?
Gute Frage - weiß ich gerade nicht. Es kämen am C128 zwei Ansätze in Betracht:
1. Das Zugriffsverfahren von GeoRAM kopieren. In der Tat bekommt es eine 1541 U2(+) hin, wenn man GeoRAM und REU gleichzeitig einschaltet, dass beide auf den selben Speicher operieren... Kann man als Bug oder als Feature auffassen. Jedenfalls geht das also technisch am C128.
2. "External function rom" könnte vielleicht gehen. Lesezugriff geht damit auf jeden Fall, ich weiß aber nicht, ab Schreibuigriffe an das Modul gemeldet werden. Wäre über das Verfahren ganz normal per MMU adddressierbar - eben so wie externe function roms.
Zu 2: Wenn man Zeit übrig hat, kann man das ausprobieren - in der 1541 U2+ ist quasi alles drin, nur der Schreibzugriff nicht. Den müsste man im FPGA-Code reinbasteln und dann einen Test machen. So bekäme man raus, ob ein externes function rom schreiben kann oder nicht.
Wenn die CPU des C128 per DMA die REU als Arbeitsspeicher einbinden könnte, wäre das ein Meilenstein gewesen.
Das war ja (auch) geplant (neben 256 kB intern adressierbarem RAM), wenn ich das richtig verstanden hatte. Wurde beides zugunsten der "CBMs", denen man keine Konkurrenz machen wollte verworfen.
ich weiß aber nicht, ab Schreibuigriffe an das Modul gemeldet werden.
Eher nicht, wenn es gleich implementiert wurde wie im C64.
Zudem ist es sehr schade, das der REC in der REU nur die Bits 00 bis 03 für die Bankwahl nutzen kann. Mehr als 512KB geht ohne aufwändige Änderungen nicht.
Warum wurden da nicht gleich 8 Bits genutzt um eine Bank in der REU anzusprechen. Platz genung wäre im Die des MOS 8726 vorhanden gewesen.
Das mit dem "keine Konkurrenz machen" hat Commodore ja mit den C65 bewiesen. Die dachten ernsthaft, dass der C65 dem Amiga 1000 eine zu starke Konkurenz beschert hätte.
Ich benutze bei GoDot die REU für drei Sachen: a) als RAM-Disk zum schnellen Austausch der Bearbeitungsmodule, b) als superschnellen Zwischenspeicher beim Bearbeiten von Bildern und c) als virtuellen *zweiten* C64, z.B. beim Darstellen von IFLI-Bildern oder beim Rendern von JPG-Bildern. Ach ja - weil die Rede von Nuvies war - eine ganz simple Animierungsmethode durch sowas wie Fingerkino hat GoDot auch (eben mithilfe einer REU), nämlich eine FullScreen-Animation (aber das ist nur eine Machbarkeitsstudie).
Also, ohne REU-Unterstützung kann ich mir das Arbeiten mit GoDot überhaupt nicht mehr vorstellen.
Arndt
2. "External function rom" könnte vielleicht gehen. Lesezugriff geht damit auf jeden Fall, ich weiß aber nicht, ab Schreibuigriffe an das Modul gemeldet werden.
Nein, werden sie nicht. Wenn das R/W-Signal auf "Schreiben" steht, leitet die PLA die Zugriffe aufs RAM um, das externe Funktions-ROM bekommt dann kein /CE-Signal. Ist also genau wie beim internen Funktions-ROM (U36).
Mit einem HC138-Decoder an der MMU kann man sich die beiden /CE-Signale aber selber erzeugen, siehe "Internal function RAM" nach Richard Curcio.
Meine Erfahrugnen mit der Commodore REU 1750
Commdore REU Unterstützung:
Geos: Schnelleres Scrollen durch DMA-Verwendung und RAM-DISK.
Test Drive (Autorennspiel): Cached alle bereits geladenen Level (keine Ahnung ob original eingebaut oder gepatcht)
Burst Nibbler und diverse englische Kopierprograqmme (Maverick?): Kopieren einer Disk in einem Durchgang
Quelle: Tests aus meiner Jugend C64 / 128 mit Commdore 1750 REU (512kb am C64 mit stärkerem Netzteil wie bei dier 1764 mitgeliefert).
Mit Ultimate 1541 II noch nicht nachgetestet. Diese benutzt DMA auch wenn man ein Spiel aus dem Menü lädt und ist dann somit schneller als jeder Fastloader. Wahlweise wird nach dem laden auch noch das Diskimage gemountet.
Ich habe damals auch mal versucht das COMAL Modul aus der Schule auszulesen und nachzubilden, das mit Banking funktioniert. Klappte, war aber irsinnig langsam weil das Modul jeweils 16K von 64 (oder so ähnlich) eingeblendet hat, die REU musste das natürlich ständig hin und her kopieren 
COMAL war eine Programmiersprache u.a. mit Turtlegrafik wie LOGO. Die 1750 hat man ähnlich wie den Videochip des C128 genutzt in dem man Quell und Zieladressen in Register geschrieben hat, und dann durch Schreiben des Befehlsbytes die Operation ausgelöst hat. KEIN Memory-Map.
Gruß, Rune.
P.S.
Hat schon jemand probiert wieviel Speicher GEOS maximal nutzen kann? (Kann ich natürlich auch selbst mal probieren... der C128 steht allerdings im Schrank und der Amiga 2000/68030 fast griffbereit unterm Drucker). Meine SFD-1001 mit REX-IEEE Modul ist leider wegen der Kondensatorkrankheit kaputt und wartet auf Reperatur... 1581 und 1541 mit DolphinDos laufen. Habe mal unter GEOS programmiert (Geoprogrammer).
Hat schon jemand probiert wieviel Speicher GEOS maximal nutzen kann
Geos Megapatch 3: 16 MB aus der REU können genutzt werden. Davon 12 MB am Stück für eine RAMDISK XXL. Und der Rest ganz normal (weitere RAMDisks, RAM-Topdesk, ...).
mrsid (30.01.2020): Da gibt es natürlich schon Möglichkeiten, wenn man das richtig plant...
Stephan Scheuer (30.01.2020): Im Moment fällt mir nicht wirklich ein Spiel ein, dass von einer REU profitieren würde. Sonic vielleicht, aber das gibbet nicht für den C64.
mrsid (30.01.2020 - 12.12.2021): 
mrsid (30.01.2020): Da gibt es natürlich schon Möglichkeiten, wenn man das richtig plant...
Stephan Scheuer (30.01.2020): Im Moment fällt mir nicht wirklich ein Spiel ein, dass von einer REU profitieren würde. Sonic vielleicht, aber das gibbet nicht für den C64.
mrsid (30.01.2020 - 12.12.2021):
Zu geil! 
2. "External function rom" könnte vielleicht gehen. Lesezugriff geht damit auf jeden Fall, ich weiß aber nicht, ab Schreibuigriffe an das Modul gemeldet werden.
Nein, werden sie nicht. Wenn das R/W-Signal auf "Schreiben" steht, leitet die PLA die Zugriffe aufs RAM um, das externe Funktions-ROM bekommt dann kein /CE-Signal. Ist also genau wie beim internen Funktions-ROM (U36).
Mit einem HC138-Decoder an der MMU kann man sich die beiden /CE-Signale aber selber erzeugen, siehe "Internal function RAM" nach Richard Curcio.
