Beiträge von edrive

Sorry, ich hatte bereits bei dem Ungarn bestellt (ohne bis jetzt eine Rückmeldung zu erhalten).

Auf der Seite von dem Shop steht, dass noch 4 verfügbar seien und es läuft ein Timer in ca. 10h ab (wozu auch immer der gut sein soll).

Bei "Zimmers" findest du allerlei Infos rund um den PET (neben anderen CBM Rechnern).

Die Handbücher sind hier:

http://www.zimmers.net/anonftp…bm/manuals/pet/index.html

Oder ab hier einfach mal durchklicken:

http://www.zimmers.net/anonftp/pub/cbm/

Nach dem Load-Befehl und der darauf folgenden Aufforderung den Play-Button zu drücken, kommt dann wenigstens die "SEARCHING" Meldung?

Hm lt. Anleitung hat das eingebaute Kassttenlaufwerk die Devicenr. 1 und das externe die 2.

Allerdings habe ich das aus einer Anleitung für die PETs 2001-16 und aufwärts, eventuell war das bei deinem anders.

Probiere mal LOAD"*" (ohne Deviceangabe) auch am hinteren Anschluss und schaue ober er die "Press Play in Tape" Anweisung auch so akzeptiert.

Dann fällt mir noch etwas ein:

Bei meiner (externen aber sonst praktisch baugleichen) Datasette musste ich den Aufnahme-/Wiedergabeumschalter mit Kontaktspray behandeln, damit die wieder nach langer Lagerzeit ging. In der Datasette befindet sich ein mehrpoliger Schiebeschalter, der zwischen Aufnahme u. Wiedergabe umschaltet. Dieser kann nach langer Zeit des Nichtbenutzens Kontaktschwächen aufweisen. Hier ein paar Sprühstösse Elektronik-Kontaktspray hineingeben. Mit einem Aufgesetztem Sprühröhrchen trifft man besser in den Schalter rein. Dann den Schiebeschalter einige Male hin und her bewegen.

Willkommen hier Alex. Sieht ja noch richtig gut aus der PET.

Theoretisch gibt es mehrere Möglichkeiten.

Da du den Riemen gewechselt hast, könnte es sein, dass die Datasette u.U. zu schnell oder zu langsam läuft.

Kapstan, Andruckrolle und die Scheiben über die die Riemen laufen, sind auch sauber, nicht dass dort Gummireste anhaften, was zu Gleichlaufschwankungen führen könnte.

Es könnte auch sein dass der Tonkopf verstellt ist, was ich aber eher für unwahrscheinlich halte -sofern da nicht dran rumgeschraubt wurde.

Der Stecker von der Datasette zum Mainboard könnte Kontaktschwächen haben, ggf. Stecker abziehen und die Kontaktflächen reinigen (sind beidseits).

Der PET hat i.d.R. 2 Kassettenanschlüsse, der andere sollte sich an der Rückseite rechts links befinden.

Die Datasette testweise dort anschliessen, dann hast du auch gleich die Eingangselektronik quergetestet.

Ich bin mir dabei aber nicht ganz sicher ob man dann beim LOAD-Befehl einen Parameter z.B. LOAD"mein Programm",1 angeben muss um den PET zu sagen, dass er den anderen Kassettenanschluss nehmen soll. Könnte auch sein, dass dies selbstständig erkannt wird, wenn man Play drückt.

Hast du mal versucht auf eine Leerkassette etwas zu schreiben (etwa einen 3-Zeiler) und das zurück zu lesen - nicht dass es doch an den 40 Jahre alten Kassetten liegt?

Alternatve Methoden:

Funktionierendes Diskettenlaufwerk organisieren.

Oder einen SD-Kartenleser wie z.B. diesen "sd2pet" hier:

https://www.thefuturewas8bit.com/sd2pet-future.html

Eine etwas luxuriösere Variante petSD+ wird leider nicht mehr hergestellt:

https://petsd.net/index.php?lang=de

Man kann das zur Not aber selber bauen oder versuchen das hier aus Ungarn zu bestellen:

https://www.sellmyretro.com/of…488-floppy-emulator-37156

Dann gibt es noch Programme wie tap2wav mit denen man aufgenommene Kassetten am Computer ins WAV-Format konvertieren kann um sie dann als "*TAP"-Files zu haben.

Siehe z.B. hier:

https://sourceforge.net/projec…ape%20tools/WAV%20format/

Die TAP-Files kann man dann mittels Tapedeck wieder auf Kassette bringen.

Oder versuchen mit einem anderen (gewöhnlichen) Kassettenrekorder in den PET einzuspielen.

Für letzteres braucht man aber eine Adapterelektronik.

