BeitrÀge von mantillo

    Bitte melde dich an, um diesen Link zu sehen.

    Wie auf dem Video hinter obigem Link zu sehen,
    arbeitet(-e?) jemand namens Glen Kleinschmidt an einem PET 2001 - Prototyp.

    Hat jemand da weitere Infos zu (gefunden), eventuell auch zu alternativen Projekten?

    Mit dem Tynemouth-Board funktioniert es (kam inkl. CPU)!

    Im Test-Modus (Zeichensatz-Anzeige & erste 1024 Bytes ĂŒberprĂŒfen) des Boards sieht alles gut aus.

    Bonus:

    Es funktioniert sogar, wenn ich weder ROM, noch RAM ersetzen lasse!
    D.h., nur der 6502 scheint keine Lust mehr zu haben. :smile:

    Als nÀchstes werde ich den RAM einmal durchtesten
    und eventuell nur den anderen 6502 einsetzen (wenn ich ich mich traue..).

    Danach kommen die scheinbar funktionierenden ROMs und RAMs dann in Sicherheitsverwahrung.

    Aber schön, wenn ich mir eine weitere 6502 organisiere,
    habe ich (so wie es jetzt aussieht) einen komplett ohne ROM-/RAM-Adapter funktionierenden PET.
    Das schreit ja nach der Anschaffung eines weiteren PETs.. 8-O

    Bitte melde dich an, um diesen Link zu sehen.

    Danke fĂŒr den Tipp mit dem Logiktester.

    Das Board ist von Tynemouth.
    Mehr oder weniger die einzige Quelle momentan
    (es sei denn, man ist löttechnisch begabt und mehr).

    Ja, der PET macht einen guten Eindruck.

    Die Delle ist wÀhrend des Versands passiert.
    Kombination optimistisch verpackt plus "RĂŒpel" beim Paketdienst kommt nicht so gut..
    Aber das kann man bestimmt korrigieren.

    Wie sieht die RESET-Leitung aus, hast du Möglichkeiten deren Pegel zu bestimmen?
    Zumindest den "statischen" Pegel. Fehlermöglichkeiten: a) "stuck low" b) "no pulse"

    Am _RST - Eingang des 6502 (Pin 40) liegen ~3,6V an. Ist es sinnvoll, das noch woanders zu ĂŒberprĂŒfen?

    Am User-Port (?) des PET so wie ich ihn kenne gibt es auch einen Diagnostic-Eingang, an dem man einen Taster (gegen GND) anschließen kann. HĂ€lt man diesen gedrĂŒckt wĂ€hrend dem Einschalten bzw. RESET, springt das Kernel-ROM in den TIM-Monitor (Maschinensprachmonitor). Meines Wissens geschieht das vor dem Anspringen des Basic-ROM. es gibt so eine schwache Chance, dass ein defektes Basic-ROM sich so "umgehen" lĂ€sst. Wenn statt des Basic- das Kernel-ROM selber defekt ist, vermindert sich diese Chance.

    Es hĂ€ngt aber von der Version des PET ab bzw. welche Firmware drin ist, weiß nicht ob schon die ganz alten den Diagnostic-Eingang ausgewertet haben.

    Ich werde mich noch ĂŒber den Diagnose-Eingang informieren - danke. Wahrscheinlich hat der PET noch keinen eingebauten TIM (da Basic 1 ROM). Aber bei mir lief er noch nie, deswegen weiss ich das nicht.

    * Die Chip-Select-Leitungen vom Decoder 74154 zu den Roms verfolgen und auf DurchgĂ€ngigkeit messen (dabei auf Möglichkeit zu hoher Meßströme und oder statischer Entladung achten; ich verwendete dafĂŒr frĂŒher meist ein Zeiger-Multimeter mit schwacher Batterie ~ 0,8 Volt im Meßbereich "niederohmig"--> dann fließt besonders wenig Meßstrom)

    Ich habe nur ein digitales Multimeter - vielleicht sollte ich das lieber lassen..?

    Da die Video-Logik ganz offensichtlich "arbeitet" und das Video-ROM offensichtlich intakt ist, denn sonst wÀren keine Zeichen identifizierbar (R,S,T,Q .. A,E,P,Y ..) kommt mir noch folgende verwegene Idee:

    Falls das Character-Generator-ROM das du oben "Video-ROM" genannt hast, ein 2 KB großes 6540 ist und der Kernel aus 2 dazu pinkompatiblen weiteren 6540 besteht,
    ... könnte man probehalber das Character-Generator-ROM aus dem Sockel entfernen und sicher beiseitelegen
    und dann
    ... die beiden Kernel-ROMs jeweils einzeln probehalber als Character-Generator-ROMs "temporÀr" einsetzen.
    So mĂŒsste sich zumindest grob abschĂ€tzen lassen, ob grĂ¶ĂŸere "eintönige" FarbflĂ€chen, oder feingrieselige Bitmap-Strukturen sich ergeben. In ersterem Fall ist das ROM stĂ€rker beschĂ€digt (Datenleitungen verklemmt) als in letzterem (evtl. nur einzelne Bitfehler oder gar intakt).

    Das wÀre eine primitive Möglichkeit das Kernel-ROM irgendwie "auszulesen" auch ohne Eprom-Brenner / Ersatzrechner / Adaptersockel.

    Unter der Annahme, dass Ă€hnliche Bausteine mit Ă€hnlichem Herstellungsdatum sich auch in der Haltbarkeit Ă€hneln, spricht ein intaktes "Video_ROM" allerdings dafĂŒr, dass auch die Kernel-ROMs noch intakt sind (Spekulation).

    Das meinte ich mit:

    - Wenn das Video-ROM durch jeweils eines der anderen ROMs ersetzt ist, zeigt der Monitor ein stabiles, zufÀlliges Pixel-Muster an. => OK.

    Die ROMs sind also wahrscheinlich OK (der Test ist natĂŒrlich nicht 100%'ig).

    Danke fĂŒr Eure Antworten soweit! SpĂ€testens, wenn ich eine ROM/RAM - Ersatzplatine hier habe, wissen wir konkretes (dauert noch ein bisschen).

    Noch etwas getestet (siehe Bitte melde dich an, um diesen Link zu sehen.:sad:

    - SYNC an der CPU ist ~0V
    - A15, A14, A13 und A 12 sind alle auf "1" (allerdings jeweils nur ~3,6V - ist das normal..?).

    Die in dem Thread (siehe Bitte melde dich an, um diesen Link zu sehen. oben) beschriebene Situation ist aber nicht ganz die gleiche, da der Bildschirm bei meinem PET nicht schwarz wird.

    1. Ist der Motor der eingebauten Datasette bei entriegelten Tasten (= nichts gedrĂŒckt) auch im Dauerlauf, wĂ€hrend die Zufallszeichen am Schirm sind? Oder steht der selbige still?

    2. ist - wenigstens schemenhaft angedeutet - der Anschein eines mit 2 Hz blinkenden Cursor da zu erkennen, wo er normalerweise zu sehen ist? (unter dem READY.)

    3. FĂ€ngt der Motor an zu drehen, wenn man probehalber PLAY drĂŒckt? und hört wieder auf zu drehen wenn man die Play - Taste wieder entriegelt /ausschaltet?

    Falls der Motor nicht auf das Play-DrĂŒcken reagiert, wĂ€re m.E. ein Defekt der RESET-Schaltung oder des Prozessor 6502 möglich.

    1. Ja, man hört ohne gedrĂŒckte Datasette-Tasten, dass in der Datasette etwas "lĂ€uft" (wird wohl der Motor sein..).

    2. Nein, es ist kein Cursor zu sehen, auch nicht andeutungsweise.

    3. Ja, nach DrĂŒcken der Play-Taste der Datasette sieht man, wie sich das rechte "Drehdings" (sorry..) bewegt. Und ja, wenn man auf die Stop-Taste drĂŒckt, dreht sich nichts mehr (den Motor hört man aber noch laufen).

    Danke, Stephan!

    Der PET 2001 (YEAH! - siehe Bilder) bleibt nach dem Einschalten bei der Bildschirm-Ansicht mit den Zufallszeichen stehen.

    Bitte melde dich an, um diesen Anhang zu sehen. Bitte melde dich an, um diesen Anhang zu sehen.

    Zu dem GerÀt:

    - PET 2001-8C.
    - Assembly 320008.
    - Mit 6550 RAMs und 6540 ROMs.

    Eventuell hat ja jemand mit Ahnung (die ich nicht habe..) aufgrund meiner Beschreibung unten eine Idee.
    Mit einem ROM/RAM - Adapter werde ich das demnÀchst ansonsten auch nocheinmal probieren.

    Was ich bisher gemacht habe:

    - Alle gesockelten ICs herausgenommen, Sockel und IC-Beine mit ZahnbĂŒrste abgebĂŒrstet [ ohne Zahnpasta :wink: ] - sah eh alles recht sauber aus - wieder hereingesteckt.
    - Spannung an den vier Spannungsreglern (links nahe der Stromversorgung, jeweils mittleres und rechtes Bein, wenn man vor dem Computer steht) gemessen (~5V). => OK.
    - Bei allen gesockelten ICs VCC (~5V) und VSS (~0V) gemessen. => OK.
    - Bei allen gesockelten ICs Phi / CLK - Spannung (mit Multimeter ~1.86V) gemessen. => Ist OK, oder?
    - Wenn beide Video-RAMs entfernt sind, zeigt der Monitor das Schachbrettmuster. => OK.
    - Wenn das Video-ROM durch jeweils eines der anderen ROMs ersetzt ist, zeigt der Monitor ein stabiles, zufÀlliges Pixel-Muster an. => OK.
    - Wenn ich beide PIAs und alle Arbeitsspeicher-RAMs, bis auf die "ersten" 4 (I1, I2, J1 und J2) herausnehme, Àndert das nichts. => Schade!
    - Ohne PIAs und mit nur 4 RAMs (siehe letzter Punkt) die Video-RAMs und/oder 4 eingesetzten Arbeitsspeicher-RAMs durch andere (mehr oder weniger wild und sinnlos) austauschen, fĂŒhrt zwar teilweise zu anderen Mustern auf dem Bildschirm, aber zu keiner Verbesserung. => Schade!
    - Ist einer der ICs auffallend heiß? => Nein, zumindest die RAMs und ROMs sind alle gleich warm/heiß.

    Danke fĂŒrs Lesen und eventuelle Ideen!

    Hier meine Quellen:

    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.

    Nachdem ich das gesamte Internet (na gut, vielleicht nicht ganz..) durchforstet habe,
    bin ich zu dem Schluss gekommen, das man originale Amiga 500 - Netzteile immer noch ohne Angst vor Zerstörung des
    Rechners bei Netzteildefekt (so wie beim C64) verwenden kann.

    Außerdem scheinen die Netzteile ja recht robust zu sein(?).

    WĂŒrdet Ihr mir da so zustimmen?

    Ich Frage, weil ich mir einen Amiga 500 ohne Netzteil organisiert habe
    und mir gar nicht erst ein altes NetzgerÀt kaufen möchte, falls davon abzuraten ist und es gute Alternativen gibt.

    Der Mega-Bastler bin ich aber auch nicht,
    sowas hier

    Bitte melde dich an, um diesen Link zu sehen.

    muss ich nicht unbedingt selber machen.. :)

    Nebenbei: FĂŒr den C64 habe ich diese Anleitung befolgt:

    Bitte melde dich an, um diesen Link zu sehen.

    Bei mir will es eben nicht. Die 3 Dateien sind natĂŒrlich alle im selben Verzeichnis.
    Jetzt hab ich grad nochmal meinen alten Win2k-Rechner aufgebaut und getestet, damit ging es :) Dort ist aber auch Python drauf, auch haben sich da diverse vb-dll oder .net-Dateien angesammelt. FĂŒr eine klare Aussage, was fehlt, reicht das natĂŒrlich nicht.

    Ich habe nicht darauf geachtet (vielleicht geht das auch gar nicht?), die EXE-Datei DLL-unabhÀngig zu kompilieren (habe VS Express 2005 verwendet).
    Also entweder die zu VS2005 passenden Runtime Libraries installieren (keine Ahnung, welche das sind..),
    oder den Source Code mit einem anderen Compiler ĂŒbersetzen.

    Beim nÀchsten Release werde ich versuchen, keine Library-AbhÀngigkeit hineinzukompilieren. :)

    Mit Python hat das nichts zu tun (siehe C++ Source Code), enthusi's tolles png2hires - Tool ist aber ein Python Skript.