atari-home.de - Foren
Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet von: Atariosimus am Fr 04.05.2018, 09:12:55
-
Aufmerksam auf Exxos Artikel geworden
https://www.exxoshost.co.uk/atari/last/gigafile/index.htm (https://www.exxoshost.co.uk/atari/last/gigafile/index.htm)
habe ich auch manchmal Bootprobleme. Diese finde ich zwar nicht so schlimm wie bei Exxos,
denn booten geht irgendwie immer aber vielleicht kann man da noch etwas optimieren.
Die Gigafile habe ich jetzt mehr als ein halbes Jahr im Einsatz.
Zunächst ist bei mir eine interne Gigafile mittels Adapter im MegaSTE eingebaut. Bei Exxos
ist diese extern.
Symptome:
1) Der Rechner wird frisch gestartet und zeigt dann nur die Floppylaufwerke an ohne Festplattensymbol.
Dabei wird der Speichertest nicht unterbrochen oder irgendeine Taste gedrückt.
Die Gigafile wird nach einem Kaltstart einfach nicht erkannt. Nach Drücken des Resetknopfes kommt sie dann. Dieser Vorgang passiert sehr häufig, wenn der Rechner zum ersten mal gestartet wird, also Stromschalter auf ein. Gelegentlich klappt es auch sofort.
2) Drücke ich Reset, weil ein Programm abgestürzt ist oder einfach um ein Programm zu unterbrechen,
direkt nach dem Hochfahren oder auch später, kommen 4 Bomben.
Hier hilft nur mehrmaliges längeres Drücken der Resettaste um die Gigafile wieder booten zu lassen.
Die 4 Bomben erweisen sich dann als sehr hartnäckig. Kurzes Drücken reicht nicht aus sondern 10 bis 20 Sekunden oder auch länger. Das passiert mit großer Häufigkeit.
Die PSU ist komplett mit neuen Kondensatoren ausgerüstet. Deshalb gehe ich nicht als Ursache
von dieser aus. Wie Exxos schreibt hat er Kondensatoren zwischen Masse und ACK sowie DRQ Leitung
in der Größenordnung von 220 pF und 370pF am Adapter angelötet. Damit konnte er das Problem
lösen.
Sofern die Gigafile richtig gebootet hat läuft diese sehr stabil. Die Software von Uwe Seimet
ist die Version 10.
Interessant fand ich noch folgende Bemerkung vom Hersteller der Gigafile:
I emailed the makers of Gigafile who said.
The problem is, that there are a various of chips with different timings. In principle it is possible to adjust the GigaFile individually but not for all together
-
Vielleicht muß da schlicht eine kleine Boot-Verzögerung ´rein?
(So wie früher bei Platten, die vor dem Rechner gestartet werden mußten).
-
Kann sein, die Symptome müßten eigentlich auch andere haben vermute ich.
Vielleicht melden sich ja noch ein paar um das zu bestätigen.
-
Hat nix mit einer Boot-Verzögerung zu tun. Die hat ja TOS 2.06 durch den Speichertest und den anschließenden Warte-Balken schon drin. Hat auch nix mit Elko-Problemen im Netzteil zu tun.
ACK sowie DRQ sind ja Signale auf dem ACSI-Bus. Und jetzt überlegen wir mal, was Kondensatoren auf geschalteten Steuersignalen machen...
Die Natur eines Kondensator ist, sich bei angelegter Spannung (mehr oder weniger langsam) aufzuladen. Das heißt, du legst schlagartig (über einen Vorwiderstand, der kann auch einfach ein Draht sein) an den Kondensator eine Spannung an. Das bedeutet, der Kondensator hat nicht schlagartig auch diese Spannung, sondern er lädt sich bis zur Maximal-Spannung auf. Die Zeit, die er braucht, um sich aufzuladen gibt man pauschal mit "5 mal Tau" an, wobei die Zeitkonstante Tau = R * C, also Vorwiderstand R mal Kapazität C. Je kleiner R, um so schneller, je größer die Kaparität C, um so langsammer. Während er sich auflädt, fließt ein Strom durch den Kondensator, der um so geringer wird, je weiter sich der Kondensator auflädt. Ist er vollständig aufgeladen, fließt nur noch ein winziger Leckstrom. Die Spannung folgt dabei einer e-Funktion. Ähnliches passiert auch, wenn man an einen aufgeladenen Kondensator plötzlich Masse anlegt, der Kondensator entlädt sich wieder, es fließt ein Strom aus dem Kondensator heraus, und die Spannung am Kondensator wird immer kleiner, auch hier beträgt die Entladezeit wieder 5 mal Tau.
Das heißt, das Signal ACK und DRQ wird durch die Kondensatoren verändert, man sagt auch "verschliffen" oder verzögert, das Low-Signal liegt länger an, als ohne den Kondensator, auch der High-Pegel wird länger gehalten.
Hier mal eine Prinzip-Skizze, die das mit der Zeitverzögerung des Signals darstellt. Ich hoffe, das macht verständlich, was Kondensatörchen auf Signalleitungen so machen. Und wenn du jetzt auf dem ACSI-Bus den WIderstand R suchst, es ist die Leiterbahn, das Kabel, der Stecker, die haben nämlich auch einen Widerstand, der ist klein, aber die angelöteten Kondensatörchen auch. Der Effekt ist minimal, aber bei Exxos hat es wohl gereicht, denn die Wege der Elektronen sind manchmal auf den ersten Blick unergründlich, und Hochfrequenz (wir reden auf dem ACSI-Bus von 8 MHz) ist sowieso Voodoo. (Anmerkung: Die Entladekurve ist mir besser gelungen als die Ladekurve)
-
Hast oder hattest Du denn auch solche Symptome? Schöne Erklärung übrigens.
Exxos hatte bisher immer sehr gute Tipps. Ich besorg mir auch mal solche Kondensatoren,
wenn es nicht hilft kommen die wieder weg.
-
Ich habe keine Gigafile. Aber ich hatte - wie einige andere hier im Forum - mal was mit Elektrotechnik und Elektronik in der Berufsausbildung und im Studium. Es gibt auch Bücher zur Selbstlektüre, wo man sowas lernen kann, auch die entsprechenden Wikipedia-Artikel sind nicht schlecht zum Einstieg, wenn man weiß wonach man suchen muss.
Vielleicht kann auch @wfoerster was zu dem Propblem sagen?
-
Förster hatte ja im Prinzip bei Exxos schon alles gesagt. Ich wollte eigentlich nur von
anderen Anwendern wissen, ob sie auch solche Erlebnisse haben und ob sie diese lösen konnten.
-
Ich hatte eine Gigafile in meinem TT. An sich hat sie auch prima funktioniert, schön schnell, klein, nichts weiter zu beachten. Dafür bekam ich sie niemals in der Art zum Laufen, dass ich weitere (externe) SCSI-Geräte benutzen konnte. Entweder blieb die Gigafile einsam auf ID0, belegte alle IDs oder der ganze Bus blieb leer (je nach Jumper der IDs, TermPower etc.).
Ich habe sie dann gegen eine UltraSatan eingetauscht, einen SCSI<->USCSI-Adapter angeschafft und eine USCSI-HDD eingebaut. Seitdem ist der TT wieder glücklich...
-
Hatte Anfangs ein ähnliches Problem mit der Gigafile. Bei den meisten Startvorgängen (MegaSTE mit HDDriver 10.03), wurde die Gigafile überhaupt nicht erkannt.
W. Förster hat dann Filterkondensatoren auf der Unterseite des ASCI Adapters der GigaFile eingelötet.
Gelegentlich, aber inzwischen sehr selten, kommt es trotzdem vor, dass ich nochmal einen Reset durchführen muss.
Das hängt, vermutet W.F., "mit Wakestates zusammen - kurz gesagt
ein nicht optimalen Timing zwischen DMA, Glue und MMU". Eine Lösung hat er bisher noch nicht
gefunden.
Aber zu 95% läuft die Gigafile normal an.
-
Ah, das ist doch das was ich als Antwort erwartet habe. Kannst Du mir sagen was da für Kondensatoren
eingelötet wurden und wo? Vielleicht ein Bild? Ansonsten halte ich mich an die Beschreibung von
Exxos.
@RealLarry gibt es solche Symptome auch bei der UltraSatan?
-
Schreib doch einfach mal W. Förster an, er ist bestimmt behilflich.
Ansonsten ist die Modifikation so, wie von Chris Swinson in "The LaST Upgrade" beschrieben.
-
Ist denn bei der UltraSatan so was auch vorgekommen? ;D
-
Auch bei der UltraSatan
http://joo.kie.sk/?page_id=250
-
Beim 2ten Boot scheint es zu klappen nach jookie. Das hab ich auch. Aber nicht immer.
Manchmal kommt die Festplatte sofort. Und schlechte DMA Chips find ich nicht.
Scheint zumindest kein spezifisches Gigafileproblem zu sein.
Ich werde Exxos Tipp mal anwenden.
Welchen Typ von Kondensatoren sollte man einsetzen? Tantal??
-
Auf dem Bild sind das zwei Styroflex Kondensatoren. Normale Keramische sollten aber auch gehen denke ich mal ...
-
Styroflex gabs bei Conrad nicht. Auch 370pF hatte der nicht. Habe mir Wima geben lassen mit 330pF.
Wird man sehen ob das klappt. Höchstens ich finde noch welche in der Krabbelkiste die sind jedoch
20 Jahre alt. Bin mal gespannt was passiert.
-
Ich hatte ein vergleichbares Problem, das sich allerdings durch Wechsel der SD-Karte lösen ließ. Eine meiner SD-Karten lief reproduzierbar überhaupt nicht in der Gigafile; eine andere hatte die hier Thread beschriebenen gelegentlichen Bootprobleme. Mit der Karte, die ich jetzt nutze, ist im MegaSTE alles gut. Evtl. testest Du auch mal verschiedene Karten?
Das zeigt, dass das alles ein komplexes Thema ist, an dem nicht nur das Timing des ACSI-Busses schuld ist.
Ich hatte Wolfgang Förster übrigens die Infos zu der überhaupt nicht funktionierenden Karte geschickt, damit er diesen Fehler suchen kann, aber nichts mehr dazu gehört...
-
parallel von 330pF + 33 oder 39pF
-
Jetzt frag ich mich nur noch wo ist DRQ und ACK?
Meine Version sieht anders aus. Wo häng ich die Kondensatoren am Besten dran?
-
Schau in den MSTE Schaltplan. Die beiden Signale sind von ACSI Port. Kannst du durchmessen ...
-
Jetzt frag ich mich nur noch wo ist DRQ und ACK?
Meine Version sieht anders aus. Wo häng ich die Kondensatoren am Besten dran?
Hab jetzt nicht alles durchgelesen aber evtl. sind es diese?
(https://www.exxoshost.co.uk/atari/last/gigafile/mod1.png)
Quelle: https://www.exxoshost.co.uk/atari/last/gigafile/index.htm
-
Kanns Du übrigens hier:
http://www.atariworld.org/download.php?id=126
auf seite 109 nachschauen.
-
Danke Arthur, wie immer den passenden Link parat.
ACK ist klar, ist Leitung 14 nur bei DRQ bin ich mir nicht ganz sicher. Ist das der Anschluß 19 DR Daten Anforderung?
-
11 = GND und dann 14 und 19
-
http://www.stcarchiv.de/stc1988/03/die-festplatte-teil-3 (http://www.stcarchiv.de/stc1988/03/die-festplatte-teil-3)
Da ist die Zuordnung eindeutig dargestellt.
-
Heißt das jetzt, daß man grundsätzlich den ACSI-Adapter der GigaFile modden sollte wie im Bild zu #20 ? Läuft die GigaFile dann an allen ACSI-Anschlüssen (ST, STe, MSTE, TT) zugleich? Oder doch lieber von Fall zu Fall die Ko.en In´s innere der Geräte packen (wie von exxos als Alternative gezeigt) ? Und dann wäre vielleicht auch die UltraSatan stabiler? Oder habe ich das Problem ganz falsch verstanden?
-
Es wird nicht schaden doch wenns auch ohne läuft kann man sich das auch sparen.
-
Heißt das jetzt, daß man grundsätzlich den ACSI-Adapter der GigaFile modden sollte wie im Bild zu #20 ? Läuft die GigaFile dann an allen ACSI-Anschlüssen (ST, STe, MSTE, TT) zugleich? Oder doch lieber von Fall zu Fall die Ko.en In´s innere der Geräte packen (wie von exxos als Alternative gezeigt) ? Und dann wäre vielleicht auch die UltraSatan stabiler? Oder habe ich das Problem ganz falsch verstanden?
1) Nein, nur wenn die Symptome wie am Anfang des Threads erklärt vorkommen
2) Ist anzunehmen, Exxos hatte es extern verbessert bei mir wäre es intern, bin jedoch noch nicht
soweit um das zu gestätigen.
3) Die UltraSatan hat gleiche Probleme laut Ama.
czietz schrieb, daß auch ein Tausch der SD Karte helfen kann.
Wenn bei Dir alles stabil läuft ist der Mod unnötig
Exxos hat hier noch einen weiteren Artikel zu DMA Problemen verfasst
http://www.exxoshost.co.uk/atari/last/DMAfix/ (http://www.exxoshost.co.uk/atari/last/DMAfix/)
Hier setzt er die Kondensatoren direkt auf den DMA Chip für STE/STFM. Interessant ist was er dabei für einen Wert als optimal herausgefunden hat. -> 330pF
The capacitors are soldered directly on top of the DMA chip exactly as show and assumed the mod can be done on any Atari machine using the DMA chip. During my tests I found values of 330pF to 390pF are the optimum values, though these were only tested on my STFM and STE machines. The mod has not been tried on any other machines so the values may be different. It is also worth noting that on the STFM machine, values below 220pF or higher than 470pF do not work at all! A value of 330pF is suggested for STE and STFM machines
Hier noch eine Möglichkeit die Resetzeit zu vergrößern falls man eine SH205 hat. Das Verhalten
ist ähnlich.
DMA FAIL AFTER "RESET" COMPUTER
Using some hard drives of the old model (SH205 / megafile 20) there may be a non-functioning HDD after "Reset" from the computer. The only way to solve this failure is to cut and restore the system full on. This failure is caused by the fact that in the following on 25uS RESET signal another signal appears on the bus. Some hard drives are very sensitive. The problem depends greatly from the combination of hardware.
The solution to the problem is to alter the response time 10 uS to +/- 100 uS, the U20 circuit (74LS13 one shot) This extension of time may be realized how next : Replace R53 75 K Ohm 240K Ohm 1/4 W +/- 5% ca ~ bone. Replace C35 to 330 pF by 1.0uF> 25 VDC +/- 20% ceramics. See diagram attached
-
Endlich auch die interne Pinbelegung gefunden :D
http://wiki.newtosworld.de/index.php?title=Vantage_Micro (http://wiki.newtosworld.de/index.php?title=Vantage_Micro)
Jetzt kann es weitergehen.
-
Die 330pF sind eingelötet.
Beim ersten Einschalten kam die SD wieder nicht. Hochfahren nach Reset ging dann einwandfrei.
Test gemacht indem mehrmals kurz Reset Schalter gedrückt wurde nach dem Booten.
Mein Eindruck ist das es jetzt etwas besser geworden ist aber noch nicht optimal.
Die Häufigkeit von 4 Bomben hat auch stark nachgelassen.
Mache jetzt noch einige Tests mit Drücken der Resettaste Mal während ein Programm
ausgeführt wird oder im Bootvorgang sowie einfach mal zufällig lang oder kurz drücken.
-
Endlich auch die interne Pinbelegung gefunden :D
http://wiki.newtosworld.de/index.php?title=Vantage_Micro (http://wiki.newtosworld.de/index.php?title=Vantage_Micro)
Jetzt kann es weitergehen.
Naja, im Handbuch der Gigafile hätte die Pinbelegung der Stiftleiste im MegaSTE auch gestanden. Ein Fall von RTFM? ;-)
-
Tja hinterher war ich auch schlauer. :D
-
Versuche es doch mal mit verschiedenen SD Karten wie von czietz vorgeschlagen ...
Ppera hatte ja auch berichtet über Probleme mit diversen CF Karten. Ich habe auch eine die am Atari nicht will, am Mac und PC aber geht.
-
Naja, sie will ja. Denn sofern das Booten klappt läuft alles problemlos und garnicht booten
macht sie auch nicht, nur manchmal.
Dann müsste ich auch wieder eine SD neu aufsetzen. Ist ja nicht vom PC lesbar.
Wie ich davon eine Kopie mache wäre ein extra Thread.
Eventuell hilft dabei diese Seite. Mehrere Partitionen auf SD Karte mit XP
http://www.8bitchip.info/atari/multpremxp.html (http://www.8bitchip.info/atari/multpremxp.html)
Natürlich kann ich erstmal eine SD nur so vorbereiten daß der Boot geht um einen Vergleich zu haben.
Jetzt läuft es schon wesentlich besser. Hab nachdem ich das Foto gemacht hatte sofort
einen einwandfreien Boot gehabt. Muß noch etwas weiter testen.
Jetzt mal eine TOS 1.04 Diskette zum Boot eingelegt. War immer etwas schwierig vorher dass der Boot klappte. Jetzt scheint es so als wär das auch behoben. Stecke Diskette rein, Diskette wird sofort gelesen
und Bootx wird aufgerufen und dann bin ich auf dem Rainbow Desktop. Da hat sich irgendwas getan :D
4 Bomben nach Umschalten von Farbe auf S/W Modus. Reset gedrückt und einwandfreier Boot.
-
Versuche es doch mal mit verschiedenen SD Karten wie von czietz vorgeschlagen ...
Ppera hatte ja auch berichtet über Probleme mit diversen CF Karten. Ich habe auch eine die am Atari nicht will, am Mac und PC aber geht.
Naja, sie will ja. Denn sofern das Booten klappt läuft alles problemlos und garnicht booten
macht sie auch nicht, nur manchmal.
Dann müsste ich auch wieder eine SD neu aufsetzen. Ist ja nicht vom PC lesbar.
Wie ich davon eine Kopie mache wäre ein extra Thread.
Die SD-Karte benötigt ja zum Test nur eine Partition und einen installierten HDD-Treiber.
-
Natürlich kann ich erstmal eine SD nur so vorbereiten daß der Boot geht um einen Vergleich zu haben.
Sorry, hatte ich überlesen.
-
Wenn bei Dir alles stabil läuft ist der Mod unnötig
Ich habe gewisse - nee, eher ungewisse - Probleme mit meinem STE (den ich aber nur selten einschalte; HD ist dann LINK97+YAMAHA_V769970+CF). Deshalb interessiert mich das Thema.
--------
Den ersten Artikel von exxos zur DMA-Problematik
https://www.exxoshost.co.uk/atari/last/gigafile/index.htm
kannte ich schon (aber total verdrängt), der zweite
http://www.exxoshost.co.uk/atari/last/DMAfix/
war mir neu - Thanx for Linx!
Bei der neuen/erneuten Lektüre ist mir zweierlei aufgefallen.
1) exxos beschreibt Kopierfehler, die von den zu kopierenden Daten abhängig sind.
2) Das Thema DMA scheint auch einen Software-Aspekt zu haben (bzgl. Treiber).
Zu 2) werde ich gelegentlich ´nen neuen Thread öffnen (aber erst in 2 Wochen).
Zu 1) hätte ich da mal ´ne Frage:
Wie muß man das ansehen? Ist das eine Art Interferenz mit dem Noise oder gar eine Sorte Aliasing? Wird etwa durch die Daten eine Art Resonanz in einem der Chips getriggert, sodaß übler Noise auf dem DMA-Bus entsteht?
-
Ich mache hier mal einen Zwischenstand.
Zu ca. 80% klappt es mit der bisherigen SD Cart. Im Vergleich zu Vorher hat sich durch den Einbau eine merkliche Verbesserung ergeben.
100% sind meiner Ansicht nicht drin. Möglicherweise sind auch Störeinflüsse meines
Hausnetzes eine Ursache. Ob eine andere SD mehr bringt ist noch zu prüfen.
Am Netzteil selbst liegt es nicht. Wurde überarbeitet. Auch ein HC 68000 brachte nichts
-
Hat jetzt vermutlich nicht direkt mit dem Problem zu tun, aber du kannst auch mal mit dem "correct,prg" (Kobold) die SD Karte untersuchen. Bei mir waren, nach den Anfangsproblemen einige verlorene Cluster zu reparieren.
-
Das einzige was mir noch einfällt wäre evtl. das Resetsignal... aber bitte vorher erstmal eine andere SD-Karte verwenden. ;)
-
... auch mal mit dem "correct,prg" (Kobold) die SD Karte untersuchen. Bei mir waren, nach den Anfangsproblemen einige verlorene Cluster zu reparieren.
sic!
-
So, eine andere SD ist jetzt drin. Leider bombt die auch ab und zu allerdings auch eher selten. >:(
Kein Unterschied zur anderen festzustellen. Habe dazu immer wieder mal auf den Resetknopf
gedrückt (1-2 Sekunden). Wann es bombt ist nicht genau festzustellen.
Mit Kobold habe ich die noch nicht untersucht, vermute jedoch das wird keine neuen Erkenntnisse
bringen. Mit HDDRUTIL wurden ca. 2/3 der Karte ohne Fehler dargestellt.
Es scheint sich herauszukristallisieren, dass bei längerem Drücken (4 Sekunden) von
Reset nichts passiert. Da ist kein Bomben zu erzwingen. Also mag er wohl die kurzen Impulse nicht.
Scheint wie Arthur schon vermutet hat am Resetsignal zu liegen. Nur frage ich mich
wie man das bei Kaltstart in den Griff bekommen will.
Mit correct 1.3 hab ich einen Fehler einer Datei casetowr.prg im Autoordner gefunden. Dieser
ist jetzt behoben.