Forum64

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.

Quoted

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.

Quoted

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?

Quoted

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.

Quoted

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.

Quoted

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. =(

Quoted

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.

Quoted

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]

Quoted

(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)

Quoted

ich bin gespannt was dabei rauskommt.

Ich auch =)

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

Quoted

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?

Quoted

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.

Quoted

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.