Selbstbaubeschleuniger für den Falcon - HW4711-Edition

[mfro]

Jaja, Du würdest Deinen VW auch auf dem Prüfstand unter Spezial-Bedingungen testen, ich dagegen schaue lieber mal, was er denn so im alltäglichen Gebrauch macht...
Hier geht es um die CPU-Performance.
Ein Benchmark, der behauptet, diese zu messen, sollte das völlig unabhängig vom BS sowie auch unbeeindruckt von jeglicher sonstiger nebenläufiger Software können! Genau das aber schafft GEMBENCH _nicht_ (wie meine ScreenShots beweisen)...

Da brauchst Du nix mehr zu beweisen.

Daß GEMBENCH bezüglich der CPU-Performance nicht besonders akkurat ist, ist seit Urzeiten bekannt. Für einen vernünftigen "pure"-CPU-Benchmark müssten alle Interrupts gesperrt werden, was GEMBENCH eben nicht tut. Selbst wenn's das täte, könnte man wieder argumentieren, daß die Werte falsch sind, weil sie eben nicht in einer benutzbaren, realen Laufzeitumgebung stattgefunden haben (wenn Du feststellst, daß jemand im VBL-Interrupt hängt, hängst Du den dann zum Messen aus oder nicht?).

Irgendwas ist halt immer. Die vernünftigste GEMBENCH Messung bekommst Du, wie die Dinge liegen, eben dann, wenn es (soweit möglich) alleine läuft.

[tuxie]

ein CPU-Wert von 141% noch "durchschnittlich um ca.130%", also Indikator, daß ddd zurückswitcht - oder schon im Gegenteil der Beweis, daß dies nicht geschieht? Oder, noch mal ganz anders formuliert: Die 68k-CPUs laufen doch asynchron? Warum also meinen manche Speeder, doch mit dem Bustakt synchronisieren zu müssen?

Leider stimmt deine Aussage nur beim Falcon, alle andere Ataris wie der St und auch der TT besitzen einen Syncronen modus nämlich immer dann wenn auf Motorolla Bauteile zugegriffen wird wie z.b. der MFP. Dafür haben die Cpus nämlich auch extra Steuerleitungen damit das Funktioiert. Asyncron laufen alle Buszugriffe die Über Adresse/AS/DTACK gesteuert werden. Und dort ist das auch nicht egal, denn wenn die CPU beschleunigt ist dann stimmen die Timings nicht mehr und die CPU versucht z.b. schon zu lesen obwohl die Daten auf dem Bus noch nicht Stabil sind und damit Führt es zum Crash. Ja es geht das die CPU mit höheren Takt läuft wie der Bus selbst aber dafür bedarf es der Anpassung der Steuersignale d.h. es müssen entsprechend der Differenz verzögerungen eingebaut werden, am Bsp. 8 auf 16 Mhz sind es z.b. 125ns wo das DTACK und das BGACK Signal verzögert werden muß. Und damit ist die CPU am ende für diese 125ns ebenfalls angehalten. Anders ist das wenn ein Cache eingebaut ist.

Beschreibung des Syncronen Buszugriffes siehe Handbuch Seite 9
http://www.weblearn.hs-bremen.de/risse/RST/WS02/Motorola68K.pdf

[ari.tao]

Danke für die Aufklärung, @tuxie , das war nun endlich einmal Tacheles. Und Danke auch für den Link!
-------
Eben weil dann der beste Wert erscheint, @1ST1 & @mfro , war die Messung unter TOS_4 dabei  .
Wenn ich alle ACCs aushänge (außer ScreenShot), geht der CPU-Wert von 141 auf 142.

Hilfe, Moderator, könnte mal jmd. diese sicherlich sehr interessante Benchmark-Diskussion in einen eigenen Thread auslagern?! (Ich könnte da sicherlich noch einiges zu beitragen  ).

Und nun zurück zum Thema:
Meine Frage an @Arthur (& alle) war (und ist immer noch nicht sicher beantwortet), ob ddd/HS32 den Bustakt switcht wie Green oder HW in seiner Version 1, oder etwa nicht, wie HW in seiner Version 3 ?
Die nächste Frage wäre, wie man die Video-Modes in den Griff kriegt, wenn der Bus-Takt zw. 16/18/20/25  MHz wechselt? Nach meiner Erfahrung mit der SRC kommt wohl nur ein fest eingestellter Bustakt in Frage? Wie funzt denn das mit dem Video, @Arthur , wenn der Bustakt per Software umgestellt wird?!
-------
Ist HW noch bei uns?

PS: Ich habe den status nascendi in meinem Vorstellungs-Thread jetzt aufgehoben.

[tuxie]

Dazu kann ich heute abend nochwas schreiben... bin aktuell unterwegs

[tuxie]

CPU Benchmark:

Es gibt verschiedene Arten von CPU benchmark, das wären z.b. Primzahlenberechnung, SuperPI und einiges mehr, auf HWbot gibt es eine ganze liste einige davon sind auch Open Source und könnte man eventuell auch auf einem TT/F030 oder gar ST abbilden.

Dann ist noch ein Interessantes Thema die Busgeschwindigkeit also auch der Datendurchsatz zum Ram und zurück, denn mit dieser Geschwindigkeit steht und Fällt die Performance des ganzen Systems. Deswegen bringen die Busbeschleunigungen mehr an Performance als diese Taktverdopplung wie z.b. beim Skunk.
Thema Videl:

Der Videl hat drei Takteingänge 1. 25Mhz (fest) 2. Bustakt, 3. Genlock eingang bzw. Externer Takteingang welcher gern bei der externen blowup verwendet wird.

Die SRC hat soweit ich mich erinnern kann eine direkte Verbindung zum Externen Takteingang des Videls und somit ist der Takt des Videls Bustaktunabhängig.

Bei den einzelnen Tools zum Verändern der Auflösung kann man dann auch Auswählen welchen Takteingang man verwenden möchte.

[ari.tao]

An meinen Dhrystone-Testergebnissen
->   http://forum.atari-home.de/index.php?topic=13075.20
kann man den Einfluß der verschiedenen Parameter auf die Gesamt-Performance, wie zB. CPU-Takt, Bus-Takt, Prozessor, Cache, Video-System etc., sehr gut ablesen.
-------
In welchem Thread hab´ ich denn das bloß gelesen, wie nämlich der Bustakt das Video-Timing (Horizontalfrequenz?) beeinflußt?!
Bei der SRC wird nmE. nur ein Takt (50MHz?) in den ext. Takteingang des Videl eingespeist. Der ist aber nicht für alle Auflösungen brauchbar (ibs. nicht für die drei ST-Auflsgn.) und der 25MHz-ClockTakt (der zB. ST-hi abdeckt) wiederum reicht auch nicht für alle restlichen ... Der mittlere Takt aber verändert sich anscheinend mit dem BusTakt!
Die _Wahl_ ist also sehr eingeschränkt - ausgerechnet für die interessante Auflösung 800x600x4!

[tuxie]

Das wird aber abhängig der Auflösung selbst gesetzt welchen eingang er verwendet, also ich hatte da eigentlich nie Probleme. Und deinen benchmark werde ich mal testen

[ari.tao]

Wie schon mal kurz erwähnt, hatte ich Probs bei der BusTakt-Umschaltung der SRC mit den Video-Modes (in meiner damaligen Naivität hatte ich auch dafür einen Schalter eingebaut).
------
Der Dhrystone ist nicht _mein_ Benchmark. Ich habe lediglich geringfügige Anpassungen an div. M2-Systeme vorgenommen. Lediglich etliche (nicht alle) der Meßergebnisse sind von mir.