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

Quote from MartinGoodwell

Das Verhalten hat sich nicht geändert.

Und: der Speed Test bringt jetzt sogar 419 Umdrehungen, wo vor dem Elko-tausch noch 407 Umdrehungen gezeigt wurden.

Bei der LED fällt mir jetzt aber auf, dass sie nach dem Speedtest 5 oder 6 mal blinkt, dann für ca 4 Sekunen leuchtet, und dann wieder blinkt, und so weiter.

Keine Ahnung, ob das gestern auch schon so war...

Dann werd ich wohl trotzdem mal alle Elkos austauschen - gegen Neue. Die aus meiner Kiste liegen da ja auch schon Jahre lang drin.

Display More

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?

Quote from kinzi

4µ7 meine ich hatte der, als ich auf meine Platine geschaut hatte.

Könnte man sicher auch mal einen 10µF versuchen, das ist der Wert, der meist in 3,5" Laufwerken dafür eingesetzt wird.

EDIT: Oder 2x 10µF in Reihe, dann hat man 5µF

Was hat der für einen Wert, 10µF?

Quote from kinzi

kbr Das Foto ist von meiner Platine.

ich meinte schon das Bild von 1571 knattert und FILE NOT FOUND

Deiner hat auch keinen Grünspan

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.

Immer diese Sonderlocken

Aber daran sieht man, wie schnell so ein winziges Detail vergessen wird, und sehr entscheidend sein kann...

Freut mich, daß es läuft!

Aber normalerweise ergibt sich der Pull-Up anhand des 1K Widerstandes zum Seriell-/USB-Wandler, der im Ruhezustand ein high liefern sollte. https://www.arduino.cc/en/uplo…no_Uno_Rev3-schematic.pdf

Daher macht es keinen Sinn, den per Software zu aktivieren, einmal reicht

PS: Ich betreibe ja nach wie vor alle meine SDrive-MAX ohne diesen 7407, und hatte damit noch nie Probleme, auch nicht zusammen mit einer 1050.

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.

Quote from castlewolfenstein

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.

Quote from vossi

Ich hatte geschrieben, das ich mit dem Atmel-ice programmiert habe.

Das eeprom könnte ich natürlich auch direkt schreiben, aber der eeprom writer macht ja wohl bei der v1.2 auch die Touchscreen Erkennung und schreibt da etwas ins eeprom ?

Beim Einschalten des Atari 800XLs kommt im Monitor mehrfach SIO-Error: 1

Kannst du mir sagen, was das bedeutet?

Display More

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

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.

Wenn du unten auf das READY-Fenster drückst, dann wird ein SIO-Monitor gestartet. Kommt da irgendwas beim Booten?

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?

Quote from vossi

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)