Hallo Besucher, der Thread wurde 9,1k mal aufgerufen und enthält 29 Antworten

letzter Beitrag von Chol am

Gotek für C64

    Da die 1541 (auch 1570/71) ein ganz anderes Interface besitzt wird das wohl schwierig.
    Die Köpfe werden z.B. mit Analogsignalen angesteuert. Das Gotek hat ein digitales Interface.


    Bei einer 1581 sollte das machbar sein, aber wer wird schon eine 1581 schlachten?
    Ich weiss nicht ob es dafür einen Markt gibt. Also 1581 mit defekten Laufwerken.

    Es geht nicht!!!


    Der Gotek erwartet ein Shugart-Interface, mit Signalen wie Read Data, Write Data, Step in/out, Track 0, Head, Index, Motor-On usw. Das sind alles TTL-Digitalsignale. Und die Rohdaten werden als MFM-Code ausgegeben, und NICHT als GCR.


    In der 1541 das Laufwerk hat Anschlüsse für analoge Motoren, sprich vier Anschlüsse alleine für den Step-Motor, mehrere für den Drehmotor, mehrere für die Spulen im Lesekopf, KEIN Index, Kein Track 0, usw. Das Laufwerk ist eigentlich nur eine Mechanik, die ganze Umsetzung auf Shugart fehlt beim Commodore-Laufwerk.


    Wir hatten genau das selbe Thema neulich zur 1571. Es ist das selbe Thema mit selben Diskussionsausgang! Damals habe ich auch "Es geht nicht!" geschrieben, und es kam ein Rattenschwanz an weiteren Diskussionen, und am Ende einigte man sich auf "Es geht nicht."


    Wollen wir das selbe dann auch noch für die großen CBM-Floppys, für die SDF1001, die VC-1540, die 1551, die 1570 durchexcerzieren? Hier schonmal die Antwort: Es geht nicht!

    Zitat

    Da wirst du aber ALLES umbauen müssen. Die Gotek produziert im Original ein MFM-Signal während die 1541 GCR benutzt und das auch noch mit 4 verschiedenen Datenraten abhängig von der aktuellen Spur. Die Programmierung dürfte interessant werden.


    Da gebe ich Dir sofort recht. War aber auch nicht die Frage. Der TE kann es nicht, sonst wird es keinen interessieren. Machbar wäre es aber sicherlich wenig sinnvoll.


    Zitat

    Es geht nicht!!!


    Der Gotek erwartet ein Shugart-Interface, mit Signalen wie Read Data, Write Data, Step in/out, Track 0, Head, Index, Motor-On usw. Das sind alles TTL-Digitalsignale. Und die Rohdaten werden als MFM-Code ausgegeben, und NICHT als GCR.


    In der 1541 das Laufwerk hat Anschlüsse für analoge Motoren, sprich vier Anschlüsse alleine für den Step-Motor, mehrere für den Drehmotor, mehrere für die Spulen im Lesekopf, KEIN Index, Kein Track 0, usw. Das Laufwerk ist eigentlich nur eine Mechanik, die ganze Umsetzung auf Shugart fehlt beim Commodore-Laufwerk.


    Große Worte! Du verkennst aber etwas, bzw. stellst es genau falsch herum dar. Natürlich hat die 1541 kein Shugart Interface. Aber ihr fehlt dazu nichts, sondern sie hat etwas zuviel. Die digitalen Signale sind sehr wohl vorhanden, aber werden direkt auf der 1541 Platine weiter in analoge Signale umgesetzt. Was hindert nun jemanden daran, diese digitalen Signale abzugreifen und auf einen Shugart Bus zu legen?


    Die Steppersignale liegen als 2 Bit kodierte Information vor, diese kann man in das DIR/STEP Signal wandeln, oder gleich im 1541 ROM entsprechend ausgeben. Track 0 ist ein Ausgang des Laufwerks und das wird sich nicht stören, wenn das nicht beachtet wird. Gleiches gilt für INDEX. HEAD legt man auf festen Pegel für eine einseitige Ansteuerung. Usw.


    Du hast die großen CBM Floppies angesprochen. Genau dort ist fast eine Shugart artige Verbindung zwischen Digitalplatine und Analogplatine vorhanden. Da muß man nicht viel ändern.


    Wenn du es nun noch nicht glaubst, schau in den Schaltplan der MSD-SD1 und MSD-SD2. Das sind 1541/2031 bzw. 4040 kompatible Laufwerke mit Shugart Mechaniken drin von TEC. Dann vergleiche den mit der 1541 und du weisst, wo du eingreifen kannst.

    Zitat von x1541

    Große Worte! Du verkennst aber etwas, bzw. stellst es genau falsch herum dar.


    Daß man sich die Shugart-Signale ganz bequem auf der Floppyplatine zusammenklauben kann hatte ich vor geraumer Zeit schonmal versucht ihm anhand der 1571 klarzumachen- vergeblich...


    ...und natürlich hat das Gotek (nicht Gortek; das war ein Roboter aus einem Lernspiel für den VC20...) keinerlei Ahnung von MFM oder GCR. Das geschieht alles in Software, die man halt neu schreiben müßte- aber einerseits ist der Quelltext der Amiga-spezifischen Software nicht zugänglich, und zweitens gibts mit 1541U und Chameleon deutlich kompaktere Lösungen für das Problem.


    (hat eigentlich mal jemand überschlagen, wie schnell ein ARM zu takten wäre, damit er zyklen-genaue 6502-Emulation und Ringpuffer-Verwaltung schafft- so als aller-unterste Grenze, ab der es sich überhaupt lohnt über eine 'ARM-1541' nachzudenken?

    Zitat von mc71

    hat eigentlich mal jemand überschlagen, wie schnell ein ARM zu takten wäre, damit er zyklen-genaue 6502-Emulation und Ringpuffer-Verwaltung schafft


    Das solltest Du evtl. Skoe und Enthusi fragen. Die hatten mal mit soetwas angefangen:
    http://www.forum64.de/wbb3/boa…t-zum-experiment-open1541
    http://www.xcore.com/projects/open1541

    Hallo,


    ich habe hier irgendwie keine richtig lesbaren Schaltplan der 1541 zur Hand.
    Mir spukte beim zusammelöten eines SD2IEC folgender Gedanke durch den Kopf:


    1541-Platine nehmen. Motor On/Off, Steppersignale, R/W an den Atmel, Schreib-/Lesedaten möglichst weit vorn abgreifen (müßten vom PortA der VIA sein?).
    Der AVR muß das auswerten, die Steppersignale mitzählen und entsprechend die aktuelle Spur feststellen. Den ersten Sektor dazu dann im D64-File suchen.
    Dann GCR-codieren (sollte per Tabelle ja kein Problem sein) ,die GCR-Daten der Spur schickt er als Loop los, bis die Floppylogik den gewünschten Sektor gefunden hat.
    Ich habe das Timing noch nicht abgeschätzt, ob ein AVR das schafft


    Das dann als Zusatz in eine 1541 eingebaut, einen (Logik-)Umschalter dazu und man hätte eine 100% kompatibel 1541, entweder von Disk oder von SD.


    Das Laufwerk selbst dreht nie schneller als 300U/min und mehr Daten als (theoretisch) auf eine Spur passen, geht auch nicht.


    Was könnte ich übersehen haben?


    1541 habe ich parat, klasssiche Hardware ist kein Problem, AVR liegen auch rum, die Entwicklungsumgebung müßte ich wohl in Gang bringen, da ist nur das letzte AVR-Studio 4 mit dem letzten WinAVR startklar...


    Außerdem ist mein C etwas bescheiden, ASM liegt mir mehr, auch Z80 oder 6502, auch wenn es sehr lange her ist.
    Und Zeit könnte etwas knapp sein.

    Gruß aus Berlin
    Michael

    Bzgl. Schaltplan, halte dich mal an den der 2031. Der ist sehr gut lesbar, und es ist alles noch diskret ausgeführt, was in der 1541 schon integriert ist. Das fördert das Verständnis :) Das Interface ist natürlich unterschiedlich, aber das sollte zweitrangig sein.


    http://www.zimmers.net/anonftp…rives/old/2031/index.html


    Sonst kann das schon funktionieren. An der VIA 6522 lassen sich ja soweit alle Signale für die Laufwerkssteuerung abgreifen, und die schon parallelen GCR Signale liegen da auch an.


    Kompatibel? Jain, da die .d64 ja einiges an Information nicht hat. Daher gibt es weiter Probleme mit Kopierschutz und co.
    Allerdings sollten zumindest Nachlader und Fastloader kein Problem mehr sein.

    Ich würde so einen Boliden direkt an den VIA-Datenport koppeln, dann braucht man den ganzen Shift-Register-Krempel nicht.


    Für 'normale' Disketten reicht das völlig, soweit ich weiß haben die Original-Routinen keinerlei Time-Out für das Byte-Ready-Signal. Der AVR könnte also (nahezu) beliebig langsam sein. KOmpatibilität wäre allerdings auch nur knapp über dem SD2IEC. Soweit ich weiß sind diverse Kopierschutz-Verfahren aber auf eine passende (und konstante) Datenrate angewiesen. _das_ könnte dann wieder auf dem AVR pusselig werden- nicht weil er zu langsam wäre, sondern weil sich die Übertragungsrate nicht fein genug einstellen läßt..

    Zitat

    Wer will, ich hab einen Schaltplan der zur 1540/41 long board passt. Ist allerdings nicht ganz so schön zu lesen wie der zur 2031.


    1 Datei, 386 KB


    Die hier? ;)


    http://www.zimmers.net/anonftp…new/1541/tech/1541-35.gif


    Gesendet von meinem GT-N5100 mit Tapatalk

    Ja sicher an die CIA, ich konnte nur die Signalnamen und die IC-Bezeichnungen auf dem Plan nur erraten. Was in der 1541 passiert, bekomme ich mit etwas Mühe auch nach den vielen Jahren noch zusammen.
    Datenrate usw. dürfte bei Kopierschutz nicht das wirkliche Problem sein, auch da dreht sich die Disk nicht schneller und es können nicht beliebige Datenraten geschrieben oder gelesen werden als die Hardware mit Taktrückgewinnung, Schieberegister usw. zuläßt.
    Das D64-Format ist für Kopierschutz ja sowieso nicht geeignet.
    Nachlader, eigene Floppy-Speeder, abweichende Formate (Datendisk von Seven Cities of Gold z.B.), REL-Dateien (Superbase64), alles was mit B-R/B-W/M-R/M-W usw. zugreift, würde ohne Änderungen laufen, dafür reicht der Sektorzugriff im D64.
    Wäre also wohl doch um einiges kompatibler und trotzdem wenig Hardwareaufwand bzw. keine Spezialteile nötig.
    Man müßte sich natürlich auch no was einfallen lassen, wie man Images mountet, Dirs auf der Karte wechselt usw.
    Entweder also ein Display an den AVR oder vom 64er aus per Standard-Kommandos einen Sektor von der SD-Karte in den Floppy-Ram holen und ausführen.
    Von da könnte man ja prinzipiell mit dem AVR reden.


    Ich muß wirklich mal das Timing anschauen, ob ein AVR damit klarkommt.
    Außer bei speziellen Kopierschutzverfahren muß die Floppysoftware ja sowieso warten, bis ein Sektor vorbeikommt.
    Das sind bei 300//min mehr als 3ms.
    Spurwechsel dauern auch, da sollte also eigentlich Zeit genug sein, um die Daten auf der SD-Card zu finden.


    Was mir im Moment völlig fehlt, sind die durchschnittlichen und die maximalen Zugriffszeiten auf die SD-Card mit den aktuell benutzten Bibliotheken.


    Ich verfolge den Gedanken zumindest mal weiter...


    Gruß aus Berlin
    Michael

    Zitat

    Ich würde so einen Boliden direkt an den VIA-Datenport koppeln, dann braucht man den ganzen Shift-Register-Krempel nicht.


    Anders würde es ja auch keinen Sinn machen. Das Bit Timing selbst kommt ja bei der 1541 nie an, nur das Byte Timing über Byte Ready.


    Die Datenrate sollte handhabbar sein. Immerhin schafft das auch der 1MHz 6502.


    Um Kopierschutzverfahren zu unterstützen ist sicherlich sehr viel Gehirnschmalz notwendig. Zuerst einmal muß man die passenden Imageformate einlesen und verarbeiten können. Dann die üblichen Tricks umsetzen: Halbspuren, Spursynchronisation, Fat Tracks, Variable Sync Länge, Long Tracks, Variable Datenrate, weak bits usw.