was ich nur nicht verstehe , warum es keine schnittstelle gibt, die dem c64 ein laufwerk vorgaukelt was exakt dem original entspricht. warum muss es da immer software inkompatibilitäten geben ?
Weil es nicht reicht, nur die Schnittstelle nachzubilden - das komplette Laufwerk inklusive des dort laufenden Prozessors muss in Echtzeit nachgebildet werden, weil die inkompatiblen C64-Programme eigenen Code auf dem Laufwerksprozessor ausführen wollen. Wieso?
Zitatein 1541 z.b. kommuniziert mit dem c64 auf eine festgelegte art und weise
...beispielsweise um ein eigenes Kommunikationsprotokoll zwischen C64 und Laufwerk zu verwenden, welches die Daten schneller übertragen kann als das Commodore-Protokoll. Oder zu überprüfen, ob auf der eingelegten Diskette alle Merkmale des vom Hersteller aufgebrachten Kopierschutzes vorhanden sind, d.h. ob die Diskette ein Orginal ist.
Zitatwarum setzt man das nicht einfach mit der firmware so um und dann ist es für den c64 wie wenn da tatsächlich ein floppy dranhängt. nur ohne schreib-rechte- oder befehle bei einem cdrom laufwerk. der atmega sollte doch sowas problemlos simulieren können.
in der heutigen zeit !!!
Wenn die C64-Software tatsächlich nur den normalen Befehlssatz des Diskettenlaufwerks verwendet und keinen eigenen Code auf dem Prozessor der 1541 ausführen will, dann funktioniert das mit Lösungen wie sd2iec (welches unter anderem auf einem ATmega laufen kann) tatsächlich ziemlich gut. Nur reicht das eben nicht wenn ein C64-Programm mehr als das machen will.
Zitatich möchte ein IDE oder SATA CD-Rom/DVD-Rom Laufwerk über den IEC Bus mit dem Commodore C64 verbinden.
Wozu? CDs sind unhandlich, kratzergefährdet, nur lästig beschreibbar und danach nicht änderbar und haben eine aus heutiger Sicht ziemlich kleine Kapazität. SD-Karten sind billig, leicht beschreibbar, änderbar und inzwischen kaum noch in Grössen aufzutreiben, die weniger Kapazität als eine CD bieten würden.