Hallo Besucher, der Thread wurde 198k mal aufgerufen und enthält 1577 Antworten

letzter Beitrag von fook42 am

Laufwerk der 1541 emulieren

  • Hallo,


    vor ein paar Wochen spukte mir eine Überlegung durch den Kopf:
    warum nicht nur das Laufwerk einer 1541 durch eine SD-Card -Lösung ersetzen?
    Die Geschichte wäre theoretisch 100% kompatibel, die Diskette kann sich nicht plötzlich mit anderer Drehzahl drehen, die Bitraten können nicht anders sein, als C= es wollte.


    Dann gab es eine Bemerkung von OlsenG in einem anderen Thread:



    Zum Stand der Dinge: ich will zwischen Original-Laufwerk und SD-Card-Modul umschalten. Das kostet 2 (vermutlich eher 3) 74LS245 o.ä.)
    In der Floppy müssen VIA2 und die CPU gesocklet sein (an der CPU mu nur SO vom Board getrennt und per Leitung zurm VIA2-Pin verbunden werden).


    Das Ding braucht natürlich ein LCD-Display und einen Drehgeber mit Taste als Bedienelemente.
    CPU wird ein AVR ATMega1284P (bei mir auch nur dieser...), weil DIP-Gehäuse und 16k Ram.
    Ich habe mir jetzt erstmal eine SD-Card Bibliothek gesucht, die ich nicht erst nach 3 Monaten Studium verstehe. Display- (2*16 im Momet) und Drehgeber sind dran, alles erstam auf ein Stecjbrett gesteckt, ich hatte diesmal keine Lust, gleich Lochraster zu bemühen.


    Auf der SD-Card Seite baue ich jetzt erstmal nur die minimalren Funktionen zusammen, also die Files aus einem Direktory per Drehgeber anzeigen und mit Tastedruck diese Disk einlegen.
    Vorerst .d64, obwohl .g64 eigentlich Arbeit sparen würde.
    Dieses Handlicng ist völlig unkritsch, die Floppy bekommt vom "Laufwerk" nur mitgeteilt, daß keine Disk drinliegt (bzw. sie merkt das alleine, wenn sie angesprochen wird und weder Sync noch Sektorheader findet).
    Auf SD-Card-Seite muß nach Auswahl des Images der Track 18 gelesen werden, bei .d64 nach GCR codiert und Sync und Sektorheader zusammengebastelt werden.
    Das liegt dann im Ram des AVR (deshalb sind die 16k nötig, dafür gehen schon 8kB drauf) und wenn die Floppy MotorOn setzt, bekommt sie in einem Loop den Track mit den passenden Signalen (Sync, ByteReady usw.) byteweise an die VIA.
    Reagiert werden muß erst wieder, wenn die Floppy entweder den Motor aus macht oder Stepimpulse kommen. Dann müssen jeweis die angefahrenen Trackdaten von der SD-Card in den AVR-Ram gebracht werden und wenn die Floppy dann erwartet, daß Daten kommen, geht es wie oben weiter.
    Das gesammte Timing sieht bisher sehr unkritisch aus, ist je von den mechanischen Parametern des Laufwerkes bestimmt.


    Die Hardware macht mir bis jetzt kein Kopfzerbrechen, außer der Umschaltung ist es nur der Mega1284, SD-Card-Slot, Display und Drehgeber.
    6502 kann ich sowohl programmieren als auch die Romlisting lesen, ich war schon früher immer dicht an der Hardware, deshalb normalerweise auch Assembler bei Bedarf auch mit Takte zählen...


    Wegen der FAT-Routinen ist nun aber C angesagt und das ist nicht unbedingt meine stärkste Seite. Will sagen: ich kann das programmieren, was ich da will, es wird vermutlich für C alles andere als elegant sein und irgendwer wird sicher kommen und mir erklären, daß das nicht ins .c File oder dieses nicht ins .h File gehört.


    Wenn jemand das also interessant findet, sich beteiligen will, kann er das gern machen.
    Schön wäre es natürlich, wenn er eine 1541 zur Verfügung hat, wo CPU und VIA2 gesockelt sind, dann wären da erstmal nur 2 Adapter in der üblichen DIL-Version zu basten, wo divere Leitungen der VIA vom Board getrennt und zum AVR gelegt werden.
    AVR-seitig wäre es schön, wenn er ein 2*16 Display o.ä. verfügbar hätte und einen Drehgeber. Tasten könnte man natürlich auch nehmen, ich möchte aber nicht mit 50 Tastendrücken zu einem File kommen müssen...


    So, ich höre hier jetzt erstmal auf und warte die Reaktionen ab.


    Gruß aus Berlin
    Michael

  • Die Idee ist faszinierend, allein schon weil es so easy ist.


    Es geht beides, D64 und G64. Im Falle von D64 muss man halt die GCR dekodierung pro Track machen.


    Vorallem könnte man Laufwerke verwenden, wo der analog Teil defekt ist und der CPU Teil noch funzt.



    Coole Sache! :thumbsup:

  • Aus meiner Sicht spielt es keine Rolle ob 1541 oder 1541-II.



    Die Software sehe ich da eher unkritisch. Man kann ja anfangen mit einem fixen G64 File, ohne LCD und Image Auswahl. Eigentlich habe ich alle Code Fragmente dafür bereits.


    Das Problem ist viel mehr die Hardware. Da ich zwei linke Hände habe, sind solche Basteleien für mich eher schwierig.

  • Aaahh, da ist der von mir erwartete Thread :)


    Ich hab bzgl. der FAT-Routinen den Vorschlag, dass wir uns einfach beim Arduino bedienen. Die SdFat-Library hat bisher wunderbar funktioniert. Je nachdem, welchen Compiler Du einsetzen willst, muss ich mir halt die entsprechende Toolchain installieren. Die nötigen Anpassungen am Sourcecode sind nicht das Problem.


    An Laufwerken mangelt es auch nicht.


    Mach Dir um die Qualität Deines C-Codes erstmal keine Gedanken. Ich kann das gern jeweils überarbeiten. Wenn Du mir Pseudocode gibst und mir sagst, was Du damit erreichen willst, schreib ich Dir das.


    Was für einen Drehgeber verwendest Du? Alle anderen Teile hab ich da.

  • Nette Idee, und grundsätzlich bin ich neuen Ideen zu alter Hardware immer aufgeschlossen - aber:


    Wo liegt hier der Vorteil gegenüber z.B. einer 1541U? Klar, vermutlich einmal der Preis und ein Diskettenlaufwerk dürfte wohl quasi jeder aktive C64-Nutzer besitzen, aber lohnt sich der Aufwand, da etwas komplett neues zu entwickeln?


    Ich frag' nur, bitte nicht als "Schlechtmachen" werten - so ist das keinesfalls gemeint!


    Gruß
    rootfather

  • Wo liegt hier der Vorteil gegenüber z.B. einer 1541U?


    100% Kompatibilität zu einer echten 1541 mit 'weak bits' als einziger Ausnahme (und selbst die könnte man reinbauen) weil eben die echte Elektronik noch läuft und damit alle möglichen Schnelllader und andere Programme mit eigenem Code in der 1541 keinen Unterschied bemerken können.


    Man müsste sogar Hardware-speeder verbauen können, ohne das die Probleme machen.

  • Alsooooo... ;)
    FAT-Bibliothek ist die von Roland Riegel drin, war für mich übersichtlich, gut lesbar und hat ein paar Debugsachen drin, die mir das Leben leichter machten.
    Drangeknotet ist eine LCD-4Bit-Lib vom Peter Dannecker (war gerade da und meine eigene wäre in ASM gewesen).
    Drehencoder ebenfalls vom Peter, die kommt eigentlich mit allem klar, was sich dreht, auch mit meinem Pollin-Encoder.


    Was geht: MMC/Sd/SHDC zumindest vom 128MB bis 16GB werden erkannt, gelesen und geschrieben.
    Auswahl der Datei per Drehgeber und Anzeige im Display ist provisorisch drin (nur Root, begrenzte Anzahl Dateien usw.).
    Beim Druck auf den Button wird die Datei als Hex-Dump per UART ausgegeben.


    Mein Versuch, "mal schnell" einen Seek auf Beginn Track 18 und ein Ausgeben über UART endete im Moment mit einem File-Open-Error...


    Zur Hardware: prinzipiell muß alles gehen, was wie eine 1541 funktioniert, also die VIA zur Laufwerkssteuerung hat und einen 6502, der SO benutzt.
    Also eigentlich alles...
    Die Umschaltung 1541-LW/AVR liegt erstmal auf Eis, ist kein sonderliches Problem (2-3x 74LS245 o.ä), ist mir nur gerade noch unwichtig und zu fummelig. ;)
    Wenn mein Seek geht, werde ich (oder wer gerne will...) das GCR-Encoding machen und dien Track im Ram aufbauen, also mit allen Syncbytes, GAPs, Header, Daten usw.


    Die VIA bekommt einen Adapersockel, wo Port A und B ziemlich komplett vom AVR bedient wird.


    Der ganze Dateikram ist erstmal unkritsch, weil die 1541-Logik da sowieso denkt, es liegt keine Disk im Laufwerk.
    Dann erstmal MotorOn überwachen und den Rambuffer mit dem Track als Endlosloop rausschieben. Dazu passend Sync, SOE, ByteReady bedienen, das müßte schon reichen, damit ein 64er das Direktory anzeigt.


    Gruß aus Berlin
    Michael



    Ich hänge mal ein Bild des temporären Aufbaus ran, das Archiv mit den Sourcen auch.
    Ist AVR-Studio letzte 4er Version und WinAVR-20100110.
    Ich weiß auch nicht, ob ich da von meinen Gewohnheiten weichen werde, bei mir soll es nur laufen. ;)

  • Noch kurz zu den anderen Anmerkungen:
    Gerrit hat schon richtig angemerkkt: eigentlich kann man mit der Floppy machen, was man will, es muß alles laufen können.
    Schnittstelle ist die zum mechanischen Laufwerk und die an dieses gebundene Elektronik.
    Drehzahl, Stepzeiten, Wartezeiten zur Kopfberuhigung usw. stehen im gegeben Toleranzbereich fest.
    Kein Speeder, Umbau o.ä. kann an diesen mechanischen Grenzen ewas ändern.


    Aufwand: ein AVR, ein Display, ein Drehgeber, ein SD-Slot und 2 Adaptersockel mit Drähten dran ist der maximale Aufwand.


    Lesekopf/Lichtschranke usw: mit einem AVR ist die Bitrate nicht machbar. Außerdem müßten die analogen Signale erzeugt werden, damit die Floppy-Hardware damit klarkommt.
    Der Punkt dazwischen ist günstiger, TTL-Pegel, 8Bit-Paralleldaten statt alles seriell usw.


    Sinn? Keine Ahnung, macht Spaß...
    Das Timing an der VIA müßte es zulassen, mit TriState-Buffern sowhl das LW an die Floppy-Logik schalten zu können (Originalzustand), den AVR an die Floppy-Logik (Emu des Laufwerks durch den AVR) und prinzipiell auch den AVR an das LAufwerk. Dann könnte man auch direkt Floppy rein -> D64/G64 auf SD-Card schreiben oder D64/G64 von SD-Card direkt auf Diskette schreiben.


    Gruß aus Berlin
    Michael

  • Würde es nicht theoretisch genügen, die Leitungen vom Schreib-Lesekopf, vom Schrittmotor und von der Lichtschranke umzuleiten?


    Schreib-Lese-kopf ist analog, da müßte man noch Pegel wandeln. Außerdem ist die VIA-Schnittstelle um den Faktor 8 langsamer und synchron (über S.O.), ist also wesentlich toleranter gegen Jitter und so krams- wenn man es nicht mit ganz harten Kopierschutz-Verfahren oder Nibble-Copys zu tun hat ist der Floppy die Datenrate einigermaßen Wumpe, während eine serielle EInspeisung bereits für den Normalbetrieb ziemlich exakte Datenraten verlangt.

  • Sehr schönes Projekt! Die Idee hatte ich auch schon, nur leider bis jetzt keine Zeit dafür gehabt das mal umzusetzen. Drücke dir die Daumen das es klappt. Hab hier noch eine 1541 II Platine rumliegen wo der R/W Amp (CX20185) die Hufe hoch gerissen hat. Also genau das richtige dafür ;) . Und den Rest an benötigten Teilen hab ich auch hier. Also wenn ich mal was Testen oder Helfen kann ... gerne :thumbsup:

  • Hallo allerseits,

    Würde es nicht theoretisch genügen, die Leitungen vom Schreib-Lesekopf, vom Schrittmotor und von der Lichtschranke umzuleiten?

    ich sehe das genau so. Der Vorteil liegt hier man muß das Board der 1541 nicht modifizieren (nur ein par stecker umstöpzeln) und dies ist dann auch eine Lösung die wesentlich Nutzerfreundlicher ist. Dass ein AVR mit einer Bitrate hierfür nicht klar kommt stimmt auch nicht ganz so, es ist halt nur etwas herausvordernd. Hier mal ein Rechnenbeispiel:


    pro Sektor:
    (258 Bytes für den Datenblock + ca. 2 byte Auffüller) * 10 (10 bit gcr-codierung pro byte) + ca. 20 bits für sync = 2620 bits
    (18 bytes für den header + ca. 2 byte Auffüller) * 10 (10 bit gcr-codierung pro byte) + ca. 20 bis für sync = 220 bits
    bits pro sektor=2620 bits + 220 bits


    und nun pro spur:
    21 (anzahl max sektoren pro Spur) * 2840 bits=59640 bits


    nun die Datenrate:
    59640 bits * 300 rpm / 60 sekunden = 298200 Hz


    Also ein AVR sollte doch in der Lage sein Daten mit einen Takt von 300 KHz zu verarbeiten. Bei einen 20MHz AVR stehen dann 66 Cyclen zur Verfügung dies zu tun. Mit ein paar externen Shift-Registeren kann man die 300 Khz bestimmt noch etwas nach unten korrigieren. Bei den ca. Werten habe ich keine Idee wieviel wirklich gebraucht werden, daher muss evt. die Gleichung angepasst werden. Ich hoffe ich habe nicht falsch gerechnet :whistling: .


    Und zu dem Thema Analog: Ich kann mir nicht vorstellen dass es wirklich so viel dahinter steht. Mit ein paar Widerständen und ein paar Komperatoren sollte man diese Signale digitalisieren können. Wenn mein neues Oszi in den nächsten Tagen kommt kann ich es ja mal an den Lese/Schreibkopf hängen und mal mal zeigen was dann wirklich dahinter steckt.

    -zschunky