Posts by kbr

    Ah ja stimmt, es fängt also gar nicht erst an zu formatieren, sondern bricht nach dem Rattern gleich ab?

    (klingt mir irgendwie nach Track0-Einstellung)


    Schon mal versucht, das Laufwerk zu initialisieren?

    OPEN1,8,15,"I":CLOSE 1

    Vielleicht sind war da auch auf der falschen Fährte, auf so einen Software-Speedtest würde ich mich nicht verlassen, der kann eben auch Müll anzeigen, wenn es Leseprobleme gibt. Am sichersten wäre, das mal mit einem Oszi über den Index-Sensor(oder so) zu überprüfen.


    Hast du eigentlich schon mal versucht, eine Diskette zu formatieren?

    Der Elko ganz links sieht verdächtig aus mit dem Grünspan, der ist vermutlich hinüber, und dadurch wird die PWM-Steuerspannung nicht mehr sauber geglättet, es kommt zu Ruckeln, und das verfälscht zum Einen die Messung, und zum Anderen führt das natürlich zu Lesefehlern.


    Der Motor ist digital gesteuert über den CSB614 Resonator(ähnlich wie ein Quarz, nur nicht ganz so präzise) mit 614KHz als Grundtakt, 11x geteilt kommt man ziemlich nah an die 300 RPM ran(299.8), daher gibts da auch nichts einzustellen.

    Im schlimmsten Fall könnte der Resonator auch seinen Wert verändert haben, glaub ich aber nicht, ist mir noch nie untergekommen sowas, zu 99% sind das die Elkos.

    Ziemlich sicher 10µ und 16V, und das wäre auch mein Tipp gewesen, hatte schon mehrere Laufwerke mit so einem ausgelaufenem, defekten Elko. Da läuft der Motor dann nicht mehr rund, was zu den Leseproblemen führt. Der ist wohl für die Glättung der PWM-Steuerung zuständig.

    Interessanter Punkt, das Datenblatt sagt jedoch, daß bei Output immer feste Pegel anliegen, man kann daran ja auch direkt eine LED betreiben, so 10-20mA wird es schon sein, also kein open Collector. Das ist vermutlich auch das Problem, was dann viele haben in Kombination mit weiteren Geräten, die schaffen es dann nicht, den Pegel so weit nach unten zu ziehen. Da bei mir zuerst die 1050 kommt, und dann ein relativ langes Kabel(ca. 1.5m) zum SDrive-MAX, wirkt der Leitungswiderstand wohl als Pull-Up, und das genügt, damit die 1050 den Pegel weit genug drücken kann.

    Es wäre zu überlegen, beim Senden den Port immer zwischen In und Out umzuschalten, müsste man mal ausprobieren, ob das vom Timing her kein Problem macht.


    Beim RX-Input könnte man den internen Pull-Up zusätzlich aktivieren, da ich aber Arduino kompatibel bleiben möchte, ist das wohl eher keine Option. Sehe ich auch nicht unbedingt für nötig, der Atari liefert im Ruhezustand ja auch immer high-Pegel.

    Interessant, es kann auch ein Timing-Problem sein, daß etwas mit der Baudrate nicht stimmt, und das Sdrive-MAX den Befehl nicht erkennt.


    EDIT: Schwierig, ich würd jetzt an der Stelle mal das Oszi dranhängen und schauen, was da am RX-Pin am Arduino ankommt.

    Moin Ihr Lieben,

    die Bedienung der Standard Startsoftware (sdrive.atr) nach dem Einschalten kann auch mit dem Joytick für die Richtungen bedient werden.
    Leider funktioniert der Feuerbutten (Return) nicht. Gibt es da eine neuere Version?

    Eben in den Code geschaut, der Trick ist, man muß den Knopf gedrückt halten, und dann nach rechts bewegen, usw.

    Atmel-ice ist/war mir leider kein Begriff...


    Korrekt, aus Platzmangel musste die Touchscreenerkennung in den eeprom_writer wandern, daher ab V1.2 nun leider notwendig.


    Im Archiv ist eine Datei "doc/errorcodes.txt":


    SD-Card:

    1 error going into idle state

    2 error getting enhanced power requirements

    3 error on initialization for SD

    4 error on initialization for MMC

    5 error setting block length to 512


    FAT:

    1 error reading master bootblock

    2 error reading partition bootblock

    3 filesystem not supported


    SIO:

    1 CMD changed to high during data reception

    2 timeout

    3 usart frame error

    4 usart data overrun


    Deutet also auf ein Problem mit der COMMAND-Leitung hin. Macht der Atari die üblichen Blubbergeräusche?

    Das mit dem EEPROM-Preserv ist Quatsch, das trifft ja nur zu, wenn man über SPI flasht, was du aber offensichtlich gemacht hast. Bitte zukünftig immer dazusagen! Per USB wird das Flash ja per Software beschrieben, sprich da bleibt das EEPROM immer ehalten.


    Ich bin zu lange draußen aus dem Geschäft :gruebel


    EDIT: Den ganzen Aufwand mit dem eeprom_writer hab ich mir ja nur aus diesem Grund gemacht, damit jedermann ganz einfach per USB flashen kann. Per SPI kann man ja direkt das EEPROM beschreiben, dazu gibts im Build-Prozess auch eine .hex-Datei.

    Ja stimmt, low=0xff passt besser, da hab ich mich verklickt...


    Aber der Screenshot stammt vom sdrive-ng, da war noch einiges anders, z. B. 4K Bootloader, anderer Quarz, und low=0xFE ist ja nur eine kürzere Startup-Time, spielt also keine Rolle. Den Rest bitte nicht mit dem Sdrive-MAX vergleichen!


    EDIT: Und EEPROM-Preserv war bei mir bis jetzt bei jedem UNO standardmäßig gesetzt, macht ja auch Sinn, da man über den USB-Bootloader das EEPROM nicht direkt beschreiben kann. Wenn das dann jedes Mal gelöscht wird, ist das schon ziemlich blöd. Ich musste bislang noch nie was an den FUSE-Bits anpassen, wo hast du diese angeblichen Defaults her?

    PS: Ich hab den Atmega mit meinem Atmel-Ice programmiert (also ohne bootloader) und habe nirgends gefunden wie die fuses sein sollen, deshalb hab ich mal Uno standard mit ext. 16MHz angenommen. Stehen irgendwo die fuse bytes für das sdrive-max?


    Christian

    Nein, es gab bislang keinen Grund dazu, die Defaults haben sonst immer gepasst.

    Hoffentlich ist CKDIV8 nicht gesetzt, sonst passt das serielle Timing natürlich nicht!

    Ich denke, folgende Werte sollten passen:

    low: 0xC7 high: 0xD6(ohne Bootloader 0xD7) ext: 0xFF

    Also nach der Ausgabe hat die automatische Erkennung richtig funktioniert, warum es dann nicht geht, kann eigentlich nur sein, daß die Werte nicht richtig ins EEPROM geschrieben werden. Das Problem mit der SDRIVE.ATR spricht ebenso dafür. Ist auf deinem AVR möglicherweise das FUSE-Bit gesetzt, daß bei Chip-Erase das EEPROM automatisch mitgelöscht wird?

    Das könnte es erklären, daß das EEPROM nach dem Flashen der SDrive.hex wieder leer ist.

    Das sieht eigentlich alles richtig aus, vielleicht hattest du einen Finger auf dem Display während der Erkennung, das verfälscht das Ergebnis!


    Das mit der SDRIVE.ATR ist mir rätselhaft, versuch mal, daß dies nicht die erste Datei ist im Verzeichnis.


    Und warum nichts lädt, kann eigentlich nur an der Verkabelung liegen.

    Kannst du mal ein Bild von der Ausgabe des eeprom_writers anhängen?

    Welche Firmware nimmst du, bzw. für welche Display-Variante?

    Die SDRIVE.ATR liegt schon direkt im root-Verzeichnis, und in Großbuchstaben?

    (manche OS machen sonst nen Long-Filename draus, das könnte Probleme machen)