Immer diese Sonderlocken ![]()
Aber daran sieht man, wie schnell so ein winziges Detail vergessen wird, und sehr entscheidend sein kann...
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. Bitte melde dich an, um diesen Link zu sehen.
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.
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.
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?
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?
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)
nachdem ich wieder mal ein paar Laufwerke bauen will bräuchte ich wieder Nachschub an Crimp-Kontakten:
Bitte melde dich an, um diesen Link zu sehen.
bestellt demnächst jemand bei reichelt und könnte mir 20 Stk. mitbestellen?
bzw. hat noch jemand mal auf die Schnelle 10 Stk. übrig, die er mir zusenden könnte?
Ich hab noch genügend davon, schick dir gerne noch paar zu, weiter dann per Mail.
Also sozusagen noch während der Blubberphase...
Interessant, aber warum das dann nicht mit Gedrückthalten funktioniert? Wäre mal spannend herauszufinden, ob das an einer anderen Hardwarebeschaltung, oder an der anderen OS-Version liegt.
Gute Idee, quasi einen Tape-Boot vortäuschen, aber ob der 800er da dann wirklich einen richtigen Reset auslöst, oder nicht auch nur ins Memopad springt?
Ich bin leider selbst noch nie in die Verlegenheit gekommen, an einem echten Atari 800 zu sitzen...
Vermutlich bootet der 800er zu schnell.
Halte mal beim Einschalten die Reset-Taste gedrückt, warte bis sich das Sdrive-Max initialisiert hat, sprich das READY erscheint, und lass dann erst die Reset-Taste los.
Interessant, aber freut mich, daß es nun läuft. Das deutet aber sehr darauf hin, daß diese Displays eigentlich durch die QS geflogen sind, wenn man da solche Anpassungen an den Defaults vornehmen muß, was wohl wiederum den günstigen Preis erklärt. You get what you pay for ![]()
Ich war gestern bei Lidl, und wollte mir so eine 32GB microSD-Karte für 6,99€ holen, da die bei mir irgendwie nach ner Weile immer kaputt gehen, lassen sich dann meist nicht mehr beschreiben. Hab dann an der Kasse gefragt, dann hat er aus dem Lager noch eine Sandisk Ultra 128GB microSDXC gezogen. Für 9,99€ hab ich die dann natürlich mitgenommen, wollte schon immer mal wissen, ob die auch im Sdrive-MAX funktionieren, und nun kann ich es bestätigen:
SDXC-Karten funktionieren im Sdrive-MAX tadellos
Sicher? Hast du mal die Firmware für ILI9329 probiert? Da ist eigentlich nur das INVERT anders.
@Bitcoin bin dabei, insofern es sich mit Beruf und Familie zeitlich vereinbaren lässt. Regelmäßigere, kleinere, regionale Treffen sind mir persönlich eh lieber. Ich könnte mir sogar vorstellen, einen Club zu gründen, wenn sich entsprechendes Interesse zeigt.
So, nachdem ich mir nun neue Diag-ROM's besorgt habe, bekomm ich zumindest schon mal seriell eine Ausgabe: Bitte melde dich an, um diesen Anhang zu sehen.
Es sieht für mich so aus, daß der Budgie manchmal den Datenbus nicht durchschaltet, denn da kommen immer wieder mal 0xFF zwischen drin auf der Seriellen.
Vielleicht hat jemand sowas schon mal gesehen, und kann mir einen Tipp geben!