Hallo Besucher, der Thread wurde 43k mal aufgerufen und enthält 209 Antworten

letzter Beitrag von DerSchatten am

XS1541 - universal serial adapter for CBM Floppy

    Danke Unseen, du hast Recht ich habe weiterhin auf das Port geschrieben und nicht ins DDR, das dürfte wohl der Grund sein. Mich wunderts was die Hardware alles aushält (1541, Atmega) ...


    Ich kämpfe gerade mit noch einem anderen Problem. Der Umstieg von Mega32 auf Mega644 gestaltet sich unerwarteterweise recht kompliziert. Die haben doch glatt viele der Registernamen geändert!


    Inzwischen lässt es sich wieder kompilieren aber der Timer 1 Interrupt läuft nicht mehr und Uart empfangen mach auch Probleme. Habe zwar diese avrcompat.h aus deinem SD2IEC entdeckt, aber es wird wohl doch besser sein ich studier erst mal das 644/324 Datenblatt.

    Selbe Firmware (0.01.09a) aber nun auch eine Version wo IEC direkt angeschlossen ist.


    Ich habe das separat aufgebaut auf einem Olimex AVR40 Board (siehe Bild). Das Olimex Board gibt es jetzt auch mit USB. Das IEC Kabel wurde einfach durchgeschnitten und direkt am Atmega angelötet (siehe Schaltbild). Bei den Signalen ATN, Clock, Data und SRQ sind jeweils in und out einfach zusammen geschaltet.


    Die Hex Dateien mit dem 'A' sind für die XA1541 Version und die 'D' sind für direkten Anschluss. Die '-32' Versionen sind für Atmega 32 kompiliert und die '-324' für den Atmega 324p.




    Vielen Dank an Unseen für den richtungsweisenden Tip, ich war echt mit Blindheit geschlagen!! Aber solche Dämpfer tun gut und verhindern Größenwahn ...
    -

    Hallo Diddle,

    Zitat von Diddl

    Bei den Signalen ATN, Clock, Data und SRQ sind jeweils in und out einfach zusammen geschaltet.


    Warum führst Du die Signale alle doppelt auf zwei Pins des AVR? Das muß doch nicht sein, oder verwendest Du spezielle Funktionen dieser Pins (Interrupts, Timer, ...)? Wenn Du nur auf die Ports mittels PORT bzw. PIN zugreifst, sollte einer reichen.


    Gruß Martin

    Zitat von HofMar

    Warum führst Du die Signale alle doppelt auf zwei Pins des AVR? Das muß doch nicht sein, oder verwendest Du spezielle Funktionen dieser Pins (Interrupts, Timer, ...)? Wenn Du nur auf die Ports mittels PORT bzw. PIN zugreifst, sollte einer reichen.


    Das ursprüngliche Schaltbild sah auch getrennte Ausgänge unter Verwendung des XA-1541 Interface vor. Die Logik im Programm ist momentan dieselbe, nur dass ich die Ausgänge mit DDRx statt mit PORTx setze.


    Es gibt zwar zur Zeit keine Verwendung für weitere Pins aber möglicherweise kann man da tatsächlich noch optimieren.


    Ich bin auch beim überlegen ob ich den 1571 burst Modus per Software unterstützen soll oder ob ich das Hardware TWI dafür missbrauchen kann/soll.

    Neue Version, alle IEC Pin belegen jetzt nur noch einen Pin des Atmega (ich bin ja trotz hohem Alter noch lernfähig ;) ).



    ACHTUNG: nochmals geändertes Schaltbild (hoffentlich jetzt entgültig).



    .

    Hallo Diddl,


    auch auf die Gefahr hin, mich unbeliebt zu machen, würde ich versuchen einige Pins zu tauschen. Ich denke, dann wird das Layout auch etwas einfacher:


    • ATN vom IEEE-488-Bus von PD3 nach PC3
    • Clock vom seriellen IEC-Bus von PD7 nach PD3


    Des weiteren könnte man nun das IFC- (Reset-) Signal des IEEE-488-Bus auf PC2 führen und damit auch softwareseitig einen Reset auslösen. Für den seriellen IEC-Bus gibt es dieses Signal schon beschaltet.


    Gruß Martin

    Zitat von HofMar
    • ATN vom IEEE-488-Bus von PD3 nach PC3
    • Clock vom seriellen IEC-Bus von PD7 nach PD3


    Des weiteren könnte man nun das IFC- (Reset-) Signal des IEEE-488-Bus auf PC2 führen und damit auch softwareseitig einen Reset auslösen. Für den seriellen IEC-Bus gibt es dieses Signal schon beschaltet.


    Sehr geschätzter HofMar. Verbesserungsvorschläge würden dich niemals unbeliebt machen. Es freut mich sehr wenn jemand mitdenkt, besonders da ich bei der Hardware starke Defizite habe.


    Der ATN ist mit ganz bestimmter Absicht am PD3. So kann der XS-1541 passiv am Bus arbeiten, auch wenn 'nur' ein Mega32 verwendet wird. Am liebsten wäre mir hier die XOR Schaltung der 8050 Floppy, die NRFD auf low zieht wenn ATN kommt.


    Das IFC anzuschließen finde ich sehr schlau! Das neue Schaltbild berücksichtigt das und auch die beiden restlichen Signale.


    .

    Neue Firmware.

    • Backup von D71 Images getestet und ok.
    • automatische Umschaltung der 1571 in den 1571 Modus (U0>M1) nach <#>, <listbam> und <backup>
    • ListBAM funktioniert jetzt ohne Parameter mit dem Default Image Typ
    • Backup funktioniert jetzt ohne Parameter mit dem Default Image Typ


    Im 1571 Modus formatiert die 1571 ziemlich schnell und beidseitig. In den 1571 Modus kommt man leicht zb. mit:


    #8 1571


    Zurück in den 1541 Modus kommt man nur bei eingestelltem 1571 Laufwerkstyp und einem D64 Image Befehl:


    listbam d64



    Wenn der aktuelle Laufwerkstyp nicht 1571 ist, dann werden die U0>M Befehle nicht gesendet. Diesen Befehl kann ja nur eine 1571 verstehen.




    Leider verzögert sich der 1581 Imagetyp noch weiter. Gestern habe ich das bestellte Amiga Laufwerk bekommen. Gekommen ist ein Sony Laufwerk, es funktioniert aber nicht in meiner 1581. Habe das Laufwerk geöffnet, es hat die Umbauten für Amiga wie es im Inet zu lesen ist, trotzdem kein Erfolg. :(


    Habe jetzt ein Epson SMD-1340 und ein Teac FD-235HF geordert. Mal sehen ob eines der beiden in dem 1581 Gehäuse richtig funktioniert.


    Vielleicht kann es mal jemand testen der ein funktionierendes 1581 besitzt?


    .

    Zitat von HofMar

    Warum führst Du die Signale alle doppelt auf zwei Pins des AVR? Das muß doch nicht sein, oder verwendest Du spezielle Funktionen dieser Pins (Interrupts, Timer, ...)? Wenn Du nur auf die Ports mittels PORT bzw. PIN zugreifst, sollte einer reichen.


    Das System mit einem Pin hat auch einen Nachteil: Man hat jetzt keinen Pullup Widerstand mehr. Dadurch sind jetzt alle Signalleitungen auf low wenn alle Floppys aus sind oder wenn gar keine Floppy dran hängt.


    Vielleicht sollte man doch 5 Widerstände spendieren?


    Zumindest werde ich den Fall mal per Software abfangen ...

    Hallo Diddl,

    Zitat von Diddl

    Das System mit einem Pin hat auch einen Nachteil: Man hat jetzt keinen Pullup Widerstand mehr. Dadurch sind jetzt alle Signalleitungen auf low wenn alle Floppys aus sind oder wenn gar keine Floppy dran hängt.


    Vielleicht sollte man doch 5 Widerstände spendieren?


    Vielleicht hast Du auch einen Fehler in der Software. Ich denke, es gibt drei Zustände auf einen Pin. Dies gilt sowohl für den IEEE-488-Bus als auch dem seriellen IEC-Bus.

    • Der AVR schaltet den Pin gegen Masse (log. 0) durch. Hier sollte der Pin als Ausgang geschaltet (DDR = 1) und das PORT auf 0 (PORT=0) geschaltet sein. Weitere Teilnehmer des Buses können auch gegen Masse schalten, dies hat aber keine weitere Auswirkung (Wired AND).
    • Der AVR schaltet gegen Plus über einen Pull-Up-Widerstand. Dazu wird der Pin als Eingang geschaltet (DDR = 0) und der Pull-Up mitels (PORT = 1) eingeschaltet. Sollten keine weiteren Teilnehmer am Bus diesen PIN auf Masse schalten, verbleibt er damit auf log. 1 und kann auch so über PIN gelesen werden.
    • Der vom AVR über den Pull-Up-Widerstand nach Plus geschaltete PIN kann jederzeit von anderen am Bus gegen Masse geschaltet werden. Dies kann mit PIN korrekt zurückgelesen werden.

    Eine kleine Übersicht ist auch unter http://www.mikrocontroller.net…torial:_IO-Grundlagen</a> zu sehen.


    Ich kenne bis jetzt nicht Deinen Source-Code, jedoch wird das auch sehr schön vom Dennis in der Sprache C mit Makros in dem Projekt http://www.dingeldein-online.de/basteln/gpib.html (in der Datei "gpib.c") gelöst:



    Ich hoffe, daß hilft etwas.


    Gruß Martin

    Diddl: Hym.. ich sehe den 14,xxx MHz Quartz im Schaltbild und meinen 16MHz auf dem Pollin Board.. das dürfte dann ja mit dem HEX File so nicht gehen.. könntest du bitte die aktuelle Firmware noch einmal mit 16MHz Quartzeinstellung durch den Compiler jagen..? Dann kann ich nächste Woche mal einen Versuch mit ATmega32+Pollin Board machen..


    Danke+Gruß, Peter

    Zitat von PeterSieg

    Diddl: Hym.. ich sehe den 14,xxx MHz Quartz im Schaltbild und meinen 16MHz auf dem Pollin Board.. das dürfte dann ja mit dem HEX File so nicht gehen.. könntest du bitte die aktuelle Firmware noch einmal mit 16MHz Quartzeinstellung durch den Compiler jagen..? Dann kann ich nächste Woche mal einen Versuch mit ATmega32+Pollin Board machen..


    Danke+Gruß, Peter


    Hallo Peter


    Mach ich gerne, allerdings stimmt dann das Timing am RS-232 dann nicht perfekt. Der AVR kann exaktes Timing nur bei den krummen Quarz Frequenzen machen. Bei manchen PC macht das nix, aber meiner zB. ist da heikel. Die 115200 schafft mein PC nicht wenn der AVR so daneben ist. Zur Sicherheit habe ich dir drei Varianten kompiliert, alle mit 16MHz aber verschiedene Baudraten.
    .

    Zitat von Diddl

    Mach ich gerne, allerdings stimmt dann das Timing am RS-232 dann nicht perfekt. Der AVR kann exaktes Timing nur bei den krummen Quarz Frequenzen machen. Bei manchen PC macht das nix, aber meiner zB. ist da heikel. Die 115200 schafft mein PC nicht wenn der AVR so daneben ist. Zur Sicherheit habe ich dir drei Varianten kompiliert, alle mit 16MHz aber verschiedene Baudraten.


    Verwendest du schon den 2X-Modus des AVR-UARTs? Damit wäre laut Tabelle im Datenblatt der Fehler etwas kleiner (+2.1% statt -3.5%).


    Oder man legt den Leuten einfach nahe sich einen flexibleren seriellen Port für den PC zuzulegen, für meinen unveröffentlichten (weil unzuverlässigen) IEC-Snooper verwende ich zB 250000 Baud mit einem FT232R als Gegenstelle auf PC-Seite.

    Zitat von Unseen

    Verwendest du schon den 2X-Modus des AVR-UARTs? Damit wäre laut Tabelle im Datenblatt der Fehler etwas kleiner (+2.1% statt -3.5%).


    Hi Unseen


    Der 2X Modus war mir bisher unbekannt, danke für den Tip.


    Oder man legt den Leuten einfach nahe sich einen flexibleren seriellen Port für den PC zuzulegen, für meinen unveröffentlichten (weil unzuverlässigen) IEC-Snooper verwende ich zB 250000 Baud mit einem FT232R als Gegenstelle auf PC-Seite.[/quote]


    IEC-Snooper? klingt interessant!


    Die meisten Leute haben in ihre PC nur die Standard Com am Motherboard oder gar keine mehr. Flexiblere serielle Port wären schon gut aber einfacher ist es den AVR perfekt abzustimmen (finde ich). Der 147456 Quarz kostet nix mehr als der 16M. Ich verwende bei AVR praktisch nur diese Frequenz.

    Zitat von Diddl

    IEC-Snooper? klingt interessant!


    Evtl. räume ich den Code demnächst mal ein wenig auf und lege ihn irgendwo ab. Läuft auf sd2iec 1.x-Hardware und liefert einen Hexdump aller übertragenen Daten und Befehle im Standardprotokoll - aber gelegentlich geht mal ein Byte verloren. Die hohe Baudrate ist nötig weil die Interrupts ziemlich häufig gesperrt sind.


    Zitat

    Der 147456 Quarz kostet nix mehr als der 16M. Ich verwende bei AVR praktisch nur diese Frequenz.


    Ja, du versuchst ja auch keine Floppyspeeder in AVR-Assembler nachzubauen. =) Bei Turbodisk hätte für 7.x/14.xMHz-Betrieb die innere Schleife vermutlich eine variable Wartezeit bekommen müssen damit das Timing nicht in die eine oder andere Richtung wandert. Mit 8MHz ist das viel entspannter, weil dann immer 8 AVR-Takte einem 1541-Takt entsprechen.

    Zitat von Unseen

    Ja, du versuchst ja auch keine Floppyspeeder in AVR-Assembler nachzubauen. =) Bei Turbodisk hätte für 7.x/14.xMHz-Betrieb die innere Schleife vermutlich eine variable Wartezeit bekommen müssen damit das Timing nicht in die eine oder andere Richtung wandert. Mit 8MHz ist das viel entspannter, weil dann immer 8 AVR-Takte einem 1541-Takt entsprechen.


    Ah interessant, ungeahnte Probleme! Ich bin ja eigentlich noch blutiger Anfänger am AVR, aber ich lerne täglich ziemlich was dazu.



    Zur Zeit kämpfe ich etwas mit dem Burst mode der 1571. Da hast du keine Patent Lösung für mich?


    Das Problem ist, mit dem Pin Change Interrupt des 644 geht das leicht. Aber mit einem normalen Mega32 wirds happiger. Ich habe gehofft ein Hardware Schieberegister des Mega32 könnte mir helfen. Aber mit den Sachen kenn ich mich leider zuwenig aus ...


    Das USR eines Tiny müsste doch dafür gehen? Leider hat der Mega32 sowas nicht. Die synchrone UART Geschichte verlangt immer Frames, oder? und der TWI hat immer 9 Bit, oder? Und das SPI geht nur als drei Draht? Oder seh ich das falsch?

    Zitat von Diddl

    Zur Zeit kämpfe ich etwas mit dem Burst mode der 1571. Da hast du keine Patent Lösung für mich?


    Nein, den habe ich bisher ignoriert weil ich noch keine Lust hatte wieder lange in den Romlistings zu wühlen und die Burst-Befehle zu implementieren.


    Zitat

    Das Problem ist, mit dem Pin Change Interrupt des 644 geht das leicht. Aber mit einem normalen Mega32 wirds happiger.


    Am mega32 konnte ich mich in dieser Hinsicht glücklicherweise vorbeimogeln. =) Ohne die Taktleitung auf einem Interrupt zu haben wird es rein in Software ziemlich schwer.


    Zitat

    Das USR eines Tiny müsste doch dafür gehen? Leider hat der Mega32 sowas nicht. Die synchrone UART Geschichte verlangt immer Frames, oder? und der TWI hat immer 9 Bit, oder? Und das SPI geht nur als drei Draht? Oder seh ich das falsch?


    Ja, das USI wäre in diesem Fall wohl ziemlich hilfreich. Der normale synchrone UART-Modus ist AFAIK identisch zum asynchronen, abgesehen davon dass der noch ein Taktsignal liefert - aber verwendet habe ich den noch nie. TWI passt nicht zu deinem Problem, aber SPI könnte gehen wenn du die Sendeleitung extern mittels Diode zu Quasi-Open-Collector machst und mit der Empfangsleitung verbindest. Man müsste dann je nach dem wer den Takt erzeugt SPI zwischen Master und Slave umschalten um entweder selbst zu takten (Taktleitung wieder mit Diode oder Transistor entkoppeln, damit es auf dem Bus Open Collector ist) oder einen Takt empfangen zu können.

    Zitat von Unseen

    Nein, den habe ich bisher ignoriert weil ich noch keine Lust hatte wieder lange in den Romlistings zu wühlen und die Burst-Befehle zu implementieren.


    Dann kann ich wenigstens mal was an das SD2IEC Projekt zurück geben. :]


    Falls du Lust hast den Burst Mode in die SD2IEC Entwicklung rein zu bringen. Wäre interessant für 128er Benutzer die SD2IEC verwenden ...

    Zitat von Diddl

    Dann kann ich wenigstens mal was an das SD2IEC Projekt zurück geben. :]


    Falls du Lust hast den Burst Mode in die SD2IEC Entwicklung rein zu bringen. Wäre interessant für 128er Benutzer die SD2IEC verwenden ...


    Klar, Patches werden gerne angenommen - möglichst gegen die aktuelle Entwicklungsversion. Ich garantiere aber nicht dafür dass sie übernommen werden und neige gelegentlich dazu Sachen halb umzuschreiben bevor ich sie einbaue.