Mega STE stürzt ab beim Einschalten des Cache

[Skywalker]

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?

[Grendell]

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...

[Lynxman]

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.

[Grendell]

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.

[Lukas Frank]

Meiner bleibt hängen wenn ich nichts ausser XControl boote und den Cache zuschalte. Auf 16Mhz läuft alles ...

[czietz]

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. 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.  )

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.

[Lukas Frank]

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.

[czietz]

Schade, dann läuft das Programm also nicht.  Kann ich leider nichts machen. Ich entferne es dann wieder aus dem Posting.

[ari.tao]

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?   
Noch mehr würde mich interessieren, wie man ein Stück Code, natürlich passender Größe, _garantiert_in_den_Cache_ kriegt? 

[mfro]

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?   

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.

[czietz]

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.   

[goetz @ 3rz]

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 …

[mfro]

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

[1ST1]

Dann hilft wohl nur ein ROM-Port-Modul mit der Testroutine.

[Lukas Frank]

Das testet aber den Cache nicht richtig !

[Lukas Frank]

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.

[Atariosimus]

ich find im Diagnosemodul nichts mit Hidden

[Atariosimus]

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

[Atariosimus]

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.

[Lukas Frank]

Na dann ist dein Rechner halt in Ordnung im Gegensatz zu meinem ...