Diskussion:Chip-RAM und Fast-RAM

„Es war immer ein beliebtes Diskussionsthema, ob ein Amiga ganz ohne Chip-RAM überhaupt lauffähig wäre. Es gibt nämlich diverse Datenstrukturen außerhalb von Video und Sound, die im Chip-RAM liegen müssen. So scheint zumindest ein Mindestbestand an Chip-RAM unverzichtbar.“

Ich finde beliebte Diskussionsthemen gehören auf die beliebte Diskussionsseite. -- Pemu 00:13, 19. Sep 2006 (CEST)

Streichungen

„Hardwaremäßig ist das Chip-RAM zwar mit dynamischem RAM ausgeführt, es ist aber keinerlei Refresh-Logik vorhanden.“ Natürlich ist eine Refreshlogik da. Sie benutzt sogar eigene DMA-Timeslots und funktioniert auch ohne Erzeugung eines Videosignals.

„Das Chip-RAM ist immer fest auf der Amiga-Hauptplatine eingelötet ...“ – Bei meinem A4000 kann ich das Chip-RAM-SIMM 'rausnehmen, wenn ich will.

-- Pemu 00:33, 19. Sep 2006 (CEST)

Timing

"Das Timing des Chip-RAMs ist komplett durch die Video-Funktionalität und deren TV-Kompatibilität bestimmt. Damit gibt es auch signifikante Unterschiede der Daten für die PAL- und NTSC-Versionen der Chips und der mit ihnen ausgestatteten Amiga-Modelle."

Welche Daten sind hier gemeint? Ab ECS gibt es keine eigenständigen PAL/NTSC-Versionen mehr, und die Anzeigemodi sind nicht unbedingt TV-kompatibel (Productivity z.B.).

"Insbesondere der Agnus-Chip mit seinen DMA-Zugriffen auf verschiedene Arten von Daten ist auf ein festes Raster eingerichtet, wie viele Bytes pro Anzeigezeile zu welchem Zeitpunkt für welchen Zweck aus dem Chip-RAM geholt werden müssen. Das führt dazu, dass die Geschwindigkeit nicht einfach durch Takterhöhung des Hauptprozessors gesteigert werden kann, so lange dieser auf das Chip-RAM zugreift; dann würde das Video-Timing nicht mehr stimmen. Beschleunigungen wären nur durch komplette, die Rückwärtskompatibilität gefährdende Neukonstruktion des Chipsatzes zu erreichen. Entsprechend hat dieser Schritt in der Amiga-Geschichte zu Zeiten von Commodore nicht stattgefunden. Das Chip-RAM wurde so mit der Zeit zu einem ernsthaften Performance-Flaschenhals für das ganze Amiga-System. Schon zu Commodore-Zeiten begann aber auch das Zeitalter der einsteckbaren Grafikkarten, die solche Beschränkungen nicht kennen und wesentlich mehr Auflösungen und Farbtiefen generieren konnten."

Das halte ich für ziemlichen Quark. Auflösung und Farbtiefe hängen nicht von der Geschwindigkeit von CPU-Zugriffen ab. Sowohl Bandbreite Chipmem->Chipsatz als auch Chipmem<->CPU sind bei AGA wesentlich höher, obwohl es nur ein moderates Update war.

Plädiere dafür, den Absatz zu streichen, auch weil er nicht durch Quellen belegt ist. --Petuschki (Diskussion) 21:38, 26. Feb. 2014 (CET)

Nö, das war ja gerade das Problem: AGA war kein bisschen schneller! Es waren immer noch 500 usec Zugriffszeit, wie beim guten alten 6502. Deswegen waren ja auch keine höheren Pixel-Auflösungen möglich. Mit Ach und Krach hat man ein paar mehr Bits für Farben rausgequetscht, aber da hing man dann am Poller. --PeterFrankfurt (Diskussion) 01:47, 27. Feb. 2014 (CET)

