Programm zum Speichern in Spur 18.

  • Programm zum Speichern in Spur 18.

    Hallo,

    Weiß jemand, ob es ein Programm gibt, dass automatisch eine Datei in den unbenutzten Sektoren der Spur 18 kann speichern? (Daß es daher nicht notwendig ist, mit einen Hexeditor der BAM manuell zu modifizieren.)
  • Davon abgesehen kann der Speeder S-Jiffydos das. Wobei er IMHO Track 18 nur nutzt, wenn woanders nichts frei ist und die entsprechende Option eingeschaltet ist.
    Müsste aber nachschauen, wann er wirklich Track 18 nutzt...
    ---
    Meine Github-Projekte: github.com/markusC64/
    1541 Ultimate II Firmware Releases: github.com/markusC64/1541ultimate2/releases
    1541 Ultimate II Update instructions: github.com/markusC64/1541ultimate2/wiki
  • dmantione schrieb:

    Ich hab "+ 17 blocks frei" gefunden. Es funktioneert. Nachteil ist, dass es keine Kontrolle gibt, welche Datei in Spur 18 verschoben wird, es wählt Dateien selbst aus. Aber es ist sicher ein Gutes Program um mit zu beginnen.
    Das ist die maximal erreichbare Blockanzahl bei BAM (1 Sektor) und bis zu 8 Directory-Einträgen (1 Sektor). Man muss nur ab Sektor 0 in Spur 18 dem Directory folgen (Block-Verkettung), dahinter ist dann noch Platz bis einschließlich Sektor 19.
    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
  • LogicDeLuxe schrieb:

    ZeroZero schrieb:

    Vorsichtig: 64copy ist genial, funktioniert aber nicht mehr mit 64-Bit-Versionen von M$-Windows!
    Für solche Fälle gibt es DOSbox, und das sogar nicht nur unter Windows. Damit läuft bei mir 64copy seit Jahren ohne Probleme. Auf lange Dateinamen (außerhalb der Images) muß man allerdings verzichten.
    Auf DOSBox hatte ich bereits selbst hingewiesen. Aber die besten Eigenschaften von 64Copy gehen ohne OS-Unterstützung leider flöten, z. B. die direkte Bearbeitung von D64s an jeder beliebigen Stelle im Dateisystem u. ä.

    Wenn man dieses allerdings nicht jahrelang gewöhnt war (wie ich) wird man das auch nicht vermissen. Bei mir hat das allerdings dazu geführt, das ich 64Copy mittlerweile monatelang nicht mehr verwendet habe, zumal Peter derzeit und auch in nächster Zukunft daran nicht mehr arbeiten wird. Ich habe ihm bereits vor Jahren angeboten, mit ihm zusammen einen Port für Windows (oder sogar plattformoffen) zu entwickeln, aber er möchte die Sourcen nicht aus der Hand geben.

    Sein Disassembler wäre der beste, den es gibt, wenn der nicht permanent mit Speicherproblemen unvorhersehbare Probleme erzeugen würde.

    Seine letzte Version 4.45 ist massgeblich mit meiner Mitarbeit (Feedback und reproduzierbare Testszenarien für Bugs) entstanden.


    E D I T

    Meine Arbeit an BT1 für C64 hier wurde hauptsächlich mit 64Copy erstellt.
    Life's good! :thumbup:
  • ZeroZero schrieb:

    Wenn man dieses allerdings nicht jahrelang gewöhnt war (wie ich) wird man das auch nicht vermissen. Bei mir hat das allerdings dazu geführt, das ich 64Copy mittlerweile monatelang nicht mehr verwendet habe, zumal Peter derzeit und auch in nächster Zukunft daran nicht mehr arbeiten wird. Ich habe ihm bereits vor Jahren angeboten, mit ihm zusammen einen Port für Windows (oder sogar plattformoffen) zu entwickeln, aber er möchte die Sourcen nicht aus der Hand geben.

    Sein Disassembler wäre der beste, den es gibt, wenn der nicht permanent mit Speicherproblemen unvorhersehbare Probleme erzeugen würde.

    Seine letzte Version 4.45 ist massgeblich mit meiner Mitarbeit (Feedback und reproduzierbare Testszenarien für Bugs) entstanden.
    Kommt mir alles seeehr vertraut vor. :) So Ende der 90er ist auch von meinerseits so einiges an Mitarbeit/Tests/Anregungen in 64Copy und die Formats-Texte eingeflossen. Aber leider herrscht ja weitgehend matte Funkstille. Ist zwar kein Beinbruch, aber ist halt schade um das brachliegende Potential. Dennoch muss man sagen, dass 64Copy nach wie vor das Schweizer Messer schlechthin ist wenn's um die Bearbeitung von Disk Images geht. DirMaster ist gut und hat die Stärke der Systemintegration (unter Windows), aber denkt an sehr vielen Stellen zu kurz und ist natürlich durchsetzt von tonnenweise üblen Bugs.