Hallo Besucher, der Thread wurde 51k mal aufgerufen und enthält 146 Antworten

letzter Beitrag von mase76 am

sd2iec Hardware 1.0

    Zitat von RetroStyle

    Wie realisiert man denn ohne die Zusatz-Platine von X1541 den Diskchange bzw. den "Reset"? An welchen Pin muss welches Kabel bei V1.6?


    Manchmal ist es doch praktisch, wenn man den Inhalt seiner Festplatte selten aufräumt - ich hatte noch ein Foto von einer der Platinen rumliegen. =)


    Der Reset-Anschluss ist der fünfte von oben bzw. der zweite von unten, Diskchange ist der unterste Pin der rechten Seite des Microchips. Beim Resetanschluss sollte man sich bemühen die Nachbarpins nicht damit kurzzuschliessen, bei Diskchange ist es kein Problem wenn ein oder zwei Pins daneben auch noch Kontakt haben. Beide Leitungen müssen mittels je eines Tasters mit Masse (GND) verbunden werden, davon gibts auf der Stiftleiste unten (ist auf dem Foto nicht bestückt) reichlich - die Belegung findet sich zB in einem PDF im Aufbauthread.


    Den rechts im Bild zu sehenden Quarz und seine drei Leitungen bitte ignorieren.

    Zitat von Shadowolf

    Es gibt vier gleich ausgeführte IEC Anschlüsse von denen nur drei bestückt werden zur Zeit.
    Neben den FET's braucht man noch die Widerstände aber die sind weniger schwierig zu bekommen.
    Dir lege ich also auch noch zwei Transistoren dazu.


    Vielen Dank!
    Gruß WTE

    Zitat

    Manchmal ist es doch praktisch, wenn man den Inhalt seiner Festplatte selten aufräumt - ich hatte noch ein Foto von einer der Platinen rumliegen. =)


    Der Reset-Anschluss ist der fünfte von oben bzw. der zweite von unten, Diskchange ist der unterste Pin der rechten Seite des Microchips. Beim Resetanschluss sollte man sich bemühen die Nachbarpins nicht damit kurzzuschliessen, bei Diskchange ist es kein Problem wenn ein oder zwei Pins daneben auch noch Kontakt haben. Beide Leitungen müssen mittels je eines Tasters mit Masse (GND) verbunden werden, davon gibts auf der Stiftleiste unten (ist auf dem Foto nicht bestückt) reichlich - die Belegung findet sich zB in einem PDF im Aufbauthread.


    Danke für den Hinweis, da ich ja bei mir in die +5V Leitung einen Schalter eingebaut habe, kann ich damit das MMC2IEC aus- und wieder einschalten. ;) Fehlt nur noch der Diskchange... funktioniert aber nur bei D64-Dateien im selben (Unter?-)Verzeichnis, richtig? Oder funktioniert das nur bei D64-Dateien im Root?

    Zitat von RetroStyle

    Danke für den Hinweis, da ich ja bei mir in die +5V Leitung einen Schalter eingebaut habe, kann ich damit das MMC2IEC aus- und wieder einschalten. ;)


    Elektrisch ist das nicht so richtig sauber... bei den 1.6er-Platinen funktioniert sowas noch halbwegs, die 1.0er können dabei unter Umständen den Bus blockieren. Ich empfehle zum Abschalten die ATN-Leitung aufzutrennen.


    Zitat

    funktioniert aber nur bei D64-Dateien im selben (Unter?-)Verzeichnis, richtig? Oder funktioniert das nur bei D64-Dateien im Root?


    Der funktioniert mit allen D64-Dateien die man in die Liste eingetragen hat, egal wo sie liegen. Im Augenblick werden in den Wechsellisten Pfade nach FAT-Art (/dir/dir2/bla.d64) erwartet, wenn nur ein Dateinamen angegeben ist wird natürlich im aktuellen Verzeichnis gesucht.


    Da sich die Auswertung davon in 0.7 ändern wird (verwendet dann ebenso wie CD und alle anderen Befehle die Syntax der CMD-Laufwerke: //dir/dir2/:bla.d64) empfehle ich, möglichst keinen Pfad in die Wechsellisten zu schreiben.

    Ich schalte bei der 1.6 ja auch nicht wild ein und aus, sondern ich lasse kurze Zeit dazwischen (ca. 3-5 sek.) um sicher zu gehen. Evtl. baue ich auch noch einen Zusatzschalter in die ATN-Leitung ein, der andere dient ja mehr dazu, die Datasette und das MMC2IEC einigermaßen elektrisch zu "trennen", bei mir eben mit dem Zusatzeffekt, dass das MMC2IEC dabei komplett abgeschaltet wird.

    Bei der 1.0 habe ich den Fehler gemacht und an den Gates der FET's keine Pulldown Widerstände eingebaut.
    Wenn man nun in genau dem Moment einen Reset auslöst wenn die Leitungen geschaltet werden, dann wird der Bus blockiert.


    Die Gefahr ist minimal.
    Aber um das zu verhindern, habe ich noch weitere Widerstände vorgesehen.
    Die haben aber nur in 0805 reingepasst.
    Naja, ich lege die bei, die müssen aber nicht unbedingt bestückt werden.

    Wenn bis Ostern alles gelaufen sein soll, dann denke ich mal, dass demnächst auch die Platinen bestellt werden. Habt ihr das mit der IRQ-Auslösung bei vielen seriellen Geräten und langem Kabel getestet (Falls nicht, würde ich mich als Tester mit acht seriellen Geräten zur Verfügung stellen). Erwähnen könnte ich allerdings noch, dass ich das Problem, dass der AVR-Pin keinen Flanken-, sondern nur einen Level-IRQ auslöst, gleich zu Beginn von IEC2IEEE hatte. Damals benutzte ich noch einen 90S8515. Vielleicht sind die Eingangspins ja auch inzwischen verbessert.

    Zitat von NLQ

    Wenn bis Ostern alles gelaufen sein soll, dann denke ich mal, dass demnächst auch die Platinen bestellt werden.


    Yep, ich dachte so an Mitte/Ende nächster Woche, die Platinen haben ja eine garantierte Laufzeit von lediglich drei Tagen, im Gegensatz zu den Bauteilen.


    Zitat


    Habt ihr das mit der IRQ-Auslösung bei vielen seriellen Geräten und langem Kabel getestet (Falls nicht, würde ich mich als Tester mit acht seriellen Geräten zur Verfügung stellen).


    Unseen hat zwar die Software mit fieser Belastung auf dem IEC getestet, allerdings nutzt die Software bisher überhaupt keinen Interrupt, das Problem kann also garnicht wirklich auftreten.


    Zitat


    Erwähnen könnte ich allerdings noch, dass ich das Problem, dass der AVR-Pin keinen Flanken-, sondern nur einen Level-IRQ auslöst, gleich zu Beginn von IEC2IEEE hatte. Damals benutzte ich noch einen 90S8515. Vielleicht sind die Eingangspins ja auch inzwischen verbessert.


    Wir haben uns auch nicht vollständig darauf verlassen und so gibt es einen zusätzlichen Widerstand um bei Bedarf PA0 mit PB2 (INT2) zu verbinden:


    sd2iec_1.1_sch.png


    Der ist als 0603 ausgeführt, bei Bedarf werden die benachbarten Pads einfach mit ein wenig Lötzinn geschlossen.


    sd2iec_1.1_top.jpg


    Und der Vollständigkeit halber noch die Unterseite:


    sd2iec_1.1_bot.jpg


    Am Montag bekomme ich die ersten Test-Exemplare der Platine in Version 1.1.
    Leider habe ich noch keinerlei der Mega644P-20AU die jetzt letzlich zum Einsatz kommen.
    Der Mega644-20AU ist zwar Pin- und Binär-kompatibel, dem "fehlt" allerdings der zweite UART welcher künftig für Debug-Ausgaben genutzt werden soll - daher auch X7. :)


    NLQ: Wenn Dir diese Einschränkung nichts ausmacht dann könnte ich Deine beiden Sätze mit Mega644 versehen vorab auf den Weg bringen.

    Zitat von Shadowolf

    Unseen hat zwar die Software mit fieser Belastung auf dem IEC getestet, allerdings nutzt die Software bisher überhaupt keinen Interrupt, das Problem kann also garnicht wirklich auftreten.


    Na ja, nicht ganz. ATN wird im Timerinterrupt abgefragt und die Kartenwechselerkennung verwendet einen der Interrupt-Pins.


    Zitat

    Der Mega644-20AU ist zwar Pin- und Binär-kompatibel, dem "fehlt" allerdings der zweite UART welcher künftig für Debug-Ausgaben genutzt werden soll - daher auch X7. :)


    Öh, ich habe nichts davon gesagt, dass ich den zweiten UART sofort dafür verwenden würde... Das ist nur eine nette Option falls Jims serieller PC-Slave fertig wird.


    Interessanter Pinabstand:
    sd2iec_1.1_top_abstand.jpg

    Zitat


    NLQ: Wenn Dir diese Einschränkung nichts ausmacht dann könnte ich Deine beiden Sätze mit Mega644 versehen vorab auf den Weg bringen.


    Das würde mich freuen. Ich würde dann mal versuchen das an meinem seriellen Bus zu Testen. Würde Unseen den IRQ von Timer auf Pin ändern (ich kann leider kein C) oder soll ich NLQ-HD anpassen (würde etwas dauern?)

    Zitat


    ATN wird im Timerinterrupt abgefragt und die Kartenwechselerkennung verwendet einen der Interrupt-Pins.


    Der Mega644-20AU ist zwar Pin- und Binär-kompatibel, dem "fehlt" allerdings der zweite UART welcher künftig für Debug-Ausgaben genutzt werden soll - daher auch X7. :)


    Beim Schaltplan vom 3.2.08 15:02 ist Carddetect mit PD2 verbunden. Das ist aber genau ein Pin den der zweite UART benutzen müßte. Genau die beiden Pins von Port D, die einen Level-IRQ auslösen könnten (fürs Carddetect) sind auch von der zweiten UART belegt.

    Zitat von NLQ

    Das würde mich freuen. Ich würde dann mal versuchen das an meinem seriellen Bus zu Testen. Würde Unseen den IRQ von Timer auf Pin ändern (ich kann leider kein C) oder soll ich NLQ-HD anpassen (würde etwas dauern?)


    Ich würde ja eher empfehlen, endlich mal C zu lernen... ;-)


    Ich kann mal versuchen die Anpassung zu machen, kann aber nicht garantieren bis wann ich dazu komme.


    Zitat von NLQ

    Beim Schaltplan vom 3.2.08 15:02 ist Carddetect mit PD2 verbunden. Das ist aber genau ein Pin den der zweite UART benutzen müßte. Genau die beiden Pins von Port D, die einen Level-IRQ auslösen könnten (fürs Carddetect) sind auch von der zweiten UART belegt.


    Ja, Atmel hat den IMHO auf ziemlich schlechte Pins gelegt. Das einer der beiden Pins schon für andere Zwecke verwendet wird sollte aber nicht stören, wenn der wirklich für Debugausgaben genutzt wird reicht die Sendeleitung aus und man kann ja bei den AVR-USARTs Sende- und Empfangsteil getrennt ein-/ausschalten.

    Unseen


    Sorry, ja, natürlich meinte ich, die Software nutzt für den IEC keinen Pin-Interrupt.
    Und die Lösung mit dem Timer-Interrupt ist ja offenbar nicht schlecht, es funktioniert ja soweit bestens.


    >Interessanter Pinabstand:


    Das ist Absicht, X5 und X7 gehören ja nicht zusammen.
    Die sind auch nur so dicht beisammen und X7 hat nur kein GND, weil mir offensichtlich der Platz ausgeht. ;)



    NLQ
    >Beim Schaltplan vom 3.2.08 15:02 ist Carddetect mit PD2 verbunden.


    Warum siehst Du Dir so einen alten Stand an? :)


    >Das ist aber genau ein Pin den der zweite UART benutzen müßte.


    Ja, für RXD1, der 2. UART muss aber nicht unbedingt empfangen können.



    Und danke für den Schubs, als ich mir das gerade nochmal angesehen habe musste ich feststellen,
    dass ich X7 mit dem falschen Pin verbunden habe, das ist garnicht TXD1, PD3 wäre es gewesen. :baby:


    Wenigstens kann man das so patchen, dass das quasi nicht zu sehen ist.


    Und gut, dass das jetzt auffällt...

    Hallo Shadowolf,


    eine kurze Frage als Fortbildung für mich :) zur Verbindung MEGA <--> IEC-Bus.
    Könnte man nicht einfach 4 Portpins (evtl. über Vorwiderstände) mit den IEC-Pins verbinden? Versteh ich das richtig? 4 PortPins dienen zum senden über IEC und 4 zum Empfangen über IEC, getrennt durch die FETs?


    Danke!!!

    Die Diskussion schwirrt hier zwar schon rum... :)


    Richtig, es gibt getrennte Pins zum Senden und Empfangen.
    Der IEC ist so aufgebaut, dass zumindest die Commodore Geräte 1k Widerstände gegen +5V in den Leitungen haben.
    Will sich ein Bus-Teilnehmer melden dann dieser erst einmal die ATN-Leitung gegen Masse ziehen.
    Mit zunehmender Anzahl an Geräten am IEC-Bus wird das schwieriger weil ja jedes einen eigenen Widerstand mitbringt, es muss also immer mehr Strom fliessen können damit der Spannungsabfall an den Widerständen noch hoch genug ist.


    Während beim Mega32 der Innenwiderstand noch so niedrig war, dass vielleicht 4 Geräte am Bus kein Problem darstellen, ist der Mega644 leider etwas hochohmiger und spielt bestenfalls mit 2 Geräten, also gerade einmal dem C64 und einer 1541.
    Die Transistoren sind deutlich niederohmiger und selbst mit den 18 Ohm Schutz-Widerständen müsste der IEC mit bis zu 6 Teilnehmern ohne Probleme funktionieren.
    Ich schreibe müsste, weil ich das nicht praktisch testen kann.
    Meine Messungen dazu habe ich mit einer Test-Software und Belastungswiderständen gemacht.
    Die Messungen sind weiter vorne hier im Thread.