Posts by markusC64

    Könnte mir vorstellen wenn das Laufwerk initial negativ auf Track 0 steppt. Wenn man da aber schon (negativ) raus ist, dann fährt es in den Anschlag, da der Track 0-Sensor nicht auslöst.

    Eventuell wird dieses Prozedere mit einem GW (o.ä.) unterbunden.

    In der Kryoflux-Software hat man eingebaut, dass nach jeder Operation (Diskette lesen, Diskette schreiben, ...) auf Track 0 zurückgekehrt wird.

    Die Firmware geht beim Poweron ebenfalls auf Track 0.


    Ich denke mal, wenn da jetzt die Leitungen am Shugart keinen definierten Pegel haben, klappt jene Abfrage ggf. nicht, weil die elektronische Sperre, die ein Weitersteppen verhindert, ja nicht mehr da ist.


    Naja, darum mache ich mir keinen Kopf. Ich ewiß, in welcher Reihenfolge ich anschließen muss und gut.



    Keir hat von GreaseWeazle eine non-Release-Build fertig, wo das obige commodore.1541 Problem korrigiert sein soll. Sind eingeladen, die zu testen... das im Github Issue die Einladung zum Test an mich ging, ist angesichts der Öffentlichkeit der Einladung nicht so genau zu nehmen.

    Und bei Umbau a) kann es sein, dass es am normalen Controller noch geht, muss aber nicht. Meins hat den Effekt, dass beim Einschalten der Stromzufuhr bereits Verbindung zum Controller da sein muss (irgendein Signal, keine Ahnung welches, muss definiert sein!), anonsten stepped es immer weiter richtung negativer Offsets (ja wirklich, gegen den Anschlag, was nicht gut ist!!!) und findet nicht mehr zurück - außer man unterbricht die Stromzufuhr und hilft manuell nach... Richtige Reihenfolge beim Stromdraufgeben verhindert das aber zuverlässig: Erst per USB am laufenden PC anschließen, dann Strom auf die Floppy und alles ist so, wie es sein soll.


    Kurz: Je nach Controller muss das nicht funktionieren. USB kann man herstellen, bevor man Strom auf die Floppy gibt, kein Problem. Also gehen GreaseWeazle, SuperCard Pro & Kryoflux. Bei anderen Controllern: Keine Ahnung, brauche ich nicht.

    Habe gerade mal das neue commodore.1541 format vom Greaseweazle 1.12 ausprobiert. Natürlich mit dem unseren Archivisten bekannten nicht so einfachen Testfall ("Science III"). Kein Kopierschutz, aber zumindest so, dass dtc.exe versagt.


    Um es kurz zu machen: GreaseWeazle 1.12 bekommt den Testfall auch nicht hin. :-(


    Also hilft alles nicht und Bugreport vorbereiten.

    Einsehr ungewöhnliches Muster. Man müsste den Inhalt mal genauer analysieren. Für mich sieht das so aus, als wären die geraden Tracks überschrieben worden, wodurch auch immer. Formatieren auf 360k vielleicht.


    Stichprobe nach .scp einlesen (vielleicht einfach die ersten 4 Tracks) und dann anaylsieren sollte Klarheit bringen - beim Analysieren kann ich gerne helfen (sofern der Diskinhalt nicht geheim ist).

    Gibt es irgendwo eine Liste von Laufwerken, zu denen solch eine Jumperkonfigurationen bekannt ist?

    Nicht wirklich, aber im Forum von cbmstuff.com kann man durchaus fündig werden, weil deren SuperCard Pro schon viel länger das Feature mit Rumdrehen der Diskette hat.

    Apropos Supercard Pro, die habe ich auch...

    Hat jemand ähnliche Erfahrungen gemacht oder sogar brauchbare Ergebnisse erzielt?

    Bei mir klappen 1541 Disketten mit dem GreaseWeazle eigentlich immer. Allerdings will ich in der Regel (also quasi immer) den 1541 D64 Dekoder auch nicht, weil die Stärke des GreaseWeazle gerade die kopiergeschützen Disketten sind.

    Früher brauchte man ein modifiziertes "flippy" Laufwerk, um beide Seiten von C64-Disketten lesen zu können. Da diese Modifikation sehr aufwendig ist, war das immer recht unattraktiv.

    Ist das nicht mehr notwendig?

    Je nach Laufwerk geht es auch ohne, nämlich dann, wenn eine Jumperkonfiguration bekannt ist, die es erlaubt, auch ohne Indexpuls zu lesen. Dann kann man die Diskette nämlich einfach rumdrehen.


    Welches PC Laufwerk nutzt du ?

    Panasonic JU475-4APJ - allerdings auch umgebaut, so dass ich nicht rumdrehen muss. Ich kann es aber als nicht umgebautes Laufwerk verwenden und umdrehen - was ohne Umbau auch wäre gegangen.



    Nachdem die Basics beantwortet sind, zur Sache:


    Leider wirft das Teil bei meinen Versuchen nur hauptsächlich Fehler wie "unexpected sector" oder "sectors missing" aus.

    Schon mal den Schreib/Lesekopf gründlich gereinigt?


    Wenn ja, dann mach mal


    gw read --track c=0-81:h=0 test.scp


    und gib mir die Datei zur Analyse, dann sieht man hoffentlich, was an den Daten gw nicht gefällt.



    Nachtrag: GreaseWeazle Tools 0.38 ist von Keir veröffentlicht worden - inkl. wichtiger Befehle ist lesenswert dazu.

    Bei VICE hat man die Tatsache, dass D81 mit 81 Tracks nicht unterstützt wird, von einem Feature request zu einem Bug hochgestuft: https://sourceforge.net/p/vice-emu/bugs/1890/ .


    PS: Der Zusammenhang mit diesem Thread ist, dass Masterdisketten auf einer 1581 ein 81 Track .d81 brauchen.


    Nachtrag: gpz hat den Bug bereits behoben und "will have to clean this up a bit and test". Aber eigentlich ist das Problem behoben. Demnächst kann man also in VICE das einfach auf D81 installieren und das 81 Track D81 dann auf echter 1581 übertragen... wer einen GreaseWeazle hat, der unterstützt sogar 81 Track .d81.

    Für die Ultimates, welche 1581 unterstützen, ist auch ein Patch in Arbeit, der fast fertig ist, aber noch ein kosmetisches Problem hat. Dann kann man da das in VICE erstellte d81 auch einfach benutzen. So ganz ohne Ersatzroms und dergleichen.


    Wird dann wohl mal Zeit, dass ich im OP auch einen Satz D81 ergänze...

    Hmm, da muss man erst herausfinden, wie das zu bewerten ist. Bei der normalen 1571 ist es ja auch so, dass im C64 Modus die CIA nicht benutzt wird, also der Ersatzchip 5710 wird vermutlich dann auch nicht benutzt.

    Doch, müsste eigentlich, die englische Wikipedia weiß mehr:


    The 1571 built into the European plastic-case C128 D computer is electronically identical to the stand-alone version, but 1571 version integrated into the later metal-case C128 D (often called C128 DCR, for D Cost-Reduced) differs a lot from the stand-alone 1571. It includes a newer DOS, version 3.1, replaces the MOS Technology CIA interface chip, of which only a few features were used by the 1571 DOS, with a very much simplified chip called 5710, and has some compatibility issues with the stand-alone drive.

    Tja, statt CIA 6522 haben wir einen 5710 Chip, das muss eine Emulation berücksichtigen. Und das führt auch dazu, dass die 1571 DCR Roms in einer 1571 nicht funktionieren und umgekehrt.

    Track ID vor dem formatieren (durch MakeSys) auslesen und nach dem formatieren.

    Dann sollte man sehen ob diese geändert wurde.

    Kann man machen, man kann aber auch Pech haben, dass er die alte nimmt für Track 1 formatieren und es so zufällig geht.


    Besser ist es, per "nibwrite -u" vom PC aus die Diskette komplett zu löschen, so dass die noch nicht einmal mehr formatiert ist. Dann sieht man auf Track 1 später, was wirklich gemacht worden ist.

    Das macht das Ganze noch geheimnisvoller, einmal C128 mit DCR, einmal mit "normaler" 1571... jeweils Jiffydos.



    Rein von der Logik her gibt es zwei Möglichkeiten, wie Track 1 die falschen IDs im Header bekommen kann: Track 1 wird gar nicht formatiert, so dass es die alten IDs von vor der Formatierung beibehält. Oder Track 1 wird falsch formatiert.