Hallo Besucher, der Thread wurde 9k mal aufgerufen und enthält 42 Antworten

letzter Beitrag von writetome am

Amiga 500 mit 2MB Trapdoor langsam

    Hi,


    ich hab in meinen altern A500, Rev. 5 Board, Kick 1.3, so eine 2MB-Erweiterung für die Trapdoor mit Gary-Adapter eingebaut. Das funktioniert soweit auch wunderbar, es werden 1,8MB Slow-RAM erkannt.


    Nur ist mir aufgefallen, daß der Rechner damit extrem langsam ist, und es bei manchen Spielen richtig zum Stocken kommt. Sysinfo zeigt auch nur etwa Faktor 0.8 zu einem A600 an. Ein anderer A500 mit einer Standard 512k Erweiterung dagegen zeigt den Effekt nicht.


    Ist das ein bekanntes Problem dieser 2MB-Erweiterungen?

    Das ist beinah normal. Die Trapdoor wird im A500 komplett über FatAgnus verwaltet.
    Der RAM dort ist immer so schnell/langsam wie das Chipram, weil die CPU dort auch nur in den DMA Lücken zugreifen kann.
    Deswegen heisst der Bereich ab $C00000 auch Slowram, SlowFastRAM oder RangerRAM.
    Das Verhalten kann man leider nicht ändern.


    Es darf aber nicht zu einer Verlangsamung des Rechners führen.
    Der Amiga sollte also mit und ohne Erweiterung gleich schnell bleiben.
    Wenn die Erweiterung den Rechner ausbremst, könnte das am Gary Adapter oder einem Bustreiber liegen. Wenn die Bausteine zu langsam reagieren, muss die CPU noch länger warten.
    Gibt es auch seltsame Abstürze?

    Ich könnte mir auch gut vorstellen, daß es mit dem Refresh zu tun hat. Für 2MB braucht er ja 4x so lang, als für 512k, und solange müssen andere Zugriffe warten.


    Unter diesen Gesichtspunkten sind diese Erweiterungen wohl ein schlechter Scherz. Die waren damals aber bestimmt sau teuer...

    Nein, der Refresh läuft beim Amiga auch in Hardware und er zählt einfach die Zeilenadressen (RAS-only Refresh) durch. Entweder reicht das, dann läuft der Rechner stabil, oder es reicht nicht (*), dann schmiert er früher oder später ab. Es dauert bei 2 MB aber nicht länger als für 512 KB, jedenfalls nicht bei diesen Hack-Erweiterungen weil die normalerweise alle parallel an _RAS hängen und über _CAS gesteuert werden.


    (*) Verwendung von 414256-RAMs mit dem 8371 geht eigentlich nicht, dem fehlt ein Bit im Refreshzähler. Meist reichen die anderen Zugriffe aber trotzdem weil jeder RAM-Zugriff einen Refresh der entsprechenden Zeile durchführt.

    Zitat von kbr

    Aufgefallen ist es mir bislang bei PP-Hammer, insbesondere wenn man in ein Bonus-Level kommt.


    Bei dem Spiel komme ich nicht mal durchs Level 1 ;)
    Generell kann die Rechenleistung oder Grafikleistung (Blitter/Copper) bei mehr RAM nicht langsamer werden.
    Die meissten Spiele nutzen sowieso nur den Chipram und ignorieren zusätzlichen Slow/Fast RAM.

    Zitat von Gerrit

    Nein, der Refresh läuft beim Amiga auch in Hardware und er zählt einfach die Zeilenadressen (RAS-only Refresh) durch. Entweder reicht das, dann läuft der Rechner stabil, oder es reicht nicht (*), dann schmiert er früher oder später ab. Es dauert bei 2 MB aber nicht länger als für 512 KB, jedenfalls nicht bei diesen Hack-Erweiterungen weil die normalerweise alle parallel an _RAS hängen und über _CAS gesteuert werden.


    versteh ich nicht, selbst bei RAS only muß er doch doppelt soviel Zeilen durchzählen, als bei 512k.


    Zitat von BoingBall

    Bei dem Spiel komme ich nicht mal durchs Level 1 ;)
    Generell kann die Rechenleistung oder Grafikleistung (Blitter/Copper) bei mehr RAM nicht langsamer werden.
    Die meissten Spiele nutzen sowieso nur den Chipram und ignorieren zusätzlichen Slow/Fast RAM.


    Woran liegts dann?

    Zitat von kbr


    versteh ich nicht, selbst bei RAS only muß er doch doppelt soviel Zeilen durchzählen, als bei 512k.


    Der Refreshzähler zählt immer gleich viel, gleich schnell. Die RAMs in deinem C64 brauchen, wenn es eine alten Platine mit 4164 DRAMs ist, einen 128-Zyklen Refresh. Der VIC liefert aber immer einen 256-Zyklen Refresh. Aus diesem Grunde laufen auch die 41256 oder 41464 DRAMs noch problemlos. Bei 4164 bedeutet das einfach, daß sie in der gleichen Zeit 2 komplette Refreshes bekommen (Bit 7 wird nicht für Refresh benötigt) in der ein 41464 DRAM nur einen bekommt.


    Das ist der Trick bei den DRAMs, die neueren Generationen brauchten immer mehr Bits im Refreshzähler für den vollen Refresh, aber dafür durfte der sich pro Bit mehr doppelt solange Zeit lassen.


    4164 = 128 Zyklen in 2ms
    41256/41464 = 256 Zyklen in 4 ms
    411000/414256 = 512 Zyklen in 8 ms


    Der C64 war ein Beispiel. Das Gesagte gilt für alle Implementationen die RAS-only-Refresh benutzen. Wenn sie alle RAMs an _RAS parallel ansteuern und nur über _CAS selektieren gilt das sogar für (fast) beliebig viele Bänke.

    Vielen Dank für die Erklärung.
    Ich bin kein DRAM-Experte, aber so ganz will ich das immer noch nicht glauben:


    1. Einen Grund muß es ja für die Verzögerungen geben.
    2. Sind diese 2MB in nur einer Bank organisiert!


    Das sind 16 1x1Mbit Chips(411000), die alle an der selben RAS hängen. CAS gibt es 2x, für die 8 Bit Zugriffe. Und die A9 der Chips geht auf den ominösen Garry-Adapter. Ohne den Adapter funktioniert das Ding genauso wie eine 512k Erweiterung, weil ja dann A9 fehlt. Der Refreshzähler weiss also demnach auch nichts von der A9.


    Langsam frag ich mich, wie das überhaupt funktionieren kann, und vorallem, daß das bereits vom Kickstart 1.3 automatisch korrekt erkannt wird, wo doch zur Zeit der Entwicklung dort nie mehr wie 512k vorgesehen waren?

    Der $C00000-Speicher beim Amiga ist ein Sonderfall. Dort passiert keine Autoconfig, dort wird einfach (wie beim C64) getestet wieviel Speicher denn nun vorhanden ist und der wird benutzt. Es gibt eine Grenze (dazu brauchts eben das PAL/GAL auf dem GARY-Adapter um das korrekt zu erkennen) und das sind keine vollen 2 MB sondern sowas in der Gegend von 1.8 MB.


    Beim A500 waren dort vielleicht nicht mehr als 512 KB vorgesehen, bei anderen Amigas hingegen schon. Erinner dich an den A2000A mit seiner speziellen Speicherkarte im Prozessorslot. Rate mal wo die ihren Speicher einblendet. Diese Karte kann bis 1 MB.


    Wegen A9, ja die Megabitchips auf der Karte brauchen nur einen 9Bit-Refresh (A0-A8), weshalb A9 anderweitig verwendet werden kann und es nicht stört wenn dort kein Refresh kommt. Eigentlich müsste das mit einem 8371 trotzdem Ärger geben, aber es reicht anscheinend der Refresh durch die normalen Speicherzugriffe(*). Das sind nicht zufällig Low-Power Versionen auf der Karte? Die sind beim Refresh etwas entspannter vom Timing.


    (*) Jeder normale Zugriff auf ein DRAM ist äquivalent zu einem Refresh der angesprochenen Zeile.


    Nachtrag... Wer generiert für diesen Speicherbereich _DTACK? Das ist die einzige Möglichkeit wie der Speicherzugriff für die CPU gebremst werden kann. Laut meinem Schaltplan geht das über GARY. Hängt für _DTACK das GAL irgendwie zwischen GARY und dem Rest des Systems?

    Zitat von kbr

    Aufgefallen ist es mir bislang bei PP-Hammer, insbesondere wenn man in ein Bonus-Level kommt.


    Habe mir das Spiel mal angesehen.
    Es benutzt scheinbar gar keinen Slow/Fast RAM und arbeitet nur im ChipRAM.
    Daher sollte es keinen Unterschied machen, ob der Amiga irgend eine Speichererweiterung hat oder nicht.


    Zudem ist der Slowram (in der Trapdoor ab $C00000) sowieso gleich schnell wie der Chipram.
    Am besten kann man das mit dem Tool Sysinfo testen.
    Da sollte mit und ohne Erweiterung immer der Faktor 1.00 zum standard A600 erscheinen. Kleine Abweichungen im 0,0x Bereich sind egal.

    Zitat von Gerrit

    Nachtrag... Wer generiert für diesen Speicherbereich _DTACK? Das ist die einzige Möglichkeit wie der Speicherzugriff für die CPU gebremst werden kann. Laut meinem Schaltplan geht das über GARY. Hängt für _DTACK das GAL irgendwie zwischen GARY und dem Rest des Systems?


    hab gestern mal den Adapter angeschaut, und _DTACK(Pin43) ist nur durchgeschleift.


    Zitat von BoingBall

    Zudem ist der Slowram (in der Trapdoor ab $C00000) sowieso gleich schnell wie der Chipram.
    Am besten kann man das mit dem Tool Sysinfo testen.
    Da sollte mit und ohne Erweiterung immer der Faktor 1.00 zum standard A600 erscheinen. Kleine Abweichungen im 0,0x Bereich sind egal.

    Ich hatte ja bereits geschrieben, daß sysinfo etwa Faktor 0.8 zu einem A600 anzeigt.


    Aber ich habe einen neuen Anhaltspunkt. Evtl. lag es an dem verwendeten Agnus. Ich hatte da nämlich einen 8371 aus einem A2000 drin. Zuvor war ein 8375 drin für 1MB Chip, aber den brauch ich da nicht mehr, da diese Erweiterung eh kein Chipram unterstützt. Den wollte ich stattdessen im A2000 nutzen, aber da lief der nicht vernünftig. Es gab da immer Grafikfehler, so daß immer nur noch die Hintergrundfarbe angezeigt wurde, sogar bereits beim Diskettensymbol. Deutet auf irgendwelche DMA-Timingprobleme hin. Werde den demnächst wieder zurücktauschen, und dann nochmal berichten.


    Ursprünglich war da auch nur ein alter 512k Agnus drin, aber den find ich nicht mehr...

    Gut das Du das Problem lösen konntest :)


    Agnus ist quasi das Herzstück des Amiga Chipset und erzeugt alle Taktsignale für das gesamte System.
    Daher kann es bei einem Wechsel der Chipset Generation (von ECS zu OCS) zu Problemen kommen.
    Dazu vielleicht noch das Alter der ICs und die Signalbelastung an den Ausgängen, die sich je nach Board (Revision) und den anderen ICs noch verändert hat. Wenn dann irgendetwas nicht sauber läuft, kann es zu sehr seltsamen Effekten kommen.

    Nein, das geht so ohne Weiteres nicht.


    Was Du aber probieren könntest, wäre eine Verwendung der 2MB-Erweiterung ohne den Gary-Adapter. Damit wäre der Rev.8 mit seinem 2MB-Chipram Agnus auf 2MB Chipram aufgerüstet. Poste doch mal ein Bild von der 2M-Erweiterung selbst, vielleicht hast Du ja das Glück ;-)


    Jens