CBM 3032 kein Basic, nur Maschinensprache-Monitor

Vielen Dank für die Hinweise.

Mit dem Speichertest Programm von Apple konnte ich leider nicht viel anfangen.

Was mehr daran liegt, dass ich keine 6502 Maschinensprache kann.

Auch habe ich keinerlei Entwicklungsumgebung, Assembler etc..

Weswegen ich mich in den letzten Tagen erstmal mit dem 6502, dessen Registern und Befehlssatz versucht habe vertraut zu machen.

Mit einem einfachen 6502 Emulator für Anrdoid ist es mir dann gelungen ein kleines rudimentäres Testprogramm selber zu coden.

Weil ich noch nichts speichern kann und alles eintippen muss und obendrein damit rechnen muss, dass ich alles gleich wieder verliere, falls sich der Rechner aufhängt, soll es natürlich auch entsprechend kurz werden.

Raus gekommen das was man auf den Bildern sehen kann. Das Programm (im Bild gelb eingekastelt) ist 49 Byte lang und fängt bei $0600 an (was daran liegt, dass der Emulator immer nur bei dieser Stelle sein Programm ablegt was nicht verschiebbar ist. Um keine Sprungmarken umzurechnen habe ich das beibehalten).

Es beschreibt mit einer 1. Schleife einen Speicherbereich, der max. $FF lang sein kann, mit einem Prüfbyte und vergleicht anschliessend in einer 2. Schleife ob im Speicherbereich auch überall das Prüfbyte drin steht. Bei der ersten Abweichung wird das Programm beendet und noch der Adress-Offset der Fehlerstelle in die Zeropage gerettet. Das Lowbyte der Anfangsadresse vom zu testenden Speicherbereich ist z.Zt. immer mit $00 vorgegeben.

Ein paar Erläuterungen:

1. Hier wird das Hi-Byte des zu testenden Bereichs bestimmt.

2. Anzahl der zu testenden Bytes.

Im Beispiel ergibt sich aus 1. u. 2. ein zu testender der Bereich von $0700 - $07FF.

3. Das Prüfbyte mit dem der Speicherbereich beschrieben wird.

4. Dieser Codeabschnitt, zwischen den beiden Schleifen, ist eigentlich überflüssig. Es wird ein beliebiges Byte geladen und an eine beliebige Speicherzelle geschrieben. Das dient nur dazu das Programm ggf. selbst zu überprüfen, in dem man eine "Fehlfarbe" dort hinschreibt, wo in der Schleife zuvor gerade mit dem Prüfbyte gefüllt wurde. Im Beispiel lasse ich $91 ans Ende des verwendeten Programmbereichs schreiben.

Um das Programm auszuführen gibt man

G 0600 ein.

Es erscheint wieder der Prozessorstatus, man sieht am PC schon ob das Programm gut (wird bei 062C verlassen) oder mit Fehler abgebrochen wurde (0631).

Als nächstes lasse ich mir mit

M 0088 008F

einen Abschnitt der Zeropage anzeigen. Falls mit Fehle abgebrochen wurde könnte man in $8C den Offset zur Startadresse des Testbereichs sehen.

Dann der Vollständigkeit halber das Programm-"Listing".

Und zuletzt noch ein Abschnitt des testweise beschriebenen Bereichs.

Ggf. kann man dann die nummerierten Felder ändern und einen anderen Bereich testen.

Das Programm hat noch die Macke, dass es einen Überlauf erzeugt, sodass man nicht einen Bereich von z.B. $0700 - $07FF sondern von $0701 - $0800 testet (sieht man unten im Bild wo an $0700 noch ein $AA steht). Den Fehler habe ich inzwischen gefunden, nur habe ich gerade kein aktuelleres Bild.

Natürlich ist das Programm sehr rudimentär und man kann damit auch nicht alles herausfinden, insbesondere wenn man den Speicher wie im Beispiel mit $55 beschreiben lässt - könnte ja sein dass es ausgerechnet ein von $55 nicht gesetztes Bit erwischt hat. Es findet auch keine Fehler, die durch "bleedig"-Effekte in einer benachbarten Speicherzelle entstehen. Also man beschreibt $xxxx aber in $xxxx+1 landet der gleiche Wert, weil die interne Adressverarbeitung vom Chip nicht i.O. ist.

Als nächstes möchte ich noch ein Programm machen, dass den Speicher abwechselnd mit $55 und $AA beschreibt - mehr als Programmierübung.

Jedenfalls konnte ich mit dem Programm bis jetzt keine RAM-Fehler finden.

Immerhin, trotz dass der Rechner nicht wirklich funktioniert konnte ich ein erstes Programm laufen lassen ;-).

Dabei fällt mir noch folgende Frage ein:

Wieviel Speicher, besser welcher Bereich, muss eigentlich mindestens i.O. sein, damit das Basic einwandfrei läuft bzw. startet?

Eine defekte Speicherzelle an z.B. $74FF sollte ja zunächst nichts ausmachen...

Wenn der Rechner neu startet beschreibt er ja einen grossen Teil des Speichers mit $AA. Das ist bei mir ab $0403 der Fall.

