XS1541 - universal serial adapter for CBM Floppy

Es gibt 209 Antworten in diesem Thema, welches 50.291 mal aufgerufen wurde. Der letzte Beitrag (1. Juli 2009 um 23:14) ist von DerSchatten.

  • Ja, eine magische Bytekette wo das XS sich meldet und, bis zum nächsten Reset, mit einem Binär redet währe toll :)
    So nach dem Motto 0xFF, 0x00, 0xFF und als Antwort kommen dann 6 bytes "XS1541"

    Übrigens, kannst du das blinken der LED abschaffen? Da krisse nache Zeit Kreise inne Augen von... :@1@:

    Edith:
    Das XS hängt sich auf, zumindest habe ich keine Geduld länger wie 10 Sekunden zu warten, wenn kein Gerät am Strang ist bzw. es ausgeschaltet ist.
    Lass ihn es 3 Sekunden versuchen und danach ein "no device" ausgeben. :)

    Blog: Bitte melde dich an, um diesen Link zu sehen. - The Seventies Board: Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ein Terminal und ein Z80 :D

    Einmal editiert, zuletzt von BastetFurry (12. September 2008 um 02:36)

  • Ja, eine magische Bytekette wo das XS sich meldet und, bis zum nächsten Reset, mit einem Binär redet währe toll :)

    Ein Binärmode? Würde Sinn machen bei so einem "Remote Betrieb". Das Problem ist die Synchronisation die jetzt automatisch durch das Zeilenende Zeichen erfolgt. Man müßte sich ein "Protokoll" überlegen. Aber grundsätzlich gerne, Ideen?


    Übrigens, kannst du das blinken der LED abschaffen? Da krisse nache Zeit Kreise inne Augen von... :@1@:


    Ich finde es praktisch, weil ich sofort sehe ob es richtig läuft und ob es in der Eingabeloop ist. Aber kein Problem, ich mach ein Kommando zum abschalten des Blinken. Inzwischen kannst du die LED per Jumper abschalten.


    Das XS hängt sich auf, zumindest habe ich keine Geduld länger wie 10 Sekunden zu warten, wenn kein Gerät am Strang ist bzw. es ausgeschaltet ist.
    Lass ihn es 3 Sekunden versuchen und danach ein "no device" ausgeben. :)


    Das liegt daran, dass wir an PullUp Widerständen gespart haben. Nach Eingabe von LP (ListPort) sieht man dass alle Leitungen auf Low sind sind wenn keine eingeschaltene Floppy angeschlossen ist.

    Da würde auch ein CeVi ewig warten bei dem Buszustand.

    Kannst du beheben indem du 5 Widerstände einlötest Gegen + oder eine zweite Floppy anschliesst die läuft.

    Softwaremäßig kannst du das mit LP erfragen dass der Bus "leer" ist.

    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.

  • Ein Binärmode? Würde Sinn machen bei so einem "Remote Betrieb". Das Problem ist die Synchronisation die jetzt automatisch durch das Zeilenende Zeichen erfolgt. Man müßte sich ein "Protokoll" überlegen. Aber grundsätzlich gerne, Ideen?


    Naja, es würde schon mal helfen wenn man das Echoverhalten ändern könnte, so muss ich aus der Antwort jedes mal meinen gesendeten Befehl aussortieren.

    Blog: Bitte melde dich an, um diesen Link zu sehen. - The Seventies Board: Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ein Terminal und ein Z80 :D

  • Naja, es würde schon mal helfen wenn man das Echoverhalten ändern könnte, so muss ich aus der Antwort jedes mal meinen gesendeten Befehl aussortieren.

    Das ist eine ganz einfache Aufgabe. Ursprünglich hatte ich auch kein Echo, extra wegen PeterSieg eingebaut ...

    Ich mach gleich heute eine Version wo Echo und LED blinken ausschaltbar sind.

    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.

  • Hallo Diddl,

    Das liegt daran, dass wir an PullUp Widerständen gespart haben. Nach Eingabe von LP (ListPort) sieht man dass alle Leitungen auf Low sind sind wenn keine eingeschaltene Floppy angeschlossen ist.

    Da würde auch ein CeVi ewig warten bei dem Buszustand.

    Kannst du beheben indem du 5 Widerstände einlötest Gegen + oder eine zweite Floppy anschliesst die läuft.


    Der AVR hat interne Pullup-Wistände. Diese muß man nur softwaretechnisch einschalten. Ein gesetzes PORTx.y = 1 schaltet diese im Eingabebetrieb (DDRx.y = 0) ein!

    Gruß Martin

  • Der AVR hat interne Pullup-Wistände. Diese muß man nur softwaretechnisch einschalten. Ein gesetzes PORTx.y = 1 schaltet diese im Eingabebetrieb (DDRx.y = 0) ein!

    Das ist richtig aber dann kann man nicht mehr mit einem Befehl die Signale schalten und man hat, weil man zwei Zugriffe braucht unerwünschte Signaleinbrüche.

    Außerdem braucht es nicht mehr. Wer es "schön" machen will soll Widerstände einbauen und sonst muß er halt darauf achten zumindest eine Floppy einzuschalten.

    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.

  • Hallo Diddl,

    Das ist richtig aber dann kann man nicht mehr mit einem Befehl die Signale schalten und man hat, weil man zwei Zugriffe braucht unerwünschte Signaleinbrüche.


    Der zusätzliche Befehl sollte nicht das Problem sein. Auch dürten die Signaleinbrüche durch eine geschickte Wahl der beiden Befehle sich beseitigen lassen. Dazu muß man die Pullup-Widerstände immer nur ein- und ausschalten, wenn der Port im Eingabemodus ist.

    Code
    SetBit:
    DDRx.y  = 0 'Ausgangstreiber hochohmig schalten
    PORTx.y = 1 'Pullup-Widerstand einschalten
    
    
    ClrBit:
    PORTx.y = 0 'Pullup-Widerstände ausschalten
    DDRx.y  = 1 'Wie Open-Kollektor nach log. "0" schalten


    Klar ändert sich ein wenig das Verhalten, ob eine Floppy angeschlossen ist oder nicht. Entweder wird schon ein Welchsel von Low nach High (SetBit) nach dem Löschen des DDR-Bits erkannt (wenn ein externer Pullup-Widerstand in einer Floppy existiert) oder erst nach dem Einschalten des Widerstandes mittels dem Setzen des PORT-Bits. Entsprechend auch im umgekehrten Fall (ClrBit).

    Sicherlich kann man nun darüber diskutieren, ob das nur ein Schönheitsfehler ist oder ein wirklicher Bug. Trotzdem ist dieser Fehler in meinen Augen sehr einfach zu beheben und damit wird das Ganze zumindest ein wenig normgerecht. Ich jedenfalls würde es begrüßen!

    Gruß Martin

  • Was man auch machen könnte währe das das XS auf der RS232 Leitung lauscht wenn es sich mit dem IEC/IEEE Bus beschäftigt und alles abbricht wenn ein Escape Zeichen (Dezimal 27) kommt.
    So könnte Beispielsweise das Frontend 5 Sekunden warten und danach Escape senden bis ein "BREAK." zurück kommt.

    Blog: Bitte melde dich an, um diesen Link zu sehen. - The Seventies Board: Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ein Terminal und ein Z80 :D

  • Gute Idee, leider etwas aufwendig. Den ESC Character könte ich im UART Interrupt abfangen. Aber dann muß ich jede potentielle Schleife verändern. Noch dazu muß man sich überlegen den Bus entsprechend zu "normalisieren" damit er in keinem undefinierten Zustand hängen bleibt.

    Beim IEEE kann eigentlich eh nix passieren. Da ist alles mit 65ms bzw. mit 500ms gesichert. Die ST Variable Bit 0 und 1 reflektieren Timeouts beim Read und Write. Geschieht genau so wie beim 8296.

    Nur der IEC hat so ein miesses Protokoll wo es leicht Deadloops geben kann ... :(


    Ich schau mir das mal genauer an.

    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.

  • Hmm... *denk* potentielle Implementierung:
    ESC im IRQ -> Sind wir in einer Datenübertragung?
    Ja -> Ignorieren
    Nein -> Reset Routine anspringen welche alles initialisiert, am besten sogar einmal Reset aufm IEC/IEEE Bus auf Low zieht.

    Reset des Busses könnte man übrigens auch als Befehl gebrauchen, derzeit sieht das bei mir nämlich so aus:

    Code
    ''''''Reset the drive
        SendString "rp RST"+CRLF
        sleep 500,1
        rs = GetString
        SendString "sp RST"+CRLF
        sleep 500,1
        rs = GetString

    Blog: Bitte melde dich an, um diesen Link zu sehen. - The Seventies Board: Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ein Terminal und ein Z80 :D

  • Nachtrag:
    Grad rausgefunden das zwei IEC Geräte (8: 1541-I 9:1581) am Bus den Bus blockieren.

    Blog: Bitte melde dich an, um diesen Link zu sehen. - The Seventies Board: Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ein Terminal und ein Z80 :D

  • So, ich hab mir wohl für heute etwas zuviel vorgenommen, aus XS-1541 coden ist leider nix geworden (das war die Schlechte). Die gute Nachricht ist, die Doku ist jetzt halbwegs auf Vordermann gebracht (siehe unten).


    Habe jetzt endlich eine parallele 1541 und starte demnächst die parallelen Routinen im XS-1541. Dazu habe ich ein USB Board von Olimex voll ausgebaut mit IEC, IEEE und SpeedDos Port.

    Das parallel Floppy Kabel habe ich geteilt und je einen 15 poligen Stecker dran gemacht an jedem Ende (1541 <---> 15pol., 15 pol- <---> Userport). An dem XS-1541 ist nun auch so ein 15 poliger Stecker. Ich kann damit die Floppy wahlweise am Userport des C128 betreiben oder am XS-1541. Ganz nach Vorlage des XAP-1541 Adapter.

    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.


    Die Todo's sind auch klar:

    • Blinken ausschaltbar
    • Echo ausschaltbar
    • Unterbrechbar mit <ESC>
    • Busblockade bei 2 Geräte (könnte mit dem Burstmode zusammenhängen).

    Reset der Floppy geht jetzt schon. Zumindest für die IEC Floppys:

    iec
    rp res
    "250 ms warten"
    sp res


    Befehls Syntax

    Die Befehle können direkt im Terminal Programm eingegeben werden und werden direkt vom Controller ausgeführt. Dadurch ist man komplett unabhängig von der Hardware. Das funktioniert auf jedem PC, unter Windows, Linux oder Apple OS, es muß nicht mal ein PC sein.

    Optional kann natürlich auch ein Programm am PC erstellt werden, mit dem man komfortabel auf den XS1541 Adapter zugreifen kann. Dazu kann man jede beliebige Programmiersprache benutzen, die auf den seriellen Port zugreifen kann.


    Einige Befehle kontrollieren direkt das Protokoll oder sogar die Portleitungen. Diese "low level" Befehle sind zum Test des Adapter bzw. für PC Programme gedacht.


    Jeder Befehl hat einen Mussteil und einen Kannteil. Der Kannteil kann ganz oder teilweise weggelassen werden. Der Kannteil steht in rechteckigen Klammern. Manche Befehle haben mehrere Kürzel.


    h[elp]

    Listet alle Befehle die in der Firmware des Controller implementiert sind. Es kann 'h', 'he', 'hel' oder 'help' eingegeben werden.


    iee[e]

    Der aktive Bus wird zum parallelen IEEE-488 Bus geschalten. Alle Nachfolgenden Befehle (außer IEC) beziehen sich nun auf den IEEE-488 Bus. Dieser Modus ist die Standard Einstellung nach einem Controller Reset.


    iec

    Der aktive Bus wird zum seriellen IEC Bus geschalten. Alle Nachfolgenden Befehle (außer IEEE) beziehen sich nun auf den IEC Bus.


    dev[ice] oder # [d#] [floppy-typ]

    Damit wird die aktive Gerätenummer und der Floppy Typ des aktiven Bus festgelegt oder abgefragt. Dem Befehl folgt ein numerischer Parameter (Gerätenummer 8 - 12) und/oder ein Floppytyp. Der Befehl alleine ohne Parameter listet die aktuelle Einstellung. Für beide Bus Systeme ist die voreingestellte Adresse nach einem Reset 8.

    Beispiele:

    Bitte melde dich an, um diesen Link zu sehen.

    setzt die Gerätenummer 9.

    Bitte melde dich an, um diesen Link zu sehen.

    setzt den Floppytyp 1571.

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

    setzt die Gerätenummer 10 und den Floppytyp 1581.


    @

    Dieser Befehl sendet einen Befehl an die aktive Floppy (Befehlskanal 15) oder fragt den Fehlerkanal / Status ab wenn der Befehl alleine (ohne Parameter) gesendet wird.

    Beispiele:

    @

    fragt den Fehlerkanal ab und zeigt den Floppystatus an

    @I1

    sendet den befehl I (inquire) and die Floppy (Laufwerk 1)

    @N:TESTDISK,I2

    formatiert die Diskette im Laufwerk, setzt den Namen "TESTDISK" und die ID "I2".


    dir[ectory] oder ca[talog] oder $

    Listet das Verzeichnis der eingelegten Diskette. Als Parameter kann optional ein String mitgegeben werden. Das Format entspricht dem des Floppy DOS (load "$....",8). Bei Doppelfloppy sollte man als Parameter zumindest das Laufwerk (0 oder 1) mitgeben, sonst wird das Verzeichnis beider Laufwerke ausgegeben, was zu einem Fehler führt wenn nicht beide Laufwerke formatierte Disketten eingelegt haben.

    Beispiele:

    $0

    listet das Directory der Diskette im Laufwerk 0.

    $1:A*

    listet alle Dateien der Diskette im Laufwerk 1 die mit "A" beginnen.


    filec[opy] oder fc *** noch nicht implementiert

    Kopiert Dateien von Floppy zu Floppy. IEC zu IEEE oder umgekehrt ist möglich, aber auch von einem Gerät zum anderen am selben Bus.


    listb[am] oder lb [all|bam] [slow|burst|parallel|s1|s2|warp] [drive] [imagetyp]

    Liest die BAM der Diskette und zeigt die Mappe der belegten und freien Blöcke an. Wichtig ist hier dass der Laufwerkstyp


    bac[kup] oder bu [all|bam] [slow|burst|parallel|s1|s2|warp] [drive] [imagetyp]

    Damit kopiert man eine ganze Diskette zum PC. Es wird eine Image Datei erstellt von einer Diskette (.d64, .d72, .d80, .d81, .d82). Die Image Datei wird per Y-Modem Protokoll direkt auf die Festplatte des PC gespeichert. Als Laufwerk kann "D0" oder "D1" angegeben werden. Man wählt ob alle Blöcke kopiert werden sollen [all] oder nur die Belegten [bam]. Für jedes Laufwerk gibt es eine Standard Einstellung für den Busverkehr, man kann aber ein bestimmtes Protokoll erzwingen [burst, parallel]. Natürlich nur wenn die Floppy das auch unterstützt.

    Beispiel:

    bu D0 d64 all burst

    Kopiert eine Diskette im Laufwerk 0. Der Imagetyp ist D64. Es werden alle Blöcke gelesen. Die Übertragung der Daten erfolgt im schnellen burst Modus.

    bu

    Erstellt ein Image der Diskette im Laufwerk 0. Gelesen werden nur belegte Blöcke. Der Imagetyp ist der Standardwert für das eingestellte Laufwerk (d64 bei 1541, d71 bei 1571, d81 bei 1581, d80 bei 8050, d82 bei 8250 und SFD1001).


    res[tore] *** noch nicht implementiert

    Schreibt eine Image Datei auf eine Diskette zurück (d64, d72, d80, d81, d82). Die Image Datei wird per Y-Modem Protokoll vom PC zum Adapter übertragen.


    dumpf[ile] oder df [filenam] [drive] [slow|burst|parallel|s1|s2|warp]

    Erstellt einen Hexdump von der angegebenen Datei. Als Laufwerk kann "D0" oder "D1" angegeben werden. Für jedes Laufwerk gibt es eine Standard Einstellung für den Busverkehr, man kann aber ein bestimmtes Protokoll erzwingen [burst, parallel]. Natürlich nur wenn die Floppy das auch unterstützt.


    Beispiele:

    df "DATEI1" D1

    erstellt einen HEX Dump der Datei "DATEI1" am Laufwerk 1.


    dumpb[lock] oder db track# sector# [anz#] [drive] [slow|burst|parallel|s1|s2|warp]

    Erstellt einen Dump von einem oder mehereren Blöcken einer Diskette. Als Laufwerk kann "D0" oder "D1" angegeben werden. Für jedes Laufwerk gibt es eine Standard Einstellung für den Busverkehr, man kann aber ein bestimmtes Protokoll erzwingen [burst, parallel]. Natürlich nur wenn die Floppy das auch unterstützt.


    Beispiele:

    db 18 0

    Liest den Block auf Spur 18 Sektor 0 und zeigt die Daten als Hex Dump an.

    db 18 3 3 par

    Liest die Blöcke auf Spur 18 Sektor 3, 4, und 5 und zeigt die Daten als Hex Dump an. Gelesen werden die Daten über das parallele SpeedDos Kabel (PARALLEL WIRD ERST IMPLEMENTIERT).


    dumpn[ext] oder dn [slow|burst|parallel|s1|s2|warp]

    Der Befehl liest den Folgeblock ein und zeigt die Daten an. Der Befehl funktioniert nur nach einem Dumpblock Befehl, natürlich auch mehrfach bis die Blockfolge zu Ende ist. Wird der Befehl Dumpblock ausgeführt merkt sich die Firmware den Folgeblock. Die ersten beiden Bytes eines Blocks verweisen in der Regel auf den nächsten (Spur/Sektor).

    Beispiele:

    db 18 1
    dn
    dn
    dn


    dumpt[rack] oder dt track# [interleave#] [drive] [slow|burst|parallel|s1|s2|warp]

    Erstellt einen Dump von einer ganzen Spur einer Diskette. Man kann einen Soft Interleave erzwingen, es gibt aber Standard EInstellungen pro Floppytyp/Bustyp. Als Laufwerk kann "D0" oder "D1" angegeben werden. Für jedes Laufwerk gibt es eine Standard Einstellung für den Busverkehr, man kann aber ein bestimmtes Protokoll erzwingen [burst, parallel]. Natürlich nur wenn die Floppy das auch unterstützt. (DIESER BEFEHL WIRD GERADE IMPLEMENTIERT)


    Beispiele:

    dt 18

    Liest alle Sektoren der Spur 18 Sektor 0 und zeigt die Daten als Hex Dump an.

    dt 18 3 par

    Liest die Spur 18 mit interleave 3 im parallelen Bus Modus. Weil der Mega 644 nur 4 KB RAM hat sind nur 13 Buffer vorhanden. Deshalb ist nicht jeder Interleave Blockaufsteigend zu machen. Wenn die Buffer ausgehen dann werden die Blöcke in der falschen Reihenfolge gesendet (die Blöcke kommen nicht mehr in strickt aufsteigender Reihe nach).


    dumpm[em] oder dm

    Erstellt einen Dump vom Floppyspeicher. Als Laufwerk kann "D0" oder "D1" angegeben werden. Für jedes Laufwerk gibt es eine Standard Einstellung für den Busverkehr, man kann aber ein bestimmtes Protokoll erzwingen [burst, parallel]. Natürlich nur wenn die Floppy das auch unterstützt.


    Beispiel:

    dm $a000 200

    Erstellt einen HEX Dump des Floppy Speicher ab Adresse 0xa000 (40960) mit der Länge von 200 Bytes.


    dow[nload], load oder dl [filenam] [drive] [filetyp] [slow|burst|parallel|s1|s2|warp]

    Erstellt einen Hexdump von der angegebenen Datei. Als Laufwerk kann "D0" oder "D1" angegeben werden. Die Datei wird per Y-Modem Protokoll zum PC übertragen und direkt auf die Festplatte gespeichert. Als Dateityp kann man PRG, T64 oder P00 angeben. Für jedes Laufwerk gibt es eine Standard Einstellung für den Busverkehr, man kann aber ein bestimmtes Protokoll erzwingen [burst, parallel]. Natürlich nur wenn die Floppy das auch unterstützt.


    Beispiele:

    dl "DATEI2" D0 P00 burst

    Lädt die Datei "DATEI2" am Laufwerk 0 im P00 Format zum PC. Es wird der schnelle Burst Mode erzwungen.


    upl[oad], sa[ve] oder ul [filenam] [drive] [filetyp] [slow|burst|parallel|s1|s2|warp] *** noch nicht implementiert

    Schreibt eine Datei auf eine Diskette zurück (PRG, P00, T64). Die Datei wird per X-Modem Protokoll vom PC zum Adapter übertragen.


    listf[iletypes] oder lft

    Zeigt alle Dateitypen an (Image Dateien und Programmdateien.)


    PROTOKOLL BEFEHLE

    Ein Assembler Programmiererwird sich mit folgenden Befehlen gleich zuhause fühlen. Die Befehle spiegeln das IEEE-488 / IEC Protokoll von Commodore wieder. Die Namen sind angelehnt an das Commodore Kernel API.


    li[sten]

    Gerät zum 'Listener' erklären.


    ta[lk]

    Gerät zum 'Talker' erklären.


    unl[isten]

    Listen Modus beenden.


    unt[alk]

    Talk Modus beenden.


    op[en]

    Datei öffnen.


    cl[ose]

    Datei schliessen.


    ba[sin]

    Ein oder mehrere Bytes vom Bus lesen (vom Talker).


    bs[out]

    Ein oder mehrere Bytes zum Bus schreiben (zum Listener).


    st

    Die alt bekannte Status Variable ST. Nach Bus Operationen werden u.U. Bits in der Variable gesetzt. Durch das Lesen des Status mit diesem Befehl wird die Variable ST auf 0 zurückgesetzt.

    Bit0=Timeout beim Lesen, Bit1=Timeout beim Schreiben, Bit6=EOI: letztes Byte wurde gesendet, Bit7="device not present error".


    LOW LEVEL BEFEHLE

    set[pin] oder sp

    Der Befehl setzt einen Ausgang auf den Pegel high. Als Parameter muß ein gültiger Pin angegeben werden. Für den IEEE-488 Bus sind folgende Namen erlaubt: a[tn], d[av], e[oi], nr[fd], nd[ac].


    res[etpin] oder rp

    Der Befehl setzt einen Ausgang auf den Pegel low. Als Parameter muß ein gültiger Pin angegeben werden. Für den IEEE-488 Bus sind folgende Namen erlaubt: a[tn], d[av], e[oi], nr[fd], nd[ac].


    listp[in] oder lp

    Der Befehl listet den Zustand des aktiven Bus. Der momentane Zustand aller Signalleitungen wird angezeigt. Signalleitungen die den Pegel "high" haben werden mit Großbuchstaben und die mit dem Pegel low durch Kleinbuchstaben dargestellt.[/quote]

    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.

  • Beeindruckend! Das hast Du ja richtig was auf die Beine gestellt. Könnte man das eigentlich auch mit übersichtlichem Aufwand auf der sd2iec-Hardware zum Laufen kriegen (oder steht das vielleicht schon weiter oben im Thread - ist so viel Text...)? Da dann von mir aus auch ohne IEEE.

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    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.

  • Man könnte das schon auf der SD2IEC Hardware anpassen, wäre ziemlich simpel. Soviel ich sehe kann man den ATN auch aktiv bedienen.

    Leider hat die SD2IEC keinen Support für den SRQ, also kein Burstmode. Aber es gibt ja diese "Reserve", die aber bei den Bausätzen nicht verlötet wurde, aber prinzipell wäre das unsere SRQ Leitung.

    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.

  • Anbei die aktuelle Firmware für Atmega 644 v0.01.21:

    • Die LED ist nun steuerbar
    • Das Echo verhalten ist steuerbar
    • Wenn keine Floppy angeschlossen ist wird das Statusbit 3 gesetzt. Das Interface hängt dadurch nicht mehr.
    • Leider habe ich zur Zeit kein zweites Floppykabel, deshalb kann ich das Problem 1581 + 1541 nicht nachvollziehen. Aber ich glaube dass ich den Bug fixen konnte. Bekomme demnächst 5 Floppykabel und hole den Test nach.


    Ergänzung der Doku:

    co[nfig] obj [par1] [par2] ...

    Dient zur Konfiguration der Grundeinstellungen. Als <obj> kommen folgend Schlüsselworte zum tragen:


    config LED p1# [p2#]

    Der Parameter LED steuert die Funktion der Board LED. Wird EIN numerischer Parameter angegeben, dann wird die Gundfunktion eingestellt: 0=LED aus, 1=LED ein, 2=auto

    Werden zwei numerische Parameter angegeben kann man das Pulse/Pausen Verhältnis des Blinken der LED einstellen. Die Parameter geben hundertstel Sekunden an.

    Beispiele

    config led 1

    LED einschalten.

    co led 0

    LED ausschalten.

    co led 2

    LED blinkt. Im IEEE Modus blinkt die LED gleichmäßig (30/30). Im IEC Modus ist die LED nur kurz hell (10/90).

    co led 20 80

    LED blinkt. Die erste Zahl ist die Zeit in hundertstel Sekunden für die Hellphase. Die zweite Zahl ist die Zeit für die Dunkelphase.


    config ECHO p1#

    Der Parameter ECHO steuert die Echo Funktion der Eingabeschleife. Ein numerischer Parameter 0 schaltet das Echo aus. Alle anderen Zahlen schalten das Echo ein, dann werden alle eingegebenen Zeichen zum Terminal zurück gesendet

    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.

  • Anbei die aktuelle Firmware für Atmega 644 v0.01.22:

    • Die IEC Floppy(s) können nun per Hardware Reset zurückgesetzt werden (Befehl Res[et])
    • Es kann Maschinencode an die angeschlossene Floppy gesendet werden.


    Ergänzungen zur Doku:


    res[et]

    Wenn auf IEC gestellt ist, werden alle IEC Floppy zurückgesetzt indem die Reset Leitung für 250ms auf low gesetzt wird.

    Wenn auf IEEE gestellt ist, wird der Bus zurückgesetzt indem ein IFC gesendet wird.


    loadmc oder lmc par1 [par2] ... [parn]

    Lädt einen Maschinencode in den Floppy RAM. Als Parameter 1 kann ein Programmname oder eine Programm Startadresse eingegeben werden. Wird eine Startadresse angegeben folgen bis zu 32 Byte Werte die direkt per M-W Befehl in das Floppyram geschrieben werden.

    Vielen Dank an das OpenCBM Team für den Democode Flash und Morse, es macht Spass diesen Code in die Floppy zu laden und damit rumzuspielen.

    Beispiele:

    lmc flash
    @U3

    Lädt den OpenCBM Demo Code "Flash" in die Floppy und führt in aus. Die LED in der Floppy 1541 oder 1571 beginnt rythmisch zu blinken, dabei wird die Helligkeit der LED sanft per PWM geregelt.

    lmc morse
    @U3:SOS

    Lädt den OpenCBM Demo Code "Morse" in die Floppy und führt in aus. Die LED in der Floppy
    morst den Text "SOS" ...

    lmc $500 1 2 3

    Beschreibt die Speicherzellen in der Floppy an der Adresse 0x500, 0x501 und 0x502 mit den Werten 1, 2 und 3.

  • Mein XS1541 nimmt langsam Gestalt an: die Buchsen sind bereits an der Platine befestigt.

    Ist hier jemand mit AVRDUDE fit? Ich möchte das Board mit einem STK200-kompatiblen Schreiber flashen.
    Wie muß ich eigentlich die Fuses setzen? Oder hat jemand sogar eine komplette Kommandozeile parat?

  • Fuses sind total unproblematisch. Halt auf externen Quarz stellen und gut. Wenn du nen Bootloader rauf tust dann halt im obersten Bereich 2K reservieren.

    Hast du alle dre Interfaces vorgesehen? IEEE, IEC und SpeedDos?

    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.

  • BastetFurry

    Kannst du was mit GCR Nettodatein einer 1541/1571 anfangen? Wie man GCR dekodiert ist gut dokumentiert und es gibt C Source dafür. Wenn ja implementiere ich ein Flag dass du die Daten GCR dekodiert bekommst.


    Man könnte daraus einfach g64 images basteln weil man dadurch jede Information hat. Weil die Floppy nix dekodieren muss. Sogar D64 mit error info und auch d64 ohne error info wären interessant, weil die GCR Daten sauschnell gelesen werden können (ca. 400 ms pro track).

    Natürlich kann ich auch die GCR Dekodierung übernehmen, es geht halt Information verloren und etwas Zeit.

    Das Problem bei der Track Leserei ist im Moment der Mangel an RAM bei dem 644er. Wenn ich nicht auf die Reihenfolge der Sektoren achten muss funktioniert das viel einfacher und schneller.


    Am PC kann man das auf zwei Arten lösen:

    • Man könnte eine Anzahl Buffer (Sektoren Anzahl pro Track, bei 1541 21) reservieren wo man die Sektore Daten einliest. Das Schreiben des Imagefile könnte dann rein sequentiell erfolgen weil man die Buffer dann in aufsteigender Sektoren Folge auslesen kann.
    • Ohne Buffer gehts es auch am PC, weil man kann ja den Filepointer setzen auf die Stelle wo der Sektor hin gehört.

    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.

  • Hast du alle dre Interfaces vorgesehen? IEEE, IEC und SpeedDos?

    Jein. Es sind zwar schon Buchsen für alle drei Interfaces da, aber die sind noch nicht angeschlossen. Das hole ich alsbald nach. SpeedDOS bzw. PB0-7 sollen dann an eine 25-polige Sub-D-Buchse an Pin 2-9, um sie einerseits für SpeedDOS verfügbar zu haben, andererseits aber doch noch irgendwann einmal einen Drucker (der dann noch ACK bräuchte) daran zu hängen - oder aber sogar über diese Buchse das Ding mit AVRDUDE neu zu flashen.

    Ich habe gesehen, daß man AVRDUDE die Belegung von Parallel-Port-Programmieren mitteilen kann, dann muß ich dem nur noch sagen, wo MOSI, MISO etc. liegen, da die zwar an PB5-7 und somit an der Sub-D-Buchse liegen, aber mit anderer Belegung als das STK200.

    Bis jetzt steht nur die Spannungsversorgung mit dem 7805, der Atmel und der MAX232 - das sollte ausreichen um das Ding erst mal zu flashen und mit ihm über die serielle zu sprechen.

    Fuses sind total unproblematisch. Halt auf externen Quarz stellen und gut. Wenn du nen Bootloader rauf tust dann halt im obersten Bereich 2K reservieren.

    Naja, so ganz unproblematisch ist das für mich alles nicht.

    Bootloader? Was kann ich damit nettes machen? Brauche ich einen? Sollte ich einen brauchen?

    Um es vorneweg zu nehmen: vom XS1541 habe ich noch nichts gelesen. Es hätte vor meinem Test sicher ungemein geholfen, RxD und TxD vom Atmel auch mit dem MAX232 zu verbinden... das mache ich dann morgen... stöhn!

    Ein paar Fragen habe ich aber doch noch:

    Die Belegung geht von einem 1:1-Kabel aus? Also KEIN Null-Modem-Kabel?
    Die Baudrate ist 38tausendirgendwas 8N1 ?

    Zu den Fuses:

    Ich habe jetzt...

    - Ext. Crystal Osc.; Frequency 8.0- MHz; Start-up time: 16K CK + 65ms CKSEL=1111 SUT=11
    - Preserve EEPROM memory through the Chip Erase cycle EESAVE=0
    - Serial program downloading (SPI) enabled SPIEN=0
    - Brown-out detection level at VCC=4.3V BODLEVEL=100

    Alle anderen Fuses sind nicht programmiert, d.h. der Takt wird nicht an PB1 ausgegeben, der interne Takt wird nicht durch 8 geteilt, der Boot-Reset-Vektor ist gesperrt, der Watchdog ist nicht immer an, das JTAG-Interface ist gesperrt, das on-chip-debug ist gesperrt.

    Alles richtig? Auch, daß der Takt NICHT durch 8 geteilt wird?

    Als Werte macht das dann lfuse 0xff, hfuse 0xd1, efuse 0xfc