Ja, ich hatte das schon befürchtet, dass eine komplett andere Firmware notwendig sein wurde....die sources sind öffentlich auf GitHub ? Ich konnte ein versuch machen (Zeit is aber mein Feind....)

Ich habe ein kleines Batch file gemacht für die Mac.

Verschiebe der Batchfile (name: Flash Sdrive Max) in die richtige folder (also zum Beispiel atmega328-ili9341) und Doppel-clicke es.

Es furht die beide flash commando's automatisch aus.

Leider ist es sicher (noch) nicht völlig automatisch, man muss immer noch mittels
cd /dev
ls

die name für deine Arduino UNO ausfinden und das im Batchfile mit Tekseditor anpassen, also wo in meine situation:
tty.wchusbserial620

steht, muss jeder das Ergebnis aus der LS command liste hier ersetzen.

Es wurde viel netter sein wenn das automatisch erkennt und eingefüllt werden kann. Ich habe aber noch nie ein Batchfile für mein Mac geschrieben, ich habe also viel gegoogeld um dieser zu machen

Mmmmm, bitte vergessen sie die vorherige version des Batch file and auch das Bericht

Hier ist mein ganz neue Versuch

Jetzt braucht man nicht mehr "mit dem Hand" die Port name zu finden, das macht dieser Batch file selbst

Um sichert zu sein: Bitte verbinden sie nur EIN USB/Serial/Arduino device zum USB Porte ihres Mac.

Unzip die Datei, schleppen sie es zu die folder wo die richtige .HEX flash files stehen, und Doppel-clicken sie es (Flash Sdrive Mac Apple Mac).

Die Batch Datei versucht die name des Sdrive Max ports zu finden. Wenn es es nicht findet teilt es das mit and beendet sich selbst.

Wenn ein port gefunden is wird die name des port widergegeben und gefragt die Flash versuch zu machen. Jetzt soll alles autpmatisch ablaufen.

Bitte verstehen sie das es auf MEIN Mac und MEIN Sdrive Max functioniert....UND das dieser Batch Datei mein erster Mac Batch Datei ist, also wenn das nicht richtig funktioniert bitte berichten sie mir......and Sehr gerne auch wenn das richtig funktioniert.

KBR vielleicht kann dieser Batch Datei in jeden version der firmware mitgeliefert werden ? Es soll in jeder folder (abhängig von display) kopiert werden. Benutzer brauchen dann nur ein Doppel-click auf die Batch Datei

Das ist nett gemeint, aber betriebssystemabhängige Dinge, die ich nicht selber testen und pflegen kann, möchte ich nicht mit ausliefern.

PS: Und ja, die Sourcen sind auf github: https://github.com/kbr-net/sdrive-max

Habe gerade gesehen das die Version V0.8 bereits veröffentlicht wurde.

I updated my batch-file for the Mac. As I made a second unit and flashed it, it showed some problems with loading XEX files (ATX's and ATR's worked fine..... strangely).

My script didn't wait for the first flash action to complete and went to the second flashing stage right away while I could see the first progress bar still increasing.

This error was hidden because I had obviously already flashed my first (own) Sdrive-Max and so it already had the flashed data of the first flash I guess....

I added a pause of 10 seconds between the two flash-stages and a Message is shown to inform the user to wait.

Please delete the V1.0 version and only use this new V1.1 as V1.0 will not render a good working Sdrive-Max when flashing a new unit.

Would love any feedback....

Hi,

vielleicht hab ich es ja überlesen - aber ich brauche unter Windows wohl einen Treiber für das bislang unbekannte Gerät "USB2.0-serial".

Wo bekomme ich den her? Von selber findet W7x64 da nix.

Viele Grüße

Erhard

Erhard hat geschrieben:ich brauche unter Windows wohl einen Treiber für das bislang unbekannte Gerät "USB2.0-serial".
Wo bekomme ich den her?

Bitte sehr:
https://www.arduino.cc/download_handler.php
https://www.arduino.cc/en/Guide/DriverInstallation

It looks like a new version of the software has been released on Github, V1.0b

Several improvements are made, f.i. a de-bounce during the calibration process.

Level42 hat geschrieben:It looks like a new version of the software has been released on Github, V1.0b

Several improvements are made, f.i. a de-bounce during the calibration process.

Es ist die Beta Version 10b, wird im Display als V1.0b ausgegeben und ist hier zu bekommen:
http://atariage.com/forums/topic/283750 ... ves/page-3
Mit der Version können fast alle ATX-Files geladen werden. Top Job von Daniel

Hi,

danke für die Hinweise.

Hat prima funktioniert, die aktuelle Firmware ist drauf.

Viele Grüße

Erhard

Gibt es Erfahrungswerte für den Ausdruck des Gehäuses im "XL-Style"? Lässt sich das "face down", d.h. mit der Bildschirmseite auf dem Drucktisch ohne Support drucken, um eine glatte Außenseite zu bekommen, oder ist es besser, es mit der Oberseite nach oben zu drucken und dafür jede Menge Support aus dem Inneren zu entfernen?

Danke!

Wird das SDrive-Max nicht alleine am SIO-Bus betrieben, gibt es Probleme mit RX. Verursacht werden sie durch die interne Verbindung vom Atmega zum USB Chip, Open Collector für den SIO-Busbetrieb ist so nicht mehr möglich. Setzt man zwischen RX ein Open Collector Chip zum SIO-Bus, klappt alles. Zur Zeit benutze ich 2 Open Collector Inverter dafür, einen 74LS05. Dieser wird durch ein 74LS07 ersetzt. Die Diode entfällt, der 74LS07 übernimmt die Funktion. Eine Schaltplanänderung folgt von mir wenn alles getestet ist.

