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

last post from 1570 at the

MMC2IEC Firmware Entwicklung

  • Hallo, ich mache mal ein weiteres Thema zum MMC2IEC auf. Da meines schon funktioniert (Danke an Suschman, DMC, Shadowolf ...), interessieren mich vor allem die Entwicklungen bzgl. der Firmware.


    Ich habe ja eine gepatchte Version von Unseen (auch vielen Dank), die ich jetzt mit JiffyDOS testen konnte. Funktioniert einwandfrei! (natürlich ohne Beschleunigung). Ich hatte mal geschrieben, dass nichts bei mir nachlädt: Das stimmt nicht, ein einfaches, getestetes Basicprogramm lädt Bilder nach. Es liegt also doch an Fastloadern, die in vielen Programmen integriert sind.


    Wer ist denn nun eigentlich der Hauptansprechpartner, wenn es um die Weiterentwicklung der Firmware für das MMC2IEC in der Shadowolf-Variante geht? Könnte sich da evtl. mal eine Gruppe zusammentun, die die Entwicklung gemeinsam voranbringt? Oder findet das schon statt?


    Und könnte man dann evtl. für die User des Systems kurz beschreiben, was zur Zeit gemacht wird und was in der Pipeline ist (sodass man sich schon ein wenig freuen kann)?

  • Quote

    Originally posted by Retrofan
    Wer ist denn nun eigentlich der Hauptansprechpartner, wenn es um die Weiterentwicklung der Firmware für das MMC2IEC in der Shadowolf-Variante geht? Könnte sich da evtl. mal eine Gruppe zusammentun, die die Entwicklung gemeinsam voranbringt? Oder findet das schon statt?


    Und könnte man dann evtl. für die User des Systems kurz beschreiben, was zur Zeit gemacht wird und was in der Pipeline ist (sodass man sich schon ein wenig freuen kann)?


    Nachdem ich ein paar Tage im Code rumgestochert habe bin ich der Meinung, dass Wegschmeissen und neumachen (mit Übernahme einiger weniger Teile) die beste Lösung sein dürfte - was Lars da fabriziert hat spricht eher zufällig als absichtlich mit dem C64 (Beispiel: Man breche das Laden einer Datei oder des Directories mit Run/Stop ab und versuche danach das MMC2IEC nochmal anzusprechen) und geht recht verschwenderisch mit Ram/Flash im Controller um (im Code kommt kein einziges "static" vor, wenn man die nur in fat.c geeignet ergänzt spart man >200 Byte).


    Falls jemand meine aktuellen Sourcen (spi.c grössenoptimiert, sdcard.c aufgeräumt und mit ungetestetem SDHC-Support (andere Version als im anderen Thread), fat.c mit gezielten statics verkleinert) zur Weiterentwicklung nutzen will einfach bescheidsagen - ich weiss nicht ob ich in absehbarer Zeit dazu komme eine überarbeitete Firmware zu bauen.


    EDIT: Ich habe mal mein git-Repository unter http://snowcat.de/mmc2iec/mmc2iec.git gespiegelt.

  • Also zunächst einmal fände ich es schon gut und richtig, wenn sich die Software auch weiterhin für die Hardware von Lars compilieren lässt.
    Schliesslich hat er alles offen gelegt und zudem noch leichter auf andere Hardware anpassbar gemacht als ich meine Platine vorgestellt habe.


    Und während ich auch weiterhin noch für Hardware sorge fürchte ich, dass mir genauso wie Lars auch momentan die Zeit fehlt, das Projekt angemessen vorwärts zu bringen.
    Ich bin motiviert und denke mal auch qualifiziert, ist nur nicht das Einzige Projekt.
    Urlaub habe ich auch erst um Weihnachten rum.


    Unseen, die veränderte Firmware interessiert mich dennoch sehr!


    Ein CVS Server oder auch was einem sonst dazu einfällt wäre genau richtig,
    1570 hat zum Beispiel vorgeschlagen, dass Wiki dafür zu "misbrauchen".
    Wild durch die Gegend zu patchen bringt überhaupt nichts, dass muss schon ein wenig koordiniert werden.
    Nur bin ich selbst Hardware-Entwickler und bestenfalls Programmierer aber eben kein Software-Entwickler. Mir ist die vorgehensweise wage bekannt, ich muss mich normalerweise nur nicht dran halten da ich keine verteilte Entwicklung mache. :)


    Was wir also erstmal bräuchten ist ein Projekt-Manager.
    Jemand der die Dinge zusammenhält und den Überblick bewahrt.
    Der muss ja nicht einmal unbedingt Programmieren können, auch wenn das helfen würde.


    Und ist nicht viel Anreiz, okay, aber auch für diese Position würde ich eines der beiden Geräte zur Verfügung stellen die ich angeboten habe.



    Zum Thema wegschmeissen und neu machen.
    Bisher habe ich mich mit Kritik am Code ein wenig zurückgehalten, zumindest öffentlich.
    Aber was ich von dem Code gesehen habe gefällt mir auch nicht.


    Den Versuch lange Datei-Namen einzubauen habe ich aufgegeben als ich gemerkt habe,
    dass zu viel zu patchen ist um überhaupt erstmal im C64 Teil lange Datei-Namen aus dem FAT-Treiber verwenden zu können.


    Den Stil auf diese Weise C zu benutzen finde ich ein wenig holprig, auf die Art habe ich vor über zehn Jahren mal aufgehört auf dem C64 in Assembler zu proggen.
    Alleine schon wenn ich sowas wie "unsigned char" sehe kräuseln sich mir inzwischen die Fussnägel.


    Und ohne Timer, dafür mit Busy-Loops zu Programmieren kann ich garnicht mehr verstehen.



    Wenn ich die Zeit gehabt hätte, dann hätte ich mir hier Ideen für den FAT-Code geholt: FAT32


    Das FAT für jeweils eine geöffnete Datei wäre völlig ausreichend, finde ich.
    In der .d64 Emulation ist dann wiederrum die .d64 geöffnet und darin könnte man mehrer e "Dateien" öffnen.



    Fastloader.
    Ich glaube immer noch, dass eine Hash-Basierte Fastloader Unterstützung machbar ist.
    Eine Emulation dagegen wird niemals funktionieren, dafür ist der Mega32 zu langsam und hat erheblich zu wenig Speicher.
    Eine 6502 Emulation alleine müsste der locker wegstecken aber eben keine komplette Floppy Emulation mit exaktem Timing.


    Nun ja, Schritt eins ist den Memory-Write Befehl einzubauen.
    Schritt zwei ist den Memory-Execute Befehl so einzubauen, dass der bei Memory-Write empfangene Puffer mit Zusatz Informationen auf die nicht schreib-geschützte SD-Karte geschrieben wird.
    So wie den Namen der zuletzt übertragenen Datei und die beim M-W und M-W empfangenen Parameter wie Ziel-Adresse und Einsprung-Adresse.


    Vorzugsweise mit eindeutigem Namen wie: "FL!_xxxx.bin"
    Wobei das "xxxx" für eine CRC Prüfsumme steht.
    Dann veröffentlichen und schauen, was so die User so an Dateien abliefern.


    Schritt drei wäre mal einen weit verbreiteten Fastloader zu analysieren und eine IEC Übertragungs-Routine zu programmieren die ein äquivalentes Verhalten macht.


    Kommt man ratzfatz auf 450 grundverschiedene Fastloader wird es schwierig.
    Aber selbst nur eine handvoll Standard Fastloader zu erkennen und zu simulieren wäre schon der Bringer.



    Hardware.
    Zwei Wege.
    Zum einem möchte ich gerne den Mega328P verwenden - sobald der verfügbar wird.
    Der hat im Grunde alles was der Mega32 auch hat, kann aber mehr und hat weniger Pins.
    Nutzt man die neueren Features wird die Geschichte allerdings inkompatibel zur bestehenden Hardware.
    Ist also vielleicht garnicht so blöd, wenn ATN auch weiterhin zyklisch abgefragt wird, statt im Interrupt - zumal die Abfrage ja ohnehin nur gebraucht wird, wenn der Controller sonst nichts zu tun hat.


    Der Vorteil vom Mega328P wäre, dass der mit weniger Pins leichter zu löten ist und bei gleicher Platinen-Fläche alle Bauteile grösser werden können.


    Der andere Pfad wäre die Luxus-Variante.
    Den Mega32 durch den Mega644P zu ersetzen.
    Mehr Speicher, Interrupts möglich, läuft bis 20 MHz.
    Bei "Beschränkung" auf 8 MHz könnte man den sogar auf die bestehenden Platinen auflöten.
    Der Nachteil ist, der kostet erheblich mehr.
    Der Vorläufer Mega644-20AU - ohne P - kostet bei Reichelt 6,80 und bei CSD 8,95.


    Und bisher ist ja nicht raus, ob das wirklich gebraucht wird.
    Eigentlich benötigen wir ja nur eine handvoll Pins und die 30K+2K FLASH sind ja auch üppig, mit Optimierungen sowieso.


    Interessant wäre vielleicht noch, was man an Mehrwert anbauen könnte.
    Was man mit einem Display machen soll wäre mir nicht ganz klar, die Anzeige vom C64 selbst sollte ja reichen.
    Aber man könnte zum Beispiel die analog-Eingänge vom AVR per speziellen DOS-Befehlen vom C64 aus abfragen.


    ...

  • Quote

    Original von Unseen
    ich weiss nicht ob ich in absehbarer Zeit dazu komme eine überarbeitete Firmware zu bauen.


    Schade, ich hatte insgeheim gehofft, dass du kräftig an der Firmware weiterarbeitest/neubaust. Du bist da schon so schön tief drin und die ersten Ergebnisse waren ja schon sehr hilfreich. Aber vielleicht können wir hier ja noch Mitstreiter für dich finden, damit die Arbeit nicht auf den Schultern einer einzelnen Person lastet.


    Wie ich schon mal erwähnte, hatte auf der Willow-Party Skern (vom Dienstagstreff) angedeutet, dass er evtl. helfen könnte. Bei ihrem Hardwareprojekt haben sie ja teilweise mit den gleichen Sachen zu kämpfen (FAT32-Support, lange Dateinamen, D64-Unterstützung, Beschleunigung, allgem. Kompatibilität, Dateimanager, ...). Evtl. kann man grundsätzliche Sachen zusammen machen und nur bei den unterschiedlichen Implementierungen getrennte Süppchen kochen. Dann profitieren von den Entwicklungen viel mehr Leute gleichzeitig.


    Und wenn dann noch jemand hinzustoßen könnte? Wie sieht das denn mit den MMC64-Leuten aus, kann man denn da keine Gemeinsamkeiten finden? Es wäre doch sehr schade, wenn die Möglichkeiten dieser süßen Hardware brachliegen würden, vor allem, weil die Nutzerbasis des MMC2IEC hier im Forum ja gar nicht mal so schlecht ist, oder?

  • Soviel ich das mitbekommen habe, war Skern der Idee mit der Zusammenarbeit nicht unbedingt abgeneigt. Setzt euch doch mal mit ihm in Verbindung und quatscht mal über das Thema. Ich bin mir sicher, da kommt richtig was bei raus!

  • Quote


    Was wir also erstmal bräuchten ist ein Projekt-Manager.
    Jemand der die Dinge zusammenhält und den Überblick bewahrt.
    Der muss ja nicht einmal unbedingt Programmieren können, auch wenn das helfen würde.


    Sofern Bedarf besteht, bin ich gerne bereit, einen SVN Server zur Verfügung zu stellen. Da ich beruflich einige male schon Projekte über SVN koordiniert habe, sollte das kein Problem sein.


    Hab zwar momentan keinen großen Durchblick beim Quelltext zum mmc2iec, ich werde aber mal versuchen, mich da ein wenig reinzufuchsen.

  • Quote

    Originally posted by Shadowolf
    Also zunächst einmal fände ich es schon gut und richtig, wenn sich die Software auch weiterhin für die Hardware von Lars compilieren lässt.


    Sollte ich weiterbasteln wäre das auch mein Plan, sofern ich doch den mega644-Versuchungen erliege wenigstens mit reduzierter Funktion.


    Quote

    Unseen, die veränderte Firmware interessiert mich dennoch sehr!


    git nehmen und von obiger URL clonen (der fatcleanup-Branch ist der neueste) oder den Export unter http://snowcat.de/mmc2iec/mmc2iec-fatcleanup-20070913.zip saugen.


    Evtl. ist irgendwo noch Kram drin der ohne UART_DEBUG nicht compiliert, das hatte ich längere Zeit nicht mehr abgeschaltet.


    Quote

    Alleine schon wenn ich sowas wie "unsigned char" sehe kräuseln sich mir inzwischen die Fussnägel.


    Ich hatte beim Aufräumen auch erstmal alles durch uint8_t und co ersetzt, schon um mit etwas drumherumgewickelten Code zumindest grobe Tests auf dem Hostsystem statt dem Controller machen zu können - char an sich ist aber dringeblieben wo wirklich Zeichen übergeben werden.


    [SIZE=6]Kleiner Rant: fat.c hat eine Funktion fatFgetc, die das nächste Zeichen aus der Datei liest und zurückliefert. Die ist als char (signed!) deklariert und verwendet 0 als Rückgabewert für EOF. Das wird zwar nirgendwo abgefragt, aber wie kommt man bitte auf die Idee, einen an sich gültigen Rückgabewert so zu überladen? fgetc ist genau deswegen in den üblichen Standards als int deklariert und liefert dann -1 (alle normalen Zeichens ind positiv).[/SIZE]


    Quote

    Und ohne Timer, dafür mit Busy-Loops zu Programmieren kann ich garnicht mehr verstehen.


    Muss bei embedded-Kram nicht unbedingt etwas schlechtes sein, wenn man an der Stelle eh weiss das nichts anderes passieren kann oder alles andere von Interrupts behandelt wird. Die werden in MMC2IEC allerdings auch nur für den UART verwendet, im Sendefall sogar nur um ein Flag zu setzen auf das gewartet wird... :-(


    Quote

    Wenn ich die Zeit gehabt hätte, dann hätte ich mir hier Ideen für den FAT-Code geholt: FAT32


    Muss ich mir mal näher anschauen - im Augenblick schiele ich in Richtung Tiny-FatFS, das kommt wohl mit <8K Code bei voller Funktionalität aus.


    Quote

    Fastloader


    Spontaner Einfall: Brauchen wir dafür evtl. einen genauer kalibrierten RC-Oszillator? Bei einem zufälligerweise gerade angeschlossenen mega16 ist der (nur vom Programmierer auslesbare) Kalibrierungswert fuer 8MHz deutlich anders als der per Default geladene für 1MHz.


    Quote

    Nutzt man die neueren Features wird die Geschichte allerdings inkompatibel zur bestehenden Hardware.
    Ist also vielleicht garnicht so blöd, wenn ATN auch weiterhin zyklisch abgefragt wird, statt im Interrupt - zumal die Abfrage ja ohnehin nur gebraucht wird, wenn der Controller sonst nichts zu tun hat.


    "nichts zu tun hat" ist relativ, wenn man sich mal das Rom-Listing einer 1541 anschaut dann fragt die fast nach jedem Pegelwechsel auf dem Bus ab ob ATN gewackelt hat und springt ggfs. radikal zurück (incl. Stackpointer-Reset - könnte man in C natürlich mit setjmp/longjmp ähnlich machen).


    Mal so rein theoretisch rumgedacht könnte man auf dem mega328 die ATN-Abfrage via PCINT regeln und auf dem mega32 die gleiche Routine vom Timerinterrupt (<1ms Zykluszeit) aufrufen lassen - würde sich aber nur lohnen wenn man die dadurch gewonnene Rechenzeit für irgendwas braucht oder der Stromverbrauch kritisch ist.


    Quote

    Der andere Pfad wäre die Luxus-Variante.
    Den Mega32 durch den Mega644P zu ersetzen.
    Mehr Speicher, Interrupts möglich, läuft bis 20 MHz.


    Think big, mega2560 mit 512k-SRAM und Bankinglogik als XRAM. ;-)


    [SIZE=7](nicht ersthaft gemeint)[/SIZE]


    Quote

    Was man mit einem Display machen soll wäre mir nicht ganz klar, die Anzeige vom C64 selbst sollte ja reichen.


    Mitten im Spiel Disk-Images wechseln.

  • sooooo


    ich hab zwar durch mein studium jetzt verdammt wenig zeit, aber C programmieren kann ich trotzdem (nicht der hacker schlechthin, aber C klappt ziemlich gut!)


    jedoch kenne ich mich mit den benötigten routinen absolut NICHT aus!


    ich würde aber trotzdem daran teilnehmen und wenns nur dazu ist um fehler einzugrenzen etc


    also wenn dort bedarf besteht biete ich mich an! (wenn mein IEC läuft :D )


    und was neues lernen schadet ja eh nit ;)

  • Quote


    git nehmen und von obiger URL clonen (der fatcleanup-Branch ist der neueste) oder den Export unter http://snowcat.de/mmc2iec/mmc2iec-fatcleanup-20070913.zip saugen.


    Und wtf ist git schon wieder? :)


    Quote


    Spontaner Einfall: Brauchen wir dafür evtl. einen genauer kalibrierten RC-Oszillator? Bei einem zufälligerweise gerade angeschlossenen mega16 ist der (nur vom Programmierer auslesbare) Kalibrierungswert fuer 8MHz deutlich anders als der per Default geladene für 1MHz.


    Der Kalibrierungswert ist unterschiedlich weil damit der Controller ab Werk kalibriert wurde. :)
    Allerdings nur auf bestenfalls 1 Prozent und die interessante Frage ist wie viel Toleranz das IEC-Timing verträgt, vor allem wenn es um Fastloader geht.
    Mit 8 MHz läuft der AVR allerdings erheblich schneller als der 6502, das müsste mehr als Faktor 16 sein, auch in C, der 6502 braucht nicht nur mindestens zwei Takte pro Befehl, der hat auch bloss Akku, X und Y zur Verfügung.


    Ausserdem hängt in der 1541 an der CPU ja noch die Hardware die erstmal reagieren muss. Die Block-Dekodierung haben wir garnicht und der 2 MHz SPI ist wohl auch nicht wirklich als Flaschenhals zu sehen.


    Quote


    "nichts zu tun hat" ist relativ, wenn man sich mal das Rom-Listing einer 1541 anschaut dann fragt die fast nach jedem Pegelwechsel auf dem Bus ab ob ATN gewackelt hat und springt ggfs. radikal zurück (incl. Stackpointer-Reset - könnte man in C natürlich mit setjmp/longjmp ähnlich machen).


    Den letzten Satz hast Du hoffentlich nicht ernst gemeint? :)


    Quote


    Mal so rein theoretisch rumgedacht könnte man auf dem mega328 die ATN-Abfrage via PCINT regeln und auf dem mega32 die gleiche Routine vom Timerinterrupt (<1ms Zykluszeit) aufrufen lassen - würde sich aber nur lohnen wenn man die dadurch gewonnene Rechenzeit für irgendwas braucht oder der Stromverbrauch kritisch ist.


    Also im Moment wüsste ich nicht, was der Controller ausser warten noch machen sollte.
    Ein Display zu bedienen geht ja auch quasi nebenbei.
    Einen Drehimpulsgeber für das Menu abzufragen erfordert ein wenig mehr Rechenzeit.


    Quote

    Think big, mega2560 mit 512k-SRAM und Bankinglogik als XRAM. ;-)


    [SIZE=7](nicht ersthaft gemeint)[/SIZE]


    *Hust* AVR32


    Das Schmuckstück habe ich auf der Arbeit bereits rumliegen, bin nur noch nicht dazu gekommen, das mal in Betrieb zu nehmen.
    Nur wann man die kaufen kann und für wieviel - tja.
    Man könnte aber auch die EVA-Boards als 1541 Ersatz benutzen. :dance


    Ausserdem sollen auch die XMEGA's irgendwann kommen. ;)


    Quote

    Mitten im Spiel Disk-Images wechseln.


    Guter Punkt.

  • Quote

    Originally posted by Shadowolf


    Und wtf ist git schon wieder? :)


    Das Versionskontrollsystem das Linus Torvalds gebastelt hat als es zu Streitereien mit den Bitkeeper-Leuten kam. Ich finde daran recht nett, dass es komplett ohne zentralen Server auskommt. http://git.or.cz/ ist die Homepage, für Win32-Fans gibts wohl was bei cygwin und irgendwo las ich was von einer mingw-Version.


    Quote

    Der Kalibrierungswert ist unterschiedlich weil damit der Controller ab Werk kalibriert wurde. :)


    Schon klar, das Problem ist nur dass der Controller jetzt mit dem Kalibrierungswert für den 1MHz-Oszillator läuft obwohl der 8MHz-Oszillator verwendet wird -> Die 1% werden sehr wahrscheinlich nicht eingehalten.


    Es gibt irgendeine Appnote die beschreibt wie man die Kalibrierung selbst vornehmen kann wenn man einen bekannten externen Takt hat, es müsste also nur jemand ein C64-Programm schreiben das den auf einer der Leitungen erzeugt.


    Quote


    Ausserdem hängt in der 1541 an der CPU ja noch die Hardware die erstmal reagieren muss. Die Block-Dekodierung haben wir garnicht und der 2 MHz SPI ist wohl auch nicht wirklich als Flaschenhals zu sehen.


    Zumindest der Jiffydos-Code von dem mehrere Dissassemblate rumschwirren lädt erstmal die Daten ins Ram bevor sie mit genau abgezählten Takten über den Bus geschoben werden - immerhin Byte-synchronisiert. Wenn es irgendwann mal so weit ist das wir das unterstützen kann man immer noch nachrechnen wie viel Spielraum bleibt.


    Quote

    Den letzten Satz hast Du hoffentlich nicht ernst gemeint? :)


    Öh, doch? Wenn es nicht anders geht oder wenn eine Alternativlösung den Code zu umständlich macht habe ich keine Probleme damit Sprünge zu verwenden. Ja, Djikstras "GOTO considered harmful" habe ich gelesen.


    Quote

    Ein Display zu bedienen geht ja auch quasi nebenbei.
    Einen Drehimpulsgeber für das Menu abzufragen erfordert ein wenig mehr Rechenzeit.


    Wäre das ein kommerzielles Projekt wäre das der ideale Punkt für eine spätere Addon-Platine, die zB über die Laufwerksauswahlpins mit dem Orginal redet. ;-)

  • Nicht, dass ich von den letzten Postings viel verstanden hätte (muss ich wohl auch nicht) ;) aber es zeigt doch, dass sich hier speziell zwei Leute ziemlich viel Gedanken um die Entwicklungsmöglichkeiten machen und tief in der Materie sind.


    Wenn du, Shadowolf und du, Unseen jeder ein wenig Zeit für die Entwicklung einer feinen Firmware zur Verfügung stellen könntet, Watti sich ein wenig um die Koordinierung/Server kümmern würde und Jackdaniels sich da so langsam reinfuchst, sieht es doch schon gar nicht so übel aus, oder?


    :bia


    Und vielleicht stößt ja noch jemand dazu, der auch noch ein wenig Zeit aufbringen kann ...

  • Quote

    Öh, doch? Wenn es nicht anders geht oder wenn eine Alternativlösung den Code zu umständlich macht habe ich keine Probleme damit Sprünge zu verwenden. Ja, Djikstras "GOTO considered harmful" habe ich gelesen.


    hehe, in der tat. fast das schlimmste was man machen kann ist code der einzig darum so aufgebläht und ineffizient ist weil er auf ein goto an passender stelle verzichtet, und das nur weil goto "böse" ist.


    abenteuerlich wirds doch eh erst wenn da inline assembly ausserhalb des function scopes steht und das dann am besten noch per setjmp aufgerufen wird :=)

  • Ich habe heute die Info bekommen, dass ALeX/P1X3L einen schönen Dateibrowser schreiben würde, wenn die Firmware-Entwicklung ansonsten voran ginge.


    (ich nehme doch stark an, dass man die Dateibrowser der anderen IDE/MMC-Entwicklungen nicht verwenden kann, oder?)

  • Quote

    Originally posted by Retrofan
    Ich habe heute die Info bekommen, dass ALeX/P1X3L einen schönen Dateibrowser schreiben würde, wenn die Firmware-Entwicklung ansonsten voran ginge.


    Dateibrowser?
    LOAD"$",8,1?
    Was?

  • Quote

    Original von AntaBaka
    LOAD"$",8,1?


    :roll2:


    oder ist das jetzt dein Ernst? Und dann wieder "Load" bei jedem Verzeichnis?


    Ich dachte an einen Browser (der auf Wunsch per Autostart lädt), bei dem man in der Dateiliste (und sei sie noch so lang) schön hoch- und runterlaufen kann, mit einer Taste in Verzeichnisse (und D64-Images) springen (und wieder zurück), evtl. Dateien umbenennen, evtl. sogar kopieren kann. Ein Scrollbalken sollte anzeigen, wo man sich in der Liste befindet und evtl. wäre eine zusätzliche Joysticksteuerung auch nicht verkehrt, um ganz entspannt zurückgelehnt durch die Ordner zu springen.


    Ich denke, ein bisschen komfortabler als mit LOAD"$",8 geht es schon, oder?

  • Quote

    Originally posted by Retrofan
    Ich denke, ein bisschen komfortabler als mit LOAD"$",8 geht es schon, oder?


    Ja sicher, aber dafür brauchst Du auch ein ROM (oder RAM) in dem der Browsercode liegt oder ein modifiziertes Betriebssystem im C64.
    Das hat ein MMC2IEC eigentlich gar nicht, daher meine Verwunderung.
    Wo genau soll der Dateibrowser liegen?
    Wir reden hier ja nicht von einer Modulerweiterung wie dem MMC64, wo ich ROM/RAM zur Verfügung habe, um solche Plugins und Programme abzulegen und auszuführen.
    Dass MMC2IEC ist ja eigentlich 'nur' eine Floppy.
    Also müsste ich den Browser jedesmal erneut laden?
    Das erscheint mir doch etwas zu umständlich, selbst mit Autostart.