Hallo Besucher, der Thread wurde 8,4k mal aufgerufen und enthält 20 Antworten

letzter Beitrag von Shadowolf am

sd2iec 0.4.1

    Hi!


    Nur ein kleines Bugfix-Release:

    • Es werden keine Nullbytes mehr in den FAT-Namen in M2I-Dateien geschrieben (sd2iec stört sich nicht daran, keine Ahnung ob MMC2IEC es mag)
    • Kleinere (geratene) Änderung im Bustiming beim Senden - alx hatte beim Lesen der Startadresse in FIBR Probleme die darauf zurückzuführen waren, dass sd2iec das CLOSE nicht mitbekommen hat. Es sieht sehr danach aus als wäre sd2iec an dem Punkt zu schnell gewesen, aber eine exakte Rechnung anhand des Floppy-Romlistings fehlt noch.


    Jiffy-Laderoutinen fehlen weiterhin, ich hatte bisher noch keine Zeit um mich darum zu kümmern.


    Wie üblich: http://snowcat.de/mmc2iec/

    So hat lange gedauert.. aber habe jetzt die 0.4.1 lp Version mal auf meinen Lochrasteraufbau (LarsP) losgelassen..
    sieht nicht so gut aus! Grüne LED leuchtet dauernt.. und load"$",8 gibt device not present..
    Davor hatte ich die 0.8 standard mmc2iec firmware drauf und alles hat bestens funktioniert..


    Also wieder zurück das ganze und gut ist..


    Peter

    Zitat von PeterSieg

    So hat lange gedauert.. aber habe jetzt die 0.4.1 lp Version mal auf meinen Lochrasteraufbau (LarsP) losgelassen..
    sieht nicht so gut aus! Grüne LED leuchtet dauernt.. und load"$",8 gibt device not present..


    Ups, das hätte ich jetzt fast vergessen.


    Die dauerleuchtende LED lag an einer verdrehten Ansteuerung (bei LarsP sind die LEDs genau andersherum verdrahtet wie bei Shadowwolf), Fehler beim Zugriff lagen an uraltem Debug-Code im IEC-Bereich der genau die bei LarsP für den Bus verwendeten Leitungen fest auf Low zieht. Damit hängt auch ATN zwangsweise auf Low und die Datenübertragung kann nicht funktionieren.


    Allerdings lieferte letzteres Problem bei mir kein DNP sondern nur einen Hänger beim Zugriff?


    Sicherheitshalber gibts jetzt erstmal die 0.4.2 an der üblichen Stelle, bei der nur diese beiden Bugs beseitigt sind.


    0.5 muss noch warten bis auch Schreiben und Blockzugriffe auf D64 funktionieren. =)

    Hallo Unseen.. Danke ersteinmal für den Bugfix.. habe 0.4.2 heruntergeladen und geflasht. Läuft noch mit internem 8MHz, obwohl ich schon einen 8MHz Quartz bestückt habe..


    Zuerst die gute Nachricht. Es läuft!! Grüne LED nur kurz an und load"$",8 liefert ein Directory. laden eines prg geht ebenfalls!


    Was mir aufgefallen ist: Lange Dateinamen werden mit (pi) Symbol abgekürzt. Ist bei mmc2iec auch so.. aber im Dir-Listing einfach load
    davor (und zusätzliches PRG weglöschen..) bringt bei sd2iec 'File not found'.. bei mmc2iec geht das!? Wenn man mit Wildcards * arbeitet, gehts auch bei sd2iec..


    M2I: Das geht anscheinend bei sd2iec gar nicht..? load der *m2i Datei geht.. aber es ist noch das vorherige Dir-Listing im Speicher..?
    Habe es mit summer games und last ninja probiert.. beide laufen mit mmc2iec..


    Generell finde ich das Dir-Listing bei mmc2iec praktischer, weil man sich das weglöschen des PRG sparen kann.. ist aber nur ne Kleinigkeit.. Auch das Verzeichniswechseln über load finde ich praktischer.. aber dazu hattest du ja schon einiges gesagt..


    Schöne Festtage,
    Peter

    Zitat von PeterSieg

    Was mir aufgefallen ist: Lange Dateinamen werden mit (pi) Symbol abgekürzt. Ist bei mmc2iec auch so.. aber im Dir-Listing einfach load
    davor (und zusätzliches PRG weglöschen..) bringt bei sd2iec 'File not found'.. bei mmc2iec geht das!? Wenn man mit Wildcards * arbeitet, gehts auch bei sd2iec..


    Oh, Mift. Das hat früher mal funktioniert, aber das geht wahrscheinlich seit der Unterstützung von Wildcards nicht mehr - einer dieser blöden Sonderfälle deren Test man schnell vergisst. Wird in der nächsten Version gefixt sein. (Woran liegts? Die Fat-Routinen codieren zwar alle das Pi in eine Tilde um, aber nicht umgekehrt. Dadurch wird keine zum Namen passende Datei gefunden, denn die Vergleichsroutinen werden immer aufgerufen weil das weniger Code produziert als erst auf */? zu testen.)


    Zitat

    M2I: Das geht anscheinend bei sd2iec gar nicht..? load der *m2i Datei geht.. aber es ist noch das vorherige Dir-Listing im Speicher..?
    Habe es mit summer games und last ninja probiert.. beide laufen mit mmc2iec..


    M2I funktioniert problemlos, man muss nur mal die Anleitung lesen um zu wissen wie man die Datei mountet. Die einfach zu laden halte ich für die schlechteste aller Lösungen, obwohl es auf einem C64 ohne Erweiterungen weniger Tipparbeit ist.


    OPEN1,8,15,"CD:FILE.M2I":CLOSE1 hilft. =) Da es in die Verzeichniswechselroutine eingebunden ist funktioniert zB auch CD://DIR/SUBDIR/FILE.M2I um in \dir\subdir\file.m2i zu wechseln (der doppelte / am Anfang steht für das Rootverzeichnis und ist wegen der Kompatibilität zu den CMD-Geräten drin).


    Zitat

    Generell finde ich das Dir-Listing bei mmc2iec praktischer, weil man sich das weglöschen des PRG sparen kann.. ist aber nur ne Kleinigkeit..


    Dummerweise gibts einige Software die sich sehr auf das Directory-Layout einer 1541 verlässt und beim Weglassen der Dateikennung Probleme bekommt - zB der in JiffyDOS eingebaute Dateikopierer. Bau dir doch einfach einen Alternativkernal in den C64 der in irgendeiner Art damit umgehen kann (zB ignorieren Jiffy und Dolphin die Kennung, EXOS v3 fügt automatisch einen Doppelpunkt ein - letzteres ist aber noch nicht richtig kompatibel weil der Fastloader nicht erkannt wird).

    Nun, das RTFM hatte ich gemacht.. ;-)
    Also ich habe ein Unterverzeichnis SUMMER. Darin sind die M2I Dateien von Summer Games..
    open1,8,15,"CD: SUMMER": close 1 funktioniert. Ich bekomme mit load"$",8 ein Verz. des Unterverzeichnisses SUMMER.
    (Das Blank ist nur wegen dem blöden editor.., sonst macht er mir aus : S - ein :S )
    open1,8,15,"CD: SUMMER*.M2I" funktioniert NICHT?! Meldet zwar READY, aber load"$",8 zeigt wieder das Unterverz. SUMMER an..


    Das gleiche 'Problem' mit D64 Files.. open... scheint auch nicht (mehr) zu gehen..? Zwar READY aber bin nicht im D64..


    ---


    Habe dann mal den 8MHz Quartz aktiviert..
    Turbo Disk 2.1 und 2.2 probiert.. Bildschirm wird einfarbig..... das wars.... C64 hängt..?



    -- kann es sein das nur die LarsP Version solche Probleme macht -- ?


    Peter

    Zitat von PeterSieg


    open1,8,15,"CD: SUMMER*.M2I" funktioniert NICHT?! Meldet zwar READY, aber load"$",8 zeigt wieder das Unterverz. SUMMER an..
    Das gleiche 'Problem' mit D64 Files.. open... scheint auch nicht (mehr) zu gehen..? Zwar READY aber bin nicht im D64..


    Da wird mit ziemlicher Sicherheit die rote LED geblinkt haben -> FILE NOT FOUND im Fehlerkanal. Ich hatte nämlich nicht damit gerechnet, dass jemand Wildcards auch für Directories (und damit Image-Files) verwenden würde. ^^; Das in allgemeiner Form (Wildcard in irgendeinem Teilpfad) ist auch nicht ganz einfach auszuwerten.


    Zitat

    Turbo Disk 2.1 und 2.2 probiert.. Bildschirm wird einfarbig..... das wars.... C64 hängt..?


    Komisch. Wie standen die Fuses? Passen die Kondensatoren am Quarz zu dessen Datenblatt?


    Zitat

    kann es sein das nur die LarsP Version solche Probleme macht -- ?


    Theoretisch... Bisher hatte ich die LarsP-Version optimistischerweise gar nicht getestet weil ich annahm, dass die geänderten Portzuweisungen keinen grossen Unterschied machen und irgendwer schon was sagen wird wenn da noch ein Fehler drin ist. Offenbar warst du der erste Tester. =)


    Mangels unverbauten 8MHz-Quarzen kann ich LarsP+mega32 zZt gar nicht testen, mein Steckbrett-Testaufbau ist normalerweise ein mega644 mit 16MHz und auf /2 eingestelltem Prescaler - in Shadowwolf-Verdrahtung. Ich werde wohl morgen mal testen ob das Turbodisk-Problem in LarsP-Verdrahtung damit reproduzierbar ist.

    Hi. Woran könnte es bei meinem Aufbau noch liegen..? Der Quartz ist ein Überbleibsel von Pollin.. Keine Unterlagen.. Die beiden Kondensatoren sind 22pf. Leider ist der Abstand zu den XTAL1+2 PIN's ca. 3-4 cm.. Ging nicht anders.. kein Platz ;-)


    Bei Last Ninja.m2i hieß die m2i Datei "LNINJA.M2I".. dabei mußte ich kein Wildcard angeben.. aber identisches Problem...


    Ideal wären sicher einmal ein Aufbau nach Shadowolf und einmal nach LarsP.. Evtl. bau ich mir auch mal ein Lochrasterversion
    mit Textoolsockel.. allzu oft vertragen das die Billigsockel und der Aufbau nicht ;-)


    Peter

    Zitat von PeterSieg

    Hi. Woran könnte es bei meinem Aufbau noch liegen..? Der Quartz ist ein Überbleibsel von Pollin.. Keine Unterlagen.. Die beiden Kondensatoren sind 22pf. Leider ist der Abstand zu den XTAL1+2 PIN's ca. 3-4 cm.. Ging nicht anders.. kein Platz ;-)


    Sicherlich nicht optimal, sollte aber trotzdem funktionieren - meine Quarznachrüstung an den 1.6er-Platinen sieht ähnlich aus.


    Evtl. GND an den Kondensatoren eingespart? =)


    Zitat

    Bei Last Ninja.m2i hieß die m2i Datei "LNINJA.M2I".. dabei mußte ich kein Wildcard angeben.. aber identisches Problem...


    Was sagt denn der Fehlerkanal nach dem CD-Befehl?


    Zitat

    Ideal wären sicher einmal ein Aufbau nach Shadowolf und einmal nach LarsP..


    Wäre sicherlich hilfreich und mit unterschiedlichen Geräteadressen auch problemlos gleichzeit am Bus betreibbar - aber da ich via Parallelport programmiere und nicht ständig umstöpseln will (wenn man die Schaltung leicht modifiziert kann man bei eingelegter SD-Karte via ISP programmieren) könnte ich nur einen Aufbau davon programmieren.


    Vielleicht sollte ich doch mal ein Spendenkonto einrichten um mir einen AVR Dragon zuzulegen. ;-)

    >Vielleicht sollte ich doch mal ein Spendenkonto einrichten um mir einen AVR Dragon zuzulegen. ;-)


    Einfach mal im Februar die EmbeddedWorld besuchen oder ein Seminar mitmachen. :-)
    Dazu braucht man dann aber auch noch den JTAG-Anschluss und der kann ohnehin nur mit meiner Schaltung funktionieren.


    Da man nur die Pins 21 bis 28 verbinden muss für den JTAG müsste man das auch dazubasteln können, zumal ich ab der 1.7'er Platine die Pads für den Controller ein klein wenig grösser gemacht habe.
    Den Reset-Pin braucht man am JTAG überhaupt nicht und das AVR-Studio blockiert auch den Controller nach dem Programmieren, wenn Reset angeschlossen ist.


    Vielleicht sollte ich noch eine 1.9+ machen, die wie meine ersten Platinen einen JTAG-Anschluss hat.

    Noch ein paar Hinweise..


    GND ist natürlich angeschlossen bei den beiden 22pf Kondensatoren ;-)


    Ich habe mal die SD Karten probiert, die am mmc2iec ihren Dienst verweigert hatten... (2x64MB, 128M, 256M)
    Sie verweigern ebenfalls ihren Dienst am sd2iec.. :-(
    (Nur eine 256MB Karte arbeitet.. diese hatte am mmc2iec mal funktioniert, mal nicht = Grenzfall)


    Fehlerkanal auslesen, komme ich erst morgen zu ;-)


    Peter

    Zitat von Shadowolf

    >Einfach mal im Februar die EmbeddedWorld besuchen oder ein Seminar mitmachen. :-)


    Uhh... Nürnberg? Zu weit weg -> auch teuer.


    Eigentlich würde es ja schon reichen wenn ich mal ein USBISP aufbaue. Ich glaube ich hätte sogar alles dafür in der Bastelkiste, wenn ich einen mega8L ein wenig übertakte...


    Zitat von PeterSieg


    Ich habe mal die SD Karten probiert, die am mmc2iec ihren Dienst verweigert hatten... (2x64MB, 128M, 256M)
    Sie verweigern ebenfalls ihren Dienst am sd2iec.. :-(


    Oh, ich glaube es wird Zeit für carddiag Runde 3. =)


    Nicht dass es immer helfen würde, eine meiner Karten läuft auf meiner losen v1.6er-Platine einwandfrei und auf der im DTV eingeklebten akzeptiert sie nicht mal das Reset-Kommando.

    Zitat von Shadowolf

    Da ich hier gerade so am Schreiben bin, die ML funktioniert irgendwie garnicht, bounced nur als nicht zustellbar...


    Argh, den Fehler mache ich immer wieder. =(


    Zwei MXe für eine Domain, keiner davon soll Mails annehmen die am Ende doch nicht zustellbar sind -> beide müssen wissen welche Adressen gültig sind. Da ich den Teil immer noch nicht automatisiert habe muss man da natürlich auch auf beiden die Adressen eintragen (d.h. eine Datei rüberkopieren) und das habe ich (mal wieder) vergessen.

    Hmm, ich hatte gerade mit der 0.4.2 Probleme mit einem Fastloader.
    Mit der 0.4.1 hat der noch fleissig Daten übertragen, mit der 0.4.2 dann nicht mehr.


    Einmal zurück auf 0.4.1 - läuft.
    Wieder auf 0.4.2 - läuft jetzt auch - häh?


    Irgendwas muss mit meiner Hardware nicht stimmen.


    Jedesmal wenn ich die Karte raus nehme und wieder reinstecke springt der Bootloader an.
    Praktisch und doch unerwartet. :-)


    Erst dachte, das wäre ein Feature der sd2iec Firmware.
    Den Effekt habe ich aber auch mit der MMC2IEC 0.9 Firmware.


    Mist, da könnte die Brown-Out Erkennung zuschlagen.
    Was nichts anderes heisst, als das die SD-Karte beim Einstecken so viel Strom zieht,
    dass die Kondensatoren leergelutscht werden und die Spannung unter 2,7V fällt.
    Das kann ich hier nur leider nicht nachmessen, ohne Oscilloscope ist das witzlos.


    Edit: Aber Abschalten der BOD geht und dann läuft das Gerät beim Einstecken der SD-Karte
    nicht mehr durch den Reset.


    Das ist ja ziemlich empfindlich, mal schauen, dass das nicht passiert wenn beim Zugriff auf die Karte deren Strom-Bedarf plötzlich steigt...




    Und damit es nicht langweilig wird habe ich mal was zum Spielen angehängt. :-)


    test-reihe_2007-12-26.zip


    ASCII2PRG2.exe - eine neue Version von meinem sd2iec logfile Konverter
    main.c - der C-Quellcode für obiges
    42 1541-turbo.prg - Ein weiterer Fastloader mit der Besonderheit, dass der "UC" zum Starten des Codes verwendet
    42.txt - Logfile-Auschnitt
    42.prg - das Logfile in ein .prg konvertiert, fertig zum disassemblieren


    Mit der neuen Version von ASCII2PRG muss man die Logfiles auch nicht mehr bearbeiten, erst werden mit Hilfe der ">" die Zeilen separiert und in hex konvertiert und im zweiten Durchgang dann die Daten extrahiert und aufbereitet.

    Zitat von PeterSieg

    Das gleiche 'Problem' mit D64 Files..


    Der Teil ist mir erst gerade eben aufgefallen: D64 ist in 0.4.x noch nicht implementiert, aber wer Spass an spontanen Controller-Resets bei Schreibzugriffen hat (Nullpointer als Platzhalter in der Funktionstabelle) kann gerne die CVS-Version selbst compilieren.


    Zitat

    Habe dann mal den 8MHz Quartz aktiviert..
    Turbo Disk 2.1 und 2.2 probiert.. Bildschirm wird einfarbig..... das wars.... C64 hängt..?


    -- kann es sein das nur die LarsP Version solche Probleme macht -- ?


    Ja, kann durchaus sein. Diesen Fehler hätte ich auch ohne Tests finden und beseitigen können wenn ich mal einen Augenblick länger darüber nachgedacht hätte... Das Flag um auf die LarsP-Pinbelegung umzuschalten wurde zwar beim compilieren von C-Dateien übergeben, aber nicht beim Assemblermodul für die Fastloader.


    Braucht es dafür jetzt unbedingt eine 0.4.3 oder kann es noch ein paar Tage warten bis 0.5 (hoffentlich) fertig ist?


    LNINJA.M2I aus dem grossen M2I-Archiv funktioniert hier übrigens.


    (seltsame Ideen für semi-nutzlose Erweiterungen: Statt eines gleichmässigen Fehlerblinkens den Fehlertext im Morsecode ausgeben)

    So ich konnte noch einen weiteren Fehler finden.. das saß nämlich vor dem Gerät ;-)
    M2I (getestet mit Last Ninja) funktionieren..
    Ich wollte den Fehlerkanal auslesen und da gab es keinen Fehler mehr.. muß mich wohl vertippt oder doch load.. probiert haben..


    open1,8,15,"cd:lninja.m2i":close1
    load"$",8
    load"the last ninja+.prg",8,1


    funktioniert jedenfalls..


    D.h mit der 0.5 und den behobenen Fehlern:
    load mit langen Dateinamenkürzungen (pi) zulassen (wie mmc2iec) - und
    Fastload mit LarsP Pinbelegung ok


    kann ich neu flashen und testen.. super!


    Zitat

    (seltsame Ideen für semi-nutzlose Erweiterungen: Statt eines gleichmässigen Fehlerblinkens den Fehlertext im Morsecode ausgeben)

    Nun, da hätte ich noch einen anderen Vorschlag..
    Textausgabe auf Standard 2-zeiligem LCD Display!
    Obere Zeile: Aktuelles Verzeichnis/Dateinahme
    Untere Zeile: Fehlerkanal/Rückmeldung(en)


    Dazu braucht man 4 Pins für die Daten+2-3 Steuerpins.. am ATmega32 sind ja noch genug vorhanden :-)
    Diese Displays gibts für ein paar €
    Wäre doch ne nette Spielerei..



    Danke,
    Peter

    Zitat von PeterSieg

    Nun, da hätte ich noch einen anderen Vorschlag..
    Textausgabe auf Standard 2-zeiligem LCD Display!
    Obere Zeile: Aktuelles Verzeichnis/Dateinahme
    Untere Zeile: Fehlerkanal/Rückmeldung(en)


    Dazu braucht man 4 Pins für die Daten+2-3 Steuerpins.. am ATmega32 sind ja noch genug vorhanden :-)


    Ja, Pins sind noch genug frei. Aber löte mal bei den Platinen von Shadowwolf was da an... Wenn schon dann lieber per I2C, die Pins dafür sind bei Shadowwolfs Platinen zufälligerweise(?) für die beiden LEDs verwendet worden. LarsP hat leider den IEC-Bus dort angeschlossen und das nicht mal so dass man davon profitieren könnte.


    Ein Display und irgendeine Eingabemöglichkeit zwecks Diskimage-Wechsel habe ich schon länger als sinnvolle Erweiterung im Hinterkopf, allerdings wird schon jetzt der Programmspeicher eng (knapp unter 24K von 32K (-2 für den Bootloader) belegt in meiner noch nicht D64-schreibfähigen Entwicklungsversoin) und ich bin mir nicht sicher wie viel Einsparpotential es gibt. Ohne UART-Debugausgaben wird es natürlich etwas weniger, aber viel Unterschied ist da nicht. SDHC- und FAT32-Support rauswerfen bringt ca. 2K, aber bei den typischerweise kleinen C64-Dateien fände ich es schade auf FAT32 verzichten zu müssen.


    Mindestens eine Minimalversion will ich aber irgendwie noch reinquetschen, d.h. auf der Karte liegt eine Datei die die Namen von Diskimages enthält und auf Knopfdruck wird auf das jeweils nächste gewechselt.


    Oder ich entwickle nur noch für den mega644 (doppelt so viel Ram/Flash), klemme noch einen EN28J60 (SPI zu Ethernet) dran und ermögliche den Fehlerkanal via Webbrowser auszulesen. ;-)