MMC2IEC Anwender

Sorry, ich meinte "one-file fixed" games.
Und ja, jede 100% Lösung ist unverhältnismässig teurer.
Im Selbstbau kostet ein MMC2IEC ungefähr 15 EUR.

Quote

Original von greg
Also wenn schon, dann will ich endlich eine konsequente Lösung (d.h. 100% Kompatibilität zur 1541). Diese Lösung existiert zwar schon, aber leider nicht ganz billig.

Hm, welche denn?

Oliver W.

Ich glaube, er meint den Please login to see this link..

Quote

Originally posted by Retrofan
... musste ich leider feststellen, dass das Gerät mit JiffyDOS wirklich nicht arbeiten möchte (leider habe ich keine Umschaltplatine in meinem Rechner) und, was noch schwerer wiegt, überhaupt nicht nachladen möchte.

Was den JiffyDOS-Bug angeht glaube ich zu wissen woran es liegt:

Wenn man mit dem Commodore-Kernal zB das Directory lädt, schickt dieser 0x28 0xf0 (Listen 8, Secondary 0) unter ATN auf den Bus. JiffyDOS dagegen schickt 0x28 0x6f 0x3f (Listen 8, Dataq(*) 15, Unlisten) unter ATN auf den Bus. Die MMC2IEC-Firmware erwartet nach den zweiten Byte dieser Sequenz eine zu speichernde Datei übermittelt zu bekommen und ignoriert völlig, dass das dritte Byte eigentlich mit ATN gesendet wird. Nach ~9ms will Jiffy wieder ein Byte unter ATN senden, bekommt aber keine Reaktion vom mmc2iec, das zu dem Zeitpunkt meiner Meinung nach noch auf zu speichernde Daten wartet. Jiffy sieht also kein Gerät mehr am Bus, kurze Zeit später (60ms?) gibts auch einen Timeout im mmc2iec und alles ist wieder wie direkt nach dem Einschalten.

Um den Fehler vernünftig zu beseitigen müsste man die Struktur der Firmware ziemlich umbauen (ich überlege ob ich das Ding nicht komplett neuschreibe...), an einem unsauberen Fix bastele ich noch. Aktueller Stand: Laden geht, @$:* (F1) hängt.

(*) "Das grosse Floppybuch 1570/1571" beschreibt den Code als "Sekundäradresse für Listener- und Talker-Betrieb", aber das passt scheinbar nicht so ganz?

Quote

Selbst wenn ich ein Malprogramm oder ein Diashowprogramm ohne Fastloader (aus D64-Images) starte, können diese Programme keine Bilder mehr laden.

Gehts genauer, möglichst mit Link auf ein betroffenes Image?

Der D64-Support scheint sehr oberflächlich zu sein, Schreiben und alles was den Kommandokanal erfordert ist nicht implementiert.

Quote

Das D64 Image habe ich selbst erzeugt, da ich auf der Willow Party eigentlich ein paar Work-In-Progress-Bilder auf dem C64 zeigen wollte. Aber kein Grafikprogramm wollte meine Bilder mehr laden - von Disk und mit dem Emu ging es. Ich werde noch einmal ein D64 erzeugen und es hier posten.

Komisch. Ich hatte mal zwei Magic Disk-Ausgaben (11/87 und 4/88) ausprobiert, davon lief die 4/88 einwandfrei, die 11/87 scheint einen Fastloader zu verwenden.

Quote

Kannst du, sobald rudimentärer/dirty Jiffy-support vorhanden ist, die Firmware hier posten? (dann kann ich mir das ewige Umstecken sparen)

Das hatte ich so geplant, aber erstmal muss ich mir ein Adapterkabel löten um den Bus beobachten zu können ohne den C64 senkrecht zu stellen (wackelige Bastelei mit Krokoklemmen am seriellen Stecker). Kannst du den modifizierten Bootloader mit Support für "Testversionen" flashen oder muss ich eine echte Versionsnummer ins Image schreiben?

Quote

Originally posted by erik1967
Hallo Unseen, um noch mal auf Deine M2I Konvertierung zurückzukommen. Mir ist aufgefallen, dass IDE gefixte Files kein Problem darstellen. Mehrfiler aus d64 extraiert sind nach der Konvertierung nicht mehr zu starten.
Geben grundsätzlich einen Syntaxfehler aus.
Kannst Du das bestätigen?

Nein, ohne Beispieldaten die den Fehler provizieren kann ich grundsätzlich nie etwas bestätigen.

Quote

Originally posted by Retrofan

Ich glaube, ich kann nix flashen (oder muss man dafür auch nur eine Datei auf die Karte packen?)

Theoretisch könnte man mit sehr viel Aufwand eine Datei basteln die man nur auf die Karte kopiert und die dann sebstständig den Bootloader aktualisiert. Praktisch wäre das aber ein fieses Assemblergefrickel, da der AVR sich nur selbst programmieren kann wenn gerade das Programm im Bootloaderbereich ausgeführt wird - der ja gerade aktualisiert werden soll. Ein Programmierkabel zu löten wäre viel weniger Aufwand, das kommt im allereinfachsten Fall mit fünf Drähten am PC-Parallelport und einer 5V-Quelle aus und im weniger einfachen Fall (zu "moderner" PC-Parallelport) mit selbigem plus einem Puffer-IC (bei mir zB ein rumliegender 74HCT573).

Aber um zum eigentlichen Problem zurückzukommen: Während eines Directory-Listings mit @$ wirft Jiffy jede Menge UNTALK/TALK 8-Sequenzen auf den Bus. Die Firmware des MMC2IEC ist aber so simpel gestrickt, dass sie das Inhaltsverzeichnis gerne in einem an den Rechner schicken will und überhaupt nicht darauf achtet ob gerade wieder ein Steuerbyte empfangen werden muss. Ohne den IEC-Teil der Firmware komplett umzubauen, damit die sich wirklich ans Protokoll hält und nicht nur eine vereinfachte Version davon versteht die zufälligerweise häufig passt geht das komfortable Directory-Listen von Jiffy leider nicht - aber es gibt ja noch LOAD"$",8 (das geht).

Die angehängte Version sorgt wenigstens für grundsätzliche Funktion mit Jiffy (mein Test-M2I für Ultima 5 läuft), die interne Versionsnummer ist 10 statt der bisherigen 9. Wir haben noch 65525 Versuche bevor der Bootloader wirklich per Programmierkabel ausgetauscht werden muss.

Quote

Originally posted by Retrofan
Angehängte Version?

Klar. Siehst du nicht den Anhang an diesem Posting?

ich habe einige Toshiba gekauft bisher (manche mit HAMA-Label drauf) - die laufen ganz gut.
Gab's bei Blödmarkt für 18 EUR für 2x 1GB.