Gelöst: TT030 bootet nicht von neuer SCSI-Platte

[STarship]

Hallo zusammen,

ich wollte einem TT eine "neue" Festplatte implantieren, weil die zum einen größer und zum anderen wesentlich leiser ist, als das bisher verbaute Laufwerk. Nun wird die Festplatte erkannt, läßt sich partitionieren und nimmt auch Daten auf, aber booten will der TT von dieser Platte einfach nicht.

Beim TT handelt es sich um die Mainboardrevision H mit TOS 3.06. Die Ausstattung ist Standard bis auf eine Mighty-MIC, welche mit 20 MB bestückt ist. Ich verwende den aktuellen HDDRIVER 9.1, die fragliche Platte ist eine "Quantum Fireball ST 2.1S". Der SCSI-Bus ist an beiden Enden korrekt terminiert.

Starte ich den TT von Diskette (mit HDDRIVER in AUTO), kann ich ganz normal auf die Platte und das externe CD-Rom zugreifen. HDDRIVER.SYS wurde natürlich auf die Platte installiert, mit anderen (älteren) Platten hatte ich auch nie Probleme.

Mir ist aufgefallen, daß bei anderen Platten, welche normal booten, während des Startvorganges in der Statusanzeige von HDDRIVER die Laufwerkskennung "C" invertiert angezeigt wird, was bei der Problemplatte nicht der Fall ist. Ich habe erfolglos sowohl verschiedene Partitionsgrößen als auch einen Kreuztest mit einem anderen TT versucht.

Unter DOS hätte ich jetzt gesagt, die Partition ist nicht aktiviert... unter TOS scheint es dafür keine Einstellung zu geben, bzw. sollte HDDRIVER bei der Installation das Bootlaufwerk aktivieren (ein Flag dafür gibt es laut Profibuch allerdings).

Kurios ist, daß die NEWDESK.INF beim "Arbeit sichern" auf "C" abgelegt wird, obwohl "A" das Bootlaufwerk ist. Ohne jetzt nachgelesen zu haben würde ich annehmen, NEWDESK.INF sollte eigentlich auf dem Bootlaufwerk, in dem Fall also "A", liegen? Ebenso wird auch "XCONTROL.ACC" von "C" geladen, obwohl von "A" gestartet wird, wo nur "CONTROL.ACC" liegt. Ich nahm bisher eigentlich immer an, daß die ACC's immer vom Bootlaufwerk geladen werden.

Also, die Platte funktioniert und ich kann theoretisch damit arbeiten... nur starten kann ich den Rechner damit nicht. Woran könnte das denn liegen?


Danke schonmal und VG

Sven

[ari.tao]

Welche SCSI-ID hat die Platte? Ist die in HDDRIVER richtig angemeldet? (Unter ´Geräte & Partitionen´)
Was sagt HDDRIVERs ´Geräte-Check´?
Hast Du mal mit DISKUS oder SED geprüft, ob der Bootsektor tatsächlich den richtigen ausführbaren Bootstrap enthält?
Ich hatte mal zwei Fireballs (´ne Nummer kleiner), kann mich dunkel erinnern, daß eine davon damals auch irgendwie zickte. Ist aber so lange her, daß ich´s total vergessen habe. Bevorzuge heute lautlose CFs. Notfalls kannst Du eine Diskette präparieren mit einem CAUTO.PRG oä. im A:\AUTO\, welches dann die Bootsequenz umleitet.

(ich bin nun erstmal weg - im Urlaub)

Edit.: Anhang ebbs umstrukturiert und, soweit es mein eigenes CopyRight betrifft, mit GPL versehen.

[Lukas Frank]

Starte mal vom Uwe Seimet das Bootconf NVRAM Programm und schaue ob der Rechner die SCSI ID_7 hat und SCSI Initator angeschaltet ist ...

Wenn es nicht klappt ist deine NVRAM Batterie vielleicht leer !?!

[STarship]

Moin ari.tao,

danke für Deine Antwort.

Welche SCSI-ID hat die Platte?

Die Platte hat die 0, der Controller die 7. Das CD-Rom hängt dazwischen auf der 5, aber es hat auf das Bootverhalten keinen feststellbaren Einfluß, ob das überhaupt am TT hängt oder ob ich es abklemme.

Ist die in HDDRIVER richtig angemeldet? (Unter ´Geräte & Partitionen´)

Ja, ist aktiviert.

Was sagt HDDRIVERs ´Geräte-Check´?

Nun, der Check listet mir die beiden Controller auf (ACSI & SCSI) und die beiden Laufwerke (HDD & CD-Rom), ist also alles da.

Hast Du mal mit DISKUS oder SED geprüft, ob der Bootsektor tatsächlich den richtigen ausführbaren Bootstrap enthält?

Nein, das ist aber eine Idee. Ich werde das heute mal in Angriff nehmen, allerdings habe ich damit keine Erfahrung... ich versuch's mal.

(ich bin nun erstmal weg - im Urlaub)

Dann wünsche ich Dir einen schönen und erholsamen Urlaub. :-)


VG

Sven

[STarship]

Hallo Lukas Frank,

Starte mal vom Uwe Seimet das Bootconf NVRAM Programm und schaue ob der Rechner die SCSI ID_7 hat und SCSI Initator angeschaltet ist ...

Wenn es nicht klappt ist deine NVRAM Batterie vielleicht leer !?!

Den (oder sagt man "das"?) NVRAM hatte ich auch schon in Verdacht und hatte einen Reset mit RESETNVR durchgeführt und anschließend mit dem dazugehörenden CONFIG die Einstellungen neu gesetzt. Allerdings hatte ich in CONFIG nur die Option, die Systemsprache einzustellen.

Ich werde mir mal das Programm von Uwe Seimet herunterladen und damit nochmal rangehen. Aber müßte spätestens nach dem Reset nicht zumindest eine Art "Standardkonfiguration" aktiv sein, in welcher der Controller die ID 7 zugewiesen bekommt?

Laut HDDRIVER hat er diese ID. Aber ich weiß nicht, ob das Bootverhalten dennoch von irgendwas im NVRAM sabotiert werden kann, dazu reichen meine derzeitigen Kenntnisse noch nicht aus.

Wenn ich das NVRAM mal mit dem BIOS eines "normalen" PC gleichsetze, man möge mir diese Blasphemie verzeihen, wäre das ja durchaus möglich. Dort kann man ja auch eine IDE-Platte korrekt anmelden und dennoch das booten von selbiger per BIOS-Auswahl unterbinden. Wie gesagt weiß ich aber nicht, ob das NVRAM eines TT annähernd vergleichbar umfangreich ist.

Die Batterie ist tatsächlich leer. Bis Ersatz eintrifft, habe ich provisorisch eine externe 3 V Versorgung angelegt.


VG

Sven

[Lukas Frank]

Nach einem Reset des NVRAM steht die SCSI ID meist auf 0 und SCSI-Initator ist auf aus ...

HDDriver listet den Rechner normalerweise mit der eigenen SCSI ID.

[STarship]

Hallo,

Nach einem Reset des NVRAM steht die SCSI ID meist auf 0 und SCSI-Initator ist auf aus ...

Ich hab das grad mal mittels BOOTCONF eingestellt... leider ohne Erfolg. Die ID war auf 0 und ist jetzt auf 7, Init ist jetzt auch an, aber die Platte weigert sich nach wie vor, gebootet zu werden.

Mit der Platte die vorher drin war ließ sich der TT allerdings auch starten, bevor ich den NVRAM neu eingestellt hatte, also auch ohne Init und mit der hinterlegten ID 0, was die ganze Sache für mich nicht unbedingt einfacher macht. ;-)

Ich werd mal versuchen herauszufinden, was in Root- bzw. Bootsektor drinsteht. An irgendwas muß es ja liegen...

Daß die Platte ansich für einen TT zu groß sein soll, kann ich mir nicht vorstellen. So wie ich das verstanden habe, muß man wohl hauptsächlich darauf achten, die maximal zulässige Größe der Partitionen nicht zu überschreiten. Da die Platte selbst mit einer 10 MB "großen" Partition nicht booten mag, schließe ich das als Ursache eher aus.


VG

Sven

[tuxie]

das gleiche problem hatte ich auch, kannst du nur mit einer anderen festplatte lösen. warum, keine ahnung

[STarship]

Hi ingo,