Es gab auch mal eine App für Android "tapdancer":

https://paleotronic.com/software/tapdancer/

"Gab", weil sie aus dem Playstore verschwunden ist, deswegen hier als apk:

https://apkpure.com/tapdancer-…tasette/co.kica.tapdancer

Und last but not least, kann man sich eine gut erhaltene Datasette für nicht all zu viel Geld in der Bucht organisieren.

Es funktioniert die Datasette vom C64 genauso gut (die ist im Prinzip baugleich, nur äusserlich etwas rundlicher).

Lass die Drähte erstmal - er ging ja auch noch am Schluss damit.

Möglicherweise ist das auch schon ab Werk so gewesen, weil Commodore die Platine nicht besser hinbekommen hat oder in der Fertigung etwas vergessen wurde. Sieht auch sauber gelötet aus.

Ob das original so gehört kann ich leider nicht sagen (meiner ist schon mit der grossen Tastatur u. anderen Board), aber sicherlich gibt es Kenner, der älteren PETs, welche das beantworten können.

Schön zu hören, dass er einst eine "richtige" Daseinsberechtigung hatte.

Wenn er 2005 noch funktioniert hat - also mind. >25 Jahre - ist das schonmal nicht schlecht.

Weisst du warum er nicht mehr benutzt wurde? Sprich wurde er aussortiert, weil es nicht mehr in die Zeit gepasst hat und das Laden des Programms (per Kassette) zu lange gedauert hat oder weil er damals schon einen Defekt bekommen hatte?

Ergänzend zum Post von WJakobus:

Sieht echt mit genommen aus, kriegt man aber hin - mit Geduld, Erfahrung und Zeit.

Als erstes würde ich das Board ausbauen und einer Grundreinigung unterziehen.

Also im Waschbecken gründlich (nass) spülen, dabei u.U. einen chemischen Reiniger verwenden.

Hier im Nachbarthread wurde ein Reiniger empfohlen.

RE: CBM 3032 kein Basic, nur Maschinensprache-Monitor

Anschliessend würde ich mit Isopropanol oder ähnlichem das Wasser wegspülen (damit es in der Folge nicht rostet).

Danach versuchen die ICs in die Sockel zu drücken, wobei es hier wahrscheinlich besser wäre die Sockel durch neue und bessere zu ersetzen.

Weiterhin würde ich nicht ausschliessen, dass es mehrere Fehler/Defekte gibt.

Nach der Reinigung würde ich die Platine mit einer starken Lupe auf schlechte Lötstellen untersuchen.

Das Fehlerbild mit dem horizontalen Strich auf dem Bildschirm, lässt auf eine defekte Vertikalablenkung (oft sind es hier defekte Kondensatoren) und/oder Bildansteuerung schliessen.

Vorallem sollte aber, wie von WJakobus erwähnt, die Spannungsversorgung funktionieren, sonst geht gar nix.

Kennst du etwas zur Vorgeschichte?

Merci für den Hinweis auf die alternative Quelle und den extra Hinweis, dass es eine andere Buchse hat.

Ich bin geneigt dennoch eins zu bestellen.

Falls es Sinn macht und Interesse besteht, würde ich für Mitforenten ggf. mitbestellen.

zitruskeks:

Den Elko habe ich mehrfach mit dem Mutlitmeter im Ohmbereich gemessen und Kurzschluss erkannt.

Es stieg auch nicht der Widerstand während des "Aufladens" an, sondern bliebt bei 0 Ohm. Während der noch funktionierende bzw. andere Elko gleicher Kapazität bei einer Widerstandsmessung relativ bald in den Kiloohmbereich ansteigt, um dann langsam bis zum Messbereichsende "OL" anzusteigen. Habe das mehrfach im ausgebauten Zustand überprüft.

Allerdings, ein paar Tage später nochmals gemessen und er schien wieder okay.

Wer misst misst Mist... habe jetzt aber Bedenken den wieder einzubauen. Äusserliche Schäden sind keine zu erkennen.

detlef:

Merci für den Hinweis.

Nur wäre das für mich erheblich umständlicher.

Müsste erstmal ein Platinen-Layoutprogramm installieren, um die Platinen zu sichten und/oder einen Platinenhersteller ausfindig zu machen. Dann sind 2 programmierte Bausteine auf dem Board, auch da müsste ich mich erstmal damit beschäftigen, wie man die programmiert. Da wäre es mir schon lieber alles bereits zusammen gestellt aus einer Hand zu bekommen.

Tuts der hier?:

DIL_Sockel40.jpg

DIL_Sockel40unten.jpg

