CBM Tape Pi - Datasette mit Raspberry Pi emulieren

  • Um eigene Programme auf meine CBM-Computer zu bekommen (und natürlich hauptsächlich aus Spaß..),

    habe ich für den Raspberry Pi eine Software geschrieben, mit der man diesen als Datasetten-Emulator verwenden kann

    (weil der Raspi so gelangweilt herumlag und ich mal etwas hardware-nahes machen wollte..).


    Dafür muss man einen Sender (z.B. PC) per serieller Schnittstelle (z.B. USB-2-Serial - Adapter) an den GPIO Port des Raspi anschließen.

    Der Raspberry Pi wird dann mit dem Datasetten-Anschluß des Commodore verbunden (zwei Widerstände benötigt man,

    sonst nur Kabel und den Datasetten-Stecker).


    Zum Laden geht man wie folgt vor:


    - "LOAD" auf dem Commodore eingeben (kennt der eine oder andere evtl. schon..).


    - Eine PRG-Datei vom Sender, per serieller Verbindung und YMODEM-Protokoll, an den Raspi schicken.


    Danach wird die PRG-Datei auf dem Commodore-Computer geladen!


    Details zu dem Projekt und die Kernel-Dateien (für den Raspi - ist bare-metal, also ohne OS), sowie den Source Code findet Ihr unter:


    https://github.com/RhinoDevel/cbmtapepi


    Es ist natürlich noch keine vollständige Emulation, aber ein Anfang und schon ganz hilfreich (zumindest für mich..).

  • nett - ich nehme an, dass dabei der Weg das Ziel war::hacking::

    Ansonsten ist die Kombination Kassettenadapter+Smartphone ja immer noch die einfachste Lösung, indem man die prgs als mp3s abspielt:tüdeldü:

    Klar, der Weg war auf jeden Fall auch Teil des Ziels (gerade die Bare-Metal - Geschichte)!


    Aber, ich wollte auch eine Lösung mit möglichst wenig Hardware-Aufwand schaffen,

    um (z.B. selbst entwickelte) Programme auf CBMs/PETs zu bekommen (um nicht nur im Emulator zu testen, usw.).


    Wie wäre denn da der Workflow, wenn man das mit MP3s macht?


    1. PRG erstellen.

    2. PRG (evtl. erst in TAP und dann) in WAV, bzw. MP3 umwandeln.

    3. ???


    Wie bekomme ich denn nun das Audio-Signal in das digitale Signal für den Commodore umgewandelt?

    Muss ich da ein Datasettenlaufwerk manipulieren,

    oder geht das noch einfacher?


    Evtl. hast Du ja einen Link zu einem How-To, oder so!

  • Oder man nimmt einen Tapuino. ;)

    Klar, Tapuino und auch Tapecart sind tolle Projekte und haben natürlich viel mehr Features (Fast Loader, etc.).


    Aber, wie gesagt, mit viel mehr Hardware-Aufwand verbunden.

    Einen Raspi haben ja viele einfach so herumliegen, oder?


    Funktionieren die beiden Projekte eigentlich auch mit CBMs/PETs, oder nur mit dem C64?

  • nett - ich nehme an, dass dabei der Weg das Ziel war::hacking::

    Ansonsten ist die Kombination Kassettenadapter+Smartphone ja immer noch die einfachste Lösung, indem man die prgs als mp3s abspielt:tüdeldü:

    ...


    Evtl. hast Du ja einen Link zu einem How-To, oder so!

    Ich hatte in einem vorigen Post mal einen Link zu den progs und mp3s geschickt, die ich damals für meinen PET und 8032SK erstellt hatte. Den genauen Weg dorthin hab ich leider nicht dokumentiert. Ich kann dir nur noch ein paar Stichworte aus meiner (verblassenen) Erinnerung nennen:

    1. Programme für CBM findest du per Google zuhauf...
    2. wav-prg ist mir noch in Erinnerung, aber auch hier sollte Google weiterhelfen.
    3. Ich kann mich noch schwach entsinnen, dass man bei der Konvertierung beim Einstellen der Ladeadresse aufpassen musste, weil die z.B. beim C64 anders war wie bei älteren Generationen wie PET und 8032. Ob das bei dem oben genannten Tool war oder einem anderen, kann ich nicht mehr sagen.
    4. die WAVs können problemlos mit jedem Converter nach MP3 umgewandelt werden. Qualität spielt keine große Rolle (128Bit aufwärts sollten es aber schon sein).
    5. Beim Abspielen der MP3 vom Smartphone hab ich immer die größte Lautstärke verwendet.
  • nett - ich nehme an, dass dabei der Weg das Ziel war::hacking::

    Ansonsten ist die Kombination Kassettenadapter+Smartphone ja immer noch die einfachste Lösung, indem man die prgs als mp3s abspielt:tüdeldü:

    ...


    Evtl. hast Du ja einen Link zu einem How-To, oder so!

    Ich hatte in einem vorigen Post mal einen Link zu den progs und mp3s geschickt, die ich damals für meinen PET und 8032SK erstellt hatte. Den genauen Weg dorthin hab ich leider nicht dokumentiert. Ich kann dir nur noch ein paar Stichworte aus meiner (verblassenen) Erinnerung nennen:

    1. Programme für CBM findest du per Google zuhauf...
    2. wav-prg ist mir noch in Erinnerung, aber auch hier sollte Google weiterhelfen.
    3. Ich kann mich noch schwach entsinnen, dass man bei der Konvertierung beim Einstellen der Ladeadresse aufpassen musste, weil die z.B. beim C64 anders war wie bei älteren Generationen wie PET und 8032. Ob das bei dem oben genannten Tool war oder einem anderen, kann ich nicht mehr sagen.
    4. die WAVs können problemlos mit jedem Converter nach MP3 umgewandelt werden. Qualität spielt keine große Rolle (128Bit aufwärts sollten es aber schon sein).
    5. Beim Abspielen der MP3 vom Smartphone hab ich immer die größte Lautstärke verwendet.

    Den Link zu dem Post kann ich leider nicht öffnen.


    Ok, wie man das Ganze dann mit dem PET/CBM verkabelt, kannst Du mir dann wohl nicht beantworten(?).

    Das ist doch gerade der Knackpunkt.

    Oder ist das so trivial und ich komme da bloß nicht drauf?

  • Funktionieren die beiden Projekte eigentlich auch mit CBMs/PETs, oder nur mit dem C64?

    Tapuino funktioniert. Das verhält sich ja wie eine Datasette.


    Tapecart funktioniert leider nicht, weil das ein eigenes Protokoll verwendet und für den Kassettenport des C64 optimiert ist.

    Ich hatte ursprünglich mal den Plan, das für den PET zu adaptieren, aber das geht nicht, weil der Kassettenport beim PET intern anders belegt ist, so dass man die Geschwindigkeit nicht schafft. Das Tapecart-Modul ist am C64 sehr schnell.

  • um (z.B. selbst entwickelte) Programme auf CBMs/PETs zu bekommen (um nicht nur im Emulator zu testen, usw.).

    So was plane ich ja auch schon länger, aber da wäre mir der Kassettenport zu langsam. Mir schwebt da eher eine schnelle Userport-Lösung vor.


    Ich habe es auch schon über den IEEE-Bus versucht und konnte auch schon Programme auf dem PET laden (direkt vom PC über USB und Arduino an den IEEE-Bus). Auf dem PC lief eine keine Serversoftware. Aber da hatte ich Hardwareprobleme mit den Treibern, wenn noch andere Geräte am Bus hängen.


    Mit dem Lesen und Emulieren von Datasette habe ich mich auch schon beschäftigt. Aber alles mit Arduino und nur so aus Interesse ohne einen konkreten Nutzen.

  • hier nochmal der Link: http://peter-kuehn.de/docs/cbmprogs.zip

    Der kniffligere Teil ist das Umwandeln vom üblichen prg-Format nach wav. Einen billigen Kassettenadapter über den Klinkenstecker ins Handy einzustöpseln ist definitv der triviale Teil :tüdeldü:

  • An den Kassettenadapter habe ich tatsächlich nicht gedacht gerade, danke.


    Ok, beim Entwickeln und Testen von Software ist das mit dem Adapter dann einen Tick umständlicher,

    aber zum ab-und-zu Laden von PRGs aus dem Internet bestimmt ausreichend.

  • Den User Port hatte ich zunächst verwendet.

    Das Empfangsprogramm war dann aber u.U. im Speicher "im Weg" (je nachdem, was man laden will).

    Außerdem bin ich da unter Raspbian an eine Geschwindigkeitsgrenze gestoßen (Timing).

    U.a. aus diesen beiden Gründen dann der Wechsel zum Tape Port.


    Das Projekt findet Ihr hier: PetPi


    Ist aber nicht so gut dokumentiert (funktioniert aber!).

  • Du kannst den Adapter ja direkt in die Soundkarte deines Entwicklungs-PCs stecken, dann kannst du's direkt mit prg2wav rüberdudeln ;)

    klar - das ist der direkteste Weg. Mich hatte damals auch der Gedanke fasziniert, sozusagen dem 20 Kilo Urahnen (PET) vom 200gr Urenkel per Nabelschnur neues Leben einzuhauchen :smack:

  • Den User Port hatte ich zunächst verwendet.

    Das Empfangsprogramm war dann aber u.U. im Speicher "im Weg" (je nachdem, was man laden will).

    Außerdem bin ich da unter Raspbian an eine Geschwindigkeitsgrenze gestoßen (Timing).

    Ich habe in allen PETs ein RAM-ROM-Board mit Flash-Speicher im Bereich $9000-$B000. Da kann man solche Empfangsroutinen gut unterbringen.

    Wieso Geschwindigkeitsprobleme? Das kann man doch mit Handshake machen. Als Sender kann der Raspi die Geschwindigkeit vorgeben.

  • Den User Port hatte ich zunächst verwendet.

    Das Empfangsprogramm war dann aber u.U. im Speicher "im Weg" (je nachdem, was man laden will).

    Außerdem bin ich da unter Raspbian an eine Geschwindigkeitsgrenze gestoßen (Timing).

    Ich habe in allen PETs ein RAM-ROM-Board mit Flash-Speicher im Bereich $9000-$B000. Da kann man solche Empfangsroutinen gut unterbringen.

    Wieso Geschwindigkeitsprobleme? Das kann man doch mit Handshake machen. Als Sender kann der Raspi die Geschwindigkeit vorgeben.

    Handshake ist klar.


    Geschwindigkeitsprobleme in dem Sinne, als dass ich das Ganze nicht mehr schneller machen konnte.

    Meiner Meinung nach wegen des Time Sharings des Raspbian Linux.

    Aber es kann auch gut sein, dass jemand das geschickter hinbekommt,

    ich habe dann bloß das Projekt ruhen lassen.

    Aber - wie bereits geschrieben - auch das Projekt funktioniert zuverlässig.


    Ich muss dazu noch schreiben, dass ich auch bei PetPi versucht habe, so wenig Kabel (und Bauteile) wie möglich zu verwenden.

  • Geschwindigkeitsprobleme in dem Sinne, als dass ich das Ganze nicht mehr schneller machen konnte.

    Ich werde das, wie gesagt, demnächst mal mit dem Arduino aufbauen. Zum einen möchte ich über den Userport kommunizieren (da werden deine PetPi-Routinen sicher hilfreich sein) und dann plane ich auch eine Version für den Kassettenport, aber mit dem Tapecart-Protokoll. Das geht, wie gesagt, nicht so schnell wie auf dem C64, aber es sollte trotzdem deutlich schneller sein, also ein normaler Tape-Loader.

  • Geschwindigkeitsprobleme in dem Sinne, als dass ich das Ganze nicht mehr schneller machen konnte.

    Ich werde das, wie gesagt, demnächst mal mit dem Arduino aufbauen. Zum einen möchte ich über den Userport kommunizieren (da werden deine PetPi-Routinen sicher hilfreich sein) und dann plane ich auch eine Version für den Kassettenport, aber mit dem Tapecart-Protokoll. Das geht, wie gesagt, nicht so schnell wie auf dem C64, aber es sollte trotzdem deutlich schneller sein, also ein normaler Tape-Loader.

    Wenn Du mehrere Bits parallel überträgst, wird das bestimmt schneller gehen,

    ich hatte mich allerdings auf eine Datenleitung eingeschränkt.


    Trotzdem: Sag Bescheid, falls ich mit Erklärungen zum Source Code (oder so) helfen kann!

  • Warum braucht man da eigentlich noch einen PC extra ??

    Sinnvoller wäre doch eigentlich, wenn die Sachen direkt vom RPi kämen - oder ?


    Der könnte dann sogar auch gleich von selber mit dem Senden anfangen, sobald das "LOAD"+Return ausgeführt ist, wenn man das MotorSignal mit abfragt.

  • Warum braucht man da eigentlich noch einen PC extra ??

    Sinnvoller wäre doch eigentlich, wenn die Sachen direkt vom RPi kämen - oder ?


    Der könnte dann sogar auch gleich von selber mit dem Senden anfangen, sobald das "LOAD"+Return ausgeführt ist, wenn man das MotorSignal mit abfragt.

    Den PC braucht man nur extra, weil bisher nur die serielle Schnittstelle implementiert ist (ist halt bare-metal, also ohne OS auf dem Raspi).

    Ich hoffe, das in Zukunft weiterentwickeln zu können!


    Wenn ich mich richtig erinnere, wird die Motor-Spannung unabhängig vom LOAD eingeschaltet,

    sobald der Pegel der Sense-Leitung von der Datasette auf Masse gelegt wird (also beim Drücken von z.B. Play).


    D.h., automatisch geht das nicht, oder täusche ich mich??

  • (ist halt bare-metal, also ohne OS auf dem Raspi)


    OK, das ist mal was neues ... und vermutlich ziemlich anspruchsvoll.


    Wenn ich mich richtig erinnere, wird die Motor-Spannung unabhängig vom LOAD eingeschaltet,

    sobald der Pegel der Sense-Leitung von der Datasette auf Masse gelegt wird (also beim Drücken von z.B. Play).


    D.h., automatisch geht das nicht, oder täusche ich mich??


    Scheint so zu sein. Zumindest gibt es irgendwie kein Motor AN/AUS Flag. Die Kassettenroutine fragt (+4) anscheinend nur immer mal die STOP Taste ab. Das Abschalten passiert dann quasi "magisch". Zumindest habe ich jetzt auf die Schnelle kein richtiges Motor An/Aus finden können. Ich dachte immer sowas gibt es, weil die Kassette ja am Ende des Ladens irgendwie aufhört zu drehen.


    add-on: Es gibt zumindest am +4 ein Motor An/Aus, was über die Adresse $01 läuft und zwar mit

    lda $01 : and #$f5 : sta $01 zum Einschalten und

    lda $01 : ora #$08 : sta $01 zum Ausschalten

    Wer das wann aufruft, wer weiß ...

  • Stimmt, die Motorspannung wird dann ja nach dem Laden wieder abgeschaltet trotz Sense = low (= Taste immer noch gedrückt).


    Dann muss zumindest das Abschalten ja durch Software ausgelöst werden.


    Wird das Einschalten denn durch Hardware ausgelöst, oder per Interrupt-Routine?


    Müsste ich sonst mal Recherchieren, so interessehalber..

  • Wenn die Datassette inaktiv ist, wird im Interrupt abhängig von der Sense Leitung der Motor ein- und ausgeschaltet, damit man vor- und zurückspulen kann. Ist die Datassette aktiv (Load/Save...) wird der Motor ebenfalls über Sense gestartet, und angehalten, wenn der Vorgang abgeschlossen ist.

  • Hier auch nochmal ein Link zur Konfiguration von wav-prg: https://arekneubauer.com/en/pr…032-sk-datasette-emulator

    Das mit der Ladeadresse bezog sich wohl auf die PRG-Datei. Wenn das für das Zielsystem schon passt, sollte es ok sein. Ansonsten gibt es für eine Anpassung ja Tools für. Testen lassen sich die PRGs vorher immer auch in einem Emulator wie VICE.

  • Es gibt eine neue Version von CBM Tape Pi (v1.5.1).


    Damit funktioniert nun auch das Speichern von PRG-Dateien per SAVE-Befehl.


    D.h., es kann vom PC via Raspberry Pi per LOAD geladen und per SAVE auf den PC via Raspberry Pi gespeichert werden.


    Siehe auch (extrem professionell produzierte) Videos mit C64 und CBM3032.


    Alles weitere in der README bei GitHub.