Moin, Habe hier ein Technics Keyboard KN2000 mit IDE Festplatte die mittlerweile komische Geräusche macht. Ein Austausch der Platte wäre also angesagt. Vorher will ich die Daten der Platte aber noch retten. Die Firma die damals den Umbausatz von Floppy auf Festplatte angeboten hat gibt es nicht mehr. http://www.keysoftservice.ch/produkte.htm#Absatz5 Habe schon in Linux ein fdisk -l versucht, da taucht die Platte aber nicht auf. Wenn man GParted aufruft gibt es einen Ein/Ausgabefehler. Was kann ich noch tun um die Daten der Platte zu retten auf eine andere Platte?
:
Verschoben durch User
Tom F. schrieb: > Habe schon in Linux ein fdisk -l versucht, da taucht die Platte aber > nicht auf. > Wenn man GParted aufruft gibt es einen Ein/Ausgabefehler. > > Was kann ich noch tun um die Daten der Platte zu retten auf eine andere > Platte? Möglicherweise ist die Platte ja schlicht nicht partitioniert. Was immer gehen müsste: nach dem Dranstecken müsste ein neues Device auftauchen, das vorher nicht da war: /dev/sda (oder sdb, c, - abhängig davon, wieviele Platten vorher dran waren). Das komplette Device kannst Du nun mit dd auf ein image kopieren: dd if=/dev/sdx of=disk.img Das kopierst Du - andersrum - auf die neue Platte (die idealerweise genauso groß sein sollte wie die alte): dd if=disk.img of=/dev/sdx Aber aufpassen: dd hat nicht umsonst den Spitznamen "Disk Destroyer". Wenn Du die falsche Platte erwischst, ist die anschliessend beim Teufel...
Markus F. schrieb: > Tom F. schrieb: >> Habe schon in Linux ein fdisk -l versucht, da taucht die Platte aber >> nicht auf. >> Wenn man GParted aufruft gibt es einen Ein/Ausgabefehler. >> >> Was kann ich noch tun um die Daten der Platte zu retten auf eine andere >> Platte? > > Möglicherweise ist die Platte ja schlicht nicht partitioniert. > Das wäre fdisk egal denn dazu ist es ja da und irgendeine Geometrie hat sie ja, i/o Fehler ist doch fast immer Hardware. --- @tomfox welche Festplatte an welchem Board oder Controller?
dolli schrieb: > @tomfox welche Festplatte an welchem Board oder Controller? Tom F. schrieb: > ein Technics Keyboard KN2000 Dieses Keyboard ist ein Musikinstrument. So mit schwarzen und weißen Tasten. :-)) Kein Rechner...
npn schrieb: > dolli schrieb: >> @tomfox welche Festplatte an welchem Board oder Controller? > > Tom F. schrieb: >> ein Technics Keyboard KN2000 > > Dieses Keyboard ist ein Musikinstrument. > So mit schwarzen und weißen Tasten. :-)) > Kein Rechner... MäÄäaa und du bist doch ein Kasper ;) http://www.keysoftservice.ch/produkte.htm#Absatz5 Die HDD hat ausgebaut er an seinen Rechner angeschlossen um sie zu clonen. Also Welche Platte an welchen Rechner respektive an welch im Rechner befindliches Controllerboard ....
Danke, dd werd ich heute Abend mal probieren. die alte Platte hat 127 MB. die neue Platte hat 20 GB. wäre das ein Problem ? Kleinere Platten sind ja kaum noch zu bekommen. ich meine mit Knoppix hatte ich die Platte als /dev/sdc schonmal gesehen. Muss nochmal probieren. dolli schrieb: > Also Welche Platte an welchen Rechner respektive an welch im Rechner > befindliches Controllerboard .... ich habe so einen IDE zu USB Adapter,an den habe ich die original Technics Festplatte gehängt, dann diesen Adapter mit USB an meinen Windows Rechner gehängt und mit Knoppix gebootet.
:
Bearbeitet durch User
>> die alte Platte hat 127 MB. Hätte vermutet sie habe einen Hersteller und eine Modellnummer ... Das riecht nach einem Adressierungsproblem die wird wohl nur CHS 'verstehen' während der onimöse Adapter LBA verwendet. >> ich meine mit Knoppix hatte ich die Platte als /dev/sdc schonmal >> gesehen. dmesg sollte darüber auskunft geben.
Markus F. schrieb: > Was immer gehen müsste: nach dem Dranstecken müsste ein neues Device > auftauchen, das vorher nicht da war Am besten sieht man das, indem man das "lsblk" Kommando benutzt:
1 | ~ $lsblk |
2 | NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT |
3 | sda 8:0 0 477G 0 disk |
4 | ├─sda1 8:1 0 100M 0 part |
5 | ├─sda2 8:2 0 128G 0 part |
6 | ├─sda3 8:3 0 100M 0 part /boot |
7 | └─sda4 8:4 0 348.8G 0 part |
8 | ├─alpha-jessie 254:0 0 40G 0 lvm / |
9 | ├─alpha-swap 254:1 0 16G 0 lvm [SWAP] |
10 | ├─alpha-vmware 254:2 0 64G 0 lvm /usr/local/var/vmware |
11 | ├─alpha-mysql 254:3 0 40G 0 lvm /usr/local/mysql |
12 | └─alpha-temp 254:4 0 128G 0 lvm |
13 | sdb 8:16 0 1.8T 0 disk |
14 | ├─sdb1 8:17 0 1000G 0 part |
15 | └─sdb2 8:18 0 863G 0 part |
Details zur Partitionstabelle bzw. Filesystem gibt "blkid":
1 | root@alpha:~# blkid /dev/sdb |
2 | /dev/sdb: PTUUID="b7a6ed24" PTTYPE="dos" |
3 | |
4 | root@alpha:~# blkid /dev/sdb1 |
5 | /dev/sdb1: UUID="77c75293-5d60-4acc-96fa-655f76c20b81" TYPE="xfs" PARTUUID="b7a6ed24-01" |
6 | |
7 | root@alpha:~# blkid /dev/sdb2 |
8 | /dev/sdb2: LABEL="Daten" UUID="7B5F42647B8F9F31" TYPE="ntfs" PARTUUID="b7a6ed24-02" |
So hat meine sdb Platte z.B. eine DOS-Partitionstabelle und die beiden Partitionen sind mit xfs bzw. NTFS formatiert. Wenn du die Platte im laufenden Betrieb ansteckst, z.B. per USB, dann gibt auch "dmesg" einen ganzen Sack nützliche Informationen. Oder gleich ins syslog schauen: "tail -f /var/log/kern.log"
Und bei windows verhält sich das auch so das sie nicht eingebunden wird? >> Technics Festplatte gehängt, dann diesen Adapter mit USB an meinen >> Windows Rechner gehängt und mit Knoppix gebootet.
Wenn du dmesg nach dem Einstecken der Platte Eingibst, solltest du die Platte sehen können (/dev/sdx). Alternativ kannst du aber auch lsusb (falls installiert) benutzen.
Axel S. schrieb: > gibt auch "dmesg" einen ganzen Sack nützliche Informationen. Oder gleich > ins syslog schauen: "tail -f /var/log/kern.log" Knoppix startete gewöhnlich ohne syslogd. Was die aktuell machen weiß ich nicht aber.
Tom F. schrieb: > die alte Platte hat 127 MB. > die neue Platte hat 20 GB. > > wäre das ein Problem ? Ausprobieren. Wenn das Keyboard einigermassen flexibel ist wird es die ersten 127 MB der neuen Platte nutzen und gut ist. Wenn es doof ist wird es darüber stolpern, dass die Platte mehr als 504 MB oder mehr als 8 GB hat. Und wenn es arschig ist, wird es die neue Platte ablehnen weil kein Obstname im ID-String steht.
Tom F. schrieb: > die alte Platte hat 127 MB. > [...] > wäre das ein Problem ? Ja, denn Tom F. schrieb: > ich habe so einen IDE zu USB Adapter diese USB Adapter wollen UDMA mit >=33MHz sprechen, was so alte Festplatten aber nicht können. Diese Dinger kann man daher nur an Mainboard- IDE Steckplätzen betreiben. Das Problem hatte ich hier auch mal. Notfalls alten PC vom ESchrott besorgen und Linux booten.
Jim M. schrieb: > Tom F. schrieb: >> ich habe so einen IDE zu USB Adapter > > diese USB Adapter wollen UDMA mit >=33MHz sprechen, was so alte > Festplatten aber nicht können. Diese Dinger kann man daher nur an > Mainboard- IDE Steckplätzen betreiben. > > Das Problem hatte ich hier auch mal. Notfalls alten PC vom ESchrott > besorgen und Linux booten. Oder ein Knoppix booten, hat der TE ja schon mal gemacht. Damit und mit dd bzw. clonezilla geht das klonen easy.
Ich würde da keine Platte über 2GB nehmen. An USB-Adaptern wird das Umkopieren nicht gehen. Also direkt im Rechner anschließen. Eine Option wäre, anstatt einer HD eine CF-Karte 1-2GB mittels Adapter anzuschließen. Oder so einen Floppy-Adapter nach USB-Stick ( 20EUR) einzusetzen. Wenn deine Daten weg sind, nein ich rede hier nicht weiter ...
Also mit angeschlossenem USB-IDE Adapter bekomme ich die folgenden Antworten: die gesuchte Platte ist sdc knoppix@Microknoppix:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 111,8G 0 disk ├─sda1 8:1 0 100M 0 part ├─sda2 8:2 0 58,5G 0 part └─sda3 8:3 0 53,2G 0 part sdb 8:16 1 59,6G 0 disk ├─sdb1 8:17 1 4,8G 0 part /mnt-system └─sdb2 8:18 1 54,9G 0 part /KNOPPIX-DATA sdc 8:32 0 2T 0 disk sr0 11:0 1 1024M 0 rom zram0 253:0 0 1,5G 0 disk [SWAP] cloop0 240:0 0 9,6G 1 disk /KNOPPIX cloop1 240:1 0 1009,6M 1 disk /KNOPPIX1 knoppix@Microknoppix:~$ blkid /dev/cloop0: UUID="2016-10-22-11-42-58-79" LABEL="KNOPPIX_FS" TYPE="iso9660" /dev/cloop1: UUID="2016-10-22-16-00-20-00" LABEL="KNOPPIX_ADDONS1" TYPE="iso9660" /dev/zram0: UUID="f3545fdf-16fb-44c9-ad3d-b2a85e22e1bf" TYPE="swap" /dev/sda1: LABEL="System Reserved" UUID="D680E88380E86C05" TYPE="ntfs" PARTUUID="d521bdd2-01" /dev/sda2: UUID="A07C29B17C2982E0" TYPE="ntfs" PARTUUID="d521bdd2-02" /dev/sda3: LABEL="Data" UUID="507E17767E1753D6" TYPE="ntfs" PARTUUID="d521bdd2-03" /dev/sdb1: LABEL="KNOPPIX" UUID="169C-7E0D" TYPE="vfat" PARTUUID="14cd64ed-01" /dev/sdb2: LABEL="KNOPPIX-DATA" UUID="1e4ed4b3-581f-41ad-8800-b4c0df4c4a95" TYPE="reiserfs" PARTUUID="14cd64ed-02" knoppix@Microknoppix:~$ dmesg | tail [ 213.485702] sd 3:0:0:0: [sdc] tag#0 Add. Sense: Invalid command operation code [ 213.485706] sd 3:0:0:0: [sdc] tag#0 CDB: Read(16) 88 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 [ 213.485708] blk_update_request: critical target error, dev sdc, sector 0 [ 213.485710] Buffer I/O error on dev sdc, logical block 0, async page read [ 213.486962] sd 3:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 213.486965] sd 3:0:0:0: [sdc] tag#0 Sense Key : Illegal Request [current] [ 213.486968] sd 3:0:0:0: [sdc] tag#0 Add. Sense: Invalid command operation code [ 213.486970] sd 3:0:0:0: [sdc] tag#0 CDB: Read(16) 88 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 [ 213.486973] blk_update_request: critical target error, dev sdc, sector 0 [ 213.486976] Buffer I/O error on dev sdc, logical block 0, async page read habe auch das dd Kommando probiert: dd if=/dev/sdc of=/home/knoppix/output.img & watch --interval=1 "du -h /home/knoppix/output.img" die Datei output.img wird zwar angelegt bleibt aber bei 0 Bytes Was kann ich jetzt tun ? PC mit IDE Motherboard habe ich nicht. Könnte ein PCI Express-IDE Adapter helfen ?
:
Bearbeitet durch User
Tom F. schrieb: > Was kann ich jetzt tun ? > Nichts. >>> Buffer I/O error on dev sdc .... > PC mit IDE Motherboard habe ich nicht. > Könnte ein PCI Express-IDE Adapter helfen ? Probiere es halt weiß doch keiner was du da hast. Deine Platte wird mit <504MB ein ATA o. ATA-1 interface haben, falls bei dem Controller etwas von PIO 0-4 u. DMA 0-2 steht könnte es klappen, die unbekannte Platte ist halt alt und an welchen controller das dran soll nicht bekannt... ---- interesanter wäre es anzuschließen während Knoppix läuft, von Interesse ist dann alles so ab [] new high-speed USB device number ... [] New USB device found, .... da kommen so ein zwei dutzend Meldungen am Stück. usb usb-storage scsi sd
Tom F. schrieb: > Was kann ich jetzt tun ? > > PC mit IDE Motherboard habe ich nicht. Dann besorg dir eines. Es ist immer eine ganz schlechte Idee so alte Hardware mit USB Adaptern anzusprechen. Alternative wäre zu jemandem zu gehen der sowas hat. Alle modernen Möglichkeiten mit irgendwelchen Adapter oder Karten müssen nicht funktionieren. Aber das hast du schon festgestellt. Thomas
Hallo Tom, Tom F. schrieb: > habe auch das dd Kommando probiert: > dd if=/dev/sdc of=/home/knoppix/output.img & watch --interval=1 "du -h > /home/knoppix/output.img" > > die Datei output.img wird zwar angelegt bleibt aber bei 0 Bytes > > Was kann ich jetzt tun ? > > PC mit IDE Motherboard habe ich nicht. > Könnte ein PCI Express-IDE Adapter helfen ? Keine Ahnung! Welches Budget steht Dir zur Verfügung? Ich würde erst einmal eine ähnlich kleine und alte Platte gebraucht kaufen. Mit der solltest Du Deine Rettungsumgebung durchtesten. Wenn Du ddrescue zum Laufen bringst und die smartmontools auch (falls Deine Platte schon SMART spricht), kannst Du als letztes versuchen, Deine Platte zu retten. Der Einsatz von dd für vermutlich defekte Platten ist weitestgehend sinnfrei.
:
Bearbeitet durch User
Peter M. schrieb: > > Wenn Du ddrescue zum Laufen bringst und die smartmontools auch (falls > Deine Platte schon SMART spricht), kannst Du als letztes versuchen, > Deine Platte zu retten. Mit "retten" hat das nichts zu tun. Tom F. schrieb: > [ 213.486965] sd 3:0:0:0: [sdc] tag#0 Sense Key : Illegal Request > [current] > [ 213.486968] sd 3:0:0:0: [sdc] tag#0 Add. Sense: Invalid command > operation code Das ist kein Lesefehler auf der Platte, sondern der USB-Adapter hat einen Zugriff versucht, den die alte Platte noch nicht kennt. Der Kommandosatz von IDE hat sich über die Jahre auch subtil verändert. Die Platte dürfte deutlich älter sein als die USB-Schnittstelle. Direkt an IDE sollte gehen, dann limitiert der Linux-Kernel, was geht und der sollte auch mit so alten Platten noch klar kommen.
Axel S. schrieb: > Der > Kommandosatz von IDE hat sich über die Jahre auch subtil verändert. Die > Platte dürfte deutlich älter sein als die USB-Schnittstelle. Und auch die Spannung am IDE-Port. Der Weg wurde dem TO hier schon mehrfach gezeigt. Scheint aber wieder lernresistent zu sein. Einen alten Rechner oder jemanden zu finden, der einen hat kostet erst mal kein Geld. Peter M. schrieb: > Der Einsatz von dd für vermutlich defekte Platten ist weitestgehend > sinnfrei. Geht aber. Oder ein anderes Tool, welches Sektor-Verarbeitung macht. Früher habe ich das mit HD-Copy (?)gemacht. Hier sollte ein alter Fuchs ran. Falls die Musik doch wichtig ist. michael_ schrieb: > Wenn deine Daten weg sind, nein ich rede hier nicht weiter ... Fortsetzung: Selber Schuld.
Hallo Michael, michael_ schrieb: > Peter M. schrieb: >> Der Einsatz von dd für vermutlich defekte Platten ist weitestgehend >> sinnfrei. > > Geht aber. Eben nicht. Ein kaputter Sektor 0 beendet die Versuche von dd. Schau' Dir mal die Doku von ddrescue an. :) > Oder ein anderes Tool, welches Sektor-Verarbeitung macht. > Früher habe ich das mit HD-Copy (?)gemacht. Viele "Tools" machen Sektor-Verarbeitung - solange die Sektoren lesbar sind! :)
:
Bearbeitet durch User
Peter M. schrieb: > Eben nicht. Ein kaputter Sektor 0 beendet die Versuche von dd. > Schau' Dir mal die Doku von ddrescue an. :) Hast du eine Glaskugel? Woher willst du das wissen? Ansprechbar sollte die HD schon sein. Und falls das so sein sollte, kommen wir hier sowieso nicht weiter. Da hilft dann nur noch eine professionelle Datenrettung.
Hallo michael_ michael_ schrieb: > Peter M. schrieb: >> Eben nicht. Ein kaputter Sektor 0 beendet die Versuche von dd. >> Schau' Dir mal die Doku von ddrescue an. :) > > Hast du eine Glaskugel? Woher willst du das wissen? Warum gibt es ddrescue? > Ansprechbar sollte die HD schon sein. Davon war gar nicht die Rede. Natürlich, wenn die vermutete Defektplatte als Gerät bei Linux nicht auftaucht, hilft aucht ddrescue nicht weiter. > Und falls das so sein sollte, kommen wir hier sowieso nicht weiter. Falls was genauso so sein sollte - die Platte nicht ansprechbar oder ein Abbruch von "dd"? > Da hilft dann nur noch eine professionelle Datenrettung. Wenn "dd" abbricht, was sowieso das falsche Werkzeug für vermutete Defektplatten darstellt, ist das nicht notwendigerweise Anlass für die Beauftragung einer professionellen Datenrettung.
Steinaltes Zeug. Die olle 127MB Platte war noch 5V-TTL. Kann sein daß sie mit dem 3,3V LVTTL nicht zusammenspielt.
Peter M. schrieb: >> Hast du eine Glaskugel? Woher willst du das wissen? > > Warum gibt es ddrescue? Keiner weiß, was mit der Platte wirklich ist. Da muß man das Teil vor sich haben. Darum ging es. Peter M. schrieb: >> Und falls das so sein sollte, kommen wir hier sowieso nicht weiter. > > Falls was genauso so sein sollte - > > die Platte nicht ansprechbar oder ein Abbruch von "dd"? Ersteres.
Tom F. schrieb: > Was kann ich jetzt tun ? Die Platte lesen zu können ist ja bestenfalls die halbe Miete, damit hast du ja noch lange keine passende Ersatzplatte. Da kommt man ev. mit einem anderen Floppy-Emulator weiter, z.B. USB-Stick als Floppy. Ich habe noch einen alten 486er mit IDE in Betrieb, der kann die Platte sicher lesen, wenn sie denn überhaupt PC-konform formatiert ist, weiss man ja nicht. Such dir jemand in der Nähe der noch so alte Hardware hat. Georg
Hallo georg schrieb: > Die Platte lesen zu können ist ja bestenfalls die halbe Miete, damit > hast du ja noch lange keine passende Ersatzplatte. Da kommt man ev. mit CompactFlash-Karten entsprechender Größe, neu mit z.B. 128MB, sind kaufbar. Gut, man benötigt dann halt noch einen Adapter. In Summe dürfte man mit 40€ dabei sein. > Ich habe noch einen alten 486er mit IDE in Betrieb, der kann die Platte > sicher lesen, wenn sie denn überhaupt PC-konform formatiert ist, weiss > man ja nicht. Such dir jemand in der Nähe der noch so alte Hardware hat. Zum Erstellen eines Abbildes ist die Formatierung wurscht. MfG
Hallo, Tom F. schrieb: > die alte Platte hat 127 MB. > die neue Platte hat 20 GB. > > wäre das ein Problem ? Es wird ein Problem. Ich glaube nicht, daß das Keyboard schonmal was von LBA48 gehört hat. Damit ist vermutlich bei 512MB Schluß mit lustig. Schau Dich als Ersatz mal nach kleinen CF-Cards um: https://www.ebay.de/sch/i.html?_odkw=hdd+200mb&ul_noapp=true&_osacat=0&_from=R40&_trksid=m570.l1313&_nkw=cf-card+128MB&_sacat=0 Dazu den passenden Adapter suchen: https://www.ebay.de/sch/i.html?_odkw=cf-card+128MB&_osacat=0&_from=R40&_trksid=m570.l1313&_nkw=cf-card+ide+adpapter&_sacat=0 Das removable-Bit der CF-Card wird das Keyboard kaum abfragen und sich somit auch nicht daran stören. PS: da war jemand schneller... Gruß aus Berlin Michael
:
Bearbeitet durch User
Als Ergänzung: CF-Cards verwenden die IDE-Schnittstelle, nur der Stecker ist anders. Alte CF-Cards geringer Kapazität sind also per Adapter mit alten Rechnern gut verträglich.
Michael U. schrieb: >> >> wäre das ein Problem ? > > Es wird ein Problem. Ich glaube nicht, daß das Keyboard schonmal was von > LBA48 gehört hat. Damit ist vermutlich bei 512MB Schluß mit lustig. > Das ist doch kein problem der Rest bleibt eben ungenutzt und? "War noch in den erst Serien 85MB Festplatten eingebaut, müssen heute (es gibt immer noch KN2000 Kunden, die sich das gute alte KN2000 erweitern lassen) 1GB Festplatten eingebaut werden. " Da ginge noch viel mehr, denn die Elektronik die darauf speichert ist ja nicht an die limits z.B. des IMB-PC 1024×16×63 gebunden. The earlier IDE standard from Western Digital introduced 22-bit LBA; in 1994, the ATA-1 standard allowed for 28 bit addresses in both LBA and CHS modes. The CHS scheme used 16 bits for cylinder, 4 bits for head and 8 bits for sector, counting sectors from 1 to 255. This means the reported number of heads never exceeds 16 (0–15), the number of sectors can be 255 (1–255; though 63 is often the largest used) and the number of cylinders can be as large as 65,536 (0–65535), limiting disk size to 128 GiB (≈137.4 GB), assuming 512 byte sectors. Nein 137GB gabs damals noch nicht :)
M.M.M schrieb: > CompactFlash-Karten entsprechender Größe, neu mit z.B. 128MB, sind > kaufbar. > Gut, man benötigt dann halt noch einen Adapter. In Summe dürfte man mit > 40€ dabei sein. Sind 95 Cent zu teuer? https://www.pollin.de/p/diskonmodule-pqi-ide-128-mb-701790
Michael U. schrieb: > Es wird ein Problem. Ich glaube nicht, daß das Keyboard schonmal was von > LBA48 gehört hat. Damit ist vermutlich bei 512MB Schluß mit lustig. LBA48 wird erst bei Festplatten > 128 GiB (137 GB) nötig. Das ist also nicht das Problem. Aber LBA an sich, das nämlich wurde in der vorderen Altsteinzeit nicht verwendet, da gab es nur CHS-Mappings.
Eine andere Frage ist noch, was können die dazugehörigen Editor-/Backup-Programme? Ganz hilfreich für die älteren Sachen übertragen war u.a. http://www.winimage.com/winimage.htm (außerdem gibt es noch in einem entsprechenden floppyemulatorforum ganz gute Hinweise: https://torlus.com/floppy/forum/viewtopic.php?t=1175 )
Hallo, Rufus Τ. F. schrieb: > LBA48 wird erst bei Festplatten > 128 GiB (137 GB) nötig. Das ist also > nicht das Problem. stimmt. Ist wohl doch schon zulange her... PS: CF-Cards mit 8MB, 128MB, 256MB und 512MB liegen hier noch sinnlos raum, ein CF-Card auf IDE Adapter auch. Die Karten sollten alle noch ok sein, aber wie kommt das jetzt zu ihm? Gruß aus Berlin Michael
Danke für die vielen Antworten also Festplatte ist -wie auf dem Foto zu sehen- eine Seagate ST9145AG. Die Festplatte hat vor dem Ausbau aus dem Keyboard letzte Woche noch funktioniert, also sollte sie ja lesbar sein. Ok, dann werde ich mich mal auf die Suche nach einem etwas älteren IDE PC machen. Das mit dem CF Card Adapter werde ich auf jeden Fall probieren, denn ich habe hier noch eine 128MB rumliegen. Danke an Michael U. für das Angebot, werde ich im Hinterkopf behalten. Floppyemulator wäre auch interessant, allerdings wurde das Keyboard ja 1995 von Floppy auf Festplatte umgebaut. Weis nicht was da Interfacetechnisch aus-/umgebaut wurde, muss mal schauen. Werde weiter berichten. P.S. Warum sieht man in der Vorschau nicht die angehängten Bilder ?
michael_ schrieb: > Peter M. schrieb: >>> Hast du eine Glaskugel? Woher willst du das wissen? >> >> Warum gibt es ddrescue? > > Keiner weiß, was mit der Platte wirklich ist. Dazu hat sich Tom geäußert, sie wird als Gerät unter Linux erkannt. Tom schrieb: 1. dass die Platte komische Geräusche macht 2. dass die Platte bei ihm als sdc gelistet wird. Der erste Punkt ist Grund genug, auf überflüssige Zugriffe auf die Platte zu verzichten. Deine Nennung von Tools, die mit defekten Sektoren nicht zurecht kommen zeigt, dass Du bisher mit defekten Sektoren keinerlei Erfahrung hattest.
Tom F. schrieb: > allerdings wurde das Keyboard ja > 1995 von Floppy auf Festplatte umgebaut. So einen Floppy Emulator habe ich auch drin. Ist nicht schlecht. Kann bis zu 999 "Floppys" verwalten, was gut Ordnung schafft. Wegen des Problems an sich kannst du mal im Technics-Forum fragen. www.technics-forum.de
Ich glaube ja das viele hier die Komplexität des Vorhabens unterschätzen. Die Platte wird sehr wahrscheinlich mit CHS Adressierung angesprochen was aber auch bedeutet, dass man die Parameter kennen muss, mit denen die Platte im Keyboard angesteuert wird. Diese muss man kennen um an einem PC dann im BIOS die entsprechenden Einstellungen vorzunehmen. Nur dann wird eine Datensicherung erfolgreich sein. Es ist deshalb vollkommen aussichtslos mit irgend welchen Adaptern unter USB zu arbeiten. Erst wenn diese Hürde genommen ist kann man sich Gedanken darüber machen, wie man das Image dann auf einen neuen Datenträger bekommt. Thomas
Thomas schrieb: > Ich glaube ja das viele hier die Komplexität des Vorhabens > unterschätzen. Die Platte wird sehr wahrscheinlich mit CHS Adressierung > angesprochen was aber auch bedeutet, dass man die Parameter kennen muss Aha. Sieh dir doch das Bild zum Beitrag "Re: Technics Keyboard Festplatte klonen geht das ?" nochmal an. Wo ist nochmal das Problem?
Thomas schrieb: > Die Platte wird sehr wahrscheinlich mit CHS Adressierung > angesprochen was aber auch bedeutet, dass man die Parameter kennen muss, > mit denen die Platte im Keyboard angesteuert wird. Diese muss man kennen > um an einem PC dann im BIOS die entsprechenden Einstellungen > vorzunehmen. Nur dann wird eine Datensicherung erfolgreich sein. Das muss nicht unbedingt sein. Viele BIOSse machen das automatisch und übersetzen das nach LBA. Versuchen kann man das auf alle Fälle. > Es ist deshalb vollkommen aussichtslos mit irgend welchen Adaptern unter > USB zu arbeiten. Da hast Du recht. Das geht nur an einem Motherboard direkt.
Tom F. schrieb: > Ok, dann werde ich mich mal auf die Suche nach einem etwas älteren IDE > PC machen. Welches Budget steht Dir zur Verfügung? Axel S. schrieb: > Peter M. schrieb: >> >> Wenn Du ddrescue zum Laufen bringst und die smartmontools auch (falls >> Deine Platte schon SMART spricht), kannst Du als letztes versuchen, >> Deine Platte zu retten. > > Mit "retten" hat das nichts zu tun. Ich habe das Rettung genannt, weil Tom ganz oben schrieb: Tom F. schrieb: > Habe hier ein Technics Keyboard KN2000 mit IDE Festplatte die > mittlerweile komische Geräusche macht.
Peter M. schrieb: > Deine Nennung von Tools, die mit defekten Sektoren nicht zurecht kommen > zeigt, dass Du bisher mit defekten Sektoren keinerlei Erfahrung hattest. Ich hab da keine genannt! Und du mußt mal deine Glaskugel putzen.
Peter M. schrieb: > Ich habe das Rettung genannt, weil Tom ganz oben schrieb: > > Tom F. schrieb: >> Habe hier ein Technics Keyboard KN2000 mit IDE Festplatte die >> mittlerweile komische Geräusche macht. Ja mai die eiern halt so vor sich hin. hier gibts auch grad Geräusche welche man zwanzig Jahre lang nicht mehr gehört hat. Western Digital WDAC140 1991 Ausserdienststellung 1993 ;) ----- hdparm -i /dev/hdb /dev/hda /dev/hdb: Model=WDC AC140, FwRev=2.62, SerialNo=WD2254824 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq } RawCHS=980/5/17, TrkSize=9656, SectSize=568, ECCbytes=4 BuffType=DualPortCache, BuffSize=7kB, MaxMultSect=0 (maybe): CurCHS=0/0/0, CurSects=0, LBA=no IORDY=no PIO modes: pio0 AdvancedPM=no * signifies the current active mode läuft problemlos an einem Kabel zusammen mit /dev/hda: Model=Maxtor 32049H2, FwRev=YAH814Y0, SerialNo=L202TE3C Config={ Fixed } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=40021632 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 udma3 *udma4 udma5 AdvancedPM=yes: disabled (255) WriteCache=enabled Drive conforms to: ATA/ATAPI-6 T13 1410D revision 0: ATA/ATAPI-1,2,3,4,5,6 * signifies the current active mode ----- lspci|grep -i ide 00:04.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 10) ----- ./dmidecode # dmidecode 2.9 SMBIOS 2.3 present. 49 structures occupying 1378 bytes. Table at 0x000F2940. Handle 0x0000, DMI type 0, 20 bytes BIOS Information Vendor: Award Software, Inc. Version: ASUS A7V ACPI BIOS Revision 1011 Release Date: 04/23/2002 ..... ..... ----- df -h /dev/hdb1 Filesystem Size Used Avail Use% Mounted on /dev/hdb1 41M 200K 41M 1% /mnt/hdb1 ----- ls -n /mnt/hdb1 total 200 -rwxr-xr-x 1 0 0 57351 1993-09-30 05:20 command.com* -r-xr-xr-x 1 0 0 64246 1993-09-30 05:20 dblspace.bin* -r-xr-xr-x 1 0 0 40847 1993-09-30 05:20 io.sys* -r-xr-xr-x 1 0 0 38186 1993-09-30 05:20 msdos.sys* Was interessant ist das beide an ide0 hängen, pio-0 u. udma4 das muss nicht zwingend funktionieren. --- Wenn der Rechner weder zu Neu noch zu Alt ist sollte sich das bewerkstelligen lassen. Egal jetzt wieder in die Kiste :) Die sind wirklich laut.
Hallo michael_ michael_ schrieb: > Peter M. schrieb: >> Deine Nennung von Tools, die mit defekten Sektoren nicht zurecht kommen >> zeigt, dass Du bisher mit defekten Sektoren keinerlei Erfahrung hattest. > > Ich hab da keine genannt! > Und du mußt mal deine Glaskugel putzen. Du schriebst: michael_ schrieb: > Peter M. schrieb: >> Der Einsatz von dd für vermutlich defekte Platten ist weitestgehend >> sinnfrei. > > Geht aber. > Oder ein anderes Tool, welches Sektor-Verarbeitung macht. > Früher habe ich das mit HD-Copy (?)gemacht. Wie Adenauer schon sagte: "Was stört mich mein Geschwätz von gestern!" Gruß Peter
Tom F. schrieb: > Danke, > > dd werd ich heute Abend mal probieren. > > die alte Platte hat 127 MB. > die neue Platte hat 20 GB. > > wäre das ein Problem ? > Kleinere Platten sind ja kaum noch zu bekommen. Wenn es auch Solid State sein darf, dann hat Pollin da gerade was billiges: https://www.pollin.de/p/diskonmodule-pqi-ide-128-mb-701790 Für weniger als einen Euro kann man da eigentlich nicht viel falsch machen (und sich auch gleich noch ein paar als Reserve hinlegen ...). DiskOnModule PQI, IDE, 128 MB Disk on Modul (DOM) zum direkten Betrieb am IDE-Port. Ideal für Rechner mit schlanken Betriebssystemen, wie Server, Router, Car-PCs, Industrie-PCs, Homeserver usw. Das Speichermodul ist sehr robust und eignet sich auch für raue Betriebsumgebungen. Lieferung ohne Stromkabel. Technische Daten: IDE-Port Betriebsspannung: 5 V- Stromaufnahme: max. 20 mA 128 MB NAND Flash Schreib-/Lesegeschwindigkeit: 5,4/6,7 MB/s Betriebstemperatur: 0...+70 °C
Ralf D. schrieb: > Ideal für Rechner > mit schlanken Betriebssystemen Bei 128 MB (nicht GB!!!) kommt da wohl nur MSDOS in Frage.Selbst mein ururalter Win2000-Server belegt schon 5 GB. Georg
offtopic georg schrieb: > > Bei 128 MB (nicht GB!!!) kommt da wohl nur MSDOS in Frage. Weshalb nur? z.B. was vorgefertigtes: https://distro.ibiblio.org/tinycorelinux/welcome.html TinyCore becomes simply an example of what the Core Project can produce, an 16MB FLTK/FLWM desktop. ----
georg schrieb: > Bei 128 MB (nicht GB!!!) kommt da wohl nur MSDOS in Frage.Selbst mein > ururalter Win2000-Server belegt schon 5 GB. Nö. Es gibt viele OS, die man in 128MB locker unterbringen kann. Die eierlegenden Wollmilchsäue aktueller Inkarnationen bekannter DAU-tauglicher OS natürlich nicht. Die beschäftigen, grob geschätzt, 90% ihres Codes allein damit, alle denkbaren Fehleingaben des DAU abzuwehren. Und sind dabei lustigerweise nichtmal wirklich erfolgreich (Komplexitätsproblem). Irgendein Super-DAU findet doch immer noch eine Möglichkeit, etwas zu tun, was so nicht vorgesehen war... OK, das war sicher etwas übertrieben. Aber wer selber entwickelt, weiß: es war nicht sehr übertrieben...
Axel S. schrieb: > Aha. Sieh dir doch das Bild zum Beitrag "Re: Technics Keyboard > Festplatte klonen geht das ?" > > nochmal an. Wo ist nochmal das Problem? Du bist vermutlich einfach zu jung um das Problem zu verstehen. Die Parameter auf der Platte sind erst Mal nur eine Empfehlung wie man die Platte ansprechen kann. Niemand hier kennt die Parameter wie die Platte im Keyboard angesprochen wird. Ohne diese Parameter vom BIOS bleibt aber nur die Option eine Sektor basierende Kopie zu ziehen. Eine solche Kopie wird aber im Zielsystem nur funktionieren, wenn das Ziellaufwerk die gleichen Parameter benutzt. Dies ist aber ausdrücklich nicht das Ziel des TOs. In allen anderen Fällen ist es deshalb hilfreich die Parameter zu kennen, weil dann ein beliebiges Sicherungsprogramm zum ziehen des Images verwendet werden kann. Solche Images können dann auch auf Laufwerken mit abweichenden Parametern verwendet werden. Thomas
Ralf D. schrieb: > Wenn es auch Solid State sein darf, dann hat Pollin da gerade was > billiges: > https://www.pollin.de/p/diskonmodule-pqi-ide-128-mb-701790 Von der Größe passt es zum TO. Ich habe da auch mehrere. Eines für den alten EPROM-Programmer ELV. Aber erst mal muß der TO seine Daten sichern.
Thomas schrieb: > Axel S. schrieb: >> Aha. Sieh dir doch das Bild zum Beitrag "Re: Technics Keyboard >> Festplatte klonen geht das ?" >> >> nochmal an. Wo ist nochmal das Problem? > > Du bist vermutlich einfach zu jung um das Problem zu verstehen. > Die Parameter auf der Platte sind erst Mal nur eine Empfehlung wie man > die Platte ansprechen kann. Niemand hier kennt die Parameter wie die > Platte im Keyboard angesprochen wird. Ohne diese Parameter vom BIOS > bleibt aber nur die Option eine Sektor basierende Kopie zu ziehen. > Eine solche Kopie wird aber im Zielsystem nur funktionieren, wenn das > Ziellaufwerk die gleichen Parameter benutzt. Dies ist aber ausdrücklich > nicht das Ziel des TOs. Die Platte ist noch nicht so alt. Die Parameter stehen da schon im dazugehörigen Register und müssen nur ausgelesen werden. Das was du beschreibst war für die nackten ST506 Platten nötig.
Hallo! Beim HxC2001 steht das Keyboard in der Kompatibilitätsliste. https://hxc2001.com/download/floppy_drive_emulator/support.htm Ist zwar nicht das, was der TO sucht - aber ein Denkanstoss, ohne Festplatte auszukommen.
So, habe nun von der Festplatte mittels 44/40 Pin-Adapter und IDE-fähigem PC ein Image gemacht. knoppix@Microknoppix:~$ dd if=/dev/sdb of=/media/sda5/output2.img 249900+0 Datensätze ein 249900+0 Datensätze aus 127948800 bytes (128 MB, 122 MiB) copied, 135,234 s, 946 kB/s Danach die neuere Platte(20GB) angeschlossen und das Image zurückgespielt. Das selbe Image habe ich dann auch noch auf das DiskOnModule(128MB) zurückgespielt. Scheint geklappt zu haben, das dd Kommando lieferte folgenden output: knoppix@Microknoppix:~$ dd if=/media/sda5/output2.img of=/dev/sdb 249900+0 Datensätze ein 249900+0 Datensätze aus 127948800 bytes (128 MB, 122 MiB) copied, 50,4427 s, 2,5 MB/s Danach die geklonte Platte an das Keyboard angeschlossen und "Juhu" die Lieder werden alle in der Übersicht angezeigt. Doch leider zu früh gefreut. Denn wenn man nun versucht ein Lied zu laden nachdem man es ausgewählt hat, hängt das Keyboard in der Laderoutine fest. Allerdings das Speichern neuer Lieder klappt. Diese können dann auch wieder geladen werden. Da scheint wohl doch etwas mit der Formatierung noch nicht so ganz zu stimmen. Kann man aus so einem Imagefile irgendetwas herauslesen ? Was könnte ich noch probieren ?
:
Bearbeitet durch User
Tom F. schrieb: > Doch leider zu früh gefreut. > Denn wenn man nun versucht ein Lied zu laden nachdem man es ausgewählt > hat, > hängt das Keyboard in der Laderoutine fest. Vermutlich haben deine Lieder defekte Teile. Vielleicht kannst du die ext. reparieren.
> > Was könnte ich noch probieren ? Mal das Image untersuchen ob es sich um etwas bekanntes handelt. Evtl. kannst du es ja sogar mounten. blkid -o value -s TYPE xxx.img disktype xxx.img http://disktype.sourceforge.net/ Evtl. kann auch ein 'testdisk' damit umgehen.
> hängt das Keyboard in der Laderoutine fest. Dann würde ich mal nachsehen ob die alte HD die gleichen Fehler zeigt. Evtl. war das Original schon krank an dieser Stelle? Tom F. schrieb: > Kann man aus so einem Imagefile irgendetwas herauslesen ? Mal ganz einfach 2 Images vergleichen? Lesefehler? Hash MD5=? Sektoren einzeln ansehen ist mühsam. In ungünstigen Fällen könnte natürlich Dein PC irgendwas auf die Original-HD geschrienem haben? Das wäre schlecht.
> Evtl. war das Original schon krank an dieser Stelle?
Mit der originalen Festplatte werden die Lieder einwandfrei geladen.
:
Bearbeitet durch User
oszi40 schrieb: >> hängt das Keyboard in der Laderoutine fest. > > Dann würde ich mal nachsehen ob die alte HD die gleichen Fehler zeigt. > Evtl. war das Original schon krank an dieser Stelle? Vermutlich.
Tom F. schrieb: > Mit der originalen Festplatte werden die Lieder einwandfrei geladen. Einen Diskeditor suchen und die Sektoren am Anfang vergleichen? Die von Format erzeugte Zufallszahl wurde z.B. manchmal als Kopierschutz mißbraucht. Wenn man sie berichtigt, gibt es allerdings beim kopieren Erkennungsprobleme, da der PC 2 "gleiche" HDs sieht.
oszi40 schrieb: > Einen Diskeditor suchen und die Sektoren am Anfang vergleichen? Die von > Format erzeugte Zufallszahl wurde z.B. manchmal als Kopierschutz > mißbraucht. dd kopiert 1:1 auch die UUID
Ich habe erst in der letzten c't von Kryoflux gelesen, einem Floppy/USB-Interface das viele antike Formate lesen kann, u.a. "Emulator". Aber Technics finde ich nicht auf der Liste: https://kryoflux.com Mich wundert etwas, dass man damit über den normalen Shugart-Bus sogar Apple II Disketten lesen kann. Ich dachte deren Frequenzbereich des Leseverstärkers ist nicht kompatibel zu normalen Laufwerken, die brauchen auch niedrigere Frequenzen. So war es jedenfalls damals in einer Umbauanleitung zu BASF-Floppylaufwerken zu lesen. Man musste den Leseverstärker mit geänderten Koppelkondensatoren oder so ähnlich abändern.
Christoph db1uq K. schrieb: > Mich wundert etwas, dass man damit über den normalen Shugart-Bus sogar > Apple II Disketten lesen kann. Ich dachte deren Frequenzbereich des > Leseverstärkers ist nicht kompatibel zu normalen Laufwerken, die > brauchen auch niedrigere Frequenzen. So war es jedenfalls damals in > einer Umbauanleitung zu BASF-Floppylaufwerken zu lesen. Man musste den > Leseverstärker mit geänderten Koppelkondensatoren oder so ähnlich > abändern. Daran hat sich bis heute nichts geändert. Kryoflux nimmt halt die Pulse entgegen, die aus der ReadData-Leitung des Laufwerks rauskommen, misst deren Abstände und reicht das an die PC-SW weiter. Hat hier im Forum auch schon jemand mit einem Atmega gemacht. Das Laufwerk selber muss man entweder für die physischen Eigenschaften des Datenträgers tauglich machen, oder halt die Effekte in Software kompensieren. Apple II-Disketten archiviere ich mit einem Apple II und ADT.
Ach ja... Nostalgie pur... damals... http://retrocmp.de/fdd/basf/b6106_i.htm das war es, NUR 390DM, die von Teac kosteten das doppelte. aus dem englischen Manual dieser Blockschaltplan, mit Leseverstärker MC3470 https://www.alldatasheet.com/datasheet-pdf/pdf/115950/TI/MC3470.html
Tom F. schrieb: > Was könnte ich noch probieren ? Von wievielen Dateien sprechen wir? Bei ein paar Dutzend würde ich stumpf jedes einzelne Lied laden und neu abspeichern.
Tom F. schrieb: > Da scheint wohl doch etwas mit der Formatierung noch nicht so ganz zu > stimmen. > > Kann man aus so einem Imagefile irgendetwas herauslesen ? > > Was könnte ich noch probieren ? Nun wie ja schon Mal angemerkt hatte, ist dd als reiner Sektor Kopierer vermutlich einfach ungeeignet um ein Image für ein Laufwerk mit abweichenden Parametern zu erzeugen. Aber dass wissen hier ja alle besser. Ich würde es mal mit einer primären FAT 16 Partition mit 128.MB probieren und dann mit copy Die Files aus der Quelle auf die neue primäre Partition kopieren. Ich glaube nicht dass das Keyboard mit FAT32 umgehen kann. Falls das funktioniert kannst du dann immer noch probieren die Partition zu vergrößern. Thomas
Alternativ kannst du auch Mal probieren die Partition auf dem Ziellaufwerk mit dem DOS Format Befehl zu formatieren und dann die Files von der Quelle kopieren. Vielleicht reicht das ja schon. Thomas
Ohje, ich rede von Floppies und hier geht es um Harddisks - aber das geht ja schon weiter oben etwas durcheinander. Auf dem Foto ist die Beschriftung gut zu lesen, Seagate hat löblicherweise noch das Handbuch zum Download: https://www.seagate.com/support/disc/manuals/ata/9235pmb.pdf ST9235 Family Product Manual ST9080A, ST9145A,ST9145AG ST9235A, ST9235AG AT Interface Drives 36206-001, Rev. B 19 April 1993 ATA interface The ST9235 family drives use the industry-standard ATA task file inter- face. The drives support both 8-bit and 16-bit data transfers and have no DMA capability. All data transfers are done through programmed I/O. Refer to the Seagate ATA Interface Specification, publication number 36111-001 Also echte PC-Steinzeit
:
Bearbeitet durch User
Hallo Thomas schrieb: > Alternativ kannst du auch Mal probieren die Partition auf dem > Ziellaufwerk mit dem DOS Format Befehl zu formatieren und dann die > Files von der Quelle kopieren. > Vielleicht reicht das ja schon. Statt rumzuprobieren bietet es sich an. aus dem eh schon vorhandenen Image relevante Informationen auszulesen. Sofern es sich nicht um eine vom Hersteller selbstgefrickelte Formatierung handelt, sollte man nach Analyse des 1. Sektors schlauer sein. MfG
Ralf D. schrieb: > Für weniger als einen Euro kann man da eigentlich nicht viel falsch > machen (und sich auch gleich noch ein paar als Reserve hinlegen ...). Ja, leider sind sie für genau den Zweck des TO oft nicht gebrauchsfähig, weil zuviele Musikgerätehersteller ihr eigenes Gedöhns verwenden, um Daten zu speichern. Daher funktionieren die Dinger gerne an allerlei IDE-Controllern in PCs, nicht aber dort, wo man es gerne hätte. Ich habe mehrere Geräte der 90er versucht, damit umzurüsten und plug an play ging bei den Wenigsten: http://www.studio96.de/artikel/art031132%20roland%20va-76%20arranger.html
Wenn die vorhandene Platte per C-H-S angesprochen würde, dann müsste jede Platte gehen, die mehr Spuren UND mehr Köpfe UND mehr Sektoren hat (UND = log. AND). Hier ist C-H-S = 980-15-17, da müsste doch eine alte 504 MB oder weniger funktioneren. C-H-S konnte max. 504 MB addressieren, deswegen geht vermutlich die 2-GB-Platte nicht mehr, die will per LBA addressiert werden.
Mir ist noch etwas eingefallen: hast Du nach jedem dd ein sync gemacht?
1 | knoppix@Microknoppix:~$ dd if=/dev/sdb of=/media/sda5/output2.img |
2 | 249900+0 Datensätze ein |
3 | 249900+0 Datensätze aus |
4 | 127948800 bytes (128 MB, 122 MiB) copied, 135,234 s, 946 kB/s |
5 | knoppix@Microknoppix:~$ sync |
6 | knoppix@Microknoppix:~$ |
und dann
1 | knoppix@Microknoppix:~$ dd if=/media/sda5/output2.img of=/dev/sdb |
2 | 249900+0 Datensätze ein |
3 | 249900+0 Datensätze aus |
4 | 127948800 bytes (128 MB, 122 MiB) copied, 50,4427 s, 2,5 MB/s |
5 | knoppix@Microknoppix:~$ sync |
6 | knoppix@Microknoppix:~$ |
sync ist sehr wichtig, denn unixoide OS schreiben alle Daten erst mal in einen Puffer, der dann allmählich auf den Datenträger entlerrt wird. sync erzwingt ein sofortiges Schreiben. https://wiki.ubuntuusers.de/sync/
So melde mich mal wieder mit Infos, Habe noch mal die ausgelesenen Infos der alten und der neuen Platte mit angehängt, ausserdem den Anfang des Festplattenimages. Ich glaube herausgefunden zu haben dass die CHS Informationen der Festplatte in dem Eprom des Keyboards gespeichert sind. Ferner vermute ich, wenn diese CHS Info nicht mit der eingebauten Festplatte übereinstimmen, dann kann das Eprom die Daten nicht richtig zuordnen, deshalb funktioniert das lesen der Daten von der neuen Platte nicht richtig. In Zeile 00000060 stehen die CHS Daten der Platte. Wenn man die ändert zeigt das Keyboard "Wrong Eprom Version" an und fährt nicht hoch. Kann man die CHS der Platte so ändern, dass diese dem original entsprechen ? ST9145AG(original Disk): ------------------------ hard sectored not MFM encoded head switch time > 15us fixed drive disk xfer rate > 5Mbs Logical max current cylinders 980 0 heads 15 0 sectors/track 17 0 -- bytes/track: 9622 bytes/sector: 566 Logical/Physical Sector size: 512 bytes device size with M = 1024*1024: 122 MBytes device size with M = 1000*1000: 127 MBytes cache/buffer size = 64 KBytes (type=DualPortCache) PQI IDE DiskOnModule: ------------------------ Logical max current cylinders 500 500 heads 16 16 sectors/track 32 32 -- bytes/track: 0 bytes/sector: 512 CHS current addressable sectors: 256000 LBA user addressable sectors: 256000 Logical/Physical Sector size: 512 bytes device size with M = 1024*1024: 125 MBytes device size with M = 1000*1000: 131 MBytes cache/buffer size = 0 KBytes (type=1Sect)
1 | 00000000 54 45 43 48 4E 4F 53 4F 46 54 20 38 38 33 33 20 TECHNOSOFT 8833 |
2 | 00000010 53 41 4D 53 54 41 47 45 52 4E 20 43 48 41 2E 20 SAMSTAGERN CHA. |
3 | 00000020 46 61 65 73 73 6C 65 72 52 65 6C 65 61 73 65 20 FaesslerRelease |
4 | 00000030 32 2E 31 30 20 2F 20 30 35 2E 31 39 39 34 00 00 2.10 / 05.1994.. |
5 | 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
6 | 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
7 | 00000060 00 00 00 00 D4 03 0F 11 00 02 04 00 00 00 00 00 ....Ô........... |
8 | 00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
9 | 00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
10 | 00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
11 | 000000A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
12 | 000000B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
13 | 000000C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
14 | 000000D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
15 | 000000E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
16 | 000000F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
17 | 00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
18 | 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
19 | 00000120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
20 | 00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
21 | 00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
22 | 00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
23 | 00000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
24 | 00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
25 | 00000180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
26 | 00000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
27 | 000001A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
28 | 000001B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
29 | 000001C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
30 | 000001D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
31 | 000001E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
32 | 000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
33 | 00000200 31 2D 54 68 65 6F 20 30 20 20 20 20 20 20 20 32 1-Theo 0 2 |
34 | 00000210 2D 20 20 20 20 20 20 20 20 20 20 20 20 20 33 2D - 3- |
35 | 00000220 20 20 20 20 20 20 20 20 20 20 20 20 20 34 2D 20 4- |
36 | 00000230 20 20 20 20 20 20 20 20 20 20 20 20 35 2D 20 20 5- |
37 | 00000240 20 20 20 20 20 20 20 20 20 20 20 36 2D 20 20 20 6- |
38 | 00000250 20 20 20 20 20 20 20 20 20 20 37 2D 20 20 20 20 7- |
39 | 00000260 20 20 20 20 20 20 20 20 20 54 48 45 4F 20 30 31 THEO 01 |
40 | 00000270 20 20 |
:
Bearbeitet durch User
Tom F. schrieb: > In Zeile 00000060 stehen die CHS Daten der Platte. Wie bist Du darauf gekommen? Eigentlich sollte das Keyboard diese Parameter von der Festplatte auslesen. Konntest Du denn schon feststellen, ob das Keyboards CHS- oder LBA-Adressierung nutzt? Davon hängt doch alles ab. > Wenn man die ändert zeigt das Keyboard "Wrong Eprom Version" an und > fährt nicht hoch. Vermutlich musst Du die Prüfsumme des Eproms auch neu schreiben.
D4 03 = 980 0F = 15 11 = 17 Voila, das sind ganau die CHS-Daten der alten Platte. die habe ich ersetzt mit F4 01 10 20 00 02 04 die 02 04 habe ich unverändert gelassen weil ich nicht weis was das sein soll.
Tom F. schrieb: > D4 03 = 980 > 0F = 15 > 11 = 17 > > Voila, das sind ganau die CHS-Daten der alten Platte. > > die habe ich ersetzt mit > > F4 01 10 20 00 02 04 > > die 02 04 habe ich unverändert gelassen weil ich nicht weis was das sein > soll. Du willst doch auf die alten abgespeicherten Stücke wieder zugreifen können, das image entspricht ja dem Original. also müßtest du die Geometrie des DiskOnModule z.B. mit fdisk auf die 980 15 17 ändern. --- falls da jetzt schon neues darauf geschrieben wurde ginge dies nat. verloren bzw. wird nicht mehr richtig addressiert. also ggf. das image nach der Änderung nochmal schreiben.
dolli schrieb: > also müßtest du die Geometrie des DiskOnModule z.B. > mit fdisk auf die 980 15 17 ändern. Danke für den Tip, gerade mal probiert, aber die Parameter lassen sich anscheinend nicht ändern. hdparm -I zeigt mir immernoch die 500 Cylinder an nachdem ich diese geschrieben habe. Im Handbuch steht auch nichts davon https://www.pollin.de/productdownloads/D701790D.PDF
:
Bearbeitet durch User
Nur zur Sicherheit und besser wohl nicht über den Adapter :) fdisk dev.. command (m for help): x Expert command (m for help): m Command action c change number of cylinders ... h change number of heads ... s change number of sectors/track ... w write table to disk and exit --- wenns nicht geht dann gehts eben nicht. Da das problemlos mit USB-Flashdrives zu machen ist hätte ich jetzt angenommen das würde hier auch funktionieren. denn da die alte platte nur CHS kann 980 15 17 512 byte/sec 500 16 32 A = (c ⋅ Nheads + h) ⋅ Nsectors + (s − 1) führt eine z.B. chs-adressierung zu unterschiedlichen Stellen. 0/0/1 ... 0/0/17, 0/1/1 ...
> ... > > führt eine z.B. chs-adressierung zu unterschiedlichen Stellen. > Mmh, ne das wird so nicht stimmen es wird ja seitens des Controller Orgelseitig nur chs /gesprochen ---- >>> Konntest Du denn schon feststellen, ob das Keyboards CHS- oder >>> LBA-Adressierung nutzt? Davon hängt doch alles ab. Wenn die alte Platte nur chs kann dann muss sie wohl auch so angesprochen werden. ---- Das DiskOnmod. dürfte in dieser Konstellation nur zur Hälfte nutzbar sein. Weil jeder der virtuellen 500 Zylinder jeweils nur bis 15/17 adressiert wird. Solange man nichts über den steuernden Kontroller weis bleibt einem ja wenig übrig ausser sich an der ausgebauten Platte zu orientieren. --- jdf. viel Erfolg für weiteren Verlauf.
Habe nun auchmal bei einer andere IDE Platte versucht die Anzahl, der Zylinder zu ändern, leider wieder ohne Erfolg. Nach fdisk und w kam die vielversprechende Ausgabe:
1 | Die Partitionstabelle wurde verändert. |
2 | ioctl() wird aufgerufen, um die Partitionstabelle neu einzulesen. |
3 | Festplatten werden synchronisiert. |
Gibt es neben fdisk vielleicht noch eine andere Möglichkeit die Geometriedaten zu ändern oder lassen dies die meisten Festplatten schlicht nicht zu ?
1 | knoppix@Microknoppix:~$ sudo hdparm -I /dev/sdb |
2 | |
3 | /dev/sdb: |
4 | |
5 | ATA device, with non-removable media |
6 | Model Number: TOSHIBA MK2628FC |
7 | Serial Number: 85L23353 |
8 | Firmware Revision: P4.14 F |
9 | Standards: |
10 | Likely used: 2 |
11 | Configuration: |
12 | Logical max current |
13 | cylinders 1571 1571 |
14 | heads 16 16 |
15 | sectors/track 63 63 |
16 | -- |
17 | bytes/track: 40257 bytes/sector: 639 |
18 | CHS current addressable sectors: 1583568 |
19 | LBA user addressable sectors: 1584032 |
20 | Logical/Physical Sector size: 512 bytes |
21 | device size with M = 1024*1024: 773 MBytes |
22 | device size with M = 1000*1000: 811 MBytes |
23 | cache/buffer size = 128 KBytes (type=DualPortCache) |
24 | Capabilities: |
25 | LBA, IORDY(can be disabled) |
26 | Buffer size: 128.0kB bytes avail on r/w long: 4 |
27 | Standby timer values: spec'd by Vendor |
28 | R/W multiple sector transfer: Max = 16 Current = 0 |
29 | DMA: sdma0 sdma1 sdma2 mdma0 *mdma1 |
30 | Cycle time: min=150ns recommended=195ns |
31 | PIO: pio0 pio1 pio2 pio3 |
32 | Cycle time: no flow control=186ns IORDY flow control=180ns |
33 | |
34 | |
35 | |
36 | Expertenbefehl (m für Hilfe): c |
37 | Anzahl der Zylinder (1-1048576, Vorgabe 98): 980 |
38 | |
39 | Expertenbefehl (m für Hilfe): r |
40 | |
41 | Befehl (m für Hilfe): w |
42 | |
43 | Die Partitionstabelle wurde verändert. |
44 | ioctl() wird aufgerufen, um die Partitionstabelle neu einzulesen. |
45 | Festplatten werden synchronisiert. |
Hallo Tom, das CHS-Mapping konnte man früher im Mainboard-Bios ändern, aber vermutlich ist es in Deinem "Keyboard-Bios" hart kodiert worden. In Deinen Logs schlägt der Wert für "Bytes/Sektor" Purzelbäume. Ob das so gut ist, weiß ich nicht.
Peter M. schrieb: > vermutlich ist es in Deinem "Keyboard-Bios" hart kodiert worden. So sehe ich das auch. Also wenn man das Eprom nicht ändern kann muss man wohl die genau passende Festplatte anschliessen. Und wenn man die nicht auftreiben bzw. eine andere so passend machen kann, dann ist wohl Ende. Habe mal das Handbuch des MEC 2000 gescannt, falls es jemanden interssiert.
Nun ich hatte ja schon vor Wochen geschrieben dass die meisten das Problem unterschätzen. Wenn ich mir den Sektor anschaue dann lese ich was von Releasedate 1994.... Sowas ist definitiv nichts für die "alles kein Problem Fraktion". Damals gab es kein LBA irgendwas und kein FAT32 noch nicht mal FAT16b. Es wird also eine stinknormale FAT16 Partition mit 504 MB Limit sein. Der erste Schritt wäre also die Platte an den Klonrechner anzuschließen und im BIOS anstelle Auto für diese Platte eben die CHS Parameter der Platte einzustellen. Danach kann man mit einem beliebigen Programm ein Sektor Image ziehen. Auf diesem Image sind dann alle Sektoren genau in der Reihenfolge vorhanden wie es sein muss. Dieses Image kann dann auf eine neue Platte geschrieben werden mit dem Nachteil daß eben auch nur 120 MB nutzbar sein werden. Alternativ geht es eventuell auch wenn vor dem zurück schreiben auf die neu Platte auf Auto zurück stellst und eine max 504 MB große 1. Primäre Partition anlegst und diese formatierst. Früher gab es gute Programme um sowas zu machen Norton Ghost fällt mir da in erster Linie ein. Auch viele moderne Programme sollten dies noch können. Thomas
Tom F. schrieb: > Und wenn man die nicht auftreiben bzw. eine andere so passend machen > kann, dann ist wohl Ende. Kannst du MIDI-Dateien an anderer Stelle einspielen und dann aufnehmen? Oder auch von der alten Platte über das Keyboard an den PC senden? recap: >>> Allerdings das Speichern neuer Lieder klappt. >>> Diese können dann auch wieder geladen werden. Stimmt doch für die 20GB Platte oder nicht? durch den mismatch vergeudet man eben PLatz was bei 20GB zu verschmerzen ist. Zumal diese ja recht wahrscheinlich eh nicht adressiert werden können. Es bleiben eben weiße Flecken auf der Platte da nach je 17 Sektoren wohl 15 übersprungen werden. ---- Alte (vermutlich ja MIDI! dem Prospekt nach) Daten: Die können sich nun auf einem Dateisystem befinden oder eben auch nicht, sollte hier keine Rolle spielen. Schau doch mal mit testdisk direkt ins image.
Hallo Tom, leider gehst Du etwas unstrukturiert zu Werke: Punkt 1: ======== Es wurde Dir sowohl von M.M.M als auch von Dolli empfohlen, einen Blick auf das Image zu werfen. Die interessante Frage ist nämlich, ob das Keyboard eine bekannte Verwaltungsstruktur auf der Festplatte benutzt. Da ungeachtet des CHS-Mappings der erste Sektor immer korrekt übertragen wird, hast Du es bisher versäumt zu überprüfen, ob sich da nicht vielleicht eine MSDOS-Partitionstabelle oder ein MS-DOS-Bootsektor (Stichwort: Supperfloppy) befindet. Andernfalls ist es wahrscheinlich, dass das Keyboard eine proprietäre Verwaltungsstruktur nutzt, um Daten abzulegen. Punkt 2: ======== Du kannst die CHS-Parameter der Festplatte mit fdisk nicht abändern! Du kannst lediglich die CHS-Informationen in der Partitionstabelle (wenn vorhanden) so verändern, dass sie zur Geometrie der Festplatte passen.
Vielen Dank für die zahlreichen Antworten. Habe das Image mal angehängt. Vielleicht kann jemand da was erkennen. Peter M. schrieb: > Es wurde Dir sowohl von M.M.M als auch von Dolli empfohlen, einen Blick > auf das Image zu werfen. Habe mit Testdisk alle "Partition Table Types" durchprobiert. Es kam jedesmal die Ausgabe "Bad partition" oder "invalid signature". dolli schrieb: >>>> Allerdings das Speichern neuer Lieder klappt. >>>> Diese können dann auch wieder geladen werden. > > Stimmt doch für die 20GB Platte oder nicht? Leider hatte ich mich da zu früh gefreut. Die Lieder lassen sich ohne Fehlermeldung abspeichen. Wenn man aber das Abgespeicherte Lied wieder lädt, dann stimmen die Einstellung der Instrumente nicht, schade. Thomas schrieb: > Der erste Schritt wäre also die Platte an den Klonrechner anzuschließen > und im BIOS anstelle Auto für diese Platte eben die CHS Parameter Die Möglichkeit habe ich bei dem von mir verwendeten "alten" PC leider nicht. Das BIOS ist wohl zu neu. dolli schrieb: > Oder auch von der alten Platte über das Keyboard an den PC senden? Leider habe ich die beschriebe Parallelschnittstelle am Keyboard nicht. War wohl eins der früheren Serie. Sonst wäre die Idee gewesen die Neue Disk über diese Schnittstelle mit der PC Software zu formatieren.
Hallo Tom F., Tom F. schrieb: > Vielen Dank für die zahlreichen Antworten. > > Habe das Image mal angehängt. Vielleicht kann jemand da was erkennen. > Peter M. schrieb: >> Es wurde Dir sowohl von M.M.M als auch von Dolli empfohlen, einen Blick >> auf das Image zu werfen. > > Habe mit Testdisk alle "Partition Table Types" durchprobiert. > Es kam jedesmal die Ausgabe "Bad partition" oder "invalid signature". Das ist jetzt leider der blödere Fall. Wenn Du das Image nach Partitionen hast durchsuchen lassen und Testdisk findet keine, muss man davon ausgehen, dass Dein Keyboard die Platte selbst autonom ohne Zuhilfenahme von Fat16 oder ähnlichem verwaltet Jetzt hilft nur noch Technics oder Reverse Engineering Deines Keyboard-Betriebssystems.
Man kann ja schon am geposteten Sektor 0 sehen dass es sich keinesfalls um eine Umgebung handelt wie man Sie unter DOS erwarten würde. Trotzdem gehe ich davon aus, dass es eine FAT16 Umgebung ist dafür spricht ja auch dass das Inhaltsverzeichnis auf der Kopie lesbar war. Es ist vermutlich so dass bedingt durch Auto im BIOS die Sektoren halt nicht mehr an der richtigen Stelle landen. Rechner mit einstellbarern CHS Parametern würde ich in der 486er Generation vermuten max bei Pentium1. Dann hast du allerdings das Problem ein Linux dafür zu bekommen. Keine Ahnung was DD da vorraussetzt. Vielleicht gibt es hier jemand der eine alte DOS Maschine hat und auch noch ein Ghost besitzt. Thomas
Thomas schrieb: > Man kann ja schon am geposteten Sektor 0 sehen dass es sich keinesfalls > um eine Umgebung handelt wie man Sie unter DOS erwarten würde. Trotzdem > gehe ich davon aus, dass es eine FAT16 Umgebung ist dafür spricht ja > auch dass das Inhaltsverzeichnis auf der Kopie lesbar war. Es ist > vermutlich so dass bedingt durch Auto im BIOS die Sektoren halt nicht > mehr an der richtigen Stelle landen. Rechner mit einstellbarern CHS > Parametern würde ich in der 486er Generation vermuten max bei Pentium1. > Dann hast du allerdings das Problem ein Linux dafür zu bekommen. Keine > Ahnung was DD da vorraussetzt. Vielleicht gibt es hier jemand der eine > alte DOS Maschine hat und auch noch ein Ghost besitzt. > > Thomas Nein das ist wohl nicht zutreffend. -rw-r--r-- 1 0 0 127948800 2018-11-11 22:32 test.img root@box:$bc <<< '980*15*17*512' 127948800 Das image entspricht der Größe der Platte. Die Sektoren sind genau dort wo sie sein sollen und 0/0/1 ist und bleibt Adresse 0. Diese Platte hat kein Dateisystem das ist ein 'RAW-Datenträger'. Es gibt auch keine z.B. MIDI-Dateien ldg. wie auch immer organisierte Datensätze. Beim lesen der alten Platte sind auch kaum vertauschungen zu erwarten diese alten IDE Platten werden richtig erkannt wenn diese nicht auf ATA IDENTIFY antworten würden hätte hdparm o. sg_utils auch nichts zu berichten. ---- Wenn jetzt eben dummerweise weder seitens des Kontrollers noch an der Platte etwas zu machen ist könnte man probieren das image zu mappen (strecken). alte: 980/15/17 neue: 1000+/16/63 auf die neue mit der für diese Platte passende Geometrie: 16* 17*512 dann (63-17=46)*512 NULL einfügen plus einmal 63*512 NULL und das Ganze eben 980 mal. Der Kontroller der Orgel wird z.b keine Adresse 0/0/18 anspringen, nach 0/0/17 kommt 0/1/1 und das bedeutet eben auf einer /16/63 adressierbaren Platte das 46*512 Byte übersprungen werden.
Sag mal, ich habe mir mal das User Manual KN2000 angesehen. Ist es das? https://www.manualslib.com/manual/890890/Technics-Sx-Kn2000.html?page=76#manual Im Part V kann man doch auf Diskette sichern. Geht das nicht mit funktionierenden Sounds? Die nicht funktionieren sind eh kaputt.
Hallo dolli,
dolli schrieb:
fand' ich sehr interessant, wie Du künstlich den Mapping-Unterschied
kompensierst, da bin ich nicht drauf gekommen.
Boah ich bin begeistert ... dolli schrieb: > Wenn jetzt eben dummerweise weder seitens des Kontrollers noch an der > Platte etwas zu machen ist könnte man probieren das image zu mappen > (strecken). Gute Idee, da man das Technics Eprom warscheinlich nicht ändern kann ist das echt einen Versuch Wert. Kann man allerdings nicht händisch machen, aber mit einer kleinen C-Routine. Gut das jetzt die langen Winterabende kommen... michael_ schrieb: > Im Part V kann man doch auf Diskette sichern. Ja das stimmt, aber gerade wegen der langen Ladezeiten von Diskette wurde das Keyboard ja um die Festplatte erweitert. Wennn man auf der Bühne ist, kommt das garnicht gut wenn man ständig neue Disketten laden muss.
Tom F. schrieb: > Ja das stimmt, aber gerade wegen der langen Ladezeiten von Diskette > wurde das Keyboard ja um die Festplatte erweitert. > Wennn man auf der Bühne ist, kommt das garnicht gut wenn man ständig > neue Disketten laden muss. Du sollst ja nicht auf der Bühne laden, sondern einmalig die brauchbaren Daten von der eingebauten Platte sichern. Dann neue Platte rein, im Keyboard formatieren (nicht am PC) und dann die Disketten wieder zurückspielen auf die neue Platte. Oder über MIDI sichern wenn das geht. Die Daten über Sysex zum PC schicken und da wegspeichern, und nach Plattenwechsel die Files wieder zurückspielen. Also MIDI-Datentransfer (Sysex), nicht Übertragung als Noten.
soul e. schrieb: > Dann neue Platte rein, im > Keyboard formatieren (nicht am PC) und dann die Disketten wieder Formatieren der Platte geht am Keyboard leider nicht (ist im Betriebssystem nicht vorgesehen, nur Disketten), sondern nur wenn man die Parallelschnittstelle am Keyboard hat, dann über PC (und Windows 95). Ich kann mir vorstellen, dass wenn mal eine Platte defekt war ist man zum Händler, der hat dann das Formatieren, den Einbau und das Anpassen der neuen Plattengrösse im Eprom vorgenommen.
Tom F. schrieb: > Formatieren der Platte geht am Keyboard leider nicht (ist im > Betriebssystem nicht vorgesehen, nur Disketten), sondern nur wenn man > die Parallelschnittstelle am Keyboard hat, dann über PC (und Windows > 95). Muß man das? Mach doch erst mal den Versuch, eine ähnliche HD einbauen und testen. Und wenn, dann die Parallel ran und unter W95! Alte Technik will mit alten Tools und alter Hardware behandelt werden. Mein Vorschlag. Besorge dir eine baugleiche HD, im Netz gibt es einzelne Angebote unter 100EUR. Oder eine ähnliche mit gleicher Aufteilung. Kann auch 3,5" sein. Und dann einen alten PC, wo man die Aufteilung aus einer Liste auswählen kann oder manuell festlegen. Könnte bei 386' gehen. Auf diese kopierst du dann mit alten Tools, evtl. von Seagate selbst, deine HD. Ist natürlich ein gewaltiger Aufwand für dich. Für mich kaum. Die HD könnte auch von der Größe her im Amiga 1200 verbaut gewesen sein. Sehe dich da mal um.
Tom F. schrieb: > Kann man allerdings nicht händisch machen, aber mit einer kleinen > C-Routine. > > Gut das jetzt die langen Winterabende kommen... >
1 | #!/bin/bash
|
2 | |
3 | # 980 15 17 ; 1000+ 16 63
|
4 | # A = $((c * Nheads + h) * Nsectors + (s - 1))
|
5 | |
6 | |
7 | #Datei anlegen e.g.: dd if=/dev/zero of=img_new bs=512 count=987840
|
8 | |
9 | |
10 | for c in `seq 0 980`; #980 |
11 | |
12 | do
|
13 | |
14 | for h in `seq 0 15`; |
15 | |
16 | do
|
17 | |
18 | for s in `seq 1 17`; |
19 | |
20 | do
|
21 | |
22 | |
23 | A=$(((c * 15 + h)*17+(s - 1))); |
24 | #0/0/1 = 0
|
25 | B=$(((c * 16 + h)*63+(s - 1))); |
26 | #neue Adresse
|
27 | |
28 | |
29 | dd if=test.img of=img_new bs=512 skip=$A count=1 seek=$B conv=notrunc; # conv=sync; |
30 | |
31 | #lese ein Block ab Stelle A
|
32 | #überschreibe ein Block ab Stelle B
|
33 | |
34 | done; |
35 | done; |
36 | done; |
37 | ;
|
Nur stichprobenartig getestet, geht bestimmt besser. Wenns denn funktioniert und dd das macht was man sich wünscht ;) bye.
michael_ schrieb: > Besorge dir eine baugleiche HD, im Netz gibt es einzelne Angebote unter > 100EUR. Würde ich nicht machen, die Dinger sind oll und abgenudelt. Es gibt aber SD-Card-auf-IDE-Adapter, mit denen könnte man hier eventuell Erfolg haben. https://www.amazon.de/SODIAL-44-Pin-IDE-Male-SD-Adapter/dp/B00H3CRJNY
Hallo Tom, Tom F. schrieb: > Vielen Dank für die zahlreichen Antworten. > > Habe das Image mal angehängt. Vielleicht kann jemand da was erkennen. > Peter M. schrieb: >> Es wurde Dir sowohl von M.M.M als auch von Dolli empfohlen, einen Blick >> auf das Image zu werfen. > > Habe mit Testdisk alle "Partition Table Types" durchprobiert. > Es kam jedesmal die Ausgabe "Bad partition" oder "invalid signature". leider Fehlanzeige! Ich habe mir Deine Datei mal unter dem Hexeditor angeguckt. Da war nichts, was nach Partitionstabelle oder Bootsektor aussah. Das scheint ein proprietäres Format zu sein. Immerhin kenne ich jetzt das Programm von Dir oder Deiner Combo. :) Aber das hilft uns auch nicht weiter. Gruß Peter
Hallo Peter M. schrieb: > Ich habe mir Deine Datei mal unter dem Hexeditor angeguckt. > Da war nichts, was nach Partitionstabelle oder Bootsektor aussah. > > Das scheint ein proprietäres Format zu sein. Öhm, das ist aber doch schon seit einer Woche (Beitrag 5614876) klar. Da hat er doch den ersten Sektor hier eingestellt. Bleibt ihm zum Kopieren auf die größere Festplatte der von dolli beschriebene Algorithmus oder einfacher, das verändern der Geometrie der Festplatte mittels fdisk mit nachfolgendem Schreiben des Images. MfG
M.M.M schrieb: > der einfacher, das verändern der Geometrie der Festplatte mittels fdisk > mit nachfolgendem Schreiben des Images. Wie sollte das helfen? Die mit fdisk veränderbare Geometrie der Festplatte betrifft nur Systeme, die einen PC-artigen Bootsektor mit Partitionstabelle verwenden. Das ist hier wohl offensichtlich nicht der Fall. Und der Festplatte selbst ist es vollkommen wurscht, was fdisk treibt. Das Keyboard steuert die Festplatte mit CHS an, denn die Platte ist mit gerade mal 127 MB Größe so steinalt, daß sie kein LBA kennt. Wird die Festplatte mit CHS angesteuert, dann muss eine Kopie sich genauso verhalten, d.h. sie muss, wenn z.B. Zylinder X, Kopf Y und Sektor Z angefordert wird, genau die gleichen Daten liefern. Das setzt voraus, daß die Ersatzplatte sich per CHS ansteuern lässt und in keinem der Parameter C, H oder S kleinere Maximalwerte zulässt als die Originalplatte. Diese Anforderung erfüllt jede Festplatte mit 8 GB Größe, d.h. die hier eingesetzte 20-GB-Platte macht das auch. Vor dem Kopieren sind die maximalen CHS-Werte der alten Festplatte zu ermitteln - die stehen ja praktischerweise auf der Platte drauf: 980-15-17. Die Ersatzplatte muss dann sektorweise exakt genauso beschrieben werden wie das Original. Dazu muss die kopierende Software beide Platten im CHS-Modus ansteuern und darf keinerlei Interpretation der gelesenen Daten anstellen. Damit bleiben natürlich 99% der Kapazität der neuen Platte komplett ungenutzt, aber das ist eine Konsequenz des Kopierens ohne jede Kenntnis des Dateisystems, und ohne Kenntnis des die Platte ansteuernden Controllers im Keyboard.
Habe jetzt nicht den ganzen Tread hier gelesen, da kilometer lang. Wie auch im anderen Posting könnte ich mich anbieten, und die Platte per R-Studio versuchen zu retten. Alte Rechner mit Pentium 1 und P2 habe ich am laufen. Wenn die Platte IO-Problems hat, klingt das nach Kontroller, wenn sie nicht laut und komisch ist. Welche HDD genau ? Grüße Thomas (aber nicht der von oben)
M.M.M schrieb: > beschriebene Algorithmus oder einfacher, das verändern der Geometrie der > Festplatte mittels fdisk mit nachfolgendem Schreiben des Images. > Zum PQI, mit fdisk ginge das wenn sich das DiskonModule nicht im "true ide modus" befände, also Wechseldatenträger ala cf oder USB-stick wäre. Bit 6 im Config-Register man müßte nur drankommen. Word 0: general configuration: .... some operating systems require Bit 6 of Word 0 to be set to 1 non-removeable device .... aber dann wird man vermutlich noch an derer stelle doktern dürfen. Ob es gesetzt ist sollte aber in Erfahrung bringen lassen sg_inq --ata -H dev... (vermutlich die ersten zwei bytes, scsi-ata-translation) Zu dem Modul "dj high speed series" gibt es anscheinend kein (jdf. auffindbares) vollständiges DB. Bei der "dj turbo series" ist der implementierte ATA Befehlssatz aufgeführt und dieses (vermutlich nat. anderer Controller) würde lt. DB den Befehl 91h initialize drive parameters kennen. (linux, sg3_utils via satl ATA-pass-through a1) this command enables the host to set number of sectors per track and the number of heads per cylinder. [This enables Translation Mode which maps the flash storage using the altered parameters ...] Übersteht aber wohl keinen reset :( --- 128MB verteilen sich auf 504MB und der Rest bleibt nicht addressierbar. Bislang ist das nat. nur Theorie. Braucht doch kein Mensch ... ;)
Thomas schrieb: > Habe jetzt nicht den ganzen Tread hier gelesen, da kilometer lang. Lese es aber alles. Er hat ein Image. Der Typ steht auch da. Es ist ein anderes Problem, beim Rückschreiben. TO: Wie weit ist die Sicherung der Melodien auf Disketten?
In letzter Verzweiflung könnte man ja eine Daten-Rekonstruktions-Software auf das Image ansetzen, ob die Musikdateien findet - aber es ist wohl zu 99% sicher, dass auch die Musikdaten keinem bekannten Format entsprechen. Georg
dolli schrieb: > Wenn jetzt eben dummerweise weder seitens des Kontrollers noch an der > Platte etwas zu machen ist könnte man probieren das image zu mappen > (strecken). > > alte: 980/15/17 neue: 1000+/16/63 > > auf die neue mit der für diese Platte passende Geometrie: > 16* 17*512 dann (63-17=46)*512 NULL einfügen > plus einmal 63*512 NULL und das Ganze eben 980 mal. > > Der Kontroller der Orgel wird z.b keine Adresse 0/0/18 anspringen, > nach 0/0/17 kommt 0/1/1 und das bedeutet eben auf einer /16/63 > adressierbaren Platte das 46*512 Byte übersprungen werden. Habe nun versucht das original Image CHS = 980/15/17 zu stecken auf 500/16/32 (Das ist das 128MB Disk on Module von Pollin). KLar es gehen nur die ersten 500 Cylinder drauf, aber für die ersten Titel/Klänge sollte das reichen. Ergebnis: Negativ Das Keyboard kann das Inhaltsverzeichnis am Anfang der Platte lesen, so wie vorher auch. Bei der Auswahl eines Titels/Klangs scheitert es aber. Das Keybord bleibt zwar nicht hängen wie vorher, sondern es lädt einfach irgend einen Klang/Lied, aber nicht das ausgewählte. Vielleicht kann sich nochmal jemand das Image mit dem original von weiter oben (Beitrag #5618420) vergleichen, ob das so richtig ist. Schade ich dachte man könnte das schnelle Festplattensystem noch weiter nutzen, aber ohne die Adressierung im Eprom zu kennen wird das wohl nichts. Ich glaube ich muss mich so langsam doch mit so einem Floppy Emulator anfreunden. :-( https://www.amazon.de/SFRM72-TU100K-Floppy-Emulator-industriell-Ausr%C3%BCstung-Laufwerk/dp/B008HYUDV2
:
Bearbeitet durch User
Tom F. schrieb: > > Habe nun versucht das original Image CHS = 980/15/17 zu stecken auf > 500/16/63 (Das ist das 128MB Disk on Module von Pollin). KLar es gehen > Ergebnis: Negativ 500/16/32 ! Probier die 800er Platte. Wenn Zeit ist guck ich mal in die angehängte Datei. Schau doch was passiert: Cylinder 0
1 | ------------------ LBA der 0/1/1 Geo. x/15/17 |
2 | | --------------- LBA der 0/1/1 Geo. x/16/32 |
3 | h s | | |
4 | 1 1 17 32 63 |
5 | 1 2 18 33 64 |
6 | 1 3 19 34 65 |
7 | 1 4 20 35 66 |
8 | 1 5 21 36 67 |
9 | 1 6 22 37 68 |
10 | 1 7 23 38 69 |
11 | 1 8 24 39 70 |
12 | 1 9 25 40 71 |
Nun da du offensichtlich keinen passenden PC mit einstellbaren CHS Parametern an den Start bekommst gibt es immer noch die Möglichkeit ein kleines Programm zu schreiben. Es gibt da den INT 13 der Sektoren mit CHS Adressierung anspricht. Funktion 3 ist alles was du brauchst. Siehe Ralph Brouns Interuptlist (RBIL) Du liest einfach Sektor für Sektor aus deinem Image und schreibst den Sektor mit dem INT 13 auf die Platte . Das ist so ähnlich wie dein Versuch mit dem Strecken nur dass mit dem INT 13 deine Sektoren genau dahin kommen wohin sie sollen. Einfach oder? Das funktioniert wenn dd deine Sektoren der Reihe nach gelesen hat wovon ich ausgehe. Die einzige Unsicherheit wäre noch wann du jeweils die CHS variablen incremetieren must. Thomas
Thomas schrieb: > Die einzige Unsicherheit wäre noch wann du jeweils die CHS variablen > incremetieren must. Auf der Platte ist ein Aufkleber, auf dem draufsteht, wie sie anzusprechen ist - diese Nummern würde ich verwenden: 980-15-17. (980 Zylinder, 15 Köpfe und 17 Sektoren pro Spur) Das Zielmedium muss sich aber auch mit dieser Konfiguration ansprechen lassen -- wenn das verwendete 128MB-Flash-Modul mit 500/16/63 angesprochen werden will, dann geht das nicht, denn die Zylinderzahl ist zu klein.
Rufus Τ. F. schrieb im Beitrag #5632773 > Das Zielmedium muss sich aber auch mit dieser Konfiguration ansprechen > lassen -- wenn das verwendete 128MB-Flash-Modul mit 500/16/63 > angesprochen werden will, dann geht das nicht, denn die Zylinderzahl ist > zu klein. >>> 500/16/63 (Das ist das 128MB Disk on Module von Pollin). KLar es gehen 500/16/63 (*512) wäre 252MB; 256MB Modul KN2000DiskImage_resize scheint auf 32-17=15 *512 =7680 /1024 =7,5 getrimmt, lt. hexdump erste Lücke h2200 <-> h4000 = 7,5Kb. bei 63 wärs ja h7E00 das scheint jdf. doch berücksichtigt worden zu sein. aber es fehlt nat. die Hälfte. ----- Was passiert eigentlich mit einer blanken Disk? (abgesehen davon das nat. alles weg ist ;)) Geht dann garnichts oder funktioniert es ganz normal? Davon konnte man jdf., glaube ich wenigsten, nichts lesen.
Das Image lässt sich nicht in der Größe verändern, da das Dateisystem unbekannt ist. Ein Versuch des "Trimmens" oder "resize" kann nur schiefgehen.
Ich denke, man sollte hier einen anderen Weg einschlagen und man sollte sich auch (zumindest erst einmal) von seinem ev. vorhandenen PC-Wissen (oder Halbwissen...) lösen. 1.) Sichern der Daten 2.) Ersatz der Festplatte Auch fehlen wohl vielerlei Vorinformationen. Rausgelesen/anfragwürdig sind mir bis jetzt z.B.: 3.) Das Floppy des SX-KN2000 wurde hardwaremäßig durch die Festplattenerweiterung ersetzt? 4.) Das Betriebssystem des SX-KN2000 wurde nicht verändert? 5.) Alle Bedienfunktionen des SX-KN2000 sind gleich geblieben (bis auf das Zusatzmenue der Erweiterung)? 6.) Wie unterscheidet sich die Bedienung des SX-KN2000 mit Floppy zum SX-KN2000 mit HD-Erweiterung? 7.) Gibt es Datei-/Zeitgrößenbeschränkungen der abspeicherbaren Dateien (Lieder)? Anders gesagt, wie groß und was wäre eine "Speicherung"? 8.) Besitzt Du die Erweiterung der Festplattenerweiterung mit der Anbindung an einen PC? 9.) Ist z.B. 1.) jetzt wichtig oder nur bequemer? Hast du noch andere Kopien? 10.) Kann man Verzeichnisse löschen? In der Doku zur Erweiterung sind mehrere Beschränkungen aufgeführt, es wird von Bänken/Noten/Pattern/Files/Speicherinhalte usw. gesprochen, sind das jeweils einzelne Dateien oder dann gesamte Verzeichnisse? Was ich mir vorstellen könnte: Die Festplatte der HD-Erweiterung ist nicht "formatiert", sondern sie wird nur als fortlaufender Speicher verwaltet (die o.g. Beschränkungen erlauben einen direkten Zugriff auf jeweils ein Unterverzeichnis mit bekannter interner Struktur), ein Dateisystem an sich gibt es damit nicht. Rufus Τ. F. schrieb: > Und der Festplatte selbst ist es vollkommen wurscht, was fdisk treibt. > Das Keyboard steuert die Festplatte mit CHS an... Anders gesagt, wenn ein Programm seine Beschränkungen kennt, diese auch in eine feste Struktur "preßbar" sind, dann liegt eben z.B. immer ab xyz (CHS) + 1000 ein neue Datei, z.B. beginnend mit Dateinamen 28 Zeichen + dann die Daten...
:
Bearbeitet durch User
Rufus Τ. F. schrieb: > Das Image lässt sich nicht in der Größe verändern, da das Dateisystem > unbekannt ist. Ein Versuch des "Trimmens" oder "resize" kann nur > schiefgehen. Deshalb auch der Hinweis er solle die 800er bzw. die neu gekaufte dazu nehmen und schon viel weiter ober der Hinweis das mit dem 128er pqi-modul sowieso nur die Hälfte nutzbar wäre.* So jetzt sagte er aber er hätte das auf 500/16/63 gerechnet aber das Modul hat nunmal die virtuelle geometrie 500/16/32 das geht dann schon zweimal schief. *Wenn sich im zweiten Teil keine Daten befänden was aber der Fall ist hätte das als Test klappen können, das sich dann das System später u.U. Aufhängt oder kuriose dinge tut weil nicht existente Bereiche Adressiert werden ist dann nochmal was anderes. --- Das wird auch kein reiner Nutzdatenspeicher sein, da werden auf der Platte sicherlich auch Betriebsparameter vorab draufgeschrieben worden sein.
Udo A. schrieb: > 7.) Gibt es Datei-/Zeitgrößenbeschränkungen der abspeicherbaren > Dateien (Lieder)? Anders gesagt, wie groß und was wäre eine > "Speicherung"? Laut Beschreibung kann man auf Diskette sichern. Leider keine Antwort auf meine oben angestellte Anfrge, wie weit er damit ist.
michael_ schrieb: > Laut Beschreibung kann man auf Diskette sichern. Auf Diskette sichern geht, habe einige Lieder auf Diskette gesichert. Aber wie bekomme ich die Diskette(n) wieder auf die neue Festplatte ? Ich habe dann versucht einen Song von der Diskette auf die geklonte Festplatte zu speichern. Nach dem erneuten Ladern dieses Songs von Festplatte hat sich aber gezeigt dass dort völlig falsche Instrumente geladen wurden. dolli schrieb: > Deshalb auch der Hinweis er solle die 800er bzw. die neu gekaufte dazu > nehmen und schon viel weiter ober der Hinweis das mit dem 128er > pqi-modul sowieso nur die Hälfte nutzbar wäre.* Hab mir eine anderes DiskOnMOdule mit 512MB (1001/16/63) besorgt, da die 800er Platte sich nicht mehr beschreiben lies. Ergebnis war das gleiche wie mit der 128MB. Die Songs lassen sich nicht laden. dolli schrieb: > Was passiert eigentlich mit einer blanken Disk? > (abgesehen davon das nat. alles weg ist ;)) Habe ausser dem ersten Sektor wo die Plattengrösse steht alles mit NULL beschrieben, das hat das Keyboard aber mit einem "Disk Failure" Meldung quittiert.
Udo A. schrieb: > 3.) Das Floppy des SX-KN2000 wurde hardwaremäßig durch die > Festplattenerweiterung ersetzt? Nein es wurde durch HDD ergänzt, Die Floppy arbeitet nach wie vor ok. Udo A. schrieb: > 4.) Das Betriebssystem des SX-KN2000 wurde nicht verändert? > 5.) Alle Bedienfunktionen des SX-KN2000 sind gleich geblieben > (bis auf das Zusatzmenue der Erweiterung)? Ja, es wurde ein softwaremässig ein HDD Menü huinzugefügt um auf die Festplatte zuzugreifen. Udo A. schrieb: > 5.) Alle Bedienfunktionen des SX-KN2000 sind gleich geblieben > (bis auf das Zusatzmenue der Erweiterung)? Ja. Udo A. schrieb: > 6.) Wie unterscheidet sich die Bedienung des SX-KN2000 mit > Floppy zum SX-KN2000 mit HD-Erweiterung? Man geht in das HDD Menü um Titel zu laden/speichern. Udo A. schrieb: > 7.) Gibt es Datei-/Zeitgrößenbeschränkungen der abspeicherbaren > Dateien (Lieder)? Anders gesagt, wie groß und was wäre eine > "Speicherung"? Die Diskette (720kb) ist nach dem Formatieren in 20 Songs aufgeteilt. Die maximale Songlänge habe ich nicht ausprobiert. Udo A. schrieb: > 8.) Besitzt Du die Erweiterung der Festplattenerweiterung mit der > Anbindung an einen PC? Leider nicht, die frühen Umbauten hatten noch keinen Parallelport, sonst könnte man über Zusatzsoftware die Platte formatieren. Udo A. schrieb: > 9.) Ist z.B. 1.) jetzt wichtig oder nur bequemer? Deswegen hatte ich den Thread gestartet. Man kann das auch alles auch weiterhin über Floppy bedienen, aber das war nicht meine Fragestellung. Udo A. schrieb: > 10.) Kann man Verzeichnisse löschen? Nein ist im HDD Menü im Keyboard nicht vorgesehen.
Tom F. schrieb: > Hab mir eine anderes DiskOnMOdule mit 512MB (1001/16/63) besorgt, da die > 800er Platte sich nicht mehr beschreiben lies. > Ergebnis war das gleiche wie mit der 128MB. Die Songs lassen sich nicht > laden. Und wie hast du das Image zurück geschrieben? Das Modul sollte passen da alle CHS Parameter größer sind als bei der Original Platte. Jetzt musst du nur noch die Sektoren mit dem int13 zurückschreiben dann geht das Modul. Thomas
Thomas schrieb: > Und wie hast du das Image zurück geschrieben? Zunächst habe ich das 128MB Image -wie weiter oben beschrieben- "gestreckt" auf CHS 1001/16/63", also alles was grösser als CHS 980/15/17 war mit Null aufgefüllt, das ergab also 512MB. Danach mit Knoppix den alten Rechner gebootet und dd if=/media/sda5/KN2000_resize.img of=/dev/sdb Thomas schrieb: > Jetzt musst du nur noch die Sektoren mit dem int13 zurückschreiben Das wäre sicherlich einen Versuch wert. Ich habe es zwar geschafft mir in C# die o.g. Imagestreckung zu basteln, wüsste aber nicht wie ich so etwas mit INT13 umsetzen soll. Müsste so ein Programm dann auch unter Linux laufen ?
Vermutlich ist das Image selbst schon nicht brauchbar, oder wurde das sicher mit den korrekten CHS-Werten der Festplatte erzeugt?
Rufus Τ. F. schrieb: > wurde das > sicher mit den korrekten CHS-Werten der Festplatte erzeugt? Vermutlich nicht. Bei dem Bios mit dem ich das Image erzeugt habe kann man keine Plattenparameter einstellen. Das würde vielleicht erklären warum nur die ersten paar Sektoren der geklonten Platte mit den Platteninformationen und dem Anfang des Inheltverzeichnisses vom Keyboard korrekt interpretiert wird. Auf der 2-ten Ebene sieht man nämlich bei ersten Lied schon fehlerhafte Zeichen.
Tom F. schrieb: > Vermutlich nicht. Dann sollte das mit einem geeigneten PC & Programm nachgeholt werden.
:
Bearbeitet durch User
Tom F. schrieb: > Udo A. schrieb: >> 10.) Kann man Verzeichnisse löschen? > > Nein ist im HDD Menü im Keyboard nicht vorgesehen. dieses o.g. und dann Tom F. schrieb: > dolli schrieb: >> Was passiert eigentlich mit einer blanken Disk? >> (abgesehen davon das nat. alles weg ist ;)) > > Habe ausser dem ersten Sektor wo die Plattengrösse steht alles mit NULL > beschrieben, das hat das Keyboard aber mit einem "Disk Failure" Meldung > quittiert. auch das, deutet für mich damit daraufhin, das die Festplatte mit keinem bekannten Dateisystem, aber eben mit 40 festgelegten (ggf. leeren) "Directory" (Speicherblöcken) vorbereitet wurde. Das ist dann eben die "Formatierung" der Festplatte. Damit wirst Du die Festplatte auch nur CHS-Sektor-Inhalte-mäßig wieder zurück spielen können, aber auch nur unter der Bedingung: der Sektor-Inhalt (also mind. alle normal lesbaren 512-Byte-Blöcke), der sich im Original z.B. hinter: Zylinder: 101 - Kopf: 14 - Sector: 17 verbirgt, muß auch genau wieder auf: Zylinder: 101 Kopf: 14 Sector: 17 Mit einem "0-8-15" dd wirst Du da so einfach nicht zum Ziel kommen. Ich könnte mir auch vorstellen, daß es zusätzlich auch noch irgend eine Art des Sicherungs-/Anpassungssystem des Herstellers gibt, quasi einen Kopierschutz der Hard-/Software des Herstellers. Zumindest Deine o.g. Aussage ""Wrong Eprom Version" deutet auf so eine Hard-/Software- Anpassung hin. Unwägbarkeiten wären auch noch: - Hält sich die Original-Erweiterungen an die ATA-Spezifikation (zumindest ATA-1)? - Erwartet Deine Software-Version der Original-Erweiterungen auch ggf. anderen Festplatten? - Das Festplatten-Kopf 0/1 Problem könnte ggf. auch eine Rolle spielen.
Rufus Τ. F. schrieb: > Vermutlich ist das Image selbst schon nicht brauchbar, oder wurde das > sicher mit den korrekten CHS-Werten der Festplatte erzeugt? Das ist wohl schon das erste Problem, zumindest auf dem 1. dd habe ich keine 40 gleich zusamenhängenden Strukturen finden können (also nicht auf die schnelle "händische" Durchsicht)...
:
Bearbeitet durch User
Tom F. schrieb: > Rufus Τ. F. schrieb: >> wurde das >> sicher mit den korrekten CHS-Werten der Festplatte erzeugt? > > Vermutlich nicht. > Bei dem Bios mit dem ich das Image erzeugt habe kann man keine > Plattenparameter einstellen. Linux ist das egal. Schon da nicht von dieser Platte gebootet wird. Es werden keine Bios-Routinen genutzt, noch nie. Anders sähe das aus wenn der Rechner mit bis ~ DOS6/W95a laufen wuerde. mal hoch scrollen irgendwo ist die Ausgabe von hdparm zu finden. Da geht eindeutig draus hervor LBA wird von der Platte nicht unterstützt, jmd. hat sogar die spces von seagte ausgegraben. Die Parameter werden dort angezeigt, die disk gibt ata-konform ihre Konfiguration an, wo sollte da ein Problem sein? Wie die platte zu lesen ist ist dem Linux-System bekannt. Gut jetzt könnte sein das es tatsächliche Defekte gibt welche den Betrieb zwar nicht stören aber -dd- aus den Tritt bringen könnten. Nochmal ein image anfertigen und vergleichen mit dem vorhandenen. # dd if=/dev/... of=/.. bs=512 conv=sync,noerror oder ddrescue dazu hernehmen
Udo A. schrieb: > habe ich keine 40 gleich zusamenhängenden > Strukturen finden können Es müssten 600 gleiche Speicherplätze zu sehen sein(2 Pages a 20 und darunter jeweils 15 Songs), wobei die meisten leer sein müssten (siehe Screenshots).
Und, wie verhält sich dd bei unbekanntem Dateisystem und "clonen" einer Platte mit abweichenden CHS-Werten? Was macht es, wenn die Quellplatte weniger Sektoren pro Spur hat als die Zielplatte? Lässt es die übrigen unberührt? Ich habe keinerlei Hinweise auf solch ein Verhalten in der manpage finden können.
Rufus Τ. F. schrieb: > Und, wie verhält sich dd bei unbekanntem Dateisystem und "clonen" > einer Platte mit abweichenden CHS-Werten? > > Was macht es, wenn die Quellplatte weniger Sektoren pro Spur hat als die > Zielplatte? Lässt es die übrigen unberührt? Wenn du es ihm freundlich sagst, vlt. ;) skip beim lesen der Quelle seek beim schreiben ins Ziel das muss ja nicht auf ein zielmedium direkt geschehen sondern kann ja auch in eine Datei gemacht werden die anschliesend wieder linear geschrieben wird. > > Ich habe keinerlei Hinweise auf solch ein Verhalten in der manpage > finden können. Im erstellten (erst) image liegen die Daten linear von Sektor 0 bis Ende. Das Muss eben (miss)-gemappt werde auf die Geometrie der neuen Platte. Würde man das original-image linear schreiben landen Daten in nicht adressierbaren Bereichen, um das zu vermeiden mussen sie entsprechend verschieben. Beitrag "Re: Technics Keyboard Festplatte klonen geht das ?" --- Ich sehe da noch nicht das dies prinzipiell nicht funktionieren soll.
Ich hab hier was im Schrank gefunden. Hab da auch noch andere. Ein paar kann ich gegen Porto abgeben wenn sie weiterhelfen.
Hallo Rufus Τ. F. schrieb: > Und, wie verhält sich dd bei unbekanntem Dateisystem und "clonen" > einer Platte mit abweichenden CHS-Werten? dd weiß weder, was ein Dateisystem im "infile" ist, noch was CHS-Werte sind. Insofern ist es wurscht, ob das Dateisystem bekannt oder unbekannt ist. CHS-Werte sind Sache des Device-Treibers. > Was macht es, wenn die Quellplatte weniger Sektoren pro Spur hat als die > Zielplatte? Lässt es die übrigen unberührt? S.o., dd weiß weder, was ein Sektor oder eine Spur ist. Das ist Sache des Device-Treibers. > Ich habe keinerlei Hinweise auf solch ein Verhalten in der manpage > finden können. Was Wunder, s.o. Man braucht nichts in dd hingeheimnissen. Die einzige Aufgabe von dd ist es, Files zu kopieren: dd if=/dev/sdd of=geklonte_Festplatte entspricht übrigens cp /dev/sdd geklonte_Festplatte. MfG
Tom F. schrieb: > Udo A. schrieb: >> habe ich keine 40 gleich zusamenhängenden >> Strukturen finden können > > Es müssten 600 gleiche Speicherplätze zu sehen sein(2 Pages a 20 und > darunter jeweils 15 Songs), wobei die meisten leer sein müssten (siehe > Screenshots). Ich habe nur "händisch" nach der 2x 20 Gesamt-Direktory-Struktur gesucht, genau genommen dürften es wohl sogar 5x 600 Speicherplätze sein, weil die Erweiterung die midi-Files im KN2000 Format abspeichert, was für einen Song wohl 5 "Dateien" bedeutet. Auf einer Diskette (mit Filesystem(!)) ist wohl ein Song (im KN2000 Format) = 5 Dateien mit den Endungen *.CMP, *.LSW, *.SEQ, *.SQF und *.TM
:
Bearbeitet durch User
M.M.M schrieb: > Was Wunder, s.o. Man braucht nichts in dd hingeheimnissen. > Die einzige Aufgabe von dd ist es, Files zu kopieren: > dd if=/dev/sdd of=geklonte_Festplatte > entspricht übrigens > cp /dev/sdd geklonte_Festplatte. > > MfG Wenn das alles wäre was man damit anstellen kann bräuchte man es nicht. Man kann z.B. auch Bereiche aus Dateien lesen und Bereiche in Dateien überschreiben ohne das sich die Dateigröße ändert. --- @daham wenn keine 980+ 15 *17* dabei ist wird auch nur tricksen helfen.
Hallo dolli schrieb: > M.M.M schrieb: > >> Was Wunder, s.o. Man braucht nichts in dd hingeheimnissen. >> Die einzige Aufgabe von dd ist es, Files zu kopieren: >> dd if=/dev/sdd of=geklonte_Festplatte >> entspricht übrigens >> cp /dev/sdd geklonte_Festplatte. >> >> MfG > > Wenn das alles wäre was man damit anstellen kann bräuchte man es nicht. Ja, dd kann die gelesenen Daten konvertieren und formatieren. Beides wird aber hier im Thread nicht verwendet. > Man kann z.B. auch Bereiche aus Dateien lesen und Bereiche in Dateien > überschreiben ohne das sich die Dateigröße ändert. Das fällt unter Formatierung der Daten. Die Intention des oben zitierten sollt kurz gefaßt sein: dd hat keine Idee von der Hardware und dem Dateisystem, da der direkte Umgang damit nicht sein Job ist. MfG
Tom F. schrieb: > Thomas schrieb: >> Jetzt musst du nur noch die Sektoren mit dem int13 zurückschreiben > > Das wäre sicherlich einen Versuch wert. > Ich habe es zwar geschafft mir in C# die o.g. Imagestreckung zu basteln, > wüsste aber nicht wie ich so etwas mit INT13 umsetzen soll. > Müsste so ein Programm dann auch unter Linux laufen ? Wie das unter Linux funktioniert? Keine Ahnung. Im Anhang ein Programm für DOS. Unter turbo c stellt bios.h die int13 Funktion zur Verfügung. Sowas sollte es auch für Linux geben Thomas
M.M.M schrieb: > dd weiß weder, was ein Dateisystem im "infile" ist, noch was CHS-Werte > sind. Insofern ist es wurscht, ob das Dateisystem bekannt oder unbekannt > ist. CHS-Werte sind Sache des Device-Treibers. Dann ist dd für die spezifische Aufgabe hier komplett ungeeignet.
Rufus Τ. F. schrieb: > Dann ist dd für die spezifische Aufgabe hier komplett ungeeignet. Ketzer! --- Ich habe mir noch einmal das 1. Image angesehen, da lassen sich schon die o.g. fünf unterschiedlichen "Dateien-Typen" des KN2000-Song-Formates finden, die beginnen ja freundlicherweise immer ab einem 512-Byte-Block. :-) Aber ich habe da auch 512-Byte-Blöcke gefunden, die passen dann wohl "Datei-Abfolge-mäßig" nicht mehr zusammen/hintereinander. Die Frage wäre da, ist das systembedingt durch die Firmware des HD-MEC200 (alte Songreste, andere Zählung, System-Daten- Blöcke usw.) oder stimmt die Reihenfolge der Sektoren im Image nur nicht. Wie auch immer, wenn der Beitragsersteller seine Daten per int13 Funktion zurückschreibt und es läuft alles, dann wäre ja alles i.O.. Ansonst eben auch noch vorher per int13 auslesen...
:
Bearbeitet durch User
Hallo Habe mir gerade mal in der Pause den Algorithmus oberflächlich angeschaut. Da hätte ich IMHO zwei Berichtigungen: dolli schrieb: > #!/bin/bash > > # 980 15 17 ; 1000+ 16 63 > # A = $((c * Nheads + h) * Nsectors + (s - 1)) > > #Datei anlegen e.g.: dd if=/dev/zero of=img_new bs=512 count=987840 > > for c in `seq 0 980`; #980 richtig wäre: for c in `seq 0 979`; # da die Zählung der Zylinder bei 0 beginnt > > do > > for h in `seq 0 15`; richtig wäre:: for h in `seq 0 14`; # da die Zählung der Köpfe bei 0 beginnt Rufus Τ. F. schrieb: > M.M.M schrieb: >> dd weiß weder, was ein Dateisystem im "infile" ist, noch was CHS-Werte >> sind. Insofern ist es wurscht, ob das Dateisystem bekannt oder unbekannt >> ist. CHS-Werte sind Sache des Device-Treibers. > > Dann ist dd für die spezifische Aufgabe hier komplett ungeeignet. Das seh ich anders. Es gibt immer mehrere Wege, zum Ziele zu kommen. Der Weg, mittels dd zu lesen/schreiben und in der gewonnen Datei zu mappen (also quasi vorzusortieren) ist analog im täglichen Leben ständig anzutreffen. In der Pralinenschachtel sind die unterschiedlichen Pralinen auch vorsortiert und kommen dann als Ganzes (Schachtel) zu Dir. Gegenbeispiel ist die Einkaufstasche, in die alles unsortiert reinkommt, was vorher sortiert im Regal war. Da sortiert man dann später die einzelnen Artikel in den Kühlschrank usw. Das Ergebnis bleibt sich gleich, man hat in beiden Fällen wohlsortierte Produkte. MfG
Rufus Τ. F. schrieb: > M.M.M schrieb: >> dd weiß weder, was ein Dateisystem im "infile" ist, noch was CHS-Werte >> sind. Insofern ist es wurscht, ob das Dateisystem bekannt oder unbekannt >> ist. CHS-Werte sind Sache des Device-Treibers. > > Dann ist dd für die spezifische Aufgabe hier komplett ungeeignet. Magst du das auch erläutern? recap: Ein altes Laufwerk CHS-only Ein neues Laufwerk LBA+CHS idee war: alte chs auf neue lba umrechen in lba aufspielen mit chs lesen. Das sind nur logische Geometrien und es braucht zwei bekannte Dinge Startposition und Länge zusammenhängender Daten. ein dd if= ohne weitere Angabe (skip,ibs,count) beginnt immer bei position Null fragt nach 512 byte packt sie ohne weitere Angaben an Position 0 des Ziels wiederholt das Ganze zähtl eins weiter etce.. und endet wenn keine Daten mehr kommen. IM Zweifel ob der Kernel wirklich um die auszulesende Platte weis sfdisk -g or --show-geometry List the kernel's idea of the geometry of the indicated disk(s).
1 | It is possible (since Linux 2.1.79) to change the kernel's ideas about |
2 | the geometry by using the /proc filesystem. For example |
3 | |
4 | |
5 | # sfdisk -g /dev/hdc |
6 | /dev/hdc: 4441 cylinders, 255 heads, 63 sectors/track |
7 | # cd /proc/ide/ide1/hdc |
8 | # echo bios_cyl:17418 bios_head:128 bios_sect:32 > settings |
9 | # sfdisk -g /dev/hdc |
10 | /dev/hdc: 17418 cylinders, 128 heads, 32 sectors/track |
11 | # |
Das klappt 100% ein abbild zu erstellen, einzig echte lesefehler könnten da reinpfuschen Aus dem alten http://www.tldp.org/HOWTO/text/Large-Disk-HOWTO weiters, die neue Disk (ATA-2 Konform) betreffend;
1 | An ATA disk must implement both CHS and LBA addressing and |
2 | must at any given time support only one P-CHS at the device |
3 | interface. And, the drive must maintain a strick relationship |
4 | between the sector addressing in CHS mode and LBA mode. Quoting |
5 | the ATA-2 document: |
6 | |
7 | LBA = ( (cylinder * heads_per_cylinder + heads ) |
8 | * sectors_per_track ) + sector - 1 |
9 | |
10 | where heads_per_cylinder and sectors_per_track are the current |
11 | translation mode values. |
12 | |
13 | This algorithm can also be used by a BIOS or an OS to convert |
14 | a L-CHS to an LBA as we'll see below. |
15 | |
16 | This algorithm can be reversed such that an LBA can be |
17 | converted to a CHS: |
18 | |
19 | cylinder = LBA / (heads_per_cylinder * sectors_per_track) |
20 | temp = LBA % (heads_per_cylinder * sectors_per_track) |
21 | head = temp / sectors_per_track |
22 | sector = temp % sectors_per_track + 1 |
23 | |
24 | While most OS's compute disk addresses in an LBA scheme, an OS |
25 | like DOS must convert that LBA to a CHS in order to call INT 13H. |
26 | |
27 | Technically an INT 13H should follow this process when |
28 | converting an L-CHS to a P-CHS: |
29 | |
30 | 1) convert the L-CHS to an LBA, |
31 | 2) convert the LBA to a P-CHS, |
32 | |
33 | If an LBA is required at the ATA interface, then this third |
34 | step is needed: |
35 | |
36 | 3) convert the P-CHS to an LBA. |
37 | |
38 | All of these conversions are done by normal arithmetic. |
Weshalb sollte ein Kopierprogramm das in der Lage ist n-bytes ab Position A in eine andere Datei an Position B zu schreiben dazu nicht geeignet sein. *the drive must maintain a strick relationship between the sector addressing in CHS mode and LBA mode* Die konvertierte Datei wird auf die neu Disk in LBA geschrieben. Von der Disk wird später nur CHS -in den Grenzen 980/15/17- gelesen und geschrieben. Warum nicht direkt? damit das wieder ein linear am Stück schreibbarer Block wird jdf. wenn man es vermeiden will bei dem PQI (nun ja eins mit 512Mb) knapp 1 Mio. Schreibzugriffe durch die notwendige Sektorweise verarbeutng zu verursachen. ---- http://web.archive.org/web/20010702040106if_/http://www.nondot.org:80/sabre/os/files/Disk/CHSTranslation.txt Seh immer noch nicht das das nicht gehen soll ;) Ich stelle das jetzt aber ein. ----- Gibts eigentlich den samstäglichen Computerflohmarkt in Mannheim Industriestraße noch, anyone?
Die einzige Möglichkeit rauszufinden ob Image umsortieren vs. INT13 dasselbe tun ist es auszuprobieren Thomas schrieb: > Unter turbo c stellt bios.h die int13 Funktion zur Verfügung also es gibt den DJGPP compiler, damit könnte man versuchen deinen Sourcecode zu compilieren. http://www.delorie.com/djgpp/ Um das auszuprobieren würde ich dann mit einem vorbereiteten DOS Stick meinen "alten" PC booten und das compilierte programm aufrufen. Könnte die Vorgehensweise so klappen ?
'mal abseits der wohl eher OT dd-"Diskussion": dolli schrieb: > It is possible (since Linux 2.1.79) to change the kernel's ideas about > the geometry by using the /proc filesystem. For example > > # sfdisk -g /dev/hdc > /dev/hdc: 4441 cylinders, 255 heads, 63 sectors/track > # cd /proc/ide/ide1/hdc > # echo bios_cyl:17418 bios_head:128 bios_sect:32 > settings > # sfdisk -g /dev/hdc > /dev/hdc: 17418 cylinders, 128 heads, 32 sectors/track > # Wenn ich das so lese, wäre es da nicht einfach möglich, der neue 512MB-Disk die alten C-H-S Parameter "vorzusetzen", so hier z.B.: cd /proc/ide/ide1/hd_neu_PQI echo bios_cyl:980 bios_head:15 bios_sect:17 > settings und dann das originale dd-Image einfach wieder zurück zu spielen? Oder wo ist da jetzt mein Über-Denkfehler? :-0 PS: Sehe gerade: Oder entspricht das den ganz o.g. fdisk-Befehlen?
:
Bearbeitet durch User
Tom F. schrieb: > also es gibt den DJGPP compiler, damit könnte man versuchen deinen > Sourcecode zu compilieren. > http://www.delorie.com/djgpp/ Hab ich mir gerade angeschaut. Das sollte passen allerdings sind die Return Werte von biosdisk andere, so wie ich das verstehe gibt die Funktion dort nur die AH Werte zurück das musst du anpassen. Unter TC wird AX zurück gegeben. Thomas
Hallo Tom, Tom F. schrieb: > Die einzige Möglichkeit rauszufinden ob Image umsortieren vs. INT13 > dasselbe tun ist es auszuprobieren hier noch eine Idee für die CHS-Mapping-Kontrolle. Du ziehst ein Image von der Platte und spielst händisch oder über ein vorhandenes Midi-In ein Stück, dass Du vom Keyboard aufnehmen lässt. Es ist zu erwarten, dass diese Aufnahme in zusammenhängenden Sektoren auf der alten Festplatte landet. Nun ziehst Du ein zweites Image. Wenn Du dann das alte Image mit dem neuen vergleichst, suche die unterschiedlichen Sektoren. Wenn die veränderten Sektoren aufeinanderfolgen scheint das Image geklappt zu haben. Wenn die unterschiedlichen Sektoren nicht aufeinander folgen, sondern einander in einem bestimmten Abstand folgen, kriegst Du einen Hinweis auf die verwendete Mappinformation.
Was einem bei der Umkopiererei natürlich auch noch 'reingrätschen kann, wäre eine Erkennung der angeschlossenen Festplatte durch den Controller im Keyboard und eine Anpassung an die physikalischen Parameter der Platte. Andererseits scheint dem Controller ja die Möglichkeit zu fehlen, eine "fabrikneue" Festplatte selbst seinen Vorstellungen entsprechend zu initialisieren, aber es könnte natürlich sein, daß der mit verschiedenen "werkinitialisierten" (d.h. durch den Hersteller des Controllers vorbereiter) Platten unterschiedlich arbeitet. Um das genau eingrenzen zu können, müsste man einen Zugriffsanalysator konstruieren, der jeden Zugriff auf einen Sektor mit seinen physikalischen Parametern protokolliert. Das IDE-/ATAPI-Interface ist gut dokumentiert, man müsste sich hier rein lesend an die Daten-, Adress- und ein paar Steuerleitungen klemmen und die relevanten Zugriffe auf Steuerregister ausdecodieren und erfassen. So etwas kann man mit einer größeren Hand voll von LS-/HC-Logikbausteinen und einem µC hinbekommen. Damit ließe sich auch feststellen, ob die vorhandene Festplatte überhaupt zur Gänze genutzt wird, oder ob bereits die für die Aufgabe viel zu groß war und nur ein kleiner, fester Bereich angesprochen wird.
Udo A. schrieb: > Sehe gerade: > Oder entspricht das den ganz o.g. fdisk-Befehlen? sfdisk kann bei weitem mehr. Wenn man das blos alle 10Jahre braucht denkt man auch nicht mehr dran :(
1 | *sfdisk* |
2 | |
3 | |
4 | |
5 | -g or --show-geometry |
6 | List the kernel's idea of the geometry of the indicated disk(s). |
7 | |
8 | -G or --show-pt-geometry |
9 | List the geometry of the indicated disks guessed by looking at |
10 | the partition table. |
fdisk -l und sfdisk -G lesen von der platte, wenn es keine Partitionen zur Aufnahme von Dateisystemen gibt kommt auch nichts zurück. sfdisk -g zeigt die gewählte konfiguration festgelegt während des boot mit Informationen aus dem Bios, das ist die "physische"-chs/lba -------- ein z.B. /proc/ide/ide1/hdc/settings wird es heute nicht mehr geben das wird wahrscheinlich unter /proc/scsi/ zu suchen sein.
Rufus Τ. F. schrieb: > Was einem bei der Umkopiererei natürlich auch noch 'reingrätschen kann, > wäre eine Erkennung der angeschlossenen Festplatte durch den Controller > im Keyboard und eine Anpassung an die physikalischen Parameter der > Platte. Das ist höchst unwahrscheinlich. Die Kopien laufen ja prinzipiell. Ich gehe auch immer noch davon aus dass das Image korrekt ist dd kann ja bei einer Platte die kein LBA kann gar nichts anderes machen. Viel wahrscheinlicher ist es dass die Streckung nicht korrekt ist MMM hat ja schon einen Hinweis gegeben der TO zeigt ja leider nicht wie er das macht. Ob jetzt mit int13 oder mit ẞsector Mapping beide Wege sollten zum Ziel führen. Thomas
michael_ schrieb: > Keiner weiß, was mit der Platte wirklich ist. > Da muß man das Teil vor sich haben. > Darum ging es. Wenn man nicht weiß was mit der alten Platte ist fängt man gleich mit ddrescue an. Eigentlich fängt man am besten grundsätzlich mit ddrescue an wenn man ein Image von einer Platte ziehen will, es gibt ja auch keinen Grund darauf zu verzichten.
:
Bearbeitet durch User
Rufus Τ. F. schrieb: > Was einem bei der Umkopiererei natürlich auch noch 'reingrätschen > kann, wäre eine Erkennung der angeschlossenen Festplatte durch > den Controller im Keyboard und eine Anpassung an die > physikalischen Parameter der Platte. Ich glaube, da ist kein HD-Controller auf dem HD-Interface, zumindest habe ich keinen erkennen können. Braucht es denn einen? Ich denke nicht. Erkennen kann man 256K-Speicher, EPROMs etwas Digital-Zeuch und wohl etwas GAL. Die Anpassung an andere Festplatte sind die C-H-S, die liegen auf der HD und sind im EPROM hinterlegt. Zur Festplatte wird (Denk-Beispiel): setzte Kopf auf CHS 2-3-4, lese/schreibe 2-3-4 per Parallel ATA-Befehl gesprochen. Alles andere macht die "moderne IDE-Festplatte". Die Beschreibung liest sich sogar so, das eben immer Song-Direktory-Weise von/zur Festplatte gearbeitet wird, das gelesen wird im Speicher gehalten und nur als Direktory-Block wieder zurück geschrieben. Dazu kommt noch etwas Titel-Anzeige- "Zauberei". Die Song-Direktory-Anzahl (Blöcke) ist fest auf der Festplatte "vorformatier", ggf. wegen der Songlänge gibt es Zeiger auf andere Speicherbereiche. Es geht wohl "nur" um 128kB-Speicher-"Bewegungen", mehr hat das Keyboard generell(?) nicht. Zeitkritisch ist da nichts... Thomas schrieb: > Viel wahrscheinlicher ist es dass die Streckung nicht > korrekt ist Das ist wohl so. Leider ist es eben nicht verfügbar, da hätte man die neuen 512-Byte-Blöcke z.B. mit den neuen Kopf-Anzahlgrößen/-überschlägen vergleichen können.
:
Bearbeitet durch User
Udo A. schrieb: > Ich glaube, da ist kein HD-Controller auf dem HD-Interface, Damit ist das Ding gemeint, das mit der Platte "redet". Das ist kein Spezialbaustein. > Die Anpassung an andere Festplatte sind die C-H-S, > die liegen auf der HD und sind im EPROM hinterlegt. Was soll das heißen?
Rufus Τ. F. schrieb: >> Die Anpassung an andere Festplatte sind die C-H-S, >> die liegen auf der HD und sind im EPROM hinterlegt. > > Was soll das heißen? z.B. s.o.: Beitrag "Re: Technics Keyboard Festplatte klonen geht das ?" > In Zeile 00000060 stehen die CHS Daten der Platte. und > Wenn man die ändert zeigt das Keyboard "Wrong Eprom Version" und im angehängten Bild ist auch eine Beschriftung mit "HD-Type". Ich gehe damit davon aus, daß wohl die C-H-S Zahl jeweils im EPROM fest hinterlegt ist, wenn es unterschiedliche EPROM- Versionen gibt. Auf der HD sind sie auch noch einmal gespeichert, damit das HD-MEG2000 eben keine anderen HD beschreibt. Sei es jetzt zur Sicherheit bei einer festen Struktur oder als eine Art des "Kopierschutzes". Es könnte selbstverständlich auch noch andere, bessere "Kopierschutz"-Maßnahmen geben, irgend etwas wäre ja schon zu erwarten. Ist natürlich alles spekulativ. PS: Links im Bild, das könnte dann ein 8255 sein. Wenn es mit dem int13 auch nicht gut geht, wären Originalbilder der par.Port-losen HD-MEG2000 sicherlich auch nicht nachteilig...
:
Bearbeitet durch User
Nachtrag zu: Udo A. schrieb: >> und dann das originale dd-Image einfach wieder zurück zu spielen? Wenn das linux noch das alte ide-subsystem benutzt (hdX) villeicht könnte das klappen. > -------- > > ein z.B. /proc/ide/ide1/hdc/settings wird es heute nicht mehr geben das > wird wahrscheinlich unter /proc/scsi/ zu suchen sein. Das wird nicht mehr nach Außen getragen. Bei denen die über sg laufen und sich der libata bedienen, also Laufwerke mit sdX benannt, da läuft das als Nutzer nur noch über passende Tools die ATA befehle über das SCSI (satl) an die IDE-Platten senden oder man muss sich mit Systemprogrammierung auseinandersetzen für den alten Kram. Mit dem alten ide.c treiber geht das, läuft aber vermutlich garnicht auf aktueller Hardware Wenn man mal aktuell Kernelbootparameter nachschaut: # Docs » # The Linux kernel user’s and administrator’s guide » # The kernel’s command-line parameters https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html findet man zwar noch: ide_core.chs=[interface_number.device_number]:cyls,heads,sects *** das läuft aber nat. ins Leere wenn es den passenden Treiber nicht mehr gibt, also grob vlt. seit 10Jahren Geschichte. vlt. bootet ja ein zB. knopppix mit 2.6er smp kernel noch auf Boards im 'legacy-bios mode', halt ohne X und sonstige Peripherie defunkt. --- ***
1 | ide-core.nodma= [HW] (E)IDE subsystem |
2 | Format: =0.0 to prevent dma on hda, =0.1 hdb =1.0 hdc |
3 | .vlb_clock .pci_clock .noflush .nohpa .noprobe .nowerr |
4 | .cdrom .chs .ignore_cable are additional options |
5 | See Documentation/ide/ide.txt. |
Langer Rede kurzer Sinn, wenn z.B. hdparm via satl plausible Werte liefert dann werden die auch stimmen. Einfluss wie auf die Hardware geschrieben wird hat man als user praktisch keinen, gut ist ja auch eher ein Spezialfall absichtlich eine Platte praktisch 'falsch zu adressieren' und zu in Kauf zu nehmen das 3/4 des addressierbaren Speichers ungenutzt bleibt. ----
dolli schrieb: > vlt. bootet ja ein zB. knoppix mit 2.6er smp kernel noch auf > Boards im 'legacy-bios mode', Danke auch für Deinen weiteren Erläuterungen, ich hatte mich beim ersten Beitrag schon bedanken sollen, weil ich die Infos eben auch sehr informativ fand, aber da wir damit schon ziemlich OT sind, hatte ich das erst einmal unterlassen. Da es ja z.Z. gerade 'eh nicht weitergeht, nun... Ich hätte dann auch ein älteres Linux genommen, sogar irgend etwas mit Kernel zwischen 2.2.x und 2.4.x, einfach weil ich jetzt schon mehrfach was von z.B. "C-H-S muß im Kernel einkompiliert sein" gelesen habe. Gerade viele der älteren Sachen sind ja erst aus dem Kernel, dann ggf. noch in Treiber und dann auch aus den Treibern entfallen, weil es eben keiner mehr brauchte/benutzte. Solche Sachen braucht man dann einmal in 10 Jahren, aber ich habe schon das Gefühl, z.Z. wird es doch wieder mehr. Und dann eben auch einen älteren 0-8-15 PC benutzen (nicht Dell/HP/IBM), hier ggf. dann so bis max. Pentium MMX. Ältere knoppix Versionen zu finden, ist ja wohl auch schon immer ein Problem, ich habe mir jetzt 'mal damn-small angesehen, das sollte es dann wohl tun. Oder eben 'n "guten alten" DOS-Sektor-Editor :-) Unabhängig von alle, ich glaube auch, wenn der Beitragsersteller seine 512-Byte-Blöcke sauber 1:1 an die originalen C-H-S-Positionen kopiert, wie auch immer er das "technologisch" ausführt, dann sollte es schon funktionieren. Warten wir es ab, wenn es nicht klappt, dann denke ich, wäre das PQI-Modul wohl der Ansatzpunkt, ich würde da wirklich auch erst einmal 'ne andere Festplatte zum "Prinzip-Test" benutzen...
:
Bearbeitet durch User
Thomas schrieb: > Viel wahrscheinlicher ist es dass die Streckung nicht korrekt ist MMM > hat ja schon einen Hinweis gegeben der TO zeigt ja leider nicht wie er > das macht. Ich habe mal mein gebasteltes Tool angehängt (dazu braucht es dotnet 4.x) Frei nach @dolli's Idee wird alles was grösser als CHS der Originalplatte ist auf der Targetplatte mit 0x00 (oder einem beliebigen anderen Byte) aufgefüllt. Zur Bedienung: Links stellt man die CHS und die Bytes pro Sektor der Originalplatte ein und rechts die CHS und die Bytes pro Sektor der Zielplatte, danach Button Read Image und Write Image. Das Originalimage habe ich ja weiter oben schon eingestellt (Beitrag #5618420) Vielleicht hab ich ja da noch einen Denk bzw. Umsetzungsfehler. Soald ich Zeit habe, probiere ich das mit dem INT13 aus.
:
Bearbeitet durch User
Tom F. schrieb: > alles was grösser als CHS der Originalplatte Das halte ich für falsch. Ich bin der Meinung daß du auf größer gleich testen must. Thomas
Thomas schrieb: > Ich bin der Meinung daß du auf größer gleich > testen must. Wie meinst du das ? Momentan mach ich das so: Alte Platte: CHS 980/15/17 Neue Platte: CHS 1001/16/63 0/0/1 bis 0/0/17 wird 1:1 auf das neue Image kopiert. dann 0/0/18 - 0/0/63 mit 0x00 auffüllen 0/1/1 bis 0/1/17 wird 1:1 auf das neue Image kopiert. dann 0/1/18 - 0/1/63 mit 0x00 auufüllen . . . dann 0/15/1 bis 0/15/63 mit 0x00 auffüllen 1/0/1 bis 1/0/17 wird 1:1 auf das neue Image kopiert. . . . und zum Schluss 980/0/1 bis 1001/15/63 mit 0x00 auffüllen
:
Bearbeitet durch User
Hier gibt es noch ein altes DOS-Programm welches, falls es auf der gerade verwendeten Hardware läuft, geeignet sein könnte das erstellte image zu vergleichen. Ist aber mit Vorsicht zu geniesen. "Doku" leider nur teils in englischer Sprache. (tof to file o.ä. ff vermutlich from file hilfe nach kurzer Dursicht aber nur in russisch) http://mybrainwillexplode.com/abandonware/util/diag/mhdd-2-9-mhdd-3-0-chs-hard-drive-test-utility/
Tom F. schrieb: > /0/1 bis 0/0/17 wird 1:1 auf das neue Image kopiert. > dann 0/0/18 - 0/0/63 mit 0x00 auffüllen Naja eine Platte mit 17 Sektoren bedeutet aber das Sektor 0..16 kopiert werden müssen nicht 0..17. Das ist das klassische of by one Problem. Thomas
Thomas schrieb: > Naja eine Platte mit 17 Sektoren bedeutet aber das Sektor 0..16 kopiert > werden müssen nicht 0..17. Das ist das klassische of by one Problem. Denk noch 'mal nach: 1.) es gibt keinen Sector 0, Sectoren werden immer ab 1 beginnend gezählt. C/H/S 0/0/0 gibt es nicht 2.) Es ist hier aber auch völlig "wurscht", ab Du den 1. Sektor mit 0 oder 1 oder A oder Würfelzucker1 bezeichnet, hier geht es darum (bei den Sektoren), 17-mal 512-Byte-Blöcke aus dem 1. Image in das 2. Image zu kopieren, genauer gesagt z.B. für den ersten 512-Byte-Block den auch an die 1. Stelle des neuen dd-Images zu kopieren. Ein dd-Image ist hier eine Anreihung von 512-Byte-Blöcken, ohne Trenner oder Block-Abgrenzung oder (internen) Sektorzählungen. Die alte Platte wird (hoffentlich) mit C-H-S 980-15-17 angesprochen, also werden da z.B. 17 Stück 512-Byte-Blöcke für die ersten Sectoren kopiert, ob man die jetzt von 0 bis 16 oder von 1 bis 17 zähle ist da ja wohl egal, die ersten 17 Stück müssen es sein.
:
Bearbeitet durch User
Thomas schrieb: > Tom F. schrieb: >> /0/1 bis 0/0/17 wird 1:1 auf das neue Image kopiert. >> dann 0/0/18 - 0/0/63 mit 0x00 auffüllen > > Naja eine Platte mit 17 Sektoren bedeutet aber das Sektor 0..16 kopiert > werden müssen nicht 0..17. Das ist das klassische of by one Problem. > Thomas Falsch, die Sektorzählung beginnt bei 1. Es wird also von 1..17 gezählt. Ja, das macht einen Unterschied zu 0..16. Würde die Zählung bei 0 beginnen, ergäbe die Berechnung CHS -> lba für den ersten Sektor -1. MfG
Da ich bis jetzt ja wohl der Erste bin, der das gebasteltes Tool vorgestern auch runtergeladen und ausgetestet hat: Für mich sieht das Ergebnis, mit dem neuen (Tool-ausgeworfenen) Image, soweit richtig aus. Getestet (also nur "händisch" angesehen) habe ich die jeweiligen ersten sectoren- und head-Umschläge mit den jeweiligen Original-512-Blöcken, die passen für mich soweit. Auch die Anzahl der head und sectoren passen mit den jeweiligen Original-512-Blöcken des Original-Image wohl soweit zusammen. Bei den cylinder habe ich nur den ersten und den letzten mit den jeweiligen Original-512-Blöcken des Original-Image verglichen, aber auch die scheinen da zu passen. Da ich das nur schnell "händisch" im Hex-Editor angesehen und auch nur "händisch mitgezählt" habe, sollte das kein Computervergleich sein, es sieht aber für mich alles soweit i.O. aus. Ggf. kann ja ein besser Linux-Bewanderter da 'mal einen 512-Byte-Block diff o.ä. mit dem alten dd-Image und dem neuen Tool-ausgeworfenen Image machen, um das damit ggf. zu bestätigen (oder eben nicht...). :-)
:
Bearbeitet durch User
Ich habe dann auch noch einmal nach alten Software-Schätzen gesucht und bin auf die kostenlose Version des "Active Disk Image 2.1 for DOS" gestoßen. Die Software erlaubt unter DOS per Einstellung von C/H/S das sectorweise Image einer Festplatte. Dieses Image wäre damit wohl als Vergleich zur dd-Image-Version der Original-Festplatte zu benutzen. Zumindest könnte man es damit ja einmal gegentesten... Hier, auf dieser Seite ganz unten: http://www.lsoft.net/diskimage.aspx
Nachdem sich dessen keiner annehmen mochte, ************************************************* Die weiter oben verlinkte Seite enthält malware JS Ein Mod. den Link bitte ggf. entfernen. Die Seite mit deaktivierten JS anzusteuern sollte unproblematisch sein. Die dort zu findenden alten mhdd versionen scheinen clean, virustotal.com/de ************************************************** Beitrag "Re: Technics Keyboard Festplatte klonen geht das ?" Das wurde seinerzeit mit jedem update zur Freeware, der Autor ist wohl bei hddguru.com aktiv oder sogar dessen Urheber. ggf. wget o.ä. dann halt nochmal untern virenscanner ;) mybrainwillexplode.com/abandonware/wp-content/uploads/2017/06/mhdd2932.z ip mybrainwillexplode.com/abandonware/wp-content/uploads/2017/06/mhdd30-spa ces.ru_.zip mybrainwillexplode.com/abandonware/wp-content/uploads/2017/06/mhdd29.zip mybrainwillexplode.com/abandonware/wp-content/uploads/2017/06/MHDD.ver_. 3.0.zip mybrainwillexplode.com/abandonware/wp-content/uploads/2017/06/MHDD-2.9.z ip SORRY, shit happens ;)
Zum Clonen kann man aber auch Paragon nehmen. Ist free. In irgendeinem Link dieses Treads bfindet sich laut anderen Usern ein VIRUS vieleicht kann da mal jemand was dran ändern
Udo A. schrieb: > Ich hätte dann auch ein älteres Linux genommen, sogar irgend etwas > mit Kernel zwischen 2.2.x und 2.4.x, einfach weil ich jetzt > schon mehrfach was von z.B. "C-H-S muß im Kernel einkompiliert > sein" gelesen habe. Ein Experiment: spasseshalber mal probiert: alte 610 MB WDC AC2635F asus v7, slackware 12.2, kernel 2.6.29 kernel /boot/vmlinuz root=/dev/hda3 ro vga=normal ide_core.chs=0.1:980,15,17 $cat /proc/ide/ide0/hdb/geometry physical 1240/16/63 logical 980/15/17 <------ $dd if=/dev/zero of=/dev/hdb $dd if=KN2000DiskImage.img of=/dev/hdb 249900+0 records in 249900+0 records out 127948800 bytes (128 MB) copied, 104.1 s, 1.2 MB/s reboot ohne param. ide_core.chs=0.1:980,15,17 $cat /proc/ide/ide0/hdb/geometry physical 1240/16/63 logical 1240/16/63 <------ $bc <<< 'obase=16;17*512-16' 21F0
1 | $hexdump -s 0x21F0 -n 64 -C /dev/hdb |
2 | 000021f0 20 20 20 20 20 20 20 20 20 20 20 ff ff ff ff ff | ÿÿÿÿÿ| |
3 | 00002200 96 62 00 6d 00 14 00 90 00 26 6e 13 00 90 30 69 |.b.m.....&n...0i| |
4 | 00002210 64 0a 00 90 30 30 69 0b 00 90 30 32 69 09 00 90 |d...00i...02i...| |
5 | 00002220 48 69 5c 0e 00 81 90 00 30 6e 10 00 90 00 69 7f |Hi\.....0n....i.| |
6 | 00002230 |
gleicht dem .img 'Vorgaukeln' funktioniert mit IDE Laufwerken nicht. Es ist auch vollkommen egal was man als Parameter im BIOS angibt, ob auto, user-type etc. vollkommen uninteressant. $cat /proc/ide/ide0/hdb/driver ide-disk version 1.18
dolli schrieb: > Ein Experiment > ... > ...'Vorgaukeln' funktioniert mit IDE Laufwerken nicht Nun, eigentlich besagt Dein Experiment ja nur, mit dem Linux-Kernel v.2.6.29 (Stand 2009) und ide-disk v.1.18 geht es auch nicht (mehr?). "Deine" alte Large-Disk-HOWTO ist max. von 2004, zumindest damals scheint es ja (noch?) funktioniert zu haben: > It is possible (since Linux 2.1.79) to change the kernel's > ideas about the geometry by using the /proc filesystem... Dann kommen da aber wohl die erste Einschränkungen: > Since Linux 2.6.5 the kernel will... Deshalb hätte ich da eben auch nur mit einem Linux zwischen Kernel 2.1.79 und 2.6.5 experimentiert, um das dann genauer auszutesten. Ggf. ist es ja auch dort noch zusätzlich möglich, dem ide-disk-Driver zu sagen: Nutze für das Rückschreiben (mit dd) jetzt gefälligst nur die geometry, die ich dir hier "mühsam vorgaukle"!? Keine Ahnung, ob das so jemals funktioniert hat oder könnte, zumindest "Deine" alte Large-Disk-HOWTO von 2004 liest sich aber wohl doch so, irgendwie...
:
Bearbeitet durch User
Udo A. schrieb: > Keine Ahnung, ob das so jemals funktioniert hat oder könnte, > zumindest "Deine" alte Large-Disk-HOWTO von 2004 liest sich aber > wohl doch so, irgendwie... Jo ist wohl zu jung, was aelteres hab ich grad nicht... ;) ~ der erste hd.c dann ide.c dann ide-disk.c u. ide-scsi.c, .... Das bezieht sich auf den "ide" Treiber https://www.kernel.org/doc/Documentation/ide/ide.txt sonst findet sich dort nicht viel weiters unter ../ zu "ide-disk" bleibt wohl nur in ide-disk.c zu sehen. Ein paar Sachen kann man sich auch als nicht Spezi ausgucken. Jedenfalls z.B. das LBA nur dann nicht verwendet wird wenn das LW es nicht kann ansonten immer auch kein Hinweis auf sonstige optionale Parameter.
Ich hab gestern Mal mit dem Tool von Tom gespielt und mir ein gestreckten Image erstellt. Dieses Image habe ich dann mit dem Programm im Anhang wieder reduziert. Ergebnis das Image entspricht dem Original. Das lässt für mich nur den Schluss zu dass mit dem Original was nicht stimmt. Thomas
Moin, ich würde 1. Die alte Platte an einem relativ alten Rechner, also 386 oder 486, betreiben. Bei denen kann man fast immer die Plattengeometrie im BIOS einstellen. 2. Dann eine ähnlich alte/gebrauchte Ersatzplatte (auch CHS) besorgen - oben wurden ja einige angeboten. Die CHS-Werte müssen aber größer oder gleich sein. 3. Eine Sektor zu Sektor Kopie machen (mit altem Tool). 4. Die geklonte Platte einbauen, wenn sie funktioniert, dann kann man weitersehen. 5. Gleiches Spiel mit Festplatte CHS/LBS probieren. Ich würde stark vermuten (ohne es geprüft zu haben), daß sämtliche "modernen" Festplatten gar keine Adressierung über CHS mehr zulassen. Als damals(TM) die 540 MB Festplatten aufkamen, hatten die einen Jumper, um sich per Hardware auf 504 MB CHS umstellen zu lassen. Das hätte man sicherlich nicht gemacht, wenn die größeren Platten einfach mit geringerer Kapazität gelaufen wären - die gingen ohne den Jumper gar nicht.
Thomas schrieb: > Das lässt für mich nur den Schluss zu dass mit dem Original was nicht > stimmt. Da könntest du Recht haben. Siehe meine Erkenntnisse weiter unten... Udo A. schrieb: > Ich habe dann auch noch einmal nach alten Software-Schätzen gesucht > und bin auf die kostenlose Version des "Active Disk Image 2.1 for DOS" > gestoßen. Danke für den Link, habe ich probiert, das DOS Programm gibt mir gleich mal einen ReadError Sector 0 aus (ich dachte Sektor zählt man ab 1). Ausserdem gibt es Read Errors für alle durch 17 Teilbaren Sectoren 17,34,51... usw. Wenn man "Ignore All" wählt wird das Image erstellt. Wenn man nun das alte Image (Linux dd) und das mit DOS Erstellte vergleicht sieht man dass vor dem ersten Sektor noch ein Sektor geschrieben wird. dd scheint also alles was nicht lesbar ist zu verschlucken ?
:
Bearbeitet durch User
Tom F. schrieb: > dd scheint also alles was nicht lesbar ist zu verschlucken ? Offenbar ist das hier geschehen :( Der Rechner hat ein "echtes" PCI-IDE Interface, was für ein Board und Architektur ist das denn? ----- Beitrag "Re: Technics Keyboard Festplatte klonen geht das ?" >>> Nochmal ein image anfertigen und vergleichen mit dem vorhandenen. >>> # dd if=/dev/... of=/.. bs=512 conv=sync,noerror Das stammt von ddpt, einer erwiterten dd Variante: (ist auch etwas ausführlicher Dokumentiert als dd) http://sg.danny.cz/sg/ddpt.html
1 | |
2 | |
3 | coe for block devices and regular files |
4 | |
5 | Continue on error (coe) can be requested for input block devices or regular files. It is ignored for output block devices and regular files meaning that any error on such an output file will terminate the copy. |
6 | |
7 | The standard dd command also has a "continue on error" facility. These two invocations are roughly the same: |
8 | ddpt if=/dev/sdc iflag=coe of=sdc.img bs=512 |
9 | dd if=/dev/sdc of=sdc.img bs=512 conv=noerror,sync |
10 | |
11 | Without the 'count=COUNT' option the whole of /dev/sdc will be copied to sdc.img . The 'noerror' argument to 'conv=' tells dd to continue on error and the 'sync' tells it to supply zeros for blocks that can not be read. If the 'sync' is not given then the image file will be shorter when errors are detected. As a convenience ddpt will accept 'conv=noerror,sync' to mean 'iflag=coe '. So the following invocation (followed by its output) is equivalent to the two above: |
12 | ddpt if=/dev/sdc of=sdc.img bs=512 conv=noerror,sync |
13 | 16376+8 records in |
14 | 16384+0 records out |
15 | 8 unrecovered read errors |
16 | lowest unrecovered read lba=4656, highest unrecovered lba=4663 |
17 | time to transfer data: 5.822152 secs at 1.44 MB/sec |
und die Variante ddrescue ist einfach darauf getrimmt den Lesevorgang x-mal zu wiederholen ob nicht doch noch etwas zu lesen ist. --- vlt. hilft das etwas das einzuordnen.
Tom F. schrieb: > Thomas schrieb: >> Das lässt für mich nur den Schluss zu dass mit dem Original was nicht >> stimmt. > > Da könntest du Recht haben. Siehe meine Erkenntnisse weiter unten... Nun ich muss mich korrigieren. Dass das Original nicht okay ist ist eine Möglichkeit. Die zweite ist dass dd beim zurück schreiben was falsch macht. Der Geister Sektor den du liest stammt sicher nicht von der Keyboardplatte da ist der String NTFS zu finden. Ich Versuche morgen ein simples kopierprogramm hier einzustellen was die Sektoren per int13 kopiert. Das Programm ist schon fertig ich muss nur noch ein paar Fehler Meldungen einbauen. Thomas
dolli schrieb: > Tom F. schrieb: > >> dd scheint also alles was nicht lesbar ist zu verschlucken ? > > Offenbar ist das hier geschehen :( > Nö, eigentlich nicht. Denn wie schon weiter oben angeführt $ ls -an /mnt/disk1/vid-temp/KN2000DiskImage.img -rw-r--r-- 1 1001 1001 127948800 2018-12-04 22:09 /mnt/disk1/vid-temp/KN2000DiskImage.img $ echo $((127948800/(980*15*17*512))) 1 Die größe stimmt und das passt nicht zusammen mit:
1 | The 'noerror' argument to 'conv=' tells dd to continue on error and the 'sync' tells it to supply zeros for blocks that can not be read. If the 'sync' is not given then the image file will be shorter when errors are detected. |
Da sollte nichts ausgelassen worden sein, wenn der Aufruf ohne zus. Parameter geschah, von sich aus füllt der doch nichts auf.
Tom F. schrieb: > dd scheint also alles was nicht lesbar ist zu verschlucken ? Zumindest die sector-Anzahl im ersten dd-original-Image stimmt doch mit der Gesamtsektor-Anzahl der Original-Festplatte (249900) überein, also hat dd da doch wohl alle sector-Daten gelesen. Ob die stimmen und/oder in der richtigen Reihenfolge vorliegen, ist aber immer noch eine nicht untersuchte Frage. Das wäre ja z.B. testweise per Disk-Editor möglich... Wenn alle 17 Sectoren ein Lese-Fehler auftritt, dann paßt irgend etwas mit oder auch durch das "Active Disk Image 2.1 for DOS" nicht. Tippen würde ich da auf z.B. "Active Disk Image 2.1 for DOS" spricht C-H-S, Dein PC-IDE-Controller nicht/nicht mehr/mit Fehlern. Eingestellt hast Du C-H-S aber in "Active Disk Image 2.1 for DOS"? Du könntest es aber auch einfach mit den automatisch erkannten Parametern in "Active Disk Image 2.1 for DOS" versuchen, zumindest sollte da ja auch ein Image entstehen, das man mit dem dd-Image vergleichen könnte. "Active Disk Image 2.1 for DOS" könnte auch einfach einen Programmier- fehler haben, andererseits wäre das denen in ehemals 10 Jahren Entwicklung wohl schon aufgefallen... Unabhängig von allen, es sieht ja da so aus, daß Du dabei mindesten 2 Festplatten an Deinem PC-IDE-Controller hast (wie?/warum?)! Sauber aufgeteilt auf die beiden Kanäle des IDE-Kontroller und ggf. auch sauber Master/Slave-eingestellt hast Du die Festplatten aber? Was ist das für ein PC/Mainboard/ATA-Controller? Wie/Was bootest Du? Was/Wie ist im Bios eingestellt? usw. usw. Ohne genauen Angaben Deinerseits ist das aber hier ja alles schon wie "Laufen im Nebel". z.B. ist doch wohl der "nullte" Sektor bestimmt von Deiner anderen boot-Festplatte, warum? "Bootest" Du etwa aus einer Emulation? Deine originale MEG2000-HD hat doch: Sectors per track 17 Was passiert bei Einstellung von CHS mit testweise 16 sectoren in "Active Disk Image 2.1 for DOS" und was ist das dann für ein Image? Wenn wir aber einmal annehmen, Dein dd-Image ist soweit i.O., dann wird wohl Deine "gute" PQi-Flash-HD die Fehlerquelle sein, nimm doch ersteinmal eine richtige Festplatte zum austesten. Ältere (wohl auch noch per C-H-S-ansteuerbare) 20GB/40GB 2.5zoll HD gibt es für unter 10 Euro, andere Lösungen kannst Du dann ja immer noch ausprobieren. Auch über 5.25zoll z.B. 2.1GB HD (per Netzteil/Adapter) könnte man bei entsprechender Vorsicht nachdenken. Zumindes würde ich auch jeder (ggf. älteren) CompactFlash Card mehr IDE-Kompatibilität zutrauen als dem PQI-Flash... Auch saubere Fotos (beidseitig) Deines HD-MEG2000-Interfaces wären schön, da könnte man versuchen, z.B. eine 8bit-ATA-Daten-Ansteuerung der Original-Festplatte zu erkennen/auszuschließen. usw. usw.
:
Bearbeitet durch User
Udo A. schrieb: > Ob die stimmen und/oder in der richtigen Reihenfolge vorliegen, ist > aber immer noch eine nicht untersuchte Frage. > Das wäre ja z.B. testweise per Disk-Editor möglich... > Das sind 128Mib das saugt der doch weg wie ein Kokser ;) Falls GiB o. TiB dann vlt. iflag=direct [use direct I/O for data] und ggf. ein cache abwurf um Platz zu schaffen.
1 | wie gesagt ddpt ist ein superset von dd das angesprochene pt-flag grad mal ignorieren aber das greift gleichzeitig noch das andere angesprochene Problem auf. |
2 | |
3 | |
4 | ... |
5 | |
6 | NOTES |
7 | Copying data behind an Operating System's back can cause problems. |
8 | |
9 | ... |
10 | |
11 | Block devices (e.g. /dev/sda and /dev/hda) can be given for IFILE. If neither 'iflag=direct' |
12 | nor 'iflag=pt' is given then normal block IO involving buffering and caching is performed. If |
13 | 'iflag=direct' is given then the buffering and caching is bypassed (this is applicable to both |
14 | SCSI devices and ATA disks). When 'iflag=pt' is given SCSI commands are sent to the device which |
15 | bypasses most of the actions performed by the block layer. The same applies for block devices |
16 | given for OFILE. |
17 | |
18 | ... |
Auf meinem alten Rechner zeigt ein direktes hexdump -C /dev/hdX nichts anderes als das was sich in einem in einer Datei gespeicherten Abbild befindet.
dolli schrieb: > Auf meinem alten Rechner zeigt ein direktes hexdump -C /dev/hdX > nichts anderes als das was sich in einem in einer Datei > gespeicherten Abbild befindet. Das ist doch damit auch nichts anderes, als das jeweilige dd: Zugriff per (gleichen) Treiber auf die HD Wenn dabei nicht gleiche Ergebnisse raus kommen, wo dann? Das wäre so wohl kein Vergleich. Deswegen hätte ich zum Testen ein Image/Hexeditor mit einem anderen "Bezugsweg" der Daten (Dos/Bios/anderes OS/sehr altes OS/ anderer PC/sehr alter IDE-Controller usw.) benutzt. Aber schon weit vorher einfach das PQI-Flash durch eine andere (ggf. Test-) Lösung ersetzt (s.o., unter Beachtung der dann ggf. notwendigen höheren CHS-Anzahl und Image-Anpassungen)...
:
Bearbeitet durch User
Udo A. schrieb: > dolli schrieb: >> Auf meinem alten Rechner zeigt ein direktes hexdump -C /dev/hdX >> nichts anderes als das was sich in einem in einer Datei >> gespeicherten Abbild befindet. > > Das ist doch damit auch nichts anderes, als das jeweilige dd: > Zugriff per (gleichen) Treiber auf die HD > Wenn dabei nicht gleiche Ergebnisse raus kommen, wo dann? Auch wieder wahr. Allerdings die verwendete Platte stammt auch der ersten Generation, 40MB WD "RawCHS=980/5/17" und wie gesagt kein BIOS Übersetzungen etc. Kein problem image zu ziehen alles mit FF oder NULL zu schreiben eint extFS einzurichten und das ganze zurück auf Original. > Das wäre so wohl kein Vergleich. > > Deswegen hätte ich zum Testen ein Image/Hexeditor mit einem > anderen "Bezugsweg" der Daten (Dos/Bios/anderes OS/sehr altes OS/ > anderer PC/sehr alter IDE-Controller usw.) benutzt. > Aber schon weit vorher einfach das PQI-Flash durch eine andere > (ggf. Test-) Lösung ersetzt (s.o., unter Beachtung der dann ggf. > notwendigen höheren CHS-Anzahl und Image-Anpassungen)... wenns unbedingt DOS sein soll vlt. gehts ja auch mit dem aktuellen mhdd
1 | http://real-world-systems.com/docs/MHDD_en_manual.html |
2 | How it works |
3 | |
4 | When DOS needs to read a sector from a drive , it asks the BIOS to do it. The BIOS looks into its tables to find where that drive is attached, checks ranges and then starts sending commands to the drive. After everything is done BIOS returns result to DOS. |
5 | |
6 | This diagram shows how a DOS program talks to the drive. |
7 | |
8 | program <---> MSDOS <---> BIOS <---> IDE/SATA controller <---> Hard disk |
9 | |
10 | This is how MHDD works: |
11 | |
12 | MHDD <--------------------------------> IDE/SATA controller <---> Hard disk |
13 | |
14 | The main difference: MHDD does not use DOS or BIOS functions or interrupts and works even if the BIOS does not detect the drive. You can turn on your drive after DOS boots (A small risk of drive damage exists if you are not careful) |
15 | . MHDD works directly with IDE or Serial ATA controller so it does not know about partitions, file systems, BIOS (motherboard) limitations, etc. |
16 | For SCSI drives MHDD uses DOS ASPI driver (incuded). |
17 | |
18 | WARNING: Do not run MHDD from the hard drive that is on the same physical IDE channel (cable) you are going to use to diagnose drives! DOS (SMARTDRV.EXE, for example) may access any drive at the same moment as MHDD. |
19 | This will cause data loss on both devices on that channel! There is no way to block or trace MSDOS or BIOS read/write attempts. That is why, by default, MHDD does not work with Primary IDE as it usually used to boot DOS and run MHDD. |
20 | |
21 | If the drive under test is on the Primary IDE interface use /ENABLEPRIMARY switch. (this is included in the CD image) |
22 | |
23 | Platform and supported hardware |
24 | |
25 | * Platform: DR-DOS , MSDOS version 6.22 included on CD image |
26 | |
27 | * Hardware Intel Pentium or higher CPU |
28 | * boot device (USB, CDROM, FDD, HDD) |
29 | |
30 | * IDE/SATA Controllers Any integrated into motherboard north bridge (addresses: 0x1Fx for primary channel, 0x17x for secondary channel) |
31 | * PCI UDMA boards (detected automatically): HPT, Silicon Image, Promise, ITE, ATI and so on. Some RAID boards are supported. In this case MHDD works with each physical drive separately |
32 | * UDMA/RAID controllers integrated into motherboard as additional chip |
33 | |
34 | Hard disk drives |
35 | |
36 | * IDE or Serial-ATA drive with size bigger than 600Mbytes, i.e. LBA mode is supported in full.removed CHS code since version 2.9 |
37 | * IDE or Serial-ATA drive with size smaller than 8,388,607 TBytes, i.e. LBA48 mode is supported. |
38 | * SCSI drive with sector size 512—528 bytes |
39 | |
40 | * Other devices Any SCSI removable media such as tape, CDROM. Maximum sector size for such devices is 4096 bytes |
dolli schrieb: > wenns unbedingt DOS sein soll vlt. gehts ja auch mit > dem aktuellen mhdd Aber eben nicht mehr per CHS! > Hard disk drives > > * IDE or Serial-ATA drive with size bigger than 600Mbytes, > i.e. LBA mode is supported in full. removed CHS code since > version 2.9 ----> ATA drive with size bigger than 600Mbytes ----> removed CHS code since version 2.9 Also sollte es wohl besser auch irgend etwas kleiner als Version 2.9 sein... Findet man das noch irgend wo, virenfrei? Die letzten Versionen (v.4.x) sind ja unter: http://hddguru.com/software/2005.10.02-MHDD/ zu finden. Unabhängig von allen, ich glaube z.Z. nicht, daß das Image das z.Z. wichtige Hauptproblem ist (s.o.).
:
Bearbeitet durch User
Hier wie versprochen das kopierprogramm. Readme beachten! Thomas
Udo A. schrieb: > Unabhängig von allen, es sieht ja da so aus, daß Du dabei mindesten > 2 Festplatten an Deinem PC-IDE-Controller hast (wie?/warum?)! > Sauber aufgeteilt auf die beiden Kanäle des IDE-Kontroller und > ggf. auch sauber Master/Slave-eingestellt hast Du die Festplatten > aber? > Was ist das für ein PC/Mainboard/ATA-Controller? > Wie/Was bootest Du? > Was/Wie ist im Bios eingestellt? > usw. usw. Dazu habe ich mal die Bilder abgehängt. Wie man sieht kann man im BIOS den CHS Mode einstellen (habe ich jetzt für beide Platten gemacht, stand vorher auf Auto) Die Geometrie der Platten wird einwandfrei erkannt.(IDE Primary Master 980/15/17, IDE Secondary Master 1001/16/63). Nun habe ich versucht nicht den Umweg über das Image zu gehen sondern beide Platten direkt an die IDE Ports gehängt, Knoppix 8.2 gebootet und dann: dd if=/dev/sda of=/dev/sdb gestartet Ergebnis: Auf der Zielplatte sind wieder nur die ersten ca 122MB beschrieben, d.h. dd kopiert das einfach alles vorne hin ohne auf CHS zu achten. Udo A. schrieb: > Was ist das für ein PC/Mainboard/ATA-Controller? lspci|grep -i ide ergibt: 00:0f.0 IDE interface: VIA Technologiesls, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
Thomas schrieb: > Hier wie versprochen das kopierprogramm. Readme beachten! Super, danke für die Mühe. Habs direkt mal ausprobiert. Habe mir dazu einen DOS (FreeDos)Boot Stick gemacht von Rufus. https://rufus.ie/downloads/ k2copy -i ergibt: drive0 not found status: 0x180 drive1 not found status: 0x100 drive2 not found status: 0x100 drive3 not found status: 0x100 Habe ich das Falsche DOS ?
Das bedeutet das die Funktion 25h bei dir nicht geht und die Parameter deshalb nicht gelesen werden..oder dass ich da noch einen Fehler habe. Trotzdem kannst du das Kopieren starten das Programm nimmt dann die Parameter der defines Thomas
Tom F. schrieb: > Ergebnis: Auf der Zielplatte sind wieder nur die ersten ca 122MB Wieder? Jetzt mag das so sein. Das image hier hochgeladen zeigt entpackt eine Größe von 127948800 Bytes. Autor: Tom F. (tomfox) Datum: 11.11.2018 19:15 Angehängte Dateien: * KN2000DiskImage.rar (5,87 MB, 15 Downloads) An etwas anderes kann man sich nunmal zunächst nicht halten. > beschrieben, d.h. dd kopiert das einfach alles vorne hin Oben doch anscheinend nicht und würde es nur wenn Daten ausbleiben. Setz doch mal die Flags conv=noerror,sync dann kannst du auch an den Meldungen sehen ob es Bereiche gibt die nicht gelesen werden konnten und aufgefüllt wurden was er von alleine ganz sicher nicht macht. Die Bereiche die zu lesen waren sollten dann auch in der richtigen Reihenfolge sitzen. Dann sollte auch eine entsprechende Ausgabe kommen x ganze + y teil Blöcke gelesen. Oder nimm ddrescue aber auch dort wird man ggf. die man-page lesen müsen und kann nicht erwarten das das alles mit default-parametern funktioniert. > ohne auf CHS zu > achten. > > Beim schreiben in eine Datei sowieso nicht, nie. >> dann: dd if=/dev/sda of=/dev/sdb gestartet lese im thread, die manpages, frag auf stackexchange, ...
1 | The 'noerror' argument to 'conv=' tells dd to continue on error and the 'sync' tells it to supply zeros for blocks that can not be read. If the 'sync' is not given then the image file will be shorter when errors are detected. |
---- @Udo A. Jo, 600 wird nicht die Mindestgröße sein und das doc ist eine zusammengeflickte übersetzung aus dem russischen. >>> ----> ATA drive with size bigger than 600Mbytes >>> ----> removed CHS code since version 2.9 so wird das berichtet >>> Also sollte es wohl besser auch irgend etwas kleiner als >>> Version 2.9 sein... und von daher, GOTO ... ;) >>> Findet man das noch irgend wo, virenfrei? Oben, da gibts keinen Virus, ldgl. ein Stück JS welches einen Miner starten möchte, ganz und garnicht Nett aber nichts das sich irgendwo festsetzt.
k2copy test: Habe zum Testen sicherheitshalber die 2 PQI Module angehängt, damit die Originalplatte nicht aus versehen überschrieben wird. PQI 128MB hat das alte -mit dd geschriebene- Originalimage drauf. 0x81: PQI 128MB 500/16/32 0x82: PQI 512MB 1001/16/63 k2copy -s1 -d2 read failed with status 0x400 ... at sector 0
dolli schrieb: > Setz doch mal die Flags conv=noerror,sync d dolli schrieb: > Oder nimm ddrescue ddrescue zeigt 0 Fehler, das eben erstellte ddrescue Image ist identisch mit dem dd Image, sollte also nicht das Problem sein. Das mit den Bad Sectors wurde ja nur vom DOS Tool ausgegeben. knoppix@Microknoppix:~$ ddrescue /dev/sda /media/sdh/myfloppy.img /media/sdh/myfloppyddrescue_log GNU ddrescue 1.22 ipos: 127926 kB, non-trimmed: 0 B, current rate: 350 kB/s opos: 127926 kB, non-scraped: 0 B, average rate: 830 kB/s non-tried: 0 B, bad-sector: 0 B, error rate: 0 B/s rescued: 127948 kB, bad areas: 0, run time: 2m 33s pct rescued: 100.00%, read errors: 0, remaining time: n/a time since last successful read: n/a Finished
Das sollte sich doch jetzt für dich auf dieser Hardware ein für alle mal klären lassen ob das Abbild dem Original entspricht: https://www.virustotal.com/de/file/55278058ce0caa88dec6fee08f25fd78abad27df9b68c9d15ecd8310203e6394/reanalyse/?filename=mhdd2932.zip
1 | This file was last analysed by VirusTotal on 2018-12-03 17:24:37 UTC (6 Tage, 22 Stunden ago) it was first analysed by VirusTotal on 2018-12-03 17:24:37 UTC. |
2 | |
3 | Erkennungsrate: 0/59 |
4 | |
5 | Sie können sich die vormalige Analyse ansehen oder erneut eine Analyse beginnen. |
Hallo Tom F. schrieb: > Wenn man nun das alte Image (Linux dd) und das mit DOS Erstellte > vergleicht sieht man dass vor dem ersten Sektor noch ein Sektor > geschrieben wird. > dd scheint also alles was nicht lesbar ist zu verschlucken ? Auf die Idee, daß das Dos-Tool murkst, kommst Du erst gar nicht? Dabei springt einem geradezu ins Auge, daß mit Sektorversatz geschrieben wird und ein alter NTFS-Bootsektor übrig bleibt. Tom F. schrieb: > Wie man sieht kann man im BIOS den CHS Mode einstellen (habe ich jetzt > für beide Platten gemacht, stand vorher auf Auto) > Die Geometrie der Platten wird einwandfrei erkannt.(IDE Primary Master > 980/15/17, IDE Secondary Master 1001/16/63). Deine Bilder sagen was anderes. Warum kommst Du nicht mit passenden Bildern, passenden Plattennamen und woher stammen überhaupt die eingetragenen Geometrien. Wie soll ein Außenstehender Deine Beiträge nachvollziehen, wenn sie in sich nicht stimmig sind? > Nun habe ich versucht nicht den Umweg über das Image zu gehen sondern > beide Platten direkt an die IDE Ports gehängt, Knoppix 8.2 gebootet und > dann: > dd if=/dev/sda of=/dev/sdb gestartet Soweit, so gut. Aber was ist Dein Ziel, was willst Du erreichen? Vor allen unter Nutzung der oben angegebenen Geometrien. Ok, man kann nach Abarbeitung des Kommandos die Inhalte beider Platten vergleichen und wenn die übereinstimmen, hat dd korrekt gearbeitet. Wer's braucht? dd wird jetzt seit geschätzt nahezu 50 Jahren wahrscheinlich täglich zig millionenmal verwendet, ohne das es groß Klagen gibt > Ergebnis: Auf der Zielplatte sind wieder nur die ersten ca 122MB > beschrieben, d.h. dd kopiert das einfach alles vorne hin ohne auf CHS zu > achten. q.e.d., zeigt aber auch, daß Du das eigentliche Problem, "Wie muß ich eine Festplatte beschreiben, damit das Keyboard sie korrekt liest?", nur halb verstanden hast. Es geht nicht darum, was das OS oder dd oder irgendwer auf dem PC mit gleicher Geometrie der Platte liest und schreibt, sondern was das Keyboard liest. Da nützt es auch überhaupt nix, wenn Du jeden Tag ein neues tolles Tool, das irgendjemand aus dem Hut zaubert, ausprobierst. Ich versuche mal, das Problem in ein einfaches Beispiel zu kleiden. Vielleicht wird's dann klarer: Da wäre einmal das Lagerhaus Lager1 mit einem Regal, das 5 Böden übereinander hat. Auf jeden Boden passen nebeneinander 10 Kisten, also 1,5,10. Dann gibt's ein Lagerhaus Lager2 mit 1 Regal, 10 Böden, auf die jeweils 20 Kisten nebeneinander passen, also 1,10,20 Jedes Lagerhaus hat einen Verwalter, der die Kisten rausgibt und einen Plan hat, wie die im Regal stehen. Nun sei Lager1 voll mit 50 Kisten und die sollen nach Lager2. Also fährt Spedition dd vor Lager1 vor und sagt: Gib mir die Kisten in der Reihenfolge 1..50 raus. Gesagt, getan, gepackt, an Lager2 vorgefahren. dd gibt dort die Kisten in der Reihenfolge 1..50 ab, der Lagerverwalter nimmt sie entgegen und füllt das Regal von unten nach oben, also 20 Kisten jeweils auf Regalboden 1 und 2, 10 Kisten auf Regalboden 3. Egal in welche Richtung Spedition dd fährt, er bekommt die Kisten immer in der Reihenfolge 1..50 und die Kisten werden immer richtig eingeordnet, da die Lagerverwalter ja den Plan haben, wie 1..50 in RBK einsortiert wird. Jetzt kommt aber Spedition Keyboard. Der hat vom Chef die Anweisung: Hol aus Lager1 aus den 5 Böden jeweils die 10 Kisten und bring die mir, macht er. Am nächsten Tag wird er mit gleichem Auftrag zu Lager2 geschickt, zu dem dd schon angeliefert hat. Sagt er dem Lagerverwalter: 10 Kisten jeweils aus 5 Böden hätte er gerne. Der Lagerverwalter nimmt aus den 3 unteren Böden jeweils 10 Kisten, auf Regalboden 4 und 5 findet er keine. Klar, in Lager2 sind die ja auch anders eingeordnet. Das ist genau das Problem der beiden Festplatten. Lösungen, die das gleiche Ergenis liefern, gibt's 2: 1. Spedition dd stellt beim Einladen in Lager1 jeweils nach 1o Kisten zusätzlich 10 leere Kisten dazwischen. Beim Anliefern dieser 1..100 Kisten nach Lager2 werden die vom Lagerverwalter wie gehabt mit jeweils 20 Kisten von unten nach oben ins Regal gepackt. Wenn LKW Keyboard kommt holt der seine 10 Kisten aus 5 Böden ab und hat die gewünschten 50 Kisten. Das entspricht dem im Thread gemachten Vorschlag, das gezogenen Image umzumappen. 2. Lagerverwalter2 läßt sich von Keyboard den Verteilungsplan 1,5,10 geben und sortiert zukünftig bei Anliefern durch dd entsprechend die 50 Kisten ein. Keyboard bekommt dann beim Abholen die Kisten in der Ordnung, die er kennt. Das entspricht dem Ändern der Geometrie z.B. via Bios. Übrigens bekäme dd bei Abholung in Lager2 die Kisten auch hier in der Reihenfolge 1..50, für's Ordnen ist ja der Lagerverwalter zuständig. Wichtig bei Lösung 2 ist, daß Lager2 nach dem gleichen Lagerplan (1,5,10) wie Lager1 sortiert ist. Dabei ist unerheblich, das Lager 2 tatsächlich mehr Regalböden mit mehr Platz hat. LKW Keyboard wird immer nach Kisten aus 1,5,10 fragen. MfG
Tom F. schrieb: > ddrescue zeigt 0 Fehler, das eben erstellte ddrescue Image ist identisch Zur Größe grad noch mal, falls das der Auslöser der war die Angabe 127MB = 122MiB = 127948800 Byte Das ist sehr unterschiedlich wie das von Programmen per default gehandhabt wird. Ein mc zeigt 124950K, ls -an zeigt 127948800, konqueror 122.0MB, ...
Udo A. schrieb: > Da ich bis jetzt ja wohl der Erste bin, der das gebasteltes Tool > vorgestern auch runtergeladen und ausgetestet hat: > Für mich sieht das Ergebnis, mit dem neuen (Tool-ausgeworfenen) Image, > soweit richtig aus. > .... > machen, um das damit ggf. zu bestätigen (oder eben nicht...). :-) Ist das gleiche: Unterschied Nuls anstelle von Einsen, etwas kuerzer da man eh ungenutzten Platz nicht mit Einsen fuellen muss ...
1 | #!/bin/bash
|
2 | |
3 | s=$((1)) |
4 | |
5 | for ((c=0; c <= 979; c++)); do |
6 | for ((h=0; h <= 14; h++)); do |
7 |
|
8 | quell_lba=$(((c * 15 + h)*17+(s - 1))) |
9 | ziel_lba=$(((c * 16 + h)*63+(s - 1))) |
10 | |
11 | dd if=in.img of=out.img bs=512 count=17 skip=$quell_lba seek=$ziel_lba |
12 | |
13 | done
|
14 | done
|
Mutti wo sind denn die Speicherriegel .... diff -y <(xxd out.img) <(xxd out_2.img) |less
1 | #!/bin/bash
|
2 | printf '%12s | %-17s | %-15s\n' "" "Startadresse" "Zieladresse" |
3 | printf '%12s | %-17s | %-15s\n' """""" |
4 | s=$((1)) |
5 | |
6 | for ((c=0; c <= 1; c++)); do #0-979 980 |
7 | for ((h=0; h <= 14; h++)); do #0-14 15 |
8 | |
9 | quell_lba=$(((c * 15 + h)*17+(s - 1))) |
10 | ziel_lba=$(((c * 16 + h)*63+(s - 1))) |
11 | |
12 | printf '%3d | %2d | %2d | %5d | 0x%08x | %5d | 0x%08x\n' \ |
13 | "$c" "$h" "$s" "$quell_lba" "$((quell_lba*512))" "$ziel_lba" "$((ziel_lba*512))" |
14 | |
15 | #dd if=in.img of=out_2.img bs=512 count=17 skip=$quell_lba seek=$ziel_lba
|
16 | done
|
17 | done
|
1 | p450:$ ./vergleich-3.sh |
2 | | Startadresse | Zieladresse |
3 | | | |
4 | 0 | 0 | 1 | 0 | 0x00000000 | 0 | 0x00000000 |
5 | 0 | 1 | 1 | 17 | 0x00002200 | 63 | 0x00007e00 |
6 | 0 | 2 | 1 | 34 | 0x00004400 | 126 | 0x0000fc00 |
7 | 0 | 3 | 1 | 51 | 0x00006600 | 189 | 0x00017a00 |
8 | 0 | 4 | 1 | 68 | 0x00008800 | 252 | 0x0001f800 |
9 | 0 | 5 | 1 | 85 | 0x0000aa00 | 315 | 0x00027600 |
10 | 0 | 6 | 1 | 102 | 0x0000cc00 | 378 | 0x0002f400 |
11 | 0 | 7 | 1 | 119 | 0x0000ee00 | 441 | 0x00037200 |
12 | 0 | 8 | 1 | 136 | 0x00011000 | 504 | 0x0003f000 |
13 | 0 | 9 | 1 | 153 | 0x00013200 | 567 | 0x00046e00 |
14 | 0 | 10 | 1 | 170 | 0x00015400 | 630 | 0x0004ec00 |
15 | 0 | 11 | 1 | 187 | 0x00017600 | 693 | 0x00056a00 |
16 | 0 | 12 | 1 | 204 | 0x00019800 | 756 | 0x0005e800 |
17 | 0 | 13 | 1 | 221 | 0x0001ba00 | 819 | 0x00066600 |
18 | 0 | 14 | 1 | 238 | 0x0001dc00 | 882 | 0x0006e400 |
19 | 1 | 0 | 1 | 255 | 0x0001fe00 | 1008 | 0x0007e000 |
20 | 1 | 1 | 1 | 272 | 0x00022000 | 1071 | 0x00085e00 |
21 | 1 | 2 | 1 | 289 | 0x00024200 | 1134 | 0x0008dc00 |
22 | 1 | 3 | 1 | 306 | 0x00026400 | 1197 | 0x00095a00 |
23 | 1 | 4 | 1 | 323 | 0x00028600 | 1260 | 0x0009d800 |
24 | 1 | 5 | 1 | 340 | 0x0002a800 | 1323 | 0x000a5600 |
25 | 1 | 6 | 1 | 357 | 0x0002ca00 | 1386 | 0x000ad400 |
26 | 1 | 7 | 1 | 374 | 0x0002ec00 | 1449 | 0x000b5200 |
27 | 1 | 8 | 1 | 391 | 0x00030e00 | 1512 | 0x000bd000 |
28 | 1 | 9 | 1 | 408 | 0x00033000 | 1575 | 0x000c4e00 |
29 | 1 | 10 | 1 | 425 | 0x00035200 | 1638 | 0x000ccc00 |
30 | 1 | 11 | 1 | 442 | 0x00037400 | 1701 | 0x000d4a00 |
31 | 1 | 12 | 1 | 459 | 0x00039600 | 1764 | 0x000dc800 |
32 | 1 | 13 | 1 | 476 | 0x0003b800 | 1827 | 0x000e4600 |
33 | 1 | 14 | 1 | 493 | 0x0003da00 | 1890 | 0x000ec400 |
34 | box:/~ |
Ich war 3 Tage weg deshalb erst heute eine Antwort. Später werde ich noch Mal ein geändertes Programm hochladen insbesondere der HDD Scan ist jetzt anders gelöst. Außerdem hatte ich noch einen Bug in meinen Routinen. Thomas
Hier das Programm. Es ist im Prinzip eine Zusammenfassung der Routinen. Wie zuverlässig die Scanroutine arbeitet musst du ausprobieren. Zumindest hier erhalte ich gültige Ergebnisse. Alle Funktionen haben eine Sicherheitsabfrage wo die aktuellen Parameter noch Mal angezeigt werden bevor die Aktion ausgelöst wird. Das Programm ist ziemlich langsam da immer nur ein Sektor gelesen wird. Nicht ungeduldig werden. Die Direkt Kopie ist nicht sehr gut getestet. Ich besitze da einfach keine geeignete HW Thomas
Mal so ne blöde Frage... was passiert, wenn du eine komplett leere Festplatte anschließt? Wird die automatisch formatiert oder lässt sie sich im Zielsystem formatieren? Und wie groß ist diese Festplatte dann? Eine CF-Karte mit Adapter sollte auch gehen, vor allem kriegt man auch eher kleine CF-Karten noch zu kaufen. Laut deiner Webseite bestand der Bausatz anfänglich aus 84 MB-Platten, später aus 1 GB-Platten. Das klingt für mich stark nach "das Teil kann mehrere Geometrien verarbeiten". Daraus folgt oft, dass eine 1:1-Kopie nicht ohne weiteres machbar ist (weder mit noch ohne Fake-Geometrie). Es ist wahrscheinlich einfacher, eine komplett neue Platte an das Keyboard anzuschließen und die Songs irgendwie auf das Keyboard zu bekommen (entweder per MIDI oder durch Reverse-Engineering des Dateisystems, sollte ja nicht allzu schwer sein).
Hallo S. R. schrieb: > Mal so ne blöde Frage... was passiert, wenn du eine komplett leere > Festplatte anschließt? Wird die automatisch formatiert oder lässt sie > sich im Zielsystem formatieren? Und wie groß ist diese Festplatte dann? Kommt Einer daher und hat den Thread nicht gelesen.. Alles. was Du schreibst, ist schon mal beantwortet woder oder war mal Thema. MfG
M.M.M schrieb: > Kommt Einer daher und hat den Thread nicht gelesen.. Hat er schon... zumindest grob verfolgt. M.M.M schrieb: > Alles. was Du schreibst, ist schon mal beantwortet woder oder war mal > Thema. Naja. Teilweise. Aus meiner Sicht wäre es sinnvoller, eine neue Platte (oder DOM oder sonstwas) an dem Keyboard zum Laufen zu bekommen, und zwar bevorzugt mit der korrekten Geometrie - also x/16/63. Mit dem Parallelport-Interface (wo mir gerade nicht klar ist, ob das vorhanden ist) an einem alten Computer sollte sich das machen lassen. Und wenn man das EEPROM dafür ändern muss, dann ist das eben so (dafür ist hier uC.net und die Adresse ist auch bekannt). Ob das praktisch geht, wurde hier im Thread bisher nicht beantwortet (oder ich habs überlesen). Da man die Lieder auf Diskette speichern kann, könnte man sie von der alten Platte auf Diskette speichern (oder, weil das Dateiformat identisch sein dürfte, nach der zweiten Diskette aus dem Image kratzen) und auf die neue Platte kopieren. Reverse-Engineering des Dateisystems sollte im Prinzip nicht zu schwierig sein, auch das wurde hier im Thread mal erwähnt, aber nicht weiter verfolgt (oder ich habs überlesen). Vielleicht liegt das aber auch nur daran, dass mir der Ansatz "das vorhandene Image auf eine größere Geometrie strecken und hoffen, dass das Keyboard damit klarkommt" extrem unsympathisch ist. Zumal das Keyboard zwar das Inhaltsverzeichnis korrekt liest, aber die Lieder nicht. Wäre nicht das erste Mal, dass mehrere Geometrien gleichzeitig verwendet werden, was natürlich nur funktioniert, wenn die auch alle gleich sind. Älteres DOS benutzt zum Beispiel gerne die in der FAT gespeicherte Festplattengeometrie, unabhängig davon, was das BIOS meldet (oder die Festplatte selbst, da gibt's ja noch mehrere Translationsverfahren). Was ich sagen will: Kann ja gut sein, dass das Inhaltsverzeichnis anhand der EEPROM-Geometrie (oder einer auf der Platte selbst gespeicherten Geometrie) gelesen wird, aber die eigentlichen Daten nicht. Dann wird das mit so einem gestreckten Image nichts. Den Spaß habe ich auch schon durch. Schönen Abend noch.
S. R. schrieb: > Zumal das Keyboard zwar das Inhaltsverzeichnis korrekt liest Nö, lesen/Foto ansehen... ;-) 'ehe jetzt wieder... Ich mache 'mal eine subjektive Zusammenfassung: Ein Parallelport-Interface zum HD-MEC2000 hat der TO nicht, der TO möchte auch nicht seine gespeicherten Songs retten, es geht ihm um den Austausch der (noch) funktionsfähigen Festplatte und damit um die jahrzehnte-lange Weiternutzung seines Keyboards. :-) Das HD-MEC2000 hat keinen Linux-/DOS-/Windows/xyz-Betriebssystem-Bezug. Die einzigste "PC"-Komponente ist eine sehr alte Festplatte, die wohl ohne Festplattenkontroller, aber per damals gültigen ATA-Interface und wohl per damals (!) gültigen "ATA interface command description" mit dem HD-MEC2000 spricht. Die Festplatte ist eine Seagate ST9145AG, wohl von 1991 (max. 1993?): Guaranteed Mbytes: 127,9 Guaranteed sectors: 249900 Bytes per sector: 512 Sectors per track: 17 Read/Write heads: 15 Cylinders: 980 Die Festplatte läßt sich per C/H/S ansprechen, ob sie zusätzlich auch LBA unterstützt, ist nicht getestet ("A drive that supports LBA indicates this through word 49, bit 9 of the Identify Drive information" aus: ATA Interface Reference Manual 36111-001, Rev. C 1993). Es existieren Fotos anderer HD-MEC2000, mit auf dem EPROM beschrifteten Festplattentyp. Das und der Fund der C/H/S-Angaben als Daten auf einem Sektor-Image der Festplatte läßt zumindest die Vermutung zu, daß diese Festplatte auch mit diesen C/H/S-Angaben (980/15/17) durch das HD-MEC2000-Interface "besprochen" wird. Der Weg dazu scheint einfach: einfach einen PC benutzen und ein Image der alten Festplatte erstellen und auf eine neue Festplatte das altes Image aufspielen. 1. Versuch Trotz "dd ist die Lösung aller Probleme" schlägt das fehl. Leider steckt der Teufel ja im Detail - Erkenntnisse: - auf der Festplatte ist keinerlei (PC-bekanntes) Dateisystem - die Festplatte wird mit keinerlei PC-Betriebssystem betrieben - alte "passgenaue" Festplatten lassen sich nicht mehr finden - die C/H/S zu LBA-Sektor-Transformation gilt es wohl zu beachten ... Erkenntnis: --> sektorweise C/H/S-Kopie der alten Festplatte auf neue Festplatte ... weitere Vorschläge/Versuche ... Stand: arbeiten mit Linux per dd und Streckungs-Tool 1.) Image per dd erstellt 2.) Image gestreckt (C/H/S zu LBA-Sektor-Transformation) 3.) Image per dd auf PQI-Modul zurückgespielt 4.) PQI-Modul arbeitet nicht sauber am HD-MEC2000 als Festplattenersatz 5.) Stand jetzt: weitere Fehlersuche, ggf. andere "Kopierung"? mögliche Fehlerquellen (Meine ("...")-Anmerkungen sind böse/subjektiv): für 1.) Kein direkter Vergleich des Images mit der Original-Festplatte durch- geführt ("noch nicht einmal banale Sachen: ist der Sektor 1 der Festplatte wirklich Sektor 1 im Image, ist der 18. Sektor im Image auf der Festplatte wirklich 0/1/1"). Das dd-Image ("mit einem 27-Jahre neueren Linux erstellt, reine ATA-Treiber für das Ansprechen der Festplatte existieren seit mind. 23 Jahren nicht mehr im benutzten Linux"). Der benutzte PC ("ist eine Emulation eines 386er, mit einer Emulation eines Chipsatztreibers für die Emulation eines 386er, mit der Boot-Emulation einer MS-DOS-Emulation, zumindest BIOS-Einstellungen trotz HP vorhanden"). für 2.) wohl keine für die reine Funktion, mindestens so 3 Leute ;-) haben sich das Tool angesehen, das Image-Strecken scheint wohl sauber zu arbeiten für 3.) Kein direkter Vergleich des gestreckten Images mit dem PQI-Modul durchgeführt ("noch nicht einmal so banale Sachen..."). Der benutzte PC ("das ist eine Emulation eines 386er..."). Keine sektorweise Kopie der alten und neuen Festplatte ("na ja...") für 4.) Das als Ersatz-Festplatte "lieb gewonnene" PQI-Modul ("das ist eine billige Festplatten-Emulation, gerade noch gut genug für ein heutiges PC-Betriebssystem, aber eben nicht mehr für ein ATA-Interface mit einem Stand von 1991") für 5.) je nach Ausführung, wohl alles von zu 1.) bis zu 4.) +/- x Möge der TO doch bitte 'mal meine Zusammenfassung kopieren, kürzen, ergänzen und verbessern, damit man nicht immer wieder bei 0,3 anfängt. LG :-)
:
Bearbeitet durch User
Hallo Udo A. schrieb: > Die einzigste "PC"-Komponente ist eine sehr alte Festplatte, die wohl > ohne Festplattenkontroller, aber per damals gültigen ATA-Interface > und wohl per damals (!) gültigen "ATA interface command description" > mit dem HD-MEC2000 spricht. o.g. Interface ist der Controller > Die Festplatte ist eine Seagate ST9145AG, wohl von 1991 (max. 1993?): 1993 oder später > Stand: arbeiten mit Linux per dd und Streckungs-Tool > > 1.) Image per dd erstellt > 2.) Image gestreckt (C/H/S zu LBA-Sektor-Transformation) Allerdings mit falschen Parametern. > 3.) Image per dd auf PQI-Modul zurückgespielt Nein, da war das Modul von PQI (Pollin 128MB) längst aus dem Spiel. > 4.) PQI-Modul arbeitet nicht sauber am HD-MEC2000 als Festplattenersatz Das wundert mit falschen Parametern nicht. Ein Versuch mit korrekten Parametern ist nicht bisher beschrieben. > mögliche Fehlerquellen (Meine ("...")-Anmerkungen sind böse/subjektiv): Dafür, daß Du mit dem Satz "Ich denke, man sollte hier einen anderen Weg einschlagen und man sollte sich auch (zumindest erst einmal) von seinem ev. vorhandenen PC-Wissen (oder Halbwissen...) lösen." in diesem Thread eingeflogen bist, fabulierst Du reichlich. > Keine sektorweise Kopie der alten und neuen Festplatte ("na ja...") Doch, ist geschehen: Beitrag "Re: Technics Keyboard Festplatte klonen geht das ?" > für 4.) > Das als Ersatz-Festplatte "lieb gewonnene" PQI-Modul ("das ist Wie wär's, zukünfig statt PQI-Modul den Begriff DOM (Disk on Module) zu verwenden, PQI ist ein Firmenname. > eine billige Festplatten-Emulation, gerade noch gut genug für ein > heutiges PC-Betriebssystem, aber eben nicht mehr für ein > ATA-Interface mit einem Stand von 1991") Nun werden DOM aber gerade in jeder Menge oller Industriehardware als Ersatz für Festplatten eingesetzt. Ansonsten käme wohl auch niemand auf die Idee, für Module mit solch niedriger Speicherkapazität und obsoleten Interface vergleichsweise horrende Beträge zu zahlen. MfG
Danke für die Zusammenfassung. > Ein Parallelport-Interface zum HD-MEC2000 hat der TO nicht, der TO > möchte auch nicht seine gespeicherten Songs retten, es geht ihm um > den Austausch der (noch) funktionsfähigen Festplatte und damit > um die jahrzehnte-lange Weiternutzung seines Keyboards. :-) Damit wäre das Parallelport-Interface der wahrscheinlich beste Ansatz. Zumindest, wenn man damit eine am Keyboard angeschlossene Festplatte formatieren kann. Wahrscheinlich könnte man sich so ein Interface auch basteln, wenn es dazu Unterlagen gibt. > Es existieren Fotos anderer HD-MEC2000, mit auf dem EPROM beschrifteten > Festplattentyp. Das und der Fund der C/H/S-Angaben als Daten auf einem > Sektor-Image der Festplatte läßt zumindest die Vermutung zu, daß diese > Festplatte auch mit diesen C/H/S-Angaben (980/15/17) durch das > HD-MEC2000-Interface "besprochen" wird. Damit gibt es schonmal zwei möglicherweise gleichzeitig aktive Geometrien (die im EPROM und die auf der Festplatte gespeicherte) und damit Konfliktpotential, wenn die nicht übereinstimmen. Halte ich aber für unwahrscheinlich. Wesentlich wahrscheinlicher erscheint es mir, dass das ominöse Tool für das Parallelport-Interface die Geometrie von der Festplatte ausliest (oder manuell vorgegeben bekommt), diese dann auf die Festplatte geschrieben und vom Keyboard benutzt wird. Nur so kann man sinnvoll neue Festplatten anlernen. > Der Weg dazu scheint einfach: > einfach einen PC benutzen und ein Image der alten Festplatte erstellen > und auf eine neue Festplatte das altes Image aufspielen. Wenn der direkte Weg nicht funktioniert (es also Geometrieabhängig ist), dann ist das aus meiner Sicht eher Zeitverschwendung. BTDT (allerdings nicht mit dem Keyboard). Hätte man das PC-Tool zur Hand, mit dem man eine neue Festplatte formatieren kann, dann ließen sich damit bestimmt auch ohne das Interface genügend Informationen über das Dateisystem sammeln. > 4.) PQI-Modul arbeitet nicht sauber am HD-MEC2000 als Festplattenersatz Was nach meinem Erfahrungsstand schlicht daran liegt, dass die Geometrie kleiner ist. Damit kann das gestreckte Image prinzipbedingt nicht funktionieren, weil es nicht raufpasst. Der Schlüssel liegt meiner Meinung nach darin, eine neue Festplatte anzulernen, statt den Inhalt der alten Platte mühselig rüberzukopieren. Was natürlich auch daran liegt, dass dann ein späterer Wechsel (wenn DOM oder Ersatzplatte sterben) einfacher ist. Aber vielleicht denke auch nur ich so.
S. R. schrieb: > Damit gibt es schonmal zwei möglicherweise gleichzeitig aktive > Geometrien (die im EPROM und die auf der Festplatte gespeicherte) und > damit Konfliktpotential, wenn die nicht übereinstimmen. Halte ich aber > für unwahrscheinlich. Das ist bereits hier abgehandelt: Beitrag "Re: Technics Keyboard Festplatte klonen geht das ?" > Wesentlich wahrscheinlicher erscheint es mir, dass das ominöse Tool für > das Parallelport-Interface die Geometrie von der Festplatte ausliest > (oder manuell vorgegeben bekommt), diese dann auf die Festplatte > geschrieben und vom Keyboard benutzt wird. Nur so kann man sinnvoll neue > Festplatten anlernen. Eine neue Festplatte funtioniert überhaupt nur dann (zumindest partiell), wenn die Geometrie der Originalplatte, also quasi der 1 Sektor der Originalplatte, übernommen wird, siehe Link oben. > Hätte man das PC-Tool zur Hand, mit dem man eine neue Festplatte > formatieren kann, dann ließen sich damit bestimmt auch ohne das > Interface genügend Informationen über das Dateisystem sammeln. Da wird nix großartig was zu formatieren sein, außer den 1. Sektor zu übernehmen. Wenn man feste Blöcke zum Beschreiben vorsieht, wie das hier scheinbar ist, braucht's das nicht. Das Keyboard weiß ja,in welchem Format gelesen und geschrieben wird. Ist ja nicht so, daß wie beim PC Dateien unterschiedlichster Länge usw. auflaufen. >> 4.) PQI-Modul arbeitet nicht sauber am HD-MEC2000 als Festplattenersatz > > Was nach meinem Erfahrungsstand schlicht daran liegt, dass die Geometrie > kleiner ist. Damit kann das gestreckte Image prinzipbedingt nicht > funktionieren, weil es nicht raufpasst. Da geht's durcheinander. Da ist wohl derweil das 512MB Modul gemeint. Da paßt die Geometrie von der Größe her schon. Allerdings war das gestreckte Image mit fehlerhaften Parametern erzeugt, siehe: Beitrag "Re: Technics Keyboard Festplatte klonen geht das ?" > Der Schlüssel liegt meiner Meinung nach darin, eine neue Festplatte > anzulernen, statt den Inhalt der alten Platte mühselig rüberzukopieren. Mehr als der 1. Sektor wird womöglich dann gar nicht auf der Festplatte stehen. Der TE könnte das ja mal analog auf dem Diskettenlaufwerk mit einer leeren Diskette testen. > Aber vielleicht denke auch nur ich so. Jeder kann sich hier viel denken, man kann's halt nur nicht verifizieren. Das kann nur der TE. MfG
M.M.M schrieb: > Das ist bereits hier abgehandelt: Dann würde ich mich genau daran machen. Nämlich einfach ein EPROM mit einer anderen Geometrie schreiben, einen neuen Sektor generieren, fertig. M.M.M schrieb: > Mehr als der 1. Sektor wird womöglich dann gar nicht auf der Festplatte > stehen. Der TE könnte das ja mal analog auf dem Diskettenlaufwerk mit > einer leeren Diskette testen. Das vermute ich nämlich auch. Die PC-Software könnte dabei helfen. Oder man klemmt einfach eine komplett leere Festplatte (bis auf den ersten Sektor) an. Großartige Inhalte sehe ich da nämlich nicht, nur Header plus Geometrie. M.M.M schrieb: > Jeder kann sich hier viel denken, man kann's halt nur nicht > verifizieren. Das kann nur der TE. Leider. :-)
M.M.M schrieb: > Da wird nix großartig was zu formatieren sein, außer den 1. Sektor > zu übernehmen. Wenn man feste Blöcke zum Beschreiben vorsieht, wie > das hier scheinbar ist, braucht's das nicht. Das Keyboard weiß ja, > in welchem Format gelesen und geschrieben wird. Ist ja nicht so, > daß wie beim PC Dateien unterschiedlichster Länge usw. auflaufen. Junge, Junge... einen "wichtigen" Profilierungs-Post nach dem anderen schreiben, aber immer wieder nicht lesen können. Das ist doch bereits abgehandelt! Beitrag "Re: Technics Keyboard Festplatte klonen geht das ?" >> Habe ausser dem ersten Sektor wo die Plattengrösse steht alles >> mit NULL beschrieben, das hat das Keyboard aber mit einem >> "Disk Failure" Meldung quittiert. Und warum sollten die einzelnen Songs keine unterschiedliche Datei-Längen habe? RTFM kann dazu dann auch nicht schaden. Hast Du überhaupt einmal in das Original-Image reingesehen?
:
Bearbeitet durch User
Mir ist gerade etwas an den Bildern vom PC und der HDD aufgefallen. Die Hdd liegt auf dem Kopf !!! Ich hoffe jetzt nicht, dass Du die HDD so in Betrieb nimmst ?! Ältere HDD's vertragen es nicht, auf den Kopf zu arbeiten. Die hatten damals ne Einbaurichtung. Neuere Platten ab, weiß wann ich jetzt sind dafür nicht mehr empfindlich. Aber die alten. Wenn Du kannst, nimm R-Studio an einem anderen Rechner, und schau, ob das halbwegs problemlos über die gesamte Platte kommt. Meckert es rum, kommst Du zumindest an die betroffenen Sektoren nie mehr ran. PS: hier gibt' anscheinen 2 x Thomas
Thomas schrieb: > Ältere HDD's vertragen es nicht, auf den Kopf zu arbeiten. Das war schon zu der Zeit, als die betroffene Platte hergestellt wurde, nicht mehr relevant.
Es scheint so dass der TO nicht mehr hier ist. Schade eigentlich. Mich hätte es zum Beispiel interessiert ob ein Image, was mit meinem Programm erstellt ist, identisch zum original dd Image wäre. Für mich ist hier erst mal Ende. Thomas
Er wird sich ein neues Keyboard gekauft haben und die Musik neu eingespielt haben.
Tom F. schrieb: > Ich glaube ich muss mich so langsam doch mit so einem Floppy Emulator > anfreunden. :-( Da gibt es aber einige unterschiedliche. Je nachdem, was sie können und über IDE zurückmelden, funktionieren die am Gerät oder auch nicht. Kommt auf den Controller an und darauf, wie der von der MUSIC-firmware genutzt wird. Ich habe auch mehre davon getestet, bis ich einen gefunden hatte, der in der VA-76 lief. Der läuft interessanterweise nicht im Korg ix300, dafür aber in der Yamaha RM1X.
Thomas schrieb: > ... Mich hätte es zum Beispiel interessiert ob ein Image, was > mit meinem Programm erstellt ist, identisch zum original > dd Image wäre. Mir fehlt es z.Z. auch an entsprechender PC-Hardware, ich werde die nächsten 2/3 Wochen 'mal "alte Schätzchen" suchen, da Dein Programm testen und dann hier berichten.
Udo A. schrieb: > Mir fehlt es z.Z. auch an entsprechender PC-Hardware, ich werde > die nächsten 2/3 Wochen 'mal "alte Schätzchen" suchen, da Dein > Programm testen und dann hier berichten. Ja das mit der alten HW ist ein Problem. Meine Programme sind da auch etwas im Blindflug entstanden. Ich hab inzwischen auch noch etwas rumgebastelt. Der imager ist jetzt in der Lage mehrere Sektoren auf einmal zu lesen damit das ding etwas schneller wird und die Scan Funktion hab ich auch etwas ausgebaut. Mein Problem ist ich bin mir nicht so sicher wie dos mehr als 2 Hdds handhabt. EV. geht das gar nicht. Zum test habe ich Dos vom usbstick gebootet dann zeigt mir die Scan routine allerdings nur 2 Hdds hdd0 ist der USB stick hdd1 meine systemplatte. Die CHS Werte stimmen logischerweise nicht da beide Disks wesentlich größer sind als 504 MB. Schreibtests habe ich keine durchführen können. Die Lesefunktion liest bei mir aber korrekt Sektoren von der Systemplatte. Allerdings wäre es wesentlich sinnvoller wenn der TO testen würde der hat ja die HW. Thomas
Sorry, ich war die Woche ausser Haus. Danke, Danke, Danke für euren Zuspruch (22 neue Beiträge )Wow. Werde mich gleich ans Werk machen und mal MHDD über die Platte laufen lassen und Thomas Programm checken.
:
Bearbeitet durch User
Mit dem Test meines Programms solltest du warten. Ich habe eine verbesserte Version die ich später hochladen werde. Thomas
Hier das Programm. Insbesondere interessiert mich was -i oder -i0 bei dir anzeigt. Zusätzlich wäre es interessant ob ein Image mit -r gleich deinem Original ist Thomas
Thomas schrieb: > Zum test habe ich Dos vom usbstick gebootet dann zeigt mir die Scan > routine allerdings nur 2 Hdds hdd0 ist der USB stick hdd1 meine > systemplatte. Ja, genau so etwas meinte ich in "meiner bösen" Zusammenfassung z.B. unter ggf. Fehlern zu 3.), im Endeffekt schlägt man sich nur mit den möglichen Fehlern der Emulation einer ggf. anderen Emulation rum. USB-Start von DOS wäre z.B. eine...
:
Bearbeitet durch User
Udo A. schrieb: > Ja, genau so etwas meinte ich in "meiner bösen" Zusammenfassung z.B. > unter ggf. Fehlern zu 3.), im Endeffekt schlägt man sich nur mit den > möglichen Fehlern der Emulation einer ggf. anderen Emulation rum. > USB-Start von DOS wäre z.B. eine... Ich stimme dir vollkommen zu. Aber wenn ich die Diskussion weiter oben richtig verstanden habe ist das auch unter Linux ein Problem. Nicht dass ich mich da besonders gut auskenne.... Ich erhalte allerdings mit einem checkit genau die gleichen Ergebnisse wie mit meinem Programm. Ein Diskettenlaufwerk um ein DOS zu booten habe ich seit 10 Jahren nicht mehr. Selbst mein CD Laufwerk kommt so gut wie nicht mehr zum Einsatz weil einfach zu unflexibel. Thomas
dolli schrieb: > Das sollte sich doch jetzt für dich auf dieser Hardware ein für alle mal > klären lassen ob das Abbild dem Original entspricht Das Image welches MHDD schreibt ist identisch mit dem dd Image Wobei -wenn ich die Doku von MHDD richtig deute- man vereinzelt Sektoren sieht die etwas langsamer gelesen werden als andere [AccessTime] #Sectors [<10ms]334 [<50ms]14339 [<150ms]27 Thomas schrieb: > Hier das Programm. Insbesondere interessiert mich was -i Angschlossen waren die original HDD (980/15/17) und die DOM (1001/16/63) "imager -i" liefert die Ausgabe: drive0 found CHS(1023/254/99) maxdisk:3 drive1 found CHS(979/14/65) maxdisk:3 drive2 found CHS(1000/15/99) maxdisk:3 "imager -rtestimage.img" liefert das identische image wie mit dd und MHDD.
:
Bearbeitet durch User
Tom F. schrieb: > "imager -rtestimage.img" liefert das identische image wie mit dd und > MHDD. Das sieht doch schon 'mal gut aus, mind. zwei unterschiedliche Wege zum Image-Erstellen, aber 3x identisches Image. Haken wir 'mal das Image als: "das nehmen wir jetzt als Basis" ab :-)
Tom F. schrieb: > Angschlossen waren die original HDD (980/15/17) und die DOM (1001/16/63) > "imager -i" liefert die Ausgabe: > drive0 found CHS(1023/254/99) maxdisk:3 > drive1 found CHS(979/14/65) maxdisk:3 > drive2 found CHS(1000/15/99) maxdisk:3 > > "imager -rtestimage.img" liefert das identische image wie mit dd und > MHDD. OK das sieht ja schon mal ganz OK aus. Vermutlich hat meine Scan routine aber noch eine bug. Wie schon gesagt Blindflug und so .. Um ganz sicher zu gehen würde ich die Original platte entfernen und dann noch mal scannen. Drive 2 sollte dann zu drive1 werden. Dann kannst du das Image mit -w zurück schreiben. Da alle Parameter initial von den defines deiner original HDD kommen sollte das passen. Thomas
Was mir sonst noch auffällt: Wenn man sich den Index im Keyboard ansieht ist der 1 Eintrag korrupt. Im Image fehlt genau an dieser Stelle (Adresse 0x600 TRUE LOVE) ein FF FF, deswegen wird der warscheinlich im Keyboard (siehe Bild) nicht korrekt angezeigt. Das ist Adresse 0x600 also genau am Anfang vom 4. Sektor. Das wäre ja noch vor der ersten Umsortierung/Auffüllung, die ja erst ab Sektor 18 anfangen würde. Wird hier also schon falsch von der Originaldisk gelesen ? Oder ein Artefakt des falsch zurückgeschriebenen Images. Wenn ich dann wieder die Originalplatte anschliesse wird der Eintrag korrekt angezeigt. Wie gesagt, leider habe ich den Parallelport nicht am Keyboard, sonst hätte man ja die Möglichkeit gehabt die HDD zu formatieren. Ich werde trotzdem nochmal probieren händisch ein Blanko Image zu erstellen.
:
Bearbeitet durch User
Tom F. schrieb: > deswegen wird der warscheinlich im Keyboard (siehe Bild) nicht > korrekt angezeigt.. > Wird hier also schon falsch von der Originaldisk gelesen ? Eher nicht. Das hatte ich mir auch schon einmal angesehen, bin aber durch fehlenden Vergleich nicht so richtig weitergekommen. Häng doch noch einmal die Original-Platte an das Keyboard, ist es da im Direktory-Eintrag weg, also sauber?
:
Bearbeitet durch User
Ich würde mir ja mal mit einem logic analyzer den Verkehr auf dem IDE-Kabel ansehen, daraus kannste vielleicht mitverfolgen, welche Sektoren in welcher Reihenfolge angesprochen werden bzw. vergleichen wie das bei der neuen Platte anders geschieht. Ich schätze man müsste ca 16 + 2 Leitungen anzapfen um das zu machen.
Udo A. schrieb: > Häng doch noch einmal die Original-Platte an das Keyboard, ist es > da im Direktory-Eintrag weg, also sauber? Tom F. schrieb: > Wenn ich dann wieder die Originalplatte anschliesse wird der Eintrag > korrekt angezeigt. So hatte ich das in meinem Beitrag gemeint es wird 01: TRUE LOVE korrekt angezeigt, keine Hieroglyphen.
:
Bearbeitet durch User
Oh, das könnte komisch werden... Erst einmal noch 'mal abfragen: 1.) Das mit Deinem Tool gestreckte Image hattest Du aber schon auf (1001/16/63)-Modul geschrieben? 2.) Das Rückschreiben jetzt auf das (1001/16/63)-Modul mit imager -w auch?
Noch mal zur Klarstellung Imager -i ist reine Diagnose das dient nur zur Identifizierung der Hdds. Die dort angezeigten Daten sind wohl nicht ganz ok. Das spielt aber für die eigentlichen Funktionen keine Rolle. -r und -w benutzen beide die CHS Parameter der Originalplatte solange man nicht anderes einstellt. -wimage ohne extra Parameter schreibt das Image auf disk1 zurück und macht noch ein verify. D.h. das Image wird mit den original Parametern zurück geschrieben. Thomas
Tom F. schrieb: > Was mir sonst noch auffällt: Etwas das mir nicht aufgefallen ist :( weiter oben in einem deiner Posts: vermutlich Ausgabe von hdparm -I >>> bytes/track: 9622 bytes/sector: 566 <---- Mmh, prüfe das doch noch einmal ob da nicht sogar 54 Bytes fehlen. jdf. 9622/566=17 Mmh. > Das wäre ja noch vor der ersten Umsortierung/Auffüllung, die ja erst ab > Sektor 18 anfangen würde. > > > Wird hier also schon falsch von der Originaldisk gelesen ? > Oder ein Artefakt des falsch zurückgeschriebenen Images. > > Wenn ich dann wieder die Originalplatte anschliesse wird der Eintrag > korrekt angezeigt
Tom F. schrieb: > Das ist Adresse 0x600 also genau am Anfang vom 4. > Sektor. > Das wäre ja noch vor der ersten Umsortierung/Auffüllung, die > ja erst ab Sektor 18 anfangen würde. In dem Zusammenhang: Könntest Du 'mal die Fotos der einzelnen Direktory anhängen, zumindest die, in denen auch Songs liegen (mit der Original-HD)? Wo liegen z.B. - HUNGRY HEART - LET S DANCE - THE WANDERER (gibt es den mehrmals?) Mache doch bitte auch noch Fotos beidseitig der Platine des HD-MEC2000.
dolli schrieb: >>>> bytes/track: 9622 bytes/sector: 566 <---- > > Mmh, prüfe das doch noch einmal ob da nicht sogar 54 Bytes fehlen. > jdf. 9622/566=17 öhh.. = 17 sectors per track (---> für logische C/H/S) ohne jetzt genauer nachgesehen zu haben, das ist doch wohl (nur...) die Umrechnung der physikalischen (eingebauten) Köpfe/Platten in die logische C/H/S, sonst würden ja in jedem logischen sector 54 Byte fehlen, das wären dann so: 249900 x 54Byte also: nein, nach C/H/S fehlt nicht ein einziges "Stück" Byte im Image, keinerlei Lesefehler bei drei Tools, alle ((Nutz-)Daten-Byte lt. ATA) da, 249900 x 512 Byte...
:
Bearbeitet durch User
Udo A. schrieb: > dolli schrieb: >>>>> bytes/track: 9622 bytes/sector: 566 <---- >> >> Mmh, prüfe das doch noch einmal ob da nicht sogar 54 Bytes fehlen. >> jdf. 9622/566=17 > > öhh.. = 17 sectors per track (---> für logische C/H/S) > ohne jetzt genauer nachgesehen zu haben, das ist doch wohl (nur...) > die Umrechnung der physikalischen (eingebauten) Köpfe/Platten in > die logische C/H/S, sonst würden ja in jedem logischen sector > 54 Byte fehlen, das wären dann so: 249900x 54Byte > > also: nein, nach C/H/S fehlt nicht ein "Stück" Byte im Image, > alle Nutz-Daten-Byte da, 249900 x 512 Byte... Du glaubst nicht das da 10% mehr drauf passen ;) 50Byte ECC, sync, address-mark, gap, ... Hab auch Platten im Schrank mit 600byte/Sector Ist mir aber zu früh jetzt drüber nachzudenken. spontan würde ich sagen, falls die 566 nicht von dem anfäglich verwendeten Adapter stammen, mal dd if= bs=566 count=2 of= und schauen ob da nicht zwischendrin etwas auftaucht.
Da sind schon noch mehr Byte da, klar.
Deswegen hatte ich das vergessene: "lt. ATA" noch angehängt.
Das ATA-Interface kann nur(?) noch ECC-Bytes mitgeben, keine
Ahnung, ob die dann auch real als EEC stimmen müssen und/oder die
auch dann so auf Platte landen und damit als "Byte"-Anzahl-Erweiterung
(512 + 4x falsches ECC = 516-Byte/Sektor) benutzbar wären...
"Vorsorglich" da schon 'mal das:
> Oh, das könnte komisch werden...
;-(
:
Bearbeitet durch User
dolli schrieb: > spontan würde ich sagen, falls die 566 nicht von dem anfäglich > verwendeten Adapter stammen, mal dd if= bs=566 count=2 of= und schauen > ob da nicht zwischendrin etwas auftaucht. habe ich gemacht: ist identisch mit original dd ohne bs=566 Thomas schrieb: > -wimage ohne extra Parameter schreibt das Image auf disk1 zurück und > macht noch ein verify. D.h. das Image wird mit den original Parametern > zurück geschrieben. habe ich gemacht: vorher habe ich noch das 1001/16/63 Modul komplett mit Nullen beschrieben um sauber aufzusetzen. Ergebnis: ist identisch mit dem Image von meinem Tool. Man sieht wie Sektor 18-63 unangetastet bleibt und ab CHS 0/1/1 wieder geschrieben wird. Udo A. schrieb: > Mache doch bitte auch noch Fotos beidseitig der Platine des > HD-MEC2000. Rückseite will ich nicht riskieren, dort sind einige Stiftleisten die ich trennen müsste. Udo A. schrieb: > Wo liegen z.B. > - HUNGRY HEART > - LET S DANCE > - THE WANDERER (gibt es den mehrmals?) Habe ich im Keyboard überhaupt nicht gefunden. Vielleicht Überbleibsel von früherer Speicherung ? Leider nach Anschliessen des 1001/16/63 er Moduls mit zurückgeschriebenen Image im Keyboard dasselbe Problem. Ergo: Das Problem scheint also schon beim Lesen von der Originaldisk und schreiben ins Image zu entstehen ?
Tom F. schrieb: > Ergo: > Das Problem scheint also schon beim Lesen von der Originaldisk und > schreiben ins Image zu entstehen ? Glaub ich ehrlich gesagt nicht. Die alte Platte kann 16bit und 8bit. Im PC wird immer 16bit verwendet. Versuch mal rauszubekommen ob das Modul noch 8bit kann. Falls nein könnte da die Ursache liegen. Dann geht am PC alles am Keyboard aber nicht. Thomas
Thomas schrieb: > Die alte Platte kann 16bit und 8bit. Im PC wird immer 16bit verwendet. Gotcha! Auf dem Foto https://www.mikrocontroller.net/attachment/385473/IMG_5210_shr.jpg sehe ich nirgendwo die beiden Latches, mit denen das obere Byte für den 16 bit-Zugriff gespeichert wird. Eigentlich sehe ich auf der Platine keinen einzigen 74LS373 oder 573. Das lässt in der Tat vermuten, dass die die Platte im XT-Bus-Modus betrieben wird. 8 bit ATA unterstützt heutzutage fast keine Platte mehr. Da die Statusregister 8bittig sind könnte man eine reguläre IDE-Platte mit 8 bit betreiben, wenn man auf die ungeraden Bytes verzichtet. Ein Sektor hat dann nur noch 256 bytes, und beim regulären Auslesen erscheint jedes zweite Byte als 0x00 oder 0xFF. Das scheint hier aber nicht der Fall zu sein.
Thomas schrieb: > > Die alte Platte kann 16bit und 8bit. Im PC wird immer 16bit verwendet. Du meinst ein Problem mit der Endianness, highbyte u. lowbyte auf dem PC vertauscht? ---- > Versuch mal rauszubekommen ob das Modul nochkann. ATA-ATAPI-6 Stichwort "cfa" compact-flash-adapter Seiten 68/69 weiter Suchbegriff im "8-bit pio" (das Ding hat 500 Seiten) devices reporting the value 848Ah in identify device data word 0 or devices having bit 2 of identify device data word 83 set to one shall support the cfa feature set www.t13.org/Documents/UploadedDocuments/project/d1410r3b-ATA-ATAPI-6.pdf so wie kommt man dran ATA Befehl "EC" senden ohne groß zu programmieren, wie zuvor gesagt z.B. sg/sg3 utils: sg_inq --ata -H /hdX ----- falls u. Linux der verwendete Kernel bzw der Treiber noch die passenden ioctls bereitstellt mal nach "ata-query.c" suchen samfreetime.blogspot.com/2014/09/linux-ioctl-command-for-bypass-ata.html gibt noch ein paar Variationen davon wenn man ein bisl stöbert.
Ich lade das grad mal hoch. ---- Das führt aber schon etwas weg vom eigentlichen Thema, Hintergrundinfo: http://www.jukie.net/bart/blog/ata-via-scsi [...] Before you proceed... I have no idea what I am talking about. The stuff below may make your disk explode. IDE subsystem First let's review the history. Once upon a time there was IDE, and we had a whole slew of IDE devices under CONFIG_IDE in the kernel .config file..... [...]
Tom F. schrieb: >> Mache doch bitte auch noch Fotos beidseitig der Platine des >> HD-MEC2000. > > Rückseite will ich nicht riskieren, dort sind einige Stiftleisten > die ich trennen müsste. Rückseite wäre gut gewesen, wegen dem ev. 8-bit Betrieb und den da ggf. gleich auszuschließen. Ich würde da von ausgehen, wenn sie die Platte damals wirklich noch mit 8bit-"Befüllung" betrieben haben, dann haben sie auch einfach die höherwertigen 8bit der 16bit-Daten-IDE-Anschlüsse nicht benutzt. Die Steckerbelegung ist ja genormt, einmal 8bit-Daten sieht man ja wohl auch auf dem Herstellerfoto, es ist eben die Frage, untere oder obere 8bit der 16bit-Daten... soul e. schrieb: > Ein Sektor hat dann nur noch 256 bytes, und beim regulären > Auslesen erscheint jedes zweite Byte als 0x00 oder 0xFF. Ist das dann so? In der ATA-Beschreibung habe ich das nicht gefunden, (oder ich habe es überlesen), ich glaube, die c't hatte 'mal so benutzt, konnte das aber nicht mehr finden (in irgendeine Bastelanleitung?). Ich wäre da von ausgegangen, trotzdem 512-Byte in den Sektor zu bekommen... Andererseits, ist denn das wirklich wichtig für die "Sektorkopie" der Daten, wichtig wäre es doch, daß es dann das 512MB-Modul kann (oder was man eben besser benutzt - ersteinmal 'ne andere HD/CF...).
:
Bearbeitet durch User
Udo A. schrieb: > soul e. schrieb: >> Ein Sektor hat dann nur noch 256 bytes, und beim regulären >> Auslesen erscheint jedes zweite Byte als 0x00 oder 0xFF. > > Ist das dann so? In der ATA-Beschreibung habe ich das nicht > gefunden, (oder ich habe es überlesen), ich glaube, die c't hatte > 'mal so benutzt, konnte das aber nicht mehr finden (in irgendeine > Bastelanleitung?). Ich wäre da von ausgegangen, trotzdem 512-Byte > in den Sektor zu bekommen... Wie soll das denn gehen? Du machst 256 Transfers a 16 bit. Jetzt hast Du beschlossen, die oberen 8 bit nicht anzuschließen und somit zu ignorieren. Wie sollen dann da auf einmal 512 bytes rauskommen? Das klappt nur wenn man die Platte auf echten 8bit-Betrieb (XT-Bus Mode) umstellen kann und dann 512 8 bit-Transfers ausführt. > Andererseits, ist denn das wirklich wichtig für die "Sektorkopie" > der Daten, wichtig wäre es doch, daß es dann das 512MB-Modul kann > (oder was man eben besser benutzt - ersteinmal 'ne andere HD/CF...). Exakt. Die Kopie sollte erstmal 1:1 passen. Aber wenn das neue Medium keine 8 bit-Modus unterstützt bekommt man statt eines kompletten 512 byte-Blocks nur die geraden Bytes, und die gleich zweimal hintereinander.
soul e. schrieb: > Das klappt nur wenn man die Platte auf echten 8bit-Betrieb (XT-Bus Mode) > umstellen kann und dann 512 8 bit-Transfers ausführt. Ich benutze die ja nicht "nicht", der IDE-Plattenkontroller auf der HD sammelt eben statt 256 Transfers Stücker 512... Die Original-Platte kann das wohl schon so, es gibt lt. ATA ein bit: 8-Data-Transfer gesetzt...
Udo A. schrieb: > Die Original-Platte kann das wohl schon so, es gibt lt. ATA ein bit: > 8-Data-Transfer gesetzt... Eben darum geht es ja. Wenn die Originalplatte 8 bit-Transfers unterstützt und diese auch benutzt werden, dann muss eine Ersatzplatte verwendet werden, die dies ebenfalls kann. Ansonsten führt die neue Platte 16 bit-Transfers aus und die Hälfte der Daten fehlt. Nur wenige IDE-Platten unterstützen den 8 bit-Mode (XT-Bus Mode). Ich hatte früher zwei Stück in meiner Sammlung, eine mit 20 und eine mit 40 MB. Beide liefen als externes Laufwerk am Schneider Euro-PC. Der konnte nur 8 bit und kam daher mit "modernen" IDE-Laufwerken nicht zurecht.
Das ist doch 90er Jahre tech. Heute kannste mit nem kleinen microcontroller und ner SD-Karte im SPI-Modus doch die ATA Platte locker emulieren!
Ich würde mich nicht so versteifen unbedingt die Festplatte gegen eine andere alte Festplatte auszutauschen. In 5 Jahren ist die dann durchgerostet und was dann?
soul e. schrieb: > Platte 16 bit-Transfers aus und die Hälfte der Daten fehlt. > Einverstanden, würde dann aber auch keinen lesbaren Text erwarten xxd -b -l 6 KN2000DiskImage.img 0000000: 01010100 01000101 01000011 01001000 01001110 01001111 TECHNO TCN oder EHO ; oder eben ugyhr hungry hart :) Oder? --- Und das mit der Endianness kanns eigentlich auch nicht sein
Auf dem Keyboard ja. Am Pc bzw im Image nein, denn der macht 16 bit-Transfer. Egal ob die Platte 8 bit könnte oder nicht.
soul e. schrieb: > Ein Sektor hat dann nur noch 256 bytes... darauf bezog ich mich, ich glaube, wir reden aneinander vorbei. Die Original-Platte hat doch wohl eine 512-Byte-Befüllung je sektor. Das es dann beim Auslesen und neu beschreiben mit dem Ersatz- Flash-Modul im Keyboard kracht, wenn das Ersatz-Dingens keinen 8bit-Transfer kennt, ist doch wohl unstrittig und wurde ja auch schon mehrmals weit vorher angesprochen. Die Frage ist aber doch, sind es den wirklich 8bit-Daten-Transfers? Andererseits gibt es das Keybord-Modul ja auch mit anderen Festplattengrößen, so wenige 8bit-Transfer-Festplatten sollte es wohl dann doch nicht geben (auf dem Bild steht z.B. HD 6, größere sind ja auch nachgekommen)... Wie sieht es denn bei CF-Karten aus, können die das?
soul e. schrieb: > Auf dem Keyboard ja. > Eben und das zeigt Klartext [mit der Kopie], ein Byte/Char das zeigt der Blick ins .img Wenn daraus ein 16bit Wort gemacht würde dann träte das ggf. auf.
Udo A. schrieb: > Rückseite wäre gut gewesen, wegen dem ev. 8-bit Betrieb und den da > ggf. gleich auszuschließen. Hier nochmal die Rückseite des HDD Controllers und das Mainboard. Das helle Flachbandkabel geht zur Floppydisk. Udo A. schrieb: > Wie sieht es denn bei CF-Karten aus, können die das? Auch direkt mal probiert. Ich hatte noch so einen CF-IDE Adapter, leider nur eine 128MB CF Karte (CHS 984/16/16), damit startet das Keyboard aber nicht. Ich nehme an die ersten 17 Sektoren müssen vorhanden sein was ja bei dieser Karte nicht der Fall ist.
Tom F. schrieb: > 128MB CF Karte (CHS 984/16/16) Nun ja, das hatten wir doch schon 'mal, C/H/S-Anzahl eben zu klein. Sollte doch aber kein Problem sein, eine 512MB/1GB aufzutreiben. Das haben ja eben viele der HD-Erweiterungen der 8bit-Computer dann auch alle benutzt: 'ne CF-Karte. Da steht dann aber durchaus auch, es gehen nur manche... Interface mußt Du ja nicht basteln, nur passende CF-Karte + Adapter. :-) z.B. als Einstieg: http://www.waveguide.se/?article=8-bit-compact-flash-interface http://www.b-pahl.de/atari8bit/MyIDE/myide.html Das Netz ist voll davon...
:
Bearbeitet durch User
Beitrag #5660894 wurde vom Autor gelöscht.
Tom F. schrieb:
> Rückseite des HDD Controllers
Das und die Vorderseite, das sieht doch so aus, wie:
eine Terminierung per Widerstandsnetzwerk der anderen 8bit
der 16-Daten-Byte?
Kann sich das 'mal jemand ansehen, der Ahnung hat ;-(
:
Bearbeitet durch User
Das sieht für mich schon nach 16 bit aus. Es sind alle 16 Datenleitungen angeschlossen. Für 16 bit spricht ja auch dass Dir Einträge auch auf einer Kopie korrekt angezeigt werde. Zumindest einige. Trotzdem muss es wohl einen Unterschied geben. Ich gegen davon aus dass die images vollkommen korrekt geschrieben wurden. Allerdings ist die Steuercpu wohl 8 Bit welche? Ich würde dann ein paar Latches erwarten. Vielleicht gibts einfach Timming Probleme. Thomas
Das Modul klaut sich seine Signale aus einem Steckplatz für ein 16 bit-EPROM. Dann wird das wohl eine 16 bit-CPU hinterstecken...
Kleines Update: habe noch eine identische Platte im Eb.. ergattern können (danke an Udo A.). Sofort per dd das Image draufkopiert. Ergebnis: Funktioniert ! Was sagt uns das ? Der alte PC, den ich nutze wäre für mein Vorhaben (das Image auf eine grössere Platte zu strecken und zu kopieren) geeignet ? Ich fasse nochmal zusammen was ich verstanden habe: - Das erstellte Image von der alten Platte ist in Ordnung. - Wir wissen immernoch nicht wie die Einteilung der Sektoren auf der grösseren Platte zu organisieren ist. - Wir wissen nicht wie auf die Platte zugegriffen wird (8-Bit, 16-Bit, CHS, LBA). Jetzt könnte ich mich zufrieden zurücklehnen, aber richtig zufrieden bin ich nicht, da die Mission ja war die Platte durch ein aktuelleres IDE-Speichermedium zu ersetzen. Der Ergeiz das zu schaffen ist immernoch vorhanden. Aber vielleicht fällt ja jemandem noch etwas ein.
:
Bearbeitet durch User
Hallo Tom F. schrieb: > eines Update: > > habe noch eine identische Platte im Eb.. ergattern können (danke an Udo > A.). > Sofort per dd das Image draufkopiert. > Ergebnis: > Funktioniert ! Das ist schön. > Was sagt uns das ? > Der alte PC, den ich nutze wäre für mein Vorhaben (das Image auf eine > grössere Platte zu strecken und zu kopieren) geeignet ? Das sollte egal sein > Ich fasse nochmal zusammen was ich verstanden habe: > - Das erstellte Image von der alten Platte ist in Ordnung. Dazu Frage 2 unten: > - Wir wissen immernoch nicht wie die Einteilung der Sektoren auf der > grösseren Platte zu organisieren ist. s.u. > - Wir wissen nicht wie auf die Platte zugegriffen wird (8-Bit, 16-Bit, > CHS, LBA). 16-Bit CHS > Jetzt könnte ich mich zufrieden zurücklehnen, aber richtig zufrieden bin > ich nicht, da die Mission ja war die Platte durch ein aktuelleres > IDE-Speichermedium zu ersetzen. Der Ergeiz das zu schaffen ist immernoch > vorhanden. > Aber vielleicht fällt ja jemandem noch etwas ein. Die Originalplatte (127MB) scheint selbst ein gestrecktes Image eine 80MB Platte zu beinhalten. Der Controller im Keyboard hat eine andere zählweise beim Beschreiben der Festplatte als beim PC üblich. Daher erscheinen die Sektoren beim Blick ins Image, das ja die Sektoren linear hintereinander zeigt, ein wenig verwürfelt. Für's kopieren des Images ist das aber egal. Es sind für mich, sofern ich nichts übersehen habe, immer noch 2 Fragen unbeantwortet: 1. Der Algorithmus in Beitrag "Re: Technics Keyboard Festplatte klonen geht das ?" hat 2 Fehler, wie ich in Beitrag "Re: Technics Keyboard Festplatte klonen geht das ?" beschrieben habe. Ist das Image für die DiskonModule denn jemals mit dem berichtigten Algorithmus beschrieben worden? 2. Die Darstellung des Ordners in Beitrag "Re: Technics Keyboard Festplatte klonen geht das ?" sieht wirklich seltsam aus. Um das mal mit dem Inhalt der Sektoren zu vergleichen, wäre es tatsächlich sinnvoll, mal von allen Ordnern der Originalplatte, die Stücke beinhalten, Fotos einzustellen, so wie in Beitrag "Re: Technics Keyboard Festplatte klonen geht das ?" vorgeschlagen. Die Beantwortung dieser 2 Fragen würde mehr über die Struktur, also die Verteilung der Daten auf die Festplatte aufzeigen. MfG
M.M.M schrieb: > Hallo > > Tom F. schrieb: >> eines Update: >> >> habe noch eine identische Platte im Eb.. ergattern können (danke an Udo >> A.). >> Sofort per dd das Image draufkopiert. >> Ergebnis: >> Funktioniert ! > > Das ist schön. > >> Was sagt uns das ? >> Der alte PC, den ich nutze wäre für mein Vorhaben (das Image auf eine >> grössere Platte zu strecken und zu kopieren) geeignet ? > > Das sollte egal sein > >> Ich fasse nochmal zusammen was ich verstanden habe: >> - Das erstellte Image von der alten Platte ist in Ordnung. > > Dazu Frage 2 unten: > >> - Wir wissen immernoch nicht wie die Einteilung der Sektoren auf der >> grösseren Platte zu organisieren ist. > > s.u. > >> - Wir wissen nicht wie auf die Platte zugegriffen wird (8-Bit, 16-Bit, >> CHS, LBA). > > 16-Bit CHS > >> Jetzt könnte ich mich zufrieden zurücklehnen, aber richtig zufrieden bin >> ich nicht, da die Mission ja war die Platte durch ein aktuelleres >> IDE-Speichermedium zu ersetzen. Der Ergeiz das zu schaffen ist immernoch >> vorhanden. >> Aber vielleicht fällt ja jemandem noch etwas ein. > > Die Originalplatte (127MB) scheint selbst ein gestrecktes Image eine > 80MB Platte zu beinhalten. Sehr sehr unwahrscheinlich aber selbst wenn vollkommen egal. > Der Controller im Keyboard hat eine andere zählweise beim Beschreiben > der Festplatte als beim PC üblich. Daher erscheinen die Sektoren beim > Blick ins > Image, das ja die Sektoren linear hintereinander zeigt, ein wenig > verwürfelt. Für's kopieren des Images ist das aber egal. > > Es sind für mich, sofern ich nichts übersehen habe, immer noch 2 Fragen > unbeantwortet: > 1. Der Algorithmus in > Beitrag "Re: Technics Keyboard Festplatte klonen geht das ?" > hat 2 Fehler, wie ich in > Beitrag "Re: Technics Keyboard Festplatte klonen geht das ?" beschrieben habe. > Das hat der doch garnicht verwendet und sich selbst was geschrieben. Dann war das auch ldgl. ein ungetester Vorschlag wie man das schnell [in wenigen Minuten bis einer halben Stunde] testen könnte ohne das programmierend unter dos oder windows mit irgendeiner Hochsprache zu machen. Spätestens nach dem ersten echten Durchlauf müßte es einem auffallen das da ein paar bytes zuviel raus kommen, das Ergebnis kann ich eh nicht testen also brauch ich das nicht voll durchlaufen lassen. Da in dem entwurf 512 Byteweise kopiert wird ist das doch schnarchlahm reicht aber zu sehen ob der dd aufruf das macht was man sich von ihm wünscht, wenn man das halt nicht aufgreifen mochte, ja mai muß man ja nicht. jdf. kommt dabei wie du etwas weiter unten lesen kannst das gleiche raus wie bei seinem Tool Beitrag "Re: Technics Keyboard Festplatte klonen geht das ?" abhaken und gut, hätte kein son Drama werden müssen ;) Die letzten zwei Meter thread galten ja dem Zweifel ob das image dem Original entspricht, das sollt jetzt abgehandelt sein. Diesbzgl. ldlg. die Nachfrage ob es sich beim Image tatsächlich um die im thread zu findente Datei KN2000DiskImage.rar handelt. Nur der vollständigkeithalber; Was die vermeintlich oder tatsächlich fehlenden FF FFs anlangt, da das Ding schon zbr (zone-bit-recording) verwendet ist kein lowlevelformat mehr möglich also kann der 'Verarbeiter' da auch keine inividuelle geometrie verwendet haben um ggf. mehr Daten unterzubringen. Das fällt damit schonmal aus. Seagte hat übrigens noch einen ftp-server am laufen auf dem man viel altes Zeug findet. Das readme zum seagate-Format4 "sgatfmt4.zip" ist ganz interessant wenn man eine Aufrischer in Sachen RLL/ZBR und frühem IDE will. Im Anhang noch das Original DB zur Platte. ftp.seagate.com/pub/techsuppt/ --- Mit dem DOM modul und ATA 91h mal beschäftigen, testen ob sich die Parameter über einen Reset hinaus nicht irgendwie speichern lassen.
Hallo dolli schrieb: > Das hat der doch garnicht verwendet und sich selbst was geschrieben. OK, das habe ich von da an nur noch oberflächlich wegen.. > Die letzten zwei Meter thread galten ja dem Zweifel ob das image dem > Original entspricht, das sollt jetzt abgehandelt sein. ..verfolgt. > Diesbzgl. ldlg. die Nachfrage ob es sich beim Image tatsächlich um die > im thread zu findente Datei KN2000DiskImage.rar handelt. > > Nur der vollständigkeithalber; > Was die vermeintlich oder tatsächlich fehlenden FF FFs anlangt, Wenn er, wie er schreibt, jetzt das Image mittels dd von/zu Festplatte gleichen Type überspielt hat und das Keyboard wie gewünscht funktioniert, sollte die fehlenden FF FF mindestens dann belanglos sein, wenn das im Image auch so steht. Aber irgendwo ist da faul. Ich werde mir das Mapping noch mal anschauen. MfG
Tom F. schrieb: > Kleines Update: > > habe noch eine identische Platte im Eb.. ergattern können (danke an Udo > A.). > Sofort per dd das Image draufkopiert. > Ergebnis: > Funktioniert ! Schön! Das wurde dir aber mehrfach ganz am Anfang geraten. Was hat dein Keyboard eigentlich zu der neuen unbespielten Platte gesagt?
M.M.M schrieb: > 2. Die Darstellung des Ordners in > Beitrag "Re: Technics Keyboard Festplatte klonen geht das ?" sieht > wirklich > seltsam aus. Um das mal mit dem Inhalt der Sektoren zu vergleichen, wäre > es tatsächlich sinnvoll, mal von allen Ordnern der Originalplatte, die > Stücke beinhalten, Fotos einzustellen, so wie in > Beitrag "Re: Technics Keyboard Festplatte klonen geht das ?" > vorgeschlagen. Ich hoffe man erkennt etwas auf dem Bild. Die ersten 9 Bilder zeigen Page1 (Song 1-300). Ab Ordner 9 ist alles leer Ab Bild 10 ist Page 2 zu sehen. Dort habe ich nur die 2 Unterordner "Fasching"(auch leer) und "Pause" geknipst, da alle anderen Ordner auch leer sind. michael_ schrieb: > Was hat dein Keyboard eigentlich zu der neuen unbespielten Platte > gesagt? Wenn man eine leere Festplatte ansteckt, dann kommt man nicht ins HDD Menü. Wenn man nur den ersten Sektor mit den Geometriedaten auf der Platte hat und sonst alles Null, dann kann man das HDD Menü aufrufen und bekommt eine Blanko Menüstruktur angezeigt(so wie in Bild1 nur ohne Titel). Wenn man dann aber Laden oder Speichern will friert das Keyboard ein. Es wird also anscheinend eine bestimmte Formatierung erwartet.
Bitte 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.