Hello, Guest the thread was viewed13k times and contains 36 replies

last post from Shadowolf at the

sd2iec 0.1

    Hi!


    So, nur noch 24 Fixmes und Laden/Speichern scheint zu funktionieren - Zeit für ein Release. =)


    Sicherlich erinnert sich irgendjemand an mein Posting in dem ich anmerkte, dass man am besten fast den kompletten Code von MMC2IEC wegwerfen und alles neu schreiben sollte. Ich habe das dann einfach mal gemacht - das Ergebnis ist sd2iec, welches mit MMC2IEC eigentlich nur einen Teil der config.h sowie die SD-Zugriffsroutinen gemeinsam hat.


    Vorteile:

    • Hält sich deutlich besser ans IEC-Protokoll weil ich mich ziemlich dicht ans 1571-Rom gehalten habe. Beispielsweise funktionieren die Directory-Lister von Jiffy+DolphinDOS beide einwandfrei.
    • Der Aufbau des Directories das an den C64 geschickt wird ist identisch zu dem was die Commodore-Floppys erzeugen. Insbesondere werden die Dateigrössen (aber nicht der freie Platz) auf 254-Byte-Blöcke umgerechnet.
    • Ich finde den Code lesbarer und besser erweiterbar ;-)


    Nachteile:

    • Viele Features von MMC2IEC fehlen, darunter D64/T64/M2I-Unterstützung und Unterverzeichnisse.
    • Es gibt zwar eine Auswertung für den Kommandokanal, die kann aber bisher nur UJ (Reset), M (wird als Hexdump auf die serielle Schnittstelle geschoben, Bonusfeature für Shadowwolf ;-) ), S: für einzelne Dateien und E<num> um die Fehlermeldung mit Nummer <num> zu erzeugen (praktisch zum Testen!).
    • Die Karte wird nur beim Reset initialisiert, daher geht auch kein Kartenwechsel im Betrieb.
    • Kaum getestet, insbesondere nicht am DTV und nur mit einem Quarz als Taktgeber.
    • Schon jetzt fast so grosser Code wie MMC2IEC
    • Kann unter ungünstigen Umständen in einen Zustand geraten in dem ein Controllerreset der einfachste Ausweg ist. MMC2IEC arbeitet intensiv mit Timeouts, mein Code nicht. Nachrüsten ist auch nicht ganz einfach, manche Zustände dürfen wirklich beliebig lange dauern.
    • Keine der diversen Ideen wie man MMC2IEC erweitern könnte wurden umgesetzt.
    • Die Fehlerbehandlung ist teilweise nichtexistent oder im Vergleich zur 1571 falsch. Die Aktualisierungen des Fehlerkanals müssen nochmal genau überprüft werden, evtl. fehlen diese an einigen Stellen oder werden doppelt ausgeführt (Symptome: 73 statt 00 oder 00 statt Fehler)
    • Wildcards in Dateinamen fehlen noch komplett.
    • Erwähnte ich schon die >20 FIXME-Kommentare?
    • bestimmt noch mehr was mir gerade nicht einfällt...


    Aber um auch mal was Positives nennen zu können: Es ist keinerlei Fastloader implementiert (Jiffy-Erkennung ist drin, aber inaktiv - bastelt jemand Jiffy-Byte-Transfer-Routinen?), trotzdem meldet der 64'er Speed-Test schon Faktor 2.27 für SAVE und 1.61 für LOAD. =)


    GIT-Repository, Sourcen und Binaries unter http://snowcat.de/mmc2iec/
    Webinterface für das GIT-Repository unter http://snowcat.de/cgi-bin/gitweb.cgi/sd2iec.git
    GIT für Windows existiert, das ist also keine Ausrede um mich zur Nutzung von svn zu bringen: http://git.or.cz/gitwiki/WindowsInstall


    Bugfixes/Erweiterungen bitte als Patch oder als git pull-fähige URL an die Mailadresse in den Sourcen.

    Quote

    Originally posted by AntaBaka
    Aber warum ausgerechnet kompatibel zur 1571?


    Weil ich nur das Rom-Listing der 1571 in Buchform im Regal stehen habe (Data Becker, 1571&1570: Das grosse Floppybuch), aber nicht das der 1541.


    AAY1541 ist etwas spärlich kommentiert (und gerne mal falsch), bei der PDF-Version von Die Floppy 1541 ist es recht schwer mehrere Seiten gleichzeitig offenzuhalten.


    Ausserdem wäre es nett irgendwann mal Burst-Support einzubauen...

    Quote

    Originally posted by Unseen
    Weil ich nur das Rom-Listing der 1571 in Buchform im Regal stehen habe (Data Becker, 1571&1570: Das grosse Floppybuch), aber nicht das der 1541.


    Das ROM-Listing hätte ich da...

    Quote

    Originally posted by jackdaniels
    reicht denn der platz im MMC2IEC aus falls der code weiter wächst?


    Ja, im Augenblick braucht der Code nur etwas mehr als die Hälfte des Speichers des Controllers - und bisher habe ich mir noch nicht mal die Mühe gemacht die Codegrösse zu optimieren. Der Ram-Verbrauch sollte hoffentlich stabil bleiben, wenn nicht müsst ihr eben eure mega32 auslöten und durch mega644 ersetzen. ;-)


    Quote

    Originally posted by AntaBaka
    Das ROM-Listing hätte ich da...


    Ich kann gerne alle Vorkommen von 1571 im Code durch 1541 ersetzen wenn du das für hilfreich hälst. ;-) Von der Funktion her sollte es keinen Unterschied machen ob ich nun die 1571 oder 1541 als Vorlage verwende.

    Quote

    Originally posted by Unseen
    Ich kann gerne alle Vorkommen von 1571 im Code durch 1541 ersetzen wenn du das für hilfreich hälst. ;-) Von der Funktion her sollte es keinen Unterschied machen ob ich nun die 1571 oder 1541 als Vorlage verwende.


    Wenn's keinen Unterschied macht *schulterzuck*...
    Trotzdem mal angehängt.


    Ich hätte auch noch das INSIDE COMMODORE DOS Buch, aber das sind knapp 40MB PDF...

    Erst einmal vielen Dank für deine Arbeit.


    Zu den Unterverzeichnissen und D64-Images hätte ich eine Frage, wie du die implementieren möchtest. Das MMC2IEC geht da ja einen etwas anderen Weg als die anderen MMC/HD-Lösungen. Wenn ich richtig informiert bin, dann machen die anderen einen Verzeichniswechsel mit Open und dann einem selbst eingeführten CD-Befehl, während das MMC2IEC ja einfach den LOAD-Befehl verwendet (was natürlich weniger Tipparbeit bedeutet, wenn man ohne Filebrowser arbeitet). Wenn ich ALeX richtig verstanden habe, macht ihm das bei den D64-Dateien Kopfschmerzen, weil er dadurch in unserem Filebrowser nicht wirklich lesend auf das D64-Image zugreifen kann, um es z.B. auf eine echte Disk zu kopieren. Sobald er es lädt, springt er ins D64-Verzeichnis. Könnte man sich eine Lösung überlegen, wie man das Problem in den Griff bekommen könnte?

    Quote

    Originally posted by Retrofan
    Wenn ich richtig informiert bin, dann machen die anderen einen Verzeichniswechsel mit Open und dann einem selbst eingeführten CD-Befehl, während das MMC2IEC ja einfach den LOAD-Befehl verwendet (was natürlich weniger Tipparbeit bedeutet, wenn man ohne Filebrowser arbeitet).


    Ich plante in dieser Hinsicht komplett MMC2IEC-inkompatibel zu sein und Unterverzeichnisse mit der gleichen Syntax wie die CMD-Laufwerke anzusprechen, d.h. (vereinfacht) CD:name zum reinwechseln und CD:_ (Linkspfeil) um eine Ebene hochzuwechseln - falls ich in tff noch das Konzept eines aktuellen Verzeichnisses einbasteln kann wird CD:.. für letzteres automatisch auch funktionieren.


    Für Leute ohne Dos-Wedge oder ähnliche Hilfen: Sorry, aber der Hack via LOAD in MMC2IEC ist einfach nur eklig.


    D64-Images (und falls irgendwann mal implementiert M2I oder S2I-Dateien) würde ich ebenfalls via CD "mountbar" machen wollen, dann löst sich auch gleich das Problem die als normale Datei öffnen zu wollen.


    Man könnte übrigens in MMC2IEC noch ein wenig rumbasteln, damit der Verzeichniswechsel nur ausgeführt wird wenn auf dem Bus Sekundäradresse 0 übermittelt wird, d.h. wenn die Datei nicht mit LOAD angesprochen wird könnte man sie normal lesen. Aber lohnt sich der Aufwand noch?


    Wie markieren eigentlich die CMD-Laufwerke in ihrer Directory-Ausgabe eine Zeile als Unterverzeichnis? Ich habe vorläufig "DIR" geraten.

    Quote

    Original von Unseen
    D64-Images (und falls irgendwann mal implementiert M2I oder S2I-Dateien) würde ich ebenfalls via CD "mountbar" machen wollen, dann löst sich auch gleich das Problem die als normale Datei öffnen zu wollen.


    Super! :D



    Oliver W.

    Quote

    Originally posted by sauhund
    DIR ist richtig...dafür gibts sogar ein standard wert im programtyp in der direktory (steht in den 1581 docs ...)


    Die 1581 kann doch meines Wissens nur CBM (Typ 5) für ihre Unterpartitionen?

    Hallo. Super. Ich hätte noch eine Bitte.


    1.
    könnte man eine #ifdef - #else - #endif Klammer in config.h (?) so setzten, das sich eine HEX Datei sowohl für shadowolfs alsauch für Lars original Variante des Boardsaufbaus erzeugen läßt? Soweit ich weiß haben sich ja nur die Ports geändert..


    2.
    Dann auch eine HEX-Datei zum testen für Lars Aufbau zur Verfügung zu stellen.. dann könnte ich auch als Betatester fungieren..


    Danke, Peter

    Okay, auf geht's. :hammer:


    Ich habe mir für die serielle Verbindung einen USB-seriell Wandler an das MMC2IEC gehängt, die Platine habe ich vor ein paar Monaten mal für den Einsatz in der Firma gebaut.
    Falls es jemanden interessiert, dass ist ein FT232RL und ausser dem IC, der USB-Dose und den drei Kondensatoren wird nichts weiter benötigt.


    So, Feuer, sd2iec.bin auf die SD-Karte, Hyper-Terminal anwerfen, DTV einschalten.


    Bootloader bootloaded und dann kommt das:


    ---
    In iec_mainloop listening on 08
    ---


    Prima, läuft schon mal. :)


    Bei 'LOAD"$",8' kommt dann allerdings das hier:


    ---
    A28
    Af0
    LEA3f
    A48
    A60
    T++A5f
    A28
    Ae0
    CA3f
    ---


    Häh?


    Das Directory wird allerdings ohne Probleme gelesen.
    Wobei, verwirrt mich ein wenig, dass die Grössen jetzt wieder in Blöcken sind und
    nicht mehr in KB.
    Und "7608 BLOCKS FREE" sind für meine 128 MB Karte mit 118 MB frei ein wenig sehr tief gestapelt. ;)


    Fehler-Kanal auslesen:


    ---
    A48
    A6f
    TA5f
    A28
    Aef
    CA3f
    ---


    Scheint aber nicht zu funktionieren, mein BASIC Programm gibt nichts aus.


    Aber Print#1,"M-W" und "M-W" nach Open gehen schon mal. :-)


    ---
    M-W 77 00 02 28 48 0d
    ---


    Wobei das "0d" am Ende habe ich nicht gesendet!?


    OPEN 1,8,15,"M-WXXXXX"
    CLOSE 1


    ---
    A28
    Aff
    LEA3f
    M-W 58 58 58 58 58
    A28
    Aef
    CA3f
    ---


    Sieht auch sehr gut aus, diesmal aber kein "0d".

    Da ich mit W$N und AVR-Studio arbeite habe ich erstmal eine Projekt-Datei
    für AVR-Studio erzeugt mit der sich SD2IEC im AVR-Studio kompilieren lässt.


    Interessant finde ich nur, dass ich nicht die exakt gleiche binär-Datei erzeugen kann,
    wie sie zum Download zur Verfügung steht.


    Die CRC-Prüfsumme für den Bootloader weicht ab.
    Das passiert auch, wenn ich einfach "make" benutze.


    ---
    D:\>avr-gcc -v
    ...
    gcc version 4.1.2 (WinAVR 20070525)
    ---


    Die von mir aus der .hex erzeugten .bin sind sowieso anders, der Converter den ich benutze füllt leeren Platz nicht mit "0" sondern mit "f".


    Ist jetzt vielleicht nicht sooo wichtig.


    Öh, ja, meine Debugging-Ausgaben sind etwas kryptisch und protokollieren fast nur den seriellen Bus. ^^; Ist ein Überbleibsel aus der Zeit als ich noch keinen Sendepuffer für die RS232 verwendet habe, da reichte das Timing nicht für mehr.


    0x28 unter ATN, 0xf0 unter ATN, Listen-Routine aufgerufen, EOI empfangen, 0x3f/48/60 unter ATN, Talk-Routine aufgerufen, fat_dir_refill aufgerufen (+), 0x5f/28/e0 unter ATN, Byte unter ATN erwartet aber ATN zurückgenommen (C), 0x3f unter ATN.


    Als iec_getc und iec_putc noch bei jedem Byte ein Zeichen ausgegeben haben war das ganze geringfügig hilfreicher als jetzt weil der Datentransfer besser zu erkennen war. Eines der beiden uart_putc ist sogar noch im Code, nur auskommentiert.


    Quote

    Und "7608 BLOCKS FREE" sind für meine 128 MB Karte mit 118 MB frei ein wenig sehr tief gestapelt. ;)


    Ja, da am Ende stehen freie Cluster. Sollte ich evtl. auch mal umrechnen lassen, allerdings überschreitet man bei SDHC-Karten (weiterhin ungetestet) schonmal die Grenzen von 32-Bit-Variablen. Andererseits^2 ist das egal weil sowieso nur ein 16-Bit-Wert übertragen werden kann... *idee notier*


    Quote

    Fehler-Kanal auslesen:
    Scheint aber nicht zu funktionieren, mein BASIC Programm gibt nichts aus.


    Irgendwas wurde übertragen, da ist ein T in der Liste. Ein spontaner Test mit

    Code
    1. 10 open 1,8,15
    2. 20 input#1,a$,b$,c$,d$
    3. 30 print a$,b$,c$,d$
    4. 40 close 1


    funktioniert jedenfalls.


    Quote

    ---
    M-W 77 00 02 28 48 0d
    ---
    Wobei das "0d" am Ende habe ich nicht gesendet!?


    Semikolon am Ende des print# vergessen?


    Quote

    OPEN 1,8,15,"M-WXXXXX"


    Sieht auch sehr gut aus, diesmal aber kein "0d".


    Natürlich nicht, ist ja OPEN und nicht PRINT.


    Die AVR-Studio-Datei kippe ich mal einfach in mein Sourcenverzeichnis in der Hoffnung, dass sie längere Zeit gültig bleibt...


    Quote

    Die CRC-Prüfsumme für den Bootloader weicht ab.
    Das passiert auch, wenn ich einfach "make" benutze.


    Meinst du damit das dein Compilat nicht 100%ig identisch ist zu meinem oder das eine falsche CRC in die Datei geschrieben wird?

    Schade, Edit-Zeitlimit knapp verpasst.


    Quote

    Originally posted by PeterSieg
    könnte man eine #ifdef - #else - #endif Klammer in config.h (?) so setzten, das sich eine HEX Datei sowohl für shadowolfs alsauch für Lars original Variante des Boardsaufbaus erzeugen läßt? Soweit ich weiß haben sich ja nur die Ports geändert..


    Ist drin.


    Quote

    Dann auch eine HEX-Datei zum testen für Lars Aufbau zur Verfügung zu stellen.. dann könnte ich auch als Betatester fungieren..


    Ist für die 0.1 manuell nachgereicht, für die 0.2 sollte ich mir wohl ein Releasescript basteln das das alles automatisiert.