atari-home.de - Foren
Hardware => Hardware (High-End) => Thema gestartet von: Lukas Frank am Mo 05.12.2022, 14:53:59
-
Setze zur Zeit das Setup von BikerBob aus Canada instand. Auf dem Atari Mega ST4 Mainboard war die Memory Verbindung zwischen Shifter D6 und dem Latch 74F373 (PAK) nicht da. Mit einem Draht auf der Platinenrückseite gefixt, konnte an den Leiterbahnen auf dem Board nichts sehen/finden. Nächtes ist die PAK68/3 mit PuPla/2 und FRAK/2 Kombi anzupassen mit den Patches dazu ...
Bikerbob war auch bei Exxos im Forum aktiv und alle Pullups waren 2,2k, habe ich erstmal wieder geändert auf 3,3k und 6,8k für die PAK. Die beiden FDC Patches lasse ich erstmal drin und schaue später ob ich die rausnehme?
Das einlöten der IC Sockel hat er gut und sauber gemacht.
-
Original Atari Floppy mit großen Auswurfknopf funktioniert nicht richtig, beim Formatieren kommt es zu einer Abbruch Meldung ...
Frage erstmal was für ein Laufwerk er verwenden will und baue ansonsten die beiden Exxos FDC Patches zurück ...
-
Er möchte ein Sony 920 nutzen. Floppy formatiert nicht komplett durch und eine ACSI Festplatte mit LINK97 bootet nicht, es kommen nur 2 Bomben ...
Exxos FDC Mods habe ich erstmal zurückgebaut. Die Atari Floppy hat Pullups, bei der Sony muss ich schauen. So ein Sony 920 läuft bei meinen Rechnern aber ohne die Mods einwandfrei.
-
Testmodul meldet beim DMA Test ...
DMAPort Test
D1 DMA count error
Fail at cycle:000001
D0 bis D15 von der CPU ist da, A1, R/W, RDY und /FCS ist da. Keine Ahnung wo das Problem liegt ...
DMA Chip schon getauscht ohne Änderung. D0 bis D7 von der DMA zur Buchse sind da.
-
Das mit dem DMA Error war mein Fehler weil das Mainboard einen Mix aus IMP und nicht IMP hatte habe ich den Chipsatz aus meinem Bestand ersetzt. Meine eingesetzte MMU war wohl defekt. Jetzt bootet das Board von Festplatte und die SONY 920 Floppy formatiert eine DD Diskette durch ohne Problem ...
-
So ...
PAK68/3 plus FRAK/2 plus PuPla/2 laufen soweit Stabil im ersten Test. Das läuft mit 50Mhz und 64MB Fastram und FPU. Floppy funktioniert soweit einwandfrei und der Rechner bootet von einer SCSI Festplatte über einen LINK97 Hostadapter.
Muss am Wochenende noch mehr Testen auch ein Betrieb von IDE und alles länger laufen lassen ...
Die PAK Kombi zu patchen war eine Menge Arbeit und hat einiges an Nerven gekostet beim Zerbohren von Leiterbahnen auf der PAK. Den Bohrer drehe ich Vorsichtig per Hand unter einer Lupe. Es waren sechs Unterbrechungen und ein Patchkabel sowie elf neue Masseverbindungen auf der FRAK und eine Unterbrechung. Lief auf anhieb ...
-
Fastram ist einwandfrei ...
Die ganzen PAK/FRAK Patches sind von Holger Zimmermann, habe ich mir abgeg(k)uckt.
-
Habe das HD Modul eingebaut und Bikerbob gesagt er solle sich über BEST einen AJAX Floppy Controller Baustein kaufen. Er hat auch eine LightningST Erweiterung die er noch einbauen will, zum Testen nutze ich ein c´t IDE Interface ...
Habe ihm am Floppycontroller eine Sockelleiste eingelötet damit er vielleicht doch den Exxos Patch einstecken kann ...
Der FDC der auf dem Mainboard steckte war ein WD1772-02-02 und der tut es nicht im HD Betrieb. Einer meiner 02-02 geht weil ich keinen AJAX übrig habe zum pobieren aber auf Dauer ist so ein 02-02 nichts ...
Lief jetzt eine ganze Zeit mit der PAK und alles ist sehr Stabil.
-
PAK mit IDE ...
-
Mit Panther/2 und ET4000 ...
So wie es scheint aus Polen von Artur funktioniert aber einwandfrei.
Lasse alles morgen nochmal länger laufen und geht dann die Woche zurück nach Canada.
-
Es ist die zweite PAK von Bikerbob aus Canada. Es ist eine Kopie der PAK68/3-030 aus Polen mit einer fehlenden Verbindung an den Level 2 Cache Ram Bausteinen. Das ist schon gepatcht und macht aber nichts an der Lauffähigkeit der PAK. Laut Bikerbob soll die laufen, tut sie aber nicht. Bekomme die PAK nicht zum funktionieren. Probiert mit PAK TOS und auch Onboard TOS 2.06. GAL Satz neu gemacht. Habe schon alles weggenommen wie FPU, Level 2 Cache, 32bit TOS Roms getauscht und die CPU getauscht ...
D0 an D16 und bis zu D15 an D31 sind alle da
A1 - A23 sind da
Alles vom Mainboard Sockel ist an den GALs da
Alle Daten und Adressen an den Rombausteinen haben normale einige Kiloohm und sind in Ordnung
Habe die PAK Patches wegen der FRAK/2 gemacht. Wegen der 20ns TAG Ram nur 40Mhz Quarz.
Der Rechner ein Mega ST scheint mit der PAK nicht zu booten. Der Monitor bekommt sync Signale und die Aktivitäts LED wird grün aber der Bildschirm bleibt schwarz.
Habe keine Idee mehr ...?
-
Vielleicht kein Ram...
-
Wie meinst du das?
Kein SRAM unter den ROM Bausteinen, die kann ich nicht prüfen da eingelötet. Das Mega ST Mainboard läuft einwandfrei mit einer 68000 CPU oder auch einer anderen PAK allerdings eine 020 Version mit FRAK.
-
Ich finde bei der zweiten PAK030 den Fehler nicht. Verhalten ist so das der Monitor unter ST Hoch Sync bekommt also die Status LED Grün wird aber das Bild bleibt schwarz. Reset und Halt sind gut, beide high. Unter ST-Gering wird der Bildschirm weiß und nichts geht. Bleibt beim booten irgendwo hängen? GAL Satz und Roms sind in Ordnung. Selbst ohne das PAK TOS müsste mit dem Onboard TOS 1.04 der Bildschirm unter ST-Hoch weiß werden und Bomben kommen.
@czietz ... welche 68000 Bus Signale müssen denn wie reagieren beim booten?
-
Es ist schwierig, das umfassend zu beantworten, ohne ein Buch zu schreiben. ;)
Nach dem Prüfen der "Basics" (5V, Clock, Reset) guckt man gängigerweise erstmal, wie viele Buszugriffe (am 68000er Bus: /AS, /LDS, /UDS) die CPU versucht ... und ob die bis zum Onboard-ROM (dessen /CE) durchkommen. Und ob ein /DTACK vom System zurückkommt. Im besten Fall sind es nur sehr wenige Zugriffe, dann ist der Fehler oft trivial.
-
Danke.
Hänge mal meinen LA dran, mal schauen ...
-
Das erste was ich gemacht habe ist das GAL P3 aufgesteckt und eine 68000 CPU montiert. Läuft auch mit 68000 nicht, alles tot wie es scheint ...
LA im Modus PAK Modus an ...
(ROM2 ist von den TOS Bausteinen auf dem Atari Board, also das TOS 1.04)
Im weiteren Verlauf alles High ...
-
Das müsste ein PAK-Kundiger (=nicht ich!) bewerten. Ich sehe, dass die ersten vier Buszugriffe wie erwartet auf das Mainboard-ROM gehen. Wohin die weiteren Buszugriffe gehen, ist aus der Aufzeichnung nicht zu erkennen.
-
sehe, dass die ersten vier Buszugriffe wie erwartet auf das Mainboard-ROM gehen. Wohin die weiteren Buszugriffe gehen, ist aus der Aufzeichnung nicht zu erkennen.
... ohne Ahnung vermute ich das jetzt alles auf die PAK springen muss (PAK TOS) und die PAK die Steuerung übernimmt.
Das Mainboard ist ja Fehlerfrei und der Fehler liegt auf der PAK ...
Das müsste ein PAK-Kundiger (=nicht ich!) bewerten.
Da gibt es ja nur einen. Habe ihn angeschrieben, mal schauen ...
-
... ohne Ahnung vermute ich das jetzt alles auf die PAK springen muss (PAK TOS) und die PAK die Steuerung übernimmt.
Das wäre das korrekte Verhalten ja: Die ersten vier Zugriffe (Adressen 0-7) gehen auf das Mainboard-ROM, die Folgezugriffe dann auf das PAK-ROM. Aber wir wissen nicht, ob Deine PAK das korrekte Verhalten zeigt. Du könntest natürlich auch mal die /CE-Leitung der PAK-ROMs beobachten.
-
Bitte sehr ...
Habe ja die Schaltpläne, prüfe nochmal ob von den GALs her da ist.
-
Nun habe ich keinen Vergleich, was eine funktionierende PAK tun würde. Aber dass es nur sieben Zugriffe auf das PAK-ROM gibt und danach wieder so viele Zugriffe auf den Mainboard-Bus (erkennbar an /AS, /LDS, /UDS), kommt mir doch sehr seltsam vor. Vielleicht kommen die Daten aus den PAK-ROMs nicht richtig bei der CPU an, weil eine Daten- oder Adressleitung unterbrochen oder kurzgeschlossen ist.
-
Was ich bisher gemessen habe ...
D0 - D31 zwischen CPU -> 541 -> ROM
D0 Mainboard CPU Sockel auf 030 CPU D16 und alles weitere bis D15 Mainboard auf 030 CPU D31
alle Adressen und Steuersignale vom Mainboard CPU Sockel auf die PAK GALs
... alles da. Widerstandstandswerte gegen VCC sowie GND im 7KOhm Bereich an allen ROM Pins gut.
Das einzige was nicht mit dem Schaltplan übereinstimmte war die Zuordnung an den 541 aber war alles da. Spielt glaube ich keine Rolle so ähnlich wie bei den MAD Leitungen beim ST Ram von de MMU ...
Ich muss ja davon ausgehen das die Platine in Ordnung ist weil auch die Lötungen gut aussehen. Die Bauteile in Ordnung sind. Die Roms liefen in einer anderen PAK. Ich suche weiter ...
-
Meine PAK/2/3 Experience liegt schon lange zurück, finde das Thema aber immer wieder spannend und habe mir eben mal die Jumper-Doku bei Wrsonline angeschaut:
Demnach kann über Jumper 7 (ROM) festgelegt werden, wo das TOS liegt (auf dem Mainboard oder auf der PAK).
Das deutet ja darauf hin, dass ein Betrieb mit TOS unterhalb der PAK möglich wäre, sofern dort ein PAK taugliches TOS vorhanden ist.
Das gepatchte 3.06er TOS (aka PAK-TOS) könnte mit passend gestecktem Jumper also in zwei Sockel einer TOS-Card laufen, sofern diese das (doppelt??) so große 3.06 er TOS komplett adressieren kann. Ich meine, ich hätte das damals mal so probiert, hatte als TOS Card die c't-IDE TOS Karte. Kann aber auch sein, dass meine Erinnerung mich täuscht.
btw. Wie sehen denn die DTACK0 und DTACK1-Signale aus?
Entspricht der PAK-Nachbau aus Polen der neueren A-Version von WRS?
Weiterhin viel Erfolg bei deinen spannenden Auf- und Nachbauten,
Jörg
-
Die Polen PAK68/3-030 Platine entspricht der neueren Version plus eventuellen Patches. Einziger Fehler ist eine fehlende Verbindung zu den L2 Cache.
Habe den ROM Jumper auf der PAK mal auf das Mainboard ROM gesetzt. Dort sitzt ein TOS 1.04 und ich meine es müsste so ein weißer Bildschirm unter ST-Hoch kommen mit Bomben. Ist aber genau wie bei dem PAK TOS also Monitor LED wird grün (Monitor bekommt Sync) und Bildschirm bleibt schwarz ...
-
btw. Wie sehen denn die DTACK0 und DTACK1-Signale aus?
Der Ordnung halber: die gemeinten Signale heißen DSACK0 und DSACK1
-
Ja ...
... aber ich hatte vorher mal geschrieben das eine Umschaltung mit dem GAL P3 auf eine 68000 CPU oben auf der PAK auch nicht geht.
-
Der 16Mhz Clock und der 8Mhz Clock beides aus dem 74F86 sind da und kommen an den beiden GALs an.
Alle Steuersignale am 68000 Sockel sowie alle Adress und Daten Signale sind hochohmig also kein Kurzschluß.
Mal ein Bild der Karte ...
-
Da die ganze Sache umschaltbar auf 68000 nicht läuft habe ich mal die Signale die an das Umschaltgal gesteuert werden auf gezeichnet ...
/BG_PAK, /BR_PAK und E_PAK sind die Signale die vom mainbaord auf die PAK gehen, die mit 68K bezeichneten gehen auf die 68000 CPU die man oben auf die PAK stecken kann.
Die Umschaltsignale am GAL P3 gehen an die Pins 9,12,11,19,13,4 und zwei weitere, somit müsste das GAL PUK3_A das richtige sein.
Bei E ist ein Takt und /BG und /BR sind beide High. PUK GAL nicht bestückt und J5 und J6 gesetzt. Die Ausreißer bei dem 8Mhz und 16Mhz Clock bei der zu geringen Abtastrate vom LA begründet ...
-
FC2,1,0 scheinen auch zu reagieren. FC2 ist dauert High ...
030 CPU Clock ist auch da mit 40Mhz
Nicht das ich wüsste was ich da mache !
-
FC2 dauerhaft "1" sagt, die CPU ist im Supervisor-Mode, was kurz nach Reset vermutlich völlig korrekt ist.
Reset ist auch nur eine Exception. Diese werden - nach meiner blassen Erinnerung - immer im Supervisor-Mode ausgeführt. Normale Programme laufen dann im User-Mode, können aber auch den Supervisor Mode aufrufen.
-
Ohne PAK mit einer 68000er CPU läuft der MegaST ja?
Ohne dir tatsächlich kompetente Hilfe anbieten zu können, würde ich so vorgehen:
1. mit dem LA mal schauen, wie die am PUK-GAL anliegenden Signale nach einem Reset an der original CPU aussehen, dann hast du den Vergleich
2. das PUK-GAL und die 68000er CPU auf der PAK bestücken und die relevanten Signale (welche? habe keinen Schaltplan der PAK/3, gibt es offenbar auch nicht bei wrs) dort erneut abgreifen und mit der funktionierenden Aufzeichnung vergleichen.
Es ist sehr merkwürdig, dass die CPU nicht aus dem Supervisor-Level herauskommt, bei deinem LA-Log.
aus dem Handbuch zum 68030:
4.1.1 Supervisor Privilege Level
The supervisor level is the higher privilege level. The privilege level is determined by the Sbit of the status register; if the S bit is set, the supervisor privilege level applies, and allinstructions are executable. The bus cycles for instructions executed at the supervisor levelare normally classified as supervisor references, and the values of the function codes onFC0–FC2 refer to supervisor address spaces.
und
When the M bit is clear, the MC68030 is in the interrupt mode of the supervisor privilegelevel, and operation is the same as in the MC68000, MC68008, and MC68010 supervisormode. (The processor is in this mode after a reset operation.) All supervisor stack pointerreferences access the interrupt stack pointer (ISP) in this mode.
zu FC0 bis FC2 siehe das angehängt Bild
Demnach geht die CPU für die ersten 4 (32bit) Zugriffe in den Supervisor Program Space und wechselt dann dauerhaft in den Supervisor Data Space. Ob das so korrekt ist, weiß ich leider nicht...
-
Danke für deine Hilfe ...
Was ich nicht verstehe ist das eine 68000 CPU oben auf der PAK zusammen mit dem PUK3A GAL auch nicht geht. Das gleiche Verhalten wie wenn die PAK alleine Aktiv ist. Außer VCC und GND sind alle Pins am 68000 Sockel hochohmig.
Das Mega ST Board läuft mit einer 68000 CPU oder einer anderen PAK.
-
Hatte ein Mega ST4 Board was das gleiche Fehlerbild zeigte und da war auch mit Testmodul über die Serielle alles tot. War ein Kontakt Problem an den PLCC Sockel von MMU und/oder GLUE.
Messe jetzt nochmal alle 64 Verbindungen vom 68000 Anschluss der PAK auf die Karte. Hatte das schon gemacht aber man weiss ja nie ...
-
So nochmal alles nachgemessen ohne einen Fehler zu finden. Ich bin Ratlos und weiss erstmal nicht weiter ...
-
Läuft jetzt. Ist halt ziemlich Blöd wenn man nicht weiss wo der Fehler war!
Die PuPla/2 scheint kaputt und die PAK läuft zwar aber nicht richtig. Der Rechner bootet nur durch bis zum Desktop wenn der L2 Cache ausgeschaltet ist. Doof halt das bei disable L2 Cache das Fastram auf der FRAK nicht geht. Habe mal die TAG Rams getauscht, daran liegt es aber nicht. Mal sehen ob ich den Fehler finde ...
-
Verbindungen auf der PAK sind wie zu erwarten alle da. Alle SRAM Bausteine nachgelötet.
Keine Änderung des Fehlerbildes ...
-
Weiss der Geier was die Leute in Polen oder Canada für Lötzinn nutzen? Habe an der PuPla/2 einen Pin nachgelötet und plötzlich eine kleine Explosion unmd eine ganze Menge Zinn spritzer die durch die Gegend flogen. War da Wasser im alten Zinn?
Kleiner Lichtblick ist das die PuPla/2 wieder funktioniert. Da musste einiges nachgelötet werden.
An der PAK nochmal die TAG Ram Bausteine nachgelötet und den GAL Satz neu gemacht weil U1 und U2 den L2 Cache steuern. Fehler ist immer noch da.
Wenn ich deen disable L2 Cache Jumper setze läuft es. Bei L2 Cache enable bootet die PAK nicht bis zum Desktop, es bleibt das Atari PAK3 Logo stehen und es geht nicht weiter. Oder es kommen vier oder zwei Bomben oder manchmal den ganzem Bildschirm in voller Breite alles voller Bomben.
Bin jetzt am Ende. Nach Logik kann ja nur noch das SRAM defekt sein. Problem ist das es verlötet ist. Vermute aber das ist in Ordnung.
-
deswegen ziehe ich immer eine Schutzbrille beim Löten an. Hab auch mal so eine Erfahrung gemacht am Schneider CPC6128, als ich das RAM nachgelötet habe. Da hatte ich Lötspritzer an der Augenbraue. Kann alles mögliche sein, reinigungsmittel was sich abgesetzt hat im Zinn, Wasser oder andere Stoffe.
-
Wie gedacht ...
SRAM Bausteine ausgelötet, das ging gut Dank einer neuen Ersatz Entlötpistole. Sockel rein und alles um eine Sockellage erhöht wegen der FRAK. Jedes SRAM in einer anderen PAK laufen lassen mit HDD Boot und einem Lauf Gembench, alle vier gut.
-
@pakman Inzwischen alles vier bis fünf mal kontrolliert und der Fehler war die MC68030RC33 CPU die bei mir mit 25Mhz oder auch 32Mhz lief. Vermute das zeigt ein Übertakten auf Dauer schadet ...
Eine andere CPU eingesetzt und alles läuft mit dem Level 2 Cache ohne Bomben ...
Hätte nie an die CPU als Grund gedacht weil mit dem L2 disable lief es ja stabil mit der kaputten CPU. Der GAL Satz aus Canada von Bikerbob ist defekt und läuft nicht richtig, sprich CRC Fehler beim booten und Systemhänger.
FRAK/2 mit dem Fastram läuft nicht, zeigt 128kB Fastram und das System hängt beim booten. Oxidiert teilweise, in Canada scheint es sehr feucht zu sein. Muss ich überarbeiten und da der FRAK GAL satz bestimmt auch nicht besser ist als bei der PAK muss ich den Neu machen ...
... in Canada lötet man mit Wasser Lötzinn oder unter Wasser ;-)
-
Vielleicht nutzt er Wasserhaltiges Flussmittel ?
Muss ihn mal fragen ...
-
Er hat die beiden PS/2 Simm Sockel falsch herum eingelötet ...
-
Er hat die beiden PS/2 Simm Sockel falsch herum eingelötet ...
Um 180 Grad vertan?
-
Ja geht ja nicht anders ...
Da sind Kodierpinne dicker und dünner an den Sockeln aber leider hat die FRAK keine Bohrungen dafür. Ist aber ein Aufdruck auf der Platine.
-
Vielleicht nutzt er Wasserhaltiges Flussmittel ?
Muss ihn mal fragen ...
oder 70%iges Isopropanol ?
-
Er hat die beiden PS/2 Simm Sockel falsch herum eingelötet ...
Die Aussage stimmt nicht. Es gibt wohl rechte und linke Sockel.
Also Fehler ist bei 32MB auf der Karte zeigt der Memorytest beim booten 128kB ...
Alle Adressen A0 bis A26 plus A31 an den verschiedenen GALs vorhanden von der 030 CPU zur FRAK. An den Ram Bausteinen liegt es nicht.
-
Die Behauptung das die FRAK mit L2 Cache disable auf der PAK das Fastram nicht erkennt stimmt nicht, es geht auch so ...
Die FRAK die zur PAK gehört ist in Ordnung und funktioniert getestet an einer anderen PAK nach meiner Überarbeitung. Das Problem liegt also an der Bikerbob PAK. Die läuft ja ohne FRAK einwandfrei, also suchen wo das Problem liegt ...
-
Normalerweise baut/lötet man das alles ordnungsgemäß zusammen und das läuft immer auf Anhieb ...
Nochmal zum xten Mal alles nachgemessen und das GAL P6FR überprüft und keinen Fehler entdeckt.
Im Blaue hinein vermute ich mal 030iger CPU defekt, keine Ahnung! Ist 50Mhz auf der Keramik bedruckt, vielleicht ein Fake und durch übertakten auf Dauer teilweise defekt geworden? Kaufe mal eine 33iger zum Probieren ...
-
Hatte die FRAK/2 mit einer anderen PAK68/3-030 getestet und die FRAK/2 funktionierte auf Anhieb. Die dazu gehörige PAK funktionierte alleine also ohne FRAK einwandfrei. Der Fehler mit der FRAK war mal nur 128kB Fastram und dann zwei Bomben und andere Male ein einwandfreies booten ganz ohne Fastram.
Der Grund waren ausgelutschte Sockel für die beiden 74F541. Habe beide Sockel erneuert und alles lief auf Anhieb mit Fastram einwandfrei. Das sind Präzisionssockel gewesen, messbar war alles in Ordnung laut Multimeter ...
Die von mir als defekte erkannte 030iger CPU ist doch in Ordnung. Habe den CPU Sockel komplett neu gelötet also altes Lötzinn weg und alles neu. Gab wohl Kontaktprobleme ...
Läuft jetzt mit 40Mhz weil ich nur TAG Ram Bausteine mit 35ns habe, für mehr Geschwindigkeit braucht man 20ns Bausteine die seit Jahren nicht mehr zu bekommen sind.
-
Also hast Du jetzt alles durch repariert :)
Was so Kontaktschwierigkeiten alles verursachen können. Ist echt lästig. Kenn ich von Berufswegen auch. Pixelstörungen im Bild, Antennenkabel raus/rein oder hin/her drehen und weg ist der Fehler.
Hast mal wieder perfekte Fehlersuche und Behebung geleistet.
Gruß
Wolfgang
-
Die vier zusätzlichen GND Patchkabel an CON1 auf der FRAK sind wichtig. Wegen der US SIL Streifen die Tonnenförmig an einer Seite ausgeführt sind die in die Platine kommt konnte ich die dicken Vollkupferdraht Kabel nicht zwischen SIL Streifen und Platine löten. Bikerbob hatte die Kabel deshalb von oben auf die Pins gelötet was aber zu Kontaktproblemen mit der darauf gesteckten weiteren Leiste führt. Habe deshalb sehr dünne Kabel verwendet was aber bei YAART zu Fehlern führte. Abhilfe war einfach die zusätzliche Molex Stromverbindung an der PAK anzustecken, seitdem alles ohne Fehler ...
Die SIL Leisten von Kessler hier aus der EU sind nicht Tonnenförmig geformt sondern Kegelförmig, so ist zwischen Platine und SIL Leiste genug Raum um da Kabel zwischen zu löten.
Hätte CON1 auch ersetzen können aber war mir nicht sicher ob die Leisten die gleiche Höhe haben. Hätte wahrscheinlich alle Leisten tauschen müssen, die CPU Leisten lassen sich so einfach aber nicht tauschen da dort kein Platz für die Entpumpe ist. Man hätte jeden Pin einzeln per Lötkolben rausholen müssen.
-
Well, I am glad you were able to get everything running Frank.
This set of boards were purchased from Arthur back in 2017. I was never able to get them to work. I got a lot of help from Pakman and from yourself and eventually I sent them to you.
I have been very busy this summer, and I have not put any time in to completing my project with my new FRAK/2 and the existing PAK030 I have. I should find time in the next month or so.
Great that it was not a lost cause set of boards.
James (Bikerbob)
-
After the short circuit on the old frak, I'm curious whether the newly built frak runs without problems. Please with pictures...