Hallo Besucher, der Thread wurde 4,1k mal aufgerufen und enthält 34 Antworten

letzter Beitrag von Mac Bacon am

Mal was GAANNZZZ Neues (leider nicht wirklich)

    Zitat von Cevijunkie

    Ja gut ... ich hoffe ich verstehe das jetzt richtig.


    Also mein Plan ist ja,jeweils die Komplette Disk -Sektor für Sektor-,-Track für Track- Rauszuschaufeln,ja ich weiss das Dauert EEEEEEWWWIIIIGGG.
    Sollte das Problem mit der "Disk-ID" nicht Automatisch Gelöst werden weil es wird ja alles mitkopiert -> BAM-> Directory -> die komplette Spur 18 halt.


    Marcus

    Nein, weil die ID in den Sektor-Headern beim Formatieren abgelegt wird. Und die Header werden bei Block-Schreib-Zugriffen *nicht* geändert!

    Nein bei den Block Befehlen (B-R B-W ect.) nicht,das stimmt.


    Bei den User-Befehlen (U1,U2) kannst du selbst mit den Headern Spielen,das geht wohl


    Lt.:http://c64emulator.111mb.de/c64/docu/DieFloppy1541-v4.pdf


    Edit:
    Was ich wohl nicht ändern kann ist das was Dos selbst schreibt (Checksumme als beispiel,2.Byte im Header)
    Gelesen wird bei den Userbefehlen wohl erst ab den Zeigern (3. und 4. Byte) Danach folgt die ID (5. und 6. Byte) für den Nächsten Datenblock (Track und Sektor).
    Geschrieben dann natürlich vice versa ...


    Aber ich schau nochmal ... nicht das ich mich jetzt irre.



    Marcus

    Siehe Seite 98 ebenda:


    Alles klar?



    Du müßtest also eine ganze Spur incl. der Sektorheader neu schreiben - oder, einfacher, vorab die Diskette mit der ID aus dem Dir-Block in der Quell-*.d64 neu formatieren.

    Noch zum Abschluß - für mich gibt's keinen zureichenden Grund, beim Zurückschreiben eines *.d64-Images auf eine echte Disk gleichzeitig einen PC und den C64 zu bemühen.


    Es gibt die Möglichkeit die Floppy direkt an den PC anzuschließen, der PC spricht die Floppy mit den Block-Befehlen an und schreibt so das *.d64 zurück.


    Oder Du hast am C64 neben der Floppy auch noch ein SD2IEC am Start. Dann kannst Du z.B. mit d64trans die *.d64 Datei auf die Diskette kopieren:


    C64 Disketten auf SD-Karte sichern - kann der SD2IEC sowas?

    Ja okay :-)


    Dann hab ich wohl etwas sehr Überflogen.


    Aber alles in allem nichts Unlösbares:


    Muss ich blos einmal in der Directory einmal die ID holen und dann zur Realen Maschine schicken die dann die Floppy Formatiert.


    was mich jetzt nur wundert ist das ich bei einem UserBefehl halt Track und Sektor Geliefert bekomme,und die ID Halt erst danach im Header steht,ich jedoch im Umgekehrten fall ja die Zeiger Verbiegen kann wohin ich will,die Floppy diesem auch brav folgt,nachdem der Block geschrieben ist.
    Jedoch die ID die ja erst NACH den Zeigern kommt nicht ändern kann... naja gut ... dann ist das halt so.


    Okay besser ich weiss es jetzt anstatt dann Stundenlang Debuggen zu müssen weil das was geschrieben wurde, nicht das ist was gelesen wurde.


    Marcus


    Das hatte ich Probiert,hat aber nicht geklappt mit 1541 direkt am PC.
    Aber abgesehen davon das es einfacher gehen KÖNNTE,


    Mir gehts schlicht nicht um Plug and Play ... das kann jeder.


    Und warum nicht den PC (Kann ja auch ein "Ausrangierter" sein) neben einem C64 laufen lassen und eben dem Cevi Futter zuspielen lassen ?


    Sicher gibts so keinen Grund das Rad neu erfinden,aber ICH hab da halt einfach Bock drauf. :-)


    Marcus

    Nochmal ganz genau:


    Im Sektorheader vor der "Nutzlast" des Sektors (also den 256 Bytes) stehen neben der Disk-ID Track und Sektornummer eben jenes Sektors. Das DOS fährt die Spur an, und liest solange auf der Spur, bis es einen Header findet, welcher mit der eingetragenen Track und Sektornummer dem gewünschten Sektor entspricht. Soll der Sektor nun in den Puffer gelesen werden, bleibt der Kopf im Lesemodus. Soll der Sektor jedoch geschrieben werden schaltet das DOS den Kopf in den Schreibmodus um - *nachdem* der Header eben am Kopf vorbeigelaufen ist!


    Im DOS-Dateisystem werden dann die ersten zwei Bytes in den Sektordaten (also wieder in den 256 Bytes) entweder zur Sektorverkettung gebrauchen (Zeiger auf *nächsten* Track/Sektor der Datei) oder als Angabe, wieviele Bytes im letzten Sektor einer Datei tatsächlich in Gebrauch sind. Benutzt man das Dateisystem nicht und schreibt Sektoren direkt, dann kann man auch die ersten zwei Bytes selbst gebrauchen wie man will - man muß lediglich sicherstellen, daß man nur Sektoren nutzt, die das DOS nicht gerade selbst schon in Gebrauch hat.


    Gibt noch einiges an Grundlagen, die Du dir dringend aneignen muß. Kannst dir ja mal d64trans als Beispiel anschauen. :)

    Zitat

    Mir gehts schlicht nicht um Plug and Play ... das kann jeder.

    Weißt Du, wozu Zivilisationen gut sind?


    Damit nicht jeder unbedingt *alle* Erfahrungen selbst machen muß - sondern auf die Erfahrung anderer zurückgreifen kann.


    Eine Erfahrung ist z.B. die, daß, je mehr Geräte Du an so einem Transfer-Prozeß beteiligst es um so komplizierter wird, jede Übertragung sauber hinzubekommen.


    Wenn das mit PC direkt zum Laufwerk nicht klappt, schade. Liegt aber auch daran, daß heutige PCs mit dem gängigen OS das mangels Echtzeitfähigkeit, und Verbot von direkten Zugriffen auf Hardware auch einfach nicht mehr hinbekommen. Mit 'nem ollen PC von vor 2000 ging das noch problemlos.


    Dann eben am C64 von SD2IEC zu Laufwerk. Ist erprobt und läuft. Kannst Du gerne das Rad neu erfinden - aber wie gesagt, bring erstmal die Grundlangen richtig beieinander. Und da hilft nur ausprobieren am Gerät selber. Die Diskussion hier dreht sich ohne konkrete Hardware und Software die darauf läuft (wo man dann Fehler etc. suchen könnte) einfach nur im Kreis!

    Okay.


    Ich dachte die Hardware sei Klar: Ein PC auf dem Vice64 Läuft um eine Virtuelle Diskette Sektorweise Auszulesen um sie Seriell an einen Realen C64 zu Schicken der seinerseits diese Diskette schreibt.
    Der Arduino dazwischen ist quasi nur ein USB->Seriellwandler und hat Softwaretechnisch überhaupt nix zu tun.


    Es ist natürlich super das sich jeder einbringt und IM VORFELD Probleme Aufzeigt die passieren können.
    Die Software zu schreiben Bleibt natürlich an mir hängen.


    Klar kann man das alles wesentlich vereinfachen wenn man das alles an einer Maschine machen Könnte,Octa-Copy und fertig -> als Beispiel
    Kann ich aber nicht.
    Jedoch von vorherein zu sagen "Das gibt nix" oder "Das ist zuviel Arbeit" oder oder ...


    Ich habe halt nur diese Hardware zur verfügung und schau nun was ich draus zaubern kann.

    Also Per se reden wir jetzt von:


    Disk ID(und Name)von der "Virtuellen" Disk Holen und die Reale damit Formatieren.


    Dann kommt schlicht das Sektorweise Auslesen der Virtuellen Disk und die Reale Sektorweise Schreiben -> Ich muss zugeben das ich grade 2 Sachen verhauen hab,ich hatte die Zeiger die vor dem Datenblock stehen mit den Headerdaten verwechselt.


    Sry Dafür
    Marcus

    Zitat von Cevijunkie

    Muss ich blos einmal in der Directory einmal die ID holen und dann zur Realen Maschine schicken die dann die Floppy Formatiert.

    Damit stellst Du sicher, dass die ID in den Sektorheadern die gleiche ist, die auch im Verzeichnis steht. Das heißt aber nicht, dass es die ID ist, die die Software erwartet!


    Ein Beispiel:
    Ein Spiel wird auf einer Disk mit realer ID "XY" ausgeliefert, und weil der Programierer so ein toller Hecht ist, denkt er sich: "Ich frage im Programm die ID ab, und wenn sie nicht XY ist, formatiere ich die Disk. Dem bösen Raubmordkopierer zeig ichs!"
    Anschließend verändert er mit einem Diskmonitor das Verzeichnis so, dass rechts oben statt "XY 2A" (Disk-ID und Formatkennung) "IBETH" (Ich Bin Ein Toller Hecht) angezeigt wird.


    Wird diese Diskette in eine d64-Datei umgewandelt, so geht die echte ID "XY" verloren, da ein d64 keine Sektorheader enthält. Schreibt man das d64 zurück auf eine echte Disk, ist die reale ID entweder zufällig (wenn die Disk vorher formatiert wurde) oder "IB" (wenn das Transfertool die Disk mit der ID aus dem Verzeichnis formatiert).


    Es gilt aber weiterhin: Dieser Fall ist sehr selten...

    Zitat von Cevijunkie

    Aber was meinst du mit das der Vice mit der Seriellen nicht gut kann ?

    Die Verbindung von Vice via OpenCBM, USB-Treiber, USB-Hardware zu einem echten Commodore-Laufwerk ist so ziemlich an jeder Stelle timing-kritisch und insgesamt notorisch sehr kitzlig. Viel versprechen sollte man sich davon nicht, Wunder erwarten schon garnicht. Wer das Rad neu erfinden will kann das meinetwegen gerne tun, aber das ist m.E. keine geeignete Fahrbahn für die Testfahrten...

    Zitat von GenerationCBM

    Die Verbindung von Vice via OpenCBM, USB-Treiber, USB-Hardware zu einem echten Commodore-Laufwerk ist so ziemlich an jeder Stelle timing-kritisch und insgesamt notorisch sehr kitzlig.

    Soweit ich es verstanden habe, geht es nicht um OpenCBM. Mit "seriell" war hier nicht der IEC-Bus, sondern die RS232-Schnittstelle gemeint. Wenn die Baudrate gering genug ist, müsste(tm) das gehen.

    Nein .... Das hab ich nicht vor,um das Timing kümmert sich der Reale C64.


    Das Timing für den Seriellen IEC hab ich mir schon angeschaut. Das ist gewissen Bereichen echt widerlich.
    Im Grunde bau ich ja "Nur" eine Serielle Verbindung von einem Virtuellen C64 zu einem Realen C64 auf.


    @Edit: MacBacon war schneller :-)


    Marcus

    Zitat von Mike

    für mich gibt's keinen zureichenden Grund, beim Zurückschreiben eines *.d64-Images auf eine echte Disk gleichzeitig einen PC und den C64 zu bemühen.

    Ich schreibe zwar sehr selten Images auf Disks - aber wenn, dann mache ich das genau so. :P
    ...allerdings nicht über RS232, sondern was eigenes...