Hier geht es gar nicht um NVDI sondern um den Romzugriff und NVDI verfälscht auch nicht das Ergebnis, ganz im gegenteil damit kann man ganz gut die Leistungssteigerung des gesamten Systems Sichtbar machen.
Dem ist aber nicht so, dennoch greift Tos auf das RomJa, natürlich finden noch ROM-Zugriffe statt, auf das AES, BIOS, XBIOS, Desktop-App, GEMDOS*, aber nicht mehr auf das VDI. Und wenn du irgendwelche GEM-Benchmarks machst, wird halt auch sehr viel das (N)VDI beansprucht.
Hallo Tuxie,
Da fiel mir Heute noch etwas ein. Und das will ich gerne hier mal "spiegeln" 8)
Vom MMU wird das Chip-Select Signal für den Eproms erzeugt.
Wenn ich dieses Signal direct nach XDS0/1 verbinde mittels OC Gatter (Oder Schottky Diode sogar), sollte es auch functionieren. Natürlich sind schnellere Roms da immer noch nötig. :)
Dies spart viel Verdrahtung und ist sehr wenig Arbeit. Sollte so einfach sein das fast jeder es schafft.
Werde dies mal testen.
@ Alle
Wegen Test, mag ich es immer um klar zu haben was passiert.
Einfaches ein / aus Schalten habe ich da am liebsten. Also Test mit oder ohne etwas, weiter unter gleiche Bedingungen.
Es ist mich nicht klar was Gembench genau macht bei jeden Test.
Aber bei jedes Programm werden viele Teile vom Computer benützt.
Gembench ist im Ram geladen. Aber TT oder ST-Ram? Und Firmware aus Eprom oder TT Ram nach copie? Alles hat einfluss.
Daher ist jedes mal vergleichen angesagt.
Züm Beispiel den FPU-Clock.
Ich hab bemerkt das bei steigen der Clock-geschwindigkeit über 40Hmz viel weniger passiert. Also 32 Mhz nach 40Mhz hat zuname X. Aber dann von 40 nach 48Mhz ist nicht wieder X. Und nach 56Mhz ist es noch weniger. Warum? Ich denke austausch von Daten zwischen CPU und FPU ist den "Bottleneck"
Bei diesen Tests hab ich immer nür den FPU-Takt geänderd.
MFG/
Guus
Dem ist aber nicht so, dennoch greift Tos auf das RomJa, natürlich finden noch ROM-Zugriffe statt, auf das AES, BIOS, XBIOS, Desktop-App, GEMDOS*, aber nicht mehr auf das VDI. Und wenn du irgendwelche GEM-Benchmarks machst, wird halt auch sehr viel das (N)VDI beansprucht.
*Es sei denn, du hast BigDOS geladen!
So genau muss man schon sein! Wenn du also fair ROM-Speed testen willst, darf weder BigDOS noch NVDI geladen werden, noch ein alternatives AES oder Desktop. Wenn du "Original" gegen maximal getunt vergleichen willst, dass den getunten Rechner mit TOS im RAM, NVDI, BigDOS (oder MiNT), New/MyAES und evtl. ein alternativer Desktop. In dem Extremfall wird das ROM garnicht mehr angesprochen und jegliche Schaltungen zum Beseitigen von ROM-Waitstates sind überflüssig.
Ad FPU:
Auf seinen Atari Pages schreibt auch Exxos
https://www.exxoshost.co.uk/atari/last/FPU/index.htm
daß eine Beschleunigung der FPU über ein gewisses Maß hinaus nicht mehr viel bringt.
Unter Berücksichtigung der erzeugten Abwärme ist imho >40MHz zweifelhaft (auch wenn es immer heißt, die FPU vertrage problemlos Übertaktung bis 50MHz).
Ad GemBench:
Dieser Benchmark war immer schon sehr dubios.
Zu seiner Messung des ROM-Speed ist zu sagen, daß ganz offensichtlich nicht die Geschwindigkeit des ROMs gemessen wird, sondern die gewisser TOS-Zugriffe - anders ist nämlich imho der Faktor zwei für ROM-Speed nicht zu erklären, der sich ergibt, wenn man das TOS per GemRam in´s TT-RAM lädt.
Ad FPU:
Auf seinen Atari Pages schreibt auch Exxos
https://www.exxoshost.co.uk/atari/last/FPU/index.htm
daß eine Beschleunigung der FPU über ein gewisses Maß hinaus nicht mehr viel bringt.
Unter Berücksichtigung der erzeugten Abwärme ist imho >40MHz zweifelhaft (auch wenn es immer heißt, die FPU vertrage problemlos Übertaktung bis 50MHz).
... wir haben doch geschrieben das der ROM Zugriff Künstlich gebremst ist, wenn man diese Bremse ausbaut dann verdoppelt sich die Zugriffsgeschwindigkeit auf das ROM. Bei mir sind es halt 221% was auch beim normalen Arbeiten am Rechner auf Desktop ebene auch ohne NVDI sich bemerkbar macht. Ich habe nie gemram verwendet sondern nur das TOOL von Uwe Seimet. Aber das hat hier jeder Überlesen!!! Auch damit war der Geschwindigkeitsunterschied Spürbar, aber nicht richtig Messbar (warum auch immer).
Ad Abwärme:
von 16 auf 56MHz ist´s mehr als eine ganze Größenordnung.
Da braucht der arme Chip aber wirklich einen ganz kühlen Körper.
Ich hatte mich mal vor längerer Zeit sehr intensiv mit Taktmessungen per Software am 680x0 befaßt. Für den 68000 waren Ergebnisse sehr zuverlässig zu bekommen - der 68030 jedoch ist mit seinem Cache und seiner internen Takt-Verdoppelung nur sehr schwer in Griff zu kriegen, da es afaik keine Möglichkeit gibt, sicher zu stellen, daß ein Stück Code im Cache abläuft oder nicht.
Ich hatte mich mal vor längerer Zeit sehr intensiv mit Taktmessungen per Software am 680x0 befaßt. Für den 68000 waren Ergebnisse sehr zuverlässig zu bekommen - der 68030 jedoch ist mit seinem Cache und seiner internen Takt-Verdoppelung nur sehr schwer in Griff zu kriegen, da es afaik keine Möglichkeit gibt, sicher zu stellen, daß ein Stück Code im Cache abläuft oder nicht.
68030 mit internerTaktverdoppelung? Das ist mit neu.
der 68030 jedoch ist mit seinem Cache und seiner internen Takt-Verdoppelung nur sehr schwer in Griff zu kriegen, da es afaik keine Möglichkeit gibt, sicher zu stellen, daß ein Stück Code im Cache abläuft oder nicht.
Ad Abwärme:
von 16 auf 56MHz ist´s mehr als eine ganze Größenordnung.
Da braucht der arme Chip aber wirklich einen ganz kühlen Körper.
Bei mir sind schon 70ns rams drin (PS2 Sim Modul umbau von Frank Lukas). Der läuft Stabil, ganze Nacht Gembench Loop und Julia mehrfach
Du solltest wissen, @Arthur , daß der TT einen Jumper hat, mit dem der FPU-Takt umgestellt werden kann von 16 auf 32MHz. Die ersten TTs wurden afaik mit JumperStellung 16 ausgeliefert. Keine Ahnung, ob das immer so blieb; meine TTs sind auf 32 gejumpert (möglicherweise von mir selber nach Anleitung in Chips´nChips oder sonstwo - weiß ich nicht mehr). Ich sehe daher nicht, warum Du an meiner Aussage in #46 herummäkelst.Ad Abwärme:Von 32MHz nicht von16MHz!
von 16 auf 56MHz ist´s mehr als eine ganze Größenordnung.
Da braucht der arme Chip aber wirklich einen ganz kühlen Körper.
Lesen tut es sich aber definitiv anders. :D Ich bestreite nicht das der Cache einen Einfluss hat doch Vergleichbarkeit ist weiterhin gegeben.Beim Lesen, Arthur, sollte man vielleicht versuchen herauszufinden, was der Autor meint, und nicht, was die eigenen Vorurteile bestätigt oder ihnen widerspricht.
Ich hatte mit ihm schon einmal darüber diskuttiert am Telefon und da meinte er der 68030 hätte ...Ich möchte hier einmal klarstellen, daß es nur einziges Tel.-Gespräch mit tuxie gab - das war Anfang Dez ´16 - und in dem ging es nmE. um soziale Belange des Forums und nicht um technische Fragen, schon gar nicht um Interna des 68030. Als Beleg habe ich noch seine vorweggehende PM an mich.
... der 68030 jedoch ist mit seinem Cache und seiner internen Takt-Verdoppelung nur sehr schwer in Griff zu kriegen ...(und spreche von ´intern´, weil der Cache im Prozessor integriert ist) und nicht, was Du da als mich angeblich zitierend zusammenfabulierst.
Sag mal kannst du Lesen`?und auch nicht schon wieder herumschreist mit 1000 Ausrufezeichen. Es geht hier nicht darum, einen Hahnenkampf auszufechten, sondern darum, einen technischen Irrtum zu beseitigen. Ich kann nichts dafür, daß Du offensichtlich niemals eine alternative Meßmethode anstatt GemBench verwendet hast. Nochmal in aller Deutlichkeit: Auch wenn GemBench behauptet, es messe ´ROM Access´, so ist diese Behauptung zumindest für den 68030 offenbar falsch (auch wenn für den 68000 die verwendete Methode noch funktioniert haben mag).
Man misst aber fast nur die Taktverdoppelung des Prozessors. Denn aufs ROM wird nur einmal zugeriffen, wenn die TOS-Routine das erste Mal aufgerufen wird. Wird sie dann noch hundert mal durchlaufen, ist sie 99 mal schon im Cache.der Cache ausgeschaltet sein. Das ist aber in allen Deinen Bildern, sowohl hier (s. zB. #57 & #60) als auch auf YT, _nicht_ der Fall. Aber selbst bei ausgeschaltetem Cache halte ich die Methode von GemBench für nicht seriös genug, um wirklich von einer Messung der ROM-Geschwindigkeit zu reden.
Will man wirklich das ROM benchmarken, dann ... und mit ausgeschaltetem Cache.
Tuxie ist nicht genialer als Shiraz S, sondern hat nur die Möglichkeiten der Jahre 2018/19, wo es halt wesentlich schnellere ROM Bausteine als 1988/89 gibt, als der TT entwickelt wurde. Ich möchte die Beschleunigung also grundsätzlich nicht in Abrede stellen, sondern nur dass richtig gemessen wird.
^^--Ich habe doch gerade im letzten ScreenShot gezeigt, welch unsinnige Zahlen da herauskommen, wenn die Referenz nicht stimmt.
Ich für meinen Teil halte von GEMBENCH 6 gar nichts, nutze immer noch die Version original Version 4.03 ...
Ich für meinen Teil halte von GEMBENCH 6 gar nichts, nutze immer noch die Version original Version 4.03 ...?
Dann vergleich die Ausführungszeiten !!
12.08 vs 16.46 da brauch ich auch am Referenzfile nichst verändern >:( >:(
Da ist ja logisch, wenn du den ST als Referenz nimmst und dann mit dem TT vergleichst dann stimmt die Basis nicht...In #68, @Arthur , wurde kein ST als Referenz benutzt, sondern die TT-Messung von @tuxie , die er uns hier als Referenz beschert hat:
Ich für meinen Teil halte von GEMBENCH 6 gar nichts, nutze immer noch die Version original Version 4.03 ...Du hast, Frank, genau wie Arthur, anscheinend die Hoffnung, daß trotz einiger Ungenauigkeiten wenigstens die Vergleichbarkeit in GB gegeben ist. Genau diese Illusion habe ich aber in #67, 2.Teil gründlich zerstört.
4 Posts nacheinander und dann noch nicht einmal direkt zum Hauptthema. Wie kann man nur so viel hier schreiben?! Ist schon anstrengend, bei solchen Betonbeiträgen zu folgen.Schenkel klopf. :D Geil
Inzwischen dürfte klar geworden sein, wer hier welche Meinung vertritt.
@ari.tao : warum versuchst Du Dein Talent nicht einmal mit einem Artikel in der STC?
Vorschlag zum Thema: Gembench - Gotteswerk oder Teufelszeug
Da ist ja logisch, wenn du den ST als Referenz nimmst und dann mit dem TT vergleichst dann stimmt die Basis nicht...In #68, @Arthur , wurde kein ST als Referenz benutzt, sondern die TT-Messung von @tuxie , die er uns hier als Referenz beschert hat:
https://forum.atari-home.de/index.php/topic,12819.msg208428.html#msg208428
Als offenbar wurde, daß da höchstwahrscheinlich ein Fehler bzgl. Video passiert war, wollte ich einfach eine neue Referenz erstellen - "ist ja bloß eine Stunde Mühsal" - und erlebte das in #38 berichtete Desaster.
exxos hat seit Juli nix mehr an GB6 gemacht. Kann mir nicht vorstellen, daß er von dem Problem nichts weiß... Denke mir im Gegenteil, daß er sehr gut weiß, mit welch heißer Kartoffel er da jongliert...
Hallo,
Sehr viel zu lesen....
Wenn ich einfach zwei Dioden zwischen /CS vom Rom und XDS0/1 anschliesse, bootet der TT nicht mehr. Aber ich hab noch 4 DIL 29F040 mit 90nS in mein TT.
Also werde ich erst mal schnellere Flash einbauen. Hab die aber nür als PLCC und brauche Adapter-Platinen zu machen. Lötversion, wegen bauhöhe. (Hab auch Platinen bei SEEED bestellt)
Geht also weiter.
@FPU: Könnte meine Idee stimmen dass es mit Datenaustausch zu tun hat?
@Testen von Speed: Wenn Ich je nür eine Variable ändere, kann ich sehen ob dies etwas ändert oder nicht beim testen. Dies ist für mich am wichtigsten. (Und nicht die Frage wemm ist am grössten... ;D )
@Romspeed: Wenn ich ein Teil vom Rom ins Ram copiere und feststelle wieviel Zeit das braucht, ist dieses ergebniss nür abhangig vom Rom-Zugriffszeit. Denn alle andere einflüsse sind da immer gleich. Da hilft auch kein Cache. Oder seh ich dies Falsch?
Vergleich von "absoluten Speed" ist immer sehr schwerig, denn wass möchte man wissen. Daher auch verschiedene Benchmarks, je nachdem.
MFG/
Guus
...im Apollo-Forum vorgeführt, als es um die MIPS des 68080 im Vergleich mit anderen 68K-CPUs ging.Hast Du einen Link?
Vorschlag zum Thema: Gembench - Gotteswerk oder Teufelszeuglol
@FPU: Könnte meine Idee stimmen dass es mit Datenaustausch zu tun hat?Imho ja. Müßte bei CPUs mit integrierter FPU deutlich besser sein.
@Testen von Speed: Wenn Ich je nür eine Variable ändere, kann ich sehen ob dies etwas ändert oder nicht beim testen. Dies ist für mich am wichtigsten. (Und nicht die Frage wemm ist am grössten... ;D )lol. - Nein, bei falscher Meßmethode kann der Effekt beliebig werden (auch negativ).
@Romspeed: Wenn ich ein Teil vom Rom ins Ram copiere und feststelle wieviel Zeit das braucht, ist dieses ergebniss nür abhangig vom Rom-Zugriffszeit. Denn alle andere einflüsse sind da immer gleich. Da hilft auch kein Cache. Oder seh ich dies Falsch?Ja, siehst Du imho falsch. Siehe #83. Der Cache hat Einfluß; verändertes Timing kann erstaunliche Effekte zeitigen.
Da ist ja logisch, wenn du den ST als Referenz nimmst und dann mit dem TT vergleichst dann stimmt die Basis nicht...In #68, @Arthur , wurde kein ST als Referenz benutzt, sondern die TT-Messung von @tuxie , die er uns hier als Referenz beschert hat:
https://forum.atari-home.de/index.php/topic,12819.msg208428.html#msg208428
Als offenbar wurde, daß da höchstwahrscheinlich ein Fehler bzgl. Video passiert war, wollte ich einfach eine neue Referenz erstellen - "ist ja bloß eine Stunde Mühsal" - und erlebte das in #38 berichtete Desaster.
exxos hat seit Juli nix mehr an GB6 gemacht. Kann mir nicht vorstellen, daß er von dem Problem nichts weiß... Denke mir im Gegenteil, daß er sehr gut weiß, mit welch heißer Kartoffel er da jongliert...
_KEINE_ der Versionen taugt etwas, Arthur!
Der Drache ist tot.
Unschuldige Seelen müssen ihm künftig nicht mehr zum Opfer fallen.
^^-- Lies mal oben. Da steht auch irtgendwo, daß die (immer noch aktuelle) Version vom July die Abstürze macht.
Ansonsten: Die Postings ## 67 & 85 habe ich ibs. für Dich & Frank verfaßt (aber nicht nur für Euch beide).
| * NVDI GEM-Test V2.00 (c) 1991-1993 by Sven & Wilfried Behne * * Auflösung : 1024 X, 768 Y * Farbebenen : 8 * Farbstifte : 256 * Farbpalette : > 32767 Abstufungen * Betriebssystem : Mag!X 6.20 * Referenzsystem : TOS 3.01/ST-Hoch * NVDI-Version : V4.12 installiert * GDOS-Version : NVDI * Blitter : nicht vorhanden * CPU : M68030 * FPU : M68882 * Rechner : ATARI TT * Textausgabe : 511 % Linien : 315 % Rechtecke : 115 % Polygone : 123 % Kreise/Ellipsen : 285 % Rasteroperationen : 33 % Attributfunktionen : 562 % Auskunftsfunktionen : 446 % ESCAPES : 54 % BIOS-Ausga be : 75 % GEMDOS-Ausgabe : 146 % AES-Objekt-Ausgabe : 346 % |
... würde ich Coremark statt Dhrystone empfehlen. Ich kann eine Version für TOS zur Verfügung stellen.
Für mich ist der Kampf erledigt. Ich bade jetzt noch ein wenig im Drachenblut ...
Wenn's darum geht, CPU-Leistung (und zu gewissem Anteil RAM-Zugriff) zu benchmarken, würde ich Coremark statt Dhrystone empfehlen. Ich kann eine Version für TOS zur Verfügung stellen.
Mir geht’s exakt wie @ArthurKondoliere von Herzen zum Ableben Eures Lieblings.(https://www.smilies.4-user.de/include/Traurig/smilie_tra_182.gif) (https://www.smilies.4-user.de)
Johannes - der immer Kronos benutzt, andere Tools aber nicht verteufelt. ;)
Ja, abhängig vom Schalter gibt es 2 verschiedene geschwindigkeiten.Verlaß Dich nicht auf Messungen mit GemBench! Dessen Meßmethoden sind nicht koscher. Es kann imho passieren, daß durch eine Timing-Änderung plötzlich ein Stück Code im Cache ausgeführt wird, das vorher nicht im Cache ausgeführt wurde bzw. erst noch in den Cache geladen werden mußte. Und dann siehst Du plötzlich einen positiven Effekt, der aber mit dem, was Du eigtl. beobachten möchtest, gar nichts zu tun hat.
Gembench gibt um einige Procente mehr Geschwindigkeit an. Also es hat Effect.
Verlaß Dich nicht auf Messungen mit GemBench! Dessen Meßmethoden sind nicht koscher. Es kann imho passieren, daß durch eine Timing-Änderung plötzlich ein Stück Code im Cache ausgeführt wird, das vorher nicht im Cache ausgeführt wurde bzw. erst noch in den Cache geladen werden mußte. Und dann siehst Du plötzlich einen positiven Effekt, der aber mit dem, was Du eigtl. beobachten möchtest, gar nichts zu tun hat.
Ich habe nicht aus Jux und leichtfertig gg. GemBench im anderen Thread gewettert, sondern weil ich sah, daß es sogar gestandene Profis zu Irrtümern verleitet. Man glaubt gerne, zu sehen was man doch glauben möchte.
Deine drei Sätze fallen auf Dich selber zurück.
Diese Wortwahl ("kindisch") verbitte ich mir. Sie entlarvt Deine verletzende Absicht und ist der Sache abträglich.