atari-home.de - Foren
Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet von: Grendell am Sa 20.05.2017, 17:14:46
-
Hallo Zusammen,
ich habe gerade meinen Mega STE ausprobiert und festgestellt, dass dieser beim Einschalten des Cache einfriert. Das Umschalten von 8 auf 16 MHz funktioniert noch einwandfrei.
Ich habe schon die CPU, den RAM und das TOS ROM getauscht, was alles nichts genützt hat. Auch das Netzteil habe ich mal testhalber von einem anderen MEGA STE genommen.
Das Gerät hat 4MB RAM und TOS 2.05.
Hat jemand eine Idee, woran das liegen kann?
Viele Grüße,
Grendell
-
Hat jemand eine Idee, woran das liegen kann?
An den Cache Chips?
Können die Alt werden?
(hab auch einen MSTE, wird max 1x im Jahr angeschmissen,
daher meine Sorge...)
-
An den Cache Chips?
Können die Alt werden?
(hab auch einen MSTE, wird max 1x im Jahr angeschmissen,
daher meine Sorge...)
Naja, alle Bauteile altern und können irgendwann sterben -- auch ICs. Besonders gefährdet sind aber sicherlich ICs, die heiß werden oder die Floating Gates enthalten (EPROMs, Flash-ROMs, GALs). Die Cache-RAMs gehören in keine der beiden Kategorien.
Dennoch liegt natürlich der Verdacht nahe, wenn der Rechner beim Aktivieren des Caches abstürzt, dass etwas mit dem Cache nicht in Ordnung ist. Sind die Cache-ICs im MegaSTE eigentlich -- wie es bei vielen PC-Mainboards der Fall war -- gesockelt? Dann wären vielleicht nur der Kontakte oxidiert. Sonst: Irgendein GAL/PAL ist für die Cache-Steuerung zuständig. Ist das gesockelt?
-
Bei meinem Mega STE fast genau das gleiche Problem. Auf 16Mhz läuft er aber wenn ich den Cache über das CPX zuschalte läuft es kurz und beim Beenden eines Programmes hängt sich der Rechner auf ohne Bomben oder so. Habe auch keine Ahnung was das sein könnte. Sind ja vier 8-bit breite Cache Rams mit Tag Rams verbaut. Vielleicht liegt es ja auch an der Steuerung durch die PALs ?
-
Vielen Dank für die Antworten!
Leider bin ich in Elektronik nicht so bewandert, aber habe trotzdem mal einen Blick in den Schaltplan geworfen. Neben der CPU befinden sich u.A. zwei Bausteine, die mit "SRAM" bezeichnet sind (8kx8SRAM, U004 U005) und zwei weitere, die mit "CTRAM" bezeichnet sind (8kx8CTRAM, U008 U009). Die SRAM-Bausteine sind auf diesem Board gesockelt und dir CTRAM-Bausteine sind fest verlötet.
Bilden die SRAM-Bausteine den Cache? Dann könnte ich die mal raus-fummeln und wieder rein stecken. Beim Arbeitsspeicher hat das auch schon geholfen.
-
Ja, die SRAMs stellen den eigentlichen Datencache dar und die CTRAM (Cache Tag RAM) speichern, welche Hauptspeicheradresse gerade im Cache liegt. Einmal raus und wieder rein der SRAMs kann sicherlich nicht schaden -- natürlich vorsichtig, damit kein Pin verbiegt.
-
Ja, die SRAMs stellen den eigentlichen Datencache dar und die CTRAM (Cache Tag RAM) speichern, welche Hauptspeicheradresse gerade im Cache liegt. Einmal raus und wieder rein der SRAMs kann sicherlich nicht schaden -- natürlich vorsichtig, damit kein Pin verbiegt.
Vielen Dank für die Info! Das werde ich mal ausprobieren.
-
Ich habe gerade alle gesockelten ICs im Umfeld der CPU gezogen und wieder gesteckt. Leider ohne Erfolg. Ich fürchte mal, dass ich wie Lukas bei diesem MSTE ohne Cache auskommen muss.
Übrigens: wenn der Cache beim Booten aktiviert wird, zeigen sich unterschiedliche Reaktionen. Es gibt Bomben auf dem weißen Bootscreen, eine gefrorene Biene oder manchmal schafft der Rechner sogar den Desktop aufzubauen.
-
Miss mal die Spannungen vom Netzteil, insbesondere mal die 5V unter Last.
-
Die Bussteuer PAL/GAL Bausteine gibt es glaube ich nur pro Stück für 20 Dollar bei BEST in neu zum Probieren. Wenn es die Tag Rams noch irgendwo gibt tausche ich die mal gegen neue aus ...
-
Kann mir jemand bei der Eingrenzung des Problems helfen? Mir ist noch nicht so ganz klar, was zum Cache gehört und was nicht. In allen Beschreibungen des Mega STe, die ich bisher gefunden habe, ist von 16KB Cache die Rede. Im Schaltungs-Schema von Atari finde ich jedoch insgesamt 2 x 16KB (einmal "SRAM" und einmal "CTRAM"). Wenn ich das richtig verstanden habe, puffert der SRAM die Schreib-/Lesezugriffe auf den normalen RAM des MSTe und der CTRAM die Zugriffe auf die Festplatte.
Werden beim Zuschalten des Cache über die entsprechenden Einstellungen beide Zwischenspeicher aktiviert oder ist der CTRAM immer aktiv? Welche Bausteine gehören zu welchem System?
Ich habe noch festgestellt, dass der Zeitpunkt des Absturzes nach dem Aktivieren des Cache von der Laufzeit des MSTe abhängig ist. Bei einem Neustart heute morgen konnte ich auf dem Desktop sogar kurz den Mauszeiger bewegen. Das ging nach einem darauf folgenden Neustart nicht mehr. Je öfter ich neu gestartet habe, desto weniger konnte ich nach dem Aktivieren auf dem Bildschirm sehen. In meiner Logik heißt das, dass wirklich ein Bauteil defekt ist (thermischer Effekt). Was meint Ihr?
-
Im Schaltungs-Schema von Atari finde ich jedoch insgesamt 2 x 16KB (einmal "SRAM" und einmal "CTRAM"). Wenn ich das richtig verstanden habe, puffert der SRAM die Schreib-/Lesezugriffe auf den normalen RAM des MSTe und der CTRAM die Zugriffe auf die Festplatte.
Nein. Ich schrieb es doch schon: "Ja, die SRAMs stellen den eigentlichen Datencache dar und die CTRAM (Cache Tag RAM) speichern, welche Hauptspeicheradresse gerade im Cache liegt." Die Festplatte ist da nirgendwo beteiligt!
EDIT: Das bedeutet natürlich auch, dass sowohl Cache-RAM ("SRAM" im Schaltplan) als auch Tag-RAM ("CTRAM") nur aktiv sind, wenn Du den Cache per Software einschaltest.
Den Rest der Fragen überlasse ich jemandem, der einen MegaSTE hat. Ein Diagnosemodul wäre jetzt übrigens sicherlich hilfreich. Dessen Version für den MegaSTE kann den Cache ein- und ausschalten und dann den Rechner testen.
-
Ich meine im Diagnose Modul ist nichts von wegen Cache drin.
In der Chips&Chips steht nichts drin ausser ...
MegaSTE mit dem PLCC-DMA (Absturz beim Umschalten von 8 MHz auf
16 MHz)
Unterbrechen Sie die Verbindung von U012 (PAL16L8) Pin 13 zum
Board. Löten Sie eine 220mm lange Drahtbrücke von U012 Pin 13 zu
U905 Pin5. Löten Sie außerdem eine 160mm lange Drahtbrücke von
U06 Pin 11 (PAL22V10) zu U905 Pin 15. Damit haben Sie einen Trei-
ber in die CS8-Leitung eingeschleift und das Problem sollte be-
hoben sein. (Siehe auch Bild UNTEN.IMG im Ordner ZUSATZ/PLATINEN/
MEGAST)
-
Ich meine im Diagnose Modul ist nichts von wegen Cache drin.
Doch -- laut Service Manual schon, siehe den Abschnitt "Hidden Key Sequences".
-
Nein. Ich schrieb es doch schon: "Ja, die SRAMs stellen den eigentlichen Datencache dar und die CTRAM (Cache Tag RAM) speichern, welche Hauptspeicheradresse gerade im Cache liegt." Die Festplatte ist da nirgendwo beteiligt!
EDIT: Das bedeutet natürlich auch, dass sowohl Cache-RAM ("SRAM" im Schaltplan) als auch Tag-RAM ("CTRAM") nur aktiv sind, wenn Du den Cache per Software einschaltest.
Ah jetzt... hab's auch ich verstanden. ;-)
Den Rest der Fragen überlasse ich jemandem, der einen MegaSTE hat. Ein Diagnosemodul wäre jetzt übrigens sicherlich hilfreich. Dessen Version für den MegaSTE kann den Cache ein- und ausschalten und dann den Rechner testen.
Jau so etwas wäre gut. Hat jemand so'n Teil?
-
Ich habe so ein Modul und gerade mal probiert aber meine das ist sinnlos und bringt nichts ...
HIDDEN KEY SEQUENCES:
<Shift> 1 System Clock 8 MJ-Iz cache off
<Shift> 2 System Clock 16 MJ-Iz cache off
<Shift> 3 System Clock 16 MHz cache on
<Shift> 5 8 :MHz floppy clock set
<Shift> 6 16 MHz floppy clock set (1.44 Meg Drive)
<Shift> 7 Software Date
... das bringt nichts, der Cache wird nur an geschaltet was auch funktioniert aber er wird nicht getestet.
RAM ERROR CODES
Except where noted, repair by replacing the SIMM corresponding to the indicated
bit(s).
RO
Rl
R2
R3
R4
Cache RAM
Error in low memory, possibly affecting program execution.
Error in SIMM.
Address error. Bad SIMM or memory controller. Address line
not working.
Address error at 64k boundary.
Error during video RAM test. Bad SIMM.
Error during cache RAM test. Bad cache RAM chip.
Beim Ramtest wird ja scheinbar der Cache mit getestet. Bei meinem Mega STE bleibt das hängen beim Cache einschalten trotzdem bestehen ...
-
... das bringt nichts, der Cache wird nur an geschaltet was auch funktioniert aber er wird nicht getestet.
Seufz. Du kannst den Cache ja auch schlecht einzeln testen. Aber wenn er aktiviert ist, nutzen alle Teile des Testmoduls, die auf den RAM zugreifen, natürlich den Cache. Wenn also irgendein Test funktioniert mit "Cache aus" aber nicht mit "Cache ein", dann ist das ein Test des Caches. Nichts anderes schrieb ich: "den Cache ein- und ausschalten und dann den Rechner testen."
Beim Ramtest wird ja scheinbar der Cache mit getestet. Bei meinem Mega STE bleibt das hängen beim Cache einschalten trotzdem bestehen ...
Ich nehme an -- auch wenn Du es nicht schreibst --, dass der RAM-Test auch mit "Cache ein" ohne Fehler durchläuft?
-
Bei mir führt das Einschalten des Caches zum einem umgehenden Freeze. Keine Chance, dann noch was zu testen. Es müsste also einen Test mit ausgeschalteten Cache-Funktion geben. K. A. ob sowas überhaupt möglich ist.
-
Ich habe "Shift-3 /16Mhz Cache ein" gemacht und dann den Ramtest laufen lassen. Alles in Ordnung aber der Rechner hängt ohne Testmodul im Desktop wenn ich den Cache per CPX einschalte.
-
Bei mir führt das Einschalten des Caches zum einem umgehenden Freeze. Keine Chance, dann noch was zu testen.
Auch mit dem Diagnose-Modul? Ich dachte, Du hättest keins? Es geht mir doch die ganze Zeit darum: Mit dem Diagnose-Modul booten, mit dem Diagnose-Modul den Cache einschalten, mit dem Diagnose-Modul den Rechner testen. Wobei Franks MegaSTE zeigt, dass z.B. der RAM-Test des Moduls mit eingeschaltetem Cache offensichtlich nicht alle Fehler findet.
-
Ich habe schon die CPU, den RAM und das TOS ROM getauscht, was alles nichts genützt hat. Auch das Netzteil habe ich mal testhalber von einem anderen MEGA STE genommen.
Was für Software hast du noch so laufen?
Hast du schon mal mit einem "leeren" System getestet?
Also nur das Kontrollfeld? Oder eines der zahlreichen Programme, die den 16 MHz Modus direkt aktivieren?
-
Was für Software hast du noch so laufen?
Hast du schon mal mit einem "leeren" System getestet?
Also nur das Kontrollfeld? Oder eines der zahlreichen Programme, die den 16 MHz Modus direkt aktivieren?
Mit einem "leeren" System läuft der Rechner ganz gut. Ich benutze einen CosmosEx und kann mit verschiedenen SDCards starten oder ohne. Im letzteren Fall startet der Rechner ohne das Kontrollfeld. Dabei bleibt er auf 8MHz ohne Cache. Beim Starten mit CosmosEx wird einzig der Treiber mit geladen, was auch einwandfrei funktioniert.
Wenn man nun, zB über SYSINFO.PRG auf 16MHz hochschaltet läuft der Rechner auch noch weiter. Erst beim Aktivieren des Cache friert der Rechner ein.
Ich denke mal, bevor ich mir jetzt jede Menge neue Teile einbaue, die in Summe mehr kosten, als ich für den kompletten Rechner bezahlt habe und mit ungewissem Ausgang, lasse ich den MSTe jetzt so. Dann eben kein Cache bei diesem Rechner...
-
Mit einem "leeren" System läuft der Rechner ganz gut.
Nun ja, der Cache ist ja abschaltbar weil es Software gibt die damit Probleme hat.
Vielleicht ist es so was.
Versuch mal einzukreisen mit welcher Software/Treiber der Rechner läuft und mit welchen er einfriert/abstürzt/etc.
Vielleicht kann man das verhalten mit einem anderen MEGA STE nachvollziehen.
-
Nun ja, der Cache ist ja abschaltbar weil es Software gibt die damit Probleme hat.
Vielleicht ist es so was.
Versuch mal einzukreisen mit welcher Software/Treiber der Rechner läuft und mit welchen er einfriert/abstürzt/etc.
Vielleicht kann man das verhalten mit einem anderen MEGA STE nachvollziehen.
Danke für Deinen Hinweis!
Die verwendete Installation auf der SDCard (im CosmosEx) stammt von einem anderen MSTe, der damit einwandfrei läuft. Ein "nackter" Start ohne das Kontrollfeld und andere Sachen (nur CE_DRV wird geladen) verläuft einwandfrei. Danach SYSINFO.PRG gestartet und unter Systeminformationen 16MHz und Cache ausgewählt und bei Cache friert der Rechner ein. Auch das läuft auf allen anderen MSTe, die ich je gesehen habe, einschließlich aller Clones und Emulatoren.
-
Meiner bleibt hängen wenn ich nichts ausser XControl boote und den Cache zuschalte. Auf 16Mhz läuft alles ...
-
EDIT: Programm läuft laut @Lukas Frank nicht, wieder entfernt.
Ich habe ja mal eben ein kleines Testprogramm für den Cache geschrieben. Mangels MegaSTE kann ich's natürlich nicht testen und weiß nicht, ob's überhaupt etwas taugt. Unter Hatari stürzt es jedenfalls nicht ab. Es testet Schreib- und Leseoperationen, wobei es den Cache selbst ein- und wieder ausschaltet.
Programm angehängt -- umbenennen in CACHMSTE.TOS. Ohne Garantie, weil ungetestet; vielleicht mag's ja doch jemand ausprobieren, ob er ein "FAIL" angezeigt bekommt.
Vielleicht gibt es ja auch weitere Testsoftware für den MegaSTE-Cache, die nicht mal eben als Fingerübung heruntergetippt wurde.
-
Mir mir kommt ...
Cache read fff:
und zwei Bomben
... beim starten von Diskette. Beim booten vom Rechner über eine Nova Grafikkarte kommt nur die Meldung "Cache read fff:" und das Programm beendet sich sofort ohne Bomben.
-
Schade, dann läuft das Programm also nicht. :( Kann ich leider nichts machen. Ich entferne es dann wieder aus dem Posting.
-
Der Programmcode für den Test läuft aus ungecachtem RAM, sodass der Rechner selbst dann nicht abstürzen sollte, wenn der Cache kaputt ist. (An die Profis: Ratet mal, wie ich das hinbekommen habe. ;) )
Ja, interessant. Ich vermute mal, daß Du eine Schleife geschrieben hast, die zu groß ist, als daß sie komplett in den Cache paßt? ;D
Noch mehr würde mich interessieren, wie man ein Stück Code, natürlich passender Größe, _garantiert_in_den_Cache_ kriegt? 8)
-
Der Programmcode für den Test läuft aus ungecachtem RAM, sodass der Rechner selbst dann nicht abstürzen sollte, wenn der Cache kaputt ist. (An die Profis: Ratet mal, wie ich das hinbekommen habe. ;) )
Ja, interessant. Ich vermute mal, daß Du eine Schleife geschrieben hast, die zu groß ist, als daß sie komplett in den Cache paßt? ;D
Falsch geraten, denke ich ;).
Das Zeug muß dann trotzdem durch den Cache durch, der bringt bloß keinen Geschwindigkeitsgewinn.
Wenn ich so was machen wollte, würde ich mir einen Speicherbereich suchen, der nicht gecached ist und das Programm da reinstopfen. Ich habe keinen STE, würde aber annehmen, daß sich der Bildschirmspeicher diesbezüglich anbietet.
-
Ich habe keinen STE, würde aber annehmen, daß sich der Bildschirmspeicher diesbezüglich anbietet.
Ich habe ja auch keinen MegaSTE, aber der Bildschirmspeicher ist regulärer RAM und als solcher gecachet. Definitiv nicht gecachet ist der IO-Bereich, dort gibt es allerdings nicht viel, was sich als RAM anbieten würde. Ich wollte die 16 Worte Halftone-RAM des Shifters verwenden, um dort meine Testroutine hineinzupacken. Allerdings mag es sein, dass im echten MegaSTE (im Gegensatz zur Emulation in Hatari) die Hardware verhindert, dass man Code aus dem Halftone-RAM ausführt. >:(
-
Ich habe ja auch keinen MegaSTE, aber der Bildschirmspeicher ist regulärer RAM und als solcher gecachet. Definitiv nicht gecachet ist der IO-Bereich, dort gibt es allerdings nicht viel, was sich als RAM anbieten würde. Ich wollte die 16 Worte Halftone-RAM des Shifters verwenden, um dort meine Testroutine hineinzupacken. Allerdings mag es sein, dass im echten MegaSTE (im Gegensatz zur Emulation in Hatari) die Hardware verhindert, dass man Code aus dem Halftone-RAM ausführt. >:(
Tja, da sieht man wieder, wie weit Atari der Zeit voraus war - NX-Bit / DEP schon 1990!
SCNR …
-
Ich habe ja auch keinen MegaSTE, aber der Bildschirmspeicher ist regulärer RAM und als solcher gecachet.
Hmm, ich hätte ganz naiv angenommen, es gäbe - abhängig von der Bildschirm-Basisadresse - irgendeinen schlauen Mechanismus im Mega-STE, der verhindert, daß nach einem Blitter-Zugriff der Cache-Inhalt ungültig gemacht werden muß.
War wohl ein wenig zu naiv ;)
Ich wollte die 16 Worte Halftone-RAM...
Haha, die Blitteromanie zieht Kreise ;)
-
Dann hilft wohl nur ein ROM-Port-Modul mit der Testroutine.
-
Das testet aber den Cache nicht richtig !
-
Ich habe mir jetzt mal die beiden SRAMs und die CTRAMs neu bestellt um mein Problem zu lösen ...
SRAM HM6265L-70ns bekommt man nicht, laut Datenblatt sollte ein 6264-70ns auch gehen. Hätte gerne gewußt wo der Unterschied liegt.
-
ich find im Diagnosemodul nichts mit Hidden
-
So ich hab jetzt auch mal den Takt auf 16Mhz mit dem CPX Tool General angestellt. Jegliches hin und herschalten verlief einwandfrei.
Bei XBootlll werden folgende Programme geladen:
E_Temp
Maccel40
NVDI
Selectric
Sumtime
Xboot
Bei den CPX
sind es
Asciitab
Boot
calc
clock
code
color
cookies
dips
general
kalender
und noch einige mehr
Bei den ACC
Callslct
St-Guide
Xcontrol vers 1.31
-
Wenn man nun, zB über SYSINFO.PRG auf 16MHz hochschaltet läuft der Rechner auch noch weiter. Erst beim Aktivieren des Cache friert der Rechner ein...
Könntest Du das Sysinfo.prg bitte mal hier dranhängen?
Habs gefunden. V5.02. Läuft bei mir trotzdem alles ohne Absturz. Kann den Fehler immer noch nicht nachvollziehen.
-
Na dann ist dein Rechner halt in Ordnung im Gegensatz zu meinem ...
-
ich find im Diagnosemodul nichts mit Hidden
Das könnte daran liegen, dass die Tastensequenzen nun eben einmal hidden (=versteckt) sind. Das Modul zeigt Dir diese Optionen folglich nicht an; trotzdem kannst Du die Tasten in meinem Posting drücken.
So ich hab jetzt auch mal den Takt auf 16Mhz mit dem CPX Tool General angestellt. Jegliches hin und herschalten verlief einwandfrei.
Es wäre auch verwunderlich, wenn Dein MegaSTE denselben Defekt hätte wie Franks.
Gibt es einen speziellen Grund, dass Du in Deinem MegaSTE nach Abstürzen im Zusammenhang mit dem Cache suchst?
-
@czietz ... eine Idee was der Unterschied zwischen 65 und 64 sein könnte? Ein Datenblatt vom 6265 finde ich nicht ...
Ich habe mir jetzt mal die beiden SRAMs und die CTRAMs neu bestellt um mein Problem zu lösen ...
SRAM HM6265L-70ns bekommt man nicht, laut Datenblatt sollte ein 6264-70ns auch gehen. Hätte gerne gewußt wo der Unterschied liegt.
-
HM6265 sagt mir nix. War das bisher in Deinem MSTE drin? In meinem ist IMS1630 verbaut, imho sollte jedes ausreichend schnelle SRAM mit 8kx8 Bits funktionieren.
-
Ok, Google verrät, dass 6265 ein 8k x 9 SRAM ist, also mit Parity-Bit. Das hat eine ganz andere Pinbelegung! Wenn in Deinem MegaSTE tatsächlich 6265 verbaut ist, kann der Cache nie funktioniert haben! 6264 ist hier jedenfalls die richtige Wahl.
-
Ja habe HM6265 verbaut. In der Chips&Chips steht auch ...
C302017-001 = Sram 8K*8 85ns (HM6265L-70) (U4 + U5)
Das Datenblatt eines 6264 stimmt mit dem Schaltplan überein was die Pinbelegung angeht.
-
Interessant. Vielleicht war der Google-Treffer falsch, der hier ein 8kx9-SRAM behauptete.
EDIT: In der Tat interessant. "HM" steht für Hitachi, aber laut deren Datenbuch haben sie nie ein 6265 gebaut. Noch dazu tragen die HM6265 in einem MegaSTE kein Hitachi-Logo: https://www.exxoshost.co.uk/forum/viewtopic.php?f=41&t=529. Sie haben gar kein Herstellerlogo. (Hitachi-RAM HM6264 zum Vergleich: http://www.w3b8dxt36.homepage.t-online.de/shop/images/HM%206264%20LP%20-%2015.jpg.)
Theorie: Atari hat irgendein Noname-RAM mit "erfundener" Produktbezeichnung verbaut.
-
@czietz: nein ich hatte bisher keine Probleme. Mein Zweck war nur zu helfen oder mal zu schauen, ob es bei meinem nicht auch so was gibt. Letztlich als Referenz zur Fehlerfindung.
Ich habe allerdings auch keine umfangreichen Hardwareeinbauten ausser der Gigafile. Vielleicht liegt es auch daran.
-
Mein Rechner ist jetzt wieder völlig in Ordnung. Ich hatte ST MK48S74-35 CTRAM in Keramik und Gold verbaut. Habe die beiden mal durch neue ST MK48S74N-35 ersetzt. Die alten waren wohl defekt was sich so darstellte das 16Mhz funktionierte aber sobald man den Cache dazu geschaltet hat hängte sich der Rechner nicht sofort aber nach einigen Augenblicken auf ...
-
Ich habe so ein Modul und gerade mal probiert aber meine das ist sinnlos und bringt nichts ...
HIDDEN KEY SEQUENCES:
<Shift> 1 System Clock 8 MJ-Iz cache off
<Shift> 2 System Clock 16 MJ-Iz cache off
<Shift> 3 System Clock 16 MHz cache on
<Shift> 5 8 :MHz floppy clock set
<Shift> 6 16 MHz floppy clock set (1.44 Meg Drive)
<Shift> 7 Software Date
... das bringt nichts, der Cache wird nur an geschaltet was auch funktioniert aber er wird nicht getestet.
RAM ERROR CODES
Except where noted, repair by replacing the SIMM corresponding to the indicated
bit(s).
RO
Rl
R2
R3
R4
Cache RAM
Error in low memory, possibly affecting program execution.
Error in SIMM.
Address error. Bad SIMM or memory controller. Address line
not working.
Address error at 64k boundary.
Error during video RAM test. Bad SIMM.
Error during cache RAM test. Bad cache RAM chip.
Beim Ramtest wird ja scheinbar der Cache mit getestet. Bei meinem Mega STE bleibt das hängen beim Cache einschalten trotzdem bestehen ...
Das hier hab ich so nicht. Drückt man zuvor R und dann die hidden Tasten oder davor??.
Bei meinem passiert da gar nichts.
-
Welche Version hast du denn?
-
Mein Rechner ist jetzt wieder völlig in Ordnung. Ich hatte ST MK48S74-35 CTRAM in Keramik und Gold verbaut. Habe die beiden mal durch neue ST MK48S74N-35 ersetzt. Die alten waren wohl defekt was sich so darstellte das 16Mhz funktionierte aber sobald man den Cache dazu geschaltet hat hängte sich der Rechner nicht sofort aber nach einigen Augenblicken auf ...
Gut zu wissen, wo bekommt man die günstig her?
-
Habe meine über Ebay ...
Mein Mega STE Test Modul ist die Version 1.5
Bei mir geht "Shift + 1" usw. drücken ...
-
Hab das mit dem Hidden versucht passier nichts.
Ist die gleiche Rev 1.5. Benutze das Modul von Goussoin.
Vielleicht liegt es am Eiffel Modul, das der Shift anders codiert???
-
Warte bis der Testbildschirm da ist und drücke dann mal die Taste links Shift und die Taste 1
-
Mein Rechner ist jetzt wieder völlig in Ordnung. Ich hatte ST MK48S74-35 CTRAM in Keramik und Gold verbaut. Habe die beiden mal durch neue ST MK48S74N-35 ersetzt. Die alten waren wohl defekt was sich so darstellte das 16Mhz funktionierte aber sobald man den Cache dazu geschaltet hat hängte sich der Rechner nicht sofort aber nach einigen Augenblicken auf ...
auch wenn schon etwas älter, klinke ich mich mal hier mit ein, da ich dieses seltsame Problem auch habe.
Mein MSTE mit 4MB (70nS SIMMs) hat eine Matrix C110ZV 2MB Grafikkarte im VME-Bus stecken, eine 40GB IBM SCSI HDD über Inventronic Adapter, TOS 2.06, HD FDD (über WD1772 02-02). Was dem noch fehlt ist nur etwas mehr RAM (woher aber nur beziehen, gibt nichts mehr auf dem Markt ...)
Hatte gefühlt ewig an der Matrix Grafik herumkonfiguriert und hatte bemerkt, dass immer wenn ich XBOOT im AUTO-Ordner mit aktiviere, 2 Bomben fallen. Das dann auch immer, wenn der Treiber der Matrix die CXX Auflösungsdatei aufruft - aber das auch nicht immer. Hatte zuerst XBOOT (3.20) im Verdacht. Dann habe ich mal den Cache und den Blitter in XBOOT deaktiviert, und siehe da, der MSTE startet durch.
Dann habe ich weiter bemerkt, dass wenn ich über die Systeminfo-CPX 16MHz und Cache einschalte, es Probleme beim Löschen und Kopieren von vielen Dateien gibt, der MSTE friert ein.
Erste Frage:
Auf dem MSTE habe ich MK48S74N-25 Cache RAMs mit 25nS drauf. Auf Ebay kann ich nur "MK48S74N-35 Cache Address Comparator" mit 35nS finden. Ich fürchte aber, dass diese zu langsam sind und ich mir neue Probleme damit einfange.
Kennt jemand kompatible Vergleichstypen für diese Cache RAMs und wo man die herbekommen kann?
Zweite Frage:
Der MSTE macht ja meines Wissens nach offiziell 8 oder 16MHz, je nach dem was eingestellt ist, oder?
Auf meinem MSTE ist aber eine Motorola 68000FN8 CPU verbaut. So weit ich weiß ist diese aber doch nur für 8MHz ausgelegt? Könnte das evtl. die Ursache für die Abstürze sein?
-
Ja, "8" ist eine 8-MHz-CPU. Aus Erfahrung mit der TwiSTEr kann ich sagen, dass sich manche 8-MHz-Modelle gut auf 16 MHz übertakten lassen und andere nicht.
Ob da ein Vorbesitzer die CPU getauscht hat? Atari hat in MegaSTEs typischerweise eine "12F"-CPU verbaut, die - anders als die Bezeichnung vielleicht suggeriert - für 16 MHz ausgelegt ist.
-
Ok, ein Problem ist dann schon mal identifiziert. Die 8MHz CPU ist mir auch jetzt nur vor kurzem beim Betrachten der Bilder aufgefallen. Wer weiß, was sich der Vorbesitzer dabei gedacht hat.
Ich habe vor ein paar Tagen in eBay eine MC68HC000FN20 für ~13€ gekauft.
Die hab ich meinen 1040STE mit dem bad DMA Problem eingebaut. Werde diese dort aber wieder rausholen und mal im MSTE probieren.
Im 1040STE bringt diese Pixelmüll beim Einschalten. Erst ein anschlißernder Reset startet den Rechner durch, der dann aber anschließend gut läuft, bis zum nächsten Aus- u. wieder Einschalten. Ich muss wohl irgendwie den Init-Vorgang der CPU verzögern, aber das ist eine ganz anderes Thema.
-
Naja bei eBay weißt Du nie, ob auch wirklich 20 MHz drin sind. Die CPUs dort sind so gut wie alle neu und ggf. falsch beschriftet.
-
Hoffentlich ist das bei meinem nicht der fall :-X
Ist aus Frankreich verschickt worden, aber die Beschriftung sieht nicht so aus wie die von der 8MHz CPU, eher gelblich. Hoffe kein Fake.
-
Ich habe eine 16Mhz TMP68HC000-16 Toshiba mal gekauft, kein Fake ...