Junior Computer ][

So, nach langem Suchen ist es vollbracht. Der Fehler, dass beim Wechsel in den Original Junior Monitor bei angeschlossener ASCII-Tastatur, die Eingabe über die Hex-Tastatur nicht sauber funktionierte, ist beseitigt.

Eigentlich habe ich wohl einen (fast auf den Tag genau) 42 Jahre alten Bug - der damals noch keiner war - in Alois Nachtmann's Monitor Code gefunden.

Zur Erklärung:

Zur Abfrage der Hex Tastatur und zum Ansteuern der 7-Segmentanzeige werden die Port B Pins PB1..PB4 des 6532 RIOT benötigt. Dazu wird in der Monitor Reset Routine das Port B Ausgangsregister mit $1E initialisiert, was PB1..PB4 zu Ausgängen und PB0, PB5..PB7 zu Eingängen macht. Ich hatte nun den Wert zu $3E geändert, so dass PB5 ebenfalls ein Ausgang wird (siehe unten).

Bei der Tastaturabfrage wird nun durch setzen der Werte $00, $02, $04 die Tastaturzeilen ausgewählt (LOW aktiv) und an den Port A Leitung dann die Tastaturreihen gelesen, in der eine Taste gedrückt wurde. Bei gedrückter Taste liest man also irgendwo an Port A eine Null.

Werden auf Port B die Werte $08, $0A, $0C, $0E, $10 oder $12 geschrieben, wird jeweils eine 7-Segmentanzeigen angesteuert. Der Wert $06 schaltet das Display aus.

Im gesamten Code werden nun zum Ansteuern der Port B Pins nirgendwo Werte größer $12 geschrieben...BIS AUF EINE CODE ZEILE. Hier wird Port B (aus mir unerfindlichen Gründen) auf $21 gesetzt, was PB0 und PB5 auf High setzen würde, wenn den diese beiden Pins Ausgänge wären...

Und genau das ist ja nun bei angeschlossener IO Karte für PB5 der Fall !!! Denn hiermit schalte ich die Ein-/Ausgangsbuffer für den Tastatur- und den Druckeranschluss auf READ (High), bzw. WRITE (Low). Das heißt, bei angeschlossener ASCII Tastatur ist PB5 im Normalfall auf High gesetzt um von der Tastatur zu lesen und Low um auf den Drucker zu schreiben. Bei einem Wechsel in den Original Junior Monitor schalte ich dann PB5 auf LOW um den Eingang hochohmig zu schalten.Da STROBE ebenfalls deaktiviert ist, passiert da auch auf dem Drucker dann nichts.

Allerdings wurde nun durch setzen des Wertes $21 beim Einlesen der Hex-Tastatur eben auch die ASCII-Tastatur wieder aktiviert, welche dann auf PA0..PA6 möglicherweise irgendwo eine Null setzt und somit völlig falsche Werte für die Hex Eingabe angenommen werden .

Der Wert $21 wird natürlich auch schön aus der Ferne, sozusagen als Quereinsteiger gesetzt. Wäre ja sonst auch zu einfach zu finden gewesen.

Kurze Rede Langer Sinn: Der Fehler ist behoben, ohne die Funktionalität des Original Monitors zu beeinträchtigen, indem ich jetzt an der besagten Code Stelle statt $21 nun $00 in das X Register und damit auf Port B schreibe. Gleichzeitig wird nun auch PB0 nicht mehr beeinträchtigt, an dem ja beim Junior ][ der Lautsprecher hängt.

Wahrscheinlich hatte Alois Nachtmann hier ursprünglich mal etwas anderes vorgehabt, und dann vergessen, den Wert zu bereinigen.

Ich geh jetzt jedenfalls erst mal feiern...

Gerade durfte ich herausfinden, was passiert, wenn man ein EEPROM verkehrt herum in den MiniPro TL866A steckt!

Anzeige "Current Overprotection", und der Programmer hat zum Glück nicht nur sich, sondern auch das EEPROM vor dem Abrauchen bewahrt.

Kleiner Tipp: Macht um diese Jahreszeit ab 18 Uhr einfach das Licht an, wenn ihr mit Elektronik rumbastelt .

Heute sind die Stabilisatoren eingetrudelt. Tasten und Tastenkappen fehlen leider noch. Aber langsam füllen sich die Kisten.

Gestern Abend hatte ich mal angefangen, mich um die bisher stiefmütterlich behandelte SPI-Schnittstelle, bzw. den SD-Card Adapter zu kümmern.

Ich hatte mich ja dagegen entschieden, das SPI Clock Signal von Hand, durch wiggeln einer Port Leitung, zu generieren. Stattdessen nutze ich auf der IO Platine die VIA 6522 im Modus "Shift In Under Phi2 Control", womit ich dann mit halbem CPU Takt von 500kHz Daten via CB2 Pin über die MISO Leitung sampeln kann. Das Clock Signal wird am CB1 Pin ausgegeben.

Für die Datenausgabe hängt am Port A ein Schieberegister 74LS165 mit paralleler Eingabe, welches seine Daten dann via SPI Clock austaktet.

Die Vorteile gegenüber der manuellen (wiggle) Ein-/Ausgabe über normale Port B Pins sind klar:

- Hohe Sample- und Taktgeschwindigkeit - 500 kBit, statt vielleicht 5-10 kBit.

- Das Ausgangs-Shift Register füllt sich automatisch mit $FF, womit beim Lesen an MISO die Vorgabe erfüllt ist, das MOSI gleichzeitig auf HIGH gezogen werden muss.

- Variabler Takt wählbar durch VIA Modus "Shift In Under T2 Control", indem der Zähler 2 dann als Taktgeber fungiert.

Letzteres ist notwendig, da für die Initialisierungsphase der SD-Karte nur ein Takt zwischen 100kHz und 400kHz erlaubt ist. Erst nach der Initialisierung kann der Takt bis zu 10MHz betragen.

Das ganze funktionierte auch, aus programmiertechnischer Sicht, sehr schnell wunderbar.

Hier sieht man sehr schön den Wechsel von der Initialisierungsphase mit 250kHz und /CS = H auf den Schreibmodus mit 500kHz und /CS = L, bei dem ich einfach mal die Datenwerte 1..255 ausgegeben habe.

Das MOSI so weit vor dem Takt auf LOW geht, liegt daran, dass das MSB sofort nach dem Laden des Wertes in das Schieberegister, am Ausgang (also MOSI) anliegt.

Die High Phase zwischen den Takten ist der Pollingschleife und der Langsamkeit des 6502 geschuldet. Später werde ich das dann mit Interrupt Routinen machen, und hoffe, dass das dann schneller geht.

Im Übrigen muss ich ja - wegen der frei wählbaren IO-Adresse des IO-Boards - indirekt auf die VIA mit den Befehlen LDA (IOBASE),Y und STA (IOBASE),Y zugreifen, was leider recht langsam ist, da jeder Befehl hier 5 Taktzyklen benötigt. Ich hatte das (da ich ja weiss wo meine Basisadresse liegt) auch mal mit direkter Adressen, also z.B. LDA $101A (3 Takte) probiert und war erstaunt, dass der Abstand der Takte um mehrere Mikrosekunden größer wurde. Das liegt wahrscheinlich daran, dass in der Polling Schleife hier dann gerade der Moment verpasst wird, an dem das Flag für den vollständigen Shift Vorgang gesetzt wurde. Oder um es im Biathlon Terminus auszudrücken: Pro Fehlschuss, eine Strafrunde.

Meine anfängliche Begeisterung wurde allerdings schnell gedämpft, als ich dann mal Werte von $80 aufwärts im Logiganalyzer betrachtet habe. Hier sieht man nämlich, dass das Austakten des Ausgabewertes mit dem Sampling auf die gleiche Taktflanke fällt. Bei einer steigenden Taktflanke sollte gesampled, und bei einer fallenden Flanke geschoben werden.

So sieht das bei einem Wert $82 (10000010) ohne weitere Maßnahmen aus

Am MISO Eingang funktioniert das, beim MOSI Ausgang leider nicht. Auch wenn das SPI Protokoll sich bei der Sampling Phase und der Polarität nicht festlegt - man kann das theoretisch frei wählen - das Slave Device muss den jeweiligen Modus beherrschen, und Ein- und Ausgabe müssen hier natürlich identisch arbeiten.

Das Problem lässt sich zwar problemlos mit einem D-Flip-Flop an MOSI lösen, das dann den Ausgang um einen halben Takt verschiebt. Allerdings benötigt man gleich wieder zwei Bausteinchen, da es kein D-Flip-Flop gibt, welches bei fallender Clock Flanke eintaktet. Man muss hier CLK also mit einem Inverter erst noch rumdrehen.

Hier dann das richtige Ergebnis bei $82, bei dem das MSB bei der ersten steigenden Taktflanke stabil auf HIGH liegt

Als Lösung könnte man theoretisch eine Zwischenplatine, zwischen Sockel und 74LS165 einfügen, auf dem dann die beiden Bauteile sitzen. Es gäbe sogar einzelne D-Flip-Flops (74AHC 1G79GW) und Inverter (74AHC 1GU04GW). Die sind aber nur in einem SOT-353-5 SMD-Gehäuse zu haben, was per Handlöten sehr ambitioniert ist.

Weiterhin kann man das Lochrasterfeld auf dem IO-Board zum Patchen nutzen, auf dem man dann ein 74LS74 D-Flip-Flop und einen 74LS04 Inverter lötet. Die MOSI Leitung zwischen dem Schieberegister und dem SD-Kartenadapter muss dann natürlich getrennt werden. Ich werde diese Lösung für mich mal nutzen, damit ich beim Programmieren weiterkomme.

Die dritte Lösung wäre die eleganteste. Da der SD-Kartenadapter sowieso gesteckt ist, legt man hier Hand an. Ich werde wohl eine Adapter-Adapterplatine gestalten, auf der dann das Flip-Flop und der Inverter drauf sind. Alternativ kann man natürlich auch alles, was sich auf dem SD Adapter befindet - 3,3V Regler, Level-Shifter, SD-Card Slot - zusammen mit den beiden Zusatzbauteilen als neue Adapterplatine aufbauen. Eventuell kann man ja auch eine SMD Bestückung von JLCPCB durchführen lassen, je nachdem wie teuer das dann wäre.

Ihr könnt euch ja mal Gedanken machen, welche Möglichkeiten für euch akzeptabel wären. Man kann natürlich auch auf die SD-Karte vollständig verzichten. Das wäre aber meine letzte Wahl.

So weit erst mal die letzten Bullshit Nachrichten vom Junior ][- Tut mir Leid, dass das wieder so viel Text wurde und sich da schon wieder ein neuer Show Stopper eingeschlichen hat .

Jörg

Hallo Norbert,

Zitat von Norbert-97801

reicht es nicht aus, den Takt gegenüber den Daten mit z.B. zwei oder 4 Invertern zu verzögern?

das ist mir auch schon in den Sinn gekommen. Mit einem 74LS04 komme ich dann mit den 6 Invertern natürlich auf 60ns Verzögerung, plus die Durchlaufzeit des Schieberegisters. Da auf steigende Flanke getriggert wird, könnte das eventuell durchaus reichen. Ich hab mich dann aber für die D-Flip-Flop Lösung entschieden, da ich hier auf der sicheren Seite bin. Letztlich werde ich das aber mal ausprobieren, wenn ich dann wirklich Kontakt mit der SD-Karte aufgenommen habe, denn bisher waren das ja alles Trockenübungen am Logicanalyzer.

Zitat von NorbertJ

hast du schon weitere Erkenntnisse gewonnen und weißt schon, ob es bei der Kombination 74LS74 und 74LS04 bleiben wird? Ich frage, weil ich dann welche bestellen möchte, denn ausgerechnet diese beiden Typen habe ich nicht mehr in meinem Vorrat. Funktionieren hier auch HC- oder HCT-Typen?

Hallo Norbert, nein, noch hab ich keine weiteren Erkenntnisse , ob eine Delay-Line mit Invertern oder Buffern ausreicht. Statt des 7404 kann man natürlich auch ein 7400 NAND Gatter als Inverter nutzen. Oder 7414 Inverter mit Schmitt-Trigger. Damit wären dann für eine Verzögerungsleitung auch 15nsx6 = 90ns möglich. Für den 7474 gibt es da leider wenig (keine?) Alternativen. HC oder HCT Typen sollten auch völlig problemlos gehen.

Jetzt hatte ich mir das ganze nochmal angeschaut, und festgestellt, dass ja die 6522 das Clock Signal an Pin CB1 Phasenverdreht zu Phi2 ausgibt. Ich hatte da erst mal garnicht richtig drauf geachtet, dass ja das Clock Signal auf dem Logicanalyzer immer mit einer High Phase anfing. Ich bin dann drauf gekommen, weil der Analyzer das Datenpaket mit der Einstellung SPI Mode 0 (CPOL = 0, CPHA = 0) nicht dekodieren konnte. Im Mode 2 ging es dann natürlich, was ich ja aber nicht anstrebe.

Damit war klar, eine Verschiebung des Datensignals ist überhaupt nicht notwendig, sondern eine Änderung der Taktpolarität reicht schon aus. Sprich einen Inverter an das SPI_CLK Ausgangssignal dranhängen, ohne den Takt am Shift-Register zu ändern. Und siehe da

So soll das doch aussehen.

Ihr könnt die Bestellungen der 74LS74 also wieder stornieren und bei Bedarf den Inverter mit einem NAND oder NOR basteln, falls kein 74LS04 zur Hand sein sollte.

Einen einzelnen 74LS04 (oder eben auch einen 74LS00) bekomme ich auch problemlos noch vorne auf die Platine gequetscht, ohne riesig das Layout umrouten zu müssen. Somit hätte eine neue Platinenversion dann also den Fehler nicht mehr drauf. Alle die bereits eine Platine haben, müssten dann halt patchen. Ich schau mal, wie man das am schönsten hinbekommt. Vielleicht ja einfach mit einem Piggypack auf dem Shift-Register, ist ja manchmal die einfachste Möglichkeit.

Der Tag ist gerettet.

Ich werde auf der neuesten IO-Platinen Version jetzt einfach einen SD-Karten Slot direkt On Board machen. Benötigt würden dann also noch ein 3,3V Spannungsregler, sowie Levelshifter und einen Inverter. Ich werde da auch keinen Micro SD-Slot, sondern einen ganz normal großen Slot draufpacken, der ist dann auch recht einfach zu löten.

Um die Anzahl der Bauteile noch zu reduzieren, nehme ich als Level-Shifter einfach ein 74LS136 vierfach XOR mit Open Collector Ausgängen.

Daraus kann ich dann für CS und MOSI nicht invertierende Ausgangstreiber mit 3,3V Pullup bauen, für SCK einen invertierenden Ausgangstreiber mit 3,3V Pullup und für MISO einen nicht invertierenden Eingangtreiber mit 5V Pullup, da ViH beim 74LS136 bei 2V liegt, sollte das also auch mit 3,3V Logikpegeln funktionieren. Ich spare mir somit also auch noch den einzelnen Inverter.

Für meine bestehende Platine werde ich so vorgehen:

Der Inverter kommt auf das Lochrasterfeld. Ebenso ein 6-pol Pin-Header, der dann einfach via Flachbandkabelverbinder (eventuell Leitungen vorher trennen und verdrillen, um Störungen auf den Adern zu vermeiden) mit dem bisherigen SPI-Anschluss verbunden wird.

Der SD-Kartenadapter kommt dann auch auf das Lochrasterfeld, mit vorgeschalteten Inverter bei SCK. Ich werden wohl den gewinkelten Pin-Header des SD-Card Adapters auslöten und den Adapter direkt, mit den Bauteilen nach oben, auf das Lochrasterfeld packen, dann wackelt der auch nicht rum. Natürlich irgendwas unterlegen, damit es keinen Kurzschluss gibt.

Ich finde das als Lösung eigentlich am Besten, da ich keine Platinenleitungen kappen muss, und die Verbindung zwischen SPI und Lochrasterfeld steckbar, also reversibel ist.

Gerade hab ich auch noch einen 6-Pol Wannenstecker und zugehörigem Flachband Quetschstecker gefunden. Was will man mehr.

Zitat von NorbertJ

ich möchte mich schon jetzt für ein Exemplar einer neuen Version der IO-Platine melden.

da sind wir schon zu Zweit.

Zitat von NorbertJ

wenn du eine neue I/O-Platine planst, magst du dann nicht gleich nach den Erfahrungen mit den Reed-Relais gleich ein Solid State Relais mit einplanen?

...das hatte ich befürchtet, dass die Frage nach dem Relais kommt. Ich war da ja bisher zu faul das noch zu machen aber OK, ich ändere das.

Zitat von DL8EBD

Jörg, schreibe mich dann doch bitte auch mit auf die Liste für eine neue I/O....

Hab ich vermerkt

Hier jetzt mal meine IO mit aufgeflanschtem SD-Card Adapter. Ich hab mir unter der Platine gleich noch für das SPI debugging die korrekten Signale rausgeführt.

Das Verbindungskabel kommt auch recht aufgeräumt daher.

Und hier sieht man mal, wie eine Tüte mit 600 MX Switches aussieht...ich werde die doch nicht hoffentlich nachzählen müssen .

Zitat von NorbertJ

Welche Lösung hast du denn da,

Einfach alle Signale der SPI-Buchse (MISO, MOSI, CS) bis auf SCK 1:1 auf den SD-Karten-Adapter ziehen. SCK von der Ausgangsbuchse auf einen Invertereingang des 74LS04 und den Ausgang des Inverters auf SCK des SD-Karten-Adapters.

GND und +5V kann man sich natürlich sparen über das Kabel zu führen, da das Lochrasterfeld ja oben +5V und unten GND führt. Ich hab die Spannungsversorgung trotzdem mit über das Kabel geführt, weil ich ja sowieso ein Flachbandkabel mit Quetschstecker genommen habe.

Zitat von klaly

Warum eigentlich Relais oder ... für die Datasette. Warum nicht einfach ein Transistor wie im C64.

ich hatte das Relais ursprünglich wegen der Nostalgie eingebaut. Ich werde jetzt dann wohl einen MOSFET nehmen.

Zitat von klaly

2. Falls es eine neue IO... geben sollte, noch ein Vorschlag für USB Host Interface: CH375B mit dem Teil will ich gerade etwas machen auch mit 6502, KIM-1 Nachbau. Damit kann man wohl (hoffentlich) relativ einen US Stick ankoppeln und auf Files zugreifen.

Ich denke, das USB-Board kann man dann auch über die VIA IOs ansteuern. Ich werde sowas aber nicht noch zusätzlich mit draufpacken, schon allein deshalb, weil ich dann nochmal einen Treiber in das ROM packen muss.

Wenn die SD-Karte funktioniert, dann sollte darüber ja auch ein schneller Datenaustausch möglich sein. Ansonsten möchte ich da eigentlich Old School bleiben.

Wenn ich noch eine weitere Interface-Karte mache, dann sicherlich eine Grafikkarte und da dann evtl noch einen Floppy- und IDE-Anschluss- Aber das ist erst mal Zukunftsmusik.

Übrigens Klaus, wenn du den Patch zum Abschalten der automatischen Baud-Ratenerkennung nutzen möchtest, brauchst du nur einen direkte Verbindung zwischen Pin 4 von U9 (74LS145) und Pin 11 (Port B 0) des Parallelausgangs ziehen. Mit einer Diode, wie vorgeschlagen, reicht es bei mir da oft nicht, dass ein sauberer Low Pegel erreicht wird.

Jetzt bin ich mal ein großes Stück mit der SPI Schnittstelle, bzw. dem SD-Card Reader weitergekommen.

Zuerst mal: Der Inverter in der Taktleitung wird NICHT benötigt. Meine Umbauten waren also völlig unnötig. Allerdings hab ich jetzt zumindes einen SPI-Debug Anschluss für den Logicanalyzer.

Mit Inverter zeigt zwar der Logicanalyzer die richtigen decodierten Werte an, allerdings werden von VIA dann die Eingangsdaten um einen Taktimpuls versetzt empfangen. Ohne Inverter funktioniert alles wie es soll, nur der LA kann nicht decodieren - so what.

Da war dann eben auch in einer SPI/SD-Card Beschreibung ein Satz bzgl. Taktpolung und -phase sehr hilfreich, der sonst nirgends zu finden war: "Thus the SPI mode 0 (CPHA=0, CPOL=0) is the proper setting to control MMC/SDC, but mode 3 (CPHA=1, CPOL=1) also works as well in most case".

Alle meine SD Karten funktionieren mit Mode 3 !

Das nächste Problem war - und dass war auch der Grund, warum ich zuerst dachte, die bestehende Schaltung funktioniert nicht - meine erste Test SD Karte. Diese funktionierte zwar wunderbar unter Windows, aber setzte nicht wie gefordert beim Einstecken die MISO Leitung auf HIGH, weshalb die Karte dann keine Antwort auf das Reset Kommando gab. Hier wurde erst nach dem Reset Commando (CMD0) MISO von Low auf High gesetzt. Man muss also diese Karte zwei mal resetten. Ich hab das in meiner Initialisierungsroutine jetzt auch berücksichtigt, so dass solche Ausreisser dann ebenfalls abgefangen werden.

Ansonsten sollte bei nicht gesteckter Karte MISO (wenn ich es richtig verstanden habe) eigentlich LOW sein. Das ist so bei mir definitiv nicht der Fall.

Hat da diesbezüglich von euch schon jemand Erfahrungen gemacht. Liegt das eventuell auch an dem genutzten SD-Card Adapter?

Was mir auch aufgefallen ist: Mit den Standards nimmt es keiner der Kartenhersteller so richtig ernst. So muss beim CMD0 Kommando grundsätzlich noch das gültige CRC Byte $95 anhängen, da hier die Karte noch nicht im SPI Modus und die CRC Prüfung noch eingeschaltet ist. Erst nach erfolgreicher Initialisierung benötigt man kein gültiges CRC-Byte mehr. Bei zwei von drei meiner Karten (Kingston) kann der CRC Wert allerdings bereits beim CMD0 irgendeinen Wert haben, eine Prüfung findet hier also nicht statt. Bei einer weiteren Karte (No Name) kommt bei falscher CRC dann gar kein Response Byte zurück, obwohl dieses dann mit gesetzten CRC-Error Flag von der Karte gesendet werden sollte.

Allo oben genannten Fälle hab ich jetzt soweit behandelt. Ich hoffe, es kommen nicht mit weiteren Karten weitere Probleme hinzu.

Die SPI Read und Write Routinen habe ich nun ohne Interrupt Handler programmiert, da sich hier die Zeiten, die zwischen zwei Datenbytes benötigt werden, sonst mehr als verdoppeln. Einfaches Polling ist hier wesentlich schneller.

Damit ich möglichst wenig Zeit verschwende, greife ich nun in den zeitkritischen Read/Write Routinen nicht auf die eigentlich benötigten indirekt indizierten LDA (IOBASE),Y / STA (IOBASE),Y Befehle zurück. Diese Befehle würden die Datenrate drastisch senken.

Ich kopiere stattdessen beim Initialisieren diese zwei (stattdessen mit normalen LDA/STA programmierten) Routinen vom ROM in das 128Byte RAM des 6532 RIOTS und patche dort die direkten Registeradressen, je nach eingestellter IOBASE Adresse. Alle Routinen, die Read/Write Aufrufen, machen das dann über die gepatchten Kopien im RAM.

Trotzdem der oben erwähnte Inverter ja nun doch nicht notwendig ist, werde ich übrigens dennoch wie angekündigt eine weitere IO-Board Revision mit direkt aufgelöteten SD-Card Sockel und der geänderten Datasetten-Motor-Ansteuerung machen. Alle alten Platinen können aber jetzt getrost ohne Patches mit SPI umgehen.

Ich hab jetzt von hans61 eine sehr hilfreiche Info bzgl. des genutzen SD-Karten Adapters und dessen Beschaltung bekommen. Hiernach lässt sich (zu mindest bei diesem Adapter) nicht über den Pegel der MISO Leitung feststellen, ob eine Karte vorhanden ist oder nicht.

Eventuell war da eine der von mir gefundenen Infos im Internet auch nicht korrekt und der Zustand von MISO ist für Detektierungszwecke garnicht relevant/einsetzbar.

Zitat von NorbertJ

Den einzigen Unterschied, den ich bisher bei SD-Kartenadaptern in einem einzigen Fall festgestellt habe ist, dass der Card Detection Switch bei dem einen Adapter ohne Karte offen und bei einem anderen geschlossen war, also dass umgekehrte Funktionalität bestand.

Der Card Detection Switch ist bei dem SD-Card Adapter leider nicht über eine Leitung herausgeführt, und sein Zustand daher irrelevant.

Ich werde das vorhandensein, bzw. einen Kartenwechsel jetzt einfach so detektieren, indem ich ein ausbleibendes Response Byte nach einem Befehl als Karte nicht vorhanden/Karte gewechselt interpretiere. Dann kann ich einen vollständigen Karten Reset machen und schauen, ob das Response Byte nun ankommt, wenn nein, werte ich das als Karte nicht vorhanden, wenn ja, wird die Karte Initialisiert und der fehlgeschlagene Befehl wird wiederholt.

Jetzt hab ich den Code mal so weit, dass SD-Karten mit 128MB, 2GB, 8GB und 64GB problemlos erkannt und initialisiert werden. Morgen werde ich mich dann mal an das Lesen einzelner Blöcke dran machen.