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

last post from 1570 at the

MMC2IEC Firmware Entwicklung

    Quote

    Original von wattie
    Hast Du den Rechner mal ganz ausgeschaltet und dann mit eingesteckter Karte eingeschaltet? Einfach nur im Betrieb die Karte rein oder Reset funktioniert nicht.


    Die BIN-Datei ins Hauptverzeichnis und dann einschalten. Habe ich jetzt alles 1000x probiert. Nix. Also habe ich wohl doch den alten Bootloader, oder?

    Bin zwar nicht sicher ob hier richtig.. aber..


    Der 'Lade'-Unterschied zw. MMC64 und MMC2iec ist schon enorm. War mir vorher so nicht klar.. liegt aber wohl sicher daran, das MMC64 die Datei mit eigenen Bordmitteln und parallel in den C64 Speicher 'beamt' und MMC2IEC eben Bit für Bit seriell über das IEC Protokoll.


    Hier nun 2 Fragen/Bitten.


    1. Sendet ihr Änderungen/Verbesserungen der Firmware bitte auch an Lars, damit er sie in seine orig. Version einpflegen kann (z.B Jiffydos 'Patch')?


    2. Welche Möglichkeiten seht ihr, das Laden zu beschleunigen.. mit und ohne Kompatibilität zum Standard C64/VC20/264er? Ich kenne z.B Jiffydos gar nicht? Habe bei einem C64 Speeddos drin.. braucht aber wohl ein Parallelkabel oder gibts auch schon über das IEC-Kabel eine Beschleunigung..


    Ideal wäre kompatibel zum Standard - eben mit aktueller Geschwindigkeit und bei passendem Kernel (Welcher dann?) eine höhere Geschwindigkeit..


    Peter

    Quote

    Originally posted by PeterSieg
    2. Welche Möglichkeiten seht ihr, das Laden zu beschleunigen.. mit und ohne Kompatibilität zum Standard C64/VC20/264er? Ich kenne z.B Jiffydos gar nicht? Habe bei einem C64 Speeddos drin.. braucht aber wohl ein Parallelkabel oder gibts auch schon über das IEC-Kabel eine Beschleunigung..


    Dazu gbt es u.a. hier einen Thread.


    Grundsätzlich ist es so, dass im MMC2IEC kein 1541 ROM enthalten ist, so dass seriell Speeder nicht direkt in die Routinen einsteigen können. Zudem sind aktuell keine 8 Pins am ATMega frei, um einen Parallelanschluss zu legen.

    Quote

    Original von AntaBaka
    Grundsätzlich ist es so, dass im MMC2IEC kein 1541 ROM enthalten ist, so dass seriell Speeder nicht direkt in die Routinen einsteigen können.


    Na, das wär ja gleich ein (Mörder) Feature für die 2.0er Version, oder?


    gruß,


    znarF

    Da ALeX schon mal angefangen hat, einen Datei Browser zu schreiben (wir sind bei gaaaanz frühen Tests), kann ich schon mal sagen, was für Fähigkeiten ihm in der MMC2IEC-Firmware fehlen: unabdingbar ist eine Möglichkeit zum byteweisen lesen und schreiben auf dem Medium, sonst können wir weder intelligent das Inhaltsverzeichnis auslesen noch irgend etwas kopieren. Das würde also z. Z. auf unserer Prioritätenliste ganz weit oben stehen.


    Die anderen getesteten Erweiterungen können das übrigens, sodass wir diese auf jeden Fall unterstützen wollen.

    Quote

    Originally posted by znarF
    Na, das wär ja gleich ein (Mörder) Feature für die 2.0er Version, oder?


    Ja, wenn der ATMega genug Speicher dafür hat...
    Das wurde, glaube ich, bereits in einem anderen Thread angesprochen.
    Es ist wohl etwas schwieriger, als man denkt.


    Ein MMC2IEC mit umschaltbarem Betriebssystem wäre natürlich genial, aber dafür müsste die bestehende Hardware (und Software) massiv umgebaut werden, was die Kompatibilität zur bestehenden Hardwareplattform (die ja immerhin jetzt mit über 100 tück vertreten ist) vermutlich killen würde.

    Quote

    Originally posted by Retrofan
    eine Möglichkeit zum byteweisen lesen und schreiben auf dem Medium, sonst können wir weder intelligent das Inhaltsverzeichnis auslesen noch irgend etwas kopieren


    Was spricht denn gegen die Verwendung von $ und C:neu=alt? Welche Syntax verwenden "die anderen getesteten Erweiterungen" für den gesuchten Direktzugriff?


    Quote

    Originally posted by AntaBaka
    Ein MMC2IEC mit umschaltbarem Betriebssystem wäre natürlich genial,


    Inwiefern umschaltbar?

    Quote

    Original von AntaBaka
    Ein MMC2IEC mit umschaltbarem Betriebssystem wäre natürlich genial, aber dafür müsste die bestehende Hardware (und Software) massiv umgebaut werden, was die Kompatibilität zur bestehenden Hardwareplattform (die ja immerhin jetzt mit über 100 tück vertreten ist) vermutlich killen würde.


    Und das würde meiner Meinung nach das ganze Projekt killen. Wenn jetzt, nachdem so viele Geräte "draußen" sind, noch einmal an der Hardware herumgeschraubt würde, statt jetzt mit der bestehenden Hardware zu leben und mit Software das bestmögliche aus dem System herauszuholen, würden sich die bestehenden User (und auch zukünftige) doch verschaukelt fühlen.


    Wenn jetzt, statt dass die Firmware jetzt mal richtig in die Startlöcher käme, eine neue Revision der Hardware (natürlich wieder mit nur rudimentärer Firmware) angeboten würde, hätte ich Bauchschmerzen, sie zu bestellen, da man sich auf eine Weiterentwicklung der Firmware ja anscheinend nicht verlassen könnte. Ob man so die Userbasis vergrößern könnte? Ich glaube, eher nicht.


    Ich sage ganz klar: Ich möchte keine neue Hardware (was jeder einzelne so lötet, ist mir egal), sondern verbesserte Software, damit ich die bestehende Hardware auch richtig nutzen kann! Mir ist klar, dass ich kein Recht habe, irgend etwas zu verlangen aber wenn man jetzt schon weitere Zeit in dieses Projekt steckt, dann sollte sie dazu dienen, die bestehende Userbasis glücklich zu machen und nicht schon den übernächsten Schritt zu gehen.


    (Zur Zeit muss ich wieder meine Bilder per X-Kabel auf Disks kopieren, weil ich kein brauchbares Grafikprogramm habe, dass ohne spezielle Floppyroutinen meine Koalas einließt und somit zum MMC2IEC kompatibel wäre. Und ohne die erwähnten Byte-Leseroutinen würde auch unser neuer File-Browser nicht auf dem MMC2IEC laufen)

    Quote

    Original von Unseen
    Was spricht denn gegen die Verwendung von $ und C:neu=alt? Welche Syntax verwenden "die anderen getesteten Erweiterungen" für den gesuchten Direktzugriff?


    Ich habe nur versucht, die Infos vom Programmierer an das Forum durchzureichen. Er liest (neben evtl. vorhandenen Suffixes) die ersten beiden Bytes jeder Datei aus, um den Typ zu ermitteln. Das geht wohl noch nicht beim MMC2IEC. Weiterhin wird wahrscheinlich ein Textviewer (ASCII+UTF8 ) in den Datei-Browser integriert und auch der benötigt byteweises lesen, da er evtl. den Text in Teilen lesen muss (wegen Größe). Ich hoffe, ich habe das jetzt einigermaßen richtig wiedergegeben.


    Und was ist C:neu=alt? Das kenne ich gar nicht.

    Quote

    Originally posted by Retrofan
    Er liest (neben evtl. vorhandenen Suffixes) die ersten beiden Bytes jeder Datei aus, um den Typ zu ermitteln. Das geht wohl noch nicht beim MMC2IEC.


    Ah... Byteweise ab Dateianfang lesen sollte aber eigentlich keine Spezialbefehle brauchen? Für beliebiges Springen in der Datei wollte ich mir noch was überlegen (evtl. "Missbrauch" des REL-Dateien-Positionierungs-Befehls) falls ich jemals so weit komme das es interessant wird.


    Quote

    Und was ist C:neu=alt? Das kenne ich gar nicht.


    Kann MMC2IEC auch nicht, steht aber in der 1541-Anleitung. =)

    Im Moment sehe ich das hier als 'Ideenfindungs-' und Diskussionsphase oder neudeutsch auch 'Brainstorming'.. das ist auch gut und ok so..


    Ein nächster Schritt muß dann aber eine systematische Ordnungsphase sein, in der man Anforderungen, mögliche Realisierungen - in Firmware - in Hardware, Woher kommen die Anforderungen (Direkt, Sekundär - z.B Bytesweises Lesen aus der Anforderung 'Browser'), geschätzter Aufwand etc. hervorgeht.


    Dann sortiert man alles aus, wo es nicht realistisch erscheint, diese mit der bestehenden Hardware zu lösen. Dann die, wo man wenig Changen sieht, sie mit einem vertretbarem Aufwand zu realisieren.


    Übrig bleiben dann alle auf dieser Hardware zu realisierenden, möglichen Erweiterungen/Anforderungen. (Und auf der ausgeschlossenen Liste=alle die eben hier nicht zu realisieren sind!)


    Diese Liste(n) wird priorisiert und dann muß man noch die Ressourcen finden, die dieses auch Implementieren.. Hier wäre dann spätestens auch der Punkt gekommen, nach vorhandenem Code zu schauen, den man verwenden kann (FAT.. etc.)


    Ich sehe es auch so, das die aktuelle Hardware ersteinmal die aktuellen Grenzen wiederspiegeln sollten.


    Falls man aber feststellen müßte, das viele der gewünschten Anforderungen nur mit einer neuen Hardware zu realisieren wären,
    so sollte das gleichbedeutend mit einer eben solchen Feststellung sein.
    D.h. ein Branch in:
    1. Weiterpflege der vorhandenen Firmware/Hardware im Rahmen der Möglichkeiten.
    2. Weiterentwicklung von Hardware+Firmware um die gewünschten Anforderungen abzudecken.


    Ich bin eigendlich sehr zufrieden mit dem mmc2iec. Es ist günstig zu bauen, Open Source!, es ersetzt in (nicht allen!) Fällen die echte Floppy für C64, VC20, +4 etc.


    Schön wäre ein 'Browser' ala mmc64. Schön wären beschleunigte Ladezeiten ala mmc64..


    Peter

    Quote

    Original von UnseenAh... Byteweise ab Dateianfang lesen sollte aber eigentlich keine Spezialbefehle brauchen? ...


    Da frage ich nochmal nach, damit ich das genauer beschreiben kann. Man kann also ohne Spezialkram (also vom MMC2IEC unterstützt) die ersten beiden Bytes einer Datei lesen, damit man die Ladeadresse herausbekommt?


    Quote


    Kann MMC2IEC auch nicht, steht aber in der 1541-Anleitung. =)


    Die habe ich vor etwa 120 Jahren mal gelesen. Jetzt verwende ich für so Sachen bestimmt keine Floppybefehle mehr. ;)


    Quote

    Original von PeterSieg
    Schön wäre ein 'Browser' ala mmc64. Schön wären beschleunigte Ladezeiten ala mmc64..


    ALeX hat mit einem Browser ja schon angefangen, das ist aber noch ein weiter Weg. Intuitiver bedienbar und hübscher als der vom MMC64 wird er auf jeden Fall. Das GUI habe ich schon so weit fertig. Die Masse an Arbeit hat jetzt der ALeX an den Hacken. ;)


    Beschleunigte Ladezeiten hätte ich natürlich auch gerne, lange Dateinamen und "erhöhte" Kompatibilität mit Fastloadern und Floppybefehlen. Das ist ja auch alles schon genannt.

    Quote

    Originally posted by Retrofan


    Da frage ich nochmal nach, damit ich das genauer beschreiben kann. Man kann also ohne Spezialkram (also vom MMC2IEC unterstützt) die ersten beiden Bytes einer Datei lesen, damit man die Ladeadresse herausbekommt?


    *umstöpsel* *basicprogramm tipp* *start* *1 8 seh*


    Ja, geht.


    Quote


    Die habe ich vor etwa 120 Jahren mal gelesen. Jetzt verwende ich für so Sachen bestimmt keine Floppybefehle mehr. ;)


    So lange die Kopie auf der gleichen Karte landen soll wie das Orginal wäre ein direktes Kopieren durch den Controller (genau das macht C - Copy) mit ziemlicher Sicherheit schneller als die Daten zum C64 und zurück zu kopieren. Die CMD-Geräte müssten auch eine Syntax haben um Kopien zwischen Unterverzeichnissen zu ermöglichen, wenn jemand mal das Kommando einbaut wäre es IMHO ziemlich sinnvoll das kompatibel dazu zu machen (Rad, neu erfinden, siewissenschon...).


    Quote

    Beschleunigte Ladezeiten hätte ich natürlich auch gerne


    Ich auch. =) [size=1]Und den ersten (, einfachsten) Mosaikstein dafür habe ich schon fertig.[/size]

    Quote

    Originally posted by Unseen


    Inwiefern umschaltbar?


    Man stelle sich vor, dass das MMC2IEC mehrere ROM-Images in einem Flasspeicher halten würde und über Schalter zwischen diesen ROMs umschalten könnte, um Kompatibilität zur original 1541, Jiffy, SpeedDOS und was-weiss-ich-nicht-alles zu haben.
    Das meinte ich damit und ja, realistisch sehe ich das auch nicht :)
    Dazu müsste die komplette Firmware neu geschrieben werden, um die Zugriffe auf das geflashte ROM zu emulieren und in Zugriffe auf die SD-Karte umzubiegen.
    Und ob das alles in einen ATMega noch rein passen würde, weiss ich auch nicht...

    Quote

    Dazu müsste die komplette Firmware neu geschrieben werden, um die Zugriffe auf das geflashte ROM zu emulieren und in Zugriffe auf die SD-Karte umzubiegen.


    das dürfte das geringste problem sein - denn ohne 6502 und CIA (und noch mehr) emulation nützen dir die rom images genau garnix :=)