Hello, Guest the thread was called72k times and contains 273 replays

last post from Unseen at the

arm2iec [Neue Hardware]

  • Wenn es der Rechner nicht ist.
    Wenn es der ARM nicht ist.
    Wenn es die Treiber nicht sind.
    Was ist bei allen Tests/Versuchen gleich? Vielleicht ist das die Ursache? (Kabel/Stecker/Magnetfeld/Stöhrstrahlung/Spannungsschwankungen)

  • Hallo Alex89, bist du zufällig in Rhein-Main? Wenn ja, komm mal bei mir vorbei, ich habe einen lauffähigen Arm2IEC, wir können dann ja mal vergleichen. Außerdem bitte ein paar Chips, u.a. einen PLA mitbringen, vielleicht bekommen wir so ja meinen 2. SX-64 wieder zum Laufen. Siehe auch PN.

  • An meinem "32-Bit Windows XP"-Rechner ließ sich das arm2iec auch nicht flashen. Gleicher Fehler "failed to autobaud".
    Am "64-Bit Windows 7"-Rechner hingegen keine Probleme.

  • Der MCP 2200 "Treiber" ist ja nur eine INF-Datei, so dass der mit Windows ausgelieferte Treiber verwendet wird. Vermutlich unterscheiden die sich je nach Servicepack.


    @Edit: Nö, auf W7 und XP SP2 wird auf meinen Rechnern der Treiber in Version 5.1.2600.3 vom 28.08.2012 verwendet. Allerdings hat der XP-Rechner noch einen USB 1.1 Port und es sind zusätzlich Treiber für andere USB-COM-Wandler installiert, z.B. von Prolific. Vielleicht liegt's auch daran.

  • Das Rätsel mit den Windows XP-Problemen ist gelöst.
    Der Windows Treiber "usbser.sys" in alten XP-Versionen ist fehlerhaft. Einfach http://support.microsoft.com/kb/935892 installieren und dann geht's.
    Hinweise dazu finden sich in README.TXT in MCP2200 Windows Driver.zip

  • Der Grund warum ich nach dem Betriebssystem gefragt hatte ist, dass ich mit Win7 64 Bit selber Probleme mit FlashMagic im Zusammenspiel mit dem 2378STK von Olimex habe. Irgend etwas ist da jetzt so, dass ich seriell nicht mehr flashen kann, ich weiss nur noch nicht was das ist... Da gibts auch diesen autobaud Fehler. Aber der kommt eigentlich so ziemlich immer wenn es nicht geht.

  • Hallo Unseen, ich habe einen Funktionswerweiterungswunsch, den du vielleicht erfüllen kannst?


    Und zwar hätte ich gerne, dass das ARM2IEC auf Kommando zwei Floppys emulieren kann. Ich denke an sowas:


    Ich sende dem arm2iec einen neu zu implementierenden Befehl, der vielleicht NDxx heißt (NewDrive), wobei xx eine Laufwerksnummer ist. Zum Beispiel (Dolphin-Dos-Syntax)


    @ND10


    Daraufhin ist dann das Arm2IEC unter der Adresse 9 (Dipschaltervoreinstellung) und 10 ansprechbar, und man kann unter den beiden Adressen verschiedene Images oder Verzeichnisse ansprechen. Falls man mit beiden Adressen in das selbe Diskimage oder Verzeichnis wechselt, müssten aber beide Laufwerke sich wie schreibgeschützt verhalten, damit man keinen Unsinn machen kann


    Die Idee dahinter ist, dass man so am C-64 einfach Dateien aus Diskimages oder Verzeichnissen wo anders auf der SD-Karte hinkopieren kann.


    Was denkst du, wäre das umsetzbar?

  • Die Idee dahinter ist, dass man so am C-64 einfach Dateien aus Diskimages oder Verzeichnissen wo anders auf der SD-Karte hinkopieren kann.


    Fürs Kopieren gibts doch schon das Copy-Kommando, dafür müssen die Daten nicht mal über den seriellen Bus. Allerdings ist Kopieren zwischen Diskimages sowie zwischen Karte und Diskimage nicht möglich, wenn Quelle und Ziel auf der gleichen Partition liegen.


    Quote

    Was denkst du, wäre das umsetzbar?


    Klar. Man muss nur fast alle internen Strukturen umbauen und könnte danach den ATmega644-Support komplett streichen.

  • Na gut, schade. Andererseits, ja warum denn eigentlich nicht, das ARM2IEC ist viel leistungsfähiger, man müsste die erweiterte Hardware doch eigentlich auch richtig nutzen und da ne Luxusversion vom SD2IEC drau0 machen... (So das alle den Vorteil sehen und auch aufsteigen wollen... :P )


    Aber was anderes, jetzt habe ich zwei echte Fehler gefunden, beim zweiten weiß ich aber noch nicht woran es liegen kann.


    Der erste Fehler ist, wenn man von einer echten 1541 Dateien kopiert, wo im Dateinamen ein Forward-Slash "/" drin ist, die lassen sich nicht kopieren. Doppelpunkt ":" dürfte da übrigens auch Probleme machen, und Sterne "*" auch, oder "." bzw ".." als Dateiname, weil das Zieldateisystem das FAT32 auf der SD-Karte ist und diese Zeichen nicht Bestandteil eines Dateinamen sein dürfen. Wäre es möglich, diese irgendwie zu wandeln, wenn nicht in ein Image kopiert wird? Sonst kann man solche Dateien nicht auf eine SD übertragen. (Die Dateinamen "CON", "PRN", "LPTx", "NUL" sollten auch abgefangen werden und in was unbefänglicheres umbenannt werden!)


    Außerdem wäre es schön, wenn ARM2IEC Dateien, die man von echter Floppy ins FAT32 Dateisystem kopiert, automatisch richtige Dateiendungen (.prg, .seq .rel) geben würde.


    Das zweite Problem ist, ich habe wie aus den beiden anderen Problembeschreibungen zu sehen, diverse Dateien auf SD rüber kopiert. Jetzt habe ich das Problem, dass ich am PC auf der SD zwar diese Dateien im Explorer zwar sehen kann, sie aber nicht öffnen oder kopieren kann, der Explorer behauptet immer, die Dateien würden nicht existieren. Auch von der Eingabeaufforderung kann ich diese Dateien nicht kopieren oder so. Manche funktionieren aber auch. Jetzt weiß ich aber nicht, ob dieses Problem aus der arm2iec-Firmware resultiert, oder aus DraCopy (v1.0D).

  • Andererseits, ja warum denn eigentlich nicht, das ARM2IEC ist viel leistungsfähiger, man müsste die erweiterte Hardware doch eigentlich auch richtig nutzen und da ne Luxusversion vom SD2IEC drau0 machen... (So das alle den Vorteil sehen und auch aufsteigen wollen... :P )


    Man macht sich bei Leuten total beliebt wenn man ihnen sagt, dass die von ihnen verwendete Hardware nicht mehr unterstützt wird weil Features hinzugekommen sind, die sie eh nicht brauchen.


    Quote

    Der erste Fehler ist, wenn man von einer echten 1541 Dateien kopiert, wo im Dateinamen ein Forward-Slash "/" drin ist, die lassen sich nicht kopieren.


    In ein Diskimage oder in eine Datei im FAT-Filesystem? Letzteres ist zu erwarten, da / dort kein erlaubtes Zeichen ist. Stell mit @XE2 aufs PC64-Dateiformat um, dann gehts.


    Quote

    Doppelpunkt ":" dürfte da übrigens auch Probleme machen


    Sollte nicht, der wird von Commodore-Laufwerken auch nicht in Dateinamen akzeptiert.


    Quote

    und Sterne "*" auch


    Da bin ich mir gerade nicht sicher ob eine 1541 den beim Speichern annehmen würde.


    Quote

    oder "." bzw ".." als Dateiname


    Die sind im PC64-Format grundsätzlich darstellbar, aber hier könnte es an der Erkennung doppelter Dateinamen beim Speichern haken.


    Quote

    Wäre es möglich, diese irgendwie zu wandeln, wenn nicht in ein Image kopiert wird?


    Kann man doch schon, man muss sd2iec nur sagen, dass es die Dateien mit PC64-Header speichern soll - darin steht dann der ungewandelte PETSCII-Dateiname und das Format ist schon ziemlich lange etabliert.


    Quote

    (Die Dateinamen "CON", "PRN", "LPTx", "NUL" sollten auch abgefangen werden und in was unbefänglicheres umbenannt werden!)


    Dafür sehe ich keinen Bedarf, das sind erlaubte Dateinamen auf einem FAT-Dateisystem. Auch in Microsofts Spezifikation zum Aufbau von FAT32 tauchen diese nicht als verbotene Dateinamen auf.


    Quote

    Außerdem wäre es schön, wenn ARM2IEC Dateien, die man von echter Floppy ins FAT32 Dateisystem kopiert, automatisch richtige Dateiendungen (.prg, .seq .rel) geben würde.


    Zum einen finde ich das fürchtbar lästig, zum anderen stören sich einige Programme möglicherweise daran, wenn die gerade gespeicherte Datei nicht unter dem gerade verwendeten Namen erreichbar ist weil das Laufwerk selbstständig ein ".prg" angehängt hat. Aber für Leute die das unbedingt wollen gibts auch dafür einen mit @XE einstellbaren Modus.


    Quote

    Das zweite Problem ist, ich habe wie aus den beiden anderen Problembeschreibungen zu sehen, diverse Dateien auf SD rüber kopiert. Jetzt habe ich das Problem, dass ich am PC auf der SD zwar diese Dateien im Explorer zwar sehen kann, sie aber nicht öffnen oder kopieren kann, der Explorer behauptet immer, die Dateien würden nicht existieren. Auch von der Eingabeaufforderung kann ich diese Dateien nicht kopieren oder so. Manche funktionieren aber auch. Jetzt weiß ich aber nicht, ob dieses Problem aus der arm2iec-Firmware resultiert, oder aus DraCopy (v1.0D).


    Das ignoriere ich einfach mal, so lange keine brauchbare Fehlerbeschreibung vorliegt.

  • Was brauchst du denn für eine Fehlerbeschreibung?


    Das erste Bild zeigt, was passiert, wenn ich die Datei kernelloader von e: nach c: kopieren will. Das andere sind die Eigenschaften der Datei. Und wie du siehst, gibts auf e: einige Dateien mit der Endung .prg, ich habe auf dieses Verzeichnis den Befehl "ren * *.prg" angewendet, es wurden nur einige Dateien umbenannt, die anderen zeigen genau diesen Fehler.


    Reicht das erstmal?


    Zusatzfrage, wenn ich auf @XE2 umschalte, wird das im Flash gespeichert, oder muss ich jedes Mal nach dem Einschalten des arm2iec erneut umstellen?

  • Für Mutige: Aus dem Webserver liegt jetzt ein SD-Bootloader für die a2i-Hardware mit dem Namen "lpcboot". Funktioniert im Prinzip genauso wie der bekannte Bootloader aus der AVR-Version - auf der SD-Karte wird nach einer Datei mit der richtigen Grösse, Signatur und Version gesucht und die ggfs. ins Flash geschrieben. Nur sehr minimal getestet, die Mindest-Firmwareversion die auf der SD-Karte als Update erkannt wird ist 1.0.0alpha0-52 von der Nightly-Build-Seite. Natürlich können die dortigen Dateien weiterhin mit yalf oder FlashMagic direkt in den Chip geschrieben werden falls jemand den Bootloader nicht verwenden möchte (der wird dabei überschrieben).

  • Wo seh ich jetzt ob das Flashen des lpcboot geklappt hat? Gibt es einen Status?
    Ich hatte versucht seriell per Konsole zuzugreifen, aber irgendwie bekomme ich keine Verbindung, obwohl das Flashen des Bootloader per FlashMagic ueber den Com-Port (bei mir Com 6) geklappt hat.
    Alle anderen Tools die auch noch auf Com 6 zugreifen koennten, habe ich geschlossen.

  • Wo seh ich jetzt ob das Flashen des lpcboot geklappt hat?


    Das sollte dir eigentlich dein Flashtool sagen.


    Quote

    Gibt es einen Status?


    Der Bootloader funktioniert genauso wie der auf dem AVR: Die rote LED wird eingeschaltet, auf der Karte wird nach einem Update gesucht (grüne LED leuchtet konstant). Wenn ein akzeptables solches gefunden wird flackert die grüne LED während des Flashens, wenn nicht wird versucht das schon im Flash stehende Programm zu starten. Falls das Programm im Flash ungültig ist blinkt die rote LED einige male und das ganze geht von vorne los.


    Steht übrigens auch im README.


    Quote

    Ich hatte versucht seriell per Konsole zuzugreifen, aber irgendwie bekomme ich keine Verbindung


    lpcboot fasst die serielle Schnittstelle nicht an.