last post from Juergen Johannes at the
Wenn gewünscht, kann ich das inclusive auslesen der REU und SCPU coden.
Das mit der REU auch gefällt mir... Dann hätten wir einen neuen Anwendungsfall: Mit meinem gepatchten Burstnibbler, einem Zwischenspeicher (1581 oder SD2IEC, letzteres ist einfacher!) und einem GeoRAM/NeoRAM/REU ein G64 erstellen. Eine Software, die einen Dump des Speichers der Speichererweiterung, der vom Burstnibbler gefüllt woden ist, in das .g64 umwandelt, existiert nämlich bereits.
Press 1 for 512KB
Press 2 for 1MB
Press 3 for 2MB
Press ......
Press 6 for Custom Value
Bei 6 dann aber bitte auch den Startwert eingebbar machen, nicht nur den Endwert. Es gibt nämlich einen guten Anwendungsfall, ab 4 MB eine gewisse Größe abzuspeichern (dort liegt unter Geos Megapatch nämlich die GeoRAM bzw. REU Native), welche ein DNP Image darstellt. Und wenn man das Image klein genug konfiguriert im Megapatch, speichert es aucg brauchbar schnell ab.
OK, dann werde ich mal anfangen und zuerst ein flussdiagramm zeichnen. Dann erstelle ich den code.
Eventuell lade ich die Ein- und Ausleseroutine für die REU separat hoch.
Reicht es, wenn das Auslesen bis 2MB geht?
Bei 6 dann aber bitte auch den Startwert eingebbar machen, nicht nur den Endwert. Es gibt nämlich einen guten Anwendungsfall, ab 4 MB eine gewisse Größe abzuspeichern (dort liegt unter Geos Megapatch nämlich die GeoRAM bzw. REU Native), welche ein DNP Image darstellt. Und wenn man das Image klein genug konfiguriert im Megapatch, speichert es aucg brauchbar schnell ab.
Da mache ich natürlich. start- und endadresse können angegeben werden
Für's Erste ja. Die erste Version muss ja nicht die letze sein, oder?
Bei 8 MB bzw. 16 MB GeoRAMs (ich erspare mir ab jetzt die Doppelnennung mit NeoRAM) wächst die Größe der Bänke von 16k auf 32k bzw. 64k.
So ist es richtig, denke ich
$dffe : Nr. des 256 Byte-Blocks im gewählten 16KB-Block
-------------------------------------------------------
$00 bis $3f -> 40 * 256 Byte = 16KB
$dfff : Nr. des 16KB-Blocks
---------------------------
bei 512KB : $00 - $1f -> 32 * 16KB = 512KB
---------------------------------------------
bei 1024KB : $00 - $3f -> 64 * 16KB = 1024KB
---------------------------------------------
bei 2048KB : $00 - $7f -> 128 * 16KB = 2048KB
---------------------------------------------
bei 4096 KB : $00 - $ff -> 256 * 16KB = 4096KB
---------------------------------------------
bei 8192KB : $00 - $ff -> 256 * 32KB = 8192KB
---------------------------------------------
bei 16384KB : $00 - $ff -> 256 * 64KB = 16384KB
Passt, wobei $dffe eben bei 8 MB bzw. 16 MB Gesamtgröße eben innehalb des gewählten 32k bzw 64k Blocks ist. Aus dem Kontext merkt man jedoch, dass Dir das klar ist. Nur falls hier wer mal nachliest, schrreibe ich das explizit auf.
Mal eine Frage an Rande. Ist es auch möglich ein GeoRam mit 16MB zu bauen, die mit realer Hardware funktioniert.?
Bei einer (echten) REU ist das aufgrund der Konstruktion des DMA-Controller nicht möglich.
Das wäre die Idee mit den Pages/Bänke und das halte ich auch für sinnvoll.
Nicht nur die Anzahl, sondern auch den Startwert. Dann könnte man zuerst 0-8 sichern, und danach auf einer 2ten Disk 8-16mb.
Du hat es auch versucht, fast 16MB abzuspeichern? Ich hatte bei 8MB schon ein frustrierendes gefühl der langeweile, weil es einfach zu lange dauert.
Nein, aber auf dem SD2IEC ein 16Mb-DNP erzeugt, zu Beginn in dem ich es mit $00-Bytes gefüllt habe. Also nichts anderes wie jetzt das speichern. Hat glaub ich 'ne Stunde gedauert. In der Zwischenzeit geht das mit dem SEEK-Befehl ja deutlich schneller.
Ich ahne, worauf Du hinaus willst - aber ein FPGA ist für mich reale Hardware. 
Aber da ich ja ahne, worauf Du hinauswillst: Das ist ein Schaltplan davon: http://x1541.gmxhome.de/bilder…eoram-level2-smd-v100.png.
Im Wesentlichen (genaueres müsste wer mit Praxiserfahrung sagen) braucht man nur alle 8 Adressleitungen an beiden D-Flipslops (74HCT174N sind Flipslops) anlegen. Die Ausgänge bilden dann die höherwertigen 16 Bit der Speicheradressierung. Und es geht technisch, einfach mehr Flipfloop-ICs zu nehmen, wenn die voll sein sollten. Und natürlich mehr Speicher reintun. Da ist nichts drin, was nicht skaliert bis zu der Zahl, wo die Bits noch reichen.
In wie fern man die Platine dann größer machen miss, kann ich nichts zu sagen, aber es geht. Man muss nur eine neue Platine designen, das ist alles.
...Hat glaub ich 'ne Stunde gedauert. In der Zwischenzeit geht das mit dem SEEK-Befehl ja deutlich schneller.
Ach du heilige Shice 
Ich hatte umgekehrt ein überraschendes ergebnis mit der scpu. Ich dachte anfangs, das der code fehlerhaft sei
Display MoreIch ahne, worauf Du hinaus willst - aber ein FPGA ist für mich reale Hardware.
Aber da ich ja ahne, worauf Du hinauswillst: Das ist ein Schaltplan davon: http://x1541.gmxhome.de/bilder…eoram-level2-smd-v100.png.
Im Wesentlichen (genaueres müsste wer mit Praxiserfahrung sagen) braucht man nur alle 8 Adressleitungen an beiden D-Flipslops (74HCT174N sind Flipslops) anlegen. Die Ausgänge bilden dann die höherwertigen 16 Bit der Speicheradressierung. Und es geht technisch, einfach mehr Flipfloop-ICs zu nehmen, wenn die voll sein sollten. Und natürlich mehr Speicher reintun. Da ist nichts drin, was nicht skaliert bis zu der Zahl, wo die Bits noch reichen.
In wie fern man die Platine dann größer machen miss, kann ich nichts zu sagen, aber es geht. Man muss nur eine neue Platine designen, das ist alles.
Hehe. Sicher, Der FPGA-Chip ist eine richtig gute erfindung und macht vieles billiger. ich hoffe doch, dass es mal einen FPGA gibt, mit dem es möglich ist einen (c64 + 16mb reu + 16 mb georam + scpu + ramlink + 1541+ fd-2000 + cmd-hd) zu erstellen.
Ok. Jezt haben wir unsee lustigen Momene gehabt. Ich war nämlich auch amüsiert, als Du nach realer Hadwae gefagt hast, wo es in de U2(+) (und dem U64) bereits drin ist.
Auf Grund des Schaltplanes ist abe hoffentlich ebenfalls klar, dass man das auch klasssisch auf mehr bis zu 16 MB bingen kann. Auch mehr, wenn man mehr IO2-Adressen bemüht... dann ist es aber nur bedingt kompatibel.
....U2(+) (und dem U64) bereits drin ist.
Genau, und das war für mich nicht so ganz original.
Der Schaltplan ist top und sicher wenn man noch eine adressleitung hinzufügt. z.b. $DFFD, kommt man ganz schnell in dem GB-Bereich
Wobei ich mir bei der U2(+) (und damit auch U64) Implementierung ein besonderes Feature erlaubt habe: Da man in Hardware ja Adressleitungen einfach tauschen kann (sinnbildlich einfach vertauscht anlöten, beim FPGA natürlich nicht wörtlich), habe ich die Adressleitungen so vertauscht, dass im Speicher Bank X Page Y bei Bankgrößen 16k, 32k und 64k immer an der selben Stelle landen (sofern durch die emulierte Größe des GeoRAM existent). Und diese Stelle ist genau die, wo es bei klassischen 16k Pages und normaler Verdrahtung auch landen würde. Nachtrag: Eine C64 Software merkt davon nichts...
Das ist zum einen für den Benutzer nett, zum anderen sorgt das dafür, dass man klassische GeoRAM-Images einladen kann (die dann direkt in den Speicher laden, ohne Umweg über den C64), auch wenn die Größe gerade auf 16M steht und die Software von 16k Bänken ausgeht (was die Software natürlich getan hat, es gab bis dato ja nichts anderes). Es funktioniert auf diese Art einfach. Und andere (d. h. größere) Images gab es ja nicht.
Insofern muss ich da mal für 16k und 32k Bankgrößen eine weitere Lademöglichkeit schaffen, damit man die mit der hier entstehenden Software erzeugten Images dann auch einladen kann...
Das hört sich super an. Zudem würde es den Programieraufwand verringern.
Nur mal so nebenbei. Die Lese- und Schreibzyklen kann man nicht verringern?
Nur mal so nebenbei. Die Lese- und Schreibzyklen kann man nicht verringern?
Das hier ist einer der relativ wenigen Anwendungsfälle, wo eine GeoRAM schneller ist als eine REU: Bei einer REU muss man erst den Inhalt komplett ins RAM übertragen und dann zur Floppy schicken (oder das ganze Rückwärts). Bei hinreichender Größe in Häppchen, was für den Gesamtmindestaufwand irrelevant ist.
Bei einer GeoRAM kann man beim Lesen des Bytes es gleich zur Floppy schicken und hat nur alle 256 Byte etwas Extraaufwand (Seiten- und Bankanpassung). Das dürfte weniger als 256 Zyklen kosten, die der DMA bei der REU kostet... REU Programmierung noch nicht mitgezählt.
Ansonsten fällt mir nur noch eine Stelle ein, Zeit zu sparen: ARM2IEC verwenden mit Dolphin DOS. Schneller ist Übertragung zum SD2IEC-kompatiblen Gerät nicht zu machen. Habe leider keins, beim Laden ist da aber durchaus ein Faktor zwischen 2 und 3 drin gegenüber Jiffydos mit SD2IEC.
Das eröffnet ganz neue möglichkeiten. Außerdem kann man eine GeoRam für weinig Geld selber bauen.
Ich hatte bei der GeoRAM Lese- und Schreibroutine eigendlich vor, die Daten aus der GeoRam von $1000-$cfff in das c64 RAM zu kopieren. Das wird dann abgespeichert.
der Floppykanal wird nicht geschlossen. Die nächsten Daten werden von $1000-$cfff in das c64 ram kopiert und weiter abgespeichert. Das dann solange, bis alles auf disk ist.
danach werden die kanäle erst geschlossen.
Dann hast Du ja jetzt Deine Antwort auf:
Nur mal so nebenbei. Die Lese- und Schreibzyklen kann man nicht verringern?
Ich hatte gefragt, weil ich auch mal (abschätzen) wissen wollte, ob es möglich wäre nuvies abzuspielen. zudem sollte die georam zu sich selber auch kompatibel bleiben.
mit der scpu wäre es möglich. nur nicht die gesammten 16mb.
