atari-home.de - Foren
Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet von: tuxie am Di 07.03.2017, 20:36:46
-
Weiss zufällig jemand ob man beim TT für den ST-Ram Waitstates einfügen kann ?
Der Shifter kommt nicht hinterher, brauche min einen Waitstate
-
Ich weiss nicht ob ich richtig liege aber Simbo hatte mal was geschrieben auf atari-forum.com meine ich ...
Er schreibt da was von einem Bit setzen bei der MCU im Atari TT.
-
Da ging es um die Waitstates für die Roms. Leider nicht ST-Ram, geht wohl nicht, hab die Schaltpläne mal Studiert... nun dann wird's wohl nix mit 24Mhz Bus Speed, naja.. was anderes einfallen lassen.
-
Gehts hier drum, den TT zu übertakten? Von dem was ich über den TT weiß, sind da sehr enge Grenzen gesetzt, wenn überhaupt. Da alles im TT syncron zusammen hängt, gerät da auch das komplette Videotiming durcheinander und es gibt wahrscheinlich keinen Punkt, wo man da wieder korrigierend eingreifen kann.
Ich finde eher, man sollte mal drüber nachdenken, ob es möglich ist, über den TT-RAM-Sockel eine schnellere CPU nachzurüsten. Es gibt da ein hübsches, kompaktes FPGA-Projekt, welches eine 68040/060 bei derzeit ca. 90 Mhz nachbildet...
-
ICh hab hier nicht gefragt ob was und wie machbar ist, sondern ob es eine Möglichkeit gibt Waitstate einzufügen. Und was geht und nicht geht das überlasse mal uns...
-
Gehts hier drum, den TT zu übertakten? Von dem was ich über den TT weiß, sind da sehr enge Grenzen gesetzt, wenn überhaupt. Da alles im TT syncron zusammen hängt, gerät da auch das komplette Videotiming durcheinander und es gibt wahrscheinlich keinen Punkt, wo man da wieder korrigierend eingreifen kann.
Ich finde eher, man sollte mal drüber nachdenken, ob es möglich ist, über den TT-RAM-Sockel eine schnellere CPU nachzurüsten. Es gibt da ein hübsches, kompaktes FPGA-Projekt, welches eine 68040/060 bei derzeit ca. 90 Mhz nachbildet...
Auf dem TT Ram Sockel fehlen leider die ganzen Steuersignale, d.h. wenn man so etwas macht dann bedarf es einen großen Aufwand beim Einbau. z.b. Busanpassungs IC`s und Pals auslöten.
-
Die 50Mhz 030 Karte von GE-Soft oder auch die Idee eine CT60 für den Atari TT anzubieten beschränkt sich auch die DaughterBoard Version vom Atari TT. Ohne das DaughterBoard hat der Rechner keinerlei Bussteuerung für den 32Mhz Beschleuniger ...
-
JA das ist leider das Problem, wobei es nicht unmöglich ist. Die benötigten Bussteuersignale kann man an den 4 Flipflops und den beiden Pals abgreifen die für die Bustaktanpassung zuständig sind, weil genau diese IC´s steuern die STeuersignale 16/32Mhz.
Aktuell läuft mein TT mit 20/40 Mhz Stabil, bei 24/48Mhz bekomme ich Bildschirmprobleme, wo ich jetzt schauen muss wie ich das Timingproblem gelöst bekomme. Da ich ja schon 60ns Rams als ST Rams danke Frank drin habe sollte es nicht an der Ram Geschwindigkeit liegen.
-
20/40 Mhz hätte ich jetzt nicht für möglich gehalten. Was für ein Videosignal/Auflösung hämmert der denn dabei raus?
-
640x480@75hz
-
20Mhz Bus und 40Mhz CPU ist doch schon mal was ...
-
Für die Neugierigen (Referenz ist ein Standart TT)
-
Nicht gerade die Welt aber schon gut.
Ich hoffe das ganze geht nicht auf die Lebensdauer der Logik Bausteine ...
-
Werden nicht wärmer, obwohl richtig gestresst den Rechner
-
Was passiert bei dem Takt mit VME-KArten, z.B. der NOVA?
Funktioniert ACSI noch?
Und wie aufwändig ist der Umbau?
-
Nova Funktioniert noch, bekommt sogar nochmal einen richtigen boost dadurch. Und ja klar warum soll SCSI und ACSI nicht mehr funzen ?
Was ich wie und wann zur Verfügung stelle im bezug auf umbau das muß ich noch sehen. Aktuell ist es noch lange nicht Altagsreif.
-
Für die Neugierigen (Referenz ist ein Standart TT)
Cooooool!
-
Bei SCSI mache ich mir weniger Gedanken, aber ACSI solltest du nochmal näher checken, insbesondere mit - wenns geht - einer SH204/205, Megafile 20-60. Uhd bleibt das Midi-Timing gleich?
-
@tuxie: Wie schnell sind denn die ROMs die Du derzeit einsetzt?
Ich habe hier FlashRoms mit 55ns, da brauchst Du zwar Adapterplatinen weil die in PLCC sind, aber ein versuch wäre es wert, oder?
-
Ohne Kommentar ;)
-
Das sieht aus wie 25 Mhz...
Oben schriebst du dass bei 20 Mhz Bustakt die Videorefresh-Rate bei 75 Hz liegt, wo liegt sie jetzt, und welcher TFT schafft solch hohen Refreshraten? 90 Hz? (Meine NECs machen ab 70 Hz dicht.)
-
Vergleich mal die integer werte, der beiden Ergebnis, da wirst du sehen das es Immernoch 20/40 ist. Nur mit jede Menge Optimierungen, das soll aber nicht das Ende sein. ;)
-
Mit Nova 1024x768x64k
-
Der hohe Disk-Wert verdankt sich wohl dem Donnerwetter?
Und die FPU hast Du auf 50MHz getaktet?
Aber wie hast Du den ROM-Zugriff so stark beschleunigt?
Etwas irritiert bin ich davon, daß die CPU mit 48MHz nicht deutlich mehr Power haben soll als mit 40MHz - ein Meß-Fehler? Ich hatte mir am 28.10.16 zu Kronos notiert:
"Zwischen den Versionen 2.00 & 2.02 gibt es Unterschiede in der Auswertung der Tests. Die .ABH (ibs. die Defaults) wurden aber keineswegs wiederholt, sodaß die angestrebte Vergleichbarkeit der Ergebnisse verfehlt wird! Falls dergleichen auch früher schon vorkam (was ja befürchtet werden muß), gilt das dann eigtl. für alle ABH ..."
-
Das ganze ist ganz einfach, der Cattamaran erhöht nicht wirklich den Takt der CPU, das geschieht nur solange nur intern Rechenoperationen ausgeführt werden wo der Bus nicht angegriffen wird. Egal wohin. Und da Kronos wohl viel mit dem Ram Arbeitet bin ich dort schneller. Und warum der Rom so schnell ist, ist unser Geheimnis ;) und nein es ist nicht ins Ram kopiert. Bin mit dem IDE Interface jetzt bei 6,5MB/s . Nie wieder ohne IDE, da kackt SCSI und ACSI voll ab dagegen. Also gerade Anwendungen Starten, das geht so schnell das man es eigentlich nicht messen kann. Gembench ist unter 1s gestartet. Kronos ist auch sehr schnell gestartet, kann gern mal ein Video machen wie das ganze aussieht.
-
Werte der CF und Speicherdurchsatz
-
Da müsst ihr aber auch eine einbaufertige Erweiterung rausbringen.
-
Müssen tuen wir gar nix.... wenn dann können wir ;)
-
"Einbaufertig" ist auch so eine Sache.
-
Ich dachte an ein kleines Platinchen mit einer Menge Drähte zum Einbau,, so was in der Art ...
-
Wenn wir mit der Basisentwicklung fertig sind, werden wir darüber nachdenken wie wir optimal eine oder mehrere Platinen fertigen werden. Aber aktuell sind wir noch voll in der Entwicklung und das was wir als ergebniss habe ist noch nicht das ende. Da geht nochwas aber es braucht halt Zeit da wir das alle in unserer Freizeit machen...
-
"Zwischen den Versionen 2.00 & 2.02 gibt es Unterschiede in der Auswertung der Tests. Die .ABH (ibs. die Defaults) wurden aber keineswegs wiederholt, sodaß die angestrebte Vergleichbarkeit der Ergebnisse verfehlt wird! Falls dergleichen auch früher schon vorkam (was ja befürchtet werden muß), gilt das dann eigtl. für alle ABH ..."
Zitat aus den changelogs:
KRONOS Atari Bench 2.02
Last update : January 28 2012
New in 2.02 (november 2010)
- More video card recognized
- Better coldfire support
News in 2.01
- Fix some cookies informations errors
- Detection of CaTTamaran accelerator card
- Now Mo results are conform to international definition (10^6 bytes) while previously this was 2^20 bytes (1048576) => results are now around 4,8% higher than with previous version.
-
^^-- Da hast Du ja sogar mehr Info als ich. Mir war bloß aufgefallen, daß die Referenz TT48_32k.ABH, 2256B. das Datum 18.10.10 trägt, deshalb hatte ich, wenn ich mich recht erinnere*, schon mal vorgeschlagen, daß diese Referenz-Messung zu wiederholen sei.
Die 4,8% sind ja wohl ein Durchschnittswert? Ich würde, entgegen Deinem og. Argument, erwarten, daß der CPU-Meßwert von Kronos für den CaTTamaran um ~20% höher läge; Begründung: Wenn man´s richtig macht, müßte das mit Schleifen passieren, die _ganz_ im Proz.Cache liegen. Allerdings weiß ich nicht, ob/wie man das erzwingen kann; bei meinen diesbezgl. Versuchen habe ich lediglich durch Umordnungen im Code das mehr oder weniger zufällig hinbekommen, und ich vermute, dem Kronos ging´s nicht anders (und dem GB6 erst recht).
Merke: Benchmarking einer modernen CPU ist nicht-trivial.
* Gedächtnislücken? Kann mich nicht erinnern, je welche gehabt zu haben...