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)

    Also ... nebenbei mein 1. Post (Sry dafür ..)


    Folgende Sache:
    Ich bin Bekennender Basic-Schreiberling (Egal ob 2.0 ;-) oder Q)


    Es gibt ja nun SOOO viele Disk-Images und die 1541 kann man ja wunderbar als Block-Write Maschine missbrauchen (Sry für die Wortwahl)


    Und dooferweise kann ich mein Lieblingsspiel (Katakis) nicht mehr spielen da 2 Disks nun Read-Errors ( :-( ) haben.


    Lange Rede Kurzer Unsinn:


    Die X1541-Kabel gibts ja nun zu genüge (allerdings bin ich eher der Typ der das Rad neu Erfindet).


    Also Kurz und knapp:
    Ich will mit meinem Arduino (Ich weiss .... ;-) ) an den Userport um Disk-Images so auf meine 1541-I oder meine 1541-II Zu bringen ...
    Ich habe auch schon versucht direkt mit IEC auf PC mit arduino zu Arbeiten aber das ist dann doch eher nix für mich deswegen gehen meine Gedanken eher zum Nullmodemkabel über den Userport zur Floppy (Ich hoffe ihr wisst was ich meine) ...


    Klar alles andere ist einfacher ... aber mir gehts um die Sache an sich ...
    Auch wenn das heisst das ich 2 Zwei Programme Schreiben muss (eines das die D64 Dateien "Auseinandernimmt" -> PCarbeit ... Hat genug Leistung -> und eins Für den Cevi was den "Schreibkram" übernimmt)
    Der Arduino soll nur die Wandlung USB-> Serial 5V Übernehmen.


    Meine Frage ist nun nur ... Wo finde ich DTS,CTS,CLK,DATA am Userport ?
    So das ich auch "Relativ" Lockerflockig Daten schubsen kann ...


    Alles andere Ist Software

    Ein kleines Adventure: Benutze Brain 2.0 mit https://www.c64-wiki.de/wiki/RS-232 und http://www.ebay.de/itm/USB-to-…81dc0f:g:P94AAOSwa-dWoyr7

    Zweiteres hab ich schon ... Das Programm in Atmel(Arduino) übernimmt die Stupide Arbeit.


    Das erstere ist nur eine Frage der Pinbelegung vom Userport,ich bin der Meinung das man dessen RS232C Unter Basic bequem ansteuern konnte ...


    http://www.hardwarebook.info/C64_RS232_User_Port


    Ich halte mich hieran ...


    Damit habe ich auch gefunden Device 2 bei OPEN 1,2,X



    Marcus

    Nein das nicht ,jedoch bin ich nebenher noch am Recherchieren ..


    Ich habe erst seit Kurzem wieder einen Cevi (Auf meinem Ersten Schrieb ich eine fast vollständige Textverarbeitung mit Druckerbefehlen für einen Seikosha VC20 ... wer ihn noch kennt ,-) )


    Also ich bin dran ... wenns Interessiert :-)


    Marcus

    Ich würde vom PC zum Userport eher eine parallele Übertragung über PORTB von CIA2 machen. Die Daten müsstest du so oder so vom C64 zu Fuß auf Diskette schreiben, direkt kommst du da nicht an den IEC-Bus.


    Ich weise mal auf mein Projekt xlink hin, damit ließe sich ein solches Projekt auf jeden Fall umsetzen. Es lassen sich Daten mit bis zu 20Kb/s über USB oder auch ein einfaches Parallelportkabel zum Userport schieben, eine generische C-Bibliothek sowie ein angepasster Kernal sind auch vorhanden, auf deren Basis sich ein client/server paar relativ einfach realisieren ließe.


    Aber natürlich gibt es da auch viele andere Möglichkeiten...

    Paralell Über den PortB ... da dachte ich auch schon dran.
    Problem an der gesamten Geschichte da ist da kommen wir in die Gegend ASM mit Interrupt,kann man machen ... muss man aber nicht.


    Ich habe zwar schon in ASM Reingeschnuppert aber dafür reichts nicht um im Interrupt ein Polling zu machen und eventuell noch einen Puffer zu Verwalten ... sry dafür.


    Marcus

    Was mir an dieser Stelle noch einfällt ist das Problem mit der gleichzeitigen Nutzung der rs232 und des iec Bus.


    http://www.lemon64.com/forum/viewtopic.php?t=63643


    Danach kannst Du nicht gleichzeitig rs232 und iec Bus nutzen.


    Was cool wäre, wäre Arduino Code für den iec Bus. Den könnte ich auch gebrauchen.

    Wenn mir Jemand hilft das Timing und den GENAUEN Ablauf zu erörtern Bin gern bereit den weg zu gehen,alles was ich finde ist (für mich...) zu diffus



    Mal so gesehen ... Fakt ist das der IEC in SW "Nachgebaut" werden muss .... Das allein ist ja schon nicht unbedingt ein Sonntag-Nachmittags-Spaziergang..



    Marcus

    Zitat von Cevijunkie

    Fakt ist das der IEC in SW "Nachgebaut" werden muss

    Wieso das denn jetzt? Bisher las sich das hier wie "Diskimage blockweise per RS232 empfangen und dann auf Disk schreiben" - das ist in Basic2 langsam, aber machbar.

    Die Anfrage kam doch gerade ... per Atmel direkt per IEC auf Floppy schieben.
    Deswegen müsste der IEC in SW Nachgebaut werden.


    Das umgeh ich ja über die RS232C ... auch wenn ich dann nur wie die alten Kopierprogramme erst "Holen" und dann Schreiben kann.


    Muss ich sehen inwieweit das der Cevi kann.


    Im Schlimmsten Fall muss mit einem Grossen Array arbeiten.
    Nicht schön,aber besser als die Rs232 ständig zu schliessen und neu zu Öffnen.


    Wenn ich nicht simultan Arbeiten wie weiter oben geschrieben dann halt Halt Blockweise alternierend.
    Worauf es wohl hinausläuft.
    Da ja iwie alles zu Fuss ist kommts auf die 2 Zeilen Code nun auch nicht an.


    Ja ein Max232 Würde auch reichen anstatt eines Arduinos. Aber der macht nur RS232 auf TTL ... selbst das bringt nix mehr in Zeiten von USB und Co.


    Marcus

    So ... hab mir noch 2 Gedanken mehr gemacht.


    Der Vice64 kann ja auch über eine USB-Serial Daten Raushauen.
    Das erspart mir wieder Arbeit,dann muss ich nicht das d64-Format Studieren,und ich kann von einer Virtuellen Maschine auf eine Reale Kopieren.
    Das Sendeprogramm steht soweit,und am Arduino brauche ich eigentlich gar nix tun ausser die Seriellen Daten direkt vom Wandler abgreifen (Geht ja Problemlos da 5V)


    Frage dazu:
    Weiss jemand ob im d64-Format auch ein "Kopierschutz" Defininiert werden kann ?


    Nicht das es so abläuft das ich im Endeffekt eine Virtuelle Disk auf eine Reale Disk geschoben habe und sie Trotzdem nicht läuft weil da "War ja mal was" worüber sich ein EMU nicht Aufregt,die Reale Maschine aber schon ... ich hoffe ihr wisst was ich meine ...


    Marcus

    Zitat von Cevijunkie

    Der Vice64 kann ja auch über eine USB-Serial Daten Raushauen.

    Das allerdings nicht sehr gut.


    Zitat von Cevijunkie

    Weiss jemand ob im d64-Format auch ein "Kopierschutz" Defininiert werden kann ?

    Das hängt ganz vom "Kopierschutz" ab und wie das Target damit umgeht bzw. umgehen kann. Ein Kopierschutz ist ja im Grunde immer das Ausnutzen eines technischen Problems oder einer Eigenart bzw. einer technischen Lücke. Im Audiobereich würde man sagen, ein Kopierschutz ist prinzipiell immer erstmal ein Abspielschutz.
    Es gibt zwei Arten von "Eigenarten", die hier und da auch als Kopierschutz eingesetzt wurden, die in einem D64 abgebildet werden können, und die auch korrekt funktionieren wenn korrekt damit umgegangen wird: Extended Tracks (also alles jenseits der Standardgrösse von 35 Tracks), und als fehlerhaft markierte Blöcke. Praktisch alles andere Kopierschutz-artige ist nur in low-level Formaten abbildbar, also G64, NIB & Co, nicht in einem high-level Format wie D64.

    Zitat von GenerationCBM

    Das allerdings nicht sehr gut.


    Okay,Das mit den Extended Tracks ist klar.



    Aber was meinst du mit das der Vice mit der Seriellen nicht gut kann ?
    Das er im Generellen recht "Zickig" ist hab ich schon mitbekommen,weil ich habe mein Programm ja schon Probelaufen lassen,und festgestellt der Vice gern mal ins "Nirvana" schickt.
    Sprich gar nicht erst rausgeht.


    Womit muss ich denn noch rechen ?

    Ein bekanntes Problem bei d64-Files ist, dass sie nicht die echte Disk-ID enthalten müssen: Die zwei oben rechts im Verzeichnis angezeigten Zeichen können nach dem Formatieren beliebig geändert werden, in den Sektorheadern bleibt aber die ursprüngliche, "echte" ID erhalten. Es gibt eine Handvoll Spiele, deren D64-Versionen nur funktionieren, wenn die Disk eine bestimmte ID aufweist.


    Dieses Problem ist aber selten; darum kannst Du Dich kümmern, wenn es so weit ist...

    Zitat von Cevijunkie

    Weiss jemand ob im d64-Format auch ein "Kopierschutz" Defininiert werden kann?

    Erstens: "den" Kopierschutz gibt es nicht.
    Zweitens: *.d64 legt den Inhalt einer Diskette nur auf DOS-Ebene ab. De facto alle Kopierschutzmaßnahmen zielen darauf ab, die Diskette so zu verändern, daß das mit dem Inhalt auf DOS-Ebene nicht nachvollzogen werden kann. Eine Erweiterung des *.d64 Formats sieht noch vor, Lese-Fehler auf einzelnen Blöcken zu faken - damit lassen sich die einfachsten Kopierschutzmaßnahmen aushebeln - es ist aber schon etwas schwieriger, die dann "von Hand" auf einer echten Diskette zu reproduzieren.


    Zitat

    Nicht das es so abläuft das ich im Endeffekt eine Virtuelle Disk auf eine Reale Disk geschoben habe und sie Trotzdem nicht läuft weil da "War ja mal was" worüber sich ein EMU nicht Aufregt,die Reale Maschine aber schon ... ich hoffe ihr wisst was ich meine ...

    Die Emulatoren sind mittlerweile so gut, daß in 99,999% alle Fälle das Verhalten mit der realen Hardware übereinstimmt. Eher kommt es noch vor, daß der Emu rumspackt, weil das Verhalten der realen Maschine noch nicht 100%ig nachvollzogen wurde - der umgekehrte Fall, daß was im Emu geht, auf der Hardware aber nicht, kommt nur dann vor wenn *neu* entwickelte Software im Emulator einige Sachen wie z.B. die Anlaufgeschwindigkeit des realen Floppymotors nicht mit berücksichtigt. Und selbst da hat's in der letzten Zeit deutliche Fortschritte gegeben.


    Im Falle von kopiergeschützten Disks wird man dann zumindest das *.g64 Format hernehmen, wo die Bits einer kompletten Spur mit Sektordaten, Sektorheader, "Rasen", Geschwindigkeit im GCR-Code abgelegt sind. Das dann auf eine Diskette zurückzuschreiben, ist noch mal eine Ecke heftiger.

    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