Suche Kryoflux Controller

  • Ich habe jetzt nochmals mehrere Stunden lang damit verbracht Informationen rund um unser Problem mit hartsektorierten Disketten zu sammeln. Einfach damit wir nicht wiederholen müssen, was andere vor uns ausprobiert haben.

    Das Lesen dieser Disketten ist möglich, Schreiben de facto noch nicht.

    Das Laufwerk muß passen. D.h. nicht nur Spuranzahl und Dichte sondern auch die Hardware zur Erkennung des Index-Loches. Die Controller wie Catweasel, KryoFlux, DiskFerret u.s.w. brauchen hier eine bestimmte Pulslänge. Mehrere Vordenker haben dieses Problem erkannt u. Empfehlungen was das zu verwendende Laufwerk angeht ausgesprochen. Auch mit 360 Upm drehende 1,2 MB Laufwerke können ein besseres Ergebnis liefern als ältere "originalere"

    Laufwerke mit 300 Upm. Direktantriebe sind solchen mit Riemen vorzuziehen.

    Jay Jaeger z.B. hat mit einem Catweasel mehrere hartsektorierte 8" Data General Disketten lesen u. Images erstellen können.

    Chuck Guzis hat scheinbar viel Zeit aufgewendet, um Disketten einer frühen AES/Lanier lesen zu können und dabei erstaunliche Absonderlichkeiten festgestellt. Z.B. MMFM bzw. M2FM Codierung, alle Sector Header sind absolut identisch, die Sektornummer steht mit im Datenfeld! Und als wäre das Alles nicht schon genug, ist die Bitabfolge in jedem Byte umgedreht, quasi rückwärts aufgezeichnet.

    Dann gibt es noch absichtlich verstellte Laufwerke (Track 0 Sensor), um noch eine Spur mehr aufzeichnen zu können.

    Aber warum geht das Schreiben noch nicht?

    In der Theorie müsste es gehen, wenn beim Schreiben das Index-Loch als Referenzpunkt verwendet wird. Die Software zum Schreiben muss das Timing

    aber verändern können, damit die ganze Spur zwischen zwei Index-Impulsen passt. Da braucht es sehr wahrscheinlich mehrere Versuche pro Spur mit immer neuem Lesen u. sofortigen Vergleich. Das Problem wird auf den inneren Spuren immer größer und der Datenseparator, hier der AES, kommt aus dem Tritt,

    obwohl er sicherlich, wie bei anderen Controllern, durch Early und Late Signale für den Separator eine Synchnonisation zu erreichen versucht.

    Womit ich bisher nicht gerechnet hatte, ist "noise", der beim Aufzeichnen der Fluxwechsel gnadenlos mit aufgezeichnet u. digitalisiert wird. Da sind schnell einige Bits vorhanden, die eigentlich nicht existieren sollten.

    Erst durch eine Dekodierung der Aufzeichnung, also FM, MFM, M2FM, GCR werden die Störsignale eliminiert.

    Man müsste also die Aufzeichnung erst derart bearbeiten und dann zurückschreiben, damit es "sauber" wird. Das bedeutet aber einen hohen Programmieraufwand und nicht zuletzt Kenntnisse des Aufzeichnungsformats.

    Das direkte Zurückschreiben bleibt mehr oder weniger ein Zufallsprodukt. Hierzu habe ich noch folgende Anmerkungen gefunden.

    -Floppykabel möglichst kurz und abgeschirmt zu halten

    -Evtl. Terminierung des Busses überprüfen bzw. vornehmen.


    Alles in Allem ist keine wirklich schnelle Lösung des Problems in Sicht.

  • Zitat von fishermansfriendtoo

    Aber warum geht das Schreiben noch nicht?

    In der Theorie müsste es gehen, wenn beim Schreiben das Index-Loch als Referenzpunkt verwendet wird. Die Software zum Schreiben muss das Timing

    aber verändern können, damit die ganze Spur zwischen zwei Index-Impulsen passt. Da braucht es sehr wahrscheinlich mehrere Versuche pro Spur mit immer neuem Lesen u. sofortigen Vergleich. Das Problem wird auf den inneren Spuren immer größer und der Datenseparator, hier der AES, kommt aus dem Tritt,

    Diese Logik kann ich nicht ganz nachvollziehen. Bei herkömmlichen Controllern wird der Datenstrom mit konstanter Geschwindigkeit rausgeschrieben. Es sind auf jedem Track gleichviele Sektoren, so auch bei der hardsektorierten Disk. Der Indeximpuls (für den Trackbeginn) kommt immer im gleichen Intervall (abgesehen von Drehzahlschwankungen). Ich gehe auch davon aus, dass Kryoflux & Co. das Timing des Datenstromes berücksichtigen. Was sich von Spur zu Spur ändert ist die Datendichte auf dem Speichermedium selbst. Auf Track 0 sind die Daten weit auseinandergezogen, auf der innersten Spur sind sie wesentlich dichter, müssen aber immer noch fehlerfrei verarbeitet werden können. Deshalb gibt es ja auch variable Formate, bei denen die Geschwindigkeit variert, um mehr Daten auf den äußeren Spuren unterbringen, zu können.


    Meiner Meinung nach wird das Schreiben erst dann 100% funktionieren können, wenn die Sektorlöcher mitberücksichtigt werden.


    gpospi Falls Du Zeit hast, könntest Du noch folgendende Versuche am AES durchführen. Eine "selbst-gelochte" Diskette am AES beschreiben. Bei den Lochungen absichtlich etwas im Umfang (Winkel) verrutschen, um festzustellen, wie tolerant der AES ist. Eventuell sehen was passiert, wenn ein Loch zu wenig vorhanden ist. Analog dazu wäre es interessant, eine mit Kryoflux duplizierte Diskette (noch ohne Sektorlöcher), ebenfalls mit etwas unregelmäßigen Löchern zu versehen und am AES einlesen (was ja schon bisher mit Textfiles teilweise gelungen ist). Außerdem könnte man nochmal so eine Disk (von AES beschreiben, aber mit leicht verschobenen Sektorlöchern, falls damit überhaupt funktioniert) mit Kryo einlesen und sehen, was sich im Image verschiebt.


    Gruß, PAW

  • Aus meiner zuletzt gemachten Recherche hier ein Zitat aus dem FluxEngine Forum. Angemerkt sei noch, auch hier geht es hauptsächlich darum ein Image zu erzeugen und nicht um das Zurückschreiben desselben, was wir wollen. Es geht hier auch um die Technik, wie die Flux-Aufzeichner arbeiten.

    Für den Catweasel wird klar was mit der Unterstützung von hartsektorierten Disketten ab dem MK4 gemeint war.


    In einem weiteren Thread, ich hoffe ich finde den auch noch wieder, wurde noch bemängelt, das der Catweasel vom Hersteller zu stiefmütterlich supported wurde, weshalb nur wenige fähige Programmierer Software für ihn geschrieben haben, aber immerhin alles open source.

    Der Kryoflux ist aktuell, aber nicht open source und es hängt an seinen Entwicklern, uns die gewünschten Funktionen zu implementieren.


    Haben wir ein Abbild der ersten, scheinbar richtig gelesenen, Spur? Und zum Vergleich ein Re-Read von der erstellten Kopie? Wo sind mögliche

    Unterschiede entstanden, und können wir die Samplingrate verändern, um zu viel Datenmüll zu verhindern?



    In #retrocomputing #fluxengine news:

    A little while back someone sent my a Kryoflux image of my first hard sectored floppy disk, one which uses multiple index holes to identify where sectors are. These was for an AES Data Superplus / Lanier No Problem word processor. It was actually pretty easy to decode even without the index holes, as sectors could be identified by a magic number in the data stream. http://cowlark.com/fluxengine/disk-aeslanier.html

    However, since then I’ve received another one. This one’s for a Zilog MCZ 1/20, a very early Z80 development minicomputer from 1976. http://www.retrotechnology.com/restore/zilog.html

    This one’s interesting. 32 sectors, 128 bytes per sector (plus four bytes of metadata used to form a doubly-linked list with other sectors in a file), and very hard sectored. There’s no identifiable record separator. Instead, the controller waits for an index pulse, synchronises its clock against the bitstream, and then waits for the first data bit. This is the high bit of the sector number in the sector header, so once it’s seen that it knows where the byte boundaries are.

    The trouble is that this same sequence may be embedded inside perfectly valid data. I can’t reliably find it from looking at the data stream alone.

    What I probably need to do is to take into account the index information as well. Currently FluxEngine doesn’t do this, for simplicity — the only data it captures is the intervals between pulses (I attach a picture of the source code of the FPGA firmware which does it: yes, really). The index signal is a completely independent timing stream.

    The Kryoflux handles this by having multiple parallel timing streams. The Catweasel does (well, did) it by recording the state of the index signal on every pulse. From the firmware perspective, the latter’s preferable, although I’m not sure I have enough space in my coprocessor datapath thingy to actually do it; I can only have two more states in my FSM. (I could always add another FSM and chain them. I’m using 3, and my device has space for 24.) But when writing pulse streams, things get more complicated, as things are now no longer symmetrical: reading doesn’t produce data which I can write.

    From the decode perspective… ugh. Right now the decode pipeline is: Guess clock → Decode to raw bits → Segment into records → Parse each record and produce a bag of sectors → Assemble the sectors in the right order. Taking index information into account means my raw bitstream needs to be annotated somehow. It’s not a std::vector<bool> any more…

    I sense another major refactor coming along.


    Ein anderer Autor macht folgende Anmerkungen zum Schreiben hartsektorierter Disketten auf per Flux Basis:

    "

    Actually, I'm mucking with a catweasel card right now.


    I took Tim Mann's code as a starting point and I'm going from there. I


    don't have any use for his decoding routines nor of making virtual disk


    images since my needs are different. However, I can't imagine how many


    hours of work he saved me by having routines that locate the card in PCI


    space. Also, his "trackhist" program provided some very useful


    subroutines. With the help of Tim's code, it took me less time to


    modify/write the code to decode the disk format than it did to rig up


    the 34-pin to 50-pin ribbon cable adapter.


    Anyway, I can provide an example disk format where the catweasel, as it


    stands, can't write the disk image, at least not without some dodgey


    trial & error (try to write a track, read it back and if it is mucked


    up, try and adjust the write timing for the next attempt. Even then,


    there is a lot of luck involved).


    Hard sectored disks are a problem for the catweasel to write. There is


    a function to write from index mark to index mark, except the catweasel


    assumes there is just a single index mark per revolution. Thus, you can


    write one sector, but you can't even reliably tell it which sector you


    want -- it just starts at the next index hole that appears. Perhaps


    under DOS you can disable interrupts and figure out via polling when


    sector N is about to appear and use index-to-index write mode. Even


    this doesn't suffice for the disk format used by the Processor Tech


    Helios system. It ignored every other sector mark so that effectively


    there were 16 256B sectors instead of 32 128B sectors. Further, blocks


    of data could be larger than 256B -- they simply spanned more than one


    sector. Thus, this mode is useless for that scheme.


    You can do a write where you specify "wait for an index hole, then write


    this sequence of transitions". The problem is that due to speed


    variations you can't say that index 5 is going to come exactly (166 2/3


    ms / 32) after index 4. That is where you could try to write the whole


    track, then read everything back to see if you succeeded and if not,


    adjust the clock pulses wider or shorter to make things line up. Oh


    yeah, in this mode I think it doesn't wait for an index hole, it just


    goes whenever you tell it to, so good luck trying to get the data to


    line up with the index marks at all.


    As it turns out, now that I have the catweasel set up and running, there


    are three disk formats that I would personally find useful to be able to


    decode -- 8" Helios, 8" Wang 2200, and 5.25" Northstar. Guess what --


    all three are hard sectored formats. Luckily, I'm really only looking


    to use it to archive virtual disk images, not to create new disks."

  • Habe mir mal Gedanken gemacht, wie man das Index- oder wahlweise das Sector1-Signal von der Diskette mit 2-3 TTLs ausfiltern könnte ohne dabei die Disketten zu manipulieren.

    Indexfilter_Entwurf .jpgIndexfilter_Logik.jpg

    Ob das so wirklich funktioniert weiss ich noch nicht, ist noch nicht getestet.

    Zum Einsatz kämen ein NE555 als Monoflop, ein 7400 für Invertierungen und ANDs, und ein 74164 Schieberegister.

    Vielleicht hat ja noch einer ne Idee das noch weiter zu vereinfachen.

  • Schönen Abend!

    Zitat von mister-freeze

    Ob das so wirklich funktioniert weiss ich noch nicht, ist noch nicht getestet.

    ACHTUNG! Beim SHUGART-BUS werden alle Leitungen auf der Empfängerseite mit einem Pull-Up von ca. 150 Ohm auf Plus gezogen. Das bedeutet für die Schaltung, dass am Eingang von Index der Pullup fehlt. Beim Ausgang braucht man stärkere Treiber die ca. 40mA treiben (auf LOW ziehen) können, da ja im PC ebenfalls mit 150 Ohm nach oben gezogen wird. (5 Volt / 150 OHM = 33mA)


    In den alten Schaltungen wird z.B. der 7438 verwendet, der 48mA ziehen kann. Ein 74LS38 schafft nur mehr 24mA.

    Der 74LS00 kann überhaupt nur 8mA ziehen.


    Befasse mich gerade mit der Problematik, da ich ähnliches mit einem Arduino machen möchte.


    Grüße, PAW

  • PAW jetzt muss ich doch nochmal nachhaken, wel ich gerade überlegt habe welche Pull-Ups ich dann für die Open-Collector-Ausgänge des7438 brauchen würde.


    Die Controller die ich habe (Greaseweazle und Fluxengine) haben eigentlich keine PullUps an den Eingängen der Microcontroller...Beim Kryoflux weiss ichs nicht, aber ich kann mir da auch nicht vorstellen, dass man hier am /INDEX Eingang einen Pullup verbaut hat. Von daher wäre es doch schnuppe wenn der Ausgangsbaustein keine hohen Ströme liefert. Oder übersehe ich da was ?


    Was für einenPullup Widerstand würdest Du am Eingang des Filters machen ? Die von Dir genannten 150 Ohm kommen mir gefühlt zu niederohmig vor .

  • mister-freeze


    ich habe mir die Schaltpläne von IBM-AT und von Philips P2500 angesehen.

    Bei IBM sind sowohl auf dem Floppydrive, als auch auf dem Controller jeweils 150 Ohm Widerstände vom jeweiligen Eingang auf +5Volt vorhanden. Bei den Ausgängen gibt es keinen Pull-Up. Das bedeutet bei Flopy-Drive geht der Ausgang vom 7438 direkt auf den Stecker (Leitung). Dafür ist am anderen Ende beim Controller ein Pull-Up vorhanden, der über die Leitung den Strom zieht. Die gleiche Logik bei Philips.


    Hier ein Auszug aus dem Schaltplan des FDC Controllers. (findet man in diversen Technical Reference Manuals von Personal Computer). Links die Eingänge, rechts die Ausgänge:Diskettencontroller.JPG

    Das Diskettenlaufwerk ist analog dazu beschaltet, also immer am Eingang die 150 Ohm. Manchmal sieht man auch eine Parallelschaltung von 220 und 330 Ohm, was ebenfalls ca. 150 Ohm ergibt.


    Der hohe Strom ist nötig, damit auf der doch 50-80cm langen Leitung (Flachkabel) keine Störungen auftreten.


    Ich wünsche Gutes Gelingen!


    PAW

  • 20201028_204650.jpg

    20201028_204743.jpg

    20201028_205316.jpg

    Sooo, musste meine "Indexfilter" Schaltung nochmal ein bisschen ändern. Nach dem Testaufbau haben sich natürlich noch ein paar Denkfehler bemerkbar gemacht... Das Ergebnis schaut jetzt mal gut aus.


    Wenn man nur den Indexpuls filtern will könnte man die Schaltung noch wesentlich vereinfachen. Ich wollte bei meinem Aufbau halt eine Schaltung mit der ich wahlweise das Index- oder das Sector1 Signal durchlasse.


    Um jetzt mit meinen Hardsektorierten Disketten zwecks Lesen/Schreiben weiterzuexperimentieren muss ich aber erst meinen Greaseweazle und Fluxengine zusammenbauen und...noch viel schlimmer, das Netzteil meines AES Lanier reparieren, bevor ich den Erfolg der weiteren Experimente überhaupt testen kann.

  • Habe nun auch meine Schaltung für den Index Puls mittels Arduino UNO zum Laufen gebracht.


    TEST-FLOPPY mit Arduino - Breadbord.JPG


    Dazu habe ich einen Arduino UNO verwendet, der an einem Laptop angeschlossen ist (wegen der Stromversorgung). Über das Flachkabel ist ein altes Standalone Floppylaufwerk (160KB Single Side, Single Track) angeschlossen. Dank eines Adapters von gpospi war dies problemlos möglich. Das Index-Signal (Pin #8 vom Floppykabel) ist an Eingangs-Pin #2 vom UNO angeschlossen. Am UNO läuft ein kleines Programm (siehe unten), das das gewünschte Signal rausfiltert.


    TEST-FLOPPY mit Arduino - Pulse.JPG


    Wie auf dem Scope ersichtlich, entspricht das Signal am Ausgabepin #4 vom UNO, dem von mister-freeze.


    Das neue Indexsignal wird (derzeit) nur bei Hardsektorierten Disketten erzeugt.


    Natürlich ist der Aufwand mit dem UNO größer, aber dafür lässt sich der Zeitpunkt des neuen Indeximpulses fast beliebig nach hinten verschieben (Einbau eines Delays im Programm). Dies würde es ermöglichen, den Startpunkt für das Aufzeichnen/Schreiben durch Fluxengine & CO. zu variieren.


    Einen Nachteil gibt es noch: Der Zeitpunkt des Ausgangssignales kann um ein paar Microsekunden variieren. Dies liegt an der Laufzeit des Programmes, das bei einem 16MHz Prozessor doch ein paar Microsekunden für die Schleife braucht.


    Falls das ein Problem darstellt, kann ja auch ein schnellerer Prozessor verwendet werden.


    Hier das Programm für den UNO:


    TEST-FLOPPY 002.ino.txt


    Hinweis zum Arduino UNO: die Digital-Ausgänge könne bis zu 40mA treiben. Daher können damit direkt die Floppyleitungen (die mit 150 Ohm abgschlossen sind) angesteuert werden. Bei Verwendung eines Iduino UNO (Billigvariante zu Arduino) geht das nicht mehr, da dieser nur 20mA kann. Da müssten extra Treiber verwendet werden.


    Ich wünsche Viel Erfolg beim Testen mit den Disketten!


    PAW

  • Hallo!

    Bei mir schlummert auch noch eine AES, natürlich ohne System-Disketten, seit über 15 Jahren.

    Um solche hartsectorierten u. andere abartige Disketten zu lesen und dann auch wieder schreiben zu können habe ich in der Vergangenheit sowohl

    einen Catweasel als auch einen Kryoflux Controller angeschafft. Vieles ist in der Tat bereits les u. schreibbar, bei hartsectorierten habe ich aber

    leider noch keinen Erfolg gehabt.


    Hallo!


    Das Schreibproblem bei hardsektorierten Disketten scheint bis Dato nicht gelöst zu sein.


    Ich habe in der Zwischenzeit ein paar Experimente bezüglich Diskettenlauf angestellt. Ich verwende dazu meine Philips P2500 Laufwerke (96tpi DD). Dabei hat sich bestätigt, dass das große Problem beim Schreiben (Kopieren) der (un)gleichmäßige Lauf der Drives ist.


    Bei den Soft-Sektor Disks ist der Gleichlauf kein Problem, da im Kontroller (z.B. µPD765) eine PLL (phased locked loop) läuft, die sich ständig an die Schwankungen anpasst. Daher ist es nicht relevant, wenn das Laufwerk (natürlich in relativ engen Grenzen) Unregelmäßigkeiten aufweist.


    Bei den Hardsektorierten ist die Sache anders. Hier gehe ich davon aus, das eine relativ simple Decoderlogik dahinter steckt, welche auf fixen Timings für die Datenzellen beruht. Dafür werden aber nur kurze Datensequenzen geschrieben/gelesen, nämlich maximal ein Hardsektor. Damit wirken sich Drehzahlschwankungen während einer Umdrehung nur zu einem Bruchteil aus.


    Die Ansätze, mit nur einem Indexloch zu arbeiten, ließen sich tatsächlich nur mit einem "idealen" Laufwerk, welches absolut keine Drehzahlschwankungen aufweist, realisieren. Die Praxis hat ja gezeigt, wie in vorangegangenen Threads berichtet, das Daten teilweise lesbar sind, aber nicht immer und zuverlässig. Die vorgeschlagene Lösung, so lange den Track zu schreiben, bis er passt, wäre natürlich eine Möglichkeit. Dies würde aber eine Software benötigen, die feststellen kann, ob die Daten zu den Löchern synchron sind und es kann unter Umständen lange dauern, bis sich der Zustand auch wirklich einstellt (und das pro Track)!


    Ich habe von Günther ein Kryoflux-Image erhalten, das ich näher analysiert habe. Im Gegensatz zu Softsektor-Disketten, welche nach dem Indexloch, etwa 2 Millisekunden Zeit lassen, bevor die Daten kommen (Sektorheader, etc.), ist die Zeit bei den einzelnen Hard-Sektoren wesentlich kürzer! Die Chance ein Sektorloch zu Verpassen ist damit sehr hoch.


    Wie schon von anderen bemerkt, ist die vermutlich einzige Lösung, Rücksicht auf die diversen Indexlöcher zu nehmen. Da Kryo und Co derzeit keine Möglichkeit dazu bieten, haben Günther ( gpospi) und ich beschlossen uns der Sache anzunehmen! Wir werden in Kürze den Projektstart "FLUXCOPY" bekannt geben.


    Alles in Allem ist keine wirklich schnelle Lösung des Problems in Sicht.

    Das ist richtig, wir hoffen aber, noch dieses Jahr eine Lösung für die Hardsektor AES-Disketten (16 Sektoren, FM) aufzeigen zu können.


    Grüße


    PAW

  • Es schon wieder eine Weile her das ich mich mit diesem Thema genauer auseinandergesetzt habe, doch meine ich eine Information über die letzte Version des Catweasel Controllers gefunden zu haben, nach der die Möglichkeit besteht, neben den Flusswechseln auch den Status des

    Indexsignals automatisch mit aufzunehmen.

    Es wurde ja auch Werbung für das neue Feature "Lesen von hartsektorierten Disketten" gemacht. Leider endet an dieser Stelle auch schon

    die Arbeit der Entwickler, denn Schreiben wird noch nicht unterstützt.

    Was die Theorie eines idealen Laufwerks angeht, sind die Floppy Emulatoren soetwas. Gotek bzw. HxC werben mit Unterstützung für

    hartsektorierte Images.


    Ich bin gespannt, wie es hier weitergeht.

  • Chuck Guzis hat scheinbar viel Zeit aufgewendet, um Disketten einer frühen AES/Lanier lesen zu können und dabei erstaunliche Absonderlichkeiten festgestellt. Z.B. MMFM bzw. M2FM Codierung, alle Sector Header sind absolut identisch, die Sektornummer steht mit im Datenfeld! Und als wäre das Alles nicht schon genug, ist die Bitabfolge in jedem Byte umgedreht, quasi rückwärts aufgezeichnet.

    Wie ich schon früher erwähnte, habe ich von gpospi ein Kryoflux-Image einer AES/Lanier-Diskette erhalten. Dabei konnte ich folgendes fest stellen: Die Disketten sind auf 96tpi-Laufwerken einseitig beschrieben, wobei nur jede 2. Spur verwendet wird. Das heißt die ungeraden Spuren sind leer. Die Modulation ist FM (kein M2FM). Alle Sektorheader beginnen mit dem gleichen Kennungsbyte. Im nächsten Byte steht die Tracknummer, gefolgt von Sektornummer (beginnend bei 1 bis 15, sowie 0 = 16). Tatsächlich sind die Bits in verkehrter Reihenfolge abgelegt. Die Zeichen sind im ASCII-Code gespeichert. Ein Datensektor ist ca. 150 Byte lang. Die genaue Länge konnte ich noch nicht eruieren. Dazu müsste man bestimmte Texte speichern, um zu sehen, bis zu welchem Zeichen die Daten in einem Sektor vorhanden sind. Ebenso konnte ich keine eventuelle CRC-Berechnung rausfinden.


    WICHTIGER HINWEIS: Wer seine Disketten mittels KRYOFLUX speichern möchte, darf auf keinen Fall die Sektorlöcher abdecken. Kryoflux zeichnet alle Indexpositionen auf. Diese können in Zukunft, sobald geeignete Software vorhanden ist, zum Schreiben benutzt werden.


    Bei Speichern empfehle ich auch trackweise zu speichern (nicht in einem gemeinsamen File). Der Grund dafür ist, dass ich eine Konvertierungssoftware von Kryoflux-RAW-Dateien auf mein eigenes Format "FLX" in Arbeit habe. Das FLX-Format dient dann als Basis für mein FLUXCOPY-Projekt.


    FLUXCOPY-Projekt zum Erstellen hardsektorierter AES-Disketten


    Weiters wird es ein kleines Dumpprogramm für AES-images (FLX-Format) geben, das den Inhalt der AES-Diskettenimages sektorweise lesbar macht.


    Weitere Aktivitäten in Bezug auf hardsektorierte Disketten werde ich im oben genannte Thread abhandeln.


    Falls jemand Interesse am Kopieren von anderen hardsektor Disketten (also keine AES-Lanier) hat, wäre es hilfreich Kryoflux-Images (ein File pro Track und Seite, wobei keine indexlöcher abgedeckt wurden) zu Analysezwecken bekommen. Außerdem wäre es hilfreich nähere Informationen zum Originalsystem, sowie zum System mit Kryoflux beizulegen (Disketten 5.25"/8", Anzahl Seiten, Anzahl Hardsektoren, Aufzeichnungsformat FM, MFM, etc., wenn bekannt, Aufzeichnungsgeschwindigkeit, Drehzahl der Laufwerke). Ganz wichtig wäre es Textdaten auf dem Image zu speichern und eventuell Screenshots der Texte vom Originalsystem beizulegen, damit ein Abgleich stattfinden kann. Sobald Das Projekt mit den AES-Disketten positiv abgeschlossen ist (wird noch eine längere Weile dauern), kann ich mich eventuell auch anderen Formaten widmen.


    Grüße


    PAW

  • Zum Einlesen von Hardsector-Disks eignen sich leider nicht alle 5.25" PC Laufwerke. Manche melden bei zu kurzen Intervallen der Index-Signale "No disk/drive not ready". Gute Erfahrungen habe ich mit Panasonic JU-475 Laufwerken gemacht.

  • AES-Lanier Diskette - Testdaten


    Hier ist ein Auszug der Testdiskette von gpospi


    AES Inhalt.JPG


    AES Inhalt Datei1.JPG



    AES Inhalt Datei2.JPG




    Aus nachfolgendem Bild ist die Sektorstruktur der AES-Diskette erkennbar. Hier wurden die Fluxwechselzeiten in "0" und "1" für jedes Bit umgerechnet.


    +++++ … Sektor Loch

    FM codiert, 8 Mikrosekunden pro Bit

    0 … 8 Mikrosekunden flux change

    1 … zwei 4 Mikrosekunden flux changes in Serie

    1+ … nur einen 4 Mikrosekunden flux change gefunden (gefolgt von einer 0), FEHLER

    diese falschen Pulsefolgen treten nur zwischen Indexlocj und Sektorheader auf


    Alle Bytes sind in verkehrter Bitreihenfolge zu lesen, d.h. niedrigstes Bit zuerst.



    AES Inhalt Datei binär.JPG


    In den nachfolgenden Dump-Daten sind die diversen Bildschirmtexte ersichtlich.

    Ein Inhaltsverzeichtnis konnte ich auf der Diskette nicht finden. Ein Sektor beinhaltet 151 Byte Nutzdaten. Am Ende befindet sich vermutlich noch eine Prüfsumme (CRC?) mit unbekanntem Algorithmus (bei Sektor 0 hier E1 08 siehe letzte Zeile von Sektor). Die Sektoren beginnen bei Sektor 1 bis 15, dann kommt Sektor 0 = 16. Die "+++" im Dump zeigen an, dass während dieses Sektors das Trackindex-Signal empfangen wurde. (Bei nachfolgenden Sektoren habe ich nur jene ausgewählt, die die Testdaten zeigen. Dazwischen waren noch weitere mit alten, gelöschten Daten.)


    Wenn man nach den langen Zeilen mit den 60 gleichen Buchstaben sucht, also z.B.: "aaaaa...", dann wird man diese nicht finden. AES komprimiert offenbar die Daten. Siehe z.B. Sektor 9. Hex 34 entspricht der Anzahl 60.


    Vielleicht findet jemand noch den Algorithmus für die Prüfsumme heraus. Mir ist es bis jetzt noch nicht gelungen.


    Grüße


    PAW

  • Algorithmus für die Prüfsumme der AES-Disketten herausgefunden.


    Es werden die Datenbytes, beginnend mit dem zweiten, in der Länge von 150 Bytes arithmetisch summiert. Die Summe wird auf 8 Bit reduziert (Modulo 256).


    Der Sektorheader wird also nicht berücksichtigt.


    Die Prüfsumme ist nur 8 Bit lang, obwohl in den Dumps oft 2 Bytes angezeigt werden. Beim Byte nach der Prüfumme handelt es sich vermutlich um Datenschrott, der dadurch entsteht, das nach Schreiben der Prüfsumme auf Lesen umgeschaltet wird. Das heißt der Schreibstrom bricht kurz nach der Prüfsumme ab und hinterläßt zufällige Impulse auf der Diskette.


    Grüße


    PAW

  • Nachtrag zu Prüfsumme der AES-Lanier-Disketten


    AES Prüfsumme.JPG


    Nachdem ich den Algorithmus in ein Prüfprogramm eingebaut hatte und über alle AES-Images laufen ließ, stellte ich fest, dass nicht alle Tracks fehlerfrei waren. Bei der Systemdisk waren 5 Tracks fehlerhaft, bei den Datendisks praktisch alle.


    Bei nährem Hinsehen konnte ich eine Regelmäßigkeit feststellen: die Fehler traten prinzipiell nur bei Sektor 8 und 16 (16 = 0) auf.


    Fazit: Besonderheit bei AES-Disketten ist, dass die Prüfsummen bei Sektor 8 und 16 nicht wie bei den anderen, ab dem 2. Datenbyte, sondern erst ab dem 20. Datenbyte berechnet werden!


    Jetzt stimmen alle Summen. Damit ist auch bewiesen, dass die, von gpospi mit Kryoflux erstellten, Diskimages fehlerfrei sind.


    Und wieder was dazugelernt.


    Grüße


    PAW