Hallo Besucher, der Thread wurde 6,6k mal aufgerufen und enthält 19 Antworten

letzter Beitrag von Unseen am

sd2iec 0.2.1

    Irgendwie wäre es ja schon praktisch, Postings die älter sind als eine Stunde noch editieren zu können - insbesondere wenn man dann auch den Threadtitel bearbeiten kann und somit nicht für jede Version einen neuen Thread aufmachen muss um nicht zu riskieren, dass irgendjemand das neue Release tief vergraben im alten Thread übersieht...


    Bugfix-Release, Source+Binaries unter http://snowcat.de/mmc2iec/ - siehe auch den 0.2er-Thread.


    Beseitigte Probleme:

    • Manchmal wurden die letzten 8 Directoryeinträge doppelt ausgegeben
    • Manchmal wurde der letzte Block einer zu speichernden Datei doppelt gespeichert
    • Der C64 zeigt ~ zwar als Pi an, sendet es aber als 0xff
    • Manche SD-Karten initialisierten sich so langsam, dass sie abgelehnt wurden. Jetzt sind die Zeitlimits am oberen Anschlag - wenn irgendwelche Karten weiterhin den Dienst mit sd2iec verweigern bitte mal in SD-Karten-Diagnose-Firmware reinschauen und mitwirken.


    Ja, ich habe vergessen das Patchlevel im Makefile zu erhöhen. Shame on me, dafür ersetze ich jetzt aber nicht Commit+Tag+Archive.

    Zitat

    Original von MasterJulian
    PS: wie sieht das eigentlich mit nachlade spielen aus?


    Solange die die normalen Systemroutinen verwenden, sieht es sehr gut aus.
    Alles andere halt nicht.
    Zu den Fastloadern gibt es aber auch einen eigenen Thread.

    Hallo,


    erstmal grosses Lob an alle, die sich an der Entwicklung beteiligen und Ihre Freizeit damit opfern!


    Ich hätte eine Frage zur Firmware:
    Wird es möglich sein, in einem M2I Container B-P Befehle die auf einen Track / Sektor zeigt, in eine Datei umzuleiten? Manche Programme wurden u.a. für das IDE64 so gefixt.


    gruß,


    znarF

    Zitat

    Originally posted by znarF
    Wird es möglich sein, in einem M2I Container


    Ich habe zur Zeit keine Pläne, Support für M2I einzubauen. Das Format ist einfach unbrauchbar, es gibt keine Möglichkeit zu erkennen wo der C64-Dateiname aufhört und die Füll-Leerzeichen anfangen.


    Zitat

    B-P Befehle die auf einen Track / Sektor zeigt, in eine Datei umzuleiten? Manche Programme wurden u.a. für das IDE64 so gefixt.


    B-P setzt nur den Zeiger im Puffer neu, meinst du möglicherweise B-R und B-W? Wie sollte eine Unterstützung für sowas funktionieren?

    Zitat

    B-P setzt nur den Zeiger im Puffer neu, meinst du möglicherweise B-R und B-W? Wie sollte eine Unterstützung für sowas funktionieren?


    Ja, hast recht, der Block-Read gehört natürlich dazu!
    Hier mal ein Beispiel:


    Orginal Game:

    Code
    1. open15,8,15:open5,8,5,"#"
    2. print#15,"b-r:";5;0;T;S



    IDE64 fixed Game:

    Code
    1. open15,8,15:open5,8,5,"datei"
    2. print#15,"p"chr$(5)chr$(0)chr$(ff)chr$(0)chr$(0)


    Ist die Unterstützung von D64,D71 und D81 Images in der Firmware angedacht?


    gruß,


    znarF

    Zitat

    Originally posted by znarF
    Hier mal ein Beispiel: [entfernt]


    Ah! Ja, so ergibt das ganze Sinn. Irgendwer hatte sowieso nach einem Seek-Kommando gefragt, da bietet es sich natürlich an gleich die IDE64-Syntax zu übernehmen.


    Zitat

    Ist die Unterstützung von D64,D71 und D81 Images in der Firmware angedacht?


    Gedacht sicherlich. Wann ich dazu komme ist eine andere Frage, im Augeblick fehlt auch noch diverser "Kleinkram" - zB Wildcards oder auch nur komplettes ignorieren von Laufwerksnummern (0:foo führt zZt zu einem garantierten Syntax Error). Die Auswertung von Filetyp+Modus (zB ,S,W) erfolgt auch noch nicht und wenn ich schon für CD/MD die CMD-Verzeichnissyntax unterstütze wäre es nur konsequent die beim Öffnen von Dateien auch zu verwenden.


    Da fällt mir gerade etwas auf: Wie wichtig ist es, die Funktion von * nachzubauen? Auf der 1541 wird damit immer die zuletzt angesprochene Datei anhand von gespeichertem Track+Sektor nochmal geöffnet, um das in sd2iec nachzubauen müsste ich mir den letzten Filenamen merken - effektiv eine Verdoppelung des Kommandopuffers im eh schon knappen Ram.

    Zitat

    Original von Unseen
    Da fällt mir gerade etwas auf: Wie wichtig ist es, die Funktion von * nachzubauen? Auf der 1541 wird damit immer die zuletzt angesprochene Datei anhand von gespeichertem Track+Sektor nochmal geöffnet, ...


    Also meiner Meinung nach reicht es volkommen, wenn man mit * die erste Datei ansprechen kann ;)

    naja


    was unter der haube abgeht weiß ich ja nit, aber M2I finde ich schon sinnvoll um nachlader zu zocken!


    anscheinend ist das ja problemlos möglich (nicht bei allen klaro :D )


    finde deine arbeit gut....


    nur ist halt wie immer bei projekten... es gibt ein grundprojekt (sd karte am iec bus nutzen) und dann 464894654 umsetzungen davon ....


    finde es schade das die arbeitskraft auf diese weise sehr leidet und die nutzer hin und her gerissen werden


    (sollte jetzt kritik an dir sein! ist nur ein generelles problem was sich überall findet und schade ist!)


    aber mach ma felißig weiter :D


    ich bin gespannt was dabei rauskommt.

    Zitat

    Originally posted by jackdaniels
    was unter der haube abgeht weiß ich ja nit, aber M2I finde ich schon sinnvoll um nachlader zu zocken!


    Andererseits ist das einzige was das Format wirklich bietet die Nutzung von etwas längeren Dateinamen. Als Anwender fände ich es irgendwie praktischer wenn man nicht ein Verzeichnis voller Dateien mit (mehr oder weniger) komischen Namen und eine nochmal extra zu mountende Steuerdatei hätte sondern wenn die entweder gleich alle passend im Verzeichnis liegen oder es nur eine Datei mit Metainformationen+Daten selbst ist (wie .d64 eben). Leider eignet sich keines der schon existierenden C64-Archivformate (ARC/ARK/LNX/LBR/T64) wirklich dazu es als Dateisystem einzusetzen, überall hakt es beim Hinzufügen und Löschen von Dateien. =(


    Zitat

    nur ist halt wie immer bei projekten... es gibt ein grundprojekt (sd karte am iec bus nutzen) und dann 464894654 umsetzungen davon ....


    finde es schade das die arbeitskraft auf diese weise sehr leidet


    Ah, das Mythos wieder...


    Du kannst ja mal ausprobieren wie viel du an MMC2IEC ändern musst, damit es ein mit sd2iec vergleichbares Bushandling bekommt - der Directory-Lister von JiffyDOS ist dafür ein guter Testfall, der sendet nach jeder Zeile UNTALK/TALK. Danach können wir uns nochmal darüber unterhalten ob es eine gute Idee war ein neues Projekt anzufangen oder an MMC2IEC weiterzuprogrammieren.


    Zitat

    und die nutzer hin und her gerissen werden


    Alle aus meiner Sicht relevanten Nutzer (sprich: Ich) verwenden sd2iec. ;-)


    Ich programmiere die Firmware vor allem weil ich sie gebrauchen kann, die Veröffentlichungen hier gibt es nur weil ich vermute dass das auch auf andere zutrifft.


    (nicht veröffentlichen ist eh bequemer - keine Archive die erstellt werden müssen, keine Doku zu schreiben, viel einfacheres und schnelleres Debugging wenn etwas nicht funktioniert) [size=1]Und erst recht keine grauen Haare wegen irgendwelcher mieser Webforensoftware die nie mit dem Komfort guter Newsreader konkurrieren kann.[/size]


    Zitat

    (sollte jetzt kritik an dir sein! ist nur ein generelles problem was sich überall findet und schade ist!)


    Es ist kein Problem, es ist eine Stärke von FOSS. Wenn sich niemand traut ein Projekt zu forken oder eine komplette Alternative zu bauen gehen gute Ansätze verloren wenn das Orginal stagniert (letztes offizielles MMC2IEC-Release: Mai 2007).


    Bekannte Beispiele bei denen es Spaltungen gab und die davon profitierten sind zB *BSD, egcs oder X.org.


    (in gewissem Sinne willst du, dass alle eine Kathedrale bauen während ich einen Basar bevorzuge)


    Zitat

    ich bin gespannt was dabei rauskommt.


    Ich auch =)

    Ich verwende z.Z. auch sd2iec und finde das ein super projekt. Das der User "hin und hergerissen" ist, ist doch kein problem. Einfach Den Bootloader drauf und schon kann man mit 2 sd karten einfach die Firmware wechseln(ohne pc/reflash den chips). Ich finds ne klasse sache hier und werde das auch weiter verfolgen und soweit ich kann auch unterstützen.
    [SIZE=7](Auch wenn ich dan wieder mit nervigen Debuging daten komme)[/SIZE]

    hast mich in einem punkt nicht ganz verstanden!


    mit der aufteilung der arbeitskraft meinte ich nicht, daß du lieber am MMC2IEC arbeiten sollst!
    ich will und werde keins der beiden bewerten! was besser oder schlechter ist.... kann jeder für sich herausfinden.
    ich meinte nur wirklich, daß wenn alle ihre kraft in eine richtung bündeln würden, käme man schneller voran!


    das es in diese falle nicht geht, weil du den mmc2iec code bescheiden findest ist ja ok.
    wenn aber alle an einer neuauflage arbeiten würden mit einem gemeinsamen ziel wäre es für alle am besten.


    das meinte ich :D


    naja bsd und x.org ok, aber linux nervt mich schon teilweise mit den unterschiedlichen paketverwaltern etc... mal haste rpm mal deb etc... also nit immer SOOOO sinnvoll


    aber wollte eigentlich auch keine grundsatzdiskussion hervorbringen. sorry :rotwerd:


    mach ruhig ma weidda...
    wenn das teil verzeichnisse kann und nachlader ähnlich dem m2i verarbeiten kann und dazu noch schneller ist, werde ich bestimmt nicht weinen :D

    Ist ja nicht wirklich so, dass es da viel zu bündeln gäbe.
    Unseen ist der Einzige momentan der das Projekt überhaupt vorwärts bringt.


    Und wenn ich endlich mal dazu komme mich produktiv zu beteiligen dann werde ich das auf jeden Fall bei der SD2IEC Firmware machen.



    Was es sonst noch so gibt ist Alternative Hardware, die braucht aber auch andere Software die bestenfalls nur zu einem kleinen Teil überhaupt übertragbar wäre.
    Zum Beispiel dürften die FAT Funktionen vom IEC-ATA uninteressant sein weil das Design auf erheblich mehr Speicher aufbaut.

    Zitat aus Beispiele für Games mit Fastloader? hier eingefügt weil es drüben evtl. weniger Leute bemerken.


    Zitat

    Originally posted by Unseen
    Ich suche erstmal noch nach dem Grund wieso ich gelegentlich ein Bit verliere und wenn der Teil geklärt ist wird geprüft zuverlässig man Fastloader ohne Hardwareänderungen hinbekommt - vorher lohnt sich der Aufwand nicht.


    Gefunden: Das Bit geht auf dem SPI-Bus, also auf dem Weg von der bzw. zur SD-Karte verloren. Die fertigen Platinen von Shadowwolf dürften davon nicht betroffen sein, einige Lochrasteraufbauten vielleicht schon - immerhin laufen da 2MHz über teilweise schlecht verlegte Drähte.


    Den Takt auf 500kHz herunterzudrehen hilft zumindest meinem Testaufbau nicht zuverlässig, aber SD/MMC-Karten unterstützen CRC-Prüfungen aller Daten auf dem Bus - das sollte die Fehlerwahrscheinlichkeit deutlich genug senken.


    Glaubt jemand, dringend eine 0.2.2-Version nur mit dieser Änderung zu benötigen oder kann ich mir noch etwas Zeit bis 0.3 lassen?

    Zitat

    Original von Unseen
    Glaubt jemand, dringend eine 0.2.2-Version nur mit dieser Änderung zu benötigen oder kann ich mir noch etwas Zeit bis 0.3 lassen?


    Wegen mir kann das gerne bis 0.3 warten. Allerdings habe ich die SD2IEC-Firmware noch nicht im Einsatz, da sie ohne Verzeichnis/D64-Unterstützung für mich noch nicht sinnvoll ist. Wird eigentlich die (fertige) SD2IEC-Firmware auf jeden Fall lange Dateinamen können oder ist das eher nur im Bereich des Möglichen?

    Zitat

    Originally posted by Retrofan
    Wegen mir kann das gerne bis 0.3 warten. Allerdings habe ich die SD2IEC-Firmware noch nicht im Einsatz, da sie ohne Verzeichnis/D64-Unterstützung für mich noch nicht sinnvoll ist. Wird eigentlich die (fertige) SD2IEC-Firmware auf jeden Fall lange Dateinamen können oder ist das eher nur im Bereich des Möglichen?


    Verzeichnisse sind doch schon eingebaut. =)


    Offiziell ist erstmal kein Feature "in jedem Fall" drin weil ich eh nur die Sachen einbaue von denen ich im Augenblick der Meinung bin, dass deren Implementation gerade interessant ist.


    Lange Dateinamen würde ich im Prinzip gerne irgendwann einbauen, aber die Microsoft-Patente in dem Bereich machen mir leichte Sorgen (jaja, kleine Fische, nicht kommerziell usw. - im Prinzip alles keine Ausrede). Ausserdem sind die recht schräg im Dateisystem gespeichert und wenn man mit langen Dateinamen anfängt ist der Punkt gekommen an dem man sich überlegen muss wie man die Zeichensätze konvertiert. LFNs sind immer UTF-16.


    Aber falls mir jemand einen Patch schicken sollte der LFNs auf nicht zu furchterregende Art einbaut und keine Lizenzprobleme verursacht (GPLv2!) würde ich den wohl einbinden.

    Moin,


    Zitat

    Originally posted by Unseen


    Ich habe zur Zeit keine Pläne, Support für M2I einzubauen. Das Format ist einfach unbrauchbar, es gibt keine Möglichkeit zu erkennen wo der C64-Dateiname aufhört und die Füll-Leerzeichen anfangen.


    wie waere es mit der moeglichkeit, das *.P00 dateien in einem verz. in der reihenfolge der dateinamen (z.B. 000.P00, 001.P00, ...) dargestellt werden, aber mit den echten C64 namen (die ja drinne stehen) angezeigt werden bzw. darauf zugegriffen wird?


    Dies ist nur so ein vorschlag, der fast alle features der M2I (ausser DEL's) hat, aber man nicht noch mal extra ein das M2I wechseln muss, und es sogar auch so in emulatoren ohne diskwechsel laeuft (was einfach ein nettes gimmick waere). aber ich weiss, ich hab' gut reden, da ich ja nichtmal eine brotkiste habe...


    Ciao, ALeX.

    Zitat

    Originally posted by alx
    wie waere es mit der moeglichkeit, das *.P00 dateien in einem verz. in der reihenfolge der dateinamen (z.B. 000.P00, 001.P00, ...) dargestellt werden, aber mit den echten C64 namen (die ja drinne stehen) angezeigt werden bzw. darauf zugegriffen wird?


    Die Idee klingt gar nicht mal so schlecht. Ich sehe zwar noch ein paar potentielle Haken (zB wann neu erstellte Dateien als P00 gespeichert werden sollen; auch die üblichen Probleme die durch Verwendung zweier Namen pro Datei die beide in ihrem Namensraum eindeutig sein müssen), aber wenn mal Unterstützung für Wildcards eingebaut sind sollten die lösbar sein.