letzter Beitrag von darkvision am
Ich hab auch mit GeoDOS das 16Mb-DNP auf die RL kopiert, dauert ohne SCPU ca. 30min.
Echt schnell, wenn ich daran denke das Wheels-64 um eine Stunde hatte von HD -> SD2IEC, dies trotz Parallelkabel und SCPU.
Mit TD dauerte es 1 Std. 23 min. (C128 ohne Parallelkabel und SCPU).
Entweder reisst die RamLink die Zeit so runter (ist immer noch das schnellste LfW) und/oder die Routinen von GeoDos ist soviel effizienter.
Gruss C=Mac.
oder die Routinen von GeoDos ist soviel effizienter.
Allerdings ist das SD2IEC mit Sicherheit auch schneller als die HD. Und ich glaube das die SCPU immer wieder auf 1MHz heruntergetaktet wird. Daher ist deren Vorteil nicht so groß. Ich hab ja eher von "RAM" auf "RAM" kopiert, du von "HD" auf "RAM" (ich seh das SD2IEC eher als RAM-Laufwerk....)
Ich hab zwischenzeitlich noch weitere Tests mit DNP-DiskCopy gemacht und soweit sieht alles gut aus. Die Probleme von gestern liegen wirklich an der REU als DACC und der RAMLink die bei mir nur auftreten wenn ich die RL nicht mit einer GEOS-DACC als erster Partition konfiguriere. Lässt sich reproduzieren und ist ein Ansatz für die Fehlersuche.
Pusti64: Steckt die REU bei Dir im RAM-Port? Evtl. erkennt MP3 die REU als "DACC" obwohl der Speicher eigentlich von der RL verwaltet wird. Wie groß ist Deine RL? 16Mb?
Pusti64: Steckt die REU bei Dir im RAM-Port? Evtl. erkennt MP3 die REU als "DACC" obwohl der Speicher eigentlich von der RL verwaltet wird. Wie groß ist Deine RL? 16Mb?
MP3 erkennt meine 2Mb REU problemlos.
Habe zur Zeit aber nur meine 16MB RL am Rechner hängen und selbst damit tritt der RAM-Lfw Fehler auf.
Pusti64
Habe zur Zeit aber nur meine 16MB RL am Rechner hängen und selbst damit tritt der RAM-Lfw Fehler auf.
Dann musst Du ja ein RL-DACC als GEOS-DACC verwenden. Ist die RL-DACC Partition die erste die Du auf dem Laufwerk eingerichtet hast?
Ich hab jetzt etwas am RL-Treiber geändert das bei mir die Probleme behoben hat (zumindest bei aktuellen Tests...). Wenn ich weiß wie Du Deine Partitionen (und in welcher Reihenfolge) angelegt hast kann ich das hier vorab testen.
Ansonsten gibt es am Weekend einen neuen SnapShot, dann kannst Du selbst testen...
Ansonsten gibt es am Weekend einen neuen SnapShot, dann kannst Du selbst testen...
Ist die RL-DACC Partition die erste die Du auf dem Laufwerk eingerichtet hast?
Muss die nicht sogar die erste Partition sein?
Oder hab ich da wieder was falsch in der Rübe?
Gruss C=Mac.
Dann musst Du ja ein RL-DACC als GEOS-DACC verwenden. Ist die RL-DACC Partition die erste die Du auf dem Laufwerk eingerichtet hast?Ich hab jetzt etwas am RL-Treiber geändert das bei mir die Probleme behoben hat (zumindest bei aktuellen Tests...). Wenn ich weiß wie Du Deine Partitionen (und in welcher Reihenfolge) angelegt hast kann ich das hier vorab testen.
Ansonsten gibt es am Weekend einen neuen SnapShot, dann kannst Du selbst testen...
Meine RL-DACC ist auf 31 eingerichtet. Auf 1 habe ich immer eine 1581 Partition und dann kommen zwei Native-Partition.
So habe ich das schon ewig, bis auf die Native-Partition.
Pusti64
Muss die nicht sogar die erste Partition sein?
Oder hab ich da wieder was falsch in der Rübe?
Guter Hinweis, muss ich mal testen. Aber nach dem Code wird wohl die Startadresse der Partition an GEOS übergeben und für die RAMTreiber auch als Basis-Adresse verwendet. Also scheint das für MP3 kein "Muss!" zu sein.
Werde es aber mal testen...
Meine RL-DACC ist auf 31 eingerichtet. Auf 1 habe ich immer eine 1581 Partition und dann kommen zwei Native-Partition.
OK, die Partitions-Nummern helfen da nicht wirklich. Geht um die Startadresse der Partition im RL-Speicher. Hab da ein Tool das die Adressen auslesen kann... evtl. ist es einfacher mal zu sehen was der nächste SnapShot macht... Kein Problem.
OK, die Partitions-Nummern helfen da nicht wirklich. Geht um die Startadresse der Partition im RL-Speicher. Hab da ein Tool das die Adressen auslesen kann... evtl. ist es einfacher mal zu sehen was der nächste SnapShot macht... Kein Problem.
DACC und 1581 richte ich immer automatisch mit dem Basicprogramm RL/RD GEOS SETUP ein.
Pusti64
Basicprogramm RL/RD GEOS SETUP
Kenn ich jetzt gar nicht, was ist dies für ein Programm?
Gruss C=Mac.
Kenn ich jetzt gar nicht, was ist dies für ein Programm?
Gruss C=Mac.
Ist von CMD, kann Dir morgen gerne meine "aufgebohrte" Version schicken. Welche auch 4096 kb als GEOS-DACC einrichtet.
Pusti64
Ist von CMD, kann Dir morgen gerne meine "aufgebohrte" Version schicken. Welche auch 4096 kb als GEOS-DACC einrichtet.
Da nutze ich meine RL-INIT-Tools... da muss man nix aufbohren...
Ich hab jetzt einen neuen SnapShot hochgeladen. Download hier oder hier (Datum 19.10.18).
Der IECBus-NM-Treiber ist jetzt standardmäßig nicht mehr dabei. Wer den braucht kann Ihn aber über den SourceCode selber assemblieren und mit dem MegaAss in GEOS.Disk einbinden. Für testen unter VICE mit der FD kann man den noch brauchen. Allerdings nur bis 8Mb-DNP.
Mit der großartigen Hilfe von markusC64 hab ich dafür einen SD2IEC-Treiber erstellt, der jetzt nur noch mit dem SD2IEC funktioniert. Dafür aber mit vollem 16Mb-Support 
Ich empfehle die Installation zuerst auf ein "Standard"-Laufwerk. Nach einem ReBoot kann man dann den SD2IEC-Treiber auswählen und alle Dateien auf das SD2IEC kopieren und dort GEOS.MP3 ausführen(oder MP3 erneut auf dem SD2IEC installieren...)
Das booten von SD2IEC mit dem Treiber funktioniert hier problemlos.
Es gab auch einige kleinere Bugs bei der Erkennung und Behandlung von RAMLaufwerken und RAMLink-Laufwerken, je nach Konfiguration. Ich hab da jetzt was geändert und an meinem C64 kann ich RAMLink zusammen mit RAMLaufwerken nutzen. Ich hoffe das behebt mehr Probleme als das es neue schafft 
Der neue SD2IEC-Treiber ist um ca. 500Bytes kleiner geworden da ich den eigentlichen TurboDOS-Code nicht mehr benötige (der wird ja eh nicht im SD2IEC ausgeführt...). Da wäre jetzt Platz frei um das Thema mit der Anpassung der Größe von Unterverzeichnissen einzubauen. Aber...
Das würde nur bei sehr wenigen Treibern funktionieren. Z.B. bei der CMD HD, nicht aber beim HD-PP-Treiber (da ist wieder kein Platz da...). Bei den ExtendedRAM-NM-Treibern (CREU, SCPU, GRAM) gehts nicht, beim normalen RAMNative schon.
Ausserdem würde das nur funktionieren wenn die Anwendung den neuen Sektor über die GEOS-Routinen anfordert, das machen längst nicht alle so (da bin ich mir sicher...). Falls ja würde geprüft ob man in einem Unterverzeichnis ist und dann die Sektoren gezählt und der Dateieintrag angepasst. Kein großer Perfromace-Verlust....
Es würde also je nach Treiber unterschiedlich funktionieren und je nach Anwendung auch nicht unbedingt ausgeführt. 100%ig sicher sein kann man sich also eh nicht und man muss mit entsprechenden Programmen ein VALIDATE ausführen (muss Dateilängen korrigieren können).
Ich hab jetzt einen neuen SnapShot hochgeladen. Download hier oder hier (Datum 19.10.18).
Der IECBus-NM-Treiber ist jetzt standardmäßig nicht mehr dabei.
dafür einen SD2IEC-Treiber erstellt, der jetzt nur noch mit dem SD2IEC funktioniert.
Uff Glück gehabt. 
alle Dateien auf das SD2IEC kopieren und dort GEOS.MP3 ausführen
Wird MakeBoot nicht mehr benötigt?
Naja ich seh es ja wenn ich den neuen Snapshot installiere.
Kann nur sagen: Super Arbeit von Dir.
Besten Dank dafür 
Da wäre jetzt Platz frei um das Thema mit der Anpassung der Größe von Unterverzeichnissen einzubauen. Aber...
Das würde nur bei sehr wenigen Treibern funktionieren. Z.B. bei der CMD HD, nicht aber beim HD-PP-Treiber (da ist wieder kein Platz da...). Bei den ExtendedRAM-NM-Treibern (CREU, SCPU, GRAM) gehts nicht, beim normalen RAMNative schon.
Ausserdem würde das nur funktionieren wenn die Anwendung den neuen Sektor über die GEOS-Routinen anfordert, das machen längst nicht alle so (da bin ich mir sicher...). Falls ja würde geprüft ob man in einem Unterverzeichnis ist und dann die Sektoren gezählt und der Dateieintrag angepasst. Kein großer Perfromace-Verlust....
Es würde also je nach Treiber unterschiedlich funktionieren und je nach Anwendung auch nicht unbedingt ausgeführt. 100%ig sicher sein kann man sich also eh nicht und man muss mit entsprechenden Programmen ein VALIDATE ausführen (muss Dateilängen korrigieren können).
Aus meiner Sicht, ist es nicht wirklich nötig.
Ist ja eher ein kosmetisches und kein funktionelles Problem.
Wäre eigentlich ein spezieller 1541Ultimate-Treiber auch möglich, z.B. direkter Zugriff auf den USB-Stick ohne D64 benutzen zu müssen?
Gruss C=Mac.
Wird MakeBoot nicht mehr benötigt?
Wird am Ende von GEOS.MP3 doch automatisch ausgeführt...
Wird am Ende von GEOS.MP3 doch automatisch ausgeführt...
Ach so.
Hab bis jetzt immer alle Dateien auf's neue Image/Partition/Diskette kopiert und dann nur MakeBoot ausgeführt.
Gruss C=Mac.
Hab bis jetzt immer alle Dateien auf's neue Image/Partition/Diskette kopiert und dann nur MakeBoot ausgeführt.
Das tut es natürlich auch und ist schneller... GEOS.MP3 speichert aber gleichzeitig im Editor die aktuelle Konfiguration. Falls sich die nicht ändert reicht MakeBoot.
Wenn das SD2IEC einen neuen UV-Sektor im Bereich von 32-63 anlegt, dann ändert sich die Anzahl der freien Blocks nicht und wäre aus meiner Sicht aus auch kein Problem. Wenn das bei der HD anders ist dann ist das trotzdem kein Problem:
Rein technisch gesehen kann ich Dir zustimmen. Aber: ein DNP ist ein 1:1-Abbild einer CMD-Native-Partition. Da das Native-Format auf allen CMD-Geräten identisch ist, dürfte das das auch für HD und RamLink zutreffen.
Aus Anwender-Sicht ist es aber irgendwie blöd:
Ich erstelle auf einem echten CMD-Gerät eine Native Partition und dann dort mit Bord-Mitteln ein oder mehrere UVs. Bei jedem UV wird die freie Block-Zahl um 2 verringert. Alles OK.
Ich mache genau das gleiche auf dem SD2IEC mit einem gleich großen DNP und benutze hier das MD-Kommando auf dem SD2IEC. Zumindest bis die 29 Bytes (die eigentlich für das Directory frei gehalten werden) gefüllt sind, habe ich hier eine andere Zahl der freien Blöcke.
Was sagt der "normale" Anwender: Fehler, Bug, das funktioniert doch nicht.......
Also: Das "Problem" steckt in der SD2IEC-Firmware. Die sollte sicherstellen, dass sich ein DNP genauso verhält wie die echte Hardware. Also: alles außer die 29 Directory-Blöcke sollte ab Track 1 Sektor 64 gespeichert werden und eben nicht auf dem Bereich der für das Directory da ist.
@Unseen , liest Du hier noch? Für mich ist das ein Fehler in der Firmware zum SD2IEC (Befehl "MD" innerhalb eines DNP). Bitte mal ansehen.....
Zum Abschluss noch ein Zitat aus dem englisch-sprachigen CMD-FD-Handbuch Seite 6 (von hier: http://www.bombjack.org/commodore/hardware/ ), dass es etwas deutlicher sagt als im deutschen Handbuch:
"The directory and BAM of a Native Mode partition take up 64 blocks regardless of the partition's size. For example, a Native Mode partition that takes 256 blocks to create will show 192 blocks free, a 512 block partition will show 448 blocks free, and a 12,800 block partition will show 12,736 blocks free."
Ich hab jetzt einen neuen SnapShot hochgeladen.
Hatte leider nicht viel Zeit. Habe das neue MP3-128 jetzt einmal aus der Vorversion heraus auf FD-1581 (A:) installiert und dann aus der neuen Version heraus auf ein knapp 8 MB (127 Tracks)-DNP (SD2IEC; D:) bisher keine Probleme festgestellt. Mehr dann wenn meine "normale" Test-Methode durch ist, oder mir was auffällt...
Gruß
Werner
Allerdings ist das SD2IEC mit Sicherheit auch schneller als die HD.
Ich konnt's nicht lassen und hab ein Speedtest gemacht.
C64, JiffyDOS on, SCPU off, laden eines 202 Blocks PRG.
| HD Parallel | 2.6 sec. |
| HD Serial | 6.4 sec. |
| SD2IEC | 6.4 sec. |
| RamLink | 1.4 sec. |
So der neue Snapshot ist installiert (64'er & 128'er).
Keine Probleme, bis jetzt ist mir auch nix negatives aufgefallen.
Lässt sich booten, egal ob D81, DNP oder CMD-HD.
Gruss C=Mac.
Hm, dass der IEC Bus das Nadelöhrchen darstellt, war zu erwarten. Also bin ich nicht wirklich von den Ergebnissen überrascht.
Allenfalls ein SD2IEC mit Parallelkabel (solche gibt es, auch wenn ich keines habe) mit einer für Geos nicht vorhandenen Software könnte wieder in die Nähe der Parakllelbertragung von CMD HD kommen.
C64, JiffyDOS on, SCPU off, laden eines 202 Blocks PRG.
Naja, HD Parallel und HD seriell/SD2IEC zu vergleichen, ist irgendwie unfair .
Ansonsten würden mich mal die Zeiten interessieren, die MP3 zum Booten braucht, zwischen HD seriell (Native Part) und SD2IEC (DNP) . Beide mit gleichem Inhalt, gleicher Größe und gleichen Einstellungen (JiffyDOS aktiv) . Mir kommt das (MP3-128) auf SD2IEC rasend schnell vor....
Gruß
Werner
