Hello, Guest the thread was called9.8k times and contains 96 replays

last post from 1570 at the

MMC2IEC Firmware Entwicklung

    Das sehe ich ein wenig anders. Ein Dateibrowser muß ja nicht in erster Linie dazu dienen, Programme vom mmc2iec zu starten. Ein Dateibrowser kann mir viele Funktionen (kopieren, löschen, verschieben, Verzeichnisse erstellen ...etc) zur Verfügung stellen. Und für sowas fände ich einen Dateibrowser schon komfortabel. Den Browser vom ide64 z.B. finde ich ziemlich gut und auch verdammt hilfreich.

    AntaBaka:


    Evtl. hast du recht aber das sind z.Z. ohnehin Wolkenkuckucksheime. Ich wollte in diesem Fred in erster Linie anregen, dass sich Leute zusammenfinden, die sich für die Entwicklung der MMC2IEC-Firmware verantwortlich fühlen, damit wir hier nicht auch die Situation einer halbgaren Lösung bekommen, wie es bei anderen Projekten ja schon öfters bemängelt wurde.


    Und in zweiter Linie wollte ich gerne eine Anlaufstelle haben, wo ich die aktuellen Entwicklungen bzgl. der Firmware nachvollziehen (und diese herunterladen) kann und Infos über die Roadmap bekomme (für die Vorfreude).


    (wie ich gerade sehe, ist dies mein 500ster Beitrag, hoch die Tassen auf das Jubiläum) :freude

    Quote

    Originally posted by wattie
    Ein Dateibrowser kann mir viele Funktionen (kopieren, löschen, verschieben, Verzeichnisse erstellen ...etc) zur Verfügung stellen. Und für sowas fände ich einen Dateibrowser schon komfortabel.


    Da bin ich voll bei Dir - ein solch komfortabler Dateibrowser wäre schön.
    Aber den muss man halt immer laden, solange das MMC2IEC nicht über zusätzlichen RAM/ROM-Speicher verfügt - welcher irgendwie auch noch (über den Expansionsport?) angesprochen werden müsste, um das Tool zu starten.
    Es ist ja nicht wie ein MMC64, wo man Plugins einfach einklinken kann.
    Den Dateibrowser sehe ich daher sehr unabhängig vom MMC2IEC.
    Aber haben wollen würde ich den auch.


    Am liebsten allerdings für den PC.
    Inkl. M2I-File Unterstützung usw. damit man bequem am PC seine SD-Karte managen kann.

    Es wäre doch möglich eine "Tools Diskette" unter Geräteadresse 9,10,11
    auf den Atmel-Chip zu legen.


    Das normal MMC unter ,8 und die Tools z.B. unter 9 als geflashte Disk im
    Chip?


    Ist nur ne Idee. :roll:


    Oder als spezielle Datei auf dem MMC z.B: SYSDATX.D64 (X=9,10,11) was dann auf den Chip geschoben wird oder unter dem anderen Gerät da ist.
    :roll:

    Quote

    Originally posted by hoeppie
    Es wäre doch möglich eine "Tools Diskette" unter Geräteadresse 9,10,11
    auf den Atmel-Chip zu legen.


    Das ist es ja, was ich meine - dazu benötigen wir Speicher auf dem MMC2IEC, der aktuell nicht in der Hardwarekonfiguration enthalten ist.
    Dann reden wir aber über eine technische Neuentwicklung, die vermutlich mit dem bisherigen MMC2IEC nicht mehr kompatibel wäre.

    Quote

    Original von wattie
    Den Browser vom ide64 z.B. finde ich ziemlich gut und auch verdammt hilfreich.


    Da ich kein IDE64 habe, fände ich es gut, wenn mal jemand ein kleines Video (evtl. vom VICE "abgefilmt") posten könnte, wo man die grundsätzlich Optik und Funktion des Browsers erkennen kann.


    Das könnte ich, mit ein paar mockups von mir an ALeX weiterreichen, damit er sieht, in welche Richtung das gehen kann.


    Evtl. könnte man den Browser alternativ auf ein Modul packen, für Leute, die den nicht immer laden wollen.


    Wenn die verschiedenen MMC/IDE-Projekte einigermaßen saubere 1541-Emulation (neben load und save) zur Verfügung stellen, sollte es kein Problem sein, mit einem Browser alle glücklich zu machen, oder? Ich weiß nur nicht, ob es verschiedene Ansätze gibt, die Verzeichnisse zu verwalten usw.


    Z.Z. schreibt ALeX ohnehin gerade an einer Videoroutine und an dem Grafikkonverter, sodass noch ein paar tage Zeit sind, Wünsche zu formulieren und die Firmware in Ordnung zu bringen. ;)

    Quote

    Originally posted by Retrofan
    Ich weiß nur nicht, ob es verschiedene Ansätze gibt, die Verzeichnisse zu verwalten usw.


    Da wäre es mal interessant zu wissen was denn die diversen anderen Lösungen für Kommandos zur Unterverzeichnisverwaltung verwenden - am sinnvollsten erscheint es mir bisher, die kompatibel zu denen der CMD-Laufwerke zu machen (Suche: Doku dazu, habe leider selbst keines) weil das die wohl am längsten auf dem "Markt" etablierte Lösung ist.


    Quote

    sodass noch ein paar tage Zeit sind, Wünsche zu formulieren und die Firmware in Ordnung zu bringen. ;)


    Hach, immer dieser hoffnungslose Optimismus hier... Niedlich... ;-)


    Ach ja: M2I halte ich immer noch für einen furchbaren Hack den ich am liebsten rauswerfen und durch etwas besseres ersetzen würde, aber noch bin ich mir nicht sicher was das sein könnte. LFNs auf FAT sind reichlich umständlich zu implementieren (UTF16-codierung), Imagefiles mit Commodore-kompatiblem Directory (zB im gleichen Format wie die CMD Native-Partitionen) sind umständlich für den Nutzer.

    Quote

    Original von jackdaniels
    wäre das umsetzbar auf dem MMC64 ? zb dort als plugin mit zugriff aufs diskdrive?


    Wahrscheinlich könnte der mögliche Programmierer des Browsers das am Besten beantworten. Da ich von Ihm aber erst mal ein vage Zusage habe, er noch anderweitig beschäftigt ist und sich die die Materie noch hineinarbeiten muss (mit IO hatte er noch nicht so viel zu tun) wird eine Äußerung von ihm noch dauern.


    Ich finde es viel wichtiger, dass wir beim MMC2IEC erst einmal eine stabile Basis haben. Über Multi-Projekt-Browser kann sich immer noch Gedanken machen.


    Vielleicht wäre es ja recht hilfreich, wenn ein technisch versierter Mensch mal zusammensammelt, was es an verschiedenen Lösungsansätzen bei den unterschiedlichen Hardwareprojekten gibt, was davon universell brauchbar wäre und was nicht. Muss es z.B. sein, dass bei IDE64, MMC64, MMC2IEC, IEC2ATA und wie sie alle heißen, jeder Entwickler getrennt darüber nachdenkt, wie man FAT32-Support hinbekommt?

    Ich finde es ist wichtig, das zunächst mal ein Ziel definiert wird, was die mmc2iec Firmware leisten soll. Erst danach macht es imho Sinn über den Tellerrand zu schauen, was davon bereits in anderen Projekten realisiert und auch fürs mmc2iec umsetzbar ist. Ich bezweifle nämlich, das sich z.B. vom mmc64 viel umsetzen läßt (jemand der beides kennt möge mich korrigieren).

    Ich kann ja mal sagen, was ich gerne hätte (man möge mich korrigieren, wenn irgendwas doch eher unwichtig oder unsinnig ist):


    FAT32 (Lange Dateinamen, kleine Cluster)
    Kompatibler (mehr Befehle neben Load und Save)
    Schnelleres Laden (JiffyDOS-Unterstützung?)
    Fastloader-Unterstützung für Nachladeprogramme (so gut wie geht)
    Sauberer gut pflegbarer Code? (kann ich nicht beurteilen, ist aber bestimmt hilfreich)
    Alles, was auf Dateisystemebene geht , sollte auch im D64 (und umgekehrt) gehen


    was wahrscheinlich nicht geht, ich aber super fände: Wenn sich nach einem Reset das MMC2IEC merken würde, in welchem Verzeichnis man war. Es ist sehr nervig, immer wieder durch alle Ordner zu müssen, um in einem bestimmten Verzeichnis nacheinander Bilder oder Programme zu starten.


    (vom MMC64 lässt sich wahrscheinlich weniger übernehmen als von anderen IEC-basierten Projekten, oder?)

    Quote

    Originally posted by Retrofan
    FAT32 (Lange Dateinamen, kleine Cluster)


    Zumindest dem Code nach ist FAT32 schon in Lars' Version enthalten. Lange Dateinamen sind ein davon unabhängiges (und zusätzlich patentrechtliches) Problem.


    Quote

    Alles, was auf Dateisystemebene geht , sollte auch im D64 (und umgekehrt) gehen


    Ich weiss nicht ob es wirklich eine gute Idee ist, ein Validate-äquivalent (aka chkdsk) in den Microcontroller zu stopfen... ;-)


    Quote

    was wahrscheinlich nicht geht, ich aber super fände: Wenn sich nach einem Reset das MMC2IEC merken würde, in welchem Verzeichnis man war.


    Rein theoretisch sollte das gehen, der Controller hat ja ein EEPROM wo man die Daten ablegen könnte. Wäre eigentlich auch ein netter Ablageort für die Geräteadresse wenn man die Jumper dafür für etwas anderes braucht.


    Quote

    Es ist sehr nervig, immer wieder durch alle Ordner zu müssen, um in einem bestimmten Verzeichnis nacheinander Bilder oder Programme zu starten.


    Ok, "mehrere Unterverzeichnisse in einem Befehl durchlaufen" sollte wohl auch auf die Todo-Liste.

    Quote


    was wahrscheinlich nicht geht, ich aber super fände: Wenn sich nach einem Reset das MMC2IEC merken würde, in welchem Verzeichnis man war.


    Also bei mir macht es das. Wenn ich irgendein Directory geladen habe, dann einen Reset mache und danach das Inhaltsverzeichnis wieder lade, befinde ich mich immer noch im selben Verzeichnis wie vor dem Reset.

    Quote

    Originally posted by wattie


    Also bei mir macht es das. Wenn ich irgendein Directory geladen habe, dann einen Reset mache und danach das Inhaltsverzeichnis wieder lade, befinde ich mich immer noch im selben Verzeichnis wie vor dem Reset.


    Sollte es auch, die RESET Leitung ist nämlich gar nicht angeschlossen bei dem Gerät :prof:

    Zuletzt repariert:
    21.2. Logitech M570 Microschalter ausgetauscht - geplante Obsoleszenz durch Billigtaster?
    19.11. Toshiba 3,5" Floppy defekter Elko durch Kerko getauscht auf Motorplatine
    27.11. 1541B Dauerlauf, Elko im Resetschaltkreis defekt, nicht der 7406 wie zuerst verdächtigt!

    Noch ein Nachtrag für die Wunschliste. falls möglich, wäre es sehr schön, wenn die Resource-Dateien vom Mac nicht angezeigt werden würden. Z.Z. haben diese Dateien den gleichen Namen, wie die zugehörige Datei, mit einem führenden Linkspfeil (glaube ich). Das Ausblenden dieser Dateien würde die Übersichtlichkeit erhöhen und Mac-Nutzer müssen dann nicht immer dran denken, die Resourcen auf dem Medium zu entfernen.


    Wie sieht es denn jetzt aus, gibt es nun ein verantwortliches Entwickler-Team oder doch noch nicht?

    Quote

    Originally posted by Retrofan
    Noch ein Nachtrag für die Wunschliste. falls möglich, wäre es sehr schön, wenn die Resource-Dateien vom Mac nicht angezeigt werden würden. Z.Z. haben diese Dateien den gleichen Namen, wie die zugehörige Datei, mit einem führenden Linkspfeil (glaube ich). Das Ausblenden dieser Dateien würde die Übersichtlichkeit erhöhen und Mac-Nutzer müssen dann nicht immer dran denken, die Resourcen auf dem Medium zu entfernen.


    Werden die mit Hidden- oder System-Attribut versehen? Wenn nein braucht es einen Filenamenfilter (sehr unschön, es könnte ja jemand das gleiche Namensschema verwenden wollen), wenn ja hilft die angehängte Version - die überspringt beim Erzeugen des Directories alle Dateien bei denen mindestens eines dieser Attribute gesetzt ist. IMHO auch praktisch für Verzeichnisse in denen man eh nur die M2I-Datei laden will.


    Quote

    Wie sieht es denn jetzt aus, gibt es nun ein verantwortliches Entwickler-Team oder doch noch nicht?


    Bisher scheint sich keiner getraut zu haben öffentlich zuzugeben sich dafür verantwortlich zu fühlen.