Mega STE 10MB Wevelsieb reine ST Ram Erweiterung ...

[Lukas Frank]

https://forum.atari-home.de/index.php/topic,2938.msg13413.html#msg13413

Martin Wevelsiep schreibt da etwas zu der Erweiterung ...


Es muss ja damals sowas wie eine Einbau Anleitung dazu gegeben haben. Der Einbau bei mir war Fürchterlich. Anhand der Anleitung könnte ich den Einbau überprüfen und ausschliessen das da was an den GALs nicht in Ordnung ist ...

[R^2]

Habe nochmal im Forum hier gelesen und es kann gut sein das mein MegaSTE Mainboard mit der Wevelsiep ST Ram Erweiterung funktioniert aber es ein gepatches TOS 2.06 braucht ...!?!

Hallo Frank!

Wenn ich alles - auch aus der Vergangenheit - richtig gelesen habe, dann scheint die Wevelsieb'sche Lösung wie folgt zu funktionieren:

• Die MMU vom Atari wird überlistet!
• Auffällig - in allen Wevelsiep'schen Lösungen - ist, dass die oberen Adressleitungen zur MMU durchtrennt werden. Die MMU weiß somit nicht, in welchem Adressbereich (RAM- oder Andere-) Bereiche sich die MMU befindet.
• Die GAL-Logik (umfangreich) übernimmt - statt der MMU - die Adressselektion. Ist es ein RAM Bereich (alt (00000 bis 3FFFFF MB)) geht es durch auf das RAM. Ist es ein RAM Bereich (neu (40000 bis 7FFFFF) wird der MMU gesagt --> das ist 00000 bis 3FFFFF. Dem System wird mehr Speicher angeboten. Aber Achtung: Ohne explizite Ummeldung wird die Lösung von Martin Wevelsiep nie funktionieren. Weil - wie schon geschrieben - die MMU weiß nichts von dem Patch außen drum herum. Es muss einmal - in einem gepatchen TOS - die Speichergrenze hoch gesetzt werden.
• Greift nun ein Programm auf einen Speicher > 3FFFF zu, so wird durch die GAL-Logik der Speicherbereich umgesetzt. Es wird der "richtige" Speicher adressiert. Der MMU wird gesagt, es ist der Bereich von 00000 bis 3FFFF. Sie weiß immer noch nichts von der Erweiterung.
• RAM-Refresh mit RAS und CAS, werden über die GAL-Logik zeitgleich für 00000 bis 3FFFF als auch 40000 bis 7FFFF durchgeführt. Der Refreshzyklus ist somit für den gesamten Bereich gewährleistet. Wie gesagt: Die MMU bedient nun zwei parallele Bereiche, weiß aber nichts von ihrem emsigen Treiben auf zwei parallele Bereiche.
• Nun noch der Teil, den ich nicht genau vermuten kann: Der Speicher nach 8 MB ST-RAM. Also ab 80000 bis 9FFFF. Ich vermute, dass hier auf die Lösung in der MMU mit den "2,5 MB" zurückgegriffen wird. Das erklärt auch, warum - zeitweilig - Frank die Meldung 2,5 MB als Gesamtspeicher hatte. Das könnte auf einen Wackelkontakt in dem Aufbau vermuten lassen. Für die Adressierung, lässt es vermuten, dass die eine 2 MB Bank voll bestückt gemeldet wird und die anderen mit kleineren Speicher. Oder - bedingt durch die GAL-Logik - eine Fehlinterpretation des Bereich von 80000 bis 9FFFF. Die oberen 2 MB habe ich noch nicht genau "gepeilt", wie das geht. Hier bin ich noch mit dem "Latein" am Ende, wie man so schön sagt.
• Merke: Frank bekommt vom TOS zurück gemeldet: 4 MB, einwandfrei am Laufen! Verstehe ich mit dem obigen Details. Auch wenn das TOS noch so gut ist, die quasi "Spiegelung" merkt das TOS nicht. Es fehlt, die Anmeldung, dass mehr als 4 MB vorhanden sind. Es müsste also ein TOS her, was "hart" codiert, 10 MB gesetzt bekommt. Dann müssten auch wirklich 10 MB mit der Erweiterung vorhanden sein. Wie man das dann testet, ist eine andere Sache.

Final noch einmal mein Statement: Alles nur Spekulation aufgrund der vorliegenden Daten (Alt und Neu). Martin Wevelsiep, sofern er sich von extern als Gast einloggt, hat extremes "Alsheimer". Auch wenn ich mich mit dieser Aussage in die Nesseln setze! Glauben tue ich das nicht! Bei so einer Hardwareerweiterung kann man nicht "vergessen wie es geht"! Er will das Geheimnis nicht preis geben - so meine klare Vermutung.

So weit mein Beitrag.

Beste Grüße
Robert

[czietz]

Hinweis: Atari TOS (wie auch EmuTOS) suchen von sich aus bereits nach ST-RAM oberhalb von 4 MiB. Bei der vergleichbaren MME-Erweiterung https://forum.atari-home.de/index.php/topic,16705.msg257897.html#msg257897 bekommt man das ST-RAM beweisbar "out of the box" ohne TOS-Patches oder Treiber. Ich erwarte, dass das bei der Wevelsiep'schen Lösung auch so funktionieren sollte. Ferner erwähnen die Artikel aus den damaligen Magazinen ebenfalls nicht, dass man das TOS tauschen oder patchen müsse.

[czietz]

EmuTOS 1.3 in Eproms auf dem Mainboard ...

Wie viel ST-RAM zeigt EmuTOS 1.3 denn beim Booten an?

[Lukas Frank]

Danke @R^2 für deinen Beitrag ...

EmuTOS von 2020 meldet 2,5MB und EmuTOS 1.3 meldet 4MB genau wie TOS 2.06 allerdings zeigt EmuTOS 1.3 Grafikfehler auf dem Desktop ...

[czietz]

EmuTOS 1.3 meldet 4MB genau wie TOS 2.06 allerdings zeigt EmuTOS 1.3 Grafikfehler auf dem Desktop

EmuTOS schaltet den Blitter standardmäßig ein, Atari TOS 2.06 m.W. standardmäßig aus. Vielleicht erklärt das den Unterschied in der Darstellung...

[Lukas Frank]

Gerade nochmal schnell probiert und zwar wenn ich EmuTOS 1.3 Programm unter TOS 2.06 starte ist alles gut also Blitter läuft ohne Fehler und der EmuTOS Bootscreen meldet MegaSTE und 4MB ...

Mit den beiden EmuTOS 1.3 Eproms auf dem Mainboard läuft die erste Meldung auf dem weißen Bildschirm  "EmuTOS 1.3 ..." in einer Schleife zerrissen durch und alles hängt ...

[R^2]

Hinweis: Atari TOS (wie auch EmuTOS) suchen von sich aus bereits nach ST-RAM oberhalb von 4 MiB. Bei der vergleichbaren MME-Erweiterung https://forum.atari-home.de/index.php/topic,16705.msg257897.html#msg257897 bekommt man das ST-RAM beweisbar "out of the box" ohne TOS-Patches oder Treiber. Ich erwarte, dass das bei der Wevelsiep'schen Lösung auch so funktionieren sollte. Ferner erwähnen die Artikel aus den damaligen Magazinen ebenfalls nicht, dass man das TOS tauschen oder patchen müsse.

Hallo Christian!

Ja und nein!

Ich gehe mal zuerst den "Hardware"-Weg. Die MMU werkelt beim Start vor sich hin und testet nach gewissen Parametern seine beiden RAM-Bänke ab. Folglich, nach den Tests, kommt die MMU zu einem Ergebnis, welchen Speicher sie hat. Adresse FF8001 liefert das Ergebnis der MMU. 2 x 128 kByte (00), 2 x 512 Byte (01), 2 x 2MB (10) liefert das Ergebnis. Oder andere Kombis. Siehe Atari-ST-Profibuch, ca. Seite 799.

Wenn denn nun das TOS diesen Test "überschreibt" mit eigenen Tests, dann ergibt das - natürlich - ein anderes Ergebnis. Wie weit, wird das Testergebnis der MMU vom TOS akzeptiert, korrigiert, übergangen?

Schreibt Martin Wevelsiep mit seinen GAL-Grab evtl. auch das Register (FF8001) von der MMU neu? Wenn ja, welchen Wert gibt er dort vor? (FF8001 = 0F)?

Und - logisch - final die Frage: Wer ist der letzte in der Kette der RAM-Detektion? TOS? Was macht TOS mit dem Ergebnis der MMU? Ignorieren? Neu prüfen? Verwerfen?
Wahrscheinlich auch eine Frage, des verwendeten TOS?

Gruß Robert

[Lukas Frank]

...  läuft die erste Meldung auf dem weißen Bildschirm  "EmuTOS 1.3 ..." in einer Schleife zerrissen durch und alles hängt ...

Man kann das nicht richtig lesen, scheint wohl eine Panik Meldung zu sein ...

[czietz]

Ich gehe mal zuerst den "Hardware"-Weg. Die MMU werkelt beim Start vor sich hin und testet nach gewissen Parametern seine beiden RAM-Bänke ab.

Von sich aus macht die MCU gar nichts. TOS testet beim Booten "auf Verdacht" nacheinander die möglichen Bankgrößen (2 MiB, 512 KiB, 128 KiB) und prüft jeweils, ob der Speicher damit wie erwartet funktioniert. Auf Basis dieser Prüfung wird das erwähnte Register 0xFF8001 gesetzt. Damit kann TOS bis zu 4 MiB (2 x 2 MiB) finden. Nachgelagert testet TOS dann aber oberhalb des gefundenen Speichers einfach weiter, ob es weiteren beschreib- und rücklesbaren Speicher findet. Das erlaubt dann mehr als 4 MiB ST-RAM. Die 14 MiB ST-RAM der MME-Erweiterung werden auf diesem Weg detektiert und sind für TOS "out of the box" nutzbar. Ich erwarte, dass das bei der Wevelsiep'schen Lösung auch so funktionieren sollte.

[czietz]

Mit den beiden EmuTOS 1.3 Eproms auf dem Mainboard läuft die erste Meldung auf dem weißen Bildschirm  "EmuTOS 1.3 ..." in einer Schleife zerrissen durch und alles hängt ...

Ja, was gilt denn nun? In Post #104 hast Du ein "EmuTOS1_3Eprom.jpg" gepostet, das eindeutig den Desktop zeigt, wenngleich auch mit Grafikfehlern; jetzt widersprichst Du Dir selbst und sagst, dass "alles hängt".

Es geht mir darum, was exakt diese Version mit den Grafikfehlern (also EmuTOS 1.3, EPROM, nicht PRG!) beim Booten für einen Speicherausbau anzeigt.

[R^2]

Von sich aus macht die MCU gar nichts.

Hmm, ich bin noch nicht sicher, wer (TOS/MMU) nun was genau macht. Bleibt die Frage, warum das Profibuch beschreibt, dass "die MMU" diese Werte vorgibt.
Sie muss ja schließlich einen linearen Speicher erzeugen. Egal, wo der nun liegt.
Ferner gilt natürlich - ohne genaue Prüfung meinerseits - , dass TOS das Register von sich aus beschreibt, oder zeitlich nach der MMU "überschreibt". Was gilt denn nun für das Register 0xFF8001? Wer ist der "Master"? Merkt sich die MMU mit diesem Register den "linearen" Speicher? Oder merkt sich TOS den adressierbaren Speicher?

TOS testet beim Booten "auf Verdacht" nacheinander die möglichen Bankgrößen (2 MiB, 512 KiB, 128 KiB) und prüft jeweils, ob der Speicher damit wie erwartet funktioniert. Auf Basis dieser Prüfung wird das erwähnte Register 0xFF8001 gesetzt.

Ja, wie oben! Die selbe resultierende Frage. Man muss, glaube ich, Hardwareabfrage nach linearen Speicher und Softwareabfrage nach verfügbaren Speicher ganz genau trennen. Sonst kommen wir auch in der Grundfrage "Wevelsiep'sche Lösung" nicht weiter.

Bitte Schritt für Schritt vorgehen.

Die MMU braucht andere Detektionen - vorab - damit ein linearer Speicher entsteht. Und das TOS hat Tests, damit die echte Speichergrenze detektiert wird.

Wenn Dir, Christian, klar ist, wer welche Schritte zu welchen Zeitpunkt durchführt (TOS (Software) oder MMU (Hardware)), dann bitte den Zusammenhang klar machen. Wie gesagt: Ich bin nur Hardwerker!

Für die Sache: Bitte den zeitlichen Ablauf [MMU detektiert, TOS analysiert] der RAM-Analyse genau spezifizieren, sonst wird uns m.E die Wevelsiep'sche Lösung nicht erschlossen.

Gruß Robert

[czietz]

Robert, Frank, ich verwendet schon wieder viel zu viel Zeit (die ich nicht habe) auf lange Erklärungen und anderer Leute Probleme. Ich beschreibe noch einmal, wie die ST-RAM-Detektion in TOS abläuft – auch wenn ich mir sicher bin, dass das Problem nicht in der Programmierung der MCU liegt. Seht mir bitte nach, dass ich mich aus diesem Thread danach ausklinke. Ich wünsche viel Erfolg bei der Fehlersuche.

Für beide ST-RAM-Bänke auf dem Mainboard getrennt macht TOS eine Speicherdetektion, die wie folgt abläuft: TOS programmiert auf Verdacht das MCU-Register 0xFF8001 für eine 2 MiB Bank. Sind in Wahrheit nur 512 KiB oder 128 KiB verbaut, führt das zu "Spiegelungen" im Speicher, die TOS findet, daraus die Bankgröße erkennt und entsprechend dann den korrekten Wert nach 0xFF8001 schreibt.

Doch das ist alles hier nicht Franks Problem, denn die ersten 4 MiB werden ja korrekt erkannt, wie er mehrfach geschrieben hat.

Danach sucht TOS oberhalb des schon detektierten Speichers einfach weiter, ob es weiteren beschreib- und rücklesbaren Speicher findet. Die MCU wird zu diesem Zeitpunkt nicht mehr angefasst. Die so gefundene Speichermenge wird in der Systemvariable phystop abgelegt.

[R^2]

Robert, Frank, ich verwendet schon wieder viel zu viel Zeit (die ich nicht habe) auf lange Erklärungen und anderer Leute Probleme. Ich beschreibe noch einmal, wie die ST-RAM-Detektion in TOS abläuft – auch wenn ich mir sicher bin, dass das Problem nicht in der Programmierung der MCU liegt. Seht mir bitte nach, dass ich mich aus diesem Thread danach ausklinke. Ich wünsche viel Erfolg bei der Fehlersuche.

Das hilft für die zeitliche Abfolge gut weiter. Danke Christian!

Frank, wenn Du möchtest, schick mir Deinen Rechner per Post zu. Meine postalische Adresse hast Du. (Sonst per E-Mail oder PM). Ich würde dann Deinen Rechner versuchen mir genauer anzusehen. Keine Garantie für irgendwas! Ferner: Die Zeit für Atari ist bei mir extrem eingeschränkt. Ich mach, was ich kann.

Für die Mitlesenden: Sobald sich Neuigkeiten ergeben, wird - natürlich - berichtet.

Gruß Robert

[Lukas Frank]

Danke das machen wir so ...

[czietz]

Eine Anmerkung habe ich doch noch. YAARTTT hat einen (in der Doku beschriebenen) Testmodus mit manueller Adresseingabe. Am Prompt statt [ S] oder [T] einfach [M] drücken und danach den Adressbereich eingeben. Unter einem mit 4 MiB laufenden TOS (z.B. TOS 2.06) lässt sich dann feststellen, ob überhaupt irgendwelcher Speicher oberhalb von 4 MiB zumindest teilweise funktionsfähig ist.

[Lukas Frank]

Hatte das mal versucht in Beitrag #58 und es kamen zwei Bomben ...

Edit: ... alles auf dem Weg zu Robert.