Vom 8032 zum MMF 9000 - ein Thread mit (hoffentlichem) Happy End! :)

  • Kurze Rückmeldung, um euch zu verwirren. :)


    Ich habe mal die acht 4164er gegen welche getauscht, die frisch aus dem Chiptester mit PASS kamen. (NOS TI4164)

    Verwende ich ALLE acht davon, bootet OS9 nicht mehr! Es hängt bereits einen Bildschirm vor der Zeiteingabe.

    Wechsle ich nur die untere Reihe, läuft es wie vorher.


    Und jetzt hab ich es wirklich mal gute 30 Minuten nachgestellt:

    Beschäftige ich den Rechner mit Tastatureingaben (hierzu hab ich einen Schraubendreher zwischen die ESC-Taste geklemmt, damit die dauerhaft betätigt wurde), so läuft der Rechner wirlich PERMANENT ohne Hänger/Abstürze.

    Kaum ziehe ich den Schraubendreher raus, und warte etwa 30 Sekunden, friert er ein und nix geht mehr!


    Spannende Frage: Soll ich wirklich zusätzliche Kondensatoren neben die RAMs löten- oder kann man sich das bei diesem Fehlerbild schenken?

  • Soll ich wirklich zusätzliche Kondensatoren neben die RAMs löten- oder kann man sich das bei diesem Fehlerbild schenken?

    Ich würde auf jeden Fall die 10nF Dinger rauswerfen, und 220nF einsetzen.

    => Alles, was auf Kante genäht ist, in Ordnung bringen, um es als mögliche Fehlerursache auszuschließen.

  • Ich hab nur 100nF hier… mit denen geh ich ins Rennen.

    So, zum Schlafengehen die letzte Erkenntnis des Tages:



    Wenn der Memorytest recht hat, gibt es wohl wirklich ein Problem mit dem RAM.

    Der Ausschnitt zeigt das Testprogramm, welches explizit den RAM für die Nutzung mit OS/9 testet.

  • Mal wieder ein Schuss ins Blaue: Ein Refresh-Problem? Wegen dem Absturz bei in Aktiivität? Vorausgesetzt, der RAM-Test testet den Refresh.


    Ja, ich habe nicht wirklich viel Ahnung davon, wie dyn. RAMs und der Refresh funktionieren. Ich weiß nur, dass der vorhanden sein muss. :D

  • Verändert sich denn der Memory Test wenn Du die RAM Chips in anderer Reihenfolge in die Sockel steckst? Tritt bei unveränderter Chip-Bestückung der Fehler immer an der gleichen Adresse auf?

    Wenn die Adresse gleich bleibt, dann hast Du wohl einen defekten Chip (oder ggf. ein Problem in der Adressierung). Verändert sich das Fehlerbild, dann würde ich eher auf andere Effekte tippen...

  • Vom Fehlerbild her tippe ich entweder auf einen defekten Chip oder unpassendes Timing von EINEM Chip.

    Wenn anstatt $f6 nur $f4 zurück kommt, dann ist das imho ziemlich eindeutig.

    Wie gpospi schon sagt, tausche mal die ICs, die für die untersten zwei bits zuständig sind untereinander aus

  • ich hatte ziemlich viele defekte NEC D-Rams in letzter Zeit in den C64 ..die hatten alle -15 (vermutlich ns?)

    während die OKI -12 bislang noch NIE verreckt sind

    ich bin signifikant genug:razz:

  • Ich würde wirklich mal alle Decouplingcaps auf 100 umstellen. Ich weiß, nervt aber dann ist man auf der sicheren Seite.

    Sind bestellt.

    Also wirklich ALLE auf dem Board befindlichen 10n durch 100n ersetzen?

    Vom Fehlerbild her tippe ich entweder auf einen defekten Chip oder unpassendes Timing von EINEM Chip.

    Wenn anstatt $f6 nur $f4 zurück kommt, dann ist das imho ziemlich eindeutig.

    Wie gpospi schon sagt, tausche mal die ICs, die für die untersten zwei bits zuständig sind untereinander aus

    Da geht's schon los: Ich wüsste nicht mal, wo die ICs sitzen, die für die untersten zwei Bits zuständig sind. :)

    Wie liest du das raus? $f6? Oh mei, das ist ein rieeeesengroßer Bahnhof für mich. Da verstehe ich wirklich genau 0%. angst

    Ich kann jedoch sagen, dass das Verhalten sich mit anderen 4164 in der Tat ändert.

    Jetzt sind wieder die Bausteine drin, die Richi organisiert hatte...

    Der bisherige "Durchlauf" des RAM-Tests "hängt?" seit knapp zwei Stunden bei "going to sleep..." ohne Fehlermeldung bislang.

    Mal sehen, ob sich das Programm schlichtweg aufgehängt hat- oder es wirklich so unfassbar lange läuft?

    Evtl. auch mal prüfen, ob DRAMs von einem anderen Hersteller ein anderes Verhalten erzeugen.

    Was hatte Commodore dort original verbaut? Falls greifbar, mal damit probieren.

    Siehe oben -> Verhalten ändert sich in der Tat. Sind beides 15ns-Versionen, schnellere (überhaupt andere neben diesen 2x8 Stück) hab ich leider nicht.

    CBM hat wohl auch unterschiedliche Typen verbaut?


    ich hatte ziemlich viele defekte NEC D-Rams in letzter Zeit in den C64 ..die hatten alle -15 (vermutlich ns?)

    während die OKI -12 bislang noch NIE verreckt sind

    Defekt sollten die lt. Chiptester alle nicht sein- echt suspekt.

  • Richis Chip-Tester ist aber "unempfindlicher" als meiner ..das hatten wir schonmal - bei ein und demselben Speicher-IC hat seiner OK gegeben, meiner findet einen Fehler im späteren Test-Verlauf


    ..und wenn ich diesen IC dann im C64 drin hab, läuft der auch erstmal - steigt aber so nach ca. 10min. mit seltsamen Zeichen am Monitor aus...

    ich bin signifikant genug:razz:

  • Jetzt sind wieder die Bausteine drin, die Richi organisiert hatte...

    Das ist alles gute China-Ware :D
    RCT zeigt zwar alle OK an, aber ob die Geschwindigkeiten ausreichend sind kann man schlecht sagen. 100ns steht drauf... Was aber das wirklich genau ist kann man schlecht sagen. Ich könnte mal von einer alten RAM-Karte noch welche klauen um sowas querzutesten, auch im Bezug auf mein Problem :O Ich kann dir da auch evtl. nochmal andere zum quertesten schicken!

  • 'going to sleep' klingt doch sehr nach Refresh-Test.

    Wieviel Refresh-Zyklen werden erzeugt (Schaltung analysieren)?

    Das auch mal mit den Oszi prüfen.

    Und natürlich checken, wieviele die DRAMs brauchen (siehe Tabelle weiter oben).

    +++ ATH

  • Ach so, ja!

    $f6 hab ich bei mir schon gesehen- aber dass es sich dabei um das zweite Bit handelt, hätte ich nicht rauslesen können. ;)

    Spielt eh keine Rolle mehr, da mit dem anderen RAM-Satz keine Fehlermeldung mehr kommt (allerdings passiert nach "going to sleep" auch nix mehr :D ).


    'going to sleep' klingt doch sehr nach Refresh-Test.

    Wieviel Refresh-Zyklen werden erzeugt (Schaltung analysieren)?

    Das auch mal mit den Oszi prüfen.

    Und natürlich checken, wieviele die DRAMs brauchen (siehe Tabelle weiter oben).

    Ähm... TILT?! :wegmuss:



    Ich werde jetzt noch warten, bis die 100nF-Kondensatoren hier sind (auch, wenn Commodore definitiv 10nF verwendet hat, was man in etlichen Bildern zum Originalboard auch sehen kann)- dann löte ich die ein.


    Vielleicht hat jemand von euch noch 4164 mit 120ns oder besser 100ns Zugriffszeit(?) parat, welche er mir leihen könnte.

    Dies würde ich dann auch noch testen können.

    Mehr dann aber definitiv nicht mehr. Hier sind meine Fähigkeiten dann absolut überschritten, Jungs.


    Ich kann nur nochmal sagen:

    Beschäftigt man den Rechner mit Tastatureingaben, funktioniert es bedeutend länger. Aber: Vorhin hab ich mal ne Stunde CRSR-down betätigt, danach klappten zwar noch ein paar Tastatureingaben, wirklich arbeiten wollte das System aber nicht mehr (ERROR 215 bei Versuch, das Directory aufzurufen, also eine Fehlermeldung, die damit nix zu tun hat).


    Zusammengefasst:

    Der Memorytest des Original-MMF9000 funktioniert ja, also läuft der Rechner wohl auch als MMF9000 fehlerfrei (?).

    Dieses OS/9 mag nicht so recht.

    Ich hab einfach nicht genug Wissen (und langsam auch ZEIT), den Fehler hier zu finden. :(

    An den 50Hz zu 60Hz kann es doch ned liegen, oder? Ich weiß ja nicht, ob jemals ein MMF-Nutzer mit 50Hz-Eprominhalt in U49 OS/9 getestet hatte?


    Vielleicht können wir uns das in geselliger Runde gemeinsam ansehen?

    Also Logikanalyzer/Oszi/Leute mit WISSEN/gute Laune/etc...?


    Viele Grüsse,

    Matthias

  • Der reine MMF9000 Modus verwendet doch keine MMU, d.h. das Problem muss wohl im Zusammenspiel mit der MMU zu suchen sein -> Timing issues, schlechte Lötstelle, defekte MMU Bauteile (74LS273?), ...
    Hinsichtlich "Laufzeit" des Memorytests (bzw. Verhalten rund um "Going to sleep") könntest Du doch den Test vergleichsweise einfach mal im VICE laufen lassen (xpet +sound -truedrive -superpet -cpu6809 -model SuperPET -drive8type 8050 -8 /path/to/your/os9-systemdisk.d80)?

  • Der reine MMF9000 Modus verwendet doch keine MMU, d.h. das Problem muss wohl im Zusammenspiel mit der MMU zu suchen sein -> Timing issues, schlechte Lötstelle, defekte MMU Bauteile (74LS273?), ...
    Hinsichtlich "Laufzeit" des Memorytests (bzw. Verhalten rund um "Going to sleep") könntest Du doch den Test vergleichsweise einfach mal im VICE laufen lassen (xpet +sound -truedrive -superpet -cpu6809 -model SuperPET -drive8type 8050 -8 /path/to/your/os9-systemdisk.d80)?

    Würde ich wirklich gerne testen, aber auf meinem Lenovo unter WIN10 läuft VICE leider nicht. :(


    Ich denke nicht. Wenn ich die 8032- und die MMF9000/SuperPet-Schaltpläne auf zimmers.net richtig verstanden habe, hat der doch keine aus der Stromversorgung abgeleiteten 50/60Hz.

    Ok, dann können wir dies ausschließen. :)


    Ich brauch einfach erstmal ne Pause, sonst flippe ich hier aus und werf den ganzen Wahnsinn aus dem (Keller- was ja nichts bringen würde-)fenster. :D

    In Summe läuft der Rechner ja.


    Vielleicht kommen bald weitere Nachbauer, dann könnte man vergleichen.

    Oder aber: Zur CC (oder früher in Bayern) bisserl messen und analysieren. Also FALLS sich das jemand antun möchte. ;)

  • > Würde ich wirklich gerne testen, aber auf meinem Lenovo unter WIN10 läuft VICE leider nicht. :(

    Wieso nicht? Ich habe Vice unter Win10 und Win11 im Einsatz. Allerdings ist die SuperPET/OS9 Emulation ein wenig seltsam, weil der Start recht lange dauert (es scheint als wäre Vice "eingefroren" und man sieht im Emulationsfenster für ca. 1 Minute nur die Sanduhr). Alle anderen Emulationen sind aber im Prinzip "instantan" verfügbar.

  • Mein Tester testete die auch alle gut.

    Sowohl die von dir, als auch die acht von TI von mir. ;)

    Mit dem Allestester kann man das leider nicht testen. Der kann nur testen, ob die Chips eindeutig kaputt sind und nicht, ob sie nach Specs ok sind. Weil er sie nicht nach Specs testet. Also keine Garantie, dass die wirklich ok sind.


    Das ist hier genau so ein Fall, wo der Tester nicht weiterhilft.


    Und wie Ritchi schon sagte, "getunte" China-Chips kann er in der Regel auch nicht erkennen.