[Sammelthread] NostalgieDeluxx Quatschthread

Du könntest aber auch noch mit einer dünnen Nadel versuchen, vorsichtig die verlöteten Beinchen vom IC anzustupsen. Manchmal muss ein IC aus der Zeit einfach mal wieder reflowed werden. Ist bei z.B. den Voodoo-Karten gar nicht mal so unüblich.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich mein damit, gegen jede Lötstelle vom IC vorsichtig drücken. Wenn sich das Beinchen bewegt, ist das Lot schon brüchig.
 
Es gibt hauchdünne Graphitplättchen für die Kontaktflächen l. Zumindest gab es die zu meiner Lehrzeit. Reflowen könnte ich dir das. Die Plättchen muss ich noch irgendwo haben. Aber wo... Aber wird den Aufwand mit dem verschicken eh nicht wert sein.
 
Gab es zum Asrock AM2NF3 ein Pendant mit nF4 Chipsatz? Ich finde da nur nF5 und nF6 und so etwas.

MSI hatte für S939 ja die K8N Neo2 und Neo4

edit: hat sich erledigt, das wird und Geforce6100 gelistet ... AM2NF4G, AM2NF6G und co.
 
Ich habe offensichtlich ein falsches BIOS bei einem T400 erwischt - war für mich nicht ersichtlich

Ich versuche mich gerade an dem hier : https://thinkwiki.de/BIOS

Das doofe ist nur, das es auch hier zwei gibt

1716030954230.png


Ich nehme mal die niedrigere Nummer
 
Wie kommt man auf diesen Wert?
FP32 (float): 44.86 GFLOPS

Die theoretische peak Performance für FLOPS (alternativ bei WikiChips) setzt sich zusammen aus dem Kerntakt, der Anzahl möglicher Instruktionen des gewünschten Typs pro Takt (in dem Fall 32Bit floating point) und der Anzahl paralleler Einheiten.

Die 44,86GFLOPS müssten also aus den 589*10^6Hz Kerntakt * Anzahl FP Instruktionen pro Cycle * Anzahl der Recheneinheiten für die FP Ops entstehen. Letztere dürften die 16 Shader sein.
Das käme meiner Rechnung nach dann auf 44,86*10^9 FLOPS / 589*10^6 Hz / 16 Streamprozessoren =~ 4,76FLOPS pro Cycle, da passt irgendwas bei mir noch nicht, für einen theoretischen Wert sollte es glatt aufgehen. Ist ein paar Jahre her, dass ich sowas ausrechnen durfte, aber ungefähr der Weg müsste es sein.
 
Das käme meiner Rechnung nach dann auf 44,86*10^9 FLOPS / 589*10^6 Hz / 16 Streamprozessoren =~ 4,76FLOPS pro Cycle
Achtung, die Nvidia Karten hatten in einigen Generationen einen höheren Shader Takt. Die GT 310 hat 589Mhz GPU Takt, aber die Shader laufen bei 1400Mhz. Nun wird es etwas komplizierter... Die Tesla Architektur ist folgendermaßen aufgebaut (links G92, rechts GT200):

1716096870896.png

Quelle: https://www.anandtech.com/show/2549/2

Laut Anandtech (siehe Link) kann jeder SP eine FP32 Operation ausführen und zusätzlich gibt es noch die SFU Einheiten die je 4 FP Operationen durchführen können. Pro SM Block kämen wir so auf 16 FP Operationen, zumindest wenn ich das richtig verstanden habe.

Jetzt schlagen wir den Bogen zum GT310:
1400Mhz Shadertakt, 2 SM (damit 32 FP Operationen): 1400Mhz * 32 Ops/Takt = 44,8 GFLOPS
 
Ich habe begonnen das gekaufte Konvolut an Laptops zu Sichten. Man meinte 2/3 sind nicht ok - werden wohl 75% sein, nach dem ersten anschauen.

Die Netzteile habe ich schon fast durch

1716120181798.jpeg
 
ACER Extensa 5630EZ - funktioniert auch noch

mit gebogener Tastatur

1716191169266.jpeg



Dem habe ich sogar eine SSD verpasst, da der HDD Caddy fehlt

Da sind jetzt doch mehr noch OK, als gedacht (y)