Der war wohl nie eingelötet. Das was man an den Pins sieht sind Reste vom (verhärteten) MOS-Schaum in denen der aufbehart wurde - sollte man relativ einfach runterputzen können.

Auf den Bilder sieht es etwas leicht bräunlich aus. In Wirklichkeit ist er weiß-besch aber eben nicht wirklich weiß.

Einer der beiden Becherelkos, die am Gehäuse mit Kabelbinder festgemacht sind, war auch noch eindeutig defekt.

Eine einzige 1N5407 als Ersatz für die defekte 1N5402 hatte ich noch im Bauteilelager gefunden.

Den Elko habe ich vorübergehend durch ein Provisorium ersetzt (10mF+3,3mF parallel, um auf die originalen 13mF zu kommen).

Da ich wg. der Diode das grosse Digitalboard ausbauen musste, habe ich bei der Gelegenheit die Unterseite reinigen können und auf Macken untersucht, war aber soweit optisch alles okay.

Bevor ich da wieder Saft drauf geben wollte, habe ich alle Verbindungen gründlich durchgetestet.

Nicht dass einer der Stecker etwas abgekriegt hat und überhaupt man weiss ja nie.

Allerdings stimmte etwas nicht.

Der Plusanschluss vom Ersatz-Elko muss ja mit den beiden Kathoden der Dioden CR5 u. CR6 verbunden sein, war es aber nicht.

Alles x-mal durchgemessen. Schaltplan gecheckt, Steckerpins, Nummerierung der Steckerpins, Leiterbahnen verfolgt etc..

Zuerst habe ich es nicht geglaubt, aber dann war es doch eindeutig:

Es ist eine Diode der 5V Versorgung kaputt gegangen und ein Elko aus der 12V Versorgung.

Während quasi umgedreht die Dioden der 12V Versorgung und der Elko der 5V Versorgung okay waren.

Wie das (zeitlich) zusammen passt ist mir ein Rätsel.

Egal, Hauptsache es geht wieder.

Kann wieder die Disketten drehen lassen.

Passende E-Teile habe ich mir schon bestellt, von den Elkos gleich 3 Stück, damit ich den im CBM3032 auch gleich prophylaktisch wechseln kann. Ich denke die TO-3 Spannungsregler werde ich auch mal wenigstens mit neuer Wärmeleitpaste versorgen und/oder ersetzen.

gpospi:

Ja du hast natürlich Recht, die CBM Portbausteine sind nicht gerade die robustesten.

Aber wenn man alles Externe spannungsfrei macht und die Stecker ohne zu verkanten steckt, sollte es gehen.

Das erinnert mich an meine kurze und relativ späte C64-Zeit um 1989/90.

Damals hatte ich mir einen C64 besorgt mit dem einzigen Zweck damit Packet-Radio im 2m Band zu machen.

Weil das Geld als Studi nicht noch für ein Disketten-LW gereicht hat, hatte ich nur eine Datasette.

Dumm war nur, dass die Software (Digicom 2.0) zwingend ein Disk-LW gebraucht hat, weil man sein Rufzeichen auf selbiger speichern musste. Ausserdem wurde der Kassettenport vom Modem (Eigenbau mit AMD 7911 Chip) belegt.

Weil ich einen der Entwickler von Digicom persönlich kannte, hat er mir eine Sonderversion vom Programm gemacht, bei dem mein Rufzeichen fest eincodiert war. Das konnte ich dann von Kassette laden. Allerdings musste ich nach dem Laden immer das Kassetten-LW ab- und das Modem anstecken. In 3 von 10 Fällen hat das zum Absturz geführt, wobei die vorige Ladezeit gefühlt ewig war und man wieder von vorne anfangen durfte...

Die PETSD werden übrigens nicht mehr verkauft/gebaut.

Seit 1.2.2021...

Habe den Hersteller angeschrieben, er hat prompt geantwortet und will sehen ob er noch Teile findet.

zitruskeks

Okay merci, das wusste ich nicht, dass mein 3040 LW keine C64-Disketten lesen kann, war nur verwundert, weil eben bei den meisten immerhin das Directory angezeigt wird.

Habe z.Zt. für ein DOS Upgrade keine Eproms mehr übrig.

Wobei ich mir schon überlegt habe den 3032 auf Basic4 und die 3040 auf DOS2 zu upgraden.

Anderseits habe ich im 3032 inzwischen 2 Erweiterungs-ROMs (eine Basic-Extension und einen NewTIM), das macht schon vieles von Basic2 wett und für die Disk kann ich ja die Wedge laden...

Das Doppelfloppy macht im Moment erstmal gar nix mehr, es fliegt die Sicherung!

Hatte alles Testweise so wie es war wieder zusammen gebaut.

