Auch ich bin wieder fündig geworden. Diesmal habe ich mich ganz besonders gefreut, weil mir dieses Spiel noch nie über den Weg gelaufen war 😀 Ist in absolut neuwertigem Zustand (d.h. ich habe keine all zu hohen Erwartungen an das Spiel an sich 😉).
Beiträge von DiMa
-
-
Und nochmal fündig geworden 😀
-
Du solltest vielleicht das Genre etwas einschränken: FPS, (Action-)Adventure, RPG, Strategie...?
-
Da fehlt der Gilb, das kann nicht echt sein.
Tatsächlich ist die Umverpackung etwas vergilbter, als es auf dem Foto 'rüber kommt. Ich hab' aber auch lange nach einem gut erhaltenen Exemplar gesucht...
-
Neuzugang für meine Microprose Amiga BigBox Sammlung 😀
-
So, dann nochmal eine finale Rückmeldung: Auch mit aktuellster FW und SW (Nexus 1.1) die ich auftreiben konnte ändert sich gar nichts. Da der Amiga ohne die Nexus mit dem Buddha-Controller absolut stabil läuft habe ich beschlossen, dass die Nexus schuld ist und lege die Karte in die Kiste und den Vorgang zu den Akten.
Jetzt' versuch' ich 'ne Pistorm ans Laufen zu kriegen 😉
Vielen Dank für die vielen Tips hier!
-
Eine kurze Forumssuche zu Filamenten für FDM 3D-Druck förderte keine brauchbaren Ergebnisse zutage.
Vielleicht mal ein anderes Forum dazu bemühen? 😉
Mit welchen PLA(+) Filamenten habt Ihre gute Erfahrungen gesammelt?
Bambu & colofabb. SUNLU war/ist meistens auch gut. eSUN war bei mir durchwachsen. Amazon Basic hab' ich 1x gekauft und nie wieder.
Ich suche ein gutes Altweiß und ein gutes Beige für gebleichte und ungebleichte Gehäuse.
Die mit Abstand größte Farbauswahl hast du bei colofabb, u.a. weil du da (fast) jede RAL Farbe bekommst. Musst du dir mal anhand einer Farbkarte (hat jeder Baumarkt, die lassen dich da bestimmt mal ein Gehäuseteil 'dran halten) den passenden RAL-Ton aussuchen. Du kannst dann bei denen vorab auch ein Muster bekommen.
Von Bambu bekommst du auch einen Mustersatz.
-
Sorry für die lange Funkstille - habe gerade sehr viel um die Ohren.
Ich habe den Buddha eingebaut und damit läuft der Amiga absolut stabil (2.04, 3.1 - 1.3 ja sowieso). Der Übeltäter ist also eindeutig der Nexus, zumal der Buddha auch noch im gleichen Slot wie vorher der Nexus steckt. Aktuellste FW die ich finden konnte habe ich jetzt geflasht (Danke an dl1ekm für die Unterstützung), aktuellste SW muss ich noch nach ADF konvertieren - wie gesagt, wenig Zeit. Dann probiere ich es nochmal mit dem Nexus.
Das nur mal als kurzes Update & noch mal vielen Dank für die Unterstützung hier!
-
Hast du mit geänderter Konfig für den SCSI-Controller unter AmigaOS 3.x was bezwecken können oder wird einfach nur gewechselt?
Sorry, aber ich habe wohl etwas den Faden verloren (und die letzten tage auch nichts mehr machen könnnen, irre viel beruflich um die Ohren) - was meinst du mit "geänderter Konfig für den SCSI-Controller unter 3.1? ich hab' erstmal alles ausgebaut und unter 2.04/2.1 Disketten gesichert. Keine Probleme, auch nicht mit ED. Das bestärkt den Verdacht bzgl. Nexus.
Ich habe mir jetzt eine neuere Firmware für den Nexus organisiert und auch eine neuere Treiberversion aufgetrieben - die muss ich jetzt noch von DMS nach ADF konvertieren. Parallel habe ich mir den Buddah bestellt, ist heute gekommen.
Werde jetzt also erst mal wieder Kick 3.1 einbauen und gucken, ob's ED immer noch tut 😉 Danach probiere ich den Buddah. Wenn das stabil läuft hab' ich 'ne Referenz und probiere wieder den Nexus mit anderer FW und den neueren Treibern.
ich werde berichten - schon mal vielen Dank für die viele Hilfe!
-
Es lief gestern ohne Nexus alles stabil - auch ED... 😉 Vielleicht ist's der Nexus. Der Nexus war damals beim Amiga 2000 dabei als ich ihn ca. 1996 gebraucht gekauft hatte (damals ist jeder Dank 3dfx auf PCs gewechselt und die Amigas gab's günstig 😉) und hat nicht so 'rumgezickt. Kann also durchaus sein, dass als Nachwirkung des Akkuschadens bzw. dessen Reparatur da irgendwas jetzt nicht mehr 100%-ig passt und der Nexus scheint halt zickig zu sein 🤷♂️Zumal die Rev.4 Boards ja nicht zu den Timing-stabilsten gehören...
Meine Bereitschaft, TeX oder Lattice-C auf Disketten neu zu installieren und wieder ans Laufen zu bekommen um mehr zu probieren, geht allerdings gegen Null 😉 Naja, vielleicht probier' ich's mal mit Lattice C 3.x, das passte noch auf zwei Floppies 😉
Da ich keinen weiteren Controller habe und ich dann in einem Rutsch auch die HDD loswerden will - die fängt nach bald 40 Jahren nämlich auch zu zicken an 😬hab' ich mir einen Buddah bestellt. Zumal der Nexus anscheinend auch nicht wirklich mit CD-ROMs kann - und ich hatte mir extra ein SCSI-CD-ROM organisiert...
Mal 'ne komplett andere Frage: Ein wesentlicher Grund für den Einsatz alter Hardware ist für mich, meine alten Disketten via Gotek zu sichern (Programme aber auch ganz wesentlich meine alten Daten (Code, Dokumente usw.)). Ich hab' mir dazu leere ADFs erstellt, die auf's Gotek kopiert und dann einfach auf dem Amiga wie Floppies benutzt. Funktioniert einwandfrei. Da es aber auf meinem Gotek (nur 7-Segment-Anzeige, FF ohne Index) irgendwie keine Zuordnung zwischen "Nummer" und Name des ADF auf dem Stick gibt - gibt's da einen intelligenteren Trick, als die einfach unter WinUAE (oder auf meiner Vampire) "einzulegen" und zu gucken, was 'drauf ist? Und kann ich dann das ADF einfach umbennen, ohne dass es seine Zuordnung zur "Gotek-Nummer" verliert?
-
Sorry, aber da verstehe ich den Zusammenhang nicht. Ich kann wirklich überhaupt keinen Zusammenhang mit dem Fehler und irgendeiner Floppy feststellen.
Dem Rat von gilead folgend betreibe ich den Amige jetzt mal ohne Nexus. Bisher keinen Absturz mehr - allerdings ist das alles so laaaaaangsam, dass ich auch nicht so viel pro Zeiteinheit probieren kann 😉 Empfehlungen für einen Festplatten/IDE/SD-karten... Adapter? Auf Dauer geht das so jedenfalls nicht...
-
Kannst du die Floppies mal auf Konsistenz prüfen, vllt. ist irgendwo ein Bit gekippt?
Da weiss ich jetzt ehrlich gesagt nicht, was du meinst. Wie prüft man eine Floppy auf Konsistenz? (Und ich kann keinerlei Abhängigkeit von irgendeiner Floppy erkennen, oder meinst du die Laufwerke?)
ROMs sind auch geprüft (oder Softkick?)
1.3 und 2.04 sind Original-Commodore, 3.1 ist von Cloanto. Ich weiss nicht, wie ich die prüfen soll - macht der Amiga beim Neustart nicht eh' einen Test der Prüfsumme(n) für das Kick-ROM und meckert sonst mit Code Rot?
-
Bist Du Dir sicher, dass Du ED aus offiziellen Quellen hast?
Ja. Alles von Original Installationsdisketten. 1.3/2.04 von Commodore, 3.1 von Cloanto.
Baue alle Fremdhardware aus, stelle sicher, dass ein original ROM 2.04 (ohne ROM Switcher) eingebaut ist, boote mit Boot Menü (beide Maustasten beim Anschalten drücken), gehe im Bootmenü in die Advanced Options, disable die startup sequence, verlasse die Advanced Options und boote von DF0:. Du solltest dann direkt in einem Terminal landen und ED starten können. Dadurch hast Du weder eine fremde Firmware über Zorro II gestartet (da keine Fremhardware drin ist), noch über einen andere Treibersoftware aus der startup-sequence oder der user-startup und auch kein SetPatch Kommando ausgeführt.
OK, probiere ich auch noch.
-
Es kann also durchaus sein, dass ED und MEmacs später instabil waren und es keinen interessiert hat.
µEmacs läuft stabil. Unter 2.04 hatte ich bisher (mehrere Stunden) keinen Absturz, unter 3.1 selten. ED unter 3.1 reproduzierbar immer, unter 2.04 immer wenn ich irgendwas - scheint egal zu wein - vorher gemacht habe, bevor ich ihn aufrufe. DiskCopy, Prefs, 'ne excellence!-Datei angucken - ganz egal. Frisch gestartet kann ich den ED unter 2.04 starten - auch mehrfach hintereinander - sobald ich irgendwas gemacht habe, nicht mehr.
Der ED von 1.3 läuft auch nicht mit Kick 2.04 oder 3.1 (da kommt dann aber ein komplett anderer Fehler). Die anderen Systemtools (µEmacs, DiskCopy, Edit usw. ) haben dagegen überhaupt keine Probleme mit dem neuren Kick-ROM.
Wie gesagt, wäre super, wenn mal einer von euch das probieren könnte, nicht das ich da irgendwelchen Geistern hinterherjage.
-
Ist ein Zweitgerät verfügbar, um Komponenten zu tauschen, Softwareverhalten zu vergleichen?
Nein. Deshalb muss/will ich das ja verstehen, um mein desolates Rev.6 Board in Angriff zu nehmen. Dei aktuelle Konfiguration sollte eigentlich die Referenz sein 😉 Ich könnte allerdings meinen A500 re-aktivieren - ich weiss nicht, wie repräsentativ das für solche back-to-back SW Tests ist, wenn die Hardwarekonfiguration doch deutlich anders ist.
Kannst du mal alle Chips entnehmen, mit Kontaktspray (das draufbleiben darf (Werkstatt Produkte) reinigen und wieder einsetzen (das machst du bitte Chip für Cip mit Funktionstest nach jedem Chip!).
Alles was gesockelt ist mehrfach gemacht (bis auf Agnus, da weiss ich nicht, wie ich den zerstörungsfrei 'rauskriege und einen zweiten/Ersatz habe ich nicht 😬). Auch gegen andere CIAs, Paulas usw. getauscht. Hat alles nichts gebracht - siehe erster Post hier. Kann ich natürlich nochmal machen, aber ich glaub' nicht, dass die Fassungen davon besser werden 😬
Gesockelte Speicherchips habe ich nicht. Den Fastram auf der Nexus hab' ich auch schon komplett abgeschaltet, allerdings die Module nicht gezogen - der Kunststoff wirkt recht spröde. Aber ist es das Risiko wert? ich mein', drei verschiedene Speichertests finden da keine Fehler...?!
-
Naja, ich debugge ja nun seit zwei Jahren. Noch ein Tool, was keine Fehler findet, wird da ehrlich gesagt nicht weiter helfen, wenn's nicht konkret beim Debuggen von "meinem" 8000 000B hilft 😉 Da bräuchte ich Anleitung/Hilfe, dann mache ich das gerne. Weder das DiagROM, noch das von PC-Rath_de empfohlene Testkit findet ja nun irgendeinen Fehler. Nicht im RAM, nicht auf irgendeinem custom chip.
Ich habe gestern ein paar Stunden auf einem weitgehend "nackten" 2.04 (Kick & WB)"arbeiten" können. Ich habe überwiegend Disketten gesichtet und Kram von A nach B kopiert (OK, von DF0: nach DH0: 😉). Da konnte ich tatsächlich die Abstürze auf ED und AmigaBASIC reduzieren - die stürzen beide reproduzierbar mit 8000 000B ab. Meine alte Textverarbeitung (excellence!) stürzt auch ab und zu ab, aber nicht reproduzierbar, nicht immer mit 8000 000B und vor allem: Ich hab' die von früher als eher noch instabiler in Erinnerung. Auch auf anderen Amigas (hatte damals einen 500, bzw. hab' den immer noch, ist aber aktuell eingelagert). Bei AmigaBASIC bin ich mir nicht sicher, ob das überhaupt unter 2.0/3.1 läuft - aber 8000 000B wundert mich da auch etwas, ich hätte da einen anderen Fehlercode erwartet. Starten lässt es sich übrigens, aber sobald man ein Programm lädt, stürzt AmigaBASIC dann ab (noch bevor das Programm ausgeführt wird). GFA Basic tut's dagegen problemlos.
Kann mal einer von euch das Verhalten von ED unter 2.0/2.1 oder 3.1 ausprobieren? Meine "typische" Anwendung in letzter Zeit war System starten, CLI starten und dann "ed s:startup-sequence". Unter 3.1 führt das bei mir reproduzierbar zu 8000 000B. Unter 2.04 klappt das, wenn ich das genau so machen - also als erste Amtshandlung ED aufrufen - aber sobald ich dazwischen irgendwas anderes gestartet habe, z.B. Prefs, ein anderes Programm usw. -> reproduzierbar 8000 000B. Sehr seltsam. Nicht das ed irgendein Problem hat und ich da Geister jage 😬 Mit Emacs läuft's unter 2.04 nämlich problemlos und stabil, unter 3.1 hat der nicht reproduzierbare Aussetzer (8000 000B oder 8000 0003/0004). Das passiert aber deutlich seltener und ich weiss nicht mehr so genau, ob das vielleicht der normale Amiga Wahnsinn war. Ich habe auch eigentlich immer Emacs benutzt, das ist eher Zufall, dass ich angefangen habe, ED zu benutzen. Ich glaub' weil ich die Tastaturbefehle vergessen hatte und nicht mehr wusste, dass es unter AmigaDOS bereits eine Menüsteuerung gab 😬 Das stabilste System der Welt war der Amiga zu meiner Zeit jedenfalls nicht, sobald Intuition ins Spiel kam.
-
Wie bereits in #2 geschrieben: SMB1 ist einer der typischen Kandidaten für Probleme. Das Problem löst man aber nicht mit einem neuen NAS, denn das ist gar nicht das Problem.
Also entweder uralt-Clients, die nur SMB1 sprechen in ein eigenes Netzwerksegment mit eigenem NAS verbannen und das schön vom Rest des LANs abschotten, oder halt die Clients mal ersetzen. SMB1 wird ja nun nicht überall abgeschaltet, weil das so ein tolles Protokoll ist oder um alle zu ärgern. Hier gibt's 'ne schöne Übersicht, warum man das seit Jahren schon nicht mehr will.
-
Leute, wie wär's wenn der TE mal ein paar mehr Informationen beisteuert. Bis zum Beweis des Gegenteils halte ich das erst mal für einen Konfigurationsfehler. Wir wissen ja nicht mal, ob das Win11 "Upgrade" eine Neuinstallation oder ein echtes Update war...
Das ist doch hier gerade nicht zielführend. Das Synos keinerlei grundsätzliche Problem mit Win11 haben (und jedes andere NAS vmtl. auch nicht), steht ja wohl außer Frage.
-
Nein, die wurde mit 1.3 eingeführt. 1.2 habe ich nie probiert, habe glaube ich nichtmal ein Kick-ROM dafür. Und wie gesagt: Keine Probleme unter 1.3.
-
Ich kann bedenkenlos Synology NAS empfehlen (Gerüchte sagen aber, dass die die in Zukunft mit ihren eigenen HDDs/SSDs verdongeln wollen - dass wäre dann ein klarer Grund nicht zu kaufen).
Aber ich verstehe nicht, dass du bei deinen Problemen ernsthaft über den Kauf eines neuen NAS nachdenkst, bzw. annimmst, dass sich diese dadurch (zumindest dauerhaft) lösen?!
Was für ein NAS hast du, welche Serverdienste laufen und wie hast du bisher zugegriffen (IP-Adresse, Hostname, feste Zuweisung zu einem LW-Buchstaben beim Windows-Start, ggf. Benutzer geändert/neu angelegt (Zugriffsrechte?))...
Erster Anlaufpunkt:
- NAS & Windows-PC in der gleichen Arbeitsgruppe?
- Zugriff über "\\<IP-Adresse des NAS\" möglich? (Explorer)
- Ping auf IP-Adresse des NAS möglich? (Kommandozeile)
- Welche Serverdienste laufen auf dem NAS? SMB auf >V2 eingestellt (SMB1 macht Win11 so ohne weiteres nicht mehr)
- ...
-
Ja, natürlich - verstehe den Einwand nicht.
Kick 1.3/WB1.3 -> tut's.
Kick 3.1/WB3.1 -> 8000 000B Ohne Nexus: Tut's zumindest besser. ich werd' allerdings wahnsinnig ohne HDD, daher eh' keine Lösung 😉
Kick 2.04/WB2.04 (oder 2.1 - muss mal gucken, was ich da habe) -> tat's nicht (mehr), aber da mag' mir was bei einer Neuinstallation durcheinandergekommen zu sein (Commodore Installer statt Nexus Installer benutzt). Kriege ich nicht mehr aufgedröselt, zu lange her und ich war damals auch zu 100% auf der Suche nach einem HW-Problem. Inkompatibilitäten zwischen Nexus und Kick 3.1 hatte ich z.B. gar nicht auf dem Schirm (da gibt's auch eigentlich auch keinen direkten Hinweis 'drauf - aber wenn das Mögliche ausgeschlossen ist... 😉 Aber im Installationsdialog wird's halt nicht mal erwähnt -> gab's noch nicht, als meine FW für den Nexus 'raus kam. Außerdem scheint der Nexus sehr zickig zu sein, CD-ROMs kann er anscheinend i.W. gar nicht, weil er sich auch mit so ziemlichen allen CDFS nicht verträgt - so weit bin ich aber noch gar nicht gekommen 😉) weil ich total fixiert auf HW-Fehler nach Akkuschaden war.
Kick 3.1/WB1.3 -> tut's überwiegend, aber nicht alles -> gibt aber völlig andere Fehler, keinen 8000 000B. Hab' ich aber nur mal ausprobiert, um eine kaputte startup-sequence auf der HDD zu reparieren und ich grad' kein Kick 1.3 in der Umschaltplatine hatte (BTW: memacs von der Extras 1.3 tut's auch mit Kick 3.1 😉).
-
Ein schneller Test mit "nacktem" Amiga - nur 2x FDD angeschlossen - und Kick 3.1/WB3.1 hat mich zumindest bei ED nicht 'rausgeworfen. Das ist weitgehend reproduzierbar... Damit ich damit was sinnvoll Testen kann, müsste ich mir erst mal ein paar Programme wieder "Diskettentauglich" machen. Mal schauen, was ich da noch finde.
Nach weiterer Recherche ist u.U. auch der Nexus ein Problem, das scheint ein eher zickiger SCSI-Controller zu sein. Vielleicht mache ich noch mal einen Anlauf mit einer Neuinstallation von 2.04 - das kannte jedenfalls schon das Nexus-eigene HDD-Installationsprogramm (die 3.1 Disketten hat es aber auch klaglos geschluckt; eine Installation mit dem 3.1 HDD-Installationsprogramm brachte auch keine Besserung).
Was wäre denn eine einfache/schnelle/günstige Alternative, um statt des Nexus eine andere HDD/Speicherkarte statt Floppies einzusetzen? Dann kann ich das auch ausprobieren. Buddha Plus One?
-
Hatte vor ewiger Zeit bereits das Amiga-Testkit empfohlen:
Habe ich jetzt laufen lassen. Bis auf seriell/parallel (hab' keine loopback-Stecker) laufen alle Tests durch. Bei den Speichertests: Hören die irgendwann auf, oder laufen die endlos? Wie lange sollte/muss man die laufen lassen, damit man ein belastbares Ergebnis bekommt? Für die 1MB Speicher auf dem MB hab' ich nach 150 Passes/1h mal abgebrochen und dann wieder die Nexus dazugesteckt. Läuft jetzt auch 'ne Stunde (natürlich bei 4MB weniger Passes), bisher auch keine Fehler...
-
Dann mach unter 1.3 doch mal einen Speichertest, um den auszuschließen.
Speichertests hatte ich natürlich auch laufen lassen, u.a. die in KS 2.x/3.1 integrierten
Ich hab' mir das Diag-ROM besorgt. Das ist alles unauffällig, nur der "Detected Chipmem"-Test tut einfach gar nichts (bis auf eine Titelzeile anzeigen - kann ich einfach abbrechen und komme wieder ins Menü) und der "Extended Chipmem"-Test schmeisst ganz am Ende einen Adressfehler - aber lt. Recherche ist das wohl nicht so eindeutig (also ob das überhaupt ein Fehler ist).
Ich kann einen Screenshot vom DiagROM einstellen, wenn du dich damit auskennst. Ich hab' nicht mal rausfinden können, ob das ein Adressfehler oder ein DiagROM-Fehler ist.
Welchen Speichertest soll ich unter 1.3 laufen lassen und wo kriege ich den her?
Solange die Kickstart-Version < 3 ist, kannst du in den ROM WACK springen, indem du bei einem Guru die rechte Maustaste drückst. Terminalparameter sind standard 9600 Baud, 8N1, kein Handshake.
OK, Danke - probiere ich aus.
-
Es gibt auch für Amiga mit 68000 Prozessoren sehr viele Debuggingtools, die einem bei der Analyse solcher Fehler helfen. Zum Beispiel Installieren die einen Handler für alle Exceptions und leiten dich in einen Maschinensprachmonitor, wenn eine der Exceptions auftritt.
Welche sind das und wo kriege ich die her?
-
OK. Verstanden. Danke.
Könnte denn einer von euch beiden auch mal auf folgende Punkte eingehen:
- Der Fehler tritt nur (!) mit Kick > 1.3 auf. (2.04 & 3.1 hab' ich probiert). Nicht unter 1.3. Wie passt das zu den von euch beschriebenen "allgemeinen speicherfehlern" bzw. warum spielt bei einem mgl. HW-Fehler die Kick-/OS-Version eine Rolle?
- Ich habe oben mehrere Quellen verlinkt, die 8000 000B sehr konkret mit einem FPU-Zugriff bei nicht-vorhandener oder inkompaibler FPU in Zusammenhang bringen. Tritt wohl häufiger bei nicht zur Beschleunigerkarte passender 680xx.library und/oder inkompatiblen SetPatch-Versionen auf. Das würde zumindest erklären, warum der Fehler nicht mit 1.3 auftritt. Das gibt's da alles noch gar nicht.
Wieso springst du beim Guru nicht einfach in den Debugger (Terminal an die Serielle anschließen!) und schaust nach, was an der Adresse steht?
Weil ich nicht wusste, dass das geht 😀 Welche Parameter muss ich im Terminalprogramm einstellen?
-
Ich weiß nicht, woher Du die Analyse hast, dass 8000 000B ein FPU Problem sei.
Amiga 3000 / Error 8000000B - Page 1
Simplemail 8000 000B error - English Amiga Board
(...)
8000 000B ist ein allgemeiner Speicherfehler.
Quelle?
Ein weitere Grund kann eine SW sein, die eigentlich für eine modernere OS Version gedacht ist und beim Start die Version benötigter shared libraries nicht korrekt angibt (z.B. Version 0 statt 36).
Ich kann den Fehler am zuverlässigsten mit ED auslösen und zwar in der jeweils zum Kick passenden Version (egal ob 2.04 oder 3.1). Da kann man das wohl ausschliessen?! ich hab' sowas durchaus beim Experimentieren mit verschiedenen WB-Versionen gegen Kick-ROMs hinbekommen (z.B. tut's der 1.3 ED nicht mit Kick 3.1) - da kommt aber ein sinnvoller Fehlercode (8400000C? Hab' ich nicht aufgeschrieben, da reproduzierbar immer in genau dieser Kombination.) - aber nicht den 8000 000B.
Der Fehler scheint also deterministisch zu sein.
Der Fehler ja. Wann er auftritt weniger - manchmal kann ich stundenlang "arbeiten", manchmal kommt der irgendwo während der startup-sequence. Nur wenn ich ED starte passiert's fast immer.
Wäre es wilder Speicherzugriff, dann gäbe es eher verschiedene Guru Meditations, z.B: hat die Ausführung ungültiger CPU Befehle eine andere Nummer. Wäre es eine deterministisch falsche SW, dann sollte der Fehler natürlich auch immer in der gleichen Situation auftauchen. Also könnte es sich auch um einen HW Fehler handeln. Schlechte Lötstelle eines RAM Chips?
Öhh... wäre das nicht auch Kategorie "wilder Speicherzugriff"? Lötstellen kann ich nochmal checken.
... Ich wollte die ganze Zeit "Agnus Sockel" rufen...
Den hab' ich noch nicht so genau geprüft, wie mach' ich das am besten? Nur Sichtkontrolle reicht ja eher nicht... Mal gucken, ob ich eine ausreichend feine Prüfspitze finde. Der hatte aber AFAIR nix von der kaputten Batterie abbekommen. Agnus ist auch der einzige Chip den ich nicht gewechselt habe, da ich davon tatsächlich nur einen habe. Obwohl, ich hab' jetzt noch 'nen zweiten, aber der ist auf dem R6 Board was es so gar nicht tut bisher... Also nicht so ein guter Kandidat 😬
Aber nochmal, was mich so verwirrt und mich an einem HW-Fehler mittlerweile etwas zweifeln lässt: Mit 1.3 läuft das System stabil! (So stabil ein Amiga halt läuft - aber dann gibt's halt alle möglichen Fehlercodes in allen möglichen (und unmöglichen) Kombinationen. Also wie früher 😀
-
Siehe erster Beitrag in diesem Thread - habe ich alles schon durch. RAM ist nicht gesockelt (ausser auf der Nexus - aber den hab' ich wie gesagt auch schon testweise komplett 'raus geschmissen - ändert nix).
Reinen Diskettenbetrieb unter 3.1 hab' ich noch nicht probiert (also auch ohne Nexus) - mach' ich auch noch, ist ein Tip.
Wie gesagt: Es kommt IMMER 8000 000B. Lt. Recherche liegt das i.d.R. an inkompatiblen Mischungen aus FPUs und libraries. Ich hab' aber gar keine FPU und mir fällt auch nicht ein, wozu AmigaDOS bei simplen DOS-Befehlen überhaupt FPU-Extensions nutzen sollte. 68040.library umbenennen oder löschen bringt auch nichts. SetPatch macht für mich nicht erkennbar irgendwas in Bezug auf FPU (warum auch - hab' ja keine).
Die FPU-Problematik würde zumindest erklären, warum das Problem unter 1.3 nicht auftritt: Da gab's noch keine 68k mit FPUs (zumindest nicht in der Amiga-Welt). Aber ich hab' keinen Hinweis darauf gefunden, dass Kick/WB 3.1 nicht mit A2000 Rev.4 funktionieren...?!
-
Ich hole das Thema mal wieder vor, u.a. weil ich seit zwei Tagen wieder versucht habe, das Problem in den Griff zu kriegen.
Der 8000 0003 ist weg. Ich kriege jetzt nur noch 8000 000B. Manchmal beim booten, manchmal erst nach Stunden. Internet-Recherche hat ergeben, dass das auf ein Problem mit der FPU hinweist - mein 68k hat aber gar keine. Die Gurus treten auch auf, wenn ich gar nix mache, wo FPU-Befehle genutzt werden könnten, also z.B. einfach beim editieren der startup-sequence etc.
Ich hab' mir das Diag-ROM besorgt. Das ist alles unauffällig, nur der "Detected Chipmem"-Test tut einfach gar nichts (bis auf eine Titelzeile anzeigen - kann ich einfach abbrechen und komme wieder ins Menü) und der "Extended Chipmem"-Test schmeisst ganz am Ende einen Adressfehler - aber lt. Recherche ist das wohl nicht so eindeutig (also ob das überhaupt ein Fehler ist).
Ich hab' auch mal das RAM auf der Erweiterungskarte komplett abgeklemmt - ändert nichts. Der letzte Crash hat die Platte invalidiert 😬 Jetzt hab' ich während es low-level Formats Zeit, das zu schreiben 😁
Irgendwer 'ne Idee?
Konfiguration ist weiterhin A2000 Rev4.1 (Heynie, nicht BS) , 512kb Chip/512kb Fast, Nexus-SCSI-Karte mit 4M (wenn ich den RAM abschalte, ändert sich wie gesagt auch nix) & HDD (und AT-Bridgeboard - das spielt aber keine Rolle, der Fehler tritt auf, egal ob die Karte eingebaut ist oder nicht).
Ich mach' noch einen Anlauf und die Platte jetzt eh' "geputzt" ist/wurde, kommt sonst 1.3 'drauf, denn ich bin 'drauf uns 'dran, mich
Ich würde das 1.3 lassen, wenn es stabil läuft, der eventuelle Mehrwert ist den Stress nicht wert.
anzuschliessen 😉
-
Keine Ahnung - "bezahlbar" in Bezug auf "wäre ich bereit auszugeben" würde für mich je nach Zustand und Ausstattung 100-200€ bedeuten.
