1551 USB für Commodore Plus/4

Es gibt 31 Antworten in diesem Thema, welches 7.985 mal aufgerufen wurde. Der letzte Beitrag (20. August 2017 um 17:19) ist von RKSoft.

  • Falls jemand mitwirken möchte: ich trage alle bisherigen Erkenntnisse zusammen und veröffentliche alles auf meiner Website.

    Bitte melde dich an, um diesen Link zu sehen.

    Man braucht nur einen Arduino Uno, USB<->RS232 Adapter und ein Paddle einer Bruch-1551. Und natürlich einen PC und Plus/4. :) Kenntnisse in 6502-Assembler, AVR-GCC oder C++ wären ebenfalls angebracht.

    Funktioniert nun schon mal und könnte weiterentwickelt werden. Wird es aber auch so. :)

    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. |

  • Toll! Machst das wirklich als Arduino Projekt, oder setzt Du direkt auf der AVR Hardware auf? Weil ich mich für stm32duino interessiere.

  • Der Arduino ist eine einfache Lösung. Kostet nicht viel, man braucht keine Leiterplatte mehr und leicht programmierbar durch Bootloader. Um eine ordentlicher Verbindung zum Paddle herzustellen, braucht man nur Stiftleisten und etwas Litze. Dann kann man es schon in eine kleine Plastikdose bauen und den USB-Dongle nach Wunsch herausführen.
    So kann es jeder ohne große Kosten mit geringem Aufwand nachbauen.


    Btw ... den Rest trage ich morgen auf der Webseite ein.

    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. |

  • wieso braucht man keine Leiterplatte ? ?(
    Für dein Projekt vielleicht ;)

    Arcade: Twinliner, Fashion Vision,
    "Cosmic Guerilla" cocktail table
    Pins: Scared Stiff + Getaway
    C64, C65, C66, Gammel+Mist...

  • wieso braucht man keine Leiterplatte ?

    Der Arduino ist doch die Leiterplatte. Kostet voll bestückt zwischen 4-10€, je nach Quelle. Mt dem USB-RS232 und Verkabelung kann es für 15€ fertig sein. Mit dem Arduino Nano geht es auch in sehr klein und noch günstiger.

    Für dein Projekt vielleicht

    Da gibt es wohl eher tausende dieser Arduino-Projekte. Spricht für das Konzept dieses Aufbaus.

    Ein sehr ähnliches 1551-Paddle lässt sich ebenfalls mit zwei TTLs und einem 6522A nachbilden. Bei den paar Leuten, die da vielleicht vom PC speziell zum Plus/4 übertragen möchten, wäre es aber ein unsinniger Aufwand.

    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. |

  • Ich mache Fortschritte:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Ein internes ROM wirft schon mal eine Empfangssoftware für den Tape-Buffer (mit bequemer Syszeile) heraus und damit können dann auch große Programme (32KByte>) transferiert werden. PRG-Spiele können z.B. bei Plus/4-World heruntergeladen und in Sekunden transferiert werden. Auch für CrossDev einfach nur super bequem. :)

    Gelegentlich werden hier Source-Schnipsel veröffentlicht: Bitte melde dich an, um diesen Link zu sehen.

    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. |

  • Ein sehr ähnliches 1551-Paddle lässt sich ebenfalls mit zwei TTLs und einem 6522A nachbilden.

    Durchaus noch ein bisschen interessanter wäre die Verwendung von Pin 18 der PLA. Der ist in allen 264ern unbenutzt und dekodiert auf $FD20-$FD2F wenn ich das noch richtig weiss. Bis auf einen STA in der RESET-Routine des KERNAL wird dieser Bereich nie angesprochen.

    Netterweise hat der Expansionport ein paar mit 'NC' bezeichnete Pins. :)

  • Durchaus noch ein bisschen interessanter wäre die Verwendung von Pin 18 der PLA. Der ist in allen 264ern unbenutzt und dekodiert auf $FD20-$FD2F wenn ich das noch richtig weiss. Bis auf einen STA in der RESET-Routine des KERNAL wird dieser Bereich nie angesprochen.

    Netterweise hat der Expansionport ein paar mit 'NC' bezeichnete Pins.


    Ich möchte lieber ohne Eingriffe in den P/4 auskommen. Wenn jemand ein Paddle der 1551 dazwischen steckt, ist 'NC' dann auch wieder 'NC'.


    Ich beobachte dieses Thema ja mit richtiger Neugier. Hoffe, daß alles bald richtig klappt. Sowas wäre der Hammer für unsere 264er


    Ach, das läuft schon. Im Moment habe ich aber bestenfalls ein paar Code-Beispiele oder Bilder:

    Bitte melde dich an, um diesen Anhang zu sehen.Bitte melde dich an, um diesen Anhang zu sehen.Bitte melde dich an, um diesen Anhang zu sehen.

    Hatte eben eine erste Version der ROM-Software auf ein Eprom gebrannt und das alte "3plus1" ersetzt. Danach mal testweise Xplodeman (Bomberman Klon) transferiert und es läuft. Nettes kleines Spiel.
    Jetzt habe ich schon mal eine feste Brücke für Cross-Development.


    In Deutschland kenne ich niemanden, der über das technische Know-How verfügt und an einem Plus/4 etwas machen möchte. Daher ist es eine "One-Man-Show", die immer etwas dauert.

    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. |

  • Ich bleibe am Ball. Eigentlich fehlt nur noch die Richtung P4 nach PC. Da bin ich mir im Moment noch nicht ganz im Klaren, was da transferiert werden sollte.
    Speichersegmente ($1000 - $variabel) oder per Pointer. Ganz nützlich wäre auch das Einlesen eines D64 von der 1551. Die schafft ca. 1,6kByte/s, da könnte ein D64 in 2 Minuten zum PC rüber zuckeln.
    Am PC kann man dann (mit Linux) ganz einfach per: cat myd64.d64 </dev/ttyUSB0 in eine Datei schreiben.

    Ein festes Verzeichnis am PC wie damals dieses HDD64 (?) verwendete wäre auch machbar. Mit höherem PC-Programmaufwand auch Lesen aus einem D64.

    Im Moment setzt der AVR zwei Statusbits auf "1", damit der P/4 das aktive Interface erkennen kann. Das würde ich dann erweitern: AVR %11 setzen, P/4 erkennt und sendet ACK, PC setzt Statusbits auf Eingang und wartet wieder auf ACK. Wenn der P/4 die dann löscht, geht der Datenverkehr in Richtung PC.

    Im Moment ist der Source zum gestern erwähnten ROM online: Bitte melde dich an, um diesen Link zu sehen.

    Der einfache Nachbau mit Arduino, also einfaches I/O auf I/O verbinden, funktioniert damit nach dieser Anleitung: Bitte melde dich an, um diesen Link zu sehen.

    Beim C++ Listing ist eine kleine Unsicherheit drin. Es wird nicht abgefragt, ob überhaupt ein unvollständiger Block vorhanden ist.

    Patch:

    Code
    if (rest != 0) 
            {    
    
            for(i=0; i<=255-rest; i++)
             {
               buffer2[size+3+a] = 0;
               a++; 
              }
             }

    Ich mache mir mal Gedanken, wie die Transfermöglichkeiten in Richtung PC aussehen könnten. Ansonsten kann es jeder gern aufgreifen und selbst mitwirken.

    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. |

  • Jetzt ich doch ein merkwürdiges Problem aufgetaucht, das ich erst bemerkte, als ich gepackte Programme transferierte.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Hier wurde Kikstart 2 ,einer dieser Versionen aus dem Leveleditor übertragen. An Stelle $1082 sieht man links $21 was aber $20 sein sollte. Und dieser Fehler ist reproduzierbar ! - Ich hatte es dreimal übertragen und immer wieder $21 an der gleichen Stelle wo $20 hingehört. Danach hatte ich dann ein anderes gepacktes prg (gut 10kByte) zum Testen verwendet. Wieder war in der Nähe dieses Bereichs Bit0 einmal falsch gesetzt.

    Der IRQ ist gesperrt und ich habe im AVR schon die Variable bei jedem Cycle auf 0 gesetzt, bevor diese das neue Byte aufnimmt. Der PC liest in ein Array und übertragt dieses. Da kann das Problem nicht herkommen.


    Das Diag264-Modul meint, dass der Speicher fehlerfrei ist. Wonach suche ich jetzt ?

    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. |

  • Bau dir mal eine Datei die nur aus $20 besteht und übertrage die. Dann schau nach ob noch woanders solche Fehler zu sehen sind. Sollte sich ein Muster zeigen erleichtert das das Debugging ungemein.

  • Die Idee ist nicht schlecht. Ich habe den Bereich von $1020 bis $8000 mit $20 gefüllt. Beim Plus/4 kurz im Monitor alles auf $00 in diesem Bereich und zweimal übertragen. Das Ergebnis ist immer gleich:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Ob ich da nicht doch mal das Bit 0 RAM tausche ?

    Edit: Am RAM liegt es nicht. Nach Reset und Laden des Tapebuffer-Loaders war die Übertragung ohne Fehler. Muss wohl an der ROM-Version liegen.

    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. |

    Einmal editiert, zuletzt von cbmhardware (26. Februar 2017 um 11:21)

  • ROM-Version? Du meinst die im Rechner? Welchen KERNAL hast du denn drin?

    Schreib mal eine Datei mit lauter $00 als Inhalt und eine mit $FF als Inhalt und schau nach ob sich noch andere Bits ungebührlich verhalten.

  • Ich meine meinen Function Lo Ersatz: Bitte melde dich an, um diesen Link zu sehen. , da wird das Problem beim Verlassen des ROM liegen. Wenn ich den identischen Loader vom SD2IEC lade, ist auch alles richtig im Speicher. Beim Entpacken hängt es sich dann aber auf.

    Also folgende Prozedur funktioniert: Loader für den Tapebuffer vom SD2IEC laden, übertragen und die empfangende Datei auf SD2IEC speichern. Reset und vom SD2IEC laden: entpackt und läuft.

    Hatte die übertragenen Daten auch noch mit dem gesendeten PRG verglichen: alles passend.

    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. |

  • Ein Problem scheinen auch diese alten und nicht besonders effektiven Packer zu sein. Habe Kikstart 2 mit Vice entpackt, $1001-$4000 gespeichert und dann neu gepackt:

    exomizer sfx 0x2000 kstart2 -t4 -o kick2.prg -n

    Aus ehemals 8370 wurden 5784 Bytes. Und das lässt sich dann nach dem Transfer auch ohne irgendwelche Verrenkungen entpacken. Auch nach Nutzung des ROM.

  • Ein Problem scheinen auch diese alten und nicht besonders effektiven Packer zu sein. Habe Kikstart 2 mit Vice entpackt, $1001-$4000 gespeichert und dann neu gepackt

    Das ist aber nur Rumdoktern an den Symptomen - wenn dein Übertragungsbug nur bei bestimmten Datenmustern auftritt, wird der natürlich durch Änderung der übertragenen Daten nicht mehr getriggert.

    Vielleicht hast du eine Abhängigkeit zu den zuvor übertragenen Bytes, z.B. durch zu langsam auf High oder Low wechselnde Leitungen? Ich würde zB mal versuchen, das Byte vor dem betroffenen per Hexeditor zu manipulieren (zB auf 0x66 - alle Bits invertiert) um zu testen, ob der Fehler dann immer noch auftritt.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Das ist aber nur Rumdoktern an den Symptomen - wenn dein Übertragungsbug nur bei bestimmten Datenmustern auftritt, wird der natürlich durch Änderung der übertragenen Daten nicht mehr getriggert.

    Nicht nur. :) Mit der von Speicherkarte geladenen Version ist alles fehlerfrei und wird (mit Exomizer gepackt) auch passend entpackt.

    Das Problem tritt nur bei der ROM-Version auf. Ich hatte jetzt auch bemerkt, dass nach dem Übertragen und Reset, nur noch (iirc) 12277 Bytes Free angezeigt wurden. Da hilft dann nur noch Ein/Ausschalten auf 60671 Bytes free.

    Ich muss da die Routine zum Initialisieren des RAM einbauen, ohne das Löschen des Tapebuffer-Loader. Dann sollte es imo funktionieren.


    Grundlegend funktioniert die Übertragung fehlerfrei. Nur nach Sprung aus meinem ROM passieren merkwürdige Dinge. Da muss ich nachbessern.

    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. |

  • Das Problem tritt nur bei der ROM-Version auf. Ich hatte jetzt auch bemerkt, dass nach dem Übertragen und Reset, nur noch (iirc) 12277 Bytes Free angezeigt wurden. Da hilft dann nur noch Ein/Ausschalten auf 60671 Bytes free.

    Das sind halt C-16 Programme, die früher nur mit dem Maschinensprachemonitor geschrieben wurden und einfach alles abgespeichert wurde.

    Es kann ohne weiteres sein (je nach verbauten RAM's), das auch nach 2 sek. Aus- u. Einschalten noch fast alles im Speicher steht. Abgesehen dann von den ersten paar Bytes am Basicanfang.

    Wer diesen Spuk loswerden will, gehe bitte in den Maschinensprachemonitor und gebe dort folgendes ein:
    F 1000 FD00 00
    und löse danach einen Reset aus. Dann hat man auch wirklich wieder 60671 Bytes free.