Mit dem Effekt, dass ich auf dem linken LW lesen und schreiben konnte.

Auf dem rechten LW konnte ich nicht wirklich schreiben, auch Formatierungsversuche schlugen fehl.

Das was ich links geschrieben habe, konnte ich rechts aber zumindest wieder einlesen.

Von den C64-Disketten konnte ich allenfalls das Directory lesen, aber keine Programme laden - auch keine die nach einfachen Basic aussehen.

Soweit so gut.

Dann hat heute der Postbote geklingelt.

Er brachte ein SD2PET, sodass ich endlich Programme von "aussen" via SD-Karte auf den Rechner bekommen konnte.

Und habe natürlich Programme ausprobiert.

Habe mich darüber gefreut wie ein Schneekönig.

Dann wollte ich Programme auf die Diskette übertragen.

Was ja eigentlich nicht geht, weil der IEEE Anschluss ja durch den SD2PET belegt ist.

Die Vorgehensweise war dann:

Programm laden und während der CBM noch läuft:

SD2PET Stromversorgung vom Kassettenport abziehen, dann den SD2PET abziehen.

Diskettenlaufwerk im ausgeschalteten Zustand an den IEEE-Port anschliessen, LW einschalten.

Und Programm übertragen.

Das hat auch einwandfrei geklappt, konnte so ein paar Programme auf Diskette übertragen.

Beides der CBM und das Diskettenlaufwerk liefen fast den ganzen Tag und waren beide gut warm gelaufen.

Vorhin wollte ich dann mit der Methode ein weiteres Programm übertragen.

Beim Einschalten des Diskettenlaufwerks, kam nur kurz ein deutliches Trafobrummen, was sich ziemlich eindeutig nach Kurzen angehört hat. Die Sicherung war auch gleich geflogen.

In meinen E-Teilen habe ich ein Sortiment von US-Sicherungen und kann auf mehrere sogar völlig identische zurückgreifen.

Gleich mal ein bisschen Fehlersuche:

Lässt man den Stecker, der vom Trafo kommt, abgesteckt, fliegt die Sicherung nicht, d.h. der Trafo scheints nicht zu sein.

Laufwerke abgesteckt und den Stromstecker wieder auf die Hauptplatine und ganz kurz eingeschaltet der Trafobrumm war wieder da, d.h. an den Laufwerken kann es auch nicht liegen. Auf die schnelle noch ein bisschen Fehlersuche betrieben:

Die Diode CR6 (Halbwellengleichrichter der 5V Versorgung) hat einen satten Kurzschluss.

Ob es den LM323 oder den einen grossen Elko in Mitleidenschaft gezogen hat, kann ich noch nicht sagen.

Hoffentlich hat es keine Chips gegrillt - drückt mir die Daumen. Zumindest zeigt die 5V-Rail keinen Kurzen.

Vielen Dank.

Das Programm läuft jetzt.

Um die Drehzahl, einzustellen habe ich mir eine kleine LED-Schaltung gebaut:

Rote LED direkt hinter einen 4-Weg-Ggleichrichter, davor einen Widerstand und das ganze an einen AC-Trafo. Die beiden Halbwellen lassen dann die LED mit 100Hz leuchten.

Bei beiden Laufwerken drehte sich die Stroboskopscheibe, bzw. dessen Strobo-Effektbild, deutlich nach links, was sich aber problemlos mit dem 10-Gang-Trimmer auf Stillstand einstellen lies.

Weniger Glück hatte ich mit der Einstellung der Steppermotoren.

Grundsätzlich sieht die Ausgabe vom Programm aus, wie in deinem letzten Screenshot.

Nur, dass bei wirklich jeder Zeile der Kopf auf die äusserste Spur auf Anschlag fährt.

Einen Punkt, bei dem der Kopf nicht ständig auf den Anschlag läuft habe ich bei keinen der Laufwerke gefunden.

Nachdem die FOR NEXT Schleife durchlaufen ist erfolgt i.d.R. die Ausgabe:

71 DIR ERROR 1 0

Und dann geht das ganze von vorne los, was bei beiden Laufwerken das gleiche ist.

Ich habe auch verschiedene Disketten probiert.

In einem ungesichteten Disk-Konvolut, welches nicht von mir stammt, waren ein paar Kaufdisketten darunter, u.a. zwei völlig ohne Schreibschutzkerbe. Eine Commodore C64 Demodiskette und ein Ausgabe der "Input" 1/88.

Bei denen kommt aber nach durchlaufen der Schleife ein "write protection error".

Bein manchen Disketten kommt "29 disk id mismatch 18".

Mit dem Scope habe ich versucht auf auf Maximum abzugleichen, wobei ich da kaum Änderungen bemerken kann, allenfalls wenn man den Stepper auf einen der Endanschläge dreht sackt es etwas ab.

Auch den Trick, den Kopf um eine Rille zu verschieben habe ich versucht.

Stehe jetzt ein bisschen auf dem Schlauch.

Wie empfindlich ist es denn den den Sweetspot einzustellen?

Reicht es schon wenn man an den Stepperschrauben "gemessen" um einen 1/4mm verdreht und es geht gar nichts mehr oder braucht man dazu schon 1mm oder mehr?

Weiterer kleiner Teilerfolg:

Das linke LW habe ich inzwischen genauso zerlegt wie das rechte (s. ein paar Postings weiter oben).

Dabei ist mir aufgefallen, dass schon mal jemand daran rumgeschraubt haben muss.

Dort wo am rechten LW überall die Schrauben mit rotem Lack gesichert waren, hat er im linken gefehlt, bzw. war abgeplatzt. Und an den Schrauben für den Motor vom Exenterantrieb wurde definitiv geschraubt - man sieht man Spuren und anders als beim anderen LW war fehjlte dort der rote Lack. Habe die Schrauben aber so gelassen (kalibrieren kann ich es eh nicht).

Dann alles gründlich geputzt, kaum zu glauben wie dreckig das alles war, Köpfe mit Alkohol gereinigt, die Frontblende im Spülbecken geputzt und alles wieder zusammen gebaut.

Nun bekomme ich etwas auf das linke LW geschrieben und auch wieder eingelesen.

Habe erfolgreich ein paar 3-Zeiler Programme schreiben und rücklesen können.

Ob es auch über den ganzen Bereich der Diskette klappt muss sich noch rausstellen.

Also irgendwie komme ich mit dem Testprogramm nicht weiter.

Es bricht immer in Zeile 160 mit "File not open" ab.

Tippf hler sind zwar das naheliegendste. Nur finde ich keine, möglichweise habe ich den Tomaten auf den Augen Effekt.

Zur Ansicht ein Bild wie das bei mir aussieht.

Die originale Zeile 260 habe ich duch den "Ersatzcode" in den Zeilen 260ff für Basic 2 ergänzt, aber soweit kommt das Programm ja gar nicht.

Dass man als Drive 0 o. 1 eingeben muss und nicht etwa die Devicenr. (sic) war mir von Anfang an klar.

Testweise habe ich bei dem PRINT#...-Befehl in Zeile 160 nach dem "U1:" die Kommas durch Strichpunkte ersetzt oder ein Strichpunkt ans Ende angefügt - ohne Änderung im Ergebnis.

Anbei noch die Ausgabe:

Testweise habe ich noch der Eröffnung der FOR TO -Schleife und vor dem PRINT#... eine neue Zeile 155 eingefügt, die nur das N ausgibt, um zu sehen ob die Schleife hochzählt.

Also

155 PRINT N

Interessanter weise wird anscheinend die Zeile 160 mit dem PRINT#... wenigstens einmal erfolgreich durchlaufen, und das NEXT einmal erreicht, sonst würde es ja nicht bis 2 hoch zählen.

Möglicherweise ist das aber alles normal oder eine Inkompatibilität mit Basic 2.

Egal ob Drive 0 o. 1, es fährt immer zuerst der Kopf auf die äusserste Spur um von dort aus auf die "Zielspur" zu fahren, wo sich das LW noch kurz dreht und dann bricht es mit dem Fehler ab.

Hm, es dreht sich kurz, dann kommt

File not open error in 160

Zitat von zitruskeks

Ich tipper das Programm mal ein. Nur vorher: Ich denke du hast Glück, bei allen meinen Drives (2 Shugart, 2 Alps) ist das keine eingestanzte Halbkugel, sondern in den Metallbügel ist ein Loch gestanzt, zwischen dem und dem Plasteteller eine Kugel geführt wird. Oft "kleben" die etwas an dem Metallbügel, können aber abfallen.

Weiss gar nicht wie ich für die Mühe danken soll.

Nach gpspis Hinweis habe das das linke LW, so wie es war (dreckig), wieder eingebaut um zu testen.

Zunächst einmal macht es Geräusche, die sich nicht so schön anhören. Möglicherweise springt die Kopfführung aus der Rille.

Leider konnte ich nicht zusehen, weil das Analogboard drüber ist.

Im ersten Anlauf bekam ich Fehler 22 (nicht formatierter Block).

Im zweiten hat es dann mit dem linken LW geklappt und ich konnte etwas drauf schreiben und auch wieder einlesen - sogar das Directory.

So langsam mache ich mir Hoffnung.

Mache mich jetzt dran den Code ein zu tippen.

Zitat von gpospi

Wieso Device-Nummer des linken LW? Die IEEE Adresse ist bei einem Doppellaufwerk für beide gleich, standardmäßig wird hier 8 verwendet (so auch bei Dir). Das rechte Laufwerk hat die ID0, das linke hat die ID1. Also z.B. beim Formatieren einfach "N1" statt "N0" als Geräte-Kommando verwenden.

Wow, danke für diesen Hinweis.

Ohh mann. Nie im Leben wäre ich darauf gekommen - never ever.

Für mich war immer klar dass dies 2 unterschiedliche Devices sind und ich habe mich schon gewundert, wieso man diese Initialisierungen bzw. die Angabe ob Drive 0 oder 1 machen muss. Dachte mir eben dass sind dann eben ein bisschen mehr lowlevel Funktionen.

Kein Wunder, dass sich das linke LW so nicht ansprechen lies - habe zuvor alle möglichen Divecenrn. durchprobiert (bloss nicht die 8)...

Jetzt wird mir einiges klarer.

Vielen Dank für die Hinweise.

Habe jetzt erstmal das LW wieder zusammen gebaut (ohne etwas zu ölen), nachdem ich alles gereinigt hatte.

Unter der Exenterscheibe bin ich mit einem leicht feuchten Pappstreifen ein paar mal durchgegangen.

Der Kopfschlitten lässt sich einigermassen leicht bewegen und fährt auch sauber mit der Exenterscheibe vor und zurück.

Wobei Kugeln sind da nirgends zu sehen auch nicht am anderen LW. Am Kopfträger ist ein kleiner Metallstreifen/feder, der am Ende eine eingestanzte Halbkugel hat - ähnlich wie beim Plattenspieler-Tonabnehmer (nur dass es dort eine Nadel ist).

Der Effekt ist jetzt folgender:

Grundsätzlich fährt der Kopf hin und her, Geräuschentwicklung würde ich als normal bezeichnen.

Versucht man eine Diskette zu formatieren sieht auch erstmal alles optisch gut aus.

Zum formatieren habe ich

OPEN15,8,15

PRINT#15,"N0:TESTDISK,88"

verwendet.

Beim formatieren fährt der Kopf ganz nach hinten bzw. auf die äusserste Spur bis es kurz rattert.

Dann fährt er langsam mit kleinen Ruckern nach vorne bzw. zur inneren Spur.

Man kann dabei schön zuschauen. Die Rucker kann man auch gut mitzählen es sind 34, was zur Doku passt wo 35 Tracks angegeben sind (für die äusserste Spur braucht er ja noch nicht zu rucken).

Etwa ab der Mitte lässt er sich mit dem weiterruckeln etwas mehr Zeit bzw. braucht mehr Umdrehungen bis er weitermacht.

Leider funktioniert ein anschliessendes

LOAD"$",8

LIST

nicht. D.h. es sieht so aus als wolle er etwa in der Mitte (wo wohl das BAM liegen soll) etwas lesen.

Nur nachdem das LW wieder angehalten hat kommt der Prompt bzw. Cursor nicht zurück, man muss mit RUN/STOP abbrechen.

Im Servicemanual habe ich folgendes kleines Testprogrämmchen gefunden:

10 OPEN15,8,15

20 INPUT#15,ER,MSG$,DRV,SEC

30 PRINT ER","MSG$","DRV","SEC

(die für mich seltsam anmutende Hochkomma-Setzung steht so im Manual).

Das Programm spuckt folgendes aus:

21, READ ERROR, 18,1

Also ein Lesefehler auf Spur 18.

Aus der Doku:

21: READ ERROR (no sync character)

Er findet die Sync Markierung nicht, als Ursache wird u.a. ein Fehlabgleich vom Kopf angegeben.

Dennoch habe ich einen kleinen Teilerfolg:

Das obige 3Zeilen-Programm konnte ich mit

SAVE"TEST",8 erfolgreich auf die Diskette schreiben und auch wieder einlesen - auch nachdem man NEW eingegeben hat oder ein anderes Programm eingetippt hat. Nur das Directory liest er nicht und weitere Programm konnte ich auch nicht schreiben - zumindest nicht wieder einlesen. Witzigerweise klappt es aber mit dem einen keinen Programm. Schreibvorgänge laufen scheinbar immer unauffällig ab. Nach Leseversuchen kommt der Cursor nicht zurück (ausser bei dem einen Testprogramm).

Ich denke als nächstes werde ich versuchen die Geschwindigkeit einzustellen.

Ist dein Testprogramm kurz bzw. abtippbar? Dann könnte ich es damit versuchen.

Zur Not könnte ich noch auf Kassette speichern...

Eine Testdiskette habe ich leider nicht.

Ein 2-Kanal-Oszi hätte ich aber.

Dann noch eine Frage:

Das linke LW macht überhaupt nix - keinen Muckser.

Habe mich noch nicht allzuviel damit beschäftigt nur mal die Analogplatine optisch mit Lupe überprüft.

Es ist ähnlich dreckig, nicht ganz so schlimm, scheint so als hätte die Analogplatine, die darüber liegt etwas abgehalten.

Wie bekomme ich heraus welche Device-Nummer das linke LW hat?

Habe mir dazu einen Wolf abgesucht und nichts gefunden.

Nachdem der Commodore 3032 wieder geht, siehe Nachbar-Thread

CBM 3032 kein Basic, nur Maschinensprache-Monitor

ist nun das Doppelfloppy dran.

Es ist ein CBM 3040 mit Shugart SA-390 Laufwerken (mechanisch baugleich mit SA-400).

Das linke Laufwerk habe ich inzwischen ausgebaut und teilzerlegt.

Grösstes Problem scheint teils hartnäckiger Dreck zu sein.

Folgende Erkenntnisse habe ich bis jetzt:

- Der "Kopfschlitten" lässt sich nicht wirklich leicht bewegen zumindest nicht ganz leicht, andererseits klemmt er aber auch nicht.

- Der Kopf und das kleine Anpressfilz sehen okay aus.

- Der Riemen scheint dem Alter entsprechend noch okay zu sein.

- Bei abgenommenen Riemen lässt sich die "Schwungscheibe" (das Ding mit den Geschwindigkeitsmarkierungen) einigermassen leicht drehen. Dreht man es mit Schwung an, dreht es vielleicht noch eine Umdrehung nach.

In diesem Reparatur-Video mit einem ähnlichen Laufwerk sieht man wie die "Schwungscheibe" abgenommen wird bei ca. 4:05.

https://www.youtube.com/watch?v=q6uTAWpqaEY

Doof nur, dass bei mir da keine Schraube ist, sondern die Scheibe anscheinend aufgepresst ist.

- Die schwarze Kunststoffscheibe mit der exzentrischen Führung für den Kopfschlitten lässt sich sagen wir mal wie ein schwergängiges Poti drehen. Kann natürlich auch daran liegen, dass der Steppermotor noch dran ist und am kleinen Hebel, wenn man an der (dünnen) Achse anfässt. Im Service manual vom SA-400 nennt sich das Ding "Actuator cam".In diesem 16sec Clip sieht man wie jamand an der besagten Scheibe dreht:

https://www.youtube.com/watch?v=deyAssykd4A

Um unter den Scheiben zu reinigen, ggf. zu ölen (Silikonöl?) würde ich die Dinger gerne abnehmen,

deswegen folgende Fragen:

Wie bekomme ich die "Schwungscheibe" ab? Zur Not würde ich das aber erstmal so lassen.

Wie bekomme ich die schwarze Exenterscheibe runter ohne sie kaputt zu machen?

Anbei zwei Bilder

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

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.

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.

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.

Einen Youngtimer habe ich noch gefunden:

Sharp Zaurus SL5500G ein Linux PDA Anfang der 2000er.

Für seine Zeit ein richtig gut gemachtes Teil.

Er hatte Touchscreen (welches man besser mit dem Pen bediente), Speicherkartenslots für CF- und SD-Karten, eine Infrarotschnittstelle, einen abnehmbaren Klappdeckel, Klinkenbuchse für externes Audio und "richtige" Tastatur (es gab auch div. onscreen Keyboards).

Bluetooth gab es leider noch nicht, Wlan gab es als Einsteckkarte für den CF-Slot. Mit dabei war auch eine Ladeschale, die einen USB-Anschluss für Datentransfer hatte. Man konnte Videos abspielen und es gab Office Programme für XLS- und DOC-Dateien. Seinerzeit hatte er eine Fangemeinde, die auch gerne alternative Linux-Varianten geflasht haben.

HP50g

Sehr umfangreicher RPN-Rechner mit USB-Anschluss, SD-Kartenslot und IR-Schnittstelle. Er kommt mir wie ein letztes Aufbäumen der Dinosaurier vor. Gefällt mir trotzdem, er hat noch die klassische Programmierweise wie bei den HP48ern.

HP82240B Thermodrucker, batteriebetrieben.

Für die Hardcopy Fans unter den HP-Jüngern. Er läuft mit 4 AA-Zellen und wird per Infrarot angesteuert.

Sharp EL-W550XG und TI-30XIIS

Der Sharp hat ein ausgesprochen dunkles Display und undefinierte schwammige Tasten.

Casio FX-991DEX und FX-350MS

Der 991 ist z.Zt. bei Schülern richtig beliebt, imho zu Recht.

Er kann Ergebnisse als QR-Code darstellen lassen, mit denen man auf eine weiterführende Webseite von Casio kommt. Erwähnenswert finde ich noch die rudimentäre Tabellenkalkulation (wobei die Daten leider nach dem Ausschalten weg sind).

Nein, Spiele sind da nicht drin, aber wer Bruchrechnen kann, kann damit auch TicTacToe spielen.

Was mir an den derzeitigen Schulrechnern durch die Bank nicht gefällt sind die "Füsse". Die bestehen nur aus einem kleinen "Nuppsi", welches in das Spritzgussgehäuse mit eingeformt wurde. Die haben auf glatten Tischoberflächen so gut wie keine Reibung, einmal angeschoben flitzen die wie ein Geschoss. Bei Casio ist das besonders ausgeprägt.

HP35S

RPN, richtig knackige Tasten, programmierbar und rutschfeste Gummifüsse machen ihn zu einem meiner Favoriten unter den aktuellen nicht Grafikfähigen. Nett finde ich auch das (Kunst-)Lederartige Einsteck-Etui, das hat nicht diese Anmutung von hartem Schulalltag und wirkt edler.

...to be continued (einen hab ich noch)

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.

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?

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?

Links:

MBO LC920 in etwa Scheckkartenformat nur nicht so dünn, wie die eingangs gezeigten Canon aus der Card-Serie, dafür federleicht. Der hätte eigentlich oben bei dem anderen MBO dabei sein sollen, ist mir auf Grund seiner geringen Größe nur nicht untergekommen. Dass an allen gespart wurde sieht man daran, dass die Speicherabruftaste die selbe ist wie die Speicherlöschtaste.

Ca. Mitte der 80er.

Die anderen beiden sind aus der Kategorie Klon/Rebranding

Mitte:

Ein Scientific 08 - entspricht dem Casio FX82 Solar.

Ein neueres Modell von 2017

Rechts:

Ein Toppoint von 2009.

Er entspricht dem Olympia LCD-8110.

Er hat immerhin ein 2-Zeilen Display und 9 Speicher.

Casio FX-4500PA

Umfangreiche Funktionen und programmierbar.

Leider weiss ich nicht genau von wann der ist, obwohl nicht mehr ganz taufrisch bekommt man den u.U. noch neu.

HP48SX

1988

In meinen Augen der beste Rechner ever, zumindest was die Funktionen, Programmierbarkeit und Bedienbarkeit angeht.

Den linken hatte ich mir im Studium für ein Vermögen geleistet. Anfang der 90er ist es dann passiert:

Zu später Stunde ist mir ein volles Glas Rotwein umgekippt und direkt in den Rechner geflossen.

Sofort gründlich abgetrocknet und auf die Heizung zum Trocken. Es half nichts, nach 3 Wochen wollte der immer noch nicht funktionieren. In meiner Verzweiflung habe ich dann einen missglückten Öffnungsversuch gemacht - mehr als kaputt geht auch nicht. Da ich nirgends Schrauben oder ähnliches gefunden habe und auch Aufhebelversuche fehlgeschlagen sind, habe ich unter der Tastaturschablone eine Möglichkeit zum öffnen vermutet. Deswegen ist die so verbogen. Habe es dann aber aufgegeben.

Ein viertel Jahr später hat er dann wieder funktioniert, nur war er jetzt optisch verschandelt.

Kürzlich habe ich mir das rechte Exemplar mit Displayschaden auf ebay für wenig Geld "geschossen". In der Hoffnung, dass ich da die Tastaturschablone als E-Teil unbeschadet runterbekomme.

TI-68

1989. Den TI-68 hatte ich mir als Ersatz gekauft, nachdem der HP48 defekt war.

Ein richtig guter, leider etwas verkannter, Rechner mit wirklich tollem Funktionsumfang, gut durchdacht, man kann kann eine Reihe Formeln speichern. Allerdings ist er nicht programmierbar. Dafür kann er Nullstellen finden, nach der Simpsonregel integrieren, lineare Gleichungssysteme bis 5 Unbekannte lösen und vieles mehr. Über die Jahre hat in der unteren Hälfte vom Display etwas Vergilbung eingesetzt.

So langsam geht meine Sammlung dem Ende entgegen.

D.h. es kommen schon noch ein paar Interessante, die sind aber eher aus der "Neuzeit".

...to be continued

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.