Die Zellen bis $0402 sind mit div. Bytemustern beschrieben.

Dann noch etwas:

Testweise habe ich eine alte Datasette angeschlossen. Sowohl an den internen als auch externen Anschluss.

In beiden Fällen scheint es so als ob der CBM etwas auf Kassette schreiben möchte, nur einlesen will es nix.

Wobei ich noch nicht sicher bin ob überhaupt etwas auf die Kassette gelandet ist. Jedenfalls funktioniert zumindest das mit der Motorsteuerung und im Schreibfall geht auch die Save-LED an der Datasette an.

Im übrigen ist inzwischen das EPROM-Programmiergerät eingetroffen, nebst ein paar anderen E-Teilen.

Leider fehlen mir noch die 2532er EPROMs - die sind zwar auch bestellt, weiss nur nicht wann die eintreffen.

Hurra er geht wieder!!!

Heute ist das richtige Eprom-Programmiergerät eingetroffen. Den ersten Epromer, der letzte Woche eingetroffen ist, musste ich umtauschen, weil es keine 2532er konnte (hatte die falschen Specs gelesen).

Habe gleich alle 4 Eproms gebrannt und eingesetzt.

Nach dem ersten Einschalten "NEW" eingegeben und siehe da der Cursor kam wieder zurück.

Aber beim Versuch die erste Basiczeile einzutippen hat er sich irgendwie aufgehängt.

Es halfen auch keine Resets. Manchmal kam nicht mal das "READY" nach dem Einschalten sondern nur das "R" ohne blinkenden Cursor und/oder die Tastatur hat irgendwie falsche Zeichen hervorgebracht.

Wegen den komischen Zeichen von den Tasteneingaben geriet gleich das EPROM an $E000 - $E7FF in Verdacht, weil dort wohl Zeichensätze drinnen sind - so wie das verstanden habe. Als ich das dann gegen das Original ROM zurück getauscht habe hat er funktioniert.

Möglicherweise habe ich es mit der falschen Datei gebrannt?

Folgende Dateien (von der Zimmers-Seite) habe ich gebrannt:

IC Nr.; Adresse; CBM-Teilenr.; Bezeichnung auf Zimmers Webseite

UD6; C000-CFFF; 901465-01; Basic 2

UD7; D000-DFFF; 901465-02; Basic 2

UD8; E000-E7FF; 901447-24; Basic 2 E000-E7FF (PET)

UD9; F000-FFFF; 901465-03; Kernal for Basic 2

Dabei habe ich mich an den CBM-Teilenrn. (901xxx-yy) orientiert, wie sie auch auf den originalen ROMs drauf stehen. Das EPROM < UD8; E000-E7FF; 901447-24;> habe ich auch nur auf 2KB Länge gebrannt. Weil die Datei entsprechend kleiner ist, was wohl daran liegt, dass der IO-Bereich ab $E800 anfängt.

Würde aber gerne alle ROMs durch EPROMs auschtauschen, alleine schon, weil die neuen nicht so warm/heiss werden.

Sollte ich es mit einer anderen ROM-Datei versuchen, falls ja mit welcher?

Hm, habe gedacht ich bin clever und lese das alte funktionierende ROM, UD8 $E000, aus und brenne damit ein Eprom - denkste. Zuerst habe ich an einem erfolgreich ausgetauschten ROM getestet ob der Eprom-Brenner überhaupt ROMs lesen kann - tut er. Also das ROM in ein Eprom kopiert. Hat nur nicht funktioniert, also das kopieren schon, nur wollte der Rechner damit nicht.

Dann habe ich die ROM-Datei von Zimmers mit der von mir ausgelesenen ROM-Datei und dem was auf dem Eprom ist im Hexeditor verglichen - alles gleich. Vielleicht liegt es am Eprom - zu langsam?

Danke für den Hinweis.

Dachte der ungenutzte Adressbereich wird für das (EP)ROM einfach ausgeblendet und das entsprechende CS-Signal ist im Bereich von $E800-$EFFF inaktiv. Sehe aber dass die CS-Signale für die ROMs alle aus dem selben 74154 Dekoder stammen und da nichts weiter dazwischen ist - von daher eigentlich logisch. (Möglicherweise lässt sich ein 2532 verwenden, wenn man ein Hilfsgatter vor das CS-Signal klemmt und die passende Adressleitung ausklamüsert.)

Wie dem auch sei, ich lasse erstmal das eine ROM so wie es ist - funktioniert ja und wird auch nicht so heiss, wie die anderen (defekten) ROMs. Bei Gelegenheit werde ich mir mal 27/2516er organisieren.

Ansonsten muss ich nochmal an den Monitor ran und mache mich so langsam über die nicht funktionierende Datasette und das Doppelfloppy her. Beim Floppy lässt sich nur das rechte Laufwerk ansprechen und macht nur Track-Errors. Immerhin scheint das IEEE-Kabel, der Port vom 3032 und die Digitalplatine vom Floppy gefühlt i.O. zu sein. Die Datasette scheint nur zu schreiben, aber das Rücklesen klappt nicht.

Vermutlich geht das nicht.

Denn der Chip wird über das CS-Signal aktiviert (CS="Chip Select", bei den EPROMs heissen die dann gerne "E" o. "EN" für enable). Dieses kommt vom Adressdekoder der in 4KB-Blöcken die CS-Signale generiert. D.h. auch bei Adressen die zwischen $E800 und $EFFF würde dann ein 2532er Chip aktiviert werden. Wenn er aktiviert ist, geben die Datenleitungen Signale auf den Datenbus und diese kollidieren dann mit dem IO-Bereich, der im selben Adressbereich liegt.

Alle ROMs sind am Datenbus direkt parallel geschaltet (wo auch der IO-Bereich drauf geschaltet wird), kommen sich aber nicht in die Quere. Denn wenn sie per CS deaktiviert sind, werden die Ausgänge vom Bus weggeschaltet (bzw. sind dann hochohmig).

im Schaltplan sieht man, dass bis auf die CS-Signale alles parallel ist

Mein Irrtum war, dass ich dachte, der besagte IO-Bereich würde vom besagtem ROM ferngehalten indem das CS-Signal vom Adressdekoder dort deaktiviert wird, was aber nicht der Fall ist.

Würde man nur die eine Adressleitung Chipseitig auf low legen, würde der Chip nach wie vor aktiviert werden nur dass eben der untere Bereich von $E000-$E7FF in den oberen $E800-$EFFF gespiegelt wäre, weil das EPROM dann den Unterschied nicht mehr erkennt.

Damit stellt sich die Frage wie das bei einem 2KB ROM bzw. 2516er EPROM dennoch funktionieren kann.

Dazu musste ich eben mal nach einem Datenblatt googeln. Und siehe da, dort wo die 2532er ihren A11-Adressanschluss haben, hat der 2516 einen PD/PGM Anschluss (der Rest ist pinkompatibel). PD steht für power down. Der Anschluss wird Chip-intern mit dem CS-Signal verundet. Sodass der Chip trotz aktiven CS-Signal inaktiv wird, wenn die A11 Leitung high wird.

Wenn man das mit einem Zwischensockel lösen wollte, müsste man ein kleines Gater mit dazu bauen, welches dem CS bzw. Enable vom 2532 vorgeschaltet wird. Es müsste sinngemäss die Funktion "CS und_nicht A11 = neues CS" haben.

Deswegen funktioniert es leider nicht, indem man die A11 Leitung vom 2532 auf 0 oder 1 klemmt oder die unter Hälfte vom EPROM in die obere kopiert.

Entscheidend damit es funktioniert ist, dass die Ausgänge vom Chip von $E800 bis $EFFF wegschaltet bzw. deaktiviert werden. Dies erreicht man eben nur über das CS-Signal bzw. beim 2516 über den zusätzlichen PD Eingang, welcher genau dort liegt, wo der 2532 seinen A11 Eingang hat (siehe Tabelle von mikemcbike).

Genau genommen wurde es von Commodore nicht ganz sauber gemacht. Besser wäre es wenn sie noch ein, zwei Gatter genommen hätten die das CS-Signal "SEL E" im Bereich ab $E800 bis $EFFF auf 0 gebracht hätten. Die waren aber wohl nicht "übrig".

Zumindest hätten sie im obigen Schaltplan, wo der Chip mit dem Adressbereich nicht ganz richtig mit $E000 bis $EFFF angegeben ist, eine entsprechende Notiz ergänzen sollen.

Dann hatte ich noch einen weiteren Teilerfolg:

Die Datasette geht inzwischen wieder.

Sodass ich jetzt auch speichern kann, wenn auch nur auf Kassette - immerhin.

Habe die Mechanik von Staub und Schmutz befreit und Tonköpfe, Kapstan und Andruckrolle gereinigt.

Was es aber vermutlich ausgemacht hat, waren ein paar Sprühstösse Kontaktspary in den vielpoligen Aufnahme-/Wiedergabeumschalter und etwas hin und herschieben des selben. Anschliessend noch mit Waschspray ausgewaschen. Das gleiche habe ich mit dem Stecker für den Interfaceanschluss gemacht. Danach gings. Die Riemen sehen für das Alter eigentlich noch okay aus.

Das mit dem Doppelfloppy wird was Gröberes.

Vielen Dank für den Hinweis, jetzt sehe ich es auch.

Das würde aber bedeuten, dass wenn man den IO-Bereich nach $88xx verlegt, man zumindest bei der 32KB Maschine das gleiche Problem eben nur auf den RAM statt ROM bezogen hat.

Das war damals, als Speicher knapp und teuer war, sicher eine schwere Entscheidung ob man den IO-Breich vom RAM oder ROM abknappst. Der Mitbewerb (8080, Z80) hatte den Vorteil, dass der IO-Bereich völlig vom Speicheradressbereich ferngehalten werden konnte.

Ja sorry ist mir auch gerade aufgefallen, kaum das ich es geschrieben hatte.