atari-home.de - Foren
Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet von: Lukas Frank am So 15.03.2020, 18:37:09
-
Habe eine PAM VME Ethernetkarte bei der mal die Leiterbahn von den +12V weggebrannt ist, vermutlich weil der DC/DC Wandler kaputt war. Habe alles Sichtbare Instandgesetzt und einen neuen DC/DC Wandler verbaut. Alle Bausteine geprüft und die sind in Ordnung. Man kann die Karte auch fehlerfrei ansprechen mit dem TUW TCP/IP Paket oder der PAM Testsoftware. Was nicht geht ist die Verbindung nach draussen auf das Netzwerk. Ich vermute da noch mehr durchgebrannte Verbindungen kann aber nichts sehen oder Messen.
Hat jemand einen Schaltplan einer beliebigen Netzwerkkarte z.B. ISA oder Atari Riebl mit einem AMD7990 - AMD 7992 Chipsatz ?
-
https://www.google.com/search?client=firefox-b-d&q=NIC+AMD7990+schematic
-
Die Datenblätter habe ich. Das Wiki ist ganz gut aber ansonsten nichts dabei ...
Edit: ... eine Amiga Karte ist incl. Schaltplan dabei aber damit kann ich nichts anfangen denke ich.
-
Mit Hilfe aus dem A2065_service_manual.PDF habe ich mal die Verbindungen der PAM zwischen dem AMD7990 und dem 7992 geprüft und die sind in Ordnung. Mit dem Rest aus dem PDF kann man da nichts anfangen weil auf der PAM es weitergeht mit einem UM9205 und für den BNC Anschluss einen DP8392N.
Schaue mir mal die Datenblätter an ob ich damit was anfangen kann ...
Der BNC Anschluss und der AUI gehen beide nicht. Da muss schon etwas zentrales sein?
Vielleicht wird ja jemand aus den Fehlern schlau und kann mir einen Tipp geben?
-
Sind doch keine Fehler da und alles in Ordnung? Oder nicht?
Bei den Jumpern habe ich keine Ahnung. Aber so wie das gesteckt ist müsste der BNC Anschluss aktiv sein, oder?
-
Treiber wird ohne Fehler geladen ...
p MiNT-Net TCP/IP 1.6 PL 1, q
½ 1993-1996 by Kay Roemer.
½ 1997-1999 by Torsten Lang.
½ 2000-2010 by Frank Naumann.
Loading interfaces:
AM7990: driver for PAMs EMega/VME (C) 1996, 1997, 1998 by T. Lang
AM7990: driver v1.2 (ple0) for PAMs EMega/VME (00:00:5B:E8:02:DD)
IP masquerading by Mario Becroft, 1999.
FTP masquerading support by Torsten Lang, 1999.
p xconout2 output catcher version 0.3 q
½ Jan 1 1995 by TeSche <itschere@techfak.uni-bielefeld.de>
½ 2000-2010 by Frank Naumann.
ifconfig -a ist auch gut bis natürlich auf die Output errors! Ein ping kann ich nicht aufrufen weil da gar nichts an Ausgaben kommt!
-
Ist lange her bei mir, aber ich hatte ähnliche Probleme und meine mich zu erinnern, dass es mit der MAC Adresse zu tun hat. Die muss korrekt gesetzt werden.
Schau mal auf den Aufkleber. Da steht 2.58 oder 2.5B, ich kann das nicht erkennen.
Dann musst Du die MAC auf 00:00:5B:E8:02:58 oder 00:00:5B:E8:02:5B setzen!
-
Da steht 258 meine ich. Müsste ja dann 00:00:5B:E8:02:58 sein. Aber wie stelle ich die Adresse?
Bei der Riebl kenne ich das, da gibt es ja auch ein Programm.
-
Da sind ja zwei KM62256 drauf. Wenn ich die auslese im Eprombrenner und dann nach 00:00:5B:E8:02:DD suche und das ändere in 00:00:5B:E8:02:58.
Kann das gehen?
In welchem Baustein ist die Hardwareadresse denn hinterlegt? Ich habe den Chipsatz mehrfach und bei der Fehlersuche hin und her gesteckt und weiss nicht was da original drauf gehört.
-
Wenn ich den AMD7992 tausche bleibt die MAC Adresse. Beim AMD7990 bleibt die MAC Adresse auch.
-
Bin zwar kein Experte was Netzwerk angeht, aber sollte das nicht wurscht sein? Wo auch immer die Adresse hinterlegt ist, der Baustein weiss wohl kaum was auf der Platine aufgedruckt ist...
-
Ich meine bei der Riebl ist es so das die aufgedruckte Adresse jedesmal neu gesetzt werden muss. Ansonsten läuft die Karte nicht. Steht auch so im lance.txt bei der MiNT 1-18 Version im XIF Ordner.
Über die PAM findet man nichts (ich) im Netz.
Wer kann mir die PAM Software geben?
-
Kann sein, dass das nur bei der Riebl so war. Ist zu lange her, allerdings habe ich bei meinen PAMs die MAC Adresse aufgeschrieben und auf das RAM aufgeklebt. Es folgt jedesmal dem Muster 00:00:5B:E8:0x:yz - und xyz entspricht der Notierung dem Aufkleber.
-
Vielen Dank für die Dateien aber die hatte ich schon. Da ist nichts dabei um die MAC Adresse zu setzen.
-
Anhand von dem Amiga Schaltplan habe ich mal alles rund um den AMD7992 geprüft und es ist alles richtig da.
Kann gut sein das es doch an der MAC Adresse liegt?
-
An der BNC Ausgangsseite ist auch alles in Ordnung ...
-
Glatt übersehen, da ist ein "error in receive buffer managment" ...
Aber keine Ahnung wo da das Problem liegt?
-
Ich denke mal die Karte hat irgendwelchen Speicher zur Pufferung der Pakete, vlt.liegt da was im argen?
-
Das einzige sind zwei 62256 SRAMs. Ich weiss aber nicht wie das funktioniert weil da ist glaube ich auch die MAC Adresse hinterlegt, keine Ahnung. Die TTL Bausteine rundherum sind glaube ich neu, weiss es aber nicht mehr. Seit ich das letzte Mal damit rumprobiert habe ist schon länger her. Da sind viele GALs und PALs drauf, wenn da was nicht in Ordnung ist kann je nichts mehr machen?
-
Habe mal die beiden SRAM Bausteine gemessen und A0-A13 plus /WE gehen auf zwei 574. A14 geht auf ein GAL. D0 -D7 gehen jeweils Baustein getrennt auf zwei 74F245.
A6 eines SRAM hatte keinen Kontakt. Habe beide A6 verbunden so wie alle anderen Adressen auch. Bei einer PAM Mega ST Bus Karte sind die auch verbunden.
Der Fehler bleibt aber unverändert bestehen.
Kombinierte Data/Adress Signale am AMD7990 gehen alle 16 Stück an zwei HCT646 oder 645, kann man nicht so genau lesen. Sind alle da.
-
Habe mir eine SysKonnect G16 ISA Ethernetkarte gekauft um den Chipsatz zu testen. Die Karte hat den gleichen AMD7990/7992 Chipsatz. Das Ding unter WIN95 ans laufen zu bekommen war ein Krampf aber jetzt läuft es. Die Jumperbelegung die man im Netz findet stimmt nicht und es gibt nur Treiber für Win 3 und Win95 und nichts für DOS und kein Testprogramm. Den BNC Anschluss habe ich noch nicht ans laufen bekommen, mal schauen ...
Habe noch eine PAM Mega ST Bus Karte. Das Lance Test Programm läuft ohne Fehler aber der MiNT lance.xif läuft nicht. Der MiNT Treiber zeigt an das er keine MAC Adresse finden kann, das lancetst.tos zeigt aber eine MAC Adresse an und beendet sich mit der Meldung "keine Fehler ...". Der MiNT lance.xif läuft wohl nur mit der VME Bus Karte. Ich habe alle ab 1.16 durchprobiert.
-
Wusste es nicht mehr genau aber habe jetzt den ganzen Chipsatz 74 Reihe gegen neue getauscht. Hatte das vor Jahren schon mal gemacht. Fehler bleibt aber bestehen. Ich weiss bei der Fehlermeldung nicht wo ich suchen muss. Ohne Schaltplan so gut wie unmöglich. Die 8bit Treiber/Buffer habe ich messen können, da ist alles zum AMD Chipsatz und zum VME Bus in Ordnung.
-
Ich schau mal ob ich noch ne PAM VME finde, dann kannst Du die als Referenz für die Messungen nehmen.
-
Hatte so gar Aufwand bei den 646 getrieben weil man die Bausteine in 24 DIL schmal nicht bekommt. Jeweils einmal mit Adapter rechts und einmal links. Ging sogar noch in den VME Bus rein von der Höhe her. Aber die alten waren in Ordnung ...
-
Habe mir eine SysKonnect G16 ISA Ethernetkarte gekauft um den Chipsatz zu testen. Die Karte hat den gleichen AMD7990/7992 Chipsatz. Das Ding unter WIN95 ans laufen zu bekommen war ein Krampf aber jetzt läuft es. Die Jumperbelegung die man im Netz findet stimmt nicht und es gibt nur Treiber für Win 3 und Win95 und nichts für DOS und kein Testprogramm.
Wäre super, wenn du die Jumperbelegung dann hier oder wo anders posten würdest für den nächsten, der danach sucht.
-
Jumperung SK-G16 ...
Passt auf die Standard Einstellungen von Win95 Treiber, DOS Treiber gibt es wohl nicht.
-
Habe jetzt eine funktionierende PAM VME von Idek und die Bestückung unterscheidet sich ...
Idek 74LS245 bei mir F245, Idek LS541 bei mir HC, Idek HC646 bei mir HCT, Idek HC 574 bei mir HCT
-
Ich weiss nicht wieso und warum aber meine Karte funktioniert jetzt, keine Ahnung !
Loading interfaces: (Idek)
AM7990: driver for PAMs EMega/VME (C) 1996, 1997, 1998 by T. Lang
AM7990: driver v1.2 (ple0) for PAMs EMega/VME (00:00:5B:E8:03:87)
IP masquerading by Mario Becroft, 1999.
FTP masquerading support by Torsten Lang, 1999.
Loading interfaces: (Frank)
AM7990: driver for PAMs EMega/VME (C) 1996, 1997, 1998 by T. Lang
AM7990: driver v1.2 (ple0) for PAMs EMega/VME (00:00:5B:E8:02:DD)
IP masquerading by Mario Becroft, 1999.
FTP masquerading support by Torsten Lang, 1999.
Bei der MAC Adresse ist die 00:00:5B:E8 immer und bei allen Karte gleich genau wie bei den RIEBL Karten auch. Meine Karte sollte am Ende 02:58 laut Aufkleber Beschriftung ist aber eine 02:DD ...
L A N C E S e l f t e s t
---------------------------
Selftest on Ethernet Interface located on ATARI Board
Testing installation of Ethernet Interface ... . . . . . . . . . . . . . . . ok.
Resetting LANCE ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ok.
Reading EEPROM ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ok.
Ethernet/IEEE 802.3 Node Address : 000001000200
Logical Address Filter : 0000000000000000
Initializing LANCE ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ok.
Starting LANCE ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ok.
Performing Internal Loopback ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ok.
Initializing LANCE ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ok.
Starting LANCE ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ok.
Performing External Loopback ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ok.
Test of Ethernet Interface completed. Everything ok!
LANCE stopped.
-
Ich verstehe die PAM Karte nicht. Das Teil funktionierte über zwei Tage und fiel heute wieder aus. Es kam beim lancetst.tos wieder die Fehlermeldung und es funktionierte unter MiNT auch nicht obwohl die bootmeldung einwandfrei aussah. Soweit alles normal.
Dann erst lancetst.tos laufen lassen, es kam die alte Fehlermeldung aber die Karte funktionierte dann unter MiNT wie die Tage davor ...
Nachdem die Karte unter MiNT lief beendet auch der lancetst.tos unter SingleTOS ohne Fehler ...
-
Wenigstens ein paar Grundlagen zu kennen wäre schon hilfreich, wenn man sowas analysieren bzw. reparieren will.
Bestückung: "HC" und High Speed CMOS ICs, die HCT High Speed CMOS mit TTL Pegeln. Das übrige Geraffel (F, LS) sind verschiedene TTL Varianten. Kann man alles bei den üblichen Quellen (z. B. Wikipedia) nachlesen. Da TTL und CMOS andere Bereiche für die High und Low Pegel haben kann man die nicht einfach wahllos mixen.
MAC-Adresse: Warum willst Du die ändern? Es gab ein paar verschiedene Ansätze bei den LANCE-basierten Karten, von "gar nicht gespeichert, muss der Treiber beisteuern" über "batteriegepuffertes SRAM" bis zu I2C EEPROMs (wobei bei einer der Karten in meinem Besitz, die ein Register hatten, um den I2C in Software realisieren zu können (da wurden also letztlich die Pegel auf dem Bus direkt im Register abgebildet) invertierte Pegel hatte. Beim Experimentieren hatte ich mir dann erstmal das EEPROM gelöscht ;-/
Die KM62256 sind lt. Google SRAMs. Die kannst Du natürlich ausbauen und in einen EEPROM-Brenner stecken, viel Information wird sich damit nicht gewinnen lassen.
Die MAC-Adresse (Achtung: Auch hier wieder für jedermann offen zugängliches Grundlagenwissen!) teilen sich in drei Bytes Herstellerkennung und drei Bytes Karten-Kennung. Bei großen Stückzahlen brauchte der Hersteller dann u. U. mehrere Hersteller-Kennungen. Relevant ist die Eindeutigkeit der MAC-Adresse nur im jeweiligen Netzwerk-Segment - letztlich bestimmt die MAC-Adresse, wer das Paket empfängt, über das ARP Protokoll wird eine Tabelle aufgebaut, die IP-Adressen den MAC-Adressen zuordnet. Die kann man sich mit "arp -a" auch anschauen. Sobald über höhere Protokolle geroutet wird spielt die Eindeutigkeit über die Netzwerkgrenzen hinweg keine Rolle mehr. Wenn ich also zwischen zwei physikalisch getrennten Netzen z. B. IP route kann die gleiche MAC-Adresse in beiden Netzen vorhanden sein.
Da die vom Treiber ausgegebene MAC-Adresse gültig ist, warum willst Du sie ändern?
Dass das letzte Byte bei Deiner Karte vom Label abweicht, könnte auch bedeuten, dass irgendwann mal versehentlich auf das EEPROM geschrieben wurde.
Zu den Fehlermeldungen des Testprogramms: Fehler im Puffermanagement könnten auch auf defektes SRAM oder defekte Glue Logik hindeuten. Die LANCE Karten simulieren ein Dual Ported RAM, d. h. sowohl die CPU als auch der LANCE können auf den Speicher zugreifen. Einige der Karten Designs hatten Fehler in der Arbiter-Logik. Da konnte dann z. B. ein beschleunigter Atari den Speicher dauerhaft "hoggen", so dass der LANCE dann Daten verloren hat. In meinen Treibern gab es dazu entsprechende Compilerschalter, um Wartezyklen zu erzwingen. Wenn die Karte aber mal funktioniert hat ist eher davon auszugehen, dass irgendein Baustein der Glue Logik oder eben das SRAM einen Schuss hat.
Bei den Treibern konnte man auf jeden Fall z. T. auch manuell Adressen zuweisen - wichtig eben bei den Karten, die die Adresse gar nicht speichern oder im SRAM (wenn die Batterie leer ist oder ein anderer Treiber den Speicher, wo die Adresse erwartet wird, überschreibt).
Das Datum in den Startmeldungen ist Dir sicherlich schon aufgefallen - der Spaß ist mehr als 20 Jahre her, und seitdem Frank Naumann die Sachen übernommen hatte habe ich auch nichts mehr daran gemacht. Das ist einfach zu lange her. Da musst Du also selbst in die Sourcen schauen, um zu sehen, welcher Treiber für welche LANCE-basierte Karte wie tickt...
Viele Grüße,
Torsten
-
Super, vielen Dank für die ganzen Infos.
Ich ersetze jetzt erstmal die HC durch LS wie auf der zweiten Karte vorhanden. Wenn das nichts bringt hole ich mir mal zwei neue SRAMs. Ich will die MAC Adresse nicht ändern aber ich meine die war mal im zweiten Teil wie auf den SRAMs vermerkt. Ein EEPROM hat die Karte doch garnicht.
Gäbe es zu diesem ganz anderen Problem eventuell Infos ? -> https://forum.atari-home.de/index.php/topic,15850.0.html
-
Ich will die MAC Adresse nicht ändern aber ich meine die war mal im zweiten Teil wie auf den SRAMs vermerkt. Ein EEPROM hat die Karte doch garnicht.
Ich würde mal stark annehmen, dass der Karte (und wahrscheinlich auch dem Treiber) die MAC-Adresse völlig egal ist (beide schicken und empfangen nur Pakete).
Vereinfacht: beim Senden wird die MAC-Adresse einfach vorne an das IP-Paket drangehängt, beim Empfangen wird die MAC-Adresse mit der intern gespeicherten verglichen und wenn gleich, das Paket angenommen.
Damit das funktioniert, muss die MAC-Adresse 1. eine sein, die im Subnetz nur einmal vorkommt und 2. eine, die tatsächlich als HW-Adresse verstanden wird (das sind bei weitem nicht alle möglichen). Alles andere - so zumindest meine Annahme - sollte wurscht sein.
-
Ein EEPROM hat die Karte doch garnicht.
Wie ich schon geschrieben habe: Es gibt auch Karten ohne. Bei der aus dem anderen Thread sieht man ja sofort die Hinweise im Aufdruck auf eine RAM/ROM Option. Und auch die Anschlüsse für eine Batterie und Bestückungsoptionen für die entsprechenden Dioden (um das SRAM mit VCC vom Mainboard und Batterie speisen zu können).
Der geneigte HW-Entwickler wird hier sofort vermuten, dass die Daten im EPROM stecken (wo muss der Treiber dann natürlich wissen).
Gruß,
Torsten
-
HC541 3x und 2x F245 alle durch LS ersetzt. Das Verhalten das die Karte nicht geht und dann doch bleibt. Habe noch zwei neue 62256 SRAM bestellt, sind aber noch nicht da. Die Fehlermeldung durch das lancetst.tos ist aber jetzt eine andere und zwar Error im Transmission Buffer ...
Ich hoffe mal das es an dem SRAM liegt ?
-
So beide SRAM gegen neue getauscht und das Verhalten bleibt das gleiche.
Wenn der Rechner so einen Tag aus war bootet MiNT und das Netzwerk über die PAM ist nicht verfügbar. Starte ich hingegen unter SingleTOS das lancetst.tos welches mit Fehlermeldung endet und danach MiNT, läuft das Netzwerk einwandfrei. Nachdem das Netz unter MiNTmal lief läuft auch lancetst.tos unter SingleTOS fehlerfrei bis zur "alles OK" Meldung durch.