Hardware > Hardware (Classic 16-/32-Bit)

Gewitter in meinem TT030

<< < (9/19) > >>

Gast120501:

--- Zitat von: Arthur am Fr 15.06.2018, 05:14:39 ---Byteswap ist nur bei IDE sinnvoll. Bei scsi und usb wird nicht 16bitweise darauf zugegriffen.

--- Ende Zitat ---

@ari.tao - Verbietest du jetzt Arthur auch, in "deinen" Threads zu schreiben?

Gast160608:

--- Zitat von: 1ST1 am Mo 18.06.2018, 08:40:03 ---Verbietest du jetzt ... auch, in "deinen" Threads zu schreiben?
--- Ende Zitat ---
Laß bitte andere außen vor, es genügt völlig, wenn Du @1ST1 aus diesem Thread verschwindest!

Johannes:
@ari.tao Das hier ist ein öffentliches Forum. Wenn Du einen geschlossenen Benutzerkreis möchtest, mach bitte Dein eigenes Forum auf.

@1ST1 und alle anderen, bitte beschränkt euch auf Hinweise, die zur Klärung des Problems beitragen und keine Grundsatzdiskussionen auslösen. Nicht schon wieder. Danke.

Gast160608:

--- Zitat von: ari.tao am Mo 18.06.2018, 07:22:23 ---Das .BAT ist inzw. ok, aber immer wenn ich Storage.PRG einhänge, dann gibt´s Probleme ("Fataler Error in GEMDOS" oder er vermißt LW A:) - aber erst nach den USB-BootMeldungen. USB-Maus läuft. USB-Keyboard habe ich keins, darum ~.PRG ausgehängt.
--- Ende Zitat ---
Ich habe nun, ziemlich mühsam, genaueres herauszufinden versucht:
Offenbar tritt das Problem genau dann auf, wenn Storage.PRG im Boot dabei ist. Ich tippe mal auf eine fehlende Initialisierung, womöglich sogar ein Dangling Pointer, denn die Symptome treten immer erst dann auf, wenn alle BootMeldungen bis einschl. "USB storage driver installed." durch sind.
Ich habe auch mal versuchsweise Blitz030.PRG nach Start\ verlagert - dann kommt der von Storage.PRG verursachte Absturz trotzdem schon im AUTO\ ; wenn zusätzlich auch Storage.PRG dahin verlagert wird, kommt man mit viel Glück nach WarmStart manchmal bis zum Desktop, meistens aber bleibt der Boot beim bunten TestSchirm der GK (CrazyDots) hängen. Ohne Storage.PRG läuft alles (ie. USB.PRG, Mouse.PRG & Blitz030.PRG) problemlos hoch, die USB-Maus funzt.

Edit.:
Mit der neuen Version des Storage.PRG von @czietz (die ich eher zufällig gefunden habe) sind die oben geschilderten Probleme verschwunden.

Gast160608:
Ein erstes Clonen von 4GB mit Thunder:
   Von CF in IDE0 auf CF in IDE1 und von dort auf SD am Yamaha.

Die guten Nachrichten:
Die Clone waren beide fehlerfrei (geprüft mit TreeCheck).  :D
Von IDE1 auf den Yamaha dauerte die Kopie ca. eine Stunde und war damit etwa ein drittel schneller als der gleiche Vorgang auf dem Falcon, was der Erwartung entspricht (weil ich noch den alten HDDRIVER_8.45 benutze und das TT_RAM im Storm auf FP gejumpert war). Da ist also noch eine Verbesserung möglich.  :D

Und nun die weniger guten Nachrichten:
Von IDE0 auf IDE1 dauerte es (unter gleichen Umständen wie oben) ca. einundeinhalb Stunden, also etwa doppelt so lang wie auf dem Falcon.  :(
Noch erstaunlicher - geradezu erschreckend - war das damit verbundene ziemlich laute Geräusch: Hört sich an, als ob die Daten mit Schaufeln übertragen werden. Woher kommt das @Gaga , was ist da los?  :o

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete