Ich habe mir eine kleine C2N-Lib für den Arduino Uno am Tape-Port geschrieben, die ich eigentlich für die CBMs verwenden wollte, aber nur mit dem C64 (restliche Homecomputer ungetestet) funktioniert. Ein Oszi ist leider nicht vorhanden: mein altes Voltcraft Schätzeisen aus den 80iger ist defekt, die Picoscope-Software läuft plötzlich nicht mehr auf Linux und es ist bestenfalls ein DSO150 Khz-Döschen da. Ich kann allerdings ein Analyzer-Capture mit einem Salae-Adapter aufzeichnen.

Eingestellt wurde es letztlich mit der alten Justage-Software für den C64.

Und das klappt dann auch wunderbar. An den CBMs 2001N zieht das leider ohne Reaktion vorüber oder bei Mehrfachstart hängt der sich auf. Danach hatte ich dann mit einer alten C2N den Test gemacht: ein kleines Testprogramm mit dem C64 gespeichert "10 Print "test" " und der CBM lädt es sofort. Andersherum kam es zum gleichen Ergebnis. Laut Capture sind die Signale von der Datasette und dem Arduino augenscheinlich zu 99% identisch.

Zuletzt hatte ich noch diese Kleinigkeit zusätzlich eingebaut, die bei der C2N anders war:

Da war noch eine etwas gezogenes Signal nach der Header, also dem Motor-Stop Gap vor dem Laden (ca. 400ms). Wird sicher durch das Stoppen des Motors verursacht und der letzte Signalwechsel zieht sich dann etwas. Und ich habe auch bei der Synchronisation die wirklichen 80 anstatt der oft dokumentierten 60 Signalwechsel verwendet. In der Lib verwende ich "delayMicroseconds" mit unsigned int. Das ist immer mit etwas Anpassung verbunden, da alles Zyklen verbraucht. Der ideale shortpulse liegt im Moment z.B. bei 163µS, wobei der Mittelwert des PAL-C64 bei ca. 190µS liegt. Mir graut es davor, mit der Arduino-IDE etwas direkt mit dem Timer zu machen.

Hier kann man verschiedene Werte (am Ende der Seite) für die verschiedenen Tape-Ports nachlesen: https://www.ktverkko.fi/~msmak…2n232/firmware/c2n232.txt . Und das C2N232 funktionierte mit allen C= Tapeports, ist allerdings in Assembler geschrieben.

Der C64 ist scheinbar sehr tolerant was die Signalqualität angeht.

Wie muss ich es für die CBMs anpassen ? - Brauche ich eine Punktlandung im µS-Bereich, damit der überhaupt reagiert ? - Ich hätte bei meinen zahlreichen Versuchen zumindest mal eine verstümmelte Found-Meldung erwartet.

Am Arduino hängt im Moment ein 7414 Schmitt-Trigger und dahinter ein N-FET mit Pullup.

Edit: Habe testweise den PRGuino am CBM eingesteckt, der schafft es auch nicht bis zur Found-Meldung.

Quote from Ruudi

Ich würde mal vermuten, das es weniger mit der Codierung zu tun hat, als denn mit analogen Dingen wie Pegeln, Flankensteilheit (auch zu viel davon kann negative Effekte haben!), d.h. schau Dir doch die Schaltpläne des Kassettenports DEINER C64-Version vergleichend mit dem zu deinem PET passenden an.

Eventuell liefert das ja bereits Hinweise darauf, warum es nicht funktioniert...

Auch an die unterschiedlichen INTERNEN Eingangsschaltungen von PIA, VIA und CIA denken und mit einbeziehen in diese Betrachtung!

125k-Sample "Oszi" würde übrigens für Datasette locker reichen

Ich habe zwei Board-Revisionen damit getestet, da funktionierte es gleich gut. Im Prinzip habe ich auch die zwei möglichen Ausgänge der Datasette/C2N nachgebildet. Einmal nur mit Schmitt-Trigger und zusätzlich noch mit N-FET+Pullup. Das ist eigentlich keine Raketentechnik mit den langsamen kHz-Signalen. Den flankengetriggerten Eingang des PIA hatte ich auch schon in Verdacht. Entweder zieht es dort unbemerkt vorbei oder es wird nach IRQ+Timer verworfen, weil es unpassend ist.

Dieses Mini-kHz Oszi funktioniert ganz gut, solange es keine schnellen Pegelwechsel gibt. Dann hat man das Gefühl, dass es den Signalen hinterher läuft. Aber was will man für kleines Geld erwarten ?

Quote from 1570

Ansonsten mal mit einem Emulator schauen, was die CBMs da genau wollen/produzieren, das lässt sich spätestens mit einem kleinen Patch für den Emulator-Code sicher schnell herausfinden.

Was die eigene Hardware angeht, würde ich für timingkritisches Zeugs den RP2040 empfehlen. Kost' nix, ist hinreichend schnell und erlaubt dank seiner PIOs nanosekundengenaues Timing ohne hässliches und ungenaues Delay-Gefrickel.

Dazu sollte so ein AVR eigentlich reichen. Habe auch noch einen flotten ARM da, finde es dafür aber etwas übertrieben. Um da etwas mit den Tape-Routinen zu machen, müsste ich erst mal das komplette ROM-Listing dokumentieren, um im Detail auch zu verstehen, wie das ablaufen muss. Ein Programm zum Lauschen an CA1 des PIA wäre ideal, das die Zeit zwischen den Pegel misst.

Quote from mantillo

Evtl. hilft Dir die Dokumentation und der Source Code von CBM Tape Pi weiter:

Beschreibung zum Commodore - Datassetten-Format.

Source Code der Emulation des Sendens an den Commodore im "normalen" Modus.

Danke, Tape Pi kannte ich noch nicht. Der Raspberry Pi hat ganz andere Torzeiten als ein Arduino. Ist schon eine gewaltige Rechenleistung um eine langsame Datasette zu emulieren.

Die Beschreibung des Format findet man auch hier: http://tech.guitarsite.de/datassette_enc.html und im C64-Wiki als deutsche Version.

Immer noch kein FOUND ... aber vielleicht komme ich noch drauf.

Quote from Ruudi

Das kann man ja wohl mit dem Oszi oder Logicanalyzer unterscheiden, d.h. mal an den IRQ hängen und auf ner 2. Leitung sich den Pegel am Eingang ansehen und eventuell sogar als Trigger für ne gewisse Nachlaufzeit verwenden. kommen da regelmäßig kurz drauf (mittlere Durchlaufzeit PIA) IRQs an, dann passt es in der HW, aber irgendwas am Protokoll ist anders, als von Empfängerseite-SW erwartet, wenn da kein Zusammenhang erkennbar ist, dann liegt es an der HW...

Ich werde es wohl zuerst mit einem Software-Patch versuchen. Sowohl Hardware als auch Protokoll sollten passend sein. Im ROM des CBM konnte ich nichts finden und der lädt auch problemlos eine Aufzeichnung vom C64.

Dieses "delayMicroseconds" der Arduino-IDE ist auch etwas wackelig, das schwankt sporadisch um 4µS. Da wäre es vielleicht auch angebracht, den Komfort der Arduino-IDE zu vergessen und alles direkt mit AVR-GCC umzusetzen.

Gestern hatte ich noch ein LCD-Display an den Arduino gehängt und die Laderoutine mit auf- und absteigenden Pegeln laufen lassen. Nichts, es rührt sich nichts beim CBM.

Quote from mantillo

BM Tape Pi simuliert ja nicht nur die Datassette. Das braucht man da nur, um den "Fastloader" ohne fremde Hilfe zu laden.

Braucht man das wirklich ? - Wenn man mit dem Standard-Load die Header und einen 192-Block lädt, kann man 191-361 Bytes für eigenes Programm belegen. Beim CBM hat man zusätzlich die komfortable Möglichkeit der internen 4kByte-ROMs. Da hat man gute Voraussetzungen für ein eigenes TWI, da die Daten vom µC sowieso in digitaler Form kommen und ein Fastloader im eigentlichen Sinne gar nicht mehr notwendig ist. Mir würde es gut gefallen, wenn es ohne ROM und nur mit LOAD klappen würde. Und vielleicht noch RUN hinterher, wenn die Vektoren das nicht anders hergeben.

Quote from mantillo

Kann sein, dass wir da aneinander vorbei reden. Mit "Fastloader" meinte ich (auf CBM Tape Pi bezogen) die Wedge, die per LOAD (so, wie Du meinst?) initial geladen wird. Danach kann man dann vom Pi (eben per Wedge) schnell(-er) Daten laden und auch darauf speichern.

Ja, so, ein eigenes Protokoll etablieren und dann flotter die Bytes pollen.

Ich habe nun alles nochmals neu direkt in AVR-GCC geschrieben und es scheint fast zu klappen. Der Anschluss ist nun direkt mit Pullup wie beim C2N232 und die Software invertiert. Es ist fast zum Lachen, der C64 hat es sofort geladen. Beim CBM kommt es passend im Puffer an, auch zweimal und da fehlt wohl nur noch eine Kleinigkeit, die FOUND-Meldung blieb noch aus. Habe die Pulswerte nun per Timer0 umgesetzt und die sind wohl passend. Wurde so auch beim Tape Pi und TAP-Format verwendet. Kann man sich auch leicht ausrechnen.

Fehlt nur noch ein FOUND.

Problem gelöst. Wenn in der Header an erster Stelle #$01 steht, dann lädt der CBM, mit #$03 konnte der nichts anfangen.

Ja, das funktioniert jetzt auch mit CBM Basic 1,2 und 4. Und der C64 inhaliert sowieso fast alles. Ich werde jetzt die Arduino-IDE wohl weiter verwenden: bequemer und leichter nachbaubar. Am Ende hätte ich gern einen Cardreader, Display und zwei Buttons. Also das Directory der SD-Card durchs LCD-Display scrollen und das angezeigte PRG kann dann per LOAD geladen werden.