Ich nehme mal an das die 040 und 060 ein gemeinsames Projekt ist?!
Verfügbarkeit neuer TK´s in 2021: ACA1234 , ACA1240 , ACA1260 ?
- claus71
- Thread is Unresolved
Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.
Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.
Don't Panic. Please wash hands.
-
-
Ja, das ist die gleiche Hardware, sie erkennt ohne Jumper den CPU-Typen und stellt automatisch die richtige Spannung ein.
-
Hi!
Als ich verzweifelt damit beschäftigt war lauffähige RAM module für meine Apollo 1240/40 Auszuprobieren habe ich mich daran erinnert dass ihr da ja was schönes in mache habt!
Wie schaut es denn mit den Karten aus? Gibt es schon einen aktuellen angepeilten Termin?
Welche Preisregion ist denn so ca angepeilt? (040/max Takt, mit fpu und mmu)
Es steht ja im Raum die 040 etwas zu übertakten, gibt es da schon Erfahrungen für vertretbare Taktungen?
Ausstattung wie die 030 Karten nur ohne CF Slot, dafür mehr RAM?
Grüße!
-
Wie schaut es denn mit den Karten aus? Gibt es schon einen aktuellen angepeilten Termin?
Wir sind seit ein paar Wochen wieder dran und haben auch schon die schwersten Bugs gefixt. Ich bin sehr guter Dinge, dass wir es ins Weihnachtsgeschäft 2022 schaffen werden, und es gibt auch eine Chance, dass wir für die Amiga37 im Oktober (Mönchengladbach) zeigen können, wie viel schneller unsere Karte im Vergleich zu den 1990er Karten ist. Im Moment sind die Fortschritte sehr ermutigend - sowohl für Peter, als auch für mich. Das ist so ein positiver-feedback-Effekt: Jeder Erfolg steigert die Motivation und man hat mehr Energie für die nächsten Schritte.
Welche Preisregion ist denn so ca angepeilt? (040/max Takt, mit fpu und mmu)
Am besten wäre, wenn ich gar nicht rechnen würde. Das Projekt hat am 14.1.2015 begonnen, und wurde immer wieder unterbrochen, verändert, erweitert, wieder verändert und jedes Mal gab es einen neuen Prototypen, der mit Entwicklungskosten immer locker der Preis eines Kleinwagens erreicht hat. Im Moment sind wir bei Prototyp#4 und es ist schon klar, dass wir einen weiteren Prototypen bauen müssen. Bevor ich das aber mache, gibt es noch kleinere Prototypen von Baugruppen, die einzeln geprüft werden können (unit testing auf Hardwareebene). Kurz: Der angepeilte Preis von "ca. 500 EUR für die 68040/25 Variante" wird höchst wahrscheinlich ein Verlustgeschäft. Aber immer noch besser als auf Bauteilen sitzen zu bleiben, die wir seit mehr als zehn Jahren immer wieder nachgekauft haben.
Es steht ja im Raum die 040 etwas zu übertakten, gibt es da schon Erfahrungen für vertretbare Taktungen?
Ja - je nach Maske kann sogar die 25MHz-Version bis 40MHz laufen. Wir haben schließlich eine geregelte, aktive Kühlung mit Temperatursensor, Drehzahlfühler und Drehzahlregelung. Die Performance die von Sysinfo angezeigt wird, ist kaum verändert gegenüber den 1900er Karten, aber in der Praxis (Demos, große Projekte compilieren/assemblieren, große Archive packen/entpacken) zeigt sich, dass schneller Speicher mit sehr geschickter Row-open/refresh Strategie massive Vorteile bringt. Es steht jetzt schon fest, dass jede Karte ohne Änderung der Hardware auf jeder Frequenz laufen können wird. Grenzen setzt lediglich die Lizenz, genau wie bei der ACA1234: Wer seine eigene CPU installieren will, die dann schneller läuft als das, was bei uns bezahlt wurde, muss eine Lizenz dafür kaufen.
Ausstattung wie die 030 Karten nur ohne CF Slot, dafür mehr RAM?
Ich hatte ja vor ein paar Tagen auf Twitter ein Bild aus der Entwicklung veröffentlicht, bei dem kaum jemand reagiert hat. Da war schon ein bisschen was zu sehen von Dingen, die wir noch nicht bestätigt haben - letztlich weil sie nicht komplett verifiziert sind.
-
Schön, daß es bei euch voran geht, gesundheitlich und technisch!
Ich wußte, gar nicht, daß ihr bei Twitter seit.
Second Level Cache höre ich im Amigakontext zum ersten Mal.
Nach etwas Recherche hatte CS MK1 so einen.Warum hat man den danach wieder weggelassen?
Was bringt der 2nd Level cache? -
Ich wußte, gar nicht, daß ihr bei Twitter seit.
Das ist mein privater account - Du siehst dort ab und zu auch mal ein politisches Statement, was man von einem Firmenaccount nicht unbedingt erwarten würde. Und da ich immer noch kein Profilbild habe, behandelt mich Twitter wohl auch wie einen Bot-Account. Also.. einen von den weniger als 5%.. hust..
Second Level Cache höre ich im Amigakontext zum ersten Mal.
Nach etwas Recherche hatte CS MK1 so einen.Warum hat man den danach wieder weggelassen?
Damals war das noch ziemlich teuer - und ob die CS MK1 wirklich 2nd level cache hatte, wage ich zu bezweifeln. Man liest, dass das CPU-Board den "optional" hatte, aber gesehen habe ich so ein Board noch nicht. Damals wie heute müsste ein externer Cache seinen eigenen Cache controller haben, der natürlich Zeit braucht um festzustellen, ob ein Datenwort im Cache liegt oder nicht.
Allein auf der Basis habe ich die Aussage gemacht, dass die Strategie "Rows offen halten" schneller ist, weil ich einfach nie die Entscheidung treffen muss, sondern die Row erst schließe, wenn sie im Konflikt steht mit einer anderen Row, die jetzt geöffnet werden muss. Da das schließen im eigentlichen Zugriff "untergeht", kann ich für den kompletten Vorgang - also cache-Vergleich, Cache füllen und Abholen aus dem Cache - null Zeit annehmen. Null ist immer weniger als "etwas".Ich tippe also darauf, dass man in den 1990ern den Cache *immer* weggelassen hat, weil es einfach zu teuer war und man im Vergleich zu wenig Gewinn bekommen hätte. Heute ist das anders - der große FPGA kostet (wenn nicht gerade Chip-a-geddon ist) vielleicht 1,- EUR mehr, hat dafür aber locker doppelt so viel Speicher. Den verwenden wir jetzt für was Anderes
(sind nur ein paar kBytes).
Was bringt der 2nd Level cache?
Ich beantworte das mal mit Blick auf unseren SD-Ram Controller: Der Zugriff erfolgt immer in zwei Schritten, denn der Speicher ist wie eine Tabelle organisiert: Erst muss die Row geöffnet werden, dann wird im zweiten Schritt auf die Spalte zugegriffen. Das Öffnen der Row kostet mehr Zeit als das Ansprechen der Spalte. Ist die Row schon offen, kann ich sehr viel schneller (ca. Faktor 3) auf die Spalten zugreifen, wobei Lesen oder Schreiben gleich behandelt werden kann.
Die einfache Antwort ist also: Es bringt mehr Leistung bei gleichem Takt.
Das geht übrigens _nur_ mit SDR (single data rate) SD-Ram. Es geht nicht mit DDR-Speicher, weil dort nicht so dynamisch zwischen Row- und Column Kommandos gewechselt werden darf. Man ist also mit DDR-Speicher quasi gezwungen, den "langsamen" Weg zu gehen, wirklich einen 2nd level Cache zu machen - und braucht dann einen noch teureren FPGA, wenn man diesen Verlust verstecken will. Weniger ist manchmal mehr.
-
Die Steckleiste auf der dem Mainboardanschluss gegenüberliegenden Seite dürfte wohl der Diagnoseanschluss sein aber ist das das ein (Micro)SD Steckplatz?
Das mit den Kosten und dem Verkaufspreis ist der Fluch der Kleinserie.
Klingt auf jeden Fall schonmal sehr gut. Wobei mir Zuverlässigkeit und Stabilität wichtiger sind als die reine Leistung, auch wenn ich zu mehr Speed nicht nein sagen würde...
Wie gesagt, ich habe derzeit u.a. eine Apollo 1240/40 Karte, die, trotz des alten Designs, der CPU sei Dank noch immer zu den schnellsten Karten für den A1200 gehört. Die hatte halt auch meine ppc Karte, vor dem Umbau auf 060, bei 68k Aufgaben alt aussehen lassen.
Das einzige was mich derzeit so richtig nervt ist das Thema Arbeitsspeicher. Ich hab juste erst ein Drama in X Akten hinter mir, mit rumprobieren und Kontakte reinigen hinter mir im endlich wieder Module auf der Karte zu haben die diese auch akzeptiert. Hängen geblieben bin ich da nicht einmal bei den maximal möglichen 32mb sondern nur bei 16mb und habe schon Bammel das irgendwann die Karte wieder zickt oder das Modul krepiert! Immerhin werden Karte und PS/2 Module nicht mehr jünger.
Das ist für mich der wichtigste Punkt für den ich Abhilfe erhoffe. Wenn sie Geschwindigkeit, besonders bei chipram Zugriffen, noch flotter werden sollte... Gerne aber das steht bei meinen Wünschen nicht auf dem ersten Platz.
Im Prinzip ist mit gestern als morgen lieber, allerdings wäre Weihnachten auch besser, habe ich noch etwas Zeit Geld beiseite zu schaffen...
Mich würden evtl Frequenzen oberhalb der 40Mhz interessierten, auch wenn das wohl eh eher unsinnig sein dürfte.
Gerade die Tage bin ich über ein Video bei yt gestolpert in dem ein Mac Fan eine 25mhz(glaube ich zumindest, gab es überhaupt Macs mit mehr?) testweise übertaktet hat, 45mhz ging bei seinem Exemplar wohl noch, bei 50 startete der Rechner nichtmehr.
PS: sry wenn etwas unklar oder merkwürdig formuliert sein sollte, Nachtschicht...
-
Die Steckleiste auf der dem Mainboardanschluss gegenüberliegenden Seite dürfte wohl der Diagnoseanschluss sein
Das ist ein JTAG - darüber werden der CPLD und der FPGA programmiert.
aber ist das das ein (Micro)SD Steckplatz?
Ja, aber der gehört zu den Dingen, die noch nicht komplett verifiziert worden sind. Wir nutzen erstmals den 4-Bit Mode der SD-Karte, was eigentlich kein Hexenwerk ist, aber eben auf volle Funktion überprüft werden muss. Im SPI-Mode (also 1-bit serielle Übertragung) wäre die Performance nicht viel besser als der unbeschleunigte, interne IDE. Es wäre "nicht von dieser Welt", wenn wir den IDE schneller machen könnten, als den lokalen Massenspeicher
(ja, die ACA1240/1260 bekommt natürlich auch den IDE-Speeder).
Wobei mir Zuverlässigkeit und Stabilität wichtiger sind als die reine Leistung, auch wenn ich zu mehr Speed nicht nein sagen würde...
Ich finde, dass diese CPUs ihrer Zeit ein wenig voraus waren: Sie wurden im Wesentlichen durch langsamen Speicher ausgebremst. Wie Du schon selbst festgestellt hast, ist die Apollo 1240-40 wirklich flott, denn sie kitzelt wirklich viel aus den alten 72-Pin SIMMs heraus (was das Auffinden kompatibler SIMMs nicht leichter macht).
Es ist aber nicht nur der Speicherdurchsatz, der "schnell" macht: Wenn man schon im Hardwaredesign dafür sorgt, dass bestimmte (besonders schnelle, weil kurze) Kommandos auch sehr schnell ausgeführt werden können, fallen auch die Wartezeiten für das Emulieren nicht-unterstützter Kommandos nicht so lang aus. Und wenn's in Richtung Chipram geht, haben wir gegenüber den 1990er Karten einfach den Vorteil, dass wir mit wesentlich besseren Werkzeugen arbeiten können: Wir haben eine Möglichkeit gefunden, selbst der langsamsten 68040 CPU die vollen 7MB/s aufs Chipram zu geben, was nichtmal die 40MHz-Version der Apollo 1240 schafft. Das kostet ein paar EUR mehr beim Interface in Richtung A1200, aber es bringt spürbar mehr Leistung, was sich bei Demos und Spielen sehr deutlich bemerkbar macht.
Das einzige was mich derzeit so richtig nervt ist das Thema Arbeitsspeicher. Ich hab juste erst ein Drama in X Akten hinter mir, mit rumprobieren und Kontakte reinigen hinter mir im endlich wieder Module auf der Karte zu haben die diese auch akzeptiert. Hängen geblieben bin ich da nicht einmal bei den maximal möglichen 32mb sondern nur bei 16mb und habe schon Bammel das irgendwann die Karte wieder zickt oder das Modul krepiert! Immerhin werden Karte und PS/2 Module nicht mehr jünger.
Apollo Turbokarten sind "by design" instabil. Die Designs sind voll von Metastabilitätsproblemen, aber dafür haben sie zwei Vorteile: Sie sind schneller als die damalige Konkurrenz und das Design passte in verhältnismäßig kleine Logikchips (Apollo 1240 nutzt zwei 64-Makrozellen CPLDs; einer im 44-Pin und der andere im 84-Pin Package). Wenn ich jetzt den Begriff "Metastabilität" hier erklären wollte, wäre meine Antwort viele Seiten lang. Vielleicht mache ich für die nächste Revision ein Seminar draus... die Kurzfassung ist: Apollo Turbokarten können nicht stabil laufen. Man kann nur die Absturzhäufigkeit reduzieren.
Das ist für mich der wichtigste Punkt für den ich Abhilfe erhoffe. Wenn sie Geschwindigkeit, besonders bei chipram Zugriffen, noch flotter werden sollte... Gerne aber das steht bei meinen Wünschen nicht auf dem ersten Platz.
Ich finde halt, dass man mit den heutigen Möglichkeiten auch alles 'rausholen sollte. Die CPUs werden mittlerweile in Gold aufgewogen (ja, sogar die 68040), und wer da die CPU unnötig ausbremst, der hat im übertragenen Sinne Blut an seinen Händen. Wir haben endlich die Chance, die Teile "artgerecht zu halten" - also machen wir das auch.
Mich würden evtl Frequenzen oberhalb der 40Mhz interessierten, auch wenn das wohl eh eher unsinnig sein dürfte.
Übertakten geht grundsätzlich (immerhin ist das Design auf 133MHz ausgelegt, inklusive der CPU), aber es gilt der Grundsatz "first make it work, then make it fast". Natürlich muss man von vornherein nach Flaschenhälsen gucken und diese eliminieren, aber das haben wir mit den vergangenen Prototypen schon hinter uns. Bei der Beschaltung der CPU haben wir auch noch ein paar Tricks im Ärmel, die für ein paar MHz extra sorgen können. Die Kühlung ist nicht umsonst so großzügig und aufwändig (mit extra Temperatursensor) ausgelegt.
Sämtliche Aspekte der Optimierung sind über Flash-Updates zu ändern. Wenn uns also später noch etwas einfallen sollte, was spürbar mehr Performance bringen könnte, können wir das über einfache Updates ins Feld ausrollen. Wir haben also - im Vergleich zu den Versuchen, 1990er Designs zu übertakten - die Möglichkeit, sämtliche Bauteile um die CPU herum innerhalb der Spezifikationen zu betreiben, und uns an die Besonderheiten anzupassen, die die CPU bei höherem Takt macht. Simples Beispiel: Ab einer bestimmten Frequenz sagt die CPU zwar schon, dass sie "jetzt" einen Zugriff macht, aber die Adresse auf die sie zugreifen möchte wird erst später auf dem Bus gültig. Jedes 1990er Design macht dann einfach die Grätsche, aber wir sagen unserem Speichercontroller dann einfach, dass er einen Takt später mit seinem Zugriff beginnen soll.
Und falls sich herausstellen sollte, dass irgendwas nicht stabil sein sollte, ist auch das mit einem Flash-Update zu fixen. Unsere Aufgabe im Moment ist es, die Teile des Designs auf Herz und Nieren zu prüfen, die NICHT über Flash-Updates zu fixen sind.
-
Also ist die Apollo sowas wie die F104G unter den Turbokarten...
Das mit dem finden von kompatiblen Simms kann ich so unterschreiben. Von den ganzen Modulen die ich habe nimmt die Karte nur ganz wenige an, bei den meisten bleibt der Screen Schwartz, bzw blinkt ab und zu rot auf.
Selbst bei denen die laufen wird das fastram an und an gar nicht erkannt (Rechner bootet, wird aber nur chipram angezeigt und benutzt)
Das die Karte und das RAM inzwischen ein paar Jährchen auf dem Buckel haben macht das nicht unbedingt besser...
Das Problem wird mit der Aca wohl definitiv erledigt sein.
Das was du über die Karte noch geschrieben hast macht mich darüber hinaus neugierig. Ich bin gespannt wie die sich im Einsatz macht, bzw ob ein Unterschied subjektiv spürbar sein wird.
-
Das die Karte und das RAM inzwischen ein paar Jährchen auf dem Buckel haben macht das nicht unbedingt besser...
Das könnte einfach an den MACH-Sockeln liegen - manchmal hilft es die Sockel zu entfernen und die MACHs direkt aufzulöten. Da die Chips recht heiß werden, geben sie nochmal extra-Stress auf die Sockel, die nicht gerade top-Qualität sind. Das ist aber auch nur ein geringes "plus" an Stabilität. Man verringert halt die Absturzwahrscheinlichkeit, aber lösen kann man's nur, wenn die komplette Logik neu gemacht wird.
Trotzdem - einen Versuch wäre es wert, allein damit Du eine Benchmark-Karte hast. Ich bekomme meine alte Apollo nicht mehr ans Laufen, weil der Akku komplett ausgelaufen ist; ich kann also nicht mehr benchmarken.
Das was du über die Karte noch geschrieben hast macht mich darüber hinaus neugierig. Ich bin gespannt wie die sich im Einsatz macht, bzw ob ein Unterschied subjektiv spürbar sein wird.
Da z.B. Sysinfo die Geschwindigkeit mit einer recht kleinen inneren Schleife misst, ist es dort nicht sichtbar: Da kann man bis auf wenige Punkte bei gleicher CPU-Frequenz das gleiche Ergebnis erwarten. Um Speichergeschwindigkeit wirklich in der Praxis zu demonstrieren bräuchte man "standardisierte" real-world Tests. Vielleicht ein open-source C-Compiler der sich selbst compiliert? Vorschläge willkommen!
Auch Demos die eine FPS-Anzeige haben wären sicher gut geeignet.
-
Da z.B. Sysinfo die Geschwindigkeit mit einer recht kleinen inneren Schleife misst, ist es dort nicht sichtbar:
also würde der 2nd Level Cache einen zweiten größeren Schleifenbereich erzeugen?
müßte man dafür Programme anpassen, um sie zu beschleunigen?oder ist er schon so groß, daß es für allermeisten Programme reicht?
Vorschläge willkommen!
ich weiß, ein Grauzonenbenchmark, aber mit schöner Vergleichsliste.
-
MACH-Sockel?
Im Juni habe ich etwas Urlaub, da kann ich evtl etwas an Benchmarks probieren, ausser AIBB, Sysinfo und Sysspeed kenne ich allerdings nichts. AIBB läuft allerdings nicht auf meiner 060 Karte.
Hat Quake1 nicht ne art fps counter funktion?btw: Laut SysInfo
Apollo1240/40
-Dry: 29606/ 30,9mips
BlizzardPPC mit 060/50
-Dry: 37386/ 39,02mips
Sysspeed habe ich bisher nur für die Blizzard
Bei der Apollo habe ich inzwischen zumindest 2-3 16mb Module de laufen, allerdings habe ich zwischendurch das der ganz normal bootet, allerdings dann kein fastRAM hat. Da ist aber auch ein mech Problem, also kontaktprobleme, nicht ausgeschlossen.Der Rechner befindet sioch noch im Aufbau und ist nicht fest aufgestellt, wird also öffters bewegt. Nach dem neu einlegen des Modul gehts ansich wieder.
-
also würde der 2nd Level Cache einen zweiten größeren Schleifenbereich erzeugen?
Nicht "erzeugen", aber "ermöglichen" - wenn die innere Schleife einer kritischen Operation größer wird als der Cache, wird es langsam, weil dann immer wieder Cache-Zeilen überschrieben werden, was Zeit kostet.
müßte man dafür Programme anpassen, um sie zu beschleunigen?
Nein, 2nd Level Cache würde (wenn man ihn denn implementieren würde) transparent funktionieren - es würde einfach alles schneller laufen. Genau so mit der ACA1240/1260, die mit dem "Rows offen halten" das Äquivalent zu 2nd Level Cache hat - nur ein wenig schneller.
oder ist er schon so groß, daß es für allermeisten Programme reicht?
Cache ist "technisch" nie groß genug, weil man immer von Wahrscheinlichkeiten spricht: Je mehr Software gleichzeitig läuft, desto mehr Cache-Zeilen werden statistisch immer wieder ersetzt - und dabei muss man immer wieder auf den "langsamen" externen Bus gehen und den Speichercontroller bemühen. Man kann natürlich einfach alles mit schnellem S-Ram ausstatten, aber dann bekommt man ein Platzproblem auf der Platine, und zusätzlich ein Geldproblem, weil S-Ram um Größenordnungen teurer ist als dynamischer Speicher, und in den Kapazitäten gar nicht verfügbar ist. Das ist also mehr eine akademische Überlegung - in der Praxis wird Cache deutlich kleiner ausgelegt, weil man ab einer gewissen Größe nur noch marginale Geschwindigkeitsvorteile erzielt.
Ein 68030 hat 256 Byte iCache und 256 Byte dCache, also sehr überschaubar. Wenn man das als Textdatei auswerten würde, wäre das ungefähr eine viertel Seite Text. Das klingt nach wenig, macht aber schon einen gewaltigen Unterschied in der Performance.
Ein 68040 hat schon 4kByte iCache und 4kByte dCache, also beide Caches 16 mal größer als beim 68030. Dieser Schritt hat schon massiven Performancegewinn gebracht, aber man würde nicht den gleichen Faktor an Beschleunigung bekommen, wenn man den Cache nochmal 16-mal größer macht. Hier hat Motorola also damals eine sinnvolle Größe ausgewählt, die den Prozessor zwar schnell, aber noch bezahlbar macht.
Die gleiche Aufgabe hat der Systemdesigner, der eine Karte bzw. ein Mainboard entwickelt: Ein externer Cache muss im sinnvollen Kosten/Nutzenverhältnis stehen, sonst bringt es nichts. Und hier spielt die aktuelle Technik uns in die Arme: Dadurch dass wir SD-Ram (und nicht DDR-Speicher) ausgewählt haben, haben wir sämtliche Freiheiten bei der Ansteuerung dieses Speichers: Wir können aus einem einfachen single-access noch während der Zugriff läuft einen random-Burst machen, solange der nächste Zugriff in der gleichen Row des Chips liegt, und das ist noch schneller als jeder Cache es sein kann. Im Vergleich dazu muss ein DDR-Speicher immer seine vorher (!) festgelegten Bursts abfahren, bis er den nächsten Zugriff machen kann.
Alles was ich damit sagen/erklären wollte war, dass wir mit dem augenscheinlich langsameren (single data rate) Speicher am Ende schneller sind, als double-data rate Speicher es je sein kann.
AIBB läuft allerdings nicht auf meiner 060 Karte.
Der Trick dabei ist, in den Tooltypes auf 68000-Code zurück zu gehen, dann läuft das auch.
btw: Laut SysInfo
Apollo1240/40
-Dry: 29606/ 30,9mips
BlizzardPPC mit 060/50
-Dry: 37386/ 39,02mips
Die Werte sind bekannt - und sie unterscheiden sich nur marginal von dem, was wir mit unseren Prototypen bisher erreicht haben. Aktuelle Werte (also vom Proto4-Board) habe ich gerade nicht griffbereit, aber möglicherweise können wir schon nächste Woche etwas dazu sagen.
Bei der Apollo habe ich inzwischen zumindest 2-3 16mb Module de laufen, allerdings habe ich zwischendurch das der ganz normal bootet, allerdings dann kein fastRAM hat. Da ist aber auch ein mech Problem, also kontaktprobleme, nicht ausgeschlossen.
Es hat eine Serie Apollo-Turbokarten (68030 und 68040) gegeben, bei denen die 72-Pol SIMM Sockel zu breit waren. Da musste man die Module genau mittig einsetzen, damit alle 72 Pins Kontakt haben. Wenn man das weiß, ist es ganz leicht die Module richtig einzusetzen, weil man dann einfach die beiden Pins am Rand anschaut und das Modul so seitlich verschiebt, dass die Kontakt haben. Alles dazwischen hat dann auch Kontakt. Vielleicht ist Deine Karte ja eine von denen?
Grundsätzlich solltest Du nach Modulen mit maximal 4 Chips suchen - und landest dann wahrscheinlich bei einem 4MB oder 8MB-Modul, nicht bei 16MB. Die 16MB-Module haben meist 8 Chips oder mehr, was die kritischen Signale zu sehr belastet und sie damit "noch kritischer" macht.
-
Die letzten Zeile für den Rechner sind unterwegs, sobald ich das Gehäuse schließen könnte werde ich mich weiter mit den Thema beschäftigen.
Weniger als 8mb dürften aber dann langsam schon eng werden, besonders wenn ich auch noch das Rom mappen will
Der Speedtest von sysinfo läuft wohl eh rein im CPU Cache, der lässt sich ja auch wunderbar von jit an der Nase rumführen.
Ich werde mich dann erstmal auf sysspeed und aibb konzentrierten.
Welche Tests, besonders bei aibb, wären von Interesse?
Der Benchmark den du verlinkt hast, ist der so lauffähig oder braucht man Lightwave dafür?
-
Welche Tests, besonders bei aibb, wären von Interesse?
Alles was mit Display zu tun hat (also Writepixel, TGTest, Line/Ellipsetest) und die speicherintensiven Dinger wie EmuTest, Sieve, Sort - obwohl ich auch nicht weiß, wie groß die inneren Schleifen sind. Es gibt aber auch schon AIBB-Module im Aminet - bevor Du Dir also Arbeit machst, sollten wir schauen was schon da ist.
-
-
man braucht Lightwave 3.5 dafür.
Flottes Googeln hat mir immerhin die Info gebracht, dass die Software auf 7 Disketten ausgeliefert wurde und ein Dongle hat. Ist das irgendwann freigegeben worden?
-
Nicht, daß ich wüßte. Lag wohl auch keine Cover-CD bei.
Ich hatte mal eine Lizenz und hatte sie für 500DM verkauft.
Sie war im Beifang eines A4000 mit CS MK1 060 für gesamt 1000DM.
Das waren noch Zeiten.
-
Ich habe NewTek mal angeschrieben (über die Lightwave 3D-Webseite). Mal sehen was zurück kommt
(Edit: Automatische Bestätigungen sind schon da, mit Ticketnummer und so).
-
Randinfo zum Jubibenchmark, diesen nur mit der 3.5 Version laufen lassen - die 5er Version liefert keine vergleichbaren Werte.
Die Kombination Chipmemspeed/Busboardanbindung/CPU Power lässt sich am besten mit Quake 1 AGA (timedemo) oder AlienBreed 3D2 AGA messen. Im WHD Tooltype kann ein FPS Counter aktiviert werden. AIBB liefert aber auch gute Werte die man mittels Module gut vergleichen kann.
-