Jetzt gehen mir aber die gebrauchten SATA HDD`s zum Testinstallieren aus. (n):unsure::cry:
 
Hat jemand ein sehr gutes Retroauge und kann mir sagen was das für eine Grafikkarte ist?

1716251401090.png


Ein besseres Bild habe ich leider nicht. Ich weiß dass ich damals eine Radeon 9800 gekauft habe, aber leider nicht mehr welche Version.

Ungewöhnlich finde ich die Position des Floppyanschlusses, den kenne ich eigentlich nur am hinteren Ende der Karte.
 
Aufgrund der Position des Floppy Stromsteckers hätte ich 9800 jetzt auch ausgeschlossen.
Kurze Google Suche gibt mir eine 9500 Pro, deren PCB scheint exakt zu passen.

Paar Bildbeispiele:

Hier ist auch die Rückseite zu sehen:

Edit:
Mir fiel grad noch die 9800SE ein, kurzer Check ergab, da gab es wohl Modelle, die auf dem 9500 Pro PCB basierten
Das scheint dann ohne weiteres nicht zu 100% feststellbar zu sein.

Etwas nach unten scrollen in dem Beitrag, da ist die Sapphire Atlantis 9800SE mit 9500Pro PCB zu sehen.

Hier noch eine PowerColor, leider kein Bild der Rückseite:

Und nochmal bei ixbt mit Fotos der Rückseiten von 9800SE und 9500Pro .
Der einzige Unterschied, den ich auf den beiden Bildern erkenne und auch auf anderen bei Google sehe, ist,
dass das Bauteil mittig zwischen RAM und GPU (bei den ixbt Bildern rechts des FCC Compliance Logos) bei der 9800SE gelb und der 9500Pro schwarz ist.
Scheint mir aber gewagt als Anhaltspunkt ...
 
Zuletzt bearbeitet:
Hätte ebenfalls sofort auf 9500pro getippt, diese Karte hatte ich damals auch
 
Warum? Es gab non-Ref Designs, die genau so aussahen.

Das hier ist z.B. auch eine 9800 Pro:
nicht nur das, es war auch eine zeitlang so, dass 9500 und 9500 pro auf der identischen Platine wie die 9700Pro und 9700 waren.

Ich habe aus dieser Zeit noch mein Fläschchen Silberleitlack liegen, weil man die ersten 9500 mit Glück zur 9700Pro freischalten konnte.

Die PCB Layouts erlaubten, wenn identisch, das breite Speicherinterface freizuschalten und so eine 9500 im besten Fall zur 9700pro zu machen. Gelang in den wenigsten Fällen, aber eine 9700 non pro war oft drin.

Später hat ATI dann das Layout der 9500 geändert, so dass auf der 9500 Platine das breitere Speicherinterface nicht mehr möglich war.

Wilde Zeit damals. Meine Gigabyte Maya 9500 pro suche ich heute immer noch ... nie wieder eine gesehen bei EKA
 
Das PCB Design als 9800 Pro wär mir bis dato nie begegnet, aber gut, das ändert nichts daran,
dass die Frage sich von der schlichten Kartenrückseite wohl kaum beantworten lässt, wenn am Ende jeder Chip drauf sein kann.
 
Danke euch allen für den Input! Also meinem Gedächtnis nach habe ich damals im Atitool den R350 gesehen, was ja der 9800 SE entspräche.

Dann passt das ja zu dem wie ich mich erinnert habe :)
 
Also meinem Gedächtnis nach habe ich damals im Atitool den R350 gesehen, was ja der 9800 SE entspräche.

Am Chip selbst kannst du das nicht festmachen. Mit Ausnahme der 9800 XT und XXL (exklusiv R360) haben alle anderen 9800er ebenfalls auf den R350 gesetzt, egal ob SE, Pro, XL usw... Mal mehr, mal weniger beschnitten. Es gab im späteren Produktionsverlauf auch 9800 non-XT/XXL die mit R360 bestückt waren, Resteverwertung halt. Aber R350 ansich ist weiterhin ein "Nahezu alles ist möglich"-Faktor ;)
 
Bei mir steht demnächst mal wieder Mouser an - braucht Jemand was?
ja, muss hier noch den Rest fürs A8N SLI Premium machen, Zettel liegt noch hier
Beitrag automatisch zusammengeführt:

Ja, aber Board ist noch unterwegs. Müsste nen Recap bei einem A8N-SLI Premium machen.
ich kann dir ne Liste empfehlen, aber ... die Boards sind nicht immer 100% gleich bestückt,
können wie bei mir auch mal 2 St. von einigen Elkos mehr verbaut sein

Kannst dich hieran orientieren, A8N -SLI von Keeel


aber unbedingt gelb nachzählen. Bei mir sind 23 St. verbaut auf dem Premium
 
Zuletzt bearbeitet:
Bin mir nicht ganz sicher, wo ich das mal erwähnen soll, deshalb melde ich mich hier.
Okay, ggf. passt es auch dort ... aber ich bleib erstmal in der Komfortzone.

TLDR: Überlegung, wie man ggf. ein paar der Bildinhalte aus Sammelthreads für die Zeit nach dem abload Aus bewahren könnte ohne x-hundert Links manuell zu bearbeiten.

Wir hatten ja schon wiederholt und an verschiedenen Ecken das Thema, dass abload zum 30.06. seinen Dienst einstellt.
Für einen selbst bzw. Nutzer mit Account haben sie ja auf ihrer Seite auch dankbarerweise einfache Methoden gelistet, sich seine ganzen Bilder herunterzuladen.
Das ist zwar gut für einen selbst, aber für Ressourcen wie das Forum mit teils umfangreichen Datenbanken nicht optimal.

Als Verfechter von RAM-OC denke ich da z.B. an große OC-Listen, die auch verschiedene Migrationsschritte im Forum überlebt haben, aber z.T. randvoll sind mit abload links.
Beispiele wären da für mich die große 32M-Liste im Speicher Unterforum oder die DDR1 OC Liste hier im Nostalgiebereich.

Viele Nutzer sind nichtmehr aktiv oder haben ggf. die Screenshots nichtmehr, dennoch sind viele, wenn auch nicht alle, der Bilder momentan noch online. Um solange es noch geht an der Stelle vielleicht zu versuchen, wenigstens einen Teil dieser Datenbanken zu retten, hab ich mir anhand meiner zwei Beispiele mal etwas Gedanken gemacht und rumprobiert.

Im Ergebnis kam ich jetzt auf folgenden Weg, mit dem Ziel die gleiche Linkliste, wie abload sie den eigenen Usern bereitstellt threadspezifisch zu erzeugen.
1. Seitenquellcode bzw. den Startpost des Threads als .txt ziehen
2. Ein kleines Python Skript, dass die .txt abfrühstückt und abload Links rauszieht, die dabei punktuell etwas hübsch macht und als duplikatfreie Linkliste auswirft
3. Mit dem Windows cmd Befehl, den auch abload für die eigenen Bilder vorschlägt, die Liste via curl Befehl abarbeiten und die Bilder runterladen
es fehlen die Schritte ab 4, um die Bilder wieder im Forum hochzuladen und einzufügen, aber um das Problem kann man sich auch nach dem 30.06. noch kümmern.

Die Bilder haben nach dem Download denselben Namen wie im ursprünglichen abload Link, dadurch hätte man ein eindeutiges Mapping auf die ab 01.07. toten Links in den Sammelthreads. So wäre also immerhin die Relation von Bild zu Listeneintrag auch über die Abschaltung von abload hinaus erhalten, ob und wie man den Reupload / Linkaustausch dann formschön realisiert / automatisiert bekommt, kann man sich dann immernoch in Ruhe überlegen.

Um es mal an meinen zwei Beispielthreads zu verdeutlichen:
Für die 32M OC-Liste kam ich auf 3210 Links auf der ersten Seite des Threads, nach Download hab ich nun 3086 Bilder im Verzeichnis.
Vorbehaltlich anderer Probleme/Fehler wird die Diskrepanz wohl einfach gelöscht sein, legen jedenfalls Stichproben nahe.

Für die DDR1 IC SuperPi Liste kam ich auf 202 Links, nach Download sind es 201 Bilder, nur eins war nichtmehr online.

Fakt ist, man kann nicht alles retten. Der Aufwand stünde wohl auch in keinem Verhältnis zum Ergebnis, deshalb hab ich mich bei dem Gedankengang bewusst mal auf Sammelthreads mit größeren Listen bezogen, da die nötigen Informationen nicht auf 200 Seiten in Beiträgen von 300 Usern verteilt sind, sondern schon stark gebündelt und meist in einheitlicher Struktur, was nicht nur das Erfassen sondern auch ein ggf. späteres Aktualisieren deutlich erleichtern sollte.

Soweit mal zu meiner Überlegung und meinen Experimenten. Ich bin sicher, meine hingefrickelte Skriptlösung treibt ernsthaften Entwicklern Tränen in die Augen und technisch gibt es garantiert einfachere Wege, die ich nur grad nicht kenne / sehe / etc. , falls Bedarf besteht werf ich das Skript aber auch noch hier rein. Ich bin leider den gesamten Juni über noch ziemlich ausgebucht, aber da der Termin für das Ende von abload nunmal steht und mir das heute Nacht beim Blick in alte 32M Ergebnisse wieder bewusst wurde, wollte ich zumindest mal testen, ob man da nicht doch was retten kann.

Dem ein oder anderen fallen vielleicht auch noch andere Sammelthreads mit derartigen Listen ein, die erhaltenswert wären.
Da viele der Listen auch von Mods wie @stunned_guy und @emissary42 gepflegt werden, gibt es eventuell auch elegantere Optionen die Threads zu parsen.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh