atari-home.de - Foren
Software => Alternative Betriebssysteme => Thema gestartet von: RealLarry am Sa 17.09.2016, 12:03:14
-
...habe hier ein seltsames Verhalten:
In nahezu allen Fällen des Boots bei angeschlossenem Gerät am Parallel-Port mag die MatTC nicht initialisieren ("falsche Paletten-ID"), danach geht es im Blindflug weiter.
Zuerst dachte ich, dass aus unerfindlichen Gründen vielleicht das NVRAM zickt; beim Ausschluss-Verfahren kam ich dann aber dahinter, dass es der Parallel-Port ist.
Hier ging ich dann davon aus, dass vielleicht das ParCP-Device Ärger macht, aber auch bei angeschlossenem Laser-Drucker treten diese Boot-Probleme auf.
Klemme ich das Gerät vom Parallel-Port ab, ist Ruhe und alles läuft normal. Auch die Geräte am P.-Port funktionieren - wenn das ganze denn mal zusammen bootet.
Jemand eine Idee?
-
Zauberei ...
Ich hatte so was in der Art mal an einem Mega ST. Immer wenn ich eine Megafile über das DMA Kabel angesteckt hatte wollte der Rechner nicht mehr.
Ich tippe mal auf unterschiedliche Masse Potenziale ...
-
Ich tippe mal auf unterschiedliche Masse Potenziale ...
DAS dachte ich auch schon. Leider habe ich an dieser Stelle nur eine Steckdose -> Leiste -> Equipment :(
-
Wenn du ein Multimeter hast stecke doch mal alles in die Steckdose und schalte beide Sachen ein. Den Druckerport Stecker nicht verbinden und mal AC und auch DC zwischen Rechner Druckerport Masse und Druckerkabel Masse messen ...
-
...werd' ich mal ausprobieren und berichten. Danke für den Hinweis.
-
Ich hatte am Wochenende mal wieder das Vergnügen der "falsche Paletten-ID"-Meldung, die stetig nervte und ein Arbeiten unmöglich machte - obwohl nichts weiter am TT angesteckt war.
Scheinbar habe ich jetzt aber des Rätsels Lösung gefunden. Daher für's Archiv:
Wenn wer das NVRAM löscht oder verändert und danach die besagte Meldung des NVDI/MatTC beharrlich auftaucht, den Rechner ohne Grafik-Treiber starten, BOOTCONF von Uwe Seimet aufrufen und dort 65535 Farben / 40 Spalten einstellen; Neustart und gut ist.
-
Ich kann mir nicht recht vorstellen, daß das mit der Bildschirmauflösung beim Booten zu tun hat, wenn der Drucker angesteckt ist und glaube, Du "versteckst" den Fehler so nur. Die hohe Farbtiefe macht den Rechner ein wenig langsamer, wahrscheinlich geht's deswegen.
Was ich mir viel eher vorstellen kann, ist ein Problem mit dem Netzteil. Das einzige, was ein ansonsten inaktiver Drucker macht, ist ein paar Leitungen des Druckerports mit PullDowns/Ups in die Richtung ziehen, die er gerne hätte. Vielleicht reicht das ja schon aus, um dein Netzteil soweit in die Knie zu zwingen, daß die Grafikkarte nicht mehr schnell genug Antwort gibt?
-
Ich kann mir nicht recht vorstellen, daß das mit der Bildschirmauflösung beim Booten zu tun hat, wenn der Drucker angesteckt ist und glaube, Du "versteckst" den Fehler so nur. Die hohe Farbtiefe macht den Rechner ein wenig langsamer, wahrscheinlich geht's deswegen.
Dachte ich auch. Aber Versuch macht Kluch ;) und der Fehler tritt ja mit als auch ohne angesteckten Drucker (und anderen Geräten) auf. Die eigentliche Farbtiefe wird ja dann auch durch den eigentlichen Grafiktreiber (NVDI/MatTC) entsprechend gesetzt; ich fahre die MatTC mit 1280x1024x8 und der TT samt MatTC rennt wie Sau.
Was ich mir viel eher vorstellen kann, ist ein Problem mit dem Netzteil. Das einzige, was ein ansonsten inaktiver Drucker macht, ist ein paar Leitungen des Druckerports mit PullDowns/Ups in die Richtung ziehen, die er gerne hätte. Vielleicht reicht das ja schon aus, um dein Netzteil soweit in die Knie zu zwingen, daß die Grafikkarte nicht mehr schnell genug Antwort gibt?
Das mag zwar alles sein, aber durch das Setzen von 65535/40 ist der Fehler (bislang) reproduzierbar weg und die Kiste rennt stabil. Und jetzt auch mit Drucker, CosmosEx/ACSI und internen wie externen SCSI-Geräten. Mehr will ich ja gar nicht 8)
Sicherlich ist dieser Fehler seltsam und genauso seltsam zu beheben; ich möchte das hier eben nur für andere, die ggf. einen ganz ähnlichen Fehler haben (werden), als möglichen Ansatzpunkt zur Lösung festhalten.
-
Die Video Einstellungen im NVRam sind eigentlich Falcon only ...
-
Die Video Einstellungen im NVRam sind eigentlich Falcon only ...
Ja, steht auch so im README. Funktioniert aber wohl dennoch beim TT...zumindest zeigt es eine Wirkung :)
-
Der Atari TT spinnt schonmal wenn Mist im NVRam steht. Du nutzt bestimmt NVDI5, hast du mal eine 3er oder 4er Matgraph TC Version probiert ?
-
[...] Du nutzt bestimmt NVDI5, hast du mal eine 3er oder 4er Matgraph TC Version probiert ?
Ja, ist NVDI5. Und nein, ich habe keine andere Version ausprobiert. Solange das Problem nur gelegentlich auftritt (2* in 8 Monaten) und ich mir mit BOOTCONF fix helfen kann, reicht mir das völlig.