Diskette aus alter SUN lesen

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

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.

Zeige mal die ersten 1024 Bytes in HEX.

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 ?

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.

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

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?

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.

Kopiere die Diskette mit dd o.ä. und versuche mal das Backup im 
Zielsystem einzusetzen. Da könnte durchaus noch ein Hacken sein.

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 ?

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.

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.

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.

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.

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?

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?

Mal ne Andere Frage, ist in dem System ein normales PC-Diskettenlaufwerk 
eingebaut ?

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 ?

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:
> 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

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

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.

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

 ;)

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 ?

@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 ?

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 ?

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

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.

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/