Hello, Guest the thread was viewed23k times and contains 293 replies

last post from 1570 at the

64er Magazin monatlich online

  • Soweit würde ich nicht gehen. Die sehen nicht komplett aus und ich sehe gerade, sie sind falsch numeriert. 7 -> 8 und 8--> 9 und die echte 7 fehlt ... wenn man man nicht alles 3x prüft, bevor man es achiviert :/

  • Äh, das mit den "1984 Blocks free" ist ja nett, aber warum haben diese Disks denn so ein abgefahrenes BAM Layout?


    Keine Ahnung. Die habe ich vor langer Zeit in einer meiner Jagdphasen mal gefunden, archiviert und jetzt wieder ausgegraben. Mehr kann ich dazu nicht sagen ...

    Die 1984 blocks free fand ich auch lustig. Da hat sich jemand die Mühe gemacht, das Jahr zu verewigen. Aber was meinst du mit "abgefahrenem BAM Layout?

  • Aber was meinst du mit "abgefahrenem BAM Layout?

    Damit meine ich das hier:


    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.

  • 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).

  • 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
  • Hm, das unten zeigt cc1541 an. Danach scheinen die Sektoren 0, 2 und 3 tatsächlich nicht verwendet zu sein.

    Also, zumindest in den gängigen Tracks nah an Track 18 berühren etliche File Chains der per Directory enthaltenen Dateien definitiv viele als "leer" markierte Sektoren (0,2,3). Allerdings scheint in den (fälschlich) als belegt markierten Sektoren weiter weg von Track 18 Datenkram zu sein. Vielleicht alte Chains, könnte man mal versuchen zu recovern.

  • Tolle Sache mit den Heften. Und schön, dass hier viele die Programme abschreiben. Will mich da auch bald gerne beteiligen.


    Frage zu den Cursortasten in Fahrsimulator. Ist das normal mit den Pfeiltasten am PC , dass am c64 Cursor-rechts im VICE passt, aber Cursor-links im VICE eigentlich Pfeil runter ist ?


    Kann man das einstellen/umstellen ? Ist das ein Fehler im Programm von Fahrsimulator ? Ich erinnere mich dunkel, dass ich das mit den Pfeiltasten hier irgendwo im Forum schon mal gelesen hatte.

  • Frage zu den Cursortasten in Fahrsimulator. Ist das normal mit den Pfeiltasten am PC , dass am c64 Cursor-rechts im VICE passt, aber Cursor-links im VICE eigentlich Pfeil runter ist ?


    Kann man das einstellen/umstellen ?

    Du kannst die Keymaps (*.vkm) bei VICE problemlos mit jedem Texteditor öffnen und bearbeiten.

  • Frage zu den Cursortasten in Fahrsimulator. Ist das normal mit den Pfeiltasten am PC , dass am c64 Cursor-rechts im VICE passt, aber Cursor-links im VICE eigentlich Pfeil runter ist ?

    Ja, natürlich ist das normal, die PC-Tastatur hat 4 Cursor-Tasten und der C64 nunmal nur zwei (wo die andere Richtung bei betätigung von "Shift" erreicht wird.

    Das funktioniert auch am PC, denn wenn Du "Shift + Cursor rechts" drückst, dann geht der Cursor nach links, ganau so ist es mit Cursor nach unten, wenn du dabei Shift drückst geht der Cursor nach oben.

  • 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.

  • 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.).