Beiträge von cbmhardware im Thema „1551 USB für Commodore Plus/4“

    1.21 Sekunden vom ungarischen (?) Server bis zum Programmstart. :)

    Habe mal eine eigene Sammelstelle für sicher funktionierende Programme angelegt: Bitte melde dich an, um diesen Link zu sehen. Wird mit der Zeit mehr ...

    dl.sh

    Bash
    #!/bin/bash
    wget $1
    filename=${1##*/}
    if [ -f ${filename} ]
    then
    send -f ${filename} 
    rm ${filename}
    else
    echo File not found !
    fi


    ,/dl.sh Bitte melde dich an, um diesen Link zu sehen.

    (URL im Browser mit "Link-Adresse kopieren" holen.)

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

    Heute gab es mal einen ersten Versuch, kleine Spiele direkt vom ftp auf den Plus/4 zu bringen. Schreibe noch am Bash-Script, aber prinzipiell funktioniert es schon mal. Einige alte Packer wollen nicht und für ZIP brauche ich noch eine zusätzliche Behandlung. Ist dann natürlich nur für Linux.

    Vielleicht richte ich mal einen kleinen ftp mit garantiert funktionstüchtigen Spielen (umgepackt mit Exomizer) an.


    Das Script lädt die Datei per wget runter, überprüft das Vorhandensein und sendet dann zum Plus/4:


    Bitte melde dich an, um diesen Anhang zu sehen.

    Ein kleines ROM-Update auf Version 0.3: Bitte melde dich an, um diesen Link zu sehen.

    Der "32K+ Loader" wird nun vollständig aus dem ROM heraus gestartet und liegt ab $0333 im Speicher.
    Der Border ändert nach jedem gesendeten Block die Farbe um Aktivität zu signalisieren.
    Ein kleiner Fade-In Effekt kam hinzu.
    Kleine Optische Änderungen: "1551USB ON KEY F1" mit passenden Leerzeichen.

    Bekannte Probleme:
    Einige alte RLE-Packer wollen nach dem Senden nicht richtig entpacken.
    Nach dem Empfang erscheint "?SYNTAX ERROR IN 10". Nervt, beeinträchtigt aber die Funktion nicht.

    Ansonsten stabil und schnell:

    Code
    root@michael-CELSIUS-W280:/home/michael/c16# send -f kikstart.prg
    # Complete Blocks : 24 
    # Carryover Bytes : 213 
    # Low-Address: 0X1 
    # High-Address: 0X10 
    # Filename: kikstart.prg 
    # Adding Pointer: 6405 Bytes 
    # Completing Blocks: 25 
    # Sending @ 57600 bps 
    # Runtime: 1.20 Seconds


    Mal kurz Kikstart rüber gebeamt. :)

    Ein kleines Update: der Function Lo ROM-Code wurde überarbeitet und erweitert.

    Bitte melde dich an, um diesen Link zu sehen. Function-ROM Lo V0.2

    Bitte melde dich an, um diesen Anhang zu sehen.

    Das Problem mit dem geknickten Bit ist auch behoben.

    Weil viel freier Speicher da war und es so schön bequem ist, wurde ein Directoy-Browser fürs SD2IEC eingebaut: Bitte melde dich an, um diesen Link zu sehen.
    Geht mit Jiffy schon schaurig ab. :)


    Code
    michael@michael-CELSIUS-W280:~/c16/games$ sudo send -f Mercenary.prg
    # Complete Blocks : 236 
    # Carryover Bytes : 231 
    # Low-Address: 0X1 
    # High-Address: 0X10 
    # Filename: Mercenary.prg 
    # Adding Pointer: 60677bytes 
    # Completing Blocks: 237 
    # Sending @ 57600 bps 
    Laufzeit: 10.90 Sekunden


    Der letzte Test mit angebundenen Linux cat und Laufzeitmessung. In rund 11 Sekunden ist der Speicher voll. Da sehe ich keinen Nachbesserungsbedarf in Punkto Geschwindigkeit.
    Bei kleinen CrossDev-Experimenten liege ich meist deutlich unter 0,5 Sekunden.

    Ja, so macht man eine Speichergrößenerkennung- einfach und elegant. Bei dem Wildwuchs namens B128 hat man dazu noch zwei wertvolle Portbits vergeudet und je nach Speichergröße einen anderen ROM-Satz vorgesehen. B128 war die Kiste, die nie aus dem Quark kam, was zunächst zum abgespeckten C64 führte und 'etwas' später in einer Hauruck-Aktion als C128 zur Marktreife fertig-entwickelt wurde.


    Die Vorgehensweise bei den B-Rechnern kenne ich,habe die vom 610, 710 bis zum P500 da. Beim Plus/4 hat das aber zwei kleine Nachteile: es ist unnötig und funktioniert sichtlich nicht richtig.


    Jedenfalls bin ich froh, daß ich derzeit anderes um die Ohren hab als meine Unterlagen zum TDISK-Interface auszubuddeln. Ich hatte doch tatsächlich gedacht daß es um ein ernsthaftes Projekt ginge und nicht nur um eine weitere Forum-Zumüll-Aktion


    Hier geht es um ein funktionierendes kleines und sehr flexibles Projekt. Prinzipiell läßt sich das Konzept an jedem C=-Rechner mit vollständigem Userport (8Bit+2Handshake Bits) verwenden. Das habe ich später auch noch für meinen CBM 2001 vor.

    Ich erwähne es nochmals: es ist absichtlich durch den Arduino (Uno oder Nano) so einfach konzipiert, damit die drei etwaigen Interessenten das bei Bedarf nachbilden können. Das zu irgendeinem großen Projekt aufzublasen wäre einfach unsinnig, daher das kostengünstige Baukastenprinzip.

    Meine Zeit ist auch begrenzt, daher möchte ich Dich auch bitten, das Thema nicht weiter mit Flames zu zumüllen. Ein eigenes Interface hatte ich auch schon angedacht (mit 6522A und 8255 PLCC). Das ist sehr einfach, aber auch dumm und unnötig.

    Nein. Das geht auf einer 16K-Maschine nicht anders (oder die Kiste schmiert ab). Speicher das nur bis 3ffb und gut is'.


    Da wird aber doch geprüft, wo man mit der oberen Adressleitungen schreibt. Das hätte man sich beim Plus/4 mit immer gleichem 64KB-Speicherausbau auch schenken können.

    Ich brauche schon den "ganzen" Speicher.


    (sind wir eiigentlich grad bei den Idiosynkratien von 16K-Proggrammen, dem kaputten Cartridge-Header oder dem USB-2-TDISK?)


    Generell beim merkwürdigen Verhau namens Plus/4. :)

    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.


    Das Programm wurde von mir ($1001-$4000) neu gespeichert und mit Exomizer gepackt. Dahin wird es dann auch wieder entpackt und ab $2000 gestartet.

    Da reicht ein "f 3ffd 3fff 00" und nach dem Reset passt die "60671 Bytes free" Anzeige wieder. Scheint wohl ein Fehler im ROM zu sein ?

    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.

    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.

    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.

    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 ?

    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.

    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.

    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.

    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.

    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.

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