Beiträge von markusC64 im Thema „100 TPI auf Panasonic JU-457-4 5.25" Floppy“

    Ja, das lässt sich nicht so einfach klären... Wie auch immer, selbst wenn G82 nur dazu dient, das Zwischenergebnis bei der Umwandlung von Flux nach D82 abspeichern zu können, um das bei Bedarf für die Rekonstruktion von irgendwas nutzen zu können, dann wäre das völlig hinreichend. Ist sowieso im Grunde das G71 Format mit anderem Header (halt 8250 statt 1571), also nichts Neues.

    Hoffentlich nicht so ähnlich wie das - inzwischen als Gerücht identifizierte - analoge Statement für die 1581...

    Anderseits muss es doch einen Grund haben, dass sich Leute finden, die sogar die Mechanik aus einer 8250 / 1001 ausbauen, um per Kryoflux einlesen zu können. Um ein D82 zu erhalten, hätten die ja direkt die Floppy nehmen können.

    Gibt es eigentlich ein G82 Format?

    Da mein g64conv Nachfolger sowohl G82 als auch P82 beherrscht, muss es jene geben. Per Definitionem.

    Allerdings kenne ich kein weiteres Tool, welches die Formate benutzt. Auch keinen Emulator.

    gäbe es einen guten Grund die Images nicht in das D82 Format zu konvertieren?

    Gegenfrage: Gibt es Kopierschutz für die 8250 und den dazugehörigen PET? Wenn ja, ist die Sache eh klar, man braucht G82 bzw. P82. Wenn nicht: Auch dann kann so ein Format helfen. Vielleicht ist ein nicht lesbarer Sektor ja nur so kaputt, dass der Header kaputtt ist, die eigentlichen Daten aber okay. Das kann man in einem G82 noch korrigieren.

    Dafür bekommst Du erst mal einen Daumen hoch. Kannst Du mein Ergebnis bestätigen, dass man den Flippy Mod für die Floppy auch noch braucht, weil man ansonsten nicht alle Tracks erfasst bekommt?

    Zur Klärung kannst Du einfach eine 1541 Diskette einlesen und die Spur 1 (Commodore zählt ab 1) vergleichen.

    Also eine mit einer 1541 formatierten Diskette als Referenz müsste man sich mal ansehen. Wenn man jedoch als Referenz das nimmt, was bei Originaldisketten /1541) vorkommt, dann ist das absolut zu erwarten.

    Anderseits aber auch kein Grund zur Sorge. Auch bei einer 8250 gilt das, waw man von einer 1541 kennt: Einen Sektor kann man problemlos mit der Nachbarspeed einlesen und erhält ihn in aller Regel fehlerfrei.

    Wenn das Ding nicht dekodiert, dann würde ich das doch wirklich mal im Kryoflux Dump Format abspeichern und meine Software das dekodieren lassen. Erst wenn die auch nichts rausbekommt und g64conv auch nicht (g64conv sollte es dekodieren können mit passenden Parametern, nutzt abei aber aus, dass man die Speed nicht ganz exakt treffen muss), dann würde ich anfangen, einen Fehler zu suchen.

    Und falls der erste Track nicht passt ­ - sprich: Die Nullposition nicht passt, würde ich einen weiter hinten nehmen. Vielleicht Track 10 oder so. Aber eigentlich sehen die Werte gut aus.

    Ja, das Zusammensetzen steht auf der Wunschliste für das Powershelltool... Mit jede Menge offenen Fragen. Man will ja auch nach P64 können, also ist Dekodieren nicht besonders hilfreich. Gut, im Falle einer 8250 wäre es natürlich P82 (was noch keiner implementiert hat).

    Wenn man nach G64 bzw. meinetwegen auch G82 will, so muss man sowieso "Logik implementieren um rauszufinden wo die Drehung aufhört". Sprich: Das haben wir in jener Implementierung alles schon drin.

    Der Nachfolger ist nicht mehr in Perl, sondern in Powershell 7.3 bzw. .Net 7.

    Nachtrag: Da es eine .Net DLL ist, kann man prinzipiell die eigene Funktionalität als EXE bereitstellen und per localhost mit Python kommunizieren... Also nicht dauernd Prozesse erzeugen und abbauen.

    Ich bin da vielleicht naiv, aber gibt es so große Unterschiede in den GCR codierungen?

    Ja, dass die 8250 die Bitcellsize um genau den Faktor 16/24 gegenüber einer 1541 hat. Auf einen solch krummen Faktor ist irgendwie kaum eine Software eingestellt.

    Außerdem ist es bestimmt nützlich, die original 1541 Hardware nachgebaut zu haben im Decoder... 8250 ist bis auf dem Faktor 15&24 mit derselben Hardware dekodierbar. Nun gut, den Faktor kann man rausrechnen und dann dekodieren.

    Für "herausfinden, welcher Track eigentlich gerade center ist, ich könnte jetzt einen oder mehrere daneben liegen." müsste es reichen... Das macht man dann ja nicht für jeden Track. Ich würde sogar so weit gehen und die Disk einlesen und dann damit das Ergebnis prüfen. Bevor man irgendwas dafür programmiert.

    Ja, das hatte ich schon geplant. Wenn der eingelesene Flux grob vom erwarteten Noise-level abweicht (oder optional wenn der decoder Fehler wirft), würde ich nochmal etwas links und rechts probieren

    Links und rechts probieren kannst Du immer machen - in meiner Software zum Dekodieren kann man pro Track oder auch global angeben, welche Rotation er nehmen soll. Man kann in Problemfall dann also auf die zuvor hoffentlich gespeicherten Rotationen mit Kopf minimal innen/außen verschoben wechseln.

    ürde es nicht Sinn machen zusätzlich einen Recovery Modus zu haben wo man bei bekanntem Diskformat eine Spur dreimal eingelesen wird, einmal mittig, einmal etwas weiter und einmal etwas zurück vom Optimium

    Die Idee ist nicht schlecht. Da man in einer .SCP Datei sowieso mehrere Rotationen pro Track speichern kann und auch sollte, bietet sich das geradezu an. Man solte nur sicherstellen, dass man für jede Kopflage mindestens 3 Rotationen hat. Gerne mehr.

    diese 3 Leseversuche werden dann synchronisiert und wenn ein Flußwechsel bei zweien gleich ist wird diese Version genommen und der 3 Variante ignoriert.

    Das ist jedoch nicht so einfach. Es gibt durchaus Disketten, die öfter Lesefehler produzieren, aber nicht immer. Da ist also schon ein wiederholter Leseversuch ohne die Kopfposition zu ändern derartig, dass die eingelesenen Daten sich signifikant verändern (Lesefehler kommt und geht). Das wird durch zusätzlich Kopf bewegen nicht besser.

    Daher mein Rat: Abspeichern und fürs spätere Auswerten konservieren.

    herausfinden, welcher Track eigentlich gerade center ist, ich könnte jetzt einen oder mehrere daneben liegen. (dazu muss ich decodieren und in die header schauen - geht hoffentlich mit den GW-integrierten decodern)

    Ich schätze, das könnte Probleme machen... SFD 1001 Disketten konnte ich mit keinen Decoder vernünftig lesen (mangels komplett korrektem Dump habe ich mit synthethischer Fluxdatei experimentiert).

    Wenn Du magst, kannst Du mein in Entwicklung befindliches Tool zum Dekodieren versuchen. Das ist erheblich schneller als g64conv. Auch wenn es noch Feature incomplete ist, den Teil bekommt es derzeit schon hin, denke ich.

    Wie da schon bsprochen, ist das Ziel, mit Standard-PC-Floppyhardware bei möglichst minimalen Modifikationen SFD1001/8050/8250(100 TPI) Floppies mit Greaseweazle/Kryoflux lesen und idealerweise auch schreiben zu können.

    Mich würde mal interessieren, ob man mit der Modifikation auch noch normale 48 bzw 96 tpi Disketten lesen kann.

    Falls ja: Eine interessante Frage wäre, wenn man minimal neben der Spur einer 48 tpi Diskette liest - kann man dann eventuell Lesefehler korrigieren? Da ein 48 tpi Kopf breiter ist als ein 96 tpi Kopf, ist minimal neben der Spur wohl auch noch Signal. Es zeigt sich sogar, dass es Disketten gibt, die mit einem 96 tpi Laufwerk und FLuxhardware Lesefehler haben, eine 1541 aber fehlerfrei eingelesen bekommt. Vermutlich, weil deren breiterer Kopf mehr Signal einfängt. Das gibt Anlass zur Frage, ob leicht neben der optimalen Lage in solchen Fällen halt noch was "zu retten" ist.