Sonntagsrätsel: TT-RAM-Geschwindigkeitsunterschiede

[czietz]

Lasst uns ein kleines Sonntagsrätsel spielen. 

Ich habe kürzlich herausgefunden, dass die ersten 16 MiB TT-RAM viel schneller sein können als die zweiten 16 MiB (in meinem TT mit insgesamt 32 MiB) -- und auch warum. Details und Testprogramm hier:
http://atari-forum.com/viewtopic.php?f=16&t=38138&p=390410

Was meint Ihr, ist der Grund?

[Gaga]

Vorweg: ich weiß es nicht.

Der Zugriff ab 16MB ist ca. 3,6 mal langsamer als bei den ersten 16 MB. So deute ich Dein Zahlenwerk.

Kann es sein, dass die MMU ab 16MB Waitstates oder Refreshes macht?

[mfro]

Cache ist an?
Wird aber ausgetrickst, weil die Zugriffe nicht aufsteigend sind?

[czietz]

Ja, Cache ist eingeschaltet; der Datencache nützt aber aufgrund der Reihenfolge der Zugriffe nichts, wie Du auch schon gesehen hast. (Nur der I-Cache hilft bei der Codeausführung, weil die Schleife vermutlich komplett hinein passt.)

[czietz]

Und die Auflösung: http://atari-forum.com/viewtopic.php?f=16&t=38138&p=390489#p390489

[mfro]

Ahja. Die MMU muß die Zugriffe auf die "geraden" 16-MB-Pages auf den MMU-Tree leiten, weil sie sonst keinen Supervisor-Speicherschutz in den untersten 16 MB (die sie "aufdröseln" muss) realisieren kann.

Logisch, eigentlich

[Thorsten Otto]

Mit Speicherschutz hat das nix zu tun. Die TTRs werden nur benutzt, um die I/O Addressen sowohl unter $FFFFxxxx als auch unter $00FFxxxx ansprechen zu können.

[guest4215]

Was ich nicht ansatzweise verstanden habe ist, warum es für den Speicherbereich 32-48MB wieder schnell ist und insgesamt alle 16MB wechselt.

[mfro]

Mit Speicherschutz hat das nix zu tun. Die TTRs werden nur benutzt, um die I/O Addressen sowohl unter $FFFFxxxx als auch unter $00FFxxxx ansprechen zu können.

Das stimmt. Die MMU-Tables setzen nur das Mapping und ob gecached wird oder nicht.

Nichtsdestotrotz sorgt das Ummappen der I/O-Areas natürlich auch für deren SV-Protection.

[czietz]

Was ich nicht ansatzweise verstanden habe ist, warum es für den Speicherbereich 32-48MB wieder schnell ist und insgesamt alle 16MB wechselt.

Weil das Transparent Translation Register alle Zugriffe mit Adressbit 24 = 1 an den Translation Tables vorbei leitet.

[Thorsten Otto]

Nichtsdestotrotz sorgt das Ummappen der I/O-Areas natürlich auch für deren SV-Protection.

Nein, auch nicht. Die untersten 3Bits in den TTRs sind in TOS gesetzt, damit wird der Function-Code (ob SV oder nicht) ignoriert.