Moin, ein Kfz-Testgerät startet sein Betriebssystem noch von Disketten. Die Computer-Hardware ist von SUN. Bei den Disketten handelt es sich um normale 3,5" Disketten mit 720 kB Kapazität. Ziel ist es, Backup-Disketten zu erstellen. Wenn ich mit dd unter Linux die komplette Diskette in eine Datei einlese, scheinen die Daten korrekt anzukommen. Zum Kopieren reicht das. Allerdings kann ich mit dem Dateisystem nichts anfangen. Ich würde es gerne mal mounten, um reinzuschauen. Mit "strings" findet man in dem binären Dump ein paar Informationen: 1OF1MCS D SYS V613(C)1998 SUN ELECTRIC SUN_DIR b,f0553E0456-11 SUN_VOL SYS SUN_DIR SYS SCOPE PROG GERMAN DICT MISCEL PROG APK_SEG1PROG FAT12 oder so ist es nicht, wegen der vier Buchstaben langen Endung. Hat jemand eine Idee, was für ein Format das sein könnte und ob ich das unter Linux mounten kann?
:
Verschoben durch Admin
Angehängte Dateien:
-
sysv.png
48 KB
versuch mal den "SYSV"-Filesystem-Treiber, im Kernel-Config bei den "Miscellaneous filesystems" versteckt... Und ja, Schande über mich, !!Bildformate!!. 50 kb für 7kb Text :)
Suche nach dem simplen DOS-Programm "VGACopy" . Dieses Programm beherrscht zahlreiche Diskettenformate UND zeigte auf dem Monitor fehlerhafte Stellen, die mehrfach gelesen werden mußten in verschiedenen Farben an. So konnte kränkliche Disketten rechtzeitig erkennen, bevor es zu spät war.
Gerhard schrieb: > Wenn ich mit dd unter Linux die komplette Diskette in eine Datei > einlese, scheinen die Daten korrekt anzukommen. Zum Kopieren reicht das. > Allerdings kann ich mit dem Dateisystem nichts anfangen. Ich würde es > gerne mal mounten, um reinzuschauen. Solaris nannte sein Haus-Filesystem ufs. Hervorgegangen ist es aus dem Berkeley FFS. Beide Filesysteme sollte Linux zumindest readonly unterstützen. Wenn du schon ein Image hast, mounte es per loopdevice. XL
Vorsicht, hier geht es nicht um Sun Microsystems (heute Teil von Oracle) http://de.wikipedia.org/wiki/Sun_Microsystems sondern um diese Firma hier: http://sun.snapon-equipment.de/ Ich glaube nicht, dass die beiden irgendwie zusammenhängen. Gerhard schrieb: > SUN_VOL SYS > SUN_DIR SYS > SCOPE PROG > GERMAN DICT > MISCEL PROG > APK_SEG1PROG Das sieht auch überhaupt nicht nach SunOS oder Solaris aus.
Sowohl sysv als auch ufs mit ufstype=sun/sunx86/old funktionieren leider nicht (bad superblock). Trotzdem sieht man eine Dateistruktur auf dem Binärdump. Er ist auch korrekt angekommen, es gab keine Lesefehler. Hat noch jemand Ideen?
Yalu hat recht, es handelt sich um einen Messgerätehersteller, der wohl außer dem ähnlichen Namen nichts mit SUN und dessen unixoiden Betriebssystemen zu tun hat. Aber ob die sich wirklich ein neues Dateisystem und Betriebssystem ausgedacht haben? Die Endung *.SYS erinnert an DOS, *.PROG passt wieder nicht.
dd kann doch byteweise die Sektoren auf eine andere Diskette kopieren dd if=/dev/fd0 of=/dev/fd1
> Hat noch jemand Ideen?
evtl., was sagt ein eg. gparted oder partition-magick dazu?
Gerhard schrieb: > Wenn ich mit dd unter Linux die komplette Diskette in eine Datei > einlese, scheinen die Daten korrekt anzukommen. Zum Kopieren reicht das. > Allerdings kann ich mit dem Dateisystem nichts anfangen. Ich würde es > gerne mal mounten, um reinzuschauen. Mit "strings" findet man in dem > binären Dump ein paar Informationen: > > 1OF1MCS D SYS V613(C)1998 SUN ELECTRIC > SUN_DIR > b,f0553E0456-11 > SUN_VOL SYS > SUN_DIR SYS > SCOPE PROG > GERMAN DICT > MISCEL PROG > APK_SEG1PROG > > FAT12 oder so ist es nicht, wegen der vier Buchstaben langen Endung. Hat > jemand eine Idee, was für ein Format das sein könnte Höchstwahrscheinlich ein proprietäres. Wenn du statt "strings"-Outputs einfach mal einen Hexdump des Sektors geposted hättest, in dem diese Strings lagen, wäre wahrscheinlich schon das halbe Filesystem entzaubert. Höchstwahrscheinlich handelt es sich dabei auch nur um eine modifizierte FAT-Variante. Die gab es zu Dutzenden. FAT ist einfach so primitiv, daß auch minderbegabte Entwickler es gebacken bekommen, den geklauten C-Code einer FAT-Implementierung so zu modifizieren, das was inkompatibles, aber trotzdem noch irgendwie funktionierendes herauskommt.
Diese 8+n-Dateinamen erinnern ja schon ein wenig an das FAT-Dateisystem. Vielleicht haben die Jungs in den Verzeichniseinträgen einfach das Byte mit den Dateiattributen durch ein weiteres Extension-Zeichen ersetzt bzw. das Attributbyte von Offset 0x0b auf den reservierten Platz nach 0x0c verschoben. Versuche doch mal den Bootsektor mit dieser Beschreibung hier zu matchen: http://de.wikipedia.org/wiki/File_Allocation_Table#Bootsektor Falls sich Ähnlichkeiten ergeben, kannst du mit den weiteren Sektortypen fortfahren. Stellt sich am Ende heraus, dass es sich tatsähclich um ein leicht modifiertes FAT-Dateisystem handelt, kannst du ein kleines Tool schreiben, das die Dateiinhalte extrahiert, oder eine bestehende Open-Source-FAT-Software entsprechend modifzieren.
Könnte es sogar noch Pre-DOS sein ? So CP/M o.ä. Wie alt ist das Testgerät ?
Der TE will doch nur Backup-Disketten erstellen. Dazu reicht ein dd.
dd schrieb: > Der TE will doch nur Backup-Disketten erstellen. Dazu reicht ein dd. Die Neugier treibt.
dd schrieb: > Der TE will doch nur Backup-Disketten erstellen. Dazu reicht ein dd. Gerhard schrieb: > Wenn ich mit dd unter Linux die komplette Diskette in eine Datei > einlese, scheinen die Daten korrekt anzukommen. Zum Kopieren reicht das. > Allerdings kann ich mit dem Dateisystem nichts anfangen. Ich würde es > gerne mal mounten, um reinzuschauen.
Dennis Heynlein schrieb: > Könnte es sogar noch Pre-DOS sein ? So CP/M o.ä. Was meinst du, wo Bill Gates abgeschrieben hat? 8+3 war schon zu CP/M Zeiten die Norm. Es gab aber nicht die File Allocation Table sondern den Disk Allocation Vector.
:
Bearbeitet durch User
Lange nicht mehr so etwas beschaeftigt ... Linux-Bordmittel: man tune2fs lshw vol_id parted tune2fs -l /dev/xyz lshw -class xyz vol_id /dev/xyz parted /dev/xyz print all Wird wohl noch mehr geben, in der bash-Wundertuete, have fun.
Danke für eure zahlreichen Ideen, spannende Sache. Wie gesagt, Kopien ziehen ist kein Problem, mich hat jetzt das Interesse gepackt. Interessanterweise stehen am Anfang der Diskette erstmal jede Menge Nullen. Hier der Anfang:
1 | 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
2 | * |
3 | 00002400 31 4f 46 31 4d 43 53 20 44 20 20 20 53 59 53 20 |1OF1MCS D SYS | |
4 | 00002410 56 36 31 33 28 43 29 31 39 39 38 20 53 55 4e 20 |V613(C)1998 SUN | |
5 | 00002420 45 4c 45 43 54 52 49 43 00 53 55 4e 5f 44 49 52 |ELECTRIC.SUN_DIR| |
6 | 00002430 e5 53 00 13 00 01 02 05 00 01 00 00 00 01 03 00 |.S..............| |
7 | 00002440 0e 08 00 62 2c 66 30 35 35 33 45 30 34 35 36 2d |...b,f0553E0456-| |
8 | 00002450 31 31 f0 19 da 01 e8 17 b8 0f 84 01 a2 11 e5 e5 |11..............| |
9 | 00002460 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 e5 |................| |
10 | * |
11 | 00002600 02 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
12 | 00002610 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
13 | * |
14 | 00002800 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 |................| |
15 | * |
16 | 00002880 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
17 | 00002890 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
18 | 000028a0 00 00 80 80 80 80 80 80 80 80 80 80 80 80 80 80 |................| |
19 | 000028b0 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 |................| |
20 | * |
21 | 00002d80 80 80 80 80 00 00 00 00 00 00 00 00 00 00 80 80 |................| |
22 | 00002d90 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 |................| |
23 | * |
24 | 00002e00 ff 85 53 55 4e 5f 56 4f 4c 20 53 59 53 20 00 01 |..SUN_VOL SYS ..| |
25 | 00002e10 02 00 02 02 11 09 00 62 ff 85 53 55 4e 5f 44 49 |.......b..SUN_DI| |
26 | 00002e20 52 20 53 59 53 20 00 0c 02 00 03 09 11 09 00 62 |R SYS .........b| |
27 | 00002e30 ff 14 53 43 4f 50 45 20 20 20 50 52 4f 47 00 d0 |..SCOPE PROG..| |
28 | 00002e40 01 a1 4c 05 11 09 00 62 ff 14 47 45 52 4d 41 4e |..L....b..GERMAN| |
29 | 00002e50 20 20 44 49 43 54 00 c1 01 aa 63 07 11 09 00 62 | DICT....c....b| |
30 | 00002e60 ff 14 4d 49 53 43 45 4c 20 20 50 52 4f 47 00 3c |..MISCEL PROG.<| |
31 | 00002e70 01 9c 79 03 11 09 00 62 ff 14 41 50 4b 5f 53 45 |..y....b..APK_SE| |
32 | 00002e80 47 31 50 52 4f 47 00 1c 00 08 80 01 11 09 00 62 |G1PROG.........b| |
33 | 00002e90 ff 14 41 4e 44 52 4f 53 20 20 50 52 4f 47 00 17 |..ANDROS PROG..| |
34 | 00002ea0 01 16 83 03 11 09 00 62 ff 14 53 50 54 50 52 49 |.......b..SPTPRI| |
35 | 00002eb0 4e 54 50 52 4f 47 00 17 00 64 85 09 11 09 00 62 |NTPROG...d.....b| |
36 | 00002ec0 ff 14 4e 53 54 20 20 20 20 20 50 52 4f 47 00 16 |..NST PROG..| |
37 | 00002ed0 00 8a 88 06 11 09 00 62 ff 14 41 50 4b 5f 53 45 |.......b..APK_SE| |
38 | 00002ee0 47 33 50 52 4f 47 00 15 01 f6 8b 02 11 09 00 62 |G3PROG.........b| |
39 | 00002ef0 ff 14 53 45 4e 53 4f 52 53 20 50 52 4f 47 00 15 |..SENSORS PROG..| |
40 | 00002f00 00 a4 8d 06 11 09 00 62 ff 14 4d 47 41 31 32 30 |.......b..MGA120| |
41 | 00002f10 30 20 50 52 4f 47 00 15 00 8a 90 01 11 09 00 62 |0 PROG.........b| |
42 | 00002f20 ff 14 53 47 41 39 30 30 30 20 50 52 4f 47 00 14 |..SGA9000 PROG..| |
43 | 00002f30 01 ca 92 05 11 09 00 62 ff 14 4e 4f 42 45 4e 43 |.......b..NOBENC| |
44 | 00002f40 48 20 50 52 4f 47 00 14 01 24 94 08 11 09 00 62 |H PROG...$.....b| |
45 | 00002f50 ff 14 53 44 53 5f 34 35 30 20 50 52 4f 47 00 12 |..SDS_450 PROG..| |
46 | 00002f60 00 98 97 02 11 09 00 62 ff 14 43 52 54 20 20 20 |.......b..CRT | |
47 | 00002f70 20 20 50 52 4f 47 00 10 01 ce 99 03 11 09 00 62 | PROG.........b| |
48 | 00002f80 ff 14 56 45 45 20 20 20 20 20 50 52 4f 47 00 0f |..VEE PROG..| |
49 | 00002f90 00 ee 9b 02 11 09 00 62 ff 14 53 44 4c 32 30 20 |.......b..SDL20 | |
50 | 00002fa0 20 20 50 52 4f 47 00 0c 01 9c 04 01 11 09 00 62 | PROG.........b| |
51 | 00002fb0 ff 14 4b 45 59 4d 45 41 20 20 50 52 4f 47 00 09 |..KEYMEA PROG..| |
52 | 00002fc0 00 16 05 05 11 09 00 62 ff 14 41 50 4b 5f 53 45 |.......b..APK_SE| |
53 | 00002fd0 47 32 50 52 4f 47 00 08 01 f0 06 06 11 09 00 62 |G2PROG.........b| |
54 | 00002fe0 ff 14 41 4e 44 52 5f 54 41 42 50 52 4f 47 00 08 |..ANDR_TABPROG..| |
55 | 00002ff0 01 46 07 06 11 09 00 62 ff 14 4b 45 59 4d 43 53 |.F.....b..KEYMCS| |
56 | 00003000 20 20 50 52 4f 47 00 08 00 cc 08 06 11 09 00 62 | PROG.........b| |
57 | 00003010 ff 14 4c 43 4b 30 20 20 20 20 50 52 4f 47 00 08 |..LCK0 PROG..| |
58 | 00003020 00 82 09 06 11 09 00 62 ff 14 50 54 42 20 20 20 |.......b..PTB | |
59 | 00003030 20 20 50 52 4f 47 00 05 00 a4 0d 0a 06 11 09 00 | PROG..........| |
60 | 00003040 62 ff 14 41 50 4b 5f 53 4e 53 52 50 52 4f 47 00 |b..APK_SNSRPROG.| |
61 | 00003050 05 00 6e 0b 03 11 09 00 62 ff 14 41 50 4b 5f 41 |..n.....b..APK_A| |
62 | 00003060 4e 44 52 50 52 4f 47 00 05 00 4e 0b 09 11 09 00 |NDRPROG...N.....| |
63 | 00003070 62 ff 14 42 50 43 20 20 20 20 20 50 52 4f 47 00 |b..BPC PROG.| |
64 | 00003080 04 00 d8 0c 06 11 09 00 62 ff 14 4c 49 4d 5f 56 |........b..LIM_V| |
65 | 00003090 45 43 54 44 41 54 41 00 03 01 3e 0d 02 11 09 00 |ECTDATA...>.....| |
66 | 000030a0 62 ff 14 4c 56 44 30 20 20 20 20 50 52 4f 47 00 |b..LVD0 PROG.| |
67 | 000030b0 03 00 da 0d 06 11 09 00 62 ff 14 57 54 53 30 20 |........b..WTS0 | |
68 | 000030c0 20 20 20 50 52 4f 47 00 02 01 2e 0e 01 11 09 00 | PROG.........| |
69 | 000030d0 62 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |b...............| |
70 | 000030e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
Also wenn es die Firma noch gibt, dann würde ich da mal nachfragen. Am besten in der Personalabteilung, die Dir den Kontakt zu einem Rentner von denen vermitteln können, der das damals verzapft hat :-) :-) Oh, ich sehe gerade: (c)1998 ... Junge, Junge ....
:
Bearbeitet durch User
In einem anderen Forum liest man: "Firma wurde vom Werkzeughersteller SnapOn aufgekauft, kein Interesse mehr am Support für alte Geräte. Unterlagen wurden vernichtet, keine Ersatzdisketten mehr erhältlich." In noch einem anderen Forum liest man: "Das Format der Disketten entspricht einem alten Industriestandard, der nicht mit IBM/PC kompatibel ist. Dies war unter anderem nützlich, um das illegale Kopieren der Disketten zu verhindern." Der Tester war wohl unter dem Namen "Tech-80" eine zeitlang das Standardgerät für Opel-Werkstätten und deshalb weit verbreitet. Kosten lagen damals um 30.000 DM aufwärts.
Format sieht interessant aus. Könnte eine FAT sein. Ein Directory-Eintrag ist 24 bytes lang. Für CP/M fehlt die Liste der Sektoren im Directory-Eintrag. Von den 24 Bytes müßten ein paar die Länge noch anzeigen und den Startsektor.
Gerhard schrieb: > 00003030 20 20 50 52 4f 47 00 05 00 a4 0d 0a 06 11 09 00 | PROG..........| Das 0d-Byte in dieser Zeile ist zuviel. Kann es sein, dass das Floppy-Image einen LF-nach-CR/LF-Konverter durchlief?
Das Image kommt per dd von einer funktionierenden Originaldiskette und wurde nicht (wissentlich) verändert. Ich habe es allerdings noch nicht auf eine andere Diskette kopiert und ausprobiert.
Gerhard schrieb: > Das Image kommt per dd von einer funktionierenden Originaldiskette Einfach nur dd mit if= und of= und ohne weitere Optionen? Wie groß ist das Image? Bei einer 720k-Diskette sollte es exakt 737280 groß ein.
Was ist denn das Ursprungs Filesystem? Wenn man das kennt sollte ein mount kein Problem zu sein.
Kopiere die Diskette mit dd o.ä. und versuche mal das Backup im Zielsystem einzusetzen. Da könnte durchaus noch ein Hacken sein.
So wie ich die Dateinamen interpretiere, ist das 8+4. Also nichts was in CP/M oder DOS reinpasst. Unix ist es auch nicht. Ich hatte man Ende der 80er Jahre eine Art Echzeit-Betriebssystem auf dem 68000 (es war ein Atari-ST). Das nannte sich Mirage und kam aus GB. Und das hatte, soweit ich mich erinnere, auch ein 8+4 Namen im Filesystem. Die Diskette könnte also von so etwas herkommen. Leider gibt das Internet nichts mehr dazu her, war ja noch vor der Web-Zeit.
Würdeste das Image zur Verfügung stellen für nähere Analyse ? Haste Backup auf Zielsystem ausprobiert ? Ist näheres über den Prozessor auf dem Zielsystem bekannt ? Bootet das Zielsystem ohne Diskette ?
Tja... Die beiden Images sind nicht nur unterschiedlich groß, sie sind auch größer als sie sein sollten: Und zwar 742426 und 739776 statt 512x18x80 = 737280. Die überschüssigen Bytes sind auch keine Vielfachen von 18, 80 oder 512. Da scheint wohl wirklich etwas schief gelaufen zu sein. Vielleicht doch der CR+LF-Filter? Eventuell, weil die Dateien per E-Mail verschickt wurden? Könnte man da noch etwas machen? Ich kann dir die Images gerne irgendwo hochladen. Das System selbst bootet nur von Diskette und ein 68k könnte es auch sein. Das kann ich aber noch herausfinden.
Gerhard schrieb: > Vielleicht doch der CR+LF-Filter? Vermutlich. Vom prozentualen Zuwachs der Image-Größe kommt es größenordnungsmäßig hin. > Eventuell, weil die Dateien per E-Mail verschickt wurden? Wenn die Images als gewöhnlicher E-Mail-Text und nicht als Attachment verschickt wurden, kann da sehr gut etwas konvertiert worden sein. > Könnte man da noch etwas machen? Man kann die Konvertierung wieder rückgängig machen, indem man alle CR/LF wieder durch LF ersetzt. Wenn dann die richtige Dateigröße herauskommt, ist das ein Indiz dafür, dass man alles richtig gemacht hat.
Yalu X. schrieb: > Man kann die Konvertierung wieder rückgängig machen, indem man alle > CR/LF wieder durch LF ersetzt. Das wird wohl nicht klappen, denn die Zuordnung LF <-> CR/LF wird nicht eineindeutig sein. Sprich: Wenn vorher wirklich irgendwo ein CRLF-Pärchen auf der Diskette war (z.B. zufällig in den Binärdaten), wirst Du das fälschlicherweise auch konvertieren. Die Wahrscheinlichkeit dafür ist größer als man denkt.
Yalu X. schrieb: >> Eventuell, weil die Dateien per E-Mail verschickt wurden? > > Wenn die Images als gewöhnlicher E-Mail-Text und nicht als Attachment > verschickt wurden, kann da sehr gut etwas konvertiert worden sein. Auch beliebt der Transfer per FTP im Textmodus von einem Linux- auf einen Windows-Rechner. Beim einfachen Kommandozeilen-FTP muß man z.B. erstmal explizit auf Binary-Modus umschalten.
In der Tat könnte genau das die Ursache sein. Oh Mann. Das Auslesen der Disketten war nämlich ein Riesenakt. Irgendwo einen Uralt-Rechner finden, von Knoppix CD booten, und dann eine Möglichkeit finden, die Daten abzuspeichern. Ist ne Weile her, aber wenn ich mich richtig erinnere, ging an der Kiste nichts mit USB und so wurde die Datei per FTP übertragen.
Gerhard schrieb: > Ist ne Weile her, aber wenn ich mich richtig > erinnere, ging an der Kiste nichts mit USB und so wurde die Datei per > FTP übertragen. Dann war ASCII- statt BINARY-Transfer beim FTP eingestellt - eine Falle, in die schon so mancher getappt ist.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Das wird wohl nicht klappen, denn die Zuordnung LF <-> CR/LF wird nicht > eineindeutig sein. Doch, wenn der Konvertierungsalgorithmus wirklich nur die LFs ind CR/LF konvertiert und die CRs unverändert stehen lässt, ist die Konvertierung umkehrbar. > Sprich: Wenn vorher wirklich irgendwo ein CRLF-Pärchen auf der > Diskette war (z.B. zufällig in den Binärdaten), wirst Du das > fälschlicherweise auch konvertieren. Die Konverter wandeln üblicherweise CR LF in CR CR LF um. Dies kann rückgängig gemacht werden, indem man CR LF durch LF ersetzt. Man müsste das mit Gerhards Image einfach mal ausprobieren. Wenn der DOS-Windows-FTP-Client bei der Konvertierung mehr gamacht hat als LF durch CR LF zu ersetzen, erkennt man das mit hoher Wahrscheinlichkeit daran, dass die Größe des Images nach der Konvertierung immer noch nicht stimmt.
Yalu X. schrieb: > Die Konverter wandeln üblicherweise CR LF in CR CR LF um. Ja, das ist korrekt. > Dies kann rückgängig gemacht werden, indem man CR LF durch LF ersetzt. Stimmt, solange man nicht den Fehler macht und die CR einfach "rausschmeisst", müsste das so gehen.
> FTP ASCII- statt BINARY-Transfer ausgewählt
(Wenn er alles gezippt hat VOR dem Transport, dann sind die lästigen CR
dem Zip-File hinzugefügt. Sonst wäre jede einzelne Datei verunstaltet.)
Das Einfachste wäre: nochmals FTP mit den richtigen Einstellungen zu
erledigen statt notfalls mühsam zu versuchen das .zip zu reparieren und
hinterher die Prüfzahlen mit der Quelle zu vergleichen.
oszi40 schrieb: >> FTP ASCII- statt BINARY-Transfer ausgewählt > Das Einfachste wäre: nochmals FTP mit den richtigen Einstellungen zu > erledigen statt notfalls mühsam zu versuchen das .zip zu reparieren und > hinterher die Prüfzahlen mit der Quelle zu vergleichen. Wenn er es als zip-Datei übertragen hätte, wäre diese schon defekt und unzip hätte das gar nicht mehr auspacken können. Da er aber oben einen Hex-Dump der Diskette präsentieren konnte (in welchem das mit dem CRLF aka "0d 0a" aufgefallen ist), hat er die Dumps direkt per FTP übertragen, ohne sie zu vorher zippen.
:
Bearbeitet durch Moderator
Gerhard schrieb: > Interessanterweise stehen am Anfang der Diskette erstmal jede Menge > Nullen. Könnte reservierter Platz für ein Boot-Image sein. 18 Sektoren, das dürfte doch exakt ein Zylinder sein, oder?
Auf der Kiste, von der aus ich die Originaldiskette eingelesen hatte, ist nichts gespeichert, da sie nicht mir gehört und ich sie nur mit Knoppix gestartet hatte. Ich werde also in den nächsten Tagen die Originaldiskette noch einmal einlesen und diesmal wie sonst auch "bin" in den FTP-Client eintippen und den Kram zippen wie vorgeschlagen, damit ich auch die Integrität des Übertragungsweges sicherstellen kann.
Gerhard schrieb: > Ich werde also in den nächsten Tagen die Originaldiskette noch einmal > einlesen Auch da kann es schon Nebenwirkungen geben, weiss ich z.B. von meinen CP/M-Disketten - MSDOS, Windows usw. versuchen erst mal (schon beim Reinschieben), den 1. Sektor zu lesen und daraus den Aufbau der Diskette zu bestimmen, was bei nicht-DOS-Disketten nicht funktionieren kann und zu allen möglichen Fehlern führt, z.B. dass sich das System weigert mit der Diskette irgendetwas anderes anzufangen als sie zu formatieren. Es gab verschiedene Software zum Lesen von Raw-Disketten, besonders für alte CP/M-Systeme, aber die war meistens für DOS geschrieben und funktioniert unter 32bit-Systemen meistens nicht mehr. Also am besten so eine Software auftreiben und auf einem alten System mit einer DOS-Diskette booten und ausführen. Ich habe sowas auch selbst geschrieben für meine CP/M-CNC-Systeme, aber meine Software funktioniert meines Wissens unter Vista, 7 oder 8 auch nicht mehr, da der direkte Zugriff auf den Diskettenkontroller nicht mehr möglich ist. Gruss Reinhard
Reinhard Kern schrieb: > Also am besten so eine Software auftreiben Ja, hat er doch: dd unter Unix tut genau das. Da gibt's extra ein so genanntes raw device dafür. MS-DOS & Co. haben derartige Möglichkeiten leider nie bis zur Betriebssystemebene hochgereicht, weshalb es drei Dutzend Spezialprogramme für den Zweck dann gab.
Es gab auch diesketten mit 128 byte/sektor (sd) die werden gern auf 512 aufgefüllt wenn das prog diese formate nicht kennt ich habe hier ein FS da sind die ersetn 4 sectoren 128 Byte lang während die folgenden eine sectorlänge von 128,512 oder 1024 Byte je sector auffeisen können dies wurde in den ersten 4 sekctoren vermerkt allerdings verwendete diese DOS ()ATARI 8 BIT zunächst nur 5 1/4 zoll disketten. die Standert dir war 8+3 Außerdem gab es b es jedoch zahlreiche exottische abweichende FS um spiele nicht mit DOS kopieren zu können. warum ich das schreibe? weil schon das Auslesen der Sektoren eine Hürde darstellen kann wenn der tatsächliche Sectoraufbau unbekannt ist dann können selbst sectorkopierer wie essie bei ATARI auch gab scheitern. ZB An sectorprüfbits und -checksummen ....... eventuell wäre es leichter das pferd nach bekannten kriterierien .. zu analysieren 8.4 FS welche noch dazu Industriestandard waren wären ein Anhaltspunkt poition von strukturinformationen ebenso. aber offenbar hat man sich ja wenigstens an gängige sectorgrößen gehalten Wie sieht es mit der sectorverkettung aus hat da schon jemand etwas erkannt?
Es gibt wohl auch den Kopierschutztrick, bei dem einzelne Spuren anders formatiert werden als der Rest. Die Floppy-Controller im PC unterstützen das nicht, können diese Disketten also nur lesen, nicht aber formatieren und damit auch nicht beschreiben. Ich bin mal gespannt, ob bei einem 80er-Jahre Testgerät dieser Trick angewendet wurde.
Winfried J. schrieb: > Wie sieht es mit der sectorverkettung aus hat da schon jemand etwas > erkannt? Die Frage hatte ich ganz vergessen, ist halt doch schon lange her. Aber der Hexdump zeigt > 700 Bytes fortlaufend als Directory, mehr als ein 512-Byte-Sektor, die scheinen also nicht verwürfelt zu sein. Es sei denn, nach 512 Byte fehlt ein ganzer Sektor, was wir aber nicht wissen können. Gruss Reinhard
Mal ne Andere Frage, ist in dem System ein normales PC-Diskettenlaufwerk eingebaut ?
Soweit ich weiß, ja. Allerdings eines mit "einfacher Dichte" - 720 kB.
Ja, ein Emulator wäre etwas feines :) Das Gerät wird nämlich in einer Autowerkstatt eingesetzt und dort ist es fettig, staubig und mitunter kalt.
Kann mir jemand den ein-eindeutigen sed-Befehl nennen, um die Images potentiell zu reparieren? Dann müssen wir nicht mehr warten, bis ich die Originaldisketten ein zweites Mal einlesen kann.
Hat es da noch nicht manchen Diskettensatz verrissen ? Ist es dann ein 486er oder ähnliches ? Meldet sich am Anfang nen BIOS ? Und wie ist das ausgegangen mit der kopierten Diskette ? Ging das dann ?
Ich habe bisher noch keine Diskette geschrieben und kann deshalb nichts darüber sagen, ob eine Kopie funktioniert. Das Gerät enthält keinen IBM-kompatiblen PC, es ist glaube ich 68k basiert, ein Bootloader existiert, fordert aber nur die Diskette an. Die Disketten sind in der Tat ein Problem, seit der Hersteller den Support eingestellt hat, häufen sich die Hilferufe in den Foren. Blöd ist besonders, dass regelmäßig ein Diskettenwechsel nötig ist (Motortester vs. AU-Testprogramm).
Gerhard schrieb: > ..., dass regelmäßig ein Diskettenwechsel nötig ist > (Motortester vs. AU-Testprogramm). Ist halt der begrenzte Platz auf diesen 720er Disketten. Ich würde ja sagen, daß OS ist in nem ROM ? Grafisch anspruchsvoll ist das System nicht ? "Am Ende ists nen Atari ST" :)
Die Disketten des Atari ST waren aber bis auf ein paar Bytes im Bootsektor völlig MS-DOS kompatibel. D.h. wenn man MS-DOS formattierte Disketten eingelegt hat, konnte man sie im ST lesen. Umgekehrt musste man erst die o.g. Bytes anpassen. Carsten
Es scheint aber kein exotisches Hardformat (Amiga z.B. 880kB) zu sein. Sonst würde ein PC-Laufwerk streiken. Als Betriebssystem kann ja trotzdem immernoch ein exotisches mc68k-Betriebssystem herhalten. Ich vermute aber immernoch Betriebssystem-Dateien sind mit auf der Diskette (teilweise eventuell).
Gerhard schrieb: > Dann müssen wir nicht mehr warten, bis ich die > Originaldisketten ein zweites Mal einlesen kann. Auf meinen Steuerungen - leider nur dort - läuft ein Service-Programm, das Disketten mit 720 kB dupliziert ohne Rücksicht auf den Inhalt. Ich könnte also Backups erstellen, allerdings fehlen dann womöglich solange die Disketten im Betrieb. Das scheint eh das Hauptproblem zu sein. Gruss Reinhard
Gerhard schrieb: > Kann mir jemand den ein-eindeutigen sed-Befehl nennen, um die Images > potentiell zu reparieren?
1 | sed 's/\r$//' inputfile >outputfile |
ersetzt alle CR/LF durch LF. Sollte die konvertierte Datei (outputfile) um 1 Byte zu lang sein (737281 statt 737280 Bytes), liegt das wahrscheinlich daran, dass bei der FTP-Übertragung am Ende ein CR/LF angehängt wurde, obwohl die Originaldatei nicht mit einem LF endete. In diesem Fall muss von der konvertierten Datei noch das letzte Byte abgeschnitten werden:
1 | head -c -1 outputfile >outputfile2 |
Dennis Heynlein schrieb: > "Am Ende ists nen Atari ST" :) So was ähnliches,aber ein 68k ist da auch drin. Ich kann mich erinnern, Anfang der 90er auch solche Experimente gemacht zu haben, mit genau diesen Testern (MCS 2000 ?). Ich hatte die Disketten seinerzeit mit dem Atari 1050STFM + Bitcoy kopiert => hat ewig gedauert, aber auch funktioniert (Funktionierte auch mit dem bei Bosch verwendeteten OS9,wenn man die Testersignatur am Anfang der Diskette löschte...;-) ). Zu Hause müsste ich solche Disketten noch haben,aber... Gruss aus Beijing Elux
> sed 's/\r$//' inputfile >outputfile
Geht leider nicht, die Ausgabedatei ist dann 9 Bytes zu kurz.
Wahrscheinlich taucht die Folge in der Originaldatei eben auch ein paar
mal "legitim" auf.
Ich habe die Originaldisketten jetzt wieder hier und werde noch einen
Ausleseversuch starten.
Könnte es sein das es HPUX ist? Bei meinen Systemen (dort läuft HP-Basic drauf) sehen die Dateien eben so aus!
Gerhard schrieb: >> sed 's/\r$//' inputfile >outputfile > > Geht leider nicht, die Ausgabedatei ist dann 9 Bytes zu kurz. > Wahrscheinlich taucht die Folge in der Originaldatei eben auch ein paar > mal "legitim" auf. Ja, dann war der Unix-DOS-Konverter in deinem FTP-Client wohl zu intelligent und hat LF nur dann in CR LF umgesetzt, wenn das Zeichen vor dem LF nicht sowieso schon ein CR war. In diesem Fall kann man die Originaldatei leider nicht mehr rekonstruieren. Ich habe mangels eines Windows-PCs die Unix-DOS-Konvertierung des FTP-Clients dadurch simuliert, dass ich eine Binärdatei in den Vim-Editor geladen und sie anschließend mit fileformat=dos wieder gespeichert habe. Vim ersetzt dabei kontextunabhängig jedes LF durch CR LF. Damit hat auch das obige Sed-Skript funktioniert. > Ich habe die Originaldisketten jetzt wieder hier und werde noch einen > Ausleseversuch starten. Das ist wohl die beste (und wahrscheinlich auch einzige) Möglichkeit. Am besten prüfst du nach jedem Übertragungs- und Kopierschritt, ob die Datei noch die richtige Größe hat.
Yalu X. schrieb: > In diesem Fall kann man die > Originaldatei leider nicht mehr rekonstruieren. Doch, indem man sich manuell jedes CR-LF-Paar ansieht. ;-)
So, das Einlesen war erfolgreich. Ich habe es mehrmals probiert - manchmal gab es Lesefehler. Aber ich konnte für jede der beiden Disketten drei Durchläufe ohne Fehler erreichen, und diese waren laut "diff" auch identisch. Die Größe für beide Dateien stimmt jetzt auch. Wer mit den Images spielen will, siehe Anhang. Vielleicht gibt es ja interessante Erkenntnisse. Das Schreiben der Images auf leere Disketten (und das anschließende Verifizieren) hat auch funktioniert. Ob die geklonten Disketten in dem Gerät funktionieren, ist noch eine andere Frage, die noch getestet werden muss. Ich kenne mich leider mit Diskettencontrollern nicht besonders aus. Haben die eine eingebauten Fehlerkorrektur? Wenn ja, heißt das, ein Durchlauf ohne Fehler von "dd" ergibt definitiv korrekte Daten? Oder kann da immer noch ein Kopierschutz mit komischen Sektorformaten dazwischenfunken?
* ohne jetzt einen Disassembler bemüht zu haben: im Zielsystem tickt ein 68000er. Die 68k-typischen Muster (0x4e75 "Nu" => rts etc.) sieht man auf den ersten Blick. * das OS ist VMS oder verwandt (es finden sich Strings wie DCL_COPY, DCL_CREATE, DCL_EXECUTE etc.) * Filesystem?? evtl. ods2/ods5?!? Anlaufpunkte wären da erstmal http://en.wikipedia.org/wiki/Files-11 und evtl. http://www.vms2linux.de/ods5fs.html
Gerhard schrieb: > Ich kenne mich leider mit Diskettencontrollern nicht besonders aus. > Haben die eine eingebauten Fehlerkorrektur? Wenn ja, heißt das, ein > Durchlauf ohne Fehler von "dd" ergibt definitiv korrekte Daten? Fehlerkorrektur haben sie nicht, aber Fehlererkennung per CRC.
Ich bin mal gespannt ob die Kopie im Zielsystem läuft oder sowas kommt: "DISKETTE IM LAUFWERK IST EINE ILLEGALE KOPIE, ABBIRCH ERFORDERLICH" ? ABBIRCH ? Es ist scheinbar wirklich ein mc68000 (IDA hats gesagt).
Mir ist es gelungen, das Dateisystem so weit zu analysieren, dass die Dateinamen, -größen und -inhalte extrahiert werden können (s. Anhang). Was noch fehlt, sind die Dateiattribute und das Änderungsdatum der Dateien. Da auf den Disketten nur zwei verschiedene Kombinationen von Dateiattributen vorkommen (für System- und gewöhnliche Dateien), ist es schwierig herauszufinden, welches Bit bspw. für den Schreibschutz (sofern überhaupt vorhanden) steht. Da alle Dateien auf einer Diskette dasselbe Datum zu haben scheinen, ist es auch schwierig, den verwendeten Datumscode zu ermitteln. Ich werde demnächst noch etwas zum Aufbau des Dateisystems schreiben und ein kleines C-Programm posten, mit dem ich die einzelnen Dateien aus den Images extrahiert habe.
Ich vermute fast, dass es mit den kopierten Disketten zu einem "Abbirch" kommen wird. Die Frage ist nur, ob die Abbruchbedingung innerhalb eines Programms auf der Diskette erzeugt wird (dann wäre der Lösungsweg vorgegeben), oder ob der Bootloader das System anhält und nur den Text von Diskette liest. Allerdings gibt es auch schon Erfolgsmeldungen von einem SD-Card-Emulator. Dazu muss das Image allerdings mit einem speziellen Programm erzeugt werden: http://www.torlus.com/floppy/forum/viewtopic.php?f=2&t=865 @Yalu: Super Arbeit, sehr interessant! Gibt es auch eine Art Bootsektor, oder liest der Bootloader in der Maschine eine bestimmte Datei von der Diskette, um das Betriebssystem zu starten?
Gerhard schrieb: > ...oder liest der Bootloader in der Maschine eine bestimmte Datei von der > Diskette, um das Betriebssystem zu starten? Benötigt man dazu nicht Kenntnis über den Firmwareinhalt?
http://www.torlus.com/floppy/forum/viewtopic.php?p=6014#p6014 I got the image file, and without hesitation i can tell that this is a copy protection. The track 9 side 0 have 16 sectors "mixed" together (the start of the next sector is in the data part of the previous one). This is a common protection used on video game disk (Atari ST...). Some game have up to 255 sectors in one track -> doesn't fit on a normal track if you don't mix them. By this way you cannot copy the floppy disk with an normal computer. tja da ist der gute alte ATARI Kopierschutz. Nachträglich wird ein leerer Track überladen, so das der erste Sector des Tracks nicht mehr gelesen werrden kann. Das programm prüft dann ob es auf dem ersten sector des Tracks eine Fehlermeldung bekommt, wenn nicht ;) Das kann nicht mal VGACOPY Aber wenn du direkt auf den Port schreiben kannst (Biosebene) z.B. mit debug) kannst du einzelne sektoren oder tracks lesen. So kannst du versuchen den überladenen Track zu finden und nach dem Kopieren der Diskette den Track und nur diesen mit zu vielen Sectoren zu überschreiben und so die Fehlermeldung generieren welchen die Kopierschutzroutine erwartet. good luck ach ja den trick hatten sie schon bei den 5 1/4 Disketten der 8 bit Kisten gemacht. Allerdings war das auf dem Atari kein Problem, da man die Diskettencontroller anweisen konnte solche tracks zu erzeugen ;)
:
Bearbeitet durch User
Ich vermute mal, dass irgendwo auf genau dieser Diskette ein Stück Programmcode ist, der folgendes macht:
1 | if (floppy_read_track(9)) |
2 | {
|
3 | printf("Abbirch!"); |
4 | halt_cpu(); |
5 | }
|
:)
So ein Emulator wäre in der Lage sogar so Scherze zu Emulieren. Ein FM-Format-Emulator. Die Frage wäre, kann man ein X-Beliebiges DD-Laufwerk nehmen und den Signalstream von z.B. Spur 9 aufnehmen ?
:
Bearbeitet durch User
@Gerhard: http://info-coach.fr/atari/hardware/interfaces.php Such da mal nach "The BLITZ Cable" :) Ich spekulier ja da mal "Kopieren könnte mit nem Atari ST gehen" Oder eventuell Streamkopie mit einem Mikrocontroller ? Laufwerk1.Read Data -> Laufwerk2.Write Data und Steuerung der Tracks/Write Gate per MikroController ?
:
Bearbeitet durch User
Dennis Heynlein schrieb: > Die Frage wäre, kann man ein X-Beliebiges DD-Laufwerk nehmen und den > Signalstream von z.B. Spur 9 aufnehmen ? Eriwan: im Prinzip ja. Ich hatte mal so eine Einrichtung, aber das war zu DOS-Zeiten, und Teil davon war eine ISA-Einsteckkarte mit einem speziellen, diskret aufgebauten Floppy-Kontroller. Damit konnte man auch Sektoren mit absichtlichen Fehlern Bit für Bit kopieren bzw. den ganzen Track einschliesslich der Lücken, die womöglich Kopierschutz-Informationen enthielten. Selbst wenn man sowas heute noch irgendwo finden würde, könnte man es nirgends mehr einsetzen. Nicht nur die Hardware ist in den Abgründen der Geschichte verschwunden, auch das zugehörige Knowhow. Gruss Reinhard
Reinhard Kern schrieb: > Nicht nur > die Hardware ist in den Abgründen der Geschichte verschwunden, auch das > zugehörige Knowhow. Hä? Du bist doch noch ganz munter! ;-)
Also bei mir steht noch eine Komplette ATARI XE mit XF555 Mit ein paar anpassungen könnte ich so einen Sektorkopierer sogar auf dem Laptop basteln dank ATARIemulator mit Siocopy letzterer ist dazu gedacht mittels RS232 den ATARI SIO BUS zu emuliieren ich hatte sogar mal einen Sectorcopierer und Lauwerksimulator in Quickbasic geschrieben der 8 Pysische Laufwerke am SIO Bus emulierte. Das KNow How lebt noch bei mir. Nur benötige ich es kaum noch . Auch die Grundlagenliteratur steht noch im Regal. Achja die 8 Bit ATARI laufwerke besitzen autonome Controller und es gibt in 8 bit Foren diverse umbauten auf 3 1/2" über HDD bishin zu SDKarten Laufwerken. ;)
wenn interesse besteht hier ist noch das alte KNOHOW zu finden http://info-coach.fr/atari/documents/mydoc/Atari-Copy-Protection.pdf
5.1.1 Number Of Sectors (NOS) Description: The standard Atari FD format uses tracks of 9 sectors each containing data blocks of 512 bytes. However many games use 10 or even 11 sectors per tracks just to pack more data on the diskette. Tracks with 11 sectors push several of the parameters that can be handled by the WD1772 FDC close to their limits. This is especially true considering that a 3% rotation’s speed variation is by definition possible when reading a diskette. These tracks are therefore often referred as “read only” tracks. Tracks with 12 or more sectors clearly indicate that some “tricks” have been used as 12 real sectors won’t fit on a track. Usually these tracks use the Sector within Sector protection. Tracks with less than 9 sectors are not standard and are often combined with sector of size 1024. However alone they are not considered as a protection. Creation: It is quite easy to format a track with a non-standard number of sectors up to 11. This can be done by sending the appropriate data to the FDC using a write-track command. Detection: with a read-address command. Duplication: Can easily be done in software for a number of sectors per track up to 11. Preservation: The preservation file just needs to store the data information for all the sectors of the track using standard read-sector commands. Examples: Computer Hits Volume 2 (Beau-Jolly) uses 11 sectors / track, Theme Park Mystery (Image Works) uses 12 sectors / track.
Ist das Indexloch auf einer Diskette der einzige Anhaltspunkt für eine Komplette Umdrehung einer Diskette ?
noch ein interessantes Tool: ftp://ftp.sac.sk/pub/sac/utildisk/fda61.rar
für die Hardsektorierung,ja sofern es überhaupt ausgelesen wird
Dennis Heynlein schrieb: > Ist das Indexloch auf einer Diskette der einzige Anhaltspunkt für eine > Komplette Umdrehung einer Diskette ? Nein, dafür dient die Indexmarke. Das Indexloch wiederum braucht man für zwei Dinge: damit man beim Formatieren eine Kennung hat, an welcher Stelle man die Indexmarke (und damit die Spuraufzeichnung) beginnt, und damit man beim Suchen nach der Indexmarke merkt, dass diese nicht gefunden werden kann (wenn nämlich das Indexloch während der Suche das zweite Mal vorbeikommt).
Reinhard Kern schrieb: > Eriwan: im Prinzip ja. Ich hatte mal so eine Einrichtung, aber das war > zu DOS-Zeiten, und Teil davon war eine ISA-Einsteckkarte mit einem > speziellen, diskret aufgebauten Floppy-Kontroller. Damit konnte man auch > Sektoren mit absichtlichen Fehlern Bit für Bit kopieren bzw. den ganzen > Track einschliesslich der Lücken, die womöglich > Kopierschutz-Informationen enthielten. Selbst wenn man sowas heute noch > irgendwo finden würde, könnte man es nirgends mehr einsetzen. Nicht nur > die Hardware ist in den Abgründen der Geschichte verschwunden, auch das > zugehörige Knowhow. Mit dem Catweasel gibt es durchaus noch einen recht frei programmierbaren Floppycontroller am Markt, aktuell als MK4plus PCI: http://www.vesalia.de/?V02b0f1254544511765d5e54520a514e01101f0954414752050140090a1e31115579633a223c6373744e03263c2e603c684c111071316c33616e282f6c293d2c63544a444515146358420c4d5d4e1c495f170058625d5041554c407211705c0c5e7264657b6754575 oder http://www.jschoenfeld.de/home/indexde.htm und durchklicken. EDIT: Hab gerade mal auf "Verfügbarkeit" geklickt -- EOL und rot... Ziehe alles zurück und behaupte das Gegenteil... ;-)
:
Bearbeitet durch User
FPGA/CPLD etwas RAM und ein µC ? Es ist ja im Prinzip ja nur ein Aufzeichnung von Bits und der Zeitkomponente. Das erkennen des Index-Loches kann man dann ja als Beginn und Ende der Aufzeichnung nutzen.
So, kleines Update: Die ganz einfach mit "dd" aus dem Image geschriebenen Disketten funktionieren prinzipiell, es gibt keinen "Abbirch". Eine der geschriebenen Disketten bricht mit "Interrupt 09" ab, aber das schiebe ich auf einen Materialfehler oder Toleranzüberschneidungen bei den Laufwerken.
Gerhard schrieb: > So, kleines Update: Die ganz einfach mit "dd" aus dem Image > geschriebenen Disketten funktionieren prinzipiell, es gibt keinen > "Abbirch". > > Eine der geschriebenen Disketten bricht mit "Interrupt 09" ab, aber das > schiebe ich auf einen Materialfehler oder Toleranzüberschneidungen bei > den Laufwerken. Also kein Kopierschutz ? Schau mal hier http://hackaday.com/2013/11/26/raspberry-pi-emulates-an-amiga-500-floppy-drive/
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.