Posts by strik

    Die ID wird in jeden Sektor-Header reingeschrieben. Und dort sind - oh Wunder - genau zwei Byte für reserviert. (Für die Korinthenkacker: Zwei Byte *vor* der Umwandlung in GCR).


    Im im BAM-Sektor (Track 18, Sektor 0) wird die ID abgespeichert, und auch dort sind - wieder völlig überraschend - zwei Byte vorgesehen.


    Wenn ich jetzt noch einmal genau wüsste, wieso die ID aus 2 Zeichen bestehen muss...


    Und: Ja, die beiden Zeichen sind (nahezu) beliebig.

    Wie ist denn der genaue Zustand der IO Bausteine nach dem einschalten bzw. nach einem Hard-Reset?

    Ich dachte eigentlich, dass alle Register Bits einfach auf null stehen?

    So einfach ist es tatsächlich nicht. Die Frage kann ich dir allerdings auch nicht beantworten. Du kannst aber mit den VICE-Kollegen diskutieren, da gab es zumindest früher einige Versuche.


    Ansonsten bedenke bitte, dass manche Chips (VIC-II) gar kein RESET-Signal haben. Sprich, sie können darauf gar nicht reagieren.

    Wenn doch, müsste die ZoomFloppy das ja am besten auch bekommen. Wer pflegt denn da die Firmware? go4retro oder strik ?

    Martin hat die FW für das ZF auch geändert, allerdings kann er es mangels ZF nicht testen.


    Ich habe ZF, aber kein Laufwerk mit JD. Mein EPROM-Simulator ist gut verstaut. Da ich gerade einen Haufen Projekte (leider auch dringerere als dieses Hobby) gleichzeitig habe, habe ich keine Zeit dafür, das alles aufzubauen um es testen zu können.


    Wenn jemand mit ZF-Gerät einen Test machen will kann thierer oder ich bestimmt eine Firmware zur Verfügung stellen.


    Grundsätzlich "gehört" die FW des ZF wohl Nate Lawson, allerdings machen sowohl thierer (einige) als auch ich (wenige) da commits.

    Ich werde OpenCBM noch einmal neu installieren, ich bin mir sicher das es auf dem alten Rechner funktioniert hat

    Ich bezweifle, dass das etwas bringt.


    Kannst du mal d64copy auf der Kommandozeile ausführen?


    Code
    1. d64copy 8 test.d64


    liest die Diskette in Laufwerk 8 aus und speichert sie in die Datei test.d64


    Wenn das sehr langsam ist, geht dann


    Code
    1. d64copy -tp 8 test.d64


    schneller? Hier frage ich speziell nach dem Parallelkabel ("-tp") und die automatische Erkennung wird abgeschaltet.


    Solange du die Kommandos so abtippst kannst du mit ihnen nichts falsch machen (Achtung, die Reihenfolge ist WICHTIG!)

    Aber ich hatte immerwieder Schwierigkeiten mit anderen Kernals als dem Original,

    vermutlich weil die Einsprünge für die Z(X)oomfloppy Routinen nicht mehr 100% stimmen.

    Die Einsprungpunkte sind weniger ein Problem. Allerdings benutzen manche ROMs Speicheradressen, bei denen die OpenCBM-Routinen auf die Nase fallen. Das gab es das eine oder andere Mal.


    Gibt es das SpeedDOS-ROM eigentlich im Netz? Oder kannst du es auslesen? (Das kann notfalls auch cbmctrl aus OpenCBM: cbmctrl download 8 0xc000 0x4000 floppyrom.bin schreibt es von Laufwerk #8 in die Datei floppyrom.bin. Die Datei sollte danach 16.384 byte groß sein)


    Verändert SpeedDOS mehr als nur die parallele Verbindung zum C64? Laut den Bildern auf https://www.c64-wiki.de/wiki/SpeedDOS sehe ich nichts, was auf weitreichendere Änderungen hindeuten würde.


    EDIT: Laut http://www.zock.com/64er/8510/0008.html nur Parallelkabel und alternatives EPROM.

    EDIT2: Ich habe mal nachgeschaut, WoMo hat schon 2004 immer mit SpeedDOS getestet. Das dürfte neben dem originalen ROM damit das am besten getestete ROM sein. Gerade deshalb wäre interessant, wie das ROM aussieht. Möglicherweise gibt es da Unterschiede und es ist ein gepatchtes.

    Scheint tatsächlich ein Bug zu sein, sieht so aus als wäre da ein falscher Menu Handle benutzt worden.


    Hat offenbar niemand bemerkt in den letzten 20 Jahren.

    Der Bug war noch auf meine Liste offener/zu fixender Punkte.
    Der Monitor war eigentlich WIP und sollte nie so "vor Endkunde" gehen. Mangels Zeit habe ich es damals aber auch nicht zu Ende machen können.

    1.) feststellen, dass es bis heute kein Tool gab, um am C64 Disketten/Sektoren miteinander vergleichen zu können, inklusive exakter Anzeige der abweichenden Sektoren und Bytes inkl. der Position der Bytes im Sektor, inkl. Differenz-Report mit Aufzeigen von Bitunterschieden (weshalb ich diesen alten Thread auch nicht als "erledigt" betrachten konnte)

    Wenn du ein "super-duper-Tool" benötigst, dass für diesen einen Anwendungsfall die Ausgabe in genau der Art und Weise erzeugt, wie du sie haben willst - ja, dann hast du recht, dann gibt es dieses Tool nicht. Also quasi einen Hammer, der auf 5mm lange Nägel mit 1,5 mm Kopfdurchmesser optimiert ist, dabei noch eine federgesteuerte Krafteinstellung für die Anwendung der richigen Kraft beim Schlagen auf verschiedene Untergründe hat - den gibt es noch nicht. Da mag dein Tool eine Ergänzung sein.


    Für alle anderen, sinnvollen Fälle gibt es genügend Tools. Vorschläge hast du ja bekommen. Dafür gibt es "universelle" Hämmer, mit denen das Arbeiten durchaus möglich ist. Das hat dann auch den Vorteil, dass ich mich nicht in die Anwendung reinfuchsen muss, wenn ich mal andere Nägel nutzen muss oder andere Untergründe. Oder benötige ich dann den nächsten Spezialhammer, der wiederum anders funktioniert?

    Aber würde hier dann ein normales Checksum-Vergleichs-Tool am PC diese beiden Images als gleich anzeigen oder nicht?

    Ich Vergleichs-Tool, welches nur die Binärdaten anschaut (und nicht die Inhalte interpretiert), würde das immer als verschieden anzeigen.


    Um es gleich anzuzeigen muss es in die Daten reinschauen und sie "interpretieren", um festzustellen, dass zum Beispiel kleinere zeitliche Abweichungen keinen Einfluß auf den Nutzdateninhalt haben. Hierzu bräuchte es eines sehr spezialisierten Tools.

    Aber ein Vergleich von .D64 Images macht ja auch nur begrenzt Sinn. Genügt ja ein anderer Header, schon sind zwei .D64 Images unterschiedlich, auch wenn sie sonst die selben Daten enthalten.

    Es kommt drauf an, was du brauchst. Wenn du sicher sein willst, dass die Disketten gleich sind, musst du das machen. Wenn du wissen willst, ob die Dateien auf der Diskette gleich sind, musst du die vergleichen.


    Sehr brauchbar für den Vergleich von .D64 Images wäre ein Tool, welches die darin enthaltenen Dateien (.PRG, .SEQ, usw.) von zwei .D64 Images gegeneinander vergleicht!

    Es gibt da z.b. ein .D64 Plugin für den Total Commander, allerdings fehlt dem leider die 'Direcotry's Synchronisieren/Vergleichen' Funktion

    Wieso ein spezielles Programm um D64 miteinander zu vergleichen?


    Es reichen:

    1. Ein Tool, um Dateien aus einem D64 zu extrahieren (c1541 aus dem VICE-Paket ist eine, aber nicht die einzige Option hierzu)
    2. Zum Feststellen, ob die Dateien identisch sind: Ein Vergleichstool (fc unter Windows, diff unter Unixoiden), alternativ auch ein Programm, welches eine Prüfsumme bildet (md5sum, sha256sum, ...) - wobei die Prüfsumme die (vermutlich vernachlässigbare) Gefahr enthält, dass trotz Unterschieden trotzdem die gleiche Prüfsumme rauskommt.
    3. Zum Feststellen, wo sich die Dateien unterscheiden: Ein Tool, um Binärdateien in Hex-Darstellung zu wandeln (ich nutze hier gerne xxd), sowie ein Vergleichstool (diff wäre wieder möglich, oder, bei größeren Komfort, wdiff)
    4. Je nachdem, wie groß die Unterschiede sind, ein Texteditor und/oder Viewer. Ich nutze hier gerne vim, andere gehen aber genauso.


    Wenn ich ganze Images vergleichen will lasse ich Nr. 1 weg und arbeite am Image. Zum Vergleich "identisch/nicht identisch" nutze ich diff, ansonsten ein dem diff vorgeschaltetes xxd.


    Jedes Tool kann eine Aufgabe, die aber dann richtig. Da brauche ich keine super-duper zusammengestellten Tools für eine Speziallösung. Die Kette geht mir auch schon so von der Hand, da muss ich gar nicht mehr drüber nachdenken.


    Der Vorteil: Wenn ich mal andere Dateien habe funktioniert die ganze Toolkette, mit leichten Anpassungen, immer noch. Das ist bei spezialisierten Tools meistens nicht der Fall.


    Die Kette kann ich auch rückwärts machen: Eine Hex-Darstellung, die mit xxd gewonnen wurde, kann mit "xxd -R" auch wieder zurück in eine Binärdatei umgewandelt werden. So kann ich also recht einfach editieren.


    Klingt das kompliziert? Das ist es nur auf den ersten Blick, dafür sehr flexibel handhabbar.

    Ich war etwa Ende der 80er (so im Zeitrahmen von etwa 1988 - 1990) beim Starlight Express in Bochum. Damals war es ja noch recht neu.

    Auf dem Weg zum Platz und zurück kam man an einem Raum vorbei, in dem offenbar Technik steckte, die die Anlage steuert. Ich bin mir sicher, dass ich damals einen Haufen Amigas gesehen habe. Ich bin mir da ziemlich sicher, weil ich damals davon wirklich begeistert war.


    Leider habe ich außer meiner Erinnerung nirgendwo einen Satz oder ähnliches gefunden, was mich hier in meiner Erinnerung unterstützen würde.


    Kann das jemand bestätigen? Oder spielt mir mein Gedächtnis wirklich einen Streich?

    Noch vergessen: Eine Diskette ist recht stark geknickt, sie bleibt im Laufwerk stecken und muss recht umständlich rausgeholt werden. Keine Ahnung, ob das Auswirkungen haben kann? Z.B. könnte sie nicht mehr gut drehen, vor allem, wenn der Innenring nicht mehr sauberen Kontakt hat.


    Aber bei mir war halt auch alles lesbar, wobei ich jede Diskettenseite 5 mal mit d64copy und 5 mal mit nibread ausgelesen habe.

    Hallo,


    ich habe 3 von den Disketten geschickt bekommen und eine erste Analyse:


    2 der 3 Disketten lesen sowohl die 1541 ("-I", Assy 154008) als auch die 1571 problemlos. Die D64 images sind bis auf das letzte Bit identisch.


    Die dritte Diskette hat Leseprobleme auf Tracks 34 und 35. 35 ist offenbar unformatiert, keins der Laufwerke kann eine SYNC-Markierung finden. Track 34 hat offenbar Inhalte; die 1571 schafft es, bis auf einen Track alle zu lesen (manchmal hat auch ein zweiter noch nicht-behebbare Fehler), während die 1541 die hälfte der Blöcke nicht lesen kann.


    Dumm nur, dass die beiden Tracks 34 und 35 gar nicht verlinkt sind, so dass das Laufwerk gar nicht versuchen sollte,darauf zuzugreifen.


    Was mir noch aufgefallen ist: Eine der beiden problemlosen Disketten ist nur einseitig. Auf der Rückseite konnte ich allerdings von Track 5 aufwärts Daten erkennen, allerdings nicht lesbar. Ich vermute, dass es sich um MFM-Format handelt, so dass ich von einer doppelseitig formatieren PC-Diskette ausgehe, die es mal war. Ich weiß, dass es beim Wechsel einer Diskette von PC auf Commdore immer mal wieder Probleme gab. Meine Laufwerke können allerdings alles lesen, so dass ich nicht daran glaube.


    Eine Vermutung die ich noch habe (neben einem verstellten Kopf): Die Drehzahl der Laufwerke. Wenn sie zu sehr in eine Richtung gehen, könnte ich mir auch da Probleme vorstellen. Kennt jemand ein Programm für den C64 oder C128, welches die Drehzahl eines Laufwerks bestimmt? Ich nutze da immer nur OpenCBM.

    Dir ist schon klar, dass die Aussage mit der ursprünglichen Fragestellung nur bedingt etwas zu tun hat? Ein PC-Laufwerk ist keine 1571.

    Theoretisch sollte es keine Unterschiede geben, praktisch kann ich das nicht ausschließen. Ich habe keine Ahnung, was die Kombo des Erstellers da macht.


    Ist denn überhaupt eine Disk mit einer 1571 geschrieben worden? Für mich klingt die Antwort nicht so.


    Die 27,READ ERROR sagt, dass zwar was gelesen werden konnte, die Prüfsumme aber falsch ist. Das könnte schon von einem einzigen falschen Bit hervorgerufen werden. Da ist es durchaus naheliegend, dass beim Schreiben etwas schiefgelaufen ist.