ZoomFloppy mit CBM 8050/8250

Es gibt 23 Antworten in diesem Thema, welches 4.461 mal aufgerufen wurde. Der letzte Beitrag (15. August 2011 um 13:30) ist von Diddl.

  • Mittelfristig bekommt das D82OPY drive code spendiert, dann erübrigen sich die Probleme.

    Zur Zeit läuft nur die Notlösung mit normalen DOS Kommandos.

    Das wird schon ...

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Diddl: wenn Du ein IMGCOPY machst, wäre es schön, auch die 2040/3040/4040 bzw. deren halbierten Exemplare zu berücksichtigen.
    Ich konnte von der 4040 zwar mit

    Code
    d64copy -t original 8 image.d64

    ein funktionstüchtiges D64 erzeugen, aber die 4040 wird in einem nicht ordnungsgemässen Zustand "hinterlassen".

    cbmctrl status 8 hat "26, write protect on,18,00" ausgegeben - warum bitte will d64copy schreiben?!

    Die Diskette war nur durch Zufall schreibgeschützt. Vertrauenserweckend ist das jedenfalls nicht! Ich will ja sichern und nicht irgendwas versehentlich überschreiben!

  • Diddl: wenn Du ein IMGCOPY machst, wäre es schön, auch die 2040/3040/4040 bzw. deren halbierten Exemplare zu berücksichtigen.


    Leider besitze ich keines dieser Laufwerke, deshalb kann ich dafür auch nur eingeschränkt Software entwickeln.


    Die Diskette war nur durch Zufall schreibgeschützt. Vertrauenserweckend ist das jedenfalls nicht! Ich will ja sichern und nicht irgendwas versehentlich überschreiben!


    Ich vermute da eher ein Problem im 4040 DOS.

    Soviel ich weiss schreibt D64COPY nicht beim Lesen des Image. Ich habe an der Ecke auch gar keine Änderung gemacht. Meine Änderungen zur 4040 sind gering:

    • neuer Transfermodus Standard. War notwendig, weil zur Zeit keine Drive Code zur Verfügung steht. Ich habe den Transfermode für D82COPY entwickelt und halt auch im D64COPY eingesetzt.
    • Neue Gerätetypen: 8050, 4040, 8250 und SFD
    • Geräteerkennung überarbeitet. Im Falle der 4040 eh nur aufgrund von Angaben eines Betatester, ich habe ja keine 4040.

    Der Standard Transfer Modus macht nur folgendes:

    • Öffnen eines Datenbuffer mit Bitte melde dich an, um diesen Link zu sehen.
    • lesen von Blöcken mit U1 in den Datenbuffer
    • lesen des Datenbuffer zum PC


    Datenbuffer dienen beim Commodore DOS sowohl zum schreiben als auch zum lesen. Man kann das nicht einschränken. Warum die 4040 "write protected" meldet, obwohl nie ein U2 ausgeführt wird, das ist mir ein Rätsel.

    Um sicher zu gehen dass da kein Fehler vorliegt, könntest du mal im STD.c ein printf() einbauen an der Stelle wo U2 gesendet wird. Sollte beim Lesen von Images nie auftreten.

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.