das gleiche problem hatte ich auch, kannst du nur mit einer anderen festplatte lösen. warum, keine ahnung

Nicht doch, das wäre recht ärgerlich... 

Beim Mega-STE könnte sowas ja noch verstehen, aber im TT, der meines Wissens einen "richtigen" SCSI-Controller enthält, sollte das _eigentlich_ nicht passieren. Vielleicht hat ja noch jemand eine Idee.

Die Alternative wäre, diese Platte in einem externen Gehäuse als zusätliches Datengrab zu betreiben... aber dazu mangelt es derzeit am Gehäuse. Intern als Bootlaufwerk wäre sie mir schon lieber. 


VG

Sven

[1ST1]

Ich kenne dieses Problem und du wirst mit DIESER Platte keine Chance haben. Du kannst zwar mit Bootconfig dem TT Initiator und SCSI ID 7 beibringen, das macht der TT (und Falcon!) aber erst, wenn HDDRIVER geladen wurde. Der erste Zugriff aus TOS auf die Platte erfolgt noch "unsauber", spricht nicht SCSI-konform, sprich nicht mit sauberer Initiator-Rolle (eben so wie TOS es auch auf ACSI macht), und damit kommt die Firmware dieser Platte nicht zurecht. Du kannst sie aber als nicht bootfähige Zweitplatte verwenden.

Die Größe der Platte spielt beim TT übrigens kaum eine Rolle, ich habe in meinen beiden TTs leise 15K 73 GB SCA-SCSI-Platten von Seagate drin, die booten einwandfrei. 1x 512 MB Partition für C: zum Booten, dann 15 Partitionen mit 1 GB die erst nach dem Start von Bigdos aus dem Autoordner lesbar sind, und der Rest LNX und F32 für MiNT und irgendwann mal Debian (wenn endlich die Magnum TT da ist). Ich hatte auch inzwischen mal eine 146 GB SCA-Platte dran, die ging auch, die war mir aber zu laut.

[STarship]

Hallo,

Ich kenne dieses Problem und du wirst mit DIESER Platte keine Chance haben. <snip> Du kannst sie aber als nicht bootfähige Zweitplatte verwenden.

Somit scheinen sich meinen Befürchtungen zu bewahrheiten... Pech muß man haben. Nun gut, dann muß es erstmal mit der kleinen Platte gehen und ich versuche, ein externes SCSI-Gehäuse aufzutreiben. Vielleicht gleich einen kleinen 4-Bay Tower. Dann kann ich die Platte immer noch als Datengrab verwenden.

Die Größe der Platte spielt beim TT übrigens kaum eine Rolle, ich habe in meinen beiden TTs leise 15K 73 GB SCA-SCSI-Platten von Seagate drin, die booten einwandfrei. 1x 512 MB Partition für C: zum Booten, dann 15 Partitionen mit 1 GB die erst nach dem Start von Bigdos aus dem Autoordner lesbar sind, und der Rest LNX und F32 für MiNT und irgendwann mal Debian (wenn endlich die Magnum TT da ist). Ich hatte auch inzwischen mal eine 146 GB SCA-Platte dran, die ging auch, die war mir aber zu laut.

Diesbezüglich habe ich auch mit Interesse den Thread um SCSI-Platten im Mega STE und TT verfolgt. Um ehrlich zu sein habe ich Schwierigkeiten zu glauben, daß eine mehr oder minder betagte 10k rpm Festplatte eine wohnzimmertaugliche Geräuschkulisse aufbaut. Die oben erwähnte Fireball ST dreht mit 5400 rpm, die ist gerde noch leise genug, aber dennoch hörbar. Ich bin durch meinen Tinnitus recht empfindlich geworden, was hochfrequente Geräusche angeht.

Andererseits kostet die von Dir benannte Seagate nicht die Welt, so daß ich es wohl einfach mal auf einen Test ankommen lasse. Die Möglichkeiten einer entkoppelten Montage der Festplatte im TT müßte ich mal ausloten, da kann man sicher was machen. Was mir ein wenig Sorgen macht, ist der zusätzlich benötigte Verhau an Adaptern, damit die Platte läuft.

