Michael Baeuerle schrieb:

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

Antworten

[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

Antworten

Michael Baeuerle schrieb:

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

Antworten

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

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.

Ack.

Micha
--
Liebes GMX-Mitglied,
Ihre aktuelle Mailboxgroesse betraegt jetzt 21841 von 20480 KByte.
[...]
                        Message vom GMX System nach MS-Wurm overflow

Antworten

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.

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

Micha
--
Liebes GMX-Mitglied,
Ihre aktuelle Mailboxgroesse betraegt jetzt 21841 von 20480 KByte.
[...]
                        Message vom GMX System nach MS-Wurm overflow

Antworten

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.

Antworten

Etwas ist gut, das geht dann *nur* mit MFM.

5MHz.

An solche Vereinfachungen hatte ich am Anfang ja auch gedacht. Das haben
wir dann aber mangels Flexibilitaet verworfen.

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.

Micha
--
Liebes GMX-Mitglied,
Ihre aktuelle Mailboxgroesse betraegt jetzt 21841 von 20480 KByte.
[...]
                        Message vom GMX System nach MS-Wurm overflow

Antworten

Hallo!

Also ich habe mich bisher nur am Rande mit MFM-Festplatten be-
schaeftigt, aber

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

Antworten

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

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.

Allein die Adaptierung der voellig verschiedenen Folienkabel duerfte ein
ganz wuestes Kapitel werden ...

Sicher nicht. Das wuerde man dann auch gleich per Software erschlagen.

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

Antworten