Bit 6 auf der Stackpage kippt auf "0" - oder wird hier nicht richtig geschrieben.
Ist vielleicht eine Durchkontaktierung im Daten-Pfad für das Bit 6 unzuverlässig und muß nachgelötet werden? Kleiner Haarriss?
Es scheint immer (schreibend und lesend) das Bit 6 des Datenbus vom vorheriegen Zyklus (ROM) erhalten zu bleiben.
Hast Du schon mal die Zero-Page überprüft (per ROM Tester), ob die in Ordnung ist?
Ich würde's hier auch mal mit dem Diagnose Clip versuchen. Der sollte zum Beginn Zeropage und Stack prüfen. Vielleicht bringt uns das ein wenig weiter.
Ich würde folgende Fehlerquellen vermuten:
- Der Refresh greift nicht und der Speicherinhalt geht nach einer gewissen Zeit verloren.
- Der Adressen-Multiplexer arbeitet nicht korrekt und es kommt daher zum gegenseitigen Überschreiben von eigentlich durch verschiedene Adressen getrennten Speicher.
- Der Schreib- oder Lese-Pfad verstümmelt die Daten für das RAM. Immerhin werden die Buffer in anderer Richtung genutzt.
Bei den letzten beiden Punkten kann es auch die Steuersignale betreffen, welche evtl. zu wenig oder zu stark verzögert werden. Manchmal muß man da sehr genau hinsehen.
Es wäre interessant, ob die fehlerhaften Daten reproduzierbar sind.
In den letzten 500ns wird der Datenbus D0 (hier im Bild) vermutlich von einem weiteren Teilnehmer gewaltsam auf einen ungültigen Level gezogen.
Da der 8032 bei 1 MHz in einem Takt zwei Video-RAM Zugriffe für den CRTC tätigt (dabei wird ein Zeichen zwischengespeichert), könnte es evtl. auch an diesem (Odd-) Datenweg liegen. Hast Du mal UB6 und UB7 geprüft? Oder auch UC3 für die Erzeugung von READ ODD und WRITE ODD?
Diddl hat im ersten Post meinen Artikel zittiert. Leider hat er wichtige Teile ausgelassen. In diesen wird erklärt wie die Adressdekodierung funktioniert. Das auch am Beispiel der RROITs für die CBM-Floppies. Dort wird CS1 nicht verwendet. Und CS2 ist eigentlich nur eine Negation von RS0. Das wäre prinzipiell nicht nötig und könnte anders gelöst werden.
Wie Diddl auch schon anmerkte, kann mit dem RRIOT und einer CPU ein vollständiges System aufgebaut werden. Wozu dann ein "Chip Select"? Der RRIOT ist immer selektiert, er liefert den Programmcode aus dem ROM, führt den Zugriff auf das RAM durch und liefert auch die IO-Zugriffe. Es wird also vielfach nur eine reine Adressierung (ROM, RAM, IO) benötigt. Intern werden dann aus den optionalen Adressleitungen, CS1, CS2 oder RS0 die Selektierung von ROM, RAM und IO gemacht. Genau das sind die programmierbaren Fuses im RRIOT.
In der ersten Revision des CBM-BASIC war ein Fehler, der RND(0) betrifft. Hier wurde eine VIA an Adresse $904x und nicht $E84x erwartet! Das erklärt den konstanten Wert, da hier immer das Highbyte der Adresse (also $90) gelesen wird.
Im Microsoft-Quelltext wird das als Konstante CQHTIM mit dem oktalem Wert ^O164104 (entspricht $E844) aufgeführt. Es war bei dem zweiten Abgleich (zur zweiten Revision) bereits korrigiert worden.
Commodore führt das mit der Konstanten CHTIM korrigiert fort. Weiteres unter:
Warum diese falsche Adresse hier Einzug erhalten hat, ist mir leider nicht bekannt, zumal dieser Aufruf der Zufallsfunktion mit dem Argument 0 nur in der Commodore Edition des MS-BASIC enthalten war.
MInd. ein Board erlaubte das Umschalten des IO-Bereichs von $E zu $9. Ob es damit zusammenhängt?
Habe gerade hier ein VS Express 2008 gehabt. Hab's mal kompiliert. Scheint auch unter WinXP zu laufen, mir fehlt nur das andere Ende auf COM1. 
Es gibt aber auch Warnungen beim Kompillieren. Die Logs sind im Archiv dabei, einmal Debug und einmal Release.
Viel Erfolg ...
You called the monitor via break (see the b* in the first line). The program counter (pc) is $0073. This is at the CHRGET routine. This as called to read the BASIC text or a direct line from the input buffer. This routine is a copy from $E0F9. But it seems you have bad RAM at the zero page. So the copy of CHRGET is lost and with the data byte $00 at $0073 the monitor is called.
Have a look at you DRAM!
Wenn er läuft und man nicht lädt, bleibt er sehr stabil an.
Das könnte auch auf ein thermisches Problem hindeuten. Was ich auch schon mal hatte, waren Probleme bei den Durchkontaktierungen. Die sehen zwar auf dem Foto gut aus, aber ich kenne die Unterscheite nur zum Teil. Das könnte auch die Probleme beim Laden (höhere Stromaufnahme durch den Motor) erklären.
Hier mal die Jumperbelegung von Bestückungsplan etwas übersichtlicher:
--- SH1 --- ------- SH2 -------
A B C D E F H I J K L M N P R S
- - X X - X X X X X - - - X - X 32K used with item 4116
- - X X - X - X X X - X - X - X 16K used with item 4116
- X - X X - - X X X - X - X - X 16K sub used with item 4108-30
X - - X X - - X X X - X - X - X 16K sub used with item 4108-31
- X - X X - - - X X X X - X - X 8K used with item 4108-30
X - - X X - - - X X X X - X - X 8K sub used with item 4108-31Es gibt als die Möglichkeit neben der 8 K Byte (4108-30 oder 4108-31) und 32 K Byte (4116) Bestückung auch bei der 16 K Byte auf einen Satz 4116 oder zwei Sätze 4108 zurückzugreifen. Schon sehr universell ausgelegt.
Deine Belegung nach #32:
--- SH1 --- ------- SH2 -------
A B C D E F H I J K L M N P R S
- - X - - X X X X - - - - X - X 32K used with item 33Wie Du schon schreibst sind die Unterschiede nur bei den fehlenden Jumpern D und K. Schaut man sich die Jumper auf den Schaltplänen an, findet man die Ausschlüsse. Also hier mal die Jumper, die niemals zeitgleich gebrückt sein sollten:
--- SH1 --- ------- SH2 -------
A B C - - - - - - - - - - - - - RAM type (8K-1 / 16K / 8K0) see sheet 5
- - - D - - - - - - - - - - - - ???
- - - - E F - - - - - - - - - - row selectd (8K / 16K) see sheet 6
- - - - - - H - - - - M - - - - see sheet 5
- - - - - - - I - - L - - - - - see sheet 5
- - - - - - - - J - - - - - - - see sheet 5
- - - - - - - - - K - - - - - - ???
- - - - - - - - - - - - N P - - ROM's 9, A, B (OUT / IN) see sheet 1
- - - - - - - - - - - - - - R S IO address (88xx / E8xx) see sheet 1Auffallend ist, die Jumper D und K finde ich nirgends. Mit Deiner Erkenntnis stelle ich mir die Frage, ob dieser überhaupt Kontakt haben? Dieser Frage würde ich als erstes nachgehen.
Schaue ich mir die ASSY 320351 an, gibt es dort verschiedene Versionen. darunter die 320351-05, 320351-06, 320351-11 und 320351-12 als 8 KB Version. Auf der Seite 5 findet man dann die Lösung:
Warum zwei Varianten? Und warum 8 K DRAM? Wie Christian schon schrieb war DRAM damals sehr wertvoll, so wertvoll, daß man sogar defekte Bausteine versuchte weiter zu verwenden. War ein 16 K DRAM defekt, hatte man gute Chancen, daß dies nur eine "Hälfte" betraf. Also wurden diese Bausteine nun als 8 K DRAM verkauft. Je nach nutzbarer Hälfte als 4108-30 oder 4108-31. Und auf Seite 5 des Schaltplan findet man oben links auch die passenden Brücken für die 8 K DRAM Bestückung. Drei Positionen für:
Zum "Aufrüsten" waren also nur die DRAM-Chips zu tauschen und die Brücken zu ändern. Das scheint bei Dir auch gemacht worden zu sein.
ZitatAlso müßte man den Pin 21 (A12) des 2364 auch neben der Fassung offen lassen können.
Helmut hatte es natürlich aus der "praktischen Sicht" super beschrieben. Ich vergaß dabei, daß Du schon einen Adapter-Sockel hast. Da macht es dann auf jeden Fall Sinn, mit weiteren (Low-Cost) IC-Fassungen "Türmchen" zu bauen um diesen Pin 21 "aufzutrennen" (und auf Isolation achten) um diesen dann gesondert zu beschalten.
Nun ein 8 KB-ROM kann man unter Umständen auch zur Hälfte über einen Steckplatz der für 4KB-ROMs vorgesehen ist auslesen. Wie der Zufall so will unterscheiden sich 2332 (4K) und 2364 (8K) nur durch Pin 21. Beim 2332 ist das ein weiteres (bei Commodore high-aktives) Chip-Select und beim 2364 eine weitere Adressleitung A12. Solange man auf das Chip-Select verzichten könnte, würde man (durch das high-aktive) den oberen 4 KB-Teil auslesen können, wenn man das ROM direkt in den Sockel steckt.
Aber ACHTUNG, die Chip-Select-Leitung des Boards führt nun zu A12 des ROMs. D.h. das 2364 liefert u. U. auch Daten (den unteren 4 KB-Teil), wenn das 2332 deselektiert wäre. Das kann zu Kurzschlüssen führen!
Nun wäre es wichtig zu wissen, welche Board Du verwendest. Schaue ich mir die ROMS von 8032029 an, wird hier nur das /NOROM-Signal als weiteres Chip-Select (Pin 21) verwendet. Dieses kommt von einem nicht beschalteten Pin der 6502. Erst mit einer Erweiterung sollte das Signal eine Rolle spielen.
Also müßte man den Pin 21 (A12) des 2364 auch neben der Fassung offen lassen können. Dieser offene Pin ist dann mit GND auf log. 0 zu legen, damit der untere Teil ausgelesen wird oder auf VCC (+5 V) auf log. 1 zu legen um den oberen Teil auszulesen. Also eine kleine Art des Bank-Switching. Man könnte auch ein Bit des User-Ports nutzen.
Die Anpassung der Bildwiederholrate an die Netzfrequenz ist definitiv kein "Unfug". Das haben alle Hersteller gemacht. Auch die TV-Normen passen sich dem an. Neben der EMV (Elektomagnetischen Verträglichkeit) spielt auch die Raumbeleuchtung eine große Rolle. Immerhin "flackert" das Bild (entsprechend der Nachleuchtkraft der Bildröhre) mit der Bildwiederholrate. Solange die Raumbeleuchtung nun mit der gleichen Frequenz "flackert", entsteht nur eine Schwebung, die man kaum wahrnimmt.
Die PET ohne CRTC erzeugen die Videosigale (damit auch die Bildwiederholrate) fest auf 60 Hz.
Beim CRTC kann dieser neben der Vorgabe des Editor-ROM (siehe auch hier oder hier) jederzeit umprogrammiert werden. Jedoch werden bei 60 Hz weniger Rastterzeilen pro Bild dargestelt. Damit kann es sein, daß die Bildgeometrie des Monitors angepaßt (eingestellt) werden muß.
Das Editor-ROM unterscheidet sich neben den angepaßten Werte für den CRTC auch in der Interrupt-Routine. Diese ist immer für 60 Hz ausgelegt. Bei 50 Hz wird bei jeder fünften Auslösung die Routine doppelt ausgeführt. Die Jiffy springen dann um zwei.
Es scheint so, daß es dort noch Modelle mit einem bestücktem Centronics-Ausgang gibt. Das würde den unbestückten Teil neben dem IEEE-488 Eingang erklären. Die passenden Portzugriffe scheinen im vorhandene Programm-Code nicht vorhanden. Also muß es weitere EPROM-Versionen geben.
Ab 2 bis zu 4 Festplatten braucht man für jede HD das 20 polige Kabel B zusätzlich.
Oder wir bei der Hübner & Worm HD24 einen zweiten 50 pol. Anschluß.
Die Geometrie müßte bei der 24 MB Festplatte 4 Köpfe, mit 244 Zylinder bei 48 Sektoren mit 512 Bytes pro Spur sein.
Bitte auch beachten, daß ein Trafo mit der Zeilenfrequenz schwingen kann. Hier wären es je nach Bildröhre (und Editor-ROM) 20 oder 17 kHz. Das kann auch die mechanische Belastung des Zeilentrafos auf die Platine verstärken. Die Idee mit dem Silikon als Kleber für den Zeilentrafo erscheint mir logisch.
Siehe auch hier eine Seite von André. Im Prinzip ist der 6545 nichts weiter als mehrer Register und Zähler.
Ich hab diverse verschiedene MC6845 getestet - und keiner lief im 8032 oder 8296.
Dann bliebt die spannende Frage nach dem "warum".
Hier hatte ich mal die verschiedenen Register abhängig vom Editor-ROM ausgeführt. Mir fällt dabei nichts weiter auf. Oder ist es nur ein Timing-Problem? Nur meines Wissens wird der CRTC nur einmal zum Start initialisiert. Später gibt es normal keine weitere Zugriffe. Der Cursor wird nicht über den 6545 erzeugt, sondern über Software in der Interrupt-Routine.
André zeigt hier gut die Unterschiede zwischen den verschiedenen Typen/Herstellern auf. Spannend ist dabei, daß der (oben nicht funktionierende) Motorola 6845 mit dem (von Commodore genutzen) Hitachi 46505 gleichgesetzt wird. Ich bin auch etwas verwundert, daß der nicht funktionierte und vermute hier eher einen anderen Fehler.
HIer eine Variante für die Gleichungen des 82S123:
D7 = Not(Not(A3) And A1)
D6 = 0
D5 = A1 And Not(A0 Or A3 And A2)
D4 = A1 And (Not(A3) And A2 And Not(A0) Or Not(A2) And A0)
D3 = A1 And (Not(A3) And A2 And A0 Or A3 And Not(A2) )
D2 = Not(Not(A4) And A1 And (A3 Or A2 Or A0) And Not(A3 And (A2 Or A0)))
D1 = A3 And Not(A2) And A1 And Not(A0)
D0 = Not(A3 And Not(A2) And A1 And A0 )Nun müßten wir noch A0 (Pin 10), A1 (Pin 11), A2 (Pin 12), A3 (Pin 13), A4 (Pin 14), D0 (Pin 1), D1 (Pin 2), D2 (Pin 3), D3 (Pin 4), D4 (Pin 5), D5 (Pin 6), D6 (Pin 7) und D7 (Pin 9) mit Namen füllen. Wie ich sehe kommen die Adressen alle vom 374 (A0 von Pin 9, A1 von Pin 15, A2 von Pin 6, A3 von Pin 5 und A4 von Pin 16). Jedoch sehe ich auch, daß einige Daten zum 374 gehen. Das wären mind. Pin 3 (D2) zu Pin 18 des 374 und Pin 6 (D5) zu Pin 8 des 374 kommt. Also gibt es mind. eine Rückkoppelung zwischen D5 und A0.
Das VSYNC Signal kommt aus PIN40 des 6545 und geht danach über 7486(UC2) an den Ausgangspin des Monitorsteckers. ABER es geht auch noch irgendwo anders hin, dahinter steht eine 3. Heißt das, man muss auf Blatt drei kucken?
Völlig korrekt. Das vertikale Synchronisationssignal kommt aus dem 6545. Leider ist der bei Dir nicht gesockelt, sonst könnte man den mal tauschen. Mit dem folgendem 74LS86 kann die Polarität gewechselt werden. Der Abgang zum Blatt 3 führt dann auf die Eingänge für den Interrupt. Das müßten CB1 der PIA1 und PB5 der VIA sein.
Da keine Eingaben über die Tastatur möglich sind, könnt es sein, daß dieses Signal eben fehlt oder gestört ist. Folgende Fehlerquellen sind denkbar:
Es bleibt natürlich die Frage des Grundes. Evtl. wurde vom Monitor etwas zurückgespeist. Das könnte PIA1, VIA und 74LS86 beschädigen.
Am 3032 ($b000) habe ich das Basic Programms Tool.
Das sollte aber nur 2 KB belegen. Das 2716 könnte man gegen ein 2532 ersetzen und die restlichen 2 KB nutzen.
Viele Prommer unterstützen nur den 2732. Dann muss man sich einen Adapter bauen und 3 Anschlüsse drehen.
Vorsicht ist geboten. Ich meine mit den 2732 kamen weitere Programmierverfahren auf. Normal war zu dieser Zeit ein Programmierimpuls von 50 ms. Da dauert das Programmieren schon mal einige Minuten. Bei den neueren Programmierverfahren hatte jeder Hersteller sein eigenes Verfahren. Teilweise wurde auch die Versorgungsspannung erhöht. Das klappt meines Wissens nicht bei dem 2532. Also aufpassen, welches Programmierverfahren der EPROMer für 2732 verwendet.
es sind alles programmierbare Logikbausteine.
Das sehe ich anders. Es Ist in meinen Augen keine Logik. Es ist ein normales ROM mit dem GCR-Daten (bzw. binären Daten) auf der Adresseingang und den binären Daten (bzw. GCR-Daten) auf dem Datenausgang.
Bei der Dekodierung (binär nach GCR) kommt ein wenig Logik ins Spiel. Diese befindet sich aber NICHT im ROM, da dieses nur acht Ausgangsbis hat, aber zehn Bits benötigt werden.
Das 2716 wird dort ja nicht als Programmspeicher verwendet...
Nun nicht als Programmspeicher, aber als Datenspeicher. Es ist definitiv im Datenpfad eingekoppelt.
Aber gut, wir wissen nun, was Du meinst. Magst Du das ROM mal auslesen? Die Position des ROMs läßt leider nichts genaues vermuten. Fakt ist aber, daß der 273 die Datenleitungen speichert. Der 393 vermutlich einen Teil der Adressleitungen speist. Es könnte also ein Generator oder gar eine State-Machine sein. Es gibt da noch ein weiteres ROM: 82S123. Das sollte die nötigen Taktsignale (/RAS, /CAS, MUX ...) erzeugen.
Auf dem Controller ist auch ein 2716, welches als PLA verwendet wird - genau wie in den CBM Laufwerken...
Wie meinst Du das? Mir ist nicht bekannt, daß die CBM Laufwerke eine PLA nutzen. Einzig der GCR-De- und Encoder (901467-01) ist bei einigen Laufwerken mit Hardware-Dekodingung vorhanden.
Zum Glück war ja nicht so viel defekt, so daß ich die schöne HD wieder zum Laufen bekommen habe!
Was hatte die "Kleine" denn?
Das ganze geht nur dann gut, wenn das Gerät ebenfalls noch mit dem Schutzleiter verbunden ist.
Und auch überall einen sehr guten Kontakt zur Ableitung hat. Jede Steckverbindung z.b auch bei Mehrfachsteckdosen minimiert diesen. Bei Hochspannung können da auch bei geringen Schleifenwiderstand schon mal einige Volt abfallen.
Das ganze hat Ähnlichkeit mit einem Blitzeinschlag. Es wurde dabei eine Fremspannung über den Schutzleiter zum Meßgerät eingespeist. Genau dieser Teil ist hier genauer anzusehen.
Das ROM meldet sich aber offenbar mit "H & W DISK VERS. 1.2". Das steht etwas im Widerspruch zu dem ROM-Dateinamen V11A. Ich habe auch mehr den Verdacht, auf dem Label der ROMs steht VIIa (das könnte eine römische sieben oder auch nur zwei sein). Darunter ist eine 12.3 vermerkt. Das Handbuch beschreibt auch eine VERS. 1.0. Alles sehr verwirrend.
Scheinbar eine 6809 Implementierung eines CBM-DOS ähnlichen System. Das hatten wir bei der SSE Hardbox schon einmal für den Z80.
Das ist ein sehr spannendes Gerät. Herzlichen Glückwunsch, wxo hast Du das her?
BNE *3
JMP xxxx1
Assembler mit Macros nutzen dafür häufig das Macro:
jeq xxxx1Dann würde es noch lesbarer ...