Ich würde ja auch eine kleinere (also <73GB  ) leise Platte nehmen, sofern sie im TT anstandslos läuft. Das Prädikat _leise_ war der Hauptgrund, warum ich die derzeit verbaute Kreissäge durch die Fireball ersetzen wollte.


VG

Sven

[tuxie]

Unser TT Ide interface ist so gut wie fertig, haben jetzt noch einige Optimierungen eingebaut, ich denke das wir demnächst wenn alles soweit Funktioniert in die Produktion gehen können. Mit einer CF, leiser geht es nun wirklich nimmer. Ist dann am ende der Gehäuselüfter viel Lauter

[STarship]

Hi Ingo,

Unser TT Ide interface ist so gut wie fertig, haben jetzt noch einige Optimierungen eingebaut, ich denke das wir demnächst wenn alles soweit Funktioniert in die Produktion gehen können. Mit einer CF, leiser geht es nun wirklich nimmer. Ist dann am ende der Gehäuselüfter viel Lauter

Lüfter? Welcher Lüfter? Ne Pico-PSU braucht doch keinen Lüfter... 

Nee Scherz, es ist noch das originale Netzteil drin, aber den Lüfter habe ich schon durch ein besonders leises Modell ersetzt.

Ja, der Umbau auf SD- bzw- CF-Karte wäre natürlich was. Andererseits, und das meine ich jetzt nicht im negativen Sinne, erschließt sich mir die Notwendigkeit eines IDE-Interfaces für den TT nicht. Der hat einen ROM-Port, ACSI, SCSI, VME und es gibt wohl auch USB-Adapter für'n Atari. Wären grad letztere nicht prädestiniert für den Anschluß von allerlei Peripherie, die in Massen am Markt verfügbar ist? Klar braucht man dafür Treiber, aber die brauche ich ja für ein IDE-Interface genauso. Den potentiellen Geschwindigkeitsvorteil kann ein unmodifizierter Atari meiner laienhaften Einschätzung nach nicht wirklich ausnutzen, und wenn man ihn ordentlich pimpt, besteht immer die Gefahr daß irgendeine Software nicht mehr korrekt mitspielt.

Ich kann mangels der Programmierkenntnisse natürlich nicht beurteilen, ob die Entwicklung eines Treibers für einen USB-Cardreader oder die Nutzung von USB-Sticks bzw. -Festplatten wesentlich schwieriger sein könnte, als das für einen IDE-Treiber der Fall wäre.

Andererseits sind ja die Verwendungsmöglichkeiten von IDE gegenüber USB recht eingeschränkt und IDE verschwindet allmählich ebenso vom Markt wie schon seinerzeit SCSI, was eher früher als später die gleichen Probleme aufwerfen könnte, wie wir sie jetzt zum Beispiel mit Disketten, alter SCSI-Hardware oder sonstigen inzwischen kaum noch erhältlichen (Ersatz-)Teilen haben. Daher würde ich mir persönlich wünschen, daß neue Entwicklungen eher auf halbwegs aktuelle Technologien setzen, damit sie möglichst lange nutz- und erweiterbar bleiben. Das wäre mit USB (Mäuse, Laufwerke, Netzwerkadapter, Drucker, Scanner, Fluxkompensator etc.) und SATA (beherrscht HDDRIVER bzw. MiNT eigentlich TRIM? ) zum Beispiel gewährleistet. Klar kann man auch mit Adaptern hantieren, aber das ist imho in erster Linie eine weitere Fehlerquelle und nimmt Platz weg.

Aber wie ich schon sagte, ist das nicht negativ gemeint. Das sind nur Gedanken von mir, der ich mich weder mit Soft- noch mit Hardwareentwicklung fundiert auskenne. Es wird sicher einen guten Grund geben, warum es ein IDE-Interface wird. Ich werd's mir auf jeden Fall anschauen, und wenn's hinhaut werd ich wohl auch eines abnehmen. Mir ist alles willkommen, was die Möglichkeiten meiner Schätze erweitert.

...wir schweifen ab. 


VG

Sven

[SolderGirl]

Ich kann mangels der Programmierkenntnisse natürlich nicht beurteilen, ob die Entwicklung eines Treibers für einen USB-Cardreader oder die Nutzung von USB-Sticks bzw. -Festplatten wesentlich schwieriger sein könnte, als das für einen IDE-Treiber der Fall wäre.

