Posts by Claus

    bringt aber nicht wirklich was

    Warum? JiffyDOS macht genau das beim abspeichern und das bringt messbar Geschwindigkeit (zumindest zeigen das Messreihen, die andere schon gemacht haben). Ist ja auch ganz logisch. Beim PC macht man das ja mit herkömmlichen Festplatten auch. Da muss der Kopf nicht so viele Bewegungen machen und das spart Zeit.

    Was macht JiffyDOS denn da genau? Dadurch, dass ja Zeit verbraucht wird, um die Daten von GCR zu decodieren und durch das Nadelöhr serielle Schnittstelle zu quetschen, wird für die CBM-Routinen z.B. ja ein Sektor-Interleave von 10 verwendet (siehe z.B. hier). Dadurch fallen Trackwechsel nicht so stark ins Gewicht wie man meinen würde. Natürlich ist es aber auch nicht ideal, wenn Sektoren sich abwechselnd auf Track 1 und Track 35 befnden :D.


    Das Programm von mist64 bringt nichts, wie er ja selber schreibt:


    Quote

    For simplicity, we are just filling the disk linearly, starting with track 1, and not using an interleave. This doesn’t make the defragmenter very useful, because the disk might actually read more slowly after this, but it makes for a very clean visualization!

    Eine simple Methode zu defragmentieren wäre, alle Files mit cc1541 zu extrahieren und in ein neues Disk-Image zu schreiben. Geht aber natürlich nicht so gut, wenn das Directory irgendwie speziell ist (mit Directory Art etc.).

    Schau doch mal stichprobenartig in alles was irgendwie Sektor 0, 2 oder 3 heisst.

    Hm, das unten zeigt cc1541 an. Danach scheinen die Sektoren 0, 2 und 3 tatsächlich nicht verwendet zu sein.



    EDIT: Moment, ich bin nicht ganz sicher, ob sich cc1541 da doch durch die BAM verwirren lässt. Für "Lehrerkalender" sagt es nämlich andererseits:


    Code
    1. 19/10 40 (0x01 0x01:0x40) "LEHRERKALENDER" (SL: 11)
    2. 19/10!.19/00 19/11!.19/01 19/12!.19/02 19/13!.19/03 19/14!.19/04
    3. 19/15!.19/05 19/16!.19/06 19/17!.19/07 19/18!.19/08 !19/09 -20/00 !
    4. 20/10!.20/01 !20/11!.20/02 !20/12!.20/03 !20/13!.20/04 !20/14!.20/05 !
    5. 20/15!.20/06 !20/16!.20/07 !20/17!.20/08 !20/18!.20/09 -21/00 !21/10

    Das ist natürlich nichtmal entfernt "normal", und übrigens bei allen drei Images identisch. Natürlich ist das manuell so gemacht worden, deswegen ja auch das "1984 blocks free" bei allen dreien. Mir fällt aber kein Grund dafür ein (oder auf), ein "originelles Muster" vermag ich jetzt auch nicht zu erkennen. Oder ich übersehe irgendwas.

    Zumindest werden die als frei markierten Blocks auch tatsächlich nicht von den Dateien verwendet (dafür sind jede Menge Blocks als besetzt markiert, die nicht verwendet werden).

    Der Vice- Emulator auf dem (New) 3DS emuliert das blinken und das rattern der Floppy. Und man hat den unteren Bildschirm komplett für die Anzeige der Tastatur oder als Maus-/ Koalapad. Für mich der beste Emulator.

    tilobyte Interessant, gut zu wissen, dass dies zumindest schon auf einem Handheld-Emu realisiert wurde, allerdings stehen Desktop PC User dann immer noch am 'Schlauch', trotzdem danke für die Info.

    Die Lösung ist doch naheliegend! Lad dir einen 3DS Emulator runter!

    Jaaa, aber emuliert der dann die 3DS-LED mit der Scroll-Lock-LED? :P

    Der beste Weg ist in diesem Fall, einfach zur Laufzeit die Daten an die gewünschte Position zu verschieben. Also Deine Music direkt hinter den BG-Bereich zu tun, und dann beim Start Deines Programms von da nach $c000 zu kopieren.

    Nein, wie mc71 schon sagt: ein File entspricht auf dem Cevi einem kontinuierlichen Speicherbereich. BSS irgendwo in der Mitte würde nur gehen, wenn man eine virtuelle Speicherverwaltung o.ä. hätte, die virtuelle Speicheradressen beliebig den realen Adressen zuordnet. So modernes Teufelszeugs ist dem Cevi fremd :D.

    Ja, das ist so. Es ist aber auch durchaus üblich, wenn Dinge an bestimmten Stellen im Speicher landen sollen, diese zur Laufzeit dorthin zu kopieren. Sonst wird das File ja unnötig groß (wobei ein Packer das wiederum vermeidet).

    Das Problem ist, dass Du alles in einem Outputfile haben willst, aber in der Mitte einen Bereich hast, der gar nicht definiert ist und in dem der Linker gar nicht weiß, was er für Daten schreiben soll. Entweder musst Du also dem Linker sagen, was dahin soll (wie Du mit Vergrößern des vorigen Bereichs und setzen von fill getan hast), oder Du hängst das SID direkt hinter den BG-Bereich und kopierst es zur Laufzeit nach $c000.

    Das Timing im Kernal für das serielle Protokoll ist so knapp, dass die längere Badline durch den Spritezugriff zu einem Deadlock führen kann.

    Was hat das serielle Protokoll mit Sprites zu tun? Gibt es dazu irgendwelche Informationen im Internet, die das belegen? Oder ist das so ein Aberglaube wie: "Wenn einem eine schwarze Katze über den Weg läuft, wird man vom Pech verfolgt"?

    Natürlich gibt es dazu offizielle Informationen im Internet, hier zum Beispiel: Laden und Speichern von High Score Tabellen in Assembler - Auf was muss ich achten? ^^

    Interessant, mir war bis gerade gar nicht bewusst, dass Mnemonic tatsächlich Assembly-spezifisch ist. Ich dachte bislang, der Begriff würde auch in anderen Sprachen verwendet...

    Nein natürlich ist er nicht assemblyspezifisch. Aber das wär ja kein Hindernis gewesen. Mnemonik steht einfach für sowas wie Gedächtniskunst. Oder für einen Merkhilfe. Der einzelne Assemblybefehl ist eine einfache Merkhilfe für Opcodes.

    Das war durchaus ernst gemeint, Wikipedia sagt:

    Quote from Wikipedia

    Mnemonic