Hello, Guest the thread was called47k times and contains 205 replays

last post from fandenivoldsk at the

FIBR – Der C64 File Browser 1.0 Alpha Download

    Quote from alx

    Ja, standard kernal routinen (oeffnen, lesen, schliessen) aber nicht load, da man dann ja schliesslich keinen lade-balken malen kann. (und bei sd2iec+jiffy scheint das auch keinen signifikanten unterschied zu machen)


    Bei sd2iec und FC3/EXOS macht es einen Unterschied von (grob geschätzt, bin gerade zu faul die Benchmarks rauszusuchen) Faktor 20. Bei FC3+1541 ist es ungefähr Faktor 10. Bei DolphinDos+1541 ist es etwa Faktor 2,7. Bei Jiffy+1581 ist es etwa Faktor 1,5. Bei Jiffy+1541 ist es etwa Faktor 1,5. Bei AR6+1541 ist es etwa Faktor 15. Bei AR6+1581 ist es etwa Faktor 9,8. Bei FSD+1581 (Burstmode-Kernal für den C64) ist es etwa Faktor 5.


    Aber bei so kleinen Unterschieden zieht der User sicherlich den Ladebalken einem schnelleren Ladevorgang vor, oder?

    Quote from alx

    Hi,

    Ja, standard kernal routinen (oeffnen, lesen, schliessen) aber nicht load, da man dann ja schliesslich keinen lade-balken malen kann. (und bei sd2iec+jiffy scheint das auch keinen signifikanten unterschied zu machen)


    Ciao, ALeX.


    Naja auf den Ladebalken kann ich da durchaus verzichten *G*



    Quote from Unseen

    ber bei so kleinen Unterschieden zieht der User sicherlich den Ladebalken einem schnelleren Ladevorgang vor, oder?


    Jaaaaaaaaa sicher *GGGGGGGGGG*



    Chris

    Quote from MOS-Marauder

    Ja, standard kernal routinen (oeffnen, lesen, schliessen) aber nicht load, da man dann ja schliesslich keinen lade-balken malen kann. (und bei sd2iec+jiffy scheint das auch keinen signifikanten unterschied zu machen)


    Da sieht man halt mal die Vorrteile von parallel Speeder zu Jiffy ... :prof:


    Zugegeben, der typische Spieler braucht normal nur Jiffy. :bgdev

    Quote from Unseen

    Aber bei so kleinen Unterschieden zieht der User sicherlich den Ladebalken einem schnelleren Ladevorgang vor, oder?


    Das Verhalten, ob "möglichst schnell ohne Ladebalken" oder "geringfügig langsamer, aber mit erkennbarem Fortschritt" könnte man ja auch einstellbar machen bzw. verschiedene Versionen aus einem Codestamm erstellen.

    Bei der Entwicklung von FIBR haben wir nunmal als Standard die SD2IEC-Firmware von Unseen und Jiffy-DOS vorausgesetzt. Zudem wurde darauf geachtet, dass durch saubere Kernelroutinen FIBR zu anderen Hardwares kompatibel ist. Und bei Jiffy ist der Unterschied mit und ohne Ladebalken nicht besonders groß. Es wird aber nicht ausgeschlossen, dass in Zukunft auch andere Laderoutinen verwendet werden und man sich dann entscheiden kann: Nette Optik oder schnell.


    Es ist nunmal so, dass moderne grafische Oberflächen, die u.a. auch Rückmeldung auf die Eingaben der Benutzer erzeugen (Hervorhebung gedrückter Buttons, Fortschrittsbalken, Wartesymbole) nicht gerade bekannt dafür sind, ein System zu beschleunigen, DOS ohne Windows oder Linux ohne Oberfläche sind nunmal schneller als mit. Wir werden versuchen, einen guten Kompromiss zwischen "User Experience", Usability und Speed zu finden.

    Quote from Retrofan

    Bei der Entwicklung von FIBR haben wir nunmal als Standard die SD2IEC-Firmware von Unseen und Jiffy-DOS vorausgesetzt.


    Das merkt man leider an vielen Stellen. Schonmal versehentlich auf ein echtes Diskettenlaufwerk umgeschaltet in dem zu dem Zeitpunkt eine Diskette mit vielen Dateien eingelegt war, zB mit einer A-Seite einer älteren Magic Disk oder einer 64'er-Heftdisk? Bis das Directory eingelesen ist kann man dank der vielen Seeks gemütlich ein paar Tassen Kaffee trinken.


    Selbst mit einem sd2iec und Jiffy kann das Einlesen des Directories 10-15 Minuten dauern wenn viele Dateien im Verzeichnis liegen und das ist auf sd2iec-Seite nicht brauchbar wegzuoptimieren weil das Leseverhalten eine O(n^2)-Laufzeit erzwingt.

    Quote from Unseen

    Bei FC3+1541 ist es ungefähr Faktor 10.

    Wie kommst Du darauf? Das FC3 beschleunigt LOAD etwa um Faktor 10, aber man muss das FC3-beschleunigte LOAD (etwa 4kB/Sek) mit dem vom FC3 nicht beschleunigten SEQ READ (hm... nicht getestet, vielleicht 200 Bytes/Sek?) vergleichen. Also sieht's noch etwas ärger aus.

    Quote from Diddl

    Da sieht man halt mal die Vorrteile von parallel Speeder zu Jiffy ...

    Das hat weniger mit seriell/parallel als mit "Byte für Byte" gegen "Blocktransfer" zu tun.

    Quote from for(;;)

    Das Verhalten, ob "möglichst schnell ohne Ladebalken" oder "geringfügig langsamer, aber mit erkennbarem Fortschritt" könnte man ja auch einstellbar machen bzw. verschiedene Versionen aus einem Codestamm erstellen.

    Mal im Ernst, mit jedem mäßig brauchbaren Speeder werden 202 Blöcke in maximal 13 Sekunden geladen, und dabei rattert die Floppy etwa alle 20 Blocks beim Trackwechsel. Wer da noch eine Fortschrittsanzeige, eine animierte Sanduhr oder ähnliches braucht, ist beim C64 einfach falsch.

    Quote from 1570

    Wie kommst Du darauf? Das FC3 beschleunigt LOAD etwa um Faktor 10, aber man muss das FC3-beschleunigte LOAD (etwa 4kB/Sek) mit dem vom FC3 nicht beschleunigten SEQ READ (hm... nicht getestet, vielleicht 200 Bytes/Sek?) vergleichen. Also sieht's noch etwas ärger aus.


    Ich habe einfach den Wert für LOAD und "SEQ lesen" aus den hier rumliegenden Notizen zum 64'er-Floppy-Benchmark verglichen, für FC3 und EXOS ist letzteres beides Faktor 1.00 und ersteres Faktor 9.07 (FC3) bzw. 11.04 (EXOS). Da beide einen sehr ähnlichen Speedercode verwenden habe ich das einfach zu 10 gemittelt.


    Einfach den Wert für SEQ lesen an dieser Stelle als Vergleichsfaktor heranzuziehen scheint mir gerechtfertigt, da sowohl FIBR als auch der Benchmark für jedes Byte einen Kernalaufruf machen, die Geschwindigkeit sollte für beide ungefähr die gleiche sein. Wahrscheinlich ist dieser Vergleich sogar zugunsten von FIBR, da der Benchmark die Bytes nur wegwerfen muss und FIBR die Daten speichert und gelegentlich den Balken aktualisiert.

    Quote

    Zugegeben, der typische Spieler braucht normal nur Jiffy.


    wo dieser mythos herkommt würde ich echt gerne wissen.... imho ist *grade* der typische gamer mit einem cartridge das LOAD beschleunigt (und das in der regel deutlich mehr als jiffydos es tut) vollkommen ausreichend ausgerüstet. und löten muss er auch nicht.

    Quote from sauhund

    wo dieser mythos herkommt würde ich echt gerne wissen.... imho ist *grade* der typische gamer mit einem cartridge das LOAD beschleunigt (und das in der regel deutlich mehr als jiffydos es tut) vollkommen ausreichend ausgerüstet. und löten muss er auch nicht.

    Genau und die Kompatiblitaet der von dir genannten Cardridge verschweigen wir mal schnell...... Guten Morgen der Herr ....

    Quote

    Genau und die Kompatiblitaet der von dir genannten Cardridge verschweigen wir mal schnell.


    ja immer dieser unsinn mit der angeblich nicht vorhandenen kompatibilität.... erklär doch mal wo das problem ist bei nem cartridge.


    1. beschleunigtes load per cartridge geht IMMER.
    2. starten des geladenen spiels geht spätestens nach einem "kill" IMMER (und die sachen die "kill" brauchen dürften auch bei einem kernal-replacement rumspinnen)
    3. wenn das spiel einmal läuft werden in 99% aller fälle sowieso vom spiel eigene laderoutinen benutzt. ob an der stelle also weiterhin irgendwas beschleunigt wird ist fast immer *egal*. funktionieren tut es *IMMER*


    wo ist jetzt der teil wo das cartridge für den durchschnittsgamer ein kompatibilitätsproblem darstellt?

    Quote

    passt jetzt nicht ganz zum thema, aber seh ich das richtig, dass die FC3 in sachen kompatibilität hinter jiffy liegt?


    das kommt ganz drauf an wie du kompatibilität definierst. fc3 und ar beschleunigen halt nur "load" und "save". und da die vektoren nur im ram umgebogen werden ist nach einem i/o reset schluss mit beschleunigung. was aber beides, wie oben erwähnt, wenig bis keine bedeutung hat wenn du einfach nur zocken willst :)

    Quote from Unseen

    Selbst mit einem sd2iec und Jiffy kann das Einlesen des Directories 10-15 Minuten dauern wenn viele Dateien im Verzeichnis liegen und das ist auf sd2iec-Seite nicht brauchbar wegzuoptimieren weil das Leseverhalten eine O(n^2)-Laufzeit erzwingt.


    Ich weiß ja nicht, was ihr immer so in eure Verzeichnisse packt. Ist es denn zu viel verlangt, von Nutzern eines Rechners, der bislang 160 KB-Laufwerke als Standard kannte, etwas weniger als 250 Dateien in ein Verzeichnis zu packen? Ich habe auf meiner SD-Karte 2 Ordner mit jeweils ca. 150 Unterordnern und M2Is und da braucht FIBR 5 - 10 Sekunden, bis das Verzeichnis angezeigt wird. Innerhalb dieser dieser Verzeichnisse liegen meist bis zu 50 Dateien und da braucht FIBR auch nicht länger. Wenn man natürlich immer 253 PRGs in ein Verzeichnis packt, bei denen FIBR die Startadresse ermitteln möchte, kann das schon mal dauern. Wahrscheinlich werden wir die Art und Weise, wie FIBR auf Verzeichnisse zugreift, zumindest für echte Floppylaufwerke verändern, damit die Geschwindigkeit nicht zu sehr leidet.


    Ihr erwischt FIBR jetzt in einer etwas unglücklichen Phase. Wir hatten uns seinerzeit einem anderen Projekt zugewandt, weil wir da gerade gute Voraussetzungen für einen Start hatten (Ergebnisse vom Community Colors Projekt waren Voraussetzung für unseren Grafikkonverter). Da wir ohnehin nur wenig Rückmeldung zu FIBR hatten, sahen wir kein Eile, das Projekt fertig zu stellen. Jetzt müssen halt alle warten, bis wir wieder Zeit haben.

    Quote from sauhund

    ja immer dieser unsinn mit der angeblich nicht vorhandenen kompatibilität.... erklär doch mal wo das problem ist bei nem cartridge.

    Ace wird's doch um seine CMD-Laufwerke gehen. Mit denen hat er mit einem Modul wie dem FC3 oder AR eben verloren, was aber weniger ein Fehler der Module ist.


    Im Zusammenhang mit neueren Laufwerken (bei denen man eh' Software benutzen muss, die Kernal-Routinen benutzen) ist Jiffy schon geschickter als ein Steckmodul, weil dann auch Nachlader beschleunigt werden.


    Wenn man eine 1541 mit ungepatchten Spielen (mit eigenen Schnellladern) benutzt, langt auch ein Steckmodul wie das AR, das wie Sauhund schon sagte beim Laden von Onefilern auch deutlich schneller ist (AR: 15fach, Jiffy: 6fach). Davon abgesehen bietet das FC3 oder das AR auch einen Haufen andere Funktionen, die der Jiffy-Kernal nicht hat.

    Quote

    Im Zusammenhang mit neueren Laufwerken (bei denen man eh' Software benutzen muss, die Kernal-Routinen benutzen) ist Jiffy schon geschickter als ein Steckmodul, weil dann auch Nachlader beschleunigt werden.


    das ist klar... allerdings ist nur ein verschwindend geringer anteil spiele derartig umgepatcht :) und viel wichtiger: der durchschnittsgamer hat keine obskuren laufwerke :)