Bye,
Bernd

Hallo Bernd,

auf welcher Seite besteht das Problem (Atari oder SDrive-MAX) bzw. welches RX meinst Du? Vermute das RX am SDrive-MAX?

Viele Grüße

Erhard

Moin,

Bernd hat geschrieben:Wird das SDrive-Max nicht alleine am SIO-Bus betrieben, gibt es Probleme mit RX. Verursacht werden sie durch die interne Verbindung vom Atmega zum USB Chip, Open Collector für den SIO-Busbetrieb ist so nicht mehr möglich. Setzt man zwischen RX ein Open Collector Chip zum SIO-Bus, klappt alles. Zur Zeit benutze ich 2 Open Collector Inverter dafür, einen 74LS05. Dieser wird durch ein 74LS07 ersetzt. Die Diode entfällt, der 74LS07 übernimmt die Funktion. Eine Schaltplanänderung folgt von mir wenn alles getestet ist.

Hmm - wenn der betroffene Pin als Eingang deklariert wird, dürfte das doch nicht zu Problemen kommen? Das "normale" S-Drive macht es auch nicht anders, und da funktioniert es auch. Wo genau liegt das Problem?

Und neugierige Frage - warum nicht einfach eine Shottky-Diode in Richtung Atari einschleifen plus ggf. ein Pullup-Widerstand an der Ausgangsseite des MCU (wobei auch das normal in der Port-Pin-Config gemacht werden kann)?

Grüße, Jürgen

Hallo!
Ich habe ein Problem mit meinem SDrive-max:
Da es nicht richtig funktionierte (ich habe es nicht selbst zusammengebaut) habe ich ein bisschen rumprobiert.
Dabei habe ich in "Cfg" die Buttons "rotate" und "scroll" betätigt. Der Bildschirm hat sich gedreht und nun funktionieren die Schaltflächen nicht mehr korrekt. Ich kann es also nicht mehr richtig bedienen.
Wie kann ich das rückgängig machen?

Viele Grüße,
Jens.

Ich bin nicht sicher - aber Du könntest probieren, die Datei SDRIVE.ATR neu auf die SD-Karte zu machen. In dem ATR ist eine Datei namens SDRIVE.CFG. Ich weiß allerdings nicht, ob die von Dir genannten Einstellungen darin gespeichert werden.

CU, Erhard

Erhard hat geschrieben:Ich bin nicht sicher - aber Du könntest probieren, die Datei SDRIVE.ATR neu auf die SD-Karte zu machen. In dem ATR ist eine Datei namens SDRIVE.CFG. Ich weiß allerdings nicht, ob die von Dir genannten Einstellungen darin gespeichert werden.

CU, Erhard

Hallo!
Danke für den Tipp.
Leider hat es nicht funktioniert...
Der Bildschirm ist immer noch gedreht und die Schaltflächen sprechen nicht mehr an...

Gruß,
Jens.

Hi,

nimm mal die SD-Karte raus und halte mal beim Einschalten das Display gedrückt.

CU, Erhard

Erhard hat geschrieben:Hi,

nimm mal die SD-Karte raus und halte mal beim Einschalten das Display gedrückt.

CU, Erhard

Super - das wars!!
Vielen Dank für den Tipp!!

Viele Grüße,
Jens.

p.s. wahrscheinlich melde ich mich gleich nochmal wegen des eigentlichen Problems...

tfhh hat geschrieben:Moin,

Bernd hat geschrieben:Wird das SDrive-Max nicht alleine am SIO-Bus betrieben, gibt es Probleme mit RX. Verursacht werden sie durch die interne Verbindung vom Atmega zum USB Chip, Open Collector für den SIO-Busbetrieb ist so nicht mehr möglich. Setzt man zwischen RX ein Open Collector Chip zum SIO-Bus, klappt alles. Zur Zeit benutze ich 2 Open Collector Inverter dafür, einen 74LS05. Dieser wird durch ein 74LS07 ersetzt. Die Diode entfällt, der 74LS07 übernimmt die Funktion. Eine Schaltplanänderung folgt von mir wenn alles getestet ist.

Hmm - wenn der betroffene Pin als Eingang deklariert wird, dürfte das doch nicht zu Problemen kommen? Das "normale" S-Drive macht es auch nicht anders, und da funktioniert es auch. Wo genau liegt das Problem?

Und neugierige Frage - warum nicht einfach eine Shottky-Diode in Richtung Atari einschleifen plus ggf. ein Pullup-Widerstand an der Ausgangsseite des MCU (wobei auch das normal in der Port-Pin-Config gemacht werden kann)?

Grüße, Jürgen

Hi Jürgen,
der Schaltplan liegt im Anhang, das Problem ist rot gekennzeichnet. Der Atmega hat über zwei 1k Widerstände Verbindung zum USB-Chip, darüber läuft die Kommunikation. Hat der Atmega einen DIP-Sockel, ziehst den Pin 2 aus den Sockel und verbindest diesen direkt mit der SIO-Schnittstelle, gibt es keine Probleme am SIO-Bus. Danach ist aber ein Softwareupdate über USB nicht mehr möglich. Ohne Hardwareänderungen hilft nur ein 74LS07, hatte aber noch keine Zeit den einzusetzen. Ein Testlauf mit einem 74LS05 mittels zwei Inverters lief erfolgreich, eine Diode funktioniert hier nicht.

Gruß,
Bernd