Beiträge von RhinoDevel

    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.

    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!).

    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.

    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?

    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!

    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..).

    Endlich konnte ich weiter machen

    (es fehlten mir noch Sockel für den nicht-destruktiven NOP-Generator-Bau).


    Mit NOP-Generator sehen die Signale an den Adressleitungen gut aus:

    • Von ca. 250kHz an A0 bis ca. 7,6Hz an A15 wird die Frequenz immer jeweils durch zwei dividiert.
    • Low-Pegel ist durchgängig bei ungefähr 0V (also unter 0,8V).
    • High-Pegel ist immer bei ca. 3,5V (also über 2V).

    Die Überprüfung der Datenleitungen folgt!

    Genau, da ist eine "8032090"-Platine drinnen, inklusive Pieper

    (auf der Oberseite steht 8032089, aber auf der Unterseite 8032090).

    Siehe mein erstes Posting - das passt dann auch mit den verlinkten Schaltplänen

    (Universal Dynamic PET "2").


    Das habe ich bisher nicht beobachtet, die Pegel sehen diesbezüglich gut aus.


    Allerdings ist es wohl am sinnvollsten, den NOP Tester zu bauen,

    damit ich genau weiß, was ich an dem entsprechenden Adress-PIN zu erwarten habe (also welche Frequenz).


    Die Daten-PINs schaue ich mir auch - wie von Helmut beschrieben - an.


    Ich gebe Rückmeldung, sobald ich konkretes herausgefunden habe (kann etwas dauern).

    Vielen Dank ersteinmal, Helmut!


    Nach Köln schaffe ich das leider nicht am 25.11.


    Aber ich werde, sobald wie möglich, Deine Tipps in die Tat umsetzen

    (eventuell kommen vorher noch laienhafte Rückfragen von meiner Seite..).


    Was ich schon weiß:


    Es sind (sich ändernde) Signale auf den Adress- und Datenleitungen,

    aber ich schaue mir das noch einmal genau an.

    In meinem kürzlich erstandenen


    4032-32N


    ist ein Mainboard mit Beschriftung:


    Universal Dynamic PET Assy. No. 8032089


    Leider gibt es nach dem Einschalten nicht den erwarteten Ton

    und auf dem Bildschirm ist nur mittig eine blinkende horizontale Linie zu sehen.

    Wenn ich eine Datasette anschließe, läuft der Motor beim Einschalten nicht an,

    er läuft auch nicht nach Tastendruck.


    Mit Hilfe der Schaltpläne von


    http://www.zimmers.net/anonftp…ters/pet/univ2/index.html


    habe ich die Versorgungs-Spannungen auf der Platine kontrolliert

    und auch an (den meisten) ICs, außerdem an der CPU die diversen Taktsignale

    (Ein- und Ausgänge). Reset, IRQ und NMI scheinen auch OK zu sein.


    Danach traute ich mich, das 6502 RAM/ROM Replacement Board

    (http://blog.tynemouthsoftware.…e-pet-rom-ram-boards.html) zu verwenden.


    Damit habe ich die originalen RAM- und ROM-Bausteine übergangen

    und auch (hoffentlich) evtl. Probleme mit diesen.


    Trotzdem keine Änderung. :(


    Meine Fragen:

    1) An VSYNC (aus dem 6545-1) liegt das auf dem Bild zu sehende Signal an.

    Gehört das so? Gibt es Referenz-Bilder (HSYNC, VSYNC, usw.) irgendwo im Internet?




    2) Kann ein defekter CRTC-Chip (also der 6545) die Ursache dafür sein,

    dass nicht gestartet wird (wie gesagt, weder Einschalt-Ton, noch Datasetten-"Reaktion")?


    3) Hat noch jemand Tipps?


    Ich kann auch noch mehr Details liefern, falls hilfreich.


    Danke im Voraus!