GeoDOS V2 Release 2018

Es gibt 313 Antworten in diesem Thema, welches 59.402 mal aufgerufen wurde. Der letzte Beitrag (11. Juni 2025 um 12:23) ist von darkvision.

  • Das ist aber verdammt langsam .

    Hab ich ja schon vermutet... Unter GEOS sende ich ja jedes Byte einzeln an das SD2IEC... Aber ist mir echt schnuppe... ich kann unter GeoDOS die SD-Karte aus dem Laufwerk nehmen um Daten am PC auszulesen und hinterher über den Partitionswechsel unter GeoDOS wieder "einlegen"... ohne das ich GEOS/GeoDOS beenden muss.
    Ist halt die Frage was einem wichtiger ist...

    P.S. Die 87min beinhalten das schreiben von 16Mb an Daten *PLUS* das ID-Format des SD2IEC. Wie schon erwähnt könnte ich durch das weglassen des ID-Format das ganze beschleunigen. Für ein D64 oder D81 lohnt der Aufwand aber kaum und für ein 16Mb-DNP ist das schon ein sehr seltenes Szenario... Da kopiere ich doch lieber am PC das DNP auf die SD... geht um ein vielfaches schneller. Und erspare mir damit den ganzen Aufwand die BAM-Sektoren manuell zu schreiben...

  • Gilt auch für das Basic-Programm .

    Dann liegt das wirklich an den 254 Unterbrechungen um den aktuellen Zustand unter GEOS anzuzeigen. Evtl. lässt sich da noch was optimieren. Denn auch ein BASIC-Programm kann am C64 die Daten nicht schneller an das SD2IEC senden als es der IECBus erlaubt.

  • Muss es auch nicht, denn es kann die Daten einfach nicht senden. Mit IIRC "p" drüber hinwegspringen und nur das letzte Byte senden. Die Lücke wird dann vom SD2IEC gefüllt.
    PS: Ja, ich war neulich neugierig und habe nachgeschaut, wie das BASIC-Programm das macht...


    edit: Ist nur "p", nicht "b-p".

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

  • Ich öffne einen Datenkanal und schreibe die Bytes über CIOUT/$FFD2 direkt in die Datei. Nachdem alle Sektoren eines Tracks geschrieben sind wird die Datei geschlossen, die Prozentanzeige aktualisiert und dann über open2,dev,2,"name,p,a" erneut zum schreiben/anhängen geöffnet. Das erklärt evtl. warum das so langsam geht... aber immerhin: es geht. Die andere Variante kann ich mir ja mal anschauen...

  • Wusste doch, das ich schon mal gemessen habe wie lange das erstellen eines DNP dauert -> Bitte melde dich an, um diesen Link zu sehen..

    87 Minuten sind schon eine andere Hausnummer. *schluch*


    Wollt heute noch den GD-Snapshot ausprobieren.
    Auf meiner C64-Anlage läuft er leider nicht, nach dem Starten von GD lande ich wieder in (blockiertem) Basic. ;(

    Anlage:

    A: SD2IEC (D81)
    B: FD-2000 (1581)
    C: HD (Native)
    D: RL (Native)
    SCPU mit 16 MB, RAM wird nur für die DACC gebraucht.

    Es spielt keine Rolle ob GD (Snapshot) vom SD2IEC oder der RL gestartet wird, ebenfalls ist es egal ob die SCPU auf 1 oder 20 MHZ gestellt ist.
    Mehr hab ich noch nicht probiert.

    Gruss C=Mac.

  • 87 Minuten sind schon eine andere Hausnummer. *schluch*

    Hab das mit dem "P"-Befehl angepasst und bin jetzt (inkl. ID-Format) bei 30min für 16Mb-DNP. Das D81 geht deutlich schneller... aber da lässt sich noch was optimieren da ich aktuell noch Sektorweise arbeite. Wenn ich das optimiere geht das nochmal etwas schneller, aber nie so schnell wie das BASIC-Programm da ich zur Fortschrittsanzeige die GEOS-Routinen verwende und die Datei daher bei einem DNP-16Mb mind. 254x unterbrechen / fortsetzen muss um den GEOS-Kernal zu aktivieren.

    Auf meiner C64-Anlage läuft er leider nicht, nach dem Starten von GD lande ich wieder in (blockiertem) Basic.

    Werde ich so mal nachstellen, derzeit hab ich das nur mit 2xSD2IEC und 2xRL unter MP3.3r1 getestet. Aber ich hab ja die gleichen Laufwerke, da müsste das ja hier reproduzierbar sein.

    Startet denn der Hardware-Test? Wenn ja, wie weit läuft der denn durch?

  • Hab das mit SD2IEC, RL, FD und HD getestet... startet hier problemlos. Ich hab mal einen neuen SnapShot hochgeladen, mit dem Upload vom Sonntag hatte ich ja auch Probleme.
    Mit der neuen Version dauert DNP jetzt nur noch 13-14min, ich glaub damit kann ich leben. Danke an markusC64 für den Tipp mit dem "P"-Befehl.

    Falls auch die Version abstürzt... einfach mal das RAMLink-Laufwerk durch was anderes ersetzen, z.B.RAM41. Die RL verwendet jetzt speziellen C64/C128 Code aus MP3. Wenn der Test aber durchläuft spielt das keine Rolle...

  • Nachdem das Forum wieder läuft, kann ich auch Antworten. ;)

    Anlage:

    A: SD2IEC (DNP)
    B: FD-2000 (1581)
    C: HD (Native) Parallel
    D: RL (Native)
    SCPU mit 16 MB, RAM dient als DACC-Speicher.

    Hab mal das LfW D durch andere Typen ersetzt:

    - RL Native = Absturz
    - RL 81 = Absturz
    - SuperRAM Native = Absturz

    - RAM 81 = funktioniert
    - RAM Native = funktioniert
    - Kein Laufwerk = funktioniert

    Verwendet wurde der GD-Snapshot aus Beitrag 108.
    Gestartet wurde GD von der HD.

    Gruss C=Mac.

  • Ich habe das neue GD 20181120 heute auch mal getestet:

    -D81 erstellen: GD zeigt mir in % an das das Image erzeugt wird, leider habe ich hinterher das
    (angeblich neu erstellte) D81 nicht gefunden......Komisch: Keinerlei Fehlermeldung!!

    -Partion wechseln funktioniert
    -kopieren 1:1 funktioniert dauert ca 10 Min für ein D81, aber damit kann ich leben
    -UVs erstellen funktioniert, leider bekomme ich (genau wie mit MDir) beim Füllen der UVs und des DNP die Fehlermeldung "Bam defekt".........also genau wie voher.........

    Ich habe bereits einen Man vor Ort, die Sache wird erledigt werden, so wie immer.............

  • -D81 erstellen: GD zeigt mir in % an das das Image erzeugt wird, leider habe ich hinterher das
    (angeblich neu erstellte) D81 nicht gefunden......Komisch: Keinerlei Fehlermeldung!!

    Das D81 wird nicht innerhalb eines DNP/D81 erstellt sondern auf der SD-Karte in dem Unterverzeichnis in dem sich das zuvor eingebundene D81 befunden hat. War zuvor kein D81 eingebunden (z.B. SD-Karte aus dem SD2IEC entfernt und wieder reingesteckt) dann müsste das D81 im Hauptverzeichnis der SD-Karte landen. Wenn nach der %-Anzeige auf das "Formatiere Disk..." erscheint und das auch ein paar Sekunden dauert, dann müsste GeoDOS auch in das neue D81 gewechselt haben und es müsste beim öffnen von Laufwerk X: auch direkt angezeigt werden.
    Was hattest Du für einen Namen für das D81 eingegeben? Bei manchen Zeichen bin ich mir noch nicht sicher ob das SD2IEC damit zurechtkommt...

    -UVs erstellen funktioniert, leider bekomme ich (genau wie mit MDir) beim Füllen der UVs und des DNP die Fehlermeldung "Bam defekt".........also genau wie voher.........

    Ich hoffe Du hast das nicht auf der mir zugeschickten DNP-Partition erstellt? Wie gesagt, dort war das Problem bereits vorhanden.und wird nicht besser.
    Ich hab eben auf einer leeren GeoRAM-Native ein UV erstellt. Dann mit TopDesk Dateien in das UV kopiert. Anschließend die gleichen Dateien in das Hauptverzeichnis kopiert. Anschließend die Diskette aufgeräumt und alles funktioniert.

  • Hallo,

    nur um das klar zu sagen, ACHTUNG: Wer in Bitte melde dich an, um diesen Link zu sehen. s Signatur auf "GeoDOS64" klickt, landet bei einer älteren GeoDOS-Version. Also entweder auf "SnapShots" klicken oder auf "Area6510" und dann zu den Snapshots durchhangeln. Nicht dass hier zwei verschidene Versionen von GeoDOS benutzt werden .....


    Aber GeoDOS (Snapshot vom 20.11) hat definitiv auch einen Fehler:

    MP3-128 (aktuell), die 6 geoDOS-Dateien auf Native-Ram kopiert und von dort gestartet. Die Hardware-Erkennung läuft durch und der Info-Screen (1/4) ist sichtbar. Hier habe ich aber keinen Mauspfeil auf dem Bildschirm.
    Wenn ich jetzt einfach mit der Maus klicke, dann verschwindet Info-Screen 1/4 und GeoDOS läuft. Jetzt habe ich auch einen Mauspfeil und kann GeoDOS benutzen.

    Gruß
    Werner

  • Habs heute nochmal probiert, diesmal hat es geklappt ein D81 erstellen mit GD meine ich.
    war genau wie du gesagt hast, nach dem Formatieren wurde auf das neu erstellte D81 gewechselt
    Ich vermute mal, der Schreibschutz war auf der Karte aktiviert......Darum hatts nicht geklappt

    Und Nein ich habe ein frisch erstelltes/Formatiertes DNP genommen, bevor ich die UVs mit GD erstellt habe
    war alles Fehlerfrei, keine Ahnung was da schiefgegangen ist, bei Gelegenheit versuch ich`s Nochmal.....
    Meine Ram ist leider zu klein, um da Großartig Daten draufzu kopieren..........(512KB)

    Ich habe bereits einen Man vor Ort, die Sache wird erledigt werden, so wie immer.............

  • Und Nein ich habe ein frisch erstelltes/Formatiertes DNP genommen, bevor ich die UVs mit GD erstellt habe
    war alles Fehlerfrei, keine Ahnung was da schiefgegangen ist, bei Gelegenheit versuch ich`s Nochmal.....

    Du kannst mir ja wieder so ein DNP schicken...

    Bitte melde dich an, um diesen Link zu sehen.: Konnte das Problem hier nachstellen, aber komischerweise nur mit einem SuperRAM-Laufwerk. Egal, Problem gefunden. Lies sich sogar unter BASIC reproduzieren. Der neue SnapShot(=Testversion, siehe Signatur :D ) hat den Fix mit drin...

  • C=Mac: Konnte das Problem hier nachstellen, aber komischerweise nur mit einem SuperRAM-Laufwerk. Egal, Problem gefunden. Lies sich sogar unter BASIC reproduzieren. Der neue SnapShot(=Testversion, siehe Signatur ) hat den Fix mit drin...

    :thumbup:

    Funktioniert, egal welches Ram-LfW verwendet wird.
    Kein Absturz mehr, GD startet ohne Probleme.

    Auch kann ich wieder Partitionen auf der RamLink wechseln. :party:

    Noch einwenig mit den SD2IEC-Möglichkeiten rumprobiert:

    Images wechseln = funktioniert, egal ob D81 oder DNP.

    Images erstellen = funktioniert, egal ob D81 (ca. 50s) oder DNP (1'024 KB ca. 55s; 16'320 KB ca. 14min.).


    Was mir noch aufgefallen ist.
    Wenn ich mir das Directory anzeigen lasse, kann ich die Speicherbelegung anzeigen.
    Dort gibt es u.a. zwei Punkte:

    - Blocks im Verzeichnis belegt
    - Blocks auf Diskette belegt

    Blocks im Verzeichnis belegt ist immer um 1 Block grösser als Blocks auf Diskette belegt, muss dies so sein?

    Gruss C=Mac.

  • Ein Problem hab ich in der Zwischenzeit gefunden.

    Es können keine Images auf dem SD2IEC erstellt werden - jetzt aber ganz stark sein - es betrifft MP3-128 (V3.3). :whistling:

    Beim erstellen eines Image wird die Prozentanzeige normal durchgezählt, darauf kommt der Screen mit der Meldung das formatiert wird, dann die Fehlermeldung: Fehlercode 32.

    Betrifft beide Imagearten, DNP und D81.

    Gruss C=Mac.

  • Es können keine Images auf dem SD2IEC erstellt werden

    darauf kommt der Screen mit der Meldung das formatiert wird, dann die Fehlermeldung: Fehlercode 32.

    Existiert auf der SD-Karte die neue Datei und wird nur nicht formatiert oder wird auch kein neues Image erstellt? Blinkt nach der Fehlermeldung die Fehler-LED am SD2IEC? Falls ja was sagt der Fehler-Code? (Nach BASIC verlassen und Fehlerkanal auslesen, in JiffyDOS z.B. mit @)

  • Existiert auf der SD-Karte die neue Datei und wird nur nicht formatiert oder wird auch kein neues Image erstellt?

    Auf der SD-Karte hab ich nichts gefunden, also kein neues Image oder sonstige Datei.


    Blinkt nach der Fehlermeldung die Fehler-LED am SD2IEC?

    Ups, hab ich gar nicht beachtet.
    Muss ich nochmal probieren.

    Wie gesagt betrifft MP3-128, mit MP3-64 funktioniert es, siehe Beitrag 115.

    Gruss C=Mac.

  • Auf der SD-Karte hab ich nichts gefunden, also kein neues Image oder sonstige Datei.

    Dann läuft die %-Anzeige auch deutlich schneller durch? 16Mb sollten selbst bei 2MHz am C128 ca.8-14min. benötigen. Falls es nur ein paar Sekunden sind... dann kommen die Befehle am 128er nicht am SD2IEC an...