Worauf beziehst Du Dich? Zugriffszeiten oder Transferraten? Hast Du irgendeine Quelle für 500 usec? Das wären maximal 2000 Zugriffe/s, das ist augenscheinlich falsch. Die maximale Pixelauflösung war bei AGA (und ECS) im Vergleich zum OCS verdoppelt, die Transferrate vom Chipmem zum Chipsatz bei AGA 4x so hoch (SHires 2 Planes (ECS) gegen 8 (AGA)), zur CPU doppelt so hoch dank 32-bit-Bus (Quellen:hier und hier. Das AGA "kein bißchen schneller" war, ist daher offensichtlich falsch, auch wenn's kein großartiges Design ist. Falls Du Belege und Quellen für das Gegenteil hast, bringe sie bitte. --Petuschki (Diskussion) 12:26, 27. Feb. 2014 (CET)

Ich kann da leider nur Hörensagen bieten. Diese Zahlen in den Quellen habe ich noch nie gesehen. Sollte ich da was verpasst haben? --PeterFrankfurt (Diskussion) 02:33, 28. Feb. 2014 (CET)

Nein, das ist leider kein Quark. Der Erfolg des Amiga vor allem im Entertainmentbereich beruhte darauf, dass man mit ihm prima spielen konnte- so wie mit einer Spielekonsole. Das war auch keine Kunst, denn der Amiga war noch als "Lorraine" ursprünglich als ebensolche konzipiert worden. Bis heute unsterscheiden sich Spielekonsolen in ihrer Architeku ganz grundsätzlich von der eines PCs. Die Basis einer solchen Architektur, die als unified Memory-Architektur bekannt ist, ist die absoluter Verzahnung von CPU und Graphiklogik. Es gibt nur einen Speicher für beides und nicht wie beim PC einen dedizierten Graphikspeicher. Auch wenn bei einem einfachen Laptop heute ein Teil des Hauptspeichers als Graqphikspeicher verwendet werden kann, so ist die keine UMA, denn dieser Speicherbereich steht dann für das System selbst nicht zur Verfügung. Wenn CPU und Graphik eng verzahnt mit einander aggieren (beim Amige gehören im Chip-Memory die ungeraden Buszyklen der CPU, die geraden Agnus und damit den CustomChips), kann ich nicht einfach die Taktfrequenz der einen Komponente verändern ohne die Andere zu beinflussen. Die Frequenzen mussten zudem auf das Ausgabemedium abgestimmt sein - daher kommt z.B: die krumme Zahl von 7,14 Hz Takt des NTSC-Amigas - 'zufällig' die doppelte Farbträgerfrequenz (Bei PAL funktionierte das ein wenig anders). Wollte man an einem Amiga mit ICS oder OCS einen schnelleren Prozessor betreiben, ging das nur mit einer Turbokarte, die nicht nur die schnellere CPU und einen schnelleren Speicher beinhaltete, sondern auch für eben genau diese Entkopplung bereitstellte und für eine ganze Menge von Kompatibilitätsproblemen sorgte. Dieses Timing sorgte auch dafür, dass die NTSC-Amiga rund 20% schneller von Diskette geladen haben. Das was den Amiga mitte der 1980er Jahre auszeichnete, die hohe Graphikperformance durche präzise Abstimmung und enge Verzahnung, brach ihm letztendlich auch das Genick: Dieser Entwurf ist zu steif und kann bei Systemen verwendet werden, die viele Jahre unverändert gebaut werden - also Spielekonsolen - nicht aber bei PCs. 2003:CB:A70A:1B01:DA6:885:E057:994E 00:38, 18. Jul. 2019 (CEST)

RAM-Chips war in den 70ern und 80ern teuer, die ersten Home Comuter benutzten "shared memory" ohne dedicated frame-buffer fuer Grafik, wie z.B. beim C64, Atari 800, Amiga, das Atari VCS hatte nur 128 Byte an Registern z.B. --2A04:4540:6A19:6C00:F998:3CFA:7B72:5CBA 12:45, 21. Aug. 2022 (CEST)

Hmm, vielleicht lese ich hier falsch hinein, aber der NTSC Amiga war nicht 20% schneller als der PAL Amiga (NTSC: 60 Hz vs. PAL: 50 Hz) da die Grafikaufloesung eine andere war, low res NTSC: 320x200 vs. PAL: 320x256, hi res NTSC: 640x200 vs. PAL: 640x256. Die Taktungen waren nur leicht unterschiedlich:

1. Master clock (MC): 28.37516Mhz (PAL), 28.63636Mhz (NTSC)
2. Color ClocK (CCK): MC/8 = 3.546895Mhz (PAL), 3.579545Mhz (NTSC)
3. CPU speed is (MC/4): 7.093790Mhz (PAL), 7.159090Mhz (NTSC)

https://retrocomputing.stackexchange.com/questions/5994/amiga-memory-bandwidth/6112#6112

und der ECS konnte vor dem Booten zwischen NTSC und PAL umschalten. --2A04:4540:6A32:2600:4C03:AF19:A09F:563 20:47, 21. Aug. 2022 (CEST)

68k CPU durch Copper ausgebremst

Der OCS Agnus DMA processor konnte den Copper Grafikprozessor vor der CPU beim Chip-RAM Zugriff priorisieren und damit die CPU ausbremsen.

"Hier kann der Prozessor seine Geschwindigkeit ungebremst ausspielen."

Stimmt in dem Kontext nicht ganz, mit dem odd-even access von 68000 CPU ueber Agnus auf Chip-RAM kann die CPU ihre theoretische Bandbreite voll ausfahren (siehe Taktzyklen im beigefuegten Link) wird aber in einigen Anwendungsfaellen durch Copper ausgebremst.

Gute Quelle zu Timings, Taktung und Bandbreite:

https://retrocomputing.stackexchange.com/questions/5994/amiga-memory-bandwidth/6112#6112

Gruesse,

Srdja Matovic --2A04:4540:6A19:6C00:F998:3CFA:7B72:5CBA 12:37, 21. Aug. 2022 (CEST)