Posts by Georg

    Jetzt wolltest Du es aber ganz genau wissen ;)


    Man könnte natürlich jetzt noch hingehen und mit einem Zähler die Instruktionen bzw. Zyklen zählen, die die einzelnen Maschinen tatsächlich brauchen. Anfang und Ende könnte ja über das Busy-Signal gesteuert werden, das das Lämpchen an der Tastatur steuert.

    In den ca. 0,3s konnen immerhin fast 200000 Instruktionen verarbeitet werden!


    Aber im Ernst: Es ist natürlich ein interessantes Thema, aber angesichts der Unterschiede ziemlich akademisch. Selbst die 0,3% Unterschied zwischen B/T und F finde ich eigentlich irrelevant - nur kenne ich hier halt die wesentliche Ursache. Wenn mir der unterschiedliche Aufbau der Refresh-Counter nicht aufgefallen wäre hätte ich mir nie Gedanken über Geschwindigkeitsunterschiede gemacht.

    Eigentlich dachte ich, dass zwischen der B und der T/F 0,3% wegen der 36 zu 32 Takte beim Refresh liegen. Die T und die F müssten doch eigentlich beim Refresh gleich sein, oder?

    Die Modelle B und T sind näher miteinander verwandt als mit dem Modell F. Sie benutzen (bis auf RAM und ROM) vergleichbare CPU-Boards; das Timing z.B. erledigt bei der B das Board 6308 und bei der T das Board 6708, die sich nur geringfügig unterscheiden. Beim Refresh-Zähler sehe ich auf Anhieb keine relevanten Unterschiede.

    Das Modell F ist dagegen komplett neu entworfen; beim Modell T besteht die CPU inkl. RAM/ROM aus sieben Boards - beim Modell F wurde das auf 2 Boards zusammengeschrumpft. Zwar ist die Architektur immer noch vergleichbar, aber es gibt geringfügige Unterschiede. U.A. wurden komplexere TTL-Bausteine verwendet, um ICs und damit Platz sowie Leistung zu sparen. Das äußert sich z.B. beim Refresh-Counter, der hier einfacher aufgebaut ist.


    Entsprechend sollten B und T eher gleich schnell sein, F etwas langsamer.

    (Hinweis: B steht repräsentativ für die Modelle A,B und C; entsprechend gelten die Aussagen zum Modell T auch für das Modell S, und schließlich haben die Modelle E und F ebenfalls identische CPUs.)

    0,3% wegen der 36 zu 32 Takte beim Refresh liegen

    36 / 32 sind 12,5% mehr. Oder hab ich da was falsch verstanden mit dem Refresh?

    Jaja, die Prozentrechnung. Damit kann man lustige Dinge anstellen.

    Richtig ist, dass zwischen zwei Refresh-Zyklen bei den Modellen B und T (und ihren Geschwistern) 12,5% mehr Instruktionen verarbeitet werden als bei den Modellen E und F. Da diese Abstände aber unterschiedlich lang sind, entspricht das nicht dem Unterschied in der Rechenleistung.


    Ich bin von 32 * 36 = 1152 Zyklen ausgegangen, die auf allen Maschinen in der gleichen Zeit abgearbeitet werden. Innerhalb dieser 1152 Zyklen gibt es bei den älteren Rechnern 32 Refresh-Zyklen und bei den Kompaktmodellen 36 Refresh-Zyklen.

    Tatsächlich werden also in dieser Zeit bei den alten Maschinen 1120 "echte" Instruktionen verarbeitet; bei den kompakten sind es in der gleichen Zeit 1116. Diese vier zusätzlichen Instruktionen entsprechen ca. 0,35% der Gesamtzeit; bezogen auf die 1120 Netto-Instruktionen bei den älteren Rechnern sind die neuen ca. 0,36% langsamer.

    Also gilt jetzt diese Reihenfolge:

    1. Emulator: 11:07 (kein DRAM-Refresh nötig)
    2. Modell B: 11:26
    3. Modell T: 11:27
    4. Modell F: 11:29

    Da ich nur sekundengenau handgestoppt habe, würde ich sagen, da gibt es bei diesem Programm quasi keine nennenswerte Abweichung zwischen den einzelnen Modellen. Der maximale Unterschied beträgt ja nur ca. 0,4 %...

    Nun, da der theoretische Unterschied zwischen der F und der T bei 0,3% liegt würde ich schon sagen, dass es sich bestätigt, dass die F langsamer ist.


    Also ich hatte mal einen Endlos-Benchmark auf den beiden gestartet und tatsächlich festgestellt, dass die T minimal schneller war.


    Die Sekunde zwischen B und T dürfte dagegen wirklich aus der Messmethode resultieren.

    Was die Fehler mit dem WDE angeht: das erinnert mich an die Probleme, die ich auf der CC mit der MVP im Multiuser-Modus hatte. Da scheint noch was besonderes im Protokoll zu existieren das ich nicht kenne.

    Eine Reset - Leitung von der CPU zum WDE gibt es natürlich, aber eigentlich sollte der dann nicht komplett neu booten, sondern nur der Zustand zurückgesetzt werden.

    Das mit der Adresse verstehe ich gerade auch nicht.

    Mal schauen, wann wir diesen Problemen auf die Spur kommen...

    Gerade habe ich auch die 2200T rechnen lassen, da ich sie für den Test mit dem Multiplexer sowieso eingeschaltet hatte. Sie brauchte 11 Minuten und 27 Sekunden. Die 2 Sekunden Differenz dürften wohl in der Toleranz liegen, oder?

    Zusammengefasst:

    Modell B: 11:43

    Modell T: 11:27

    Modell F: 11:29

    Emulator: 11:07


    Der Unterschied zwischen T und F entspricht ungefähr den 2,5s, die ich oben geschätzt habe. Das ROM der beiden ist afaik identisch.

    Die B hat ein anderes ROM - vielleicht ist die deshalb langsamer. Ich weiß z. B. nicht, ob die Zugriffe auf das Patchboard zusätzliche Zyklen kosten.

    (Info für den Rest der Welt: die ersten Modelle A bis C besaßen ein Patch-Board, mit dessen Hilfe Fehler im ROM korrigiert werden konnten. Die fehlerhaften Adressen wurden dort dekodiert, das Original-ROM ausgeblendet und durch eine aus Dioden gebildete Instruktion ersetzt.)


    Beim Emulator bringen die gesparten Refresh-Zyklen ca. 18 bis 19 Sekunden. Passt ungefähr...

    Toll, wenn sich die Theorie in der Praxis bestätigt! Afaik hast Du aber nur den einen Multiplexer, so dass sich das derzeit auf ein Modell T und die Workstation beschränkt, oder?

    Trotzdem eine tolle Sache. Klappt das auch mit dem Emulator?


    Und hast Du mal ein Bild von dem Setup?

    Die WANG 2200F ist von der Rechengeschwindigkeit her identisch mit der 2200B,

    Natürlich hast Du Recht, weil die Architektur und vermutlich auch der relevante Mikrokode identisch sind.

    Tatsächlich gibt es beim Refresh minimale Unterschiede: Das Modell B schiebt alle 36 Zyklen einen Refresh-Zyklus ein, beim Modell F kommt der nach 32 Zyklen. Von daher ist die F minimal langsamer.

    Wenn ich richtig gerechnet habe beträgt der Unterschied 0,3% oder 2,5s beim Apfelmännchen.

    Hi Michael,


    Das ist wirklich nicht OK:


    Da muss eine Schraube durch wie hier:

    (habe leider gerade keine besseren Bilder gefunden)

     


    Die fixe Einstellung der Adresse auf dem Disk-Controller stammt übrigens nicht von mir. Nicht meine Schrift, nicht meine Labels. :)


    Und die Stellen mit den durchgebrannt Leiterbahnen habe ich auch gefunden:

    Wie schon oben geschrieben: die zweite Schreibschutzkerbe deutet auf die Verwendung in einer 1541 hin.

    Wenn da also mal was Wang-spezifisches drauf war, dürfte das wohl überschrieben worden sein.

    Und die Hinweise auf die Nutzung in einem Wangwriter bedeuten ja nicht, dass da mal was für einen Wangwriter drauf war.

    Alles in allem bin ich ziemlich sicher, dass das keine der gesuchten Systemdisketten sind.

    Cartouce: Super, Danke!


    Ein paar Worte zur Track0-Einstellung:


    Auf der Achse des Schrittmotors für den Kopfantrieb befindet sich ein Alu-Arm, der sich durch eine Gabellichtschranke bewegt und dabei die Spur 0 festlegt (Die Lichtschranke ist auf dem Bild demontiert, um den Arm sehen zu können):



    Dieser Arm ist mit einer kleinen Imbus-Schraube auf der Motorwelle fixiert und kann somit eigentlich recht einfach justiert werden.

    Leider ist es etwas komplizierter: Der Motor hat (wie man lesen kann) 200 Schritt pro Umdrehung. Die Platte kann aber über 220 Spuren ansteuern, so dass diese Lichtschranke sowohl bei der Spur 0 als auch im Bereich der Spur 200 anschlägt. Um das jetzt eindeutig zu machen gibt es einen zweiten Sensor (das ist das Platinenteil links vom Schrittmotor, ebenfalls eine optische Lichtschranke mit LED und Phototransistor), der wohl direkt vom Kopf ausgelöst wird. Dieser Sensor gibt eine grobe Information, dass der Kopf "innen" steht, während der Sensor an der Welle eine exakte, aber dafür nicht eindeutige Information über die Kopfposition liefert.


    Die Elektronik der Platte kombiniert nun diese beiden Informationen und setzt nur dann die Leitung TRACK0, wenn beide Sensoren aktiv sind.


    Wenn ich nun den Arm auf der Welle verstelle bewege ich mich eine Zeitlang in dem aktiven Bereich des zweiten Sensors. Ungefähr ab Spur 10 liefert dieser zweite Sensor aber kein Signal mehr - und damit endet mein Einstellbereich hier. Wenn ich den Arm soweit verstelle, dass ich aus dem Bereich der Plattenschäden raus bin (ab ca. Spur 20) bekomme ich überhaupt kein TRACK0-Signal mehr.


    Mein aktueller Plan sieht jetzt so aus:


    1. Modifikation des zweiten Sensors, so dass er dauernd aktiv ist. Entsprechend bekomme ich dann über die knapp 230 Spuren der Platte zweimal das Signal TRACK0 - einmal innen, und einmal außen.

    2. Justierung des Arms, so dass die innere TRACK0-Position im Bereich der ehemaligen Spuren 20-30 liegt.

    3. Umdrehung der Anordnung: Logische Verlegung der Spur 0 auf die äußere Position


    Der Rest wird in der Software erledigt. Bei der Initialisierung wird der Kopf zunächst für ca. 250 Schritte nach außen bewegt. Die Endabschalter verhindern dabei, dass er an einen mechanischen Anschlag stößt. Anschließend wird er nach innen bewegt, bis das Signal TRACK0 erscheint. Damit ist die Spur 0 festgelegt.

    Der zweite (innere) TRACK0-Impuls nach 199 oder 200 Spuren signalisiert das Ende des nutzbaren Bereichs. Das wird zwar primär über das Zählen der Steps gesteuert, aber dieses Signal stellt eine zusätzliche Sicherheit dar, um nicht in den Bereich des Headcrashes zu kommen.


    Dass die Platte dann nur noch 200 Spuren hat ist für mich völlig unerheblich.


    Natürlich hat das Ganze nur wirklich Sinn, wenn das mit dem Lesen und Schreiben wieder klappt....


    Übrigens: Wenn ich von Spuren schreibe sind i.d.R tatsächlich Zylinder gemeint. Die tatsächliche Position eines Sektors wird durch Sektornummer, Spur und Kopf bzw. Plattenoberfläche festgelegt.

    Mein Beileid für diesen schmerzlichen Verlust :(

    Wenn wenigstens kein Headcrash vorläge, denn nun ist die Platte auch optisch beeinträchtigt.

    Danke :cry:

    Wobei ich einen solchen Headcrash bzw. dessen Spuren grundsätzlich für ganz anschaulich halte - immerhin ist das ein typischer Fehler bei diesen Platten gewesen. Ist halt im konkreten Fall wirklich blöde, weil ich bis dahin ja recht erfolgreich mit dem Lesen und Beschreiben der Platte war, woran jetzt nicht mehr zu denken ist.

    Die Welt ist um beeindruckende 6MB ärmer ....

    Hier ein kleines Andenken aus meinem YT Video, als sie sich noch munter drehte: https://youtu.be/biPoxiFeGZk?t=586

    Danke, hat mich gefreut! Genau so etwas habe ich mir hier vorgestellt.


    Joe_IBM , Digitalmax , Logout: Danke für Eure Angebote und Wünsche! Ich habe auch schon über einen Wechsel der Platte nachgedacht. Ich habe sowohl Cartridges als auch lose 14-Zoll-Scheiben hier - allerdings keine Ahnung, ob ich das mechanisch hinbekommen würde.

    Davon abgesehen fehlt es mir an einem geeigneten Arbeitsplatz:



    Ich habe zwar schon selber alte 5,25 Zoll Festplatten stundenlang ohne Deckel betrieben, ohne dass es irgendwelche Störungen gab, aber das ist keine Garantie dafür, dass diese Platte auch so robust gegen Staub ist.

    Und dann bleibt natürlich noch die Frage, welche Schäden der Schreib-/Lesekopf bei der Gelegenheit davon getragen hat.


    Mmh, ich sehe da zwei Probleme:

    Tatsächlich stellt sich die Frage, ob der Kopf zum Teufel ist. Die Scheifgeräusche sind zur Zeit nur auf den inneren ca. 20 Spuren zu hören - auf dem Rest der Platte hört sich das noch ganz normal an.

    Ich weiß auch nicht, wie die Rückseite der Platte aussieht. Möglicherweise ist der zweite Kopf und die zweite Oberfläche noch intakt - dummerweise habe ich bei meinen letzten Leseversuchen immer nur die erste Seite angesprochen. Und inzwischen habe ich die Platte wieder im Regal stehen und alle Messaufbauten abgebaut :rolleyes:

    Ich habe allerdings auch den Verdacht, dass ich beim Versuch, die Spur 0 zu verstellen, etwas an der Elektronik gegrillt habe. Jedenfalls roch es kurzfristig mal etwas streng. :fp:

    Steppen, Anschläge, Spur 0 etc. funktioniert noch alles, weshalb es kein großflächiger Schaden sein kann. Aber auf der Leseleitung habe ich nur noch irgendwelche wilden Peaks.


    Trotzdem werde ich natürlich den Strohhalm ergreifen und das Ganze nochmal auf der Rückseite ausprobieren - vielleicht ist mir ja doch eine 3MB-Platte geblieben.

    Die Welt ist um beeindruckende 6MB ärmer ....


    Viele Besucher der diesjährigen CC haben die 14-Zoll-Festplatte Philips X1250 bestaunt, die unter ihrem Klarsichtdeckel interessante Einblicke gewährte, sich eifrig drehte und dabei lustige Tänze mit ihrem Kopf aufführen konnte.


    Tja, offenbar war die Reise zur CC und der dortige Einsatz etwas zu viel für die alte Dame - wieder zurück in der Heimat zeigten sich bei der 41-jährigen die ersten Anzeichen einer Erkrankung: Vergesslichkeit, Lesefehler und dazu unangenehme Kratz- und Schleifgeräusche.

    Wie man sieht hat es einen Headcrash gegeben - dummerweise auf den Anfangsspuren (Spur 0 ist bei der Platte innen). :cry2:

    Ich habe versucht, den Kopfantrieb umzujustieren, aber das ist aus technischen Gründen zunächst unmöglich. Dazu müssen auch Teile der Elektronik umgebaut werden.


    Zusätzlich ist mir auch irgendetwas anderes kaputt gegangen; jedenfalls bekomme ich auch auf den anscheinend unbeschädigten Spuren nichts anständiges mehr gelesen.


    Schade, das war ein hübsches Spielzeug und auch ein spannendes Forschungsprojekt.


    Es würde mich freuen, wenn Ihr Eure Bilder oder Videos, die Ihr auf der CC von dem Schätzchen gemacht habt, hier posten bzw. verlinken würdet, um Eure Anteilnahme auszudrücken und mich etwas zu trösten .... :cry:

    An dieser Stelle möchte ich mal ein großes Dankeschön an Toast_r richten und meinen Respekt für deinen Einsatz und deine Arbeit zum Ausdruck bringen. :anbet:  :bussi:

    Ich versuche mir vorzustellen, was das für einen Haufen Arbeit ist, und alleine diese Vorstellung macht mich schwindlig....


    Herzlichen Dank, Christian!! :thumbup:

    Für mich ist die CP/M - Option interessant. Wenn es also geht konkretisiere ich:


    1 Stk 19" Rahmen mit Trafo und Spannungregelung

    1 Stk Parallel Eingabe

    1 Stk CPU 8085

    1 Stk Floppy Controller

    1 Stk Video 8.4

    1 Stk RAM/ROM 64k

    1 Stk RAM/ROM unbestückt

    1 Stk Bus-Signalanzeige


    Dafür verzichte ich auf das Drucker-Interface.

    Ich nehme, soweit noch vorhanden:


    1 Stk 19" Rahmen evtl. ohne Backplane

    1 Stk Trafo-Einschub

    1 Stk Spannungsregelung

    1 Stk Parallel Eingabe

    1 Stk CPU 8085

    1 Stk Floppy Controller

    1 Stk Video

    2 Stk RAM/ROM

    1 Stk Drucker-Interface

    1 Stk Bus-Signalanzeige

    Hat mir bitte eventuell jemand breites Endlospapier mit maximal 343 mm Breite, das er zur CC mitbringen kann? Das breite, das ich hier habe, ist mit 375 mm leider einige Zentimeter zu breit. :(

    Für den Drucker müsste ich noch Papier haben. Ich schaue morgen mal nach.

    Kurzer Zwischenstand: Ich habe bis jetzt nur 15"-Papier gefunden - also auch zu breit. Ich war aber eigentlich sicher, dass ich für den Drucker noch etwas gehabt hatte. Aber evtl. waren das auch nur kleine Reste ...


    Wenn sich noch was findet, bringe ich es jedenfalls mit.

    Es gibt Neuigkeiten...

    Zum einen ein YT-Video zu der Platte von mikemcbike. Allerdings hat er bisher nur den Spindelmotor in Betrieb genommen und nicht den Kopfmotor (die beiden dafür nötigen Pins /DIR und /STEP wurden ja oben bereits genannt).

    Davon abgesehen ist es eine schöne Präsentation der Platte - vorausgesetzt, man steht auf den Humor der zwei Macher :).


    Und dann bin ich mal PAW s Hinweise zu den Signalen gefolgt, und natürlich war da noch ein Klops in meiner Adaption der Platte: von meinen ersten Versuchen mit dem Oszilloskop waren noch die Pullup - Widerstände an den Ausgängen vorhanden, die gegen 5V geschaltet sind.

    Inzwischen habe ich das alles entfernt und die Signale neu vermessen. Hier die Schreibsignale:


    Interessanterweise ist das Maximum immer noch im Bereich von 3,2V statt 5V. Aber beim Lesen sieht es jetzt anders aus:


    Hier bewegen wir uns jetzt im Pegelbereich des 3.3V-Systems um den Teensy. Die negativen Überschwinger sind hoffentlich nur Messfehler (schlechte Masseverbindung?).


    Das Interessante: Seit der Modifikation sind die Schreibaussetzer weg! Ich habe jetzt bei meinen Tests pro Spur nur noch ein oder zwei Fehler, die auch noch reproduzierbar sind. Da scheint die Platte tatsächlich echte Fehler zu haben - aber zum Glück recht selten.

    Damit konnte ich nun eine Spur formatieren und bis auf einen alle Sektoren wieder lesen. Allerdings musste ich mein Timing noch etwas korrigieren und die Pulse um ein paar Prozent kürzer machen, weil ich sonst mehr als eine Umdrehung brauchte und mit dem letzten Sektor den Anfang des ersten überschrieben habe.


    Nächste Aufgabe: Schreiben einzelner Sektoren - dort muss ich genau den vorbereiteten Bereich treffen und die Daten so schreiben, dass davor und dahinter nichts zerstört wird.

    Ok, da braucht man sich um die Treiber keine Sorgen zu machen. Trotzdem sehen die Schreibsignale etwas grenzwertig aus.


    Hier die Oszillogramme von den Schreib- und Lesesignalen:



    Beim Schreiben habe ich einen Hub von nur 2,7V, vor allem aber einen Low-Pegel von 400mv - das ist schon arg eng, oder?


    Zum Vergleich die korrespondierenden Signale an der Leseleitung:



    Wie man auch sieht, habe ich die 1000ns mit meinem Timing fast genau getroffen; hier sind es 1020ns. An anderer Stelle können es auch mal ein paar Nanosekunden mehr oder weniger sein. Auch beim Lesen haben wir eine Abweichung, die aber ebenfalls leicht variiert.


    Ich hatte tatsächlich auch schon den Verdacht gehabt, dass ich z.B. Pulse mit 1020ns und die Platte in einem festen Raster von z.B. 1040ns schreibt. Dann hätten wir tatsächlich nach einiger Zeit einen so großen Versatz, dass ein Puls verloren geht - u.U. auch mit einer entstehenden Lücke.

    Um das auszuschließen habe ich dann mal bewusst längere Pulse (1050 oder 1100 Nanosekunden) geschrieben - und die Aufzeichnungen auf der Platte wurden dann entsprechend länger. Die oben gezeigten Unterschiede entstehen also eher durch Messungenauigkeiten oder Gleichlaufschwankungen.


    Auf den Verdacht bin ich übrigens gekommen, weil die Platte grundsätzlich - d.h. völlig unabhängig von der Länge des negativen Impulses beim Schreiben - den negativen Impuls immer mit einer Länge von genau 200ns liefert. Da dachte ich, dass vielleicht auch die positiven Impulse über entsprechende Zeitglieder produziert werden. Das ist aber wohl nicht der Fall.

    Hi PAW,


    Ja, die Schreibdaten habe ich mir auch angesehen, die waren OK. Also im Sinne der Vollständigkeit.

    Die Pegel waren etwas schwach (3,xxV) und die Flanken nicht die Schönsten, aber meineserachtens in Ordnung.

    Ich hatte auch schon den Verdacht, dass die Pullups in der Platte etwas zu "rustikal" für die Treiber des FLUXCOPY sein könnten, aber dann müsste das genau auf der Grenze des korrekten liegen, weil ja 99% der Pulse richtig geschrieben werden.


    Mit den Pulsdauern habe ich einiges ausprobiert. Ich habe mit den 200ns angefangen, die ich auch beim Lesen erhalte. Dann habe ich es auch mal mit 50% probiert, und die dritte Variante war 250ns, weil das besser in das Zeitraster passt.

    Ich habe auch mit größeren Abständen experimentiert, also 1250 oder 1500ns. Dabei waren die "Verluste" aber noch viel höher. Die Impulslängen scheinen also in der Plattenelektronik eingebaut zu sein. Genau wie die 200ns - die liefert die Platte immer, egal wie ich geschrieben habe.


    Die besten Ergebnisse habe ich tatsächlich mit den Kombinationen 200ns/300ns, 200ns/550ns und 200ns/800ns.

    Mal ein paar blöde Ideen:

    Ist die Datenmenge/Drehzahl von der Spur abhängig?

    Drehzahl auf keinen Fall, die ist konstant.

    Datenmenge/Datenrate grundsätzlich auch nicht - es sind immer 60 Sektoren, aber tatsächlich hatte ich auf der innersten Spur eine etwas andere Formatierung mit minimalen Änderungen im Verhältnis Nutzdaten zu Synchronisationsdaten.

    Aber das ist quasi eine Schicht höher - meine Fehler liegen in ausbleibenden / überflüssigen Fluxwechseln.


    Gibt es vielleicht Zwischenspuren, die für Positionsdaten und nicht für Daten sind?

    Schreibst du vielleicht in den Nicht-Benutzerbereich?

    So etwas kennt diese Platte nicht. Jedenfalls waren die beiden Spuren, die ich bisher zum Testen genommen habe, vorher normal formatiert und enthielten z. T. auch normale Daten/Programmcode.

    Da war doch was mit einem Pre-Comp beim Schreiben?

    Hatten manche Datenträger nicht eine abweichende SChreib-/Leseposition (irgendwie in die Richtung es wird XXxs vorher geschrieben.

    Ja, da habe ich mir auch Gedanken drüber gemacht. Aber erstens spielt das in der Regel nur bei den inneren Spuren eine Rolle - außen sollte das kein Thema sein. Und ich teste absichtlich auf einer Spur ganz außen und einer ganz innen. Das Problem tritt in beiden Fällen auf.


    Außerdem wird die write precompensation nach meinem Verständnis nur bei speziellen Bitkombinationen benötigt, um zwei dicht aufeinander folgende Fluxwechsel zu entzerren - mal wird dazu etwas früher geschrieben, mal etwas später.


    Bei meinen Versuchen habe ich aber einfach nur in festem Abstand Fluxwechsel geschrieben. Dabei gingen hin und wieder einfach Fluxwechsel verloren - egal ob ich die im Abstand von 500ns oder 1000ns geschrieben habe.


    Ich habe den Verdacht, dass die Schreibverstärker nicht ausreichend starke Signale erzeugen und das entstandene schwache Signal beim Lesen nicht reicht, um bei der folgenden Digitalisierung wieder ein Ausgangssignal zu liefern.


    Georg

    Am Freitag Abend habe ich mir beim Treffen im neuen shack eine spezielle Markierungskarte zurecht geschnitten und markiert. Damit konnte ich dann einen der WANG-Markierungskartenleser neu abgleichen. Diese Karte ermöglicht es mir, sie im Leser präzise unter der Optik zu platzieren, da die Schlitze die Transportgummiwalzen aussparen. :) Sonst müsste ich dazu beide Antriebsmotoren ablöten... ::solder::

    Gute Idee, und eigentlich naheliegend. Muss man trotzdem drauf kommen - ich bin es nicht. :fp:


    Werde ich auch mal ausprobieren, wenn ich den Kartenleser mal wieder auf dem Tisch habe.

    Hier mal wieder ein Update zu meinen Forschungsarbeiten an der Platte.


    Mittlerweile kann ich große Bereiche der Platte lesen. Dabei muss ich aber gelegentlich meine Parameter anpassen, um fehlerfreie Ergebnisse zu erzielen. Manchmal klappt das garnicht, und es bleibt bei CRC-Fehlern im Datenbereich des Sektors.

    Dazu kommt der Eindruck, dass verschiedene Teile der Platte unterschiedlich formatiert sind. Insgesamt sehr seltsam.


    Mittlerweile habe ich auch versucht, die Platte zu beschreiben. Leider habe ich da wenig Erfolg - auf der Platte landet nie genau das, was ich schreibe.


    Ich habe das dann systematisch mit wechselndem Timing und Pulsbreiten durchgetestet und dabei festgestellt, dass im Schnitt alle 120-150 Fluxwechsel einer oder mehrere davon verloren gehen. Das passiert ziemlich sicher beim Schreiben, denn mit dem Oszilloskop kann ich diese Fehler bei wiederholten Lesen jedesmal wiederfinden. Gelegentlich wird an dieser Stelle aber auch eine Folge zu schneller Fluxwechsel gelesen.


    Es wird also irgendetwas geschrieben, das beim Lesen mal mehrere schnelle Fluxwechsel und mal gar keinen Wechsel liefert.


    Trotz aller Bemühungen konnten diese Fehler nicht reduziert werden, weshalb ich jetzt nicht mehr richtig weiter weiß...


    Ein sinnvolles beschreiben der Platte ist jedenfalls aktuell nicht möglich!