Hello, Guest the thread was called3.7k times and contains 57 replays

last post from silverdr at the

Dolphindos 4 von silverdr

  • Wenn man Dolphin DOS optimiert, wäre es evtl. sinnvoll, einen eigenen Speicherbereich für Track 18 zu reservieren, damit diese Spur nicht immer und immer wieder gelesen werden muß, wenn auf viele kleine Dateien hintereinander zugegriffen wird.
    Das funktioniert bei Most Access II ganz gut, welcher als Software-Speeder allerdings auch viel C64-RAM verbraucht.

    Nicht jetzt. "Don't bite more than you can chew". Vielleicht für V5 ;-) Wie funktioniert es bei "Most Access II"?


    Also für wietere 8K hätte DolphinDos (3) von $8000 bis $9FFF noch Platz...

    Originell, in DD3 $8000-$FFFF ist mit ROM belegt wie bei 1571.

    Vvielleicht könnte man diesem Dolphin gleich etwas mehr RAM zur Verfügung stellen, so wie es das ominöse RAM-DOS von ProfDOS oder TurboTrans das machen.

    Directory-cache ist denkbar (später). Wahrscheinlich auch ohne weitere 8KiB. TurboTrans aus DolphinDOS möchte ich aber nicht machen ;-)

  • Find ich super von Dir/Euch, dass Du/Ihr DD weiter entwickelt. :thumbup:


    Eine weitere Idee wäre doch mal das Jiffy-Protokoll zu integrieren, so als Fallback-Protokoll, falls im C64 gerade JiffyDOS aktiv ist.

    Dies wäre eine sehr gute Idee.
    Mit DD4 ausgestattetes Laufwerk läuft parallel,weiter LW laufen mit JD (wenn das LW ein JD-ROM hat).
    Somit wäre ein LW super schnell und die Anderen wenigstens schnell. :rolleyes:


    Und dann das ganze auch noch für C128, C128D, C128DCR. :saint:


    Gruss C=Mac.

  • Originell, in DD3 $8000-$FFFF ist mit ROM belegt wie bei 1571.

    Ja, aber da ist nur $FF drin ... also nix.
    Hatte ich mir angeschaut...

    Zur Lösung dieses Problems wurden viele Vorschläge gemacht, aber die drehten sich meist um das Hin und Her kleiner bedruckter Papierscheinchen,
    und das ist einfach drollig, weil es im großen und ganzen ja nicht die kleinen bedruckten Papierscheinchen waren, die sich unglücklich fühlten.
    Und so blieb das Problem bestehen. Vielen Leuten ging es schlecht, den meisten sogar miserabel, selbst denen mit Digitaluhren.

  • Wie funktioniert es bei "Most Access II"?

    Es belegt halt separaten Speicher für die Directory und für die Datenspuren. Beim Original Boulder Dash Construction Kit kann man das sehr gut demonstrieren, da neben der GAM-Datei dann alle Caves mit jeweils 2 Blocks einzeln geladen werden. Auch Dolphin DOS liest da bei den maximal zulässigen 48 Caves dann 49 mal Track 18 und anschließend die Spur mit dem Cave bzw. im ungünstigsten Fall auch mal zwei Spuren.
    Da Most Access II aber nun die Directory cached, kann es mehrere Caves, die auf der selben Spur liegen, in einem Rutsch laden, also neben Track 18 benötigt es dafür nur einen weiteren Diskzugriff. Das gesamte Spiel wird folglich fast so schnell geladen, als wäre das ganze Caveset in einer einzigen Datei. Auf einer unbeschleunigten 1541 dauert der Spaß gefühlte 10 Minuten.
    Der Beschleuniger befindet sich auf der Amica Paint-Diskette.

    Dies wäre eine sehr gute Idee.
    Mit DD4 ausgestattetes Laufwerk läuft parallel,weiter LW laufen mit JD (wenn das LW ein JD-ROM hat).
    Somit wäre ein LW super schnell und die Anderen wenigstens schnell.

    So habe ich das noch nicht bedacht. Das setzt natürlich auch ein Hybrid-KERNAL im C64 voraus, um DD und Jiffy vom C64 aus gleichzeitig zu unterstützen. Um das alles unter zu bringen müßte man wohl ein KERNAL mit Bankswitching entwickeln, schätze ich.
    Im Prinzip könnte man die Dolphin-Routinen gleich weglassen und durch Jiffy ersetzen. Man sieht ja am SD2IEC, daß sich das nicht zu verstecken braucht. Mit GCR-Hardware, Trackloader und Directory-Cache bekommt man bestimmt auch ohne Parallelkabel vergleichbare Geschwindigkeiten hin und ist zudem kompatibel zum herkömmlichen JiffyDOS-KERNAL.

  • Ich habe mir mal die Mühe gemacht alles was ich an Speicherbelegungen finden konnte zusammen zu tragen ...


    Files

    Zur Lösung dieses Problems wurden viele Vorschläge gemacht, aber die drehten sich meist um das Hin und Her kleiner bedruckter Papierscheinchen,
    und das ist einfach drollig, weil es im großen und ganzen ja nicht die kleinen bedruckten Papierscheinchen waren, die sich unglücklich fühlten.
    Und so blieb das Problem bestehen. Vielen Leuten ging es schlecht, den meisten sogar miserabel, selbst denen mit Digitaluhren.

  • Wow, sehr schöner Vergleich, aber was nehmt ihr nur immer für Packer, dass 7-zip die nicht auspacken kann...

    Wie die Dateiendung schon sagt: RAR und zwar WinRAR in der aktuellen Version ;)

    Zur Lösung dieses Problems wurden viele Vorschläge gemacht, aber die drehten sich meist um das Hin und Her kleiner bedruckter Papierscheinchen,
    und das ist einfach drollig, weil es im großen und ganzen ja nicht die kleinen bedruckten Papierscheinchen waren, die sich unglücklich fühlten.
    Und so blieb das Problem bestehen. Vielen Leuten ging es schlecht, den meisten sogar miserabel, selbst denen mit Digitaluhren.

  • Wow, sehr schöner Vergleich, aber was nehmt ihr nur immer für Packer, dass 7-zip die nicht auspacken kann...

    Neueste Version von 7-zip? Hatte ich auch mal das Problem bei mir in der Firma. Update auf neueste Version hat das Problem behoben. Bei mir zu Hause arbeite ich übrigens auch mit WinRAR.

  • Ich auch Du hattest wahrscheinlich nur die 1541 Version angeschaut, oder?

    Ja klar ^^ eine 1571er Variante vom DD habe ich nicht ...


    Ich arbeite erst immer in der 1541 und schaue dann, wie es in der 1571 passt :D


    In der 1571 würde sich der Bereich $2000 bis $3FFF anbieten- eigentlich sollte der leer sein.
    Auch wenn der merkwürdige Effekte erzeugt wenn man dort das Board addressiert...


    Den Bereich $2000 bis $3FFF kann man dann natürlich auch bei der 1541 nehmen und die Spiegelungen ausblenden ...

    Zur Lösung dieses Problems wurden viele Vorschläge gemacht, aber die drehten sich meist um das Hin und Her kleiner bedruckter Papierscheinchen,
    und das ist einfach drollig, weil es im großen und ganzen ja nicht die kleinen bedruckten Papierscheinchen waren, die sich unglücklich fühlten.
    Und so blieb das Problem bestehen. Vielen Leuten ging es schlecht, den meisten sogar miserabel, selbst denen mit Digitaluhren.

  • Ist aber auch noch nicht ganz fertig. Z. B. GCR Unterstützung ist z. Zt. nur beim Lesen einsetzbar. Software ist auch noch nicht völlig adaptiert/gründlich getestet.

    Ich vermute mal, dies hier ist bekannt, oder?


    https://www.linusakesson.net/p…ng/gcr-decoding/index.php


    Da habe ich mich gefragt: Ist HW-GCR überhaupt noch notwendig?

    Zur Lösung dieses Problems wurden viele Vorschläge gemacht, aber die drehten sich meist um das Hin und Her kleiner bedruckter Papierscheinchen,
    und das ist einfach drollig, weil es im großen und ganzen ja nicht die kleinen bedruckten Papierscheinchen waren, die sich unglücklich fühlten.
    Und so blieb das Problem bestehen. Vielen Leuten ging es schlecht, den meisten sogar miserabel, selbst denen mit Digitaluhren.