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.