Ich habe mich in anderem Zusammenhang erst kürzlich etwas mit dem USB Mass Storage Profil beschäftigt, und dabei herausgefunden, das dabei wohl SCSI-Kommandos eingesetzt werden.
Also müsste man für einen Adapter von ACSI/SCSI auf USB "nur" die physikalische Schnittstelle umsetzen, kann aber die eigentlichen Befehle vom Controller praktisch unverändert an das USB-Device durchreichen.
Da der Befehlssatz bei IDE (eigentlich nur ein verlängerter AT-Bus) komplett anders ist, hat man da deutlich mehr Aufwand.

[Lukas Frank]

->   http://www.atarikit.co.uk/unicorn/unicorn.html

Alan hat einen Treiber dazu geschrieben um USB Massenspeicher mit dem HDDriver einrichten und nutzen zu können. Ich meine USB Cardreader (USB 1.1) gehen auch ...

[tuxie]

Ganz Einfach, es ist viel Einfacher eine CF einzusetzen, und unser Interface ist 100% PC Kompatibel.

d.h. CF in den PC, daten drauf und CF wieder in den Atari TT.. Funzt 1a ohne extra Treiber

Und Geschwindigkeit ist auch um ein vielfaches höher als SCSI oder ACSI oder RomPort. Genaue Daten werde ich noch nicht nennen. Werden wir wenn das Interface endgültig Fertig ist.

[czietz]

Ich kenne dieses Problem und du wirst mit DIESER Platte keine Chance haben. Du kannst zwar mit Bootconfig dem TT Initiator und SCSI ID 7 beibringen, das macht der TT (und Falcon!) aber erst, wenn HDDRIVER geladen wurde. Der erste Zugriff aus TOS auf die Platte erfolgt noch "unsauber", spricht nicht SCSI-konform, sprich nicht mit sauberer Initiator-Rolle (eben so wie TOS es auch auf ACSI macht), und damit kommt die Firmware dieser Platte nicht zurecht. Du kannst sie aber als nicht bootfähige Zweitplatte verwenden.

Wenn das das einzige Problem mit dieser Platte ist, habe ich gerade gesehen, dass es in TosPatch einen Patch dafür gibt. Setzt natürlich voraus, dass @STarship neue TOS-ROMs brennen kann:

Code: [Auswählen]

;* Initiatoridentification beim SCSI-Zugriff, TT meldet sich als ID 7
;* Damit kann auch von Quantum Empire u.ä. gebootet werden.http://www.markusheiden.de/atari/tospatch.html

[STarship]

Hallo,

Ich kenne dieses Problem und du wirst mit DIESER Platte keine Chance haben. Du kannst zwar mit Bootconfig dem TT Initiator und SCSI ID 7 beibringen, das macht der TT (und Falcon!) aber erst, wenn HDDRIVER geladen wurde. Der erste Zugriff aus TOS auf die Platte erfolgt noch "unsauber", spricht nicht SCSI-konform, sprich nicht mit sauberer Initiator-Rolle (eben so wie TOS es auch auf ACSI macht), und damit kommt die Firmware dieser Platte nicht zurecht. Du kannst sie aber als nicht bootfähige Zweitplatte verwenden.

Wenn das das einzige Problem mit dieser Platte ist, habe ich gerade gesehen, dass es in TosPatch einen Patch dafür gibt. Setzt natürlich voraus, dass @STarship neue TOS-ROMs brennen kann:

Code: [Auswählen]

;* Initiatoridentification beim SCSI-Zugriff, TT meldet sich als ID 7
;* Damit kann auch von Quantum Empire u.ä. gebootet werden.http://www.markusheiden.de/atari/tospatch.html

Das mit den TOS-Roms wird noch was dauern. Ich habe das ganze mehr oder weniger gelöst, mit einer anderen Festplatte. Mit der Fireball geht's halt nach wie vor nicht, mit einer IBM DNES funktioniert das dagegen reibungslos. Die Fireball läuft jetzt als zusätzliches Datengrab im SCSI-Tower.

VG
Sven

[czietz]

IBM sichert diese Funktion im Handbuch der DNES auch ausdrücklich zu:

For single initiator systems, it is not an error to have only the target ID bit present during selection.