Ersatz von MFM-Platten, IDE-Controller für UN IBUS/QBUS
Andreas Holz
das Sterben von MFM-Platten ist ein nunmehr nicht nur leidiges, sondern
auch ein dringliches Thema. Ich habe nunmehr zwei Symbolics, die
aufgrund defekter MFM-Platten nicht mehr betriebsfähig sind.
Ein Weg wäre natürlich, sich bei ebay gegenseitig auf die Füße zu
treten, um MFM-Platten zu ersteigern, jedoch sind diese einerseits sehr
rar, andererseits wird sie auch das besagte Schicksal ereilen.
Sinnvoller wäre es nmE. eine BlackBox zu bauen, die MFM-Platten
emuliert. Es gibts zwar mindestens einen kommerziellen Anbieter, der
etwas derartiges für USD 995 anbietet, aber ich bin noch nicht soweit,
dieses Geld dafür zu investieren. Es ist ja immerhin nur ein
"Freizeitbeschäftigung", den Keller mit Schrott vollzustellen.
Also möchte ich hier einerseits hören, wer Interesse hat, weiterhin
feststellen, ob es hier Menschen gibt, die elektrotechnisch bewandert
sind und drittens darauf hinweisen, das derartige Themen in classiccomp
diskutiert werden. Dort sitzten offensichtlich auch Menschen, die von
der Technik Ahnung haben, weil sie offensichtlich früher in den
Hardwareschnieden wie bei DEC beschäftig waren. Beispielsweise wird
gegenwärtig über eine Unibus/QBus-Ide Controller diskutiert (was nmE.
nicht die optimale Lösung wäre, da es eben nur DEC-spezifisch wäre).
Nun scheint es nicht gerade trivial zu sein, eine MFM-Platte zu
emulieren, da offensichtlich der Datenstrom analog zum Controller
floß/fließt. D.h., es werden Leute mit elektrotechnischen Kenntnissen
benötigt. Daß jedoch derartiges realisiert werden kann, zeigt das o.g.
kommerzielle Angebot, andererseit die beiden bislang entwickelten
QBus-ATA Controller.
Gibt es in hier "Lauscher", die zuvor eine Beschäftigung bei
DEC/Compaq/Symbolics hatten? Oder wo tummeln sich diese herum?
Andreas
Christian Corti
> das Sterben von MFM-Platten ist ein nunmehr nicht nur leidiges, sondern
> auch ein dringliches Thema. Ich habe nunmehr zwei Symbolics, die
> aufgrund defekter MFM-Platten nicht mehr betriebsfähig sind.
Normalerweise muß man MFM-Platten alle paar Jahre neu
lowlevel-formatieren. Das ist bei den Symbolics aber praktisch
unmöglich. Defekt sind sie vermutlich weniger, wenn Du sie nicht mehr
brauchts, würde ich sie Dir dann abnehmen :-)
Christian
Andreas Holz
> Andreas Holz <ash...@topinform.com> wrote:
>
>>das Sterben von MFM-Platten ist ein nunmehr nicht nur leidiges, sondern
>>auch ein dringliches Thema. Ich habe nunmehr zwei Symbolics, die
>>aufgrund defekter MFM-Platten nicht mehr betriebsfähig sind.
>
>
> Normalerweise muß man MFM-Platten alle paar Jahre neu
> lowlevel-formatieren. Das ist bei den Symbolics aber praktisch
Es sei denn, man hätte die IFS-Tapes.
> unmöglich. Defekt sind sie vermutlich weniger, wenn Du sie nicht mehr
> brauchts, würde ich sie Dir dann abnehmen :-)
Das würde vereinfacht bedeuten, sie verlören nur ihre
Formatierungsinformationen?
Ich habe jedoch weitere Effekte beobachten können bzw. davon gehört.
Beispielsweise löst sich die magnetisierbare Beschichtung der
Plattenoberfläche. Sie schuppt regelrecht ab.
>
> Christian
Gereon Wenzel
>
> Hallo,
>
...
> Nun scheint es nicht gerade trivial zu sein, eine MFM-Platte zu
> emulieren, da offensichtlich der Datenstrom analog zum Controller
> floß/fließt. D.h., es werden Leute mit elektrotechnischen Kenntnissen
> benötigt. Daß jedoch derartiges realisiert werden kann, zeigt das o.g.
> kommerzielle Angebot, andererseit die beiden bislang entwickelten
> QBus-ATA Controller.
Das Problem liegt vermutlich darin, das MFM ein denkbar dummes Interface
ist,
man muesste somit den angeschlossenen Platten jedwede Intelligenz
amputieren.
Der Umsetzer muesste dann fuer den Controller einzeln adressierbare
Spuren, Koepfe und Sektoren haben.
Einen kompletten Controller zu konstruieren ist vermutlich langfristig
die bessere Variante, da das Bus Interface der meisten Maschinen ja
halbwegs bekannt oder zumindest dokumentiert ist?
Natuerlich ist das dann nicht so universell verwendbar.
Irgendwas in der Art des DPT 2012B waere vielleicht denkbar?
Dieser SCSI-Controller erscheint dem Rechner gegenueber als WD-1003 und
ist wohl auch ziemlich Registerkompatibel?
Somit ist der Betrieb mit jedem OS moeglich
das den WD-1003 unterstuetzt.
Allerdings sollte man bei LINUX daran denken,
das der Kernel nicht nach IDE Platten sucht.
Der findet dann die WD-1003 Emulation und das EATA-Modul laesst sich
nicht mehr laden.
Bei der Groesse der damaligen MFM Platten waere auch die Realisierung in
Flash Technologie zu ueberlegen?
Gereon Wenzel
Christian Corti
> Es sei denn, man hätte die IFS-Tapes.
So isses. Das war ein Grund, warum Symbolics bei mir sehr schnell
unbeliebt wurde.
> Das würde vereinfacht bedeuten, sie verlören nur ihre
> Formatierungsinformationen?
Ja, das ist mir mit einigen Platten so gegangen. Fünf Jahre laufen sie
prima, doch dann mehren sich Datendefekte bzw. schlechte Sektoren. Ein
LL-Format hat dann alles wieder für einige Jahre kuriert. Am liebsten
mit Norton Calibrate, dann muß man nicht einmal ein Backup
wiedereinspielen.
> Ich habe jedoch weitere Effekte beobachten können bzw. davon gehört.
> Beispielsweise löst sich die magnetisierbare Beschichtung der
> Plattenoberfläche. Sie schuppt regelrecht ab.
Man tut Platten auch nicht in die Mikrowelle wie CDs ;-) Ehrlich gesagt
halte ich das für ein dummes Gerücht, vor allem bei alten Platten. Die
Beschichtung besteht auch nicht aus feuchtigkeitsempfindlicher
zersetzungsgefährdeter Zinkschicht wie bei Teleklumpen-Europa-Röhren, wo
der Glaskolben plötzlich ganz nackt dasteht, wenn man niesen muß...
Christian
Michael Baeuerle
>
> [MFM Sterben]
> Also möchte ich hier einerseits hören, wer Interesse hat, weiterhin
> feststellen, ob es hier Menschen gibt, die elektrotechnisch bewandert
> sind und drittens darauf hinweisen, das derartige Themen in classiccomp
> diskutiert werden. Dort sitzten offensichtlich auch Menschen, die von
> der Technik Ahnung haben, weil sie offensichtlich früher in den
> Hardwareschnieden wie bei DEC beschäftig waren. Beispielsweise wird
> gegenwärtig über eine Unibus/QBus-Ide Controller diskutiert (was nmE.
> nicht die optimale Lösung wäre, da es eben nur DEC-spezifisch wäre).
Ich brauche es zwar nicht, aber es wuerde mich reizen sowas zu bauen ...
z.B. ein SCSI HA der wie eine bzw. mehrere ST-506 Platte(n) angesprochen
wird.
> Nun scheint es nicht gerade trivial zu sein, eine MFM-Platte zu
> emulieren,
Trivial ganz sicher nicht, aber sonst waere es ja langweilig ;-)
> da offensichtlich der Datenstrom analog zum Controller
> floß/fließt. D.h., es werden Leute mit elektrotechnischen Kenntnissen
> benötigt.
Ich koennte mir folgendes vorstellen (Prinzip):
1)
MFM Platten haben ja immer 17 sectors/track und 3600RPM. Der Aufbau
aller Tracks und die Bitrate der Koepfe ist also prinzipiell immer
gleich, egal wieviele Zylinder und Koepfe die (virtuelle) Platte hat.
Das macht die Sache schonmal uebersichtlich.
2)
Der Emulator muesste ein etwa 10KiByte grosses Track Image in seinem RAM
verwalten das wohl etwa so aussehen muss wie das in:
http://cma.zdnet.com/book/upgraderepair/ch14/ch14.htm#Heading12
Table 14.5 abgebildete. Fuer den Lesemodus muesste er dieses dann z.B.
mit konstanter Symbolrate kontinuierlich ringfoermig ausgeben. Wenn die
Codierung stimmt sollte der Controller im Host aus diesem Datenstrom die
Nutz- und LL Format Daten herausfiltern können.
3)
Bei einem SeekRequest des Controllers im Host muesste dann zuerst der
reale Plattenzugriff erfolgen um die Nutzdaten des neuen Tracks zu
holen. Dann muesste daraus das Track Image erstellt werden und erst wenn
dieses fertig ist ein SeekComplete an den Controller gesendet werden.
Die so entstehende virtuelle Platte könnte also problemlos jeden
beliebigen Interleave (also auch die maximale Datenrate) emulieren,
haette aber wohl eine eher bescheidene Seek time.
4)
Die Koepfe sind nicht direkt an das Datenkabel angeschlossen sondern es
wird von der Platte automatisch immer der selektierte Kopf auf RD+/RD-
und WD+/WD- des Datenkables gelegt. Da es seperate Schreib und
Leseleitungen gibt, sind offenbar freundlicherweise auch noch Verstärker
getrennt fuer schreiben und lesen auf der Platte integriert.
Also ich halte es fuer machbar, die Performance duerfte einen aber nicht
vom Hocker reissen - tut sie beim Original aber auch nicht ...
> Daß jedoch derartiges realisiert werden kann, zeigt das o.g.
> kommerzielle Angebot, andererseit die beiden bislang entwickelten
> QBus-ATA Controller.
Ein ATA controller fuer einen beliebigen (alten) Bus sollte *deutlich*
leichter zu bauen sein als ein ST-506 Emulator.
Micha
--
[...] Nach der heutigen Rechtslage - oder muss ich sagen nach der
Rechtslage von letzter Woche?
Prof. Hans-Werner Sinn auf n-tv
Hoffmann-Vetter, Martin
> Der Emulator muesste ein etwa 10KiByte grosses Track Image in seinem
> RAM
> verwalten das wohl etwa so aussehen muss wie das in:
> http://cma.zdnet.com/book/upgraderepair/ch14/ch14.htm#Heading12
> Table 14.5 abgebildete. Fuer den Lesemodus muesste er dieses dann z.B.
> mit konstanter Symbolrate kontinuierlich ringfoermig ausgeben. Wenn
> die
> Codierung stimmt sollte der Controller im Host aus diesem Datenstrom
> die
> Nutz- und LL Format Daten herausfiltern können.
>
Da es leider verschiedene Aufzeichnungsformate gibt, die bei ST-506 noch
nicht ins Spiel kommen (MFM, RLL, ...) sollte man hier keine Bits oder
Bytes speichern, sondern nur Zeiten. Bei den Platten ist genormt, daß es
immer einen Wechsel des Magnetismus geben muß. Dieser muß innerhalb von
bestimmten Zeiten passieren. Es gibt eine min. und eine max. Zeit. Diese
Zeiten sollte man in den Speicher packen. Hier müßte man mal anhand der
Min.- und Max.-Zeiten hochrechnen, welchen Speicher man benötigt. Auch
die Grundzeiteinheit müßte man hier noch definieren sowie den
Magnetierungsrichtungsanfang.
Das ganze kann ich mir auch mit einem uC mit viel Flash-Speicher
vorstellen.
Gruß Martin
Ralf Kiefer
> MFM Platten haben ja immer 17 sectors/track und 3600RPM.
Nein, IMHO korrekt.
Ich habe hier am VMEbus-Rechner (bzw. VME-ähnlichem) einen
WD1002-Controller, der nahezu jedes beliebige Format zuläßt, was auch so
teilweise ausgenutzt wurde. OS-9/68k nutzt typischerweise
256Byte/Sektor. Auch andere auf dieser Hardware-Architektur aufbauende
BSe (UCSD, Eumel, C/PM 68k) hatten da "lustige"[tm]
Implementierungen[1].
> Also ich halte es fuer machbar, die Performance duerfte einen aber nicht
> vom Hocker reissen - tut sie beim Original aber auch nicht ...
Das theoretische Maximum ist recht einfach zu bestimmen:
3600/min = 60/sec
Also 60 * 32 * 256 Byte/sec = 480kB/sec.
Am doMeSDOS-PC der damaligen Zeit waren das dann
60 * 17 * 512 Byte/sec = 510 kB/sec
und später mit RLL AFAIR rund 50% mehr.
Gruß, Ralf
[1] Am integrierten Disketten-Controller gab es real genutzte Formate
wie z.B: äußerer Zylinder mit Single Density und 10 Sektoren je 256Byte,
alle anderen in Double Density mit 16 Sektoren je 256Byte. Dies war ein
Standard-Format vom OS-9/68k noch zu V2.1-Zeiten.
--
.. und sonst: R . K i e f e r . S P A M (at) g m x . d e
Ralf Kiefer
> Ich habe jedoch weitere Effekte beobachten können bzw. davon gehört.
> Beispielsweise löst sich die magnetisierbare Beschichtung der
> Plattenoberfläche. Sie schuppt regelrecht ab.
Das kann ich bestätigen: ich habe hier mehrere gestorbene
Rodime-Platten, bei denen der Kopf spanabhebend gelesen oder geschrieben
hat, also ein typischer Tod damaliger Platten (5,25", volle Bauhöhe,
Kapazitäten 5MB - 20MB), beispielsweise wenn sie transportiert wurden,
ohne daß die Köpfe "manuell" in der Landezone geparkt wurden.
Gruß, Ralf
Patrick Schaefer
> MFM Platten haben ja immer 17 sectors/track und 3600RPM. Der Aufbau
> aller Tracks und die Bitrate der Koepfe ist also prinzipiell immer
> gleich, egal wieviele Zylinder und Koepfe die (virtuelle) Platte hat.
Denkste. "MFM"-Platten haben eine Magnetspur (aus mehreren Heads und
Cylindern ausgewählt), ein Kabel, mit dem man den Schreibstrom ein- und
ausschalten kann und ein Kabel, aus dem für jeden Flußwechel ein Puls
rauskommt. Alles andere, d.h. auch Datenrate und Format hängt komplett
vom Controller ab.
Deine Feststellung gilt für IBM PC-MFM-Controller, z.B. den WD-1003. Mit
IBM PC-RLL-Controllern sind es 26 Sektoren pro Spur. Mit einer Apple
ProFile-Platine 16 Sektoren im GCR-Format. Du kannst auch RS232
draufschreiben, oder Morsezeichen. Der Plattenhersteller gibt nur einen
Mindest- und einen Maximalabstand zwischen den Magnetflußwechseln vor.
Dein Emulator muß also das Hostformat kennen, bzw. Du mußt Dich auf das
Emulieren des PC-MFM-Protokolls beschränken.
Patrick
Michael Baeuerle
>
> Hallo,
>
> > Der Emulator muesste ein etwa 10KiByte grosses Track Image in seinem
> > RAM verwalten das wohl etwa so aussehen muss wie das in:
> > http://cma.zdnet.com/book/upgraderepair/ch14/ch14.htm#Heading12
> > Table 14.5 abgebildete. Fuer den Lesemodus muesste er dieses dann z.B.
> > mit konstanter Symbolrate kontinuierlich ringfoermig ausgeben. Wenn
> > die Codierung stimmt sollte der Controller im Host aus diesem Datenstrom
> > die Nutz- und LL Format Daten herausfiltern können.
>
> Da es leider verschiedene Aufzeichnungsformate gibt, die bei ST-506 noch
> nicht ins Spiel kommen (MFM, RLL, ...) sollte man hier keine Bits oder
Das ist natuerlich ein Argument. Mein Hintergedanke war das LL-Format
nicht mitzuspeichern sondern immer on-the-fly neu zu erzeugen - das
wuerde die Sache IMHO stark vereinfachen und deutlich zuverlaessiger
machen. Man hat sonst evtl. das Problem, dass das LL-Format mit der Zeit
zerschossen wird (gab es ja auch bei realen Platten).
Dieser Ansatz taugt natuerlich nur fuer eine ueberschaubare Anzahl von
Formaten. Ich war eigentlich der Meinung, dass man bei Platten in der
Vergangenheit nicht so heftige Sachen gemacht hat wie bei Disketten ...
bin wohl zu spaet geboren worden ;-)
> Diese
> Zeiten sollte man in den Speicher packen. Hier müßte man mal anhand der
> Min.- und Max.-Zeiten hochrechnen, welchen Speicher man benötigt.
Das mit den Zeiten gefaellt mir nicht. Ist softwaretechnisch IMHO
schwerer zu handlen und braucht mehr Rechenpower. Man kann doch trotzdem
eine Bitmap nehmen - in deinem Fall eben eine Ebene tiefer z.B. mit
einer 1 fuer "Flusswechsel" und einer 0 fuer "keinen Flusswechsel".
Folgende Track image Daten mit 3Bit/Zelle bzw. 6Bit/Nutzdatenbit
(Abstaende als Anhaltspunkt fuer die Nutzdaten):
000010 000010 000000 010000 010000 000010
wuerden als MFM dekodiert dann z.B.:
110001
ergeben. Verrutscht ein Schreibzugriff bei diesem System um eine Stelle,
kann dies noch per Software korrigiert werden (weil er die jeweilige
Zelle noch "getroffen" hat). Der Speicherbedarf fuer das Track image
wuerde um Faktor 6 steigen (also in die Region 64KiByte) was immer noch
handlebar waere ... fuer die zu speichernden Daten um Faktor 2 (bei
MFM).
> Auch
> die Grundzeiteinheit müßte man hier noch definieren sowie den
> Magnetierungsrichtungsanfang.
Die Richtung ist IIRC uninteressant, es zählt nur "Aenderung" oder
"keine Aenderung" (so wie beim BMC code).
> Das ganze kann ich mir auch mit einem uC mit viel Flash-Speicher
> vorstellen.
Was nutzt dir das Flash? Fuer das Track image taugt es nicht wegen
Geschwindigkeit und Lebensdauer. Fuer die Nutzdaten wird es immer zu
wenig sein ...
Hoffmann-Vetter, Martin
> Das ist natuerlich ein Argument. Mein Hintergedanke war das LL-Format
> nicht mitzuspeichern sondern immer on-the-fly neu zu erzeugen - das
> wuerde die Sache IMHO stark vereinfachen und deutlich zuverlaessiger
> machen.
>
Das LL-Format ist aber nicht immer genau definiert gewesen. Ich kann
mich an Harddisk-Controller erinnern, die offensichtlich verschiedene
Signale zur ST-506 Platte schickten und infolgedessen aus erwarteten.
Dies soll heißen, daß wenn ich mit Controller A eine Platte beschrieben
habe, ich diese mit Controller B nicht unbedingt lesen kann. Nach einem
neuen LL-Format klappt es dann.
> Man hat sonst evtl. das Problem, dass das LL-Format mit der Zeit
> zerschossen wird (gab es ja auch bei realen Platten).
Der beste Emulator würde soetwas eben mitemulieren!
> Ich war eigentlich der Meinung, dass man bei Platten in der
> Vergangenheit nicht so heftige Sachen gemacht hat wie bei Disketten
> ...
Man konnte viel mehr machen, da eine Platten nicht herausgenommen
wurden. Daher mußte die Austauschbarkeit, wie sie bei Disketten wichtig
ist, nicht berücksichtigt werden.
> Das mit den Zeiten gefaellt mir nicht. Ist softwaretechnisch IMHO
> schwerer zu handlen und braucht mehr Rechenpower.
Dies könnte man evtl. durch einen Timer mit Fifo als Hardware ersetzen.
> Man kann doch trotzdem
> eine Bitmap nehmen - in deinem Fall eben eine Ebene tiefer z.B. mit
> einer 1 fuer "Flusswechsel" und einer 0 fuer "keinen Flusswechsel".
> Folgende Track image Daten mit 3Bit/Zelle bzw. 6Bit/Nutzdatenbit
> (Abstaende als Anhaltspunkt fuer die Nutzdaten):
>
> 000010 000010 000000 010000 010000 000010
>
Damit machst Du aber eine Rasterung. Die "digitalisierst" das Signal.
Leider weiß ich inzischen schon gar nicht mehr, ob die Datenübertragung
bei der ST-506 zwischen Controller und Platte synchron oder asynchron
ist. Wenn's syncron ist, dann könnte es gehen. Wenn Asynchron, müßtest
Du das Shannon-Prinzip anwenden (Abtastfrequenz ist doppelt so hoch wie
die max. Nutzfrequenz). Könnte aber weitere Fehler mit sich bringen, die
zu elemenieren sind.
> Der Speicherbedarf fuer das Track image
> wuerde um Faktor 6 steigen (also in die Region 64KiByte) was immer
> noch
> handlebar waere ... fuer die zu speichernden Daten um Faktor 2 (bei
> MFM).
Man wäre hier zumindest "LL-Format"-unabhängig!
> > Das ganze kann ich mir auch mit einem uC mit viel Flash-Speicher
> > vorstellen.
>
> Was nutzt dir das Flash? Fuer das Track image taugt es nicht wegen
> Geschwindigkeit und Lebensdauer. Fuer die Nutzdaten wird es immer zu
> wenig sein ...
War nur ein Beispiel. Und meistens sind es "kleine" Platten, die als
ST-506 existieren. Daher dachte ich eben an eine Emulation in Richtung
eines DOM (Disk-On-Module).
Gruß Martin
Andreas Holz
Ich würde mich bei entsprechendem Interesse bereiterklären, ein Excerpt
hinsichllich der Technologie und Unsetzungsvorschläge aus den
Diskussionebeiträgen der classiccmp zu erstellen, so daß wir hier das
Rad nicht vollständig neu erfinden müßten.
Gibt es hier Menschen, die Erfahrung in der Programmierung von FPGAs
bzw. auch Zugriff auf ein Entwicklungsystem beispielsweise von Xilinx
oder Atmel haben?
Andreas
Michael Baeuerle
>
> Michael Baeuerle schrieb:
>
> > MFM Platten haben ja immer 17 sectors/track und 3600RPM. Der Aufbau
> > aller Tracks und die Bitrate der Koepfe ist also prinzipiell immer
> > gleich, egal wieviele Zylinder und Koepfe die (virtuelle) Platte hat.
>
> Denkste. "MFM"-Platten haben eine Magnetspur (aus mehreren Heads und
> Cylindern ausgewählt), ein Kabel, mit dem man den Schreibstrom ein- und
> ausschalten kann und ein Kabel, aus dem für jeden Flußwechel ein Puls
> rauskommt.
Ja und noch eines wo man die Daten zum Schreiben reinlaesst, eigentlich
sogar jeweils zwei.
> Alles andere, d.h. auch Datenrate und Format hängt komplett
> vom Controller ab.
>
> Deine Feststellung gilt für IBM PC-MFM-Controller, z.B. den WD-1003. Mit
> IBM PC-RLL-Controllern sind es 26 Sektoren pro Spur. Mit einer Apple
> ProFile-Platine 16 Sektoren im GCR-Format. Du kannst auch RS232
> draufschreiben, oder Morsezeichen. Der Plattenhersteller gibt nur einen
> Mindest- und einen Maximalabstand zwischen den Magnetflußwechseln vor.
Aber RLL und GCR ist nicht MFM ;-)
Sorry dass ich mich so undeutlich ausgedrueckt habe, ich hatte MFM mit
512Byte/Sektor im Hinterkopf. Das Prinzip wuerde aber auch mit jedem
anderen Format funktionieren ...
> Dein Emulator muß also das Hostformat kennen, bzw. Du mußt Dich auf das
> Emulieren des PC-MFM-Protokolls beschränken.
Eben. Der Gedanke war ja gerade, das LL Format eines oder mehrerer
gaengiger Controller zu emulieren (mein Irrtum war offenbar anzunehmen,
dass es da nicht sooo viele gegeben hat) und *nicht* vom jeweiligen
Controller aufzeichnen zu lassen. Vorraussetzung dass das nicht zu
kompliziert wird ist eigentlich nicht mal so sehr die Sektorgroesse - da
koennte man auch mehrere unterstuetzen - sondern hauptsaechlich dass
alle Tracks gleiches Layout haben. Also kein ZBR und nicht so einen
wilden Aufbau wie bei der Diskette die aussen eine andere Codierung
verwendet wie innen ...
Das emulierte Gebilde verhaelt sich dann natuerlich nicht wie eine echte
Platte (kann z.B. nicht LL formatiert werden) und ist damit nicht so
flexibel einsetzbar. Es waere technisch aber IMHO sehr viel einfacher zu
bauen als eine echte analoge Emulation von Medium+Kopf. Auch wuerden die
zu speichernden Nutzdaten nicht um Faktor 10 oder mehr aufgeblaeht ...
viel umrechnen bzw. komprimieren kann man vermutlich nicht, da das ganze
zumindest beim Schreiben ja schnell sein muss:
Beim Lesen kann man den virtuellen SeekComplete verzögern um Zeit zu
schinden, beim Schreiben mit Verify will der Controller aber sofort bei
der naechsten Umdrehung "sehen" was er gerade geschrieben hat ...
Michael Baeuerle
>
> [LL Format]
> > Man hat sonst evtl. das Problem, dass das LL-Format mit der Zeit
> > zerschossen wird (gab es ja auch bei realen Platten).
>
> Der beste Emulator würde soetwas eben mitemulieren!
Aber dafuer Ressourcen benötigen, die diejenige eines der emulierten
Platte wuerdigen Hosts *bei weitem* in den Schatten stellt ;-)
> [...]
> > Man kann doch trotzdem
> > eine Bitmap nehmen - in deinem Fall eben eine Ebene tiefer z.B. mit
> > einer 1 fuer "Flusswechsel" und einer 0 fuer "keinen Flusswechsel".
> > Folgende Track image Daten mit 3Bit/Zelle bzw. 6Bit/Nutzdatenbit
> > (Abstaende als Anhaltspunkt fuer die Nutzdaten):
> >
> > 000010 000010 000000 010000 010000 000010
>
> Damit machst Du aber eine Rasterung. Die "digitalisierst" das Signal.
Analog speichern kann ich es ja wohl schlecht - ich versuche halt mit
möglichst geringer Aufloesung zu samplen. Natuerlich kann man da auch
anders rangehen (Pi x Daumen):
17Sektoren(pro Track) x 570Byte(pro Sektor) x 8Bit(pro Byte) x
2Flusswechsel(pro Bit) = 155040Flusswechsel(pro Track)
Das ergibt 9302400Flusswechsel(pro Sekunde bei 3600RPM).
Um die analoge Signalform des Kopfes "schoen" abzubilden sample ich dann
mit 8Bit Quantisierung und 8Samples pro (potentiellem) Flusswechsel ...
also mit 8Bit@74MHz. Meine Speicherbandbreite muss also schonmal
>71MiByte/s sein, damit mir die Puffer in der CPU nicht ueberlaufen. Da das Lesesignal des Kopfes aber nicht so aussieht wie das, das man beim Schreiben angelegt hat, muss auch noch ein Digitalfilter (und ggf. ein DSP dafuer) dazwischen.
Bei einer "Umdrehung" der virtuellen Platte fallen dann 1.2MiByte Daten
aus dem A/D Wandler - diese enthalten aber gerade mal 17 x 512 =
8.5KiByte fuer den Host nutzbare Daten. Die Effizienz waere also
grottenschlecht: Um eine 80MiByte MFM-Platte zu emulieren muesste man
etwa 12GiByte Speicherplatz vorsehen ...
Wir wollen aber IMHO etwas billigeres haben das man vielleicht sogar
selber zusammenloeten kann - keine BGAs mit hunderten von Pins, kein PCI
und keinen Pentium ... sonst kann man besser gleich das kommerzielle
Teil kaufen.
Eine perfekte Emulation die mit jedem Controller und jedem Format
zurechtkommt ist mit unseren Mitteln unrealistisch (IMHO). Irgendwo muss
man Kompromisse machen - jedenfalls bei ST-506. Wie sieht es denn mit
ESDI aus (da waere es wohl einfacher)? Wie verbreitet war das, wuerde
das auch jemand was bringen?
> Leider weiß ich inzischen schon gar nicht mehr, ob die Datenübertragung
> bei der ST-506 zwischen Controller und Platte synchron oder asynchron
> ist. Wenn's syncron ist, dann könnte es gehen.
Das Analogsignal ist prinzipiell asyncron. Einen Bezugstakt gibt es
nicht (von der Indexmarke mal abgesehen).
> Wenn Asynchron, müßtest
> Du das Shannon-Prinzip anwenden (Abtastfrequenz ist doppelt so hoch wie
> die max. Nutzfrequenz). Könnte aber weitere Fehler mit sich bringen, die
> zu elemenieren sind.
Das wird nach diesem Prinzip zu heftig und zu teuer, s.o.
Hoffmann-Vetter, Martin
>
> Aber dafuer Ressourcen benötigen, die diejenige eines der emulierten
> Platte wuerdigen Hosts *bei weitem* in den Schatten stellt ;-)
>
durch das Konzept mit abgedeckt wird, würde ich's gut finden.
> > Damit machst Du aber eine Rasterung. Die "digitalisierst" das
> Signal.
>
> Analog speichern kann ich es ja wohl schlecht
>
Leider!
> ich versuche halt mit
> möglichst geringer Aufloesung zu samplen.
>
Und genau das, vermute ich, könnte zum Problem werden. Klar, man möchte
die Datenmenge möglichst klein halten.
> 17Sektoren(pro Track) x 570Byte(pro Sektor) x 8Bit(pro Byte) x
> 2Flusswechsel(pro Bit) = 155040Flusswechsel(pro Track)
>
Ich würde hier weniger das LL-Format ansetzen, als mal einige
Datenblätter von Platten einsehen. Patrick hat hier sehr richtig den
Einwand der minimalen und maximalen Zeiten zwischen zwei Flusswechseln
angesprochen. Die Frage wäre, wie groß ist die durchschnittliche (über
die Platten verschiedener Hersteller) minimale Zeit?
> Das ergibt 9302400Flusswechsel(pro Sekunde bei 3600RPM).
>
Wobei sich das "Muster" 3600 mal in der Sekunde wiederholt.
> Um die analoge Signalform des Kopfes "schoen" abzubilden sample ich
> dann
> mit 8Bit Quantisierung und 8Samples pro (potentiellem) Flusswechsel
> ...
> also mit 8Bit@74MHz.
>
Ich denke, auf der ST-506 Schnittstelle ist ein RS-422 Treiber für den
Datenstrom. Damit reicht also 1-Bit.
> Meine Speicherbandbreite muss also schonmal
> >71MiByte/s sein, damit mir die Puffer in der CPU nicht ueberlaufen.
> Da das Lesesignal des Kopfes aber nicht so aussieht wie das, das man
> beim Schreiben angelegt hat, muss auch noch ein Digitalfilter (und
> ggf. ein DSP dafuer) dazwischen.
>
Da nun die Daten nicht mehr von einem Lesekopf kommen, könnte man den
DSP einsparen, oder?
> Bei einer "Umdrehung" der virtuellen Platte fallen dann 1.2MiByte
> Daten
> aus dem A/D Wandler - diese enthalten aber gerade mal 17 x 512 =
> 8.5KiByte fuer den Host nutzbare Daten.
>
Durch die Reduzierung auf 1 Bit wären es dann 150KiByte.
Und da hier bestimmt viele 0 oder 1 aufeinander folgen, könnte man
einiges an Speicherplatz durch ein geeignetes Verfahren sparen. Daher
mein Vorschlag mit den Zeiten. Wäre also nicht anderes, als eine Tabelle
mit der Anzahl der 0 bzw. 1. Da eine maximale Zeit zwischen den
Flußwechseln exitiert, kann auch kein Überlauf passieren. Bzw. kann
dieser gleich als "Error" für den Controller gewertet werden!
> Die Effizienz waere also
> grottenschlecht: Um eine 80MiByte MFM-Platte zu emulieren muesste man
> etwa 12GiByte Speicherplatz vorsehen ...
>
Nach deiner Rechnung schon. Leider fehlern mir für meine Rechnung
immernoch die min. und max.-Zeiten. Hilfe, kennt hier jemand diese
Zeiten? Patrick?
> Wir wollen aber IMHO etwas billigeres haben das man vielleicht sogar
> selber zusammenloeten kann - keine BGAs mit hunderten von Pins, kein
> PCI
> und keinen Pentium ...
>
Das ist richtig. Nur so würde es Sinn machen.
> > Leider weiß ich inzischen schon gar nicht mehr, ob die
> Datenübertragung
> > bei der ST-506 zwischen Controller und Platte synchron oder
> asynchron
> > ist. Wenn's syncron ist, dann könnte es gehen.
>
> Das Analogsignal ist prinzipiell asyncron. Einen Bezugstakt gibt es
> nicht (von der Indexmarke mal abgesehen).
>
Womit also mein beschriebens Problem mit den verschiedenen Controllern
erkärt wäre, und was für ein so hohe Abtastrate sprechen würde, damit
dies auch universell einsetzbar wäre. Alles andere wäre eine sehr
spezielle Lösung, die den Aufwand vermutlich gar nicht rechtfertigt!
> > Wenn Asynchron, müßtest
> > Du das Shannon-Prinzip anwenden (Abtastfrequenz ist doppelt so hoch
> wie
> > die max. Nutzfrequenz). Könnte aber weitere Fehler mit sich bringen,
> die
> > zu elemenieren sind.
>
> Das wird nach diesem Prinzip zu heftig und zu teuer, s.o.
>
Ich befürchte, Du wirst dieses Prinzip nicht umgehen können! Leider...
Gruß Martin
Michael Baeuerle
>
> > Das ergibt 9302400Flusswechsel(pro Sekunde bei 3600RPM).
> >
> Wobei sich das "Muster" 3600 mal in der Sekunde wiederholt.
Nicht wenn die virtuelle Platte gerade etwas sequentielles zu tun hat.
Bei einem Interleave von 1:1 gibt es dann bei jeder "Umdrehung" ein
komplett anderes Muster ... jedenfalls innerhalb eines Zylinders bei
korrektem Track-Skew.
> > [8Bit@74MHz]
> >
> Ich denke, auf der ST-506 Schnittstelle ist ein RS-422 Treiber für den
> Datenstrom. Damit reicht also 1-Bit.
Wenn es wirklich RS-422 ist: Ack.
> > Meine Speicherbandbreite muss also schonmal
> > >71MiByte/s sein, damit mir die Puffer in der CPU nicht ueberlaufen.
> > Da das Lesesignal des Kopfes aber nicht so aussieht wie das, das man
> > beim Schreiben angelegt hat, muss auch noch ein Digitalfilter (und
> > ggf. ein DSP dafuer) dazwischen.
> >
> Da nun die Daten nicht mehr von einem Lesekopf kommen, könnte man den
> DSP einsparen, oder?
Nur wenn auf der Platte ausser einem Verstaerker und dem RS-422 Treiber
noch mehr drauf ist.
Das Schreibsignal am Kopf [hier fuer 4 MFM Bits (1100)] muesste so
aussehen:
- --- - - ---
| | |
--- - - --- --- -
und wuerde beim Lesen dann aber etwa so aus dem Kopf herauskommen:
| |
--- - - --- - - --- --- - - ---
|
Damit das wieder genauso aussieht wie das Schreibsignal, muesste die
Platte ausser verstaerken und gleichrichten wenigstens noch ein
Flip-Flop enthalten das bei jedem Puls toggelt. Tut sie das wirklich?
> > [Datenrate]
> >
> Durch die Reduzierung auf 1 Bit wären es dann 150KiByte.
Ack.
> Und da hier bestimmt viele 0 oder 1 aufeinander folgen, könnte man
> einiges an Speicherplatz durch ein geeignetes Verfahren sparen.
Das bezweifle ich. Bei MFM duerfen z.B. niemals 2 "Einsen" und nicht
mehr als 2 "Nullen" aufeinander folgen.
> Daher
> mein Vorschlag mit den Zeiten. Wäre also nicht anderes, als eine Tabelle
> mit der Anzahl der 0 bzw. 1.
Mit einem simplen Algorithmus wie "es folgen x Nullen" wuerdest du
fruehestens bei RLL was "holen" koennen ... und fittere Algorithmen
werden mangels Rechenpower nicht moeglich sein.
Ausserdem machst du dir damit wieder das "kompatibel mit allen Formaten"
kaputt, wenn es die Datenrate des worst case (01010101) nicht
verkraftet.
> Da eine maximale Zeit zwischen den
> Flußwechseln exitiert, kann auch kein Überlauf passieren. Bzw. kann
> dieser gleich als "Error" für den Controller gewertet werden!
Ich bin nicht sicher ob eine maximale Zeit zwischen 2 Flusswechseln (von
der Platte her!) existiert. Logischerweise braucht der Controller diese
Zeit, damit sein Decoder syncron bleiben kann - die Platte braucht sie
aber IMHO nicht. Warum soll ein Controller nicht einen Track komplett in
eine Richtung magnetisieren *koennen* - was haette eine reale Platte
damit fuer ein Problem?
Der einzige *Faktor* fuer die Maximalzeit den die Platte selbst
bestimmt, ist IMHO die maximale Gleichlaufschwankung ihrer Spindel
(Gerade in dieser Disziplin wuerde unsere virtuelle Platte aber jede
reale bei weitem uebertreffen). Das absolute Limit wird aber nur durch
die Codierung - und damit durch den Controller - bestimmt.
Da du ja eine perfekte Emulation anstrebst (die sich wie eine reale
Platte verhalten soll) und keine Einschraenkungen wie "funktioniert nur
mit Codierung XXX" zulassen wolltest, muss die virtuelle Platte
konsequenterweise mit allem klarkommen - auch ganz ohne Flusswechsel
(was dem Auslieferungszustand einer realen Platte noch ohne Format
entsprechen sollte).
Hoffmann-Vetter, Martin
> > Und da hier bestimmt viele 0 oder 1 aufeinander folgen, könnte man
> > einiges an Speicherplatz durch ein geeignetes Verfahren sparen.
>
> Das bezweifle ich. Bei MFM duerfen z.B. niemals 2 "Einsen" und nicht
> mehr als 2 "Nullen" aufeinander folgen.
>
Ich denke, dies ist eine Frage der Samplingrate. Wählt man diese höher,
um die Flußwechselpunkte genauer angeben zu können, so werden es schon
ein paar mehr werden! ;-)
> Ausserdem machst du dir damit wieder das "kompatibel mit allen
> Formaten"
> kaputt, wenn es die Datenrate des worst case (01010101) nicht
> verkraftet.
>
Dazu gibt's die minimale Zeit zwischen zwei Flußwechseln, die dies
verhindert, bzw. in den Error-Zustand geht. Ich werde auch auf einer
real existierenden Platten keine Daten mit 1GHz schrieben können...
> > Da eine maximale Zeit zwischen den
> > Flußwechseln exitiert, kann auch kein Überlauf passieren. Bzw. kann
> > dieser gleich als "Error" für den Controller gewertet werden!
>
> Ich bin nicht sicher ob eine maximale Zeit zwischen 2 Flusswechseln
> (von
> der Platte her!) existiert. Logischerweise braucht der Controller
> diese
> Zeit, damit sein Decoder syncron bleiben kann - die Platte braucht sie
> aber IMHO nicht. Warum soll ein Controller nicht einen Track komplett
> in
> eine Richtung magnetisieren *koennen* - was haette eine reale Platte
> damit fuer ein Problem?
>
Evtl. weil die Verstärker für den Schreib-/Lese-Kopf
Wechselnstromverstärker sind, und daher den Flußwechseln benötigen.
Außerdem habe ich soetwas gelesen/gehört, kann aber keine Quelle
angeben. :-(
Ich habe gestern schon mal versucht irgendwas in dieser Richtung zu
finden, aber leider erfolglos. Mich würde ein richtiges Datenblatt zu
einer alten Platte interessieren. Dort müßte sowas noch drin stehen.
> Der einzige *Faktor* fuer die Maximalzeit den die Platte selbst
> bestimmt, ist IMHO die maximale Gleichlaufschwankung ihrer Spindel
> (Gerade in dieser Disziplin wuerde unsere virtuelle Platte aber jede
> reale bei weitem uebertreffen).
>
Da der Controller aber für reale Platten gabaut wurde, ist nicht davon
auszugehen, daß man von dieser max. Zeit Abstand nimmt.
> Da du ja eine perfekte Emulation anstrebst (die sich wie eine reale
> Platte verhalten soll) und keine Einschraenkungen wie "funktioniert
> nur
> mit Codierung XXX" zulassen wolltest, muss die virtuelle Platte
> konsequenterweise mit allem klarkommen - auch ganz ohne Flusswechsel
>
;-)
> (was dem Auslieferungszustand einer realen Platte noch ohne Format
> entsprechen sollte).
>
Tut es das wirklich? Oder steht dort nicht eine Art Test-Muster drauf?
Gruß Martin
Michael Baeuerle
>
> Hallo,
>
> > > Und da hier bestimmt viele 0 oder 1 aufeinander folgen, könnte man
> > > einiges an Speicherplatz durch ein geeignetes Verfahren sparen.
> >
> > Das bezweifle ich. Bei MFM duerfen z.B. niemals 2 "Einsen" und nicht
> > mehr als 2 "Nullen" aufeinander folgen.
> >
> Ich denke, dies ist eine Frage der Samplingrate. Wählt man diese höher,
> um die Flußwechselpunkte genauer angeben zu können, so werden es schon
> ein paar mehr werden! ;-)
Das ist richtig. Aber mit der Samplingrate sollte man es nicht
uebertreiben - schon mit 8 Samples pro Flusswechsel im Beispiel waren
wir bei 74MHz und alles >100MHz macht mit Hobbymitteln und -geldbeuteln
keinen richtigen Spass mehr ...
> > Ausserdem machst du dir damit wieder das "kompatibel mit allen
> > Formaten"
> > kaputt, wenn es die Datenrate des worst case (01010101) nicht
> > verkraftet.
> >
> Dazu gibt's die minimale Zeit zwischen zwei Flußwechseln, die dies
> verhindert, bzw. in den Error-Zustand geht. Ich werde auch auf einer
> real existierenden Platten keine Daten mit 1GHz schrieben können...
;-)
War ein Missverstaendnis, du bist von einer hoeheren Samplingrate
ausgegangen. Ich meinte den Fall wo pro Sample auch ein Flusswechsel
moeglich waere (also die Kompression der codierten Daten).
> > [...]
> > Warum soll ein Controller nicht einen Track komplett in
> > eine Richtung magnetisieren *koennen* - was haette eine reale Platte
> > damit fuer ein Problem?
> >
> Evtl. weil die Verstärker für den Schreib-/Lese-Kopf
> Wechselnstromverstärker sind, und daher den Flußwechseln benötigen.
Das waere in der Tat moeglich - sogar wahrscheinlich.
Legt man das genannte Flip-Flop Prinzip in der Platte zugrunde (um die
Frequenzen auf dem Datenkabel so gering wie moeglich zu halten), dann
waere die maximale Zeit zwischen zwei Flusswechseln gleich der halben
Periodendauer der kleinsten Frequenz die der Verstaerker noch
vernuenftig verarbeiten kann bzw. koennen muss.
> Ich habe gestern schon mal versucht irgendwas in dieser Richtung zu
> finden, aber leider erfolglos. Mich würde ein richtiges Datenblatt zu
> einer alten Platte interessieren. Dort müßte sowas noch drin stehen.
Allerdings. Ohne spec koennen wir das wohl vergessen.
Das Problem ist, dass das damals vermutlich alles Papier war das jetzt
jemand einscannen muesste ...
Hoffmann-Vetter, Martin
> > Ich denke, dies ist eine Frage der Samplingrate. Wählt man diese
> höher,
> > um die Flußwechselpunkte genauer angeben zu können, so werden es
> schon
> > ein paar mehr werden! ;-)
>
> Das ist richtig. Aber mit der Samplingrate sollte man es nicht
> uebertreiben - schon mit 8 Samples pro Flusswechsel im Beispiel waren
> wir bei 74MHz und alles >100MHz macht mit Hobbymitteln und
> -geldbeuteln
> keinen richtigen Spass mehr ...
>
Eine zu geringe Samplingrate bringt aber auch Probleme!
> > Evtl. weil die Verstärker für den Schreib-/Lese-Kopf
> > Wechselnstromverstärker sind, und daher den Flußwechseln benötigen.
>
> Das waere in der Tat moeglich - sogar wahrscheinlich.
>
Vermute ich auch. ;-)
> Legt man das genannte Flip-Flop Prinzip in der Platte zugrunde (um die
> Frequenzen auf dem Datenkabel so gering wie moeglich zu halten), dann
> waere die maximale Zeit zwischen zwei Flusswechseln gleich der halben
> Periodendauer der kleinsten Frequenz die der Verstaerker noch
> vernuenftig verarbeiten kann bzw. koennen muss.
>
Das sehe ich auch so! Egal ob Flip-Flop oder nicht (ich meine auf so eie
ST-506 PLatte ist schon ein Menge an Elektonik), wird es ein Verfahren
geben, welches die Daten so aufbereiten wird. Daher kann man mit obiger
Theorie nicht verkehrt liegen.
> Allerdings. Ohne spec koennen wir das wohl vergessen.
> Das Problem ist, dass das damals vermutlich alles Papier war das jetzt
> jemand einscannen muesste ...
>
Wenn mir jemand ein gutes Datenblatt einer Platte (auch in Papierform)
zur Verfügung stellen würde, könnte ich es mal einscannen. Dann würde
wir mehr wissen. Aber leider habe ich kein Datenblatt über alte ST-506
Platten. Leider!
Gruß Martin
Michael Baeuerle
>
> Ich habe gestern schon mal versucht irgendwas in dieser Richtung zu
> finden, aber leider erfolglos. Mich würde ein richtiges Datenblatt zu
> einer alten Platte interessieren. Dort müßte sowas noch drin stehen.
Also ich habe folgende Pinouts fuer ST-506 gefunden:
Data connector pinout
=====================
Pin Function Direction
-------------------------------------------
1 Drive selected from drive
3 Reserved
4 Reserved
7 Reserved
9 Reserved
10 Reserved
13 +Write data to drive
14 -Write data to drive
17 +Read data from drive
18 -Read data from drive
Pins 2, 4, 6, 8, 11, 12, 15, 16, 19 and 20 are ground.
Das sagt ueber das Kopfsignal quasi gar nichts aus, ausser dass es
differentiell ist :-(
Control connector pinout
========================
All control connector signals are TLL level signals.
They are active when set to low state (0V).
Pin Function Direction
-------------------------------------------
2 Reduced write current to drive
4 Head select 2^2 to drive
6 Write gate to drive
8 Seek complete from drive
10 Track 0 from drive
12 Write fault from drive
14 Head select 2^0 to drive
16 Reserved
18 Head select 2^1 to drive
20 Index from drive
22 Ready from drive
24 Step to drive
26 Drive select 1 to drive
28 Drive select 2 to drive
30 Drive select 3 to drive
32 Drive select 4 to drive
34 Direction to drive
Pins 1-33 all odd pins are ground.
Das hingegen sagt schon einiges ueber die Steuerung der Platte.
- Adressieren
Die jeweilige Drive select Leitung runterziehen und warten bis die
Platte "Ready" ist
- Referenzpunkt anfahren
Direction auf "nach aussen" stellen und solange "Step" pulsen bis "Track
0" aktiv wird.
- Kopf auswaehlen
Binaere Nummer des gewuenschten Kopfes an "Head select" anlegen.
- Zugriff
Mit "Write" auswaehlen ob Lesen oder Schreiben. Reduced write current
ist nur fuer reale Platten interessant, unsere virtuelle kann es
ignorieren. Das Indexsignal als Track Referenzpunkt laesst sich leicht
erzeugen (3600 Pulse pro Minute).
Offen ist welche Richtung ein aktives "Direction" Signal bewirkt und
welche Laenge die Pulse fuer Step und Index haben muessen. Die
Wartezeiten die der Controller jeweils einhalten muss sind eigentlich
uninteressant (da wir eh schneller sein werden als noetig).
Elektrisch waren vermutlich bipolare Open-Collector Treiber vorgesehen
da der Control Bus terminiert werden musste (Passive Thevenin-Equivalent
Terminatoren 220/330Ohm wie bei SE-SCSI). Damit bekommt man Abschluesse
fuer 132Ohm Kabel und es ergeben sich High-Pegel von 3V - was (wie
gefordert) TTL kompatibel ist.
Diese Steuerung waere jedenfalls sehr leicht zu emulieren (elektrisch
wie logisch). Der Knackpunkt ist also eindeutig wie wir die Position der
Flusswechsel moeglichst genau abbilden koennen, ohne dass die dabei
anfallenden Datenmengen bzw. die benoetigte Rechenpower ins uferlose
steigen.
Hoffmann-Vetter, Martin
> Also ich habe folgende Pinouts fuer ST-506 gefunden:
Die findet man noch sehr gut.
> 13 +Write data to drive
> 14 -Write data to drive
> 17 +Read data from drive
> 18 -Read data from drive
>
> Das sagt ueber das Kopfsignal quasi gar nichts aus, ausser dass es
> differentiell ist :-(
>
Ich muß hier mal wühlen. Irgendwo liegen noch solche Controller, und ich
meine dort RS422/423-Treiber drauf gesehen zu haben.
> Reduced write current
> ist nur fuer reale Platten interessant, unsere virtuelle kann es
> ignorieren.
Sehe ich auch so!
> Das Indexsignal als Track Referenzpunkt laesst sich leicht
> erzeugen (3600 Pulse pro Minute).
Sollt aber auch zum Datenstorm syncron sein. Es wären Controller
denkbar, die in der Nähe der Indexmarke einen bestimmten Sektor
erwarten.
> Offen ist welche Richtung ein aktives "Direction" Signal bewirkt und
> welche Laenge die Pulse fuer Step und Index haben muessen.
Hmm, da es zwei Möglichkeiten bezüglich der Richtung gibt, könnte man's
ausprobieren. Letztendlich ist auch egal, entweder liegt Spur 0 innen
oder außen. Wir sollten eben nur verhindern, daß man unter Spur 0 oder
über die höchste Spur fahren kann. Und der Puls sollte für uns immer
reichen. Die Indexbreite ist schon eher interessant!
> Die
> Wartezeiten die der Controller jeweils einhalten muss sind eigentlich
> uninteressant (da wir eh schneller sein werden als noetig).
;-)
> Diese Steuerung waere jedenfalls sehr leicht zu emulieren (elektrisch
> wie logisch). Der Knackpunkt ist also eindeutig wie wir die Position
> der
> Flusswechsel moeglichst genau abbilden koennen, ohne dass die dabei
> anfallenden Datenmengen bzw. die benoetigte Rechenpower ins uferlose
> steigen.
Genau hier liegt das eigentlich Probelm.
Gruß Martin
P.S.: Der vom Ulrich vorgeschlagene ct-Artikel ist ganz brauchbar. Liegt
hier in Papierform vor. Evtl. scanne ich das mal. Oder versuche morgen
mal die Zeit zum Lesen zu nehmen.
P.S.2: In dem ct-Artikel kommt als Daten-Treiber (Read-Data bzw. Write
Data) ein 26LS31 bzw. 26LS32 zum Einsatz! Also stimmte die Annahme.
Michael Baeuerle
>
> > Das Indexsignal als Track Referenzpunkt laesst sich leicht
> > erzeugen (3600 Pulse pro Minute).
>
> Sollt aber auch zum Datenstorm syncron sein. Es wären Controller
> denkbar, die in der Nähe der Indexmarke einen bestimmten Sektor
> erwarten.
Das wird automatisch syncron. Den Takt von 3600/min hat man ja sowieso
um die Track Daten zyklisch auszugeben.
> > Offen ist welche Richtung ein aktives "Direction" Signal bewirkt und
> > welche Laenge die Pulse fuer Step und Index haben muessen.
>
> Hmm, da es zwei Möglichkeiten bezüglich der Richtung gibt, könnte man's
> ausprobieren. Letztendlich ist auch egal, entweder liegt Spur 0 innen
> oder außen.
Egal ist es nicht, da in der Richtung "aussen" irgendwann das TRACK0
Signal aktiv werden muss, in der Richtung "innen" dagegen nicht.
> Wir sollten eben nur verhindern, daß man unter Spur 0 oder
> über die höchste Spur fahren kann.
Ack. Das (was bei der realen Platte der mechanische Anschlag ist)
sollten wenige Zeilen Software erledigen.
> Und der Puls sollte für uns immer
> reichen.
Das Rodime Sheet von Ralf beantwortet ja schon einge Fragen.
> Die Indexbreite ist schon eher interessant!
Warum soll die wichtiger sein als die anderen Timings?
Hoffmann-Vetter, Martin
> > Sollt aber auch zum Datenstorm syncron sein. Es wären Controller
> > denkbar, die in der Nähe der Indexmarke einen bestimmten Sektor
> > erwarten.
>
> Das wird automatisch syncron. Den Takt von 3600/min hat man ja sowieso
> um die Track Daten zyklisch auszugeben.
>
Das könnte klappen.
> > Hmm, da es zwei Möglichkeiten bezüglich der Richtung gibt, könnte
> man's
> > ausprobieren. Letztendlich ist auch egal, entweder liegt Spur 0
> innen
> > oder außen.
>
> Egal ist es nicht, da in der Richtung "aussen" irgendwann das TRACK0
> Signal aktiv werden muss, in der Richtung "innen" dagegen nicht.
>
Wenn wir das Track_0-Signal nicht bedienen würden, würde die Platte
irgendwann mal an einem Ende hängen bleiben, weil der Controller auf die
0-Marke wartet. Dieses Ende sollte dann "Track 0" sein!
> Ack. Das (was bei der realen Platte der mechanische Anschlag ist)
> sollten wenige Zeilen Software erledigen.
>
ACK, so sehe ich das auch!
> > Und der Puls sollte für uns immer
> > reichen.
>
> Das Rodime Sheet von Ralf beantwortet ja schon einge Fragen.
>
Korrekt. Leider aber noch nicht alle unsere Flusswechselfragen.
> > Die Indexbreite ist schon eher interessant!
>
> Warum soll die wichtiger sein als die anderen Timings?
>
Weil es (fast) das einzige Signal ist, auf das wir erzeugen müssen (von
den Daten mal angesehen). Alle anderen Signale steuern uns nur!
Gruß Martin
Michael Baeuerle
>
> Ingo Korb <nos...@akana.de> writes:
>
> > Die Daten stammen aus dem Datenblatt eines NEC uPD7261A/B, das ich in
> > einem aelteren NEC-Datenbuch vorliegen habe. Wenn nichts dazwischenkommt
> > scanne ich es mal in den naechsten Tagen ein.
>
> Es kam nichts dazwischen,
:-)
> http://snowcat.de/7261-9302.zip (ca. 2MB)enthaelt die Scans.
Sofort runtergeladen ...
> Der uPD9302 ist ein "CMOS Hard-Disk Interface",
> da drin steckt u.a. die PLL die sich auf den MFM-Datenstrom
> synchronisiert.
Seeehr schoen. Danke!
Aus dem maximalen Jitter den die PLL noch verarbeiten kann, kann man die
(fuer diesen Controller) minimal noetige Samplingrate fuer den Emulator
berechnen ... Damit es auch mit dem letzten diskret aufgebauten
Controller funktioniert, sollte man noch etwas hochgehen.
Patrick Schaefer
> > Ich habe gestern schon mal versucht irgendwas in dieser Richtung zu
> > finden, aber leider erfolglos. Mich würde ein richtiges Datenblatt zu
> > einer alten Platte interessieren. Dort müßte sowas noch drin stehen.
>
> Allerdings. Ohne spec koennen wir das wohl vergessen.
> Das Problem ist, dass das damals vermutlich alles Papier war das jetzt
> jemand einscannen muesste ...
Das Manual einer Seagate ST-412 kann ich Dir schicken, das sind ca.
1,5MB. Darin ist das Interface und das Timing beschrieben.
Außerdem habe ich einen Wilson SX-530 Fixed Disk Memory Exerciser, das
ist ein Prüfgerät für Platten mit SMD-, SA-, und ST-506-Interface. Wenn
es wirklich mal akut wird, kann ich Dir das Ding ausleihen (oder
verkaufen ;-), dann kannst Du mal Deine Kreation auf Herz und Nieren
testen.
BTW: ich bin immer noch der Meinung, es ist einfacher, den Controller
mitzuemulieren, d.h. die Schnittstelle auf dessen Register zu legen.
Patrick
Michael Baeuerle
>
> Michael Baeuerle schrieb:
>
> > > Ich habe gestern schon mal versucht irgendwas in dieser Richtung zu
> > > finden, aber leider erfolglos. Mich würde ein richtiges Datenblatt zu
> > > einer alten Platte interessieren. Dort müßte sowas noch drin stehen.
> >
> > Allerdings. Ohne spec koennen wir das wohl vergessen.
> > Das Problem ist, dass das damals vermutlich alles Papier war das jetzt
> > jemand einscannen muesste ...
>
> Das Manual einer Seagate ST-412 kann ich Dir schicken, das sind ca.
> 1,5MB. Darin ist das Interface und das Timing beschrieben.
[Manual nach Mailbox overflow endlich angekommen]
Da stehen sehr interessante Sachen drin:
1) Das komplette Control Interface
Damit sind jetzt alle Zuordnungen wie "nach innen" zu den zugehoerigen
Pegeln und alle Timings bekannt. Das gilt auch fuer das Protokoll.
2) Die Kopfdaten
Dass die Pegel RS-422 konform und damit digital sind (also mit 1Bit
Aufloesung gesampled werden koennen) war ja schon klar. Neu ist, dass
die Platte doch keine Flanken, sondern auf ReadData fuer jeden
Flusswechsel einen kompletten Puls >25ns ausgibt (und einen Puls von
50-150ns fuer jeden zu schreibenden Flusswechsel auf WriteData
erwartet). Der eigentliche Flusswechsel liegt dabei immer auf der
"leading edge", d.h. die Puls*laenge* ist unwichtig solange sie die
Toleranz nicht verlaesst.
Damit scheint es also doch keinen Maximalabstand zwischen 2
Flusswechseln zu geben (ist auch nirgends einer angegeben) ... der
Controller hat also offenbar tatsaechlich die Macht, notfalls den
kompletten Track auf eine Polaritaet zu magnetisieren (gar keine
Flusswechsel). Der minimale Abstand zwischen 2 Flusswechseln ist fuer
die ST-412 mit max. 9074ftpi angegeben. Was das fuer das Timing
bedeutet, muss man also erst ausrechnen:
Die ST-412 hat 130mm Medien. Wenn die Abbildung auf Seite 10 halbwegs
massstaeblich ist, liegt der innerste Track so grob auf dem halben
Radius - also ca. 33mm von der Achse entfernt. Demnach hat er eine
Laenge von grob 200mm. Damit haetten dort etwa 71449 Flusswechsel Platz
(Seagate gibt ca. 10KiByte/Track mit MFM an - das kann also stimmen).
Bei 3600RPM ergibt das max. 4.3 Millionen Flusswechsel pro Sekunde
(Seagate gibt 5MBit/s an).
Nehmen wir also auch 5MHz fuer die maximal Flusswechselrate, dann ergibt
sich 200ns Periodendauer. Die NEC 9306A DPLL kann aber nur ein maximales
Jitter von +-30ns vertragen (damit sie nicht "ausrastet"). Die
Samplingrate sollte also wohl nicht unter 1/(10ns)=100MHz liegen, damit
das auch mit aelteren (diskret aufgebauten und weniger toleranten)
Controllern noch funktioniert. Die LL-Daten wuerden dann um Faktor 20
aufgeblaeht, die Nutzdaten etwa Faktor 25 (mit gaengigem LL Format).
Die Datenmenge waere noch vetretbar, aber die noetige Rechenpower wohl
nicht. Die braucht man ausserdem zweimal: Einmal fuer diesen Task und
dann nochmal entweder fuer das Interface zur realen Platte (das
unkomprimiert im MiByte/s Bereich uebertragen koennen sollte) oder eben
fuer den Kompressionsalgorithmus.
Ich denke das laesst sich hobbymaessig (also ohne DSP und FPGA) nicht
realisieren ...
Micha
--
Liebes GMX-Mitglied,
Ihre aktuelle Mailboxgroesse betraegt jetzt 21841 von 20480 KByte.
[...]
Message vom GMX System nach MS-Wurm overflow
Patrick Schaefer
> Nehmen wir also auch 5MHz fuer die maximal Flusswechselrate, dann ergibt
> sich 200ns Periodendauer. Die NEC 9306A DPLL kann aber nur ein maximales
> Jitter von +-30ns vertragen (damit sie nicht "ausrastet"). Die
> Samplingrate sollte also wohl nicht unter 1/(10ns)=100MHz liegen, damit
> das auch mit aelteren (diskret aufgebauten und weniger toleranten)
> Controllern noch funktioniert. Die LL-Daten wuerden dann um Faktor 20
> aufgeblaeht, die Nutzdaten etwa Faktor 25 (mit gaengigem LL Format).
Das gilt, wenn Du asynchron abtastest. Du kannst es Dir einfacher
machen, wenn Du Dich an den 20MHz-Takt des MFM-Controllers hängst und
die Daten hierzu synchron rausschiebst. (100% controller-unabhängig bist
Du dann allerdings nicht mehr)
Early und Late beim Schreiben kann man ja ruhig ignorieren, da muß man
nur sicherstellen, daß einem kein Puls verloren geht.
Trotz allem, den Controller mitemulieren ist deutlich einfacher.
Patrick
Michael Baeuerle
>
> Michael Baeuerle schrieb:
>
> > Nehmen wir also auch 5MHz fuer die maximal Flusswechselrate, dann ergibt
> > sich 200ns Periodendauer. Die NEC 9306A DPLL kann aber nur ein maximales
> > Jitter von +-30ns vertragen (damit sie nicht "ausrastet"). Die
> > Samplingrate sollte also wohl nicht unter 1/(10ns)=100MHz liegen, damit
> > das auch mit aelteren (diskret aufgebauten und weniger toleranten)
> > Controllern noch funktioniert. Die LL-Daten wuerden dann um Faktor 20
> > aufgeblaeht, die Nutzdaten etwa Faktor 25 (mit gaengigem LL Format).
>
> Das gilt, wenn Du asynchron abtastest. Du kannst es Dir einfacher
> machen, wenn Du Dich an den 20MHz-Takt des MFM-Controllers hängst und
> die Daten hierzu synchron rausschiebst. (100% controller-unabhängig bist
> Du dann allerdings nicht mehr)
Dann sind wir wieder am Anfang und man muss von Codierung bis zu
LL-Format alles wissen ... Ausserdem ist das haesslich, weil man dann
ein zusaetzliches Kabel fuer 20MHz verlegen muss und das auch nicht
unbedingt bei allen Controllern gleich funktioniert (koennte z.B.
geteilt sein).
> Early und Late beim Schreiben kann man ja ruhig ignorieren, da muß man
> nur sicherstellen, daß einem kein Puls verloren geht.
Precompensation schaltet man gleich am Controller ab - dann gibt es
keine Probleme damit. Es gab ja auch reale Platten (z.B. ST-412) die das
nicht verwendet haben, muss also jeder Controller koennen.
> Trotz allem, den Controller mitemulieren ist deutlich einfacher.
Ack.
Michael Baeuerle
>
> Michael Baeuerle <michael....@gmx.net> writes:
>
> > Nehmen wir also auch 5MHz fuer die maximal Flusswechselrate, dann ergibt
> > sich 200ns Periodendauer. Die NEC 9306A DPLL kann aber nur ein maximales
> > Jitter von +-30ns vertragen (damit sie nicht "ausrastet"). Die
> > Samplingrate sollte also wohl nicht unter 1/(10ns)=100MHz liegen, damit
> > das auch mit aelteren (diskret aufgebauten und weniger toleranten)
> > Controllern noch funktioniert. Die LL-Daten wuerden dann um Faktor 20
> > aufgeblaeht, die Nutzdaten etwa Faktor 25 (mit gaengigem LL Format).
>
> Zaehlstandes eines 100MHz-Zaehlers bei steigender Flanke des
> Datensignals erfolgt? Das duerfte in Hardware noch mit vertretbarem
> Aufwand machbar sein (ein Takt-Zaehler, ein Puls-Zaehler, mehrere
> flankengetriggerte Latches von denen das durch den Puls-Zaehler
> selektierte den Takt-Zaehler uebernimmt) und reduziert vermutlich den
> Datenbedarf drastisch.
Das kriegst du aber ohne FPGA auch nicht hin ...
Ich bin mir auch nicht sicher, ob das die Datenmenge wirklich drastisch
reduziert. Wenn alle 400ns 1.5 Pulse vorhanden sind (was bei MFM der
Schnitt sein sollte) fallen beim Sampling etwa 27Bit pro Puls an. Dein
Zaehler muss eine gesamte virtuelle Umdrehung durchlaufen damit der
Jitter gering bleibt (Puls-zu-Puls Zeiten gehen IMHO nicht), d.h. er
muss 17ms laufen. Er zaehlt dabei bis ca. 1700000 und muss daher 21Bit
haben. Der Gewinn ware also nicht extrem aber der Hardwareaufwand im
Vergleich zum Sampling deutlich hoeher.
> > Ich denke das laesst sich hobbymaessig (also ohne DSP und FPGA) nicht
> > realisieren ...
>
> Warum ohne FPGA?
Weil die FPGAs halt normalwerweise widerliche Gehaeuse haben, mit 3.3V
laufen wollen und ausserdem recht teuer sind. Ich habe keine Erfahrung
damit, sieht vielleicht aktuell anders aus ... Mir waere es aber zu
aufwaendig mich da von Null an einzuarbeiten (jedenfalls fuer dieses
Projekt).
Ingo Korb
> Nehmen wir also auch 5MHz fuer die maximal Flusswechselrate, dann ergibt
> sich 200ns Periodendauer. Die NEC 9306A DPLL kann aber nur ein maximales
> Jitter von +-30ns vertragen (damit sie nicht "ausrastet"). Die
> Samplingrate sollte also wohl nicht unter 1/(10ns)=100MHz liegen, damit
> das auch mit aelteren (diskret aufgebauten und weniger toleranten)
> Controllern noch funktioniert. Die LL-Daten wuerden dann um Faktor 20
> aufgeblaeht, die Nutzdaten etwa Faktor 25 (mit gaengigem LL Format).
Eigentlich sind 100MHz Samplerate doch unnoetig: Wenn der MFMulator
ebenfalls eine 9306 oder etwas vergleichbares besitzt, wuerde die sich auf
den Schreibdatenstrom des Controllers synchronisieren und an ihren
Ausgaengen den zu den Datenbits passenden Takt liefern. Es koennte
allerdings ein wenig Flexibilitaet bei exotischeren LL-Formaten
verlorengehen.
Wenn man so wirklich nur noch die Nutzdaten mit Takt (meinem
Verstaendnis nach 10MHz) angeliefert bekommt wuerde sich auch die
umgekehrte Richtung stark vereinfachen. Mit einem (zB) 74165
8-Bit-Shiftregister muesste der Mikrocontroller 0.8uS ein Byte liefern
koennen, ein 20MHz AVR[1] koennte die Fuellschleife IMHO in weniger als
den zur Verfuegung stehenden 16 Taktzyklen schaffen.
-ik
[1] Hat leider zu wenig internes Ram und mit dem externen habe ich mich
noch nie beschaeftigt.
Michael Baeuerle
>
> Eigentlich sind 100MHz Samplerate doch unnoetig: Wenn der MFMulator
> ebenfalls eine 9306 oder etwas vergleichbares besitzt, wuerde die sich auf
> den Schreibdatenstrom des Controllers synchronisieren und an ihren
> Ausgaengen den zu den Datenbits passenden Takt liefern. Es koennte
> allerdings ein wenig Flexibilitaet bei exotischeren LL-Formaten
> verlorengehen.
Etwas ist gut, das geht dann *nur* mit MFM.
> Wenn man so wirklich nur noch die Nutzdaten mit Takt (meinem
> Verstaendnis nach 10MHz)
5MHz.
> angeliefert bekommt wuerde sich auch die
> umgekehrte Richtung stark vereinfachen. Mit einem (zB) 74165
> 8-Bit-Shiftregister muesste der Mikrocontroller 0.8uS ein Byte liefern
> koennen, ein 20MHz AVR[1] koennte die Fuellschleife IMHO in weniger als
> den zur Verfuegung stehenden 16 Taktzyklen schaffen.
An solche Vereinfachungen hatte ich am Anfang ja auch gedacht. Das haben
wir dann aber mangels Flexibilitaet verworfen.
> [1] Hat leider zu wenig internes Ram und mit dem externen habe ich mich
> noch nie beschaeftigt.
Das externe RAM wird genauso angesprochen wie das interne. Der einzige
Unterschied ist, dass im besten Fall (ohne Waitstate) ein Zugriff 3
statt 2 Takte benoetigt.
Jan Fischer
Hoffmann-Vetter, Martin <mart...@web-made.com> wrote:
Also ich habe mich bisher nur am Rande mit MFM-Festplatten be-
schaeftigt, aber
>> Analog speichern kann ich es ja wohl schlecht
>>
> Leider!
warum eigentlich nicht?
Koennte man nicht eine "moderne" Festplatte mit etwa 300 MByte
Nettokapazitaet einfach zu einer MFM-Festplatte machen?
Man koennte doch einfach die Festplattenelektronik und -steuerung
gegen die eigene austauschen. Der Aufbau der Festplatten auch
unterschiedlicher Hersteller ist recht aehnlich, so dass sich
eine Platine entwickeln lassen muesste, welche mit einem gesockelten
Microcontroller ausgestattet wird, so dass man das Programm diesen
Microcontrollers vor dem Aufstecken auf die Platine noch para-
metrieren kann. Sicherlich werden auch noch ein paar Stroeme
fuer die Motoren und den Lese-/Schreibkopf einzustellen sein,
fuer welche man dann mit Potentionmeter vorsehen muesste.
Vieleicht ist die Elektronik daher nicht vollstaendig auf
der Festplatte unter zu bringen, aber ich halte diesen
Weg fuer gangbar.
Tschuess
Jan
Michael Baeuerle
>
> [...]
> Koennte man nicht eine "moderne" Festplatte mit etwa 300 MByte
> Nettokapazitaet einfach zu einer MFM-Festplatte machen?
Mit MFM haette sie dann im besten Fall noch 200MByte, wahrscheinlich
deutlich weniger (wenn es z.B. so ein "neumodisches" 3.5" Teil mit nur 4
Koepfen ist).
> Man koennte doch einfach die Festplattenelektronik und -steuerung
> gegen die eigene austauschen.
Platten dieser Kapazitaet haben i.d.R. servogefuehrte Koepfe. Dieses
Kopfservo selbst zu entwickeln duerfte fuer unsereins unmoeglich sein
... selbst wenn man die techn. Daten die man dazu braucht haette und
eine eigene CPU dafuer spendieren wuerde.
> Der Aufbau der Festplatten auch
> unterschiedlicher Hersteller ist recht aehnlich, so dass sich
> eine Platine entwickeln lassen muesste, welche mit einem gesockelten
> Microcontroller ausgestattet wird,
Allein die Adaptierung der voellig verschiedenen Folienkabel duerfte ein
ganz wuestes Kapitel werden ...
> so dass man das Programm diesen
> Microcontrollers vor dem Aufstecken auf die Platine noch para-
> metrieren kann. Sicherlich werden auch noch ein paar Stroeme
> fuer die Motoren und den Lese-/Schreibkopf einzustellen sein,
> fuer welche man dann mit Potentionmeter vorsehen muesste.
Sicher nicht. Das wuerde man dann auch gleich per Software erschlagen.
> Vieleicht ist die Elektronik daher nicht vollstaendig auf
> der Festplatte unter zu bringen, aber ich halte diesen
> Weg fuer gangbar.
Ich nicht. Der Aufwand waere gigantisch - viel hoeher als bei dem
digitalen Emulator. Schon das Reverse-Engeneering der techn. Daten
(offizielle wird man sicher keine bekommen) waere ein Riesenaufwand.
Micha
--
Wer sagte das doch noch mal: Er koenne garnicht so viel essen, wie er
kotzen koenne?
Horst-D Winzler in de.sci.electronics