Hallo Besucher, der Thread wurde 14k mal aufgerufen und enthält 96 Antworten

letzter Beitrag von 1570 am

MMC2IEC Firmware Entwicklung

    Zitat

    Original von Shadowolf
    Warum eigentlich eine Diskussion für einen generischen Datei-Browser im Thread für die MMC2IEC Entwicklung?


    Entschuldigung, das war mein Fehler. Ich hatte schon vorher den Datei Browser erwähnt, um zu zeigen: Wenn die Firmware mehr können wird, wird das auch von anderen Entwicklungen unterstützt werden. Unser Datei Browser war auch vor allem für die komfortable Nutzung des MMC2IEC gedacht (da ich nur diese Erweiterung an meinem 64er habe).


    Nach kurzem Überlegen haben wir uns dann aber entschlossen, die Entwicklung möglichst offen zu halten, um möglichst viele C64-Nutzer damit glücklich zu machen. Nach dieser Entscheidung wäre es sinnvoller gewesen, einen eigenen Thread aufzumachen. Sobald es etwas neues über das Programm zu berichten gibt, werde ich das nachholen und im "Anwenderprogramme"-Forumsbereich einen Thread starten (oder doch besser im Bereich "neue Hardware"?). Also hier bitte nur noch etwas zu unserem Datei-Browser schreiben, wenn es mit der MMC2IEC-Firmware auch zu tun hat.

    Also eigentlich wollte ich die letzten Tage mal ein bisschen am Source schnitzen.


    Aber weiter gekommen als der letzten Version von Unseen beizubringen das sie sich mit 0.11 melden soll bin ich noch nicht.



    Was ich eigentlich gerne machen würde ist, dem Ding mal "M-W" beizubringen.
    Nur, nach zwei Tagen verstehe ich immer noch nicht, wie der Kommando-Parser überhaupt funktioniert, jedenfalls macht er nicht einmal annähernd, was ich von ihm erwarte.


    Kann mir jemand sagen, wo die Kommandos verarbeitet werden?


    Eigentlich dachte ich in "interface.c", genauer in Interface_handler().
    Die Verzweigung auf die verschiedenen Pfade FAT/D64/T64/... ist reichlich obskur.


    Aber selbst wenn ich das ignoriere und mich einfach mal in fat_cmd() einklinke und dann ein OPEN 1,8,15 sowie PRINT#1,"M-W" absetze, passiert nichts weiter, als ob der Code eben nicht angesprungen wird.


    Edit:


    Hmm, das gibt eine Reaktion in fat_cmd():


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


    Kann es sein, dass PRINT# garnicht funktioniert?


    Eine richtige Beschreibung vom IEC wäre mal praktisch...

    Zitat

    Original von Shadowolf
    Kann es sein, dass PRINT# garnicht funktioniert?


    Die MMC2IEC-Software arbeitet doch intensiv mit Timeout-Loops.


    Ist jetzt nur so eine Vermutung, aber könnte es sein, dass zwischen dem OPEN und dem PRINT# im MMC2IEC ein Timeout auftritt, da zwischen der Ausführung von zwei seperaten BASIC-Befehlen evtl. zuviel Zeit vergeht?


    Wenn dem so ist, könnte man evtl. den Delay mal testweise ein wenig höher setzen.


    CU
    Kratznagel

    Zitat

    Originally posted by Shadowolf
    Aber selbst wenn ich das ignoriere und mich einfach mal in fat_cmd() einklinke und dann ein OPEN 1,8,15 sowie PRINT#1,"M-W" absetze, passiert nichts weiter, als ob der Code eben nicht angesprungen wird.


    Ja, die Kommandos werden nur geparst wenn sie beim Open-Kommando angegeben werden und nicht wenn sie danach mit PRINT# gesendet werden. Der vermutlich passende Ort um letzteres nachzurüsten wäre interface.c, Zeile 816ff - da wo ich "ugly fix for JiffyDOS" hingekritzelt habe.


    Auf dem Bus sieht das (teilweise aus dem Gedächnis) so aus, unter ATN gesendete Bytes stehen in (), alle Zahlen in Hex:
    - OPEN1,8,15,"foo": (28 ff) "foo\n" (3f)
    - PRINT#1,"bar": (28 6f) "bar\n" (3f)
    - CLOSE1: (28 ef)


    Wenn ich den Kram noch richtig in Erinnerung habe akzeptiert die 1541 maximal 42 Byte lange Kommandos und führt diese erst aus nachdem ein Byte mit EOI empfangen wurde, Daten nach den ersten 42 Byte werden verworfen.


    [size=1]Seltsam, beim kurzen Test sehe mal gCLggggA3f und mal gCLgggEgA3f bei OPEN... Aber das Timing ist eh noch nicht komplett geprüft.[/size]


    Zitat

    Eine richtige Beschreibung vom IEC wäre mal praktisch...


    Use the disassembly, Luke. ;-)

    Zitat

    Original von Unseen


    Ja, die Kommandos werden nur geparst wenn sie beim Open-Kommando angegeben werden und nicht wenn sie danach mit PRINT# gesendet werden.


    Super, also doch an der falschen Stelle gestochert.
    Naja, jetzt bin ich gerade in fat_cmd() und der Debugger macht mich irre.
    Aus irgendeinem Grund bekomme ich keine Breakpoints in neuen Code.


    Zitat


    Der vermutlich passende Ort um letzteres nachzurüsten wäre interface.c, Zeile 816ff - da wo ich "ugly fix for JiffyDOS" hingekritzelt habe.


    Na, einen Ansatz-Punkt habe ich ja jetzt wenigstens zum weiteren Spielen.



    Na, da wird ja noch richtig Freude aufkommen...



    Zitat


    Ist jetzt nur so eine Vermutung, aber könnte es sein, dass zwischen dem OPEN und dem PRINT# im MMC2IEC ein Timeout auftritt, da zwischen der Ausführung von zwei seperaten BASIC-Befehlen evtl. zuviel Zeit vergeht?


    Zuerst habe ich das mit einem kleinen BASIC Programm versucht,
    erzeugt quasi auch keine Reaktion...

    Aus dem IEC-ATA Fred:


    Zitat

    Original von NLQ


    Interesse ja, aber leider keine Zeit. Ich habe so viel an NLQ-HD zu tun. Allerdings könnte ich dem Programmierer beim Einbinden der JIFFYDOS-Routinen helfen. Die sind allerdings in Assembler und ich weiss nicht ob MMC2IEC in C oder Assembler ist.


    Tschüss
    NLQ


    Falls Interesse bei Unseen oder Shadowolf besteht besteht, könnt ihr euch ja mal bei NLQ melden:


    http://www.forum64.de/wbb2/thread.php?postid=186760

    mhh...wollt mal fragen ob hier ein sticky "MMC2IECSoftware Thread (Kein Laberthread!)" angelegt werden kann, wo die letzten softwareupdates (eventuell letzten bootloaderversionen) und alle zusatzsoftware, tools für die MMC2IEC zum download bereitsteht. Langsam seh ich hier nicht mehr durch..

    Hallo Leute, Software zusammen entwickeln ist das Stichwort.



    Ich bin ja auch dran Jiffidos in C-Code zu packen.
    Das hatte einer meiner Leute bereits angefangen und den Ass-Code den ich vom NLQ habe in C gepackt.
    Leider ist das nicht fertig geworden, und ich habe leider nicht genug C errfahrung um es schnell fertig zustellen.


    Ich werder in den nächsten tagen alle Quellcodes, die ich habe in BerliOS einstellen. http://www.berlios.de/


    Wer möchte kann sich dazu gesellen.


    Mein Traum ist die CMD HD so gut wie es geht zu ersetzen.


    Primäres Ziel ist OPEN IEC Routinen in C für Jedermann um alle möglichen Dinge an den IEC Bus zu hängen.


    z.B. diskettenwechler, Blumengießer, neue Druckerinterface mit Jiffi und und und.


    Freue mich schon darauf... :roll2:

    Ich hoffe der eine oder andere hatte es noch nicht ;-)
    (Nicht das ich hier schon wieder Eulen nach Athen trage..)


    Hier eine Doku zu den JiffyDOS Routinen... Word 7..
    Habe zwar auch eine PDF Version, das ZIP ist aber zu groß um es hier hochzuladen..


    Evtl. ja brauchbar um die Firmware des mmc2iec weiter zu bringen..


    Peter

    Noch eine blöde Frage..


    Könnte es was bringen, die mmc2iec mal mit einem anderen C64 Kernal zu betreiben..? Einer der an einer unveränderten 1541 auch eine schnellere Ladezeit bringt..? Oder ist das so Quatsch..?


    An C64 Kernal Roms habe ich:
    speeddos
    exos v3
    superdos
    cockroach
    (einer der sich mit Armageddon or Peace meldet?)


    Roms gibts unter anderem auch hier:
    http://members.optusnet.com.au…ROM/ROM-COMPUTER/ROM.html


    Peter

    Zitat

    Originally posted by PeterSieg
    Könnte es was bringen, die mmc2iec mal mit einem anderen C64 Kernal zu betreiben..? Einer der an einer unveränderten 1541 auch eine schnellere Ladezeit bringt..? Oder ist das so Quatsch..?


    Nein, die laden einfach nur Schnellladercode in die 1541, der vom MMC2IEC mangels 6502 nicht ausgeführt werden kann.


    Zitat

    speeddos


    Läuft, aber die Directoryausgabe mit F7(?) sieht etwas kaputt aus weil SpeedDos die Formatierung ändern will und das MMC2IEC ein etwas anderes Directory schickt als erwartet.


    Zitat

    exos v3


    Hängt


    Zitat

    superdos
    cockroach


    Kenne ich beide nicht.

    Mir ist da eben was aufgefallen :


    Wenn ich während eines Ladevorgangs run/stop drücke bleibt die grüne LED an und ich muss den C64 aus- und wieder einschalten, damit er wieder was lädt (ansonsten kommt nur "device not found".


    Der Fehler tritt aber nur beim Laden von "$", "<" ,"<<" oder Verzeichnissen bzw. M2i oder D64/T64 auf.
    Lade ich ein PRG und breche ab, kommt es nicht dazu.


    Wäre nett, wenn man das demnächst beheben könnte ! :]

    Hat schonmal jemand über GEOS-Unterstützung seitens des MMC2IEC nachgedacht? Da gibt's wohl zwei Probleme - zum einen den Fastloader, zum anderen den sektorweisen Zugriff auf die Diskette. Wie wäre es zum Beispiel, Unterstützung für Block-Read und Block-Write in die Firmware einzubauen? Dann müsste man "nur" noch einen MMC2IEC-Treiber für GEOS (ohne Fastloader, nur B-R/B-W) schreiben, wenn ich richtig liege. Oder gäb's noch andere Möglichkeiten?