100 TPI auf Panasonic JU-457-4 5.25" Floppy

Es gibt 59 Antworten in diesem Thema, welches 6.914 mal aufgerufen wurde. Der letzte Beitrag (29. Januar 2024 um 21:49) ist von Asklia.

  • Ich starte jetzt mal einen eigenen Thread, statt den Bitte melde dich an, um diesen Link zu sehen. weiter zu kapern.

    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.

    Die ursprüngliche Idee war den Schrittmotor "einfach" zu microsteppen, und mit den Zwischenschritten auf die 100 TPI zu kommen.

    Das habe ich nun verworfen, da die nicht präzise genug sind.

    Der Motor ist zwar jeweils etwas weitergegangen, aber nicht immer zur angestrebten Position.

    Kann man das sehen, wenn man die Bewegung der Spindel am Motor ansieht, manchmal kleine, manchmal große Hüpfer - nicht gleichmäßig.

    Bitte melde dich an, um diesen Link zu sehen.

    Was ich nun getan habe, ist einen anderen Stepper einzubauen. Der 3D-Drucker hat die notwendigen Adapter geliefert.

    Microstepping mache ich jetzt nur noch für einen ruhigeren Lauf. So schaut das jetzt bei 96, 100, 200, 400, 800 und 1270 TPI aus: :)

    Bitte melde dich an, um diesen Link zu sehen.

    Würde mich über Rückmeldungen, Verbesserungsvorschläge, etc. freuen.

    Wenn hier Interesse besteht, packe ich die Hardware+Software+STL files noch in eine "hübsche" Anleitung.

  • 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.

    ---
    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.

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

    Klar kann man. Ich stelle auf meinem Arduino einfach die gewünschte TPI Zahl per seriellem Port ein... 96 ist aktuell der default.

    Eine interessante Frage wäre, wenn man minimal neben der Spur einer 48 tpi Diskette liest - kann man dann eventuell Lesefehler korrigieren?

    Die automatische Spur-Justierung ist momentan tatsächlich einer der größeren Motivatoren für mich. Ich hab auch noch ein paar 96 und 48 TPI Schätzchen, wo ich altes Zeug von mir nicht sauber gelesen bekomen habe.

    Dafür müsste ich aber ideralerweise die Streams überwachen, ein paar Statistiken sammeln, und nachjustieren.

    Was sich beobachten lässt, ist dass das Signal immer genauer wird, je besser man "on track" ist.

    Links ist komplett off track (also zwischen zweien), rechts so gut on track wie's geht - alle vier der selbe Track, mit 1270 TPI gesamplet.

    Ich hab jeweils ein paar Bilder (Microtracks) dazwischen ausgelassen, weil sich nicht viel getan hat.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Die "Bänder" werden immer schmaler, und die Unterschiede zwischen den verschiedenen Umläufen werden geringer (rote Balken unten)

    Die Idee wäre also, noch beim lesen die Spur so weit nachzutracken, dass die Bänder möglichst schmal werden, erst dann das wirkliche Sampling zu starten. Ähnlich wie der Autofocus in der Kamera.

    Oder man geht absichtlich nur 0.8 Tracks weiter, und fährt während dem Sampling einfach noch 0.4 Tracks weiter. Die Anzahl Revolutions muss dann halt passen, und der Decoder muss dann auch damit klarkommen, und den jeweils besten Umlauf für einen Sektor raussuchen.

    Bei Kopierschutz und für die Archivierung (im Sinne von möglichst genaue Kopie erstellen) ist das nachjustieren vermutlich Mist, aber um Daten zu retten sollte es helfen.

    Interessant wird das ganze dann, wenn verschiedene Laufwerke (unterschiedlich justiert) unterschiedlieche Sektoren geschrieben haben.

    Die Bereiche, in denen man so kompletten Mist wie links bekommt, sind übrigens recht schmal. Vielleicht 4-5 von 26 Zwischentracks (bei 48 TPI Disks). die anderen 21 geben mehr oder weniger gute Resultate.

  • Die Idee wäre also, noch beim lesen die Spur so weit nachzutracken, dass die Bänder möglichst schmal werden, erst dann das wirkliche Sampling zu starten.

    Histogramm über alle Pulslängen einer Rotation und die Kopfposition darauf optimieren, dass die grösste Anzahl in dem Histogramm möglichst gross ist? Schmale "Bänder" heisst ja Verteilung auf weniger Histogramm-Klassen und damit höhere Werte in den Einzel-Klassen.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    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.

  • Histogramm über alle Pulslängen einer Rotation und die Kopfposition darauf optimieren, dass die grösste Anzahl in dem Histogramm möglichst gross ist? Schmale "Bänder" heisst ja Verteilung auf weniger Histogramm-Klassen und damit höhere Werte in den Einzel-Klassen.

    Ja, danke für's Erden :) ich hab schon wieder viel zu kompliziert gedacht.

    Also Histogramm in 0.1µs Schritten (sinnvolle Quantelung?), 0-12 µs Bandbreite, dann aber ehrlichgesagt lieber versuchen die Anzahl der Null-felder zu maximieren. Ich bin ja nicht daran interessiert möglichst viele auf exakt 6.1ms zu haben, sondern möglichst viel Platz dazwischen. In der Realität wird es aber vermutlich auf's selbe rauskommen.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Um so etwas mitzunehmen (aus dem Kryoflux manual - Beispiel für deformierte Disk oder instabile Drehzahl), wird man dann vermutlich den Abstand vom Index-loch auch noch in Blöcke unterteilen wollen.

    Mit den heutigen Rechnern und GB von RAM ja auch nicht wirklich ein Problem.

    Edit: Quantelung angepasst

  • Nochmal ein Zwischenstand:

    Ich habe die GW-Firmware etwas gepatched, um mehr als 100 Cylinder anfahren zu können ( noch nicht sicher ob wirklich notwendig), und auch das GW Python frontend, damit es mit meinem Hardware-Mod kommunizieren kann.

    Ich habe auch die Histogramm-Idee umgesetzt, und das liefert wirklich schöne Werte.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Verschiedene Disks, reichlich durcheinander, mal runterbrechen...

    Nach oben ist der "noise-level", nach rechts der 0.02mm offset von meinem "norm-0"

    Mein Norm-0 ist nach dem Hardware-mod sehr sicher nicht gut on-track, es ist nur das wo ich gegen meinen track-0 sensor kalibriere.

    Die Werte sind leicht geglättet (moving average über 3 offsets), für die weitere Betrachtung ist das glaube ich belanglos.

    Was man sehen kann ist, dass die verschiednenen Formate sich anscheinend nicht auf einen einheitlichen track-center einig sind, und dass offenbar der Noise-Level zwischen den Tracks mit der TPI-Zahl massiv abnimmt...

    1) Positioniergnauigkeit

    Bitte melde dich an, um diesen Anhang zu sehen.

    Mal nur eine 96 TPI disk und eine 48 TPI Disk, mehrfach gelesen, auch mit Diskettenwechsel.

    Man sieht sehr schön, dass der Hardware-mod erstaunlich präzise ist ( repeatability ), ich würde schon fast sagen, perfekt.

    Auch auffällig: bei 48 und 96 TPI hätte ich erwartet, dass die Noise-Spikes (also das wo man zwischen den Tracks ist) an den selben Stellen sind, nur bei 96 TPI doppelt so häufig.

    Mein Laufwerk würde ich als Fehlerquelle mal ausschließen, wegen der Wiederholbarkeit. Auch wenn ich off-track bin, sollten die Graphen um den selben Wert verschoben sein.

    2) verschiedene Disks

    Bitte melde dich an, um diesen Anhang zu sehen.

    grün und grau sind die selbe Disk, mit diskwechsel 2-mal gelesen. Rot eine andere 96 TPI disk. (vermutlich mit dem selben Quelllaufwerk geschrieben)

    Passt soweit, würde ich sagen.

    3) 100 TPI

    Bitte melde dich an, um diesen Anhang zu sehen.

    Blau ist die SFD1001 Disk von Markus, Grau die 8050 Testdisk von Andato77

    Bei der 8050 scheint es wichtiger zu sein, exakt on-track zu sein, denn die Täler sind zum Teil recht eng. Die beiden Laufwerke scheinen sich aber relativ einig zu sein wo der track-center ist.

    To-Do:

    a) Track-center tuning programmieren ( relativ trivial )

    b) 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)

    c) alles noch aufräumen - im Moment ist es ein ziemliches gehacke..


    Edit: Typo

  • Wü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, diese 3 Leseversuche werden dann synchronisiert und wenn ein Flußwechsel bei zweien gleich ist wird diese Version genommen und der 3 Variante ignoriert.

    Interessant wäre dann natürlich eine Statistik wie oft jede Variante eintrifft und ob wohlmöglich auch mal Optimaler Track hat Fehler aber beide etwas daneben Leseversuche nicht vorkommt.
    Das müßte auch bei unbekanntem Format funktionieren aber bei bekanntem Format kann man evtl. noch per CRC auf valide oder nicht testen.

  • 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.

    ---
    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.

  • Wü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, diese 3 Leseversuche werden dann synchronisiert und wenn ein Flußwechsel bei zweien gleich ist wird diese Version genommen und der 3 Variante ignoriert.

    Interessant wäre dann natürlich eine Statistik wie oft jede Variante eintrifft und ob wohlmöglich auch mal Optimaler Track hat Fehler aber beide etwas daneben Leseversuche nicht vorkommt.
    Das müßte auch bei unbekanntem Format funktionieren aber bei bekanntem Format kann man evtl. noch per CRC auf valide oder nicht testen.

    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.

    Das war meine erste implementierung, aber dann hat er auf einmal mehr oder weniger jeden Track versucht zu optimieren, und ist dabei auch übers Ziel hinausgeschossen und hat dann den Nachbartrack 2x gelesen...

  • ü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.

    ---
    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.

  • 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.

    ---
    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.

  • 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.

    Gern, aber das war, wenn ich mich recht erinnere, in Perl. Das würde bedeuten, dass ich eine Datei schreiben und einen System-Call aus dem Python heraus machen muss.

    Ich würde es mal mit dem integrierten GCR decoder probieren, viellicht bekommt der ja einen Sektor-header decodiert. Brauche ja nur einmal den Track.

    Ich bin da vielleicht naiv, aber gibt es so große Unterschiede in den GCR codierungen? Hier hab ich jetzt erstmal nichts entsprechendes gesehen.

    [ Bitte melde dich an, um diesen Link zu sehen. ]

  • 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.

    ---
    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.

    2 Mal editiert, zuletzt von markusC64 (4. Oktober 2023 um 18:17)

  • Ja, dass die 8250 die Bitcellsize um genau den Faktor 16/24 gegenüber einer 1541 hat.

    16/24 ist ja irgendwie 2/3 :wink: OK, trotzdem eine krumme Zahl...

    Greaseweazle hat intern schon die Funktion den Flux umzurechnen für unterschiedliche RPM Werte. Wenn ich also auf 3/2 => 150% gehe, müsste ich mit der Bitcellsize ja wieder auf dem Standard liegen.

    Probiere ich nachher mal aus.

  • Außerdem ist es bestimmt nützlich, die original 1541 Hardware nachgebaut zu haben im Decoder

    Ah, das hab ich jetzt erst beim nochmal drüberlesen verstanden. Du hast also die Original-Hardware in einer .net DLL emuliert/nachgebaut? Cool :)

  • Ja, aber es macht incht so viel Sinn, die Zahlen zu kürzen. Ich bin mir ziemlich sicher, dass von den Bruch Zähler und Nenner jeweils in MHz sind, nämlich der Clock der Dekodiereinheit. Den Zahlenwert durch Kürzen kaputtmachen macht das ganze unverständlicher.

    ---
    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.

  • 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

    Und hier frage ich mich, woran das eigentlich liegt. Die magnetischen Domänen sind ja wohl immer da, oder halt nicht, nur manchmal wird der flux-change erkannt, und manchmal nicht.

    Ich würde jetzt drauf tippen, dass der "Rand" der magnetischen domäne irgendwie unscharf ist, und damit der Strom-Spike im Lesekopf nicht mehr steil genug ist.

    In dem Fall könnte eine x-tel Spur hin oder her schon einen Unterschied machen, wenn da das Medium noch sauber ist.

    Oder wenn eine Spur / ein Sektor mit einer anderen Floppy geschrieben wurde, die leicht anders kalibriert war.

    Ich könnte klar immer drei versionen vom Track schreiben, viertel vor, punkt und viertal nach - was ich gerne umgehen würde ist, die Flux zusammenrechnen zu müssen. Beim Index auseinandernehmen und zusammensetzen funktioniert für die GCR Disks vermutlich nicht so gut, weil die nicht am Index orientiert sind. Ich müsste also dann Logik implementieren um rauszufinden wo die Drehung aufhört.

    Oder ich steppe einfach unter dem Lesen, aber das wird mit dem timing schwer. mal schauen.

  • 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.

    ---
    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.

  • Commodore GCR scheint nicht Standard zu sein

    Sondern optimiert.

    Bitte melde dich an, um diesen Link zu sehen.

    In der Engl. Version sind mehr Informationen

  • Commodore GCR scheint nicht Standard zu sein

    Das stimmt - u. a. Apple machte das anders. Aber okay, Commodore hat für die 8250 das selbe GCR wie für die übrigen Floppies benútzt. Solange man also drauf achtet, dass Commdore GCR genommen wird, passt alles.

    ---
    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.