Dieses Teil ist zwar interessant, aber nicht vergleichbar mit dem HxC. Achtung, dies ist ein illusionszerstörender Beitrag.,.
Warum das so ist, dazu muss ich etwas ausholen. Und zwar hat das damit zu tun, wie Informationen auf Disketten und Festplatten geschrieben werden. Wie wir wissen, bestehen diese informationen - wie auch dieser Text - aus Nullen und Einsen. Dieser Text steht so wie er hier steht, als Nullen und Einsen ASCII (oder Unicode) kodiert im RAM. Wenn wir diese Information so unverändert nun auf ein magnetisches Speichermedium schreiben, werden wir sie mit großer Wahrscheinlichkeit nicht mehr lesen können, denn mechanische Speichermedien sind ungenau, Disketten drehen zwar mit 300 bzw. 360 U/min, aber was ist mit der Stelle nach dem Komma? Was ist bei schwergängigen schleifenden Disketten? Ist das dann noch syncron mit dem Takt des Rechners? Ohne Takt nicht. Doch dieser Text oder eine beliebige andere Information im Speicher eines Rechners, wenn man sie einfach bitweise auf das Medium schreibt, hat keinen Takt. Der Takt ist aber wichtig, denn er zeigt dem Rechner beim Lesen, wann ein Bit anfängt, und wann es wieder aufhört, das wird spätestens dann wichtig, wenn man mehrere Nullen oder mehrere Einsen hintereinander schreiben und wieder einlesen will. Wurden da jetzt 28 oder 29 Einsen hintereinander gelesen? Oder waren es 48 oder 49 Nullen, abhängig von den Drehzahlschwankungen der Floppy? Das sind zwei verschiedene Informationen.
Um sicher zu stellen, dass so etwas eben nicht passiert, hatte man schon in den frühen 70er Jahren die Idee, dem Datenstrom einen Takt mitzugeben, das heißt es wurde eine Frequenz auf den Datenbitstrom aufmoduliert, das nannte man Frequency Modulation (FM). Unser Atari und praktisch fast jeder andere moderne Computer verwenden heute (seit dem Ende der 1970er eingeführt) das "Modified Frequency Modulation" Verfahren, MFM, welches effizienter als FM ist.
(Der Commodore 64, genauer gesagt die Commodore Laufwerke VC-1540, 1541, 1570, 1571 und die großen CBM-Floppys einschl. der SFD1001, die alten 680x0 basierten Apple Macintoshs benutzen keine MFM-Codierung, sondern GCR (Group Code Recording), also eine andere Art, einen Takt in den Datenstrom zu mischen, es sei da das Data-Becker Floppy-Buch ans Herz gelegt. Optional kann auch der Commodore Amiga mit GCR umgehen, das meiste schreibt er aber auch in MFM, aber vom Sektorlayout völlig anders als der ST oder PC)
Jedenfalls wird also dem Datenstrom ein binäerer Takt aufmoduliert, was natürlich bedeutet, dass das Zeichen "a" (ASCI 97dez) nicht als Binärfolge "01100001" auf der Diskette landet, sondern mit einem Takt moduliert, was bedeutet, dass Binärfolgen nicht mehr aussehen wie vorher, zusätzliche Taktbits eingeschoben werden, usw. Nicht die Polarisierung der Elementarmagneten auf dem Datenträger stellt die Information "Null" oder "Eins" dar, sondern der Wechsel von Null nach Eins oder umgekehrt oder das Nicht vorhandensein eines Wechsels. Und das bedeuet auch, dass wenn man "aa" also binär "0110000101100001" auf die Diskette schreibt, dass da aber nicht zwei mal der selbe modulierte 8-Bit Datenstrom inklusive Takt auf der Diskette landet, sondern das sieht dann beim zweiten Byte wieder anders aus. Wichtig dabei ist, dass der Floppycontroller - der macht diese Codierung nämlich - das wieder einliest, und Takt von den Nutzdaten wieder trennt, und mit dem Takt syncron zum Speichermedium bleibt. Nur so ist ein sicherer Floppy- und Festplattenbetrieb (MFM-Platten!) gewährleistet. (RLL in der Megafile 30/60 ist übrigens nur eine Variante von MFM für höhere Datendichte)
Siehe
http://de.wikipedia.org/wiki/Modified_Frequency_Modulation http://de.wikipedia.org/wiki/Digitale_Frequenzmodulation oder Stepper/Brod "Scheibenkleister (I/II) - Massenspeicher am Atari ST" - ich meine in dem Buch wird auch GCR wie es die 1541 macht kurz erklärt, damit man den Unterschied sieht und weiß warum ein ST oder PC das niemals lesen können wird)
Das heißt, wer jetzt einfach ein *.ST bzw. *.MSA oder meinetwegen ein *.ADF (Amiga) Image auf den USB-Stick wirft, und meint, er könne das mit diesem Laufwerk am ST oder Falcon oder Amiga lesen, hat sich geschnitten. Leider. Denn diese Diskimages liegen in der Form vor, wie das Betriebssystem bzw. der Prozessor den Datenstrom sehen, nachdem der Floppycontroller den MFM-Datenstrom dekodiert hat. Dieser einfache Adapter muss (genau wie der HxC auch) einen Rohdatenstrom, also mit MFM-Codierung an den Floppycontroller liefern, bzw. bekommt ihn beim Schreiben von dort. Deswegen liegt dem HxC ein Konvertierungstool bei, welches die *.ST, *.MSA. *.ADF, *.... Diskimages spezifischer Rechner erstmal in ein Image in MFM-Rohformat umwandeln - welches dann übrigens etwa doppelt so groß wie das Ausgangsimage ist.
Vermutlich wird aber auch das Konvertierungstool vom HxC auf diesem Billigadapter nicht brauchbar sein, weil der Billigadapter die MFM-Rohdaten wahrscheinlich anders auf dem Stick ablegt, als der HxC. Und selbst wenn man auf dem ST/Falcon eine Diskette damit auf einen USB-Stick schreibt, und das dann versucht auf dem PC zu lesen, muss man auf dem PC erstmal wieder diesen MFM-Rohdatenstrom dekodieren, das wird auch sicherlich keinen Spaß machen... Man braucht am PC genau das selbe Lesegerät am Floppyanschluss, wie am Falcon, damit auch er das Diskimage lesen kann.
Hinzu kommt außerdem noch, soweit ich recherchiert und von anderen Leuten bestätigt bekommen habe, unterstützt dieser Floppyemulator nur den 16 MHz HD-Betrieb. 720 kB DD Disketten kann der nicht emulieren.
Für Indistriezwecke mag dieses Ding interessant sein, um 20 Jahre alte Steuerungsanlagen, medizinische Geräte usw. von störanfälligen Disketten zu befreien, ohne die Soft- und Hardware sonstwie zu modifizieren, für unsere Zwecke sind diese Billigdinger aber nur sehr eingeschränkt brauchbar. Das übrigens auch weil dem Teil kein Programm beiliegt, mit dem man am ST das aktuelle Diskimage wechseln kann. Das HxC bzw. sein USB-Server-Pendant sind da wesentlich interessanter.
Thema: Billig USB am Falcon (und andere Ataris) (Gelesen 35832 mal)