Hello, Guest the thread was called33k times and contains 151 replays

last post from Enzo1960 at the

Sd2Iec 0.10.3 - Lcd

  • Die Stromversorgung war nur fürs Einspielen und ersten Test. Im Regelbetrieb werden die 5V übern Kasettenport abgegriffen.


    Nachdem die Autoswap nicht funkte hab ich angenommen der Reader hat iwo nen Fehler und habs am C128 gar nicht probiert bzw warte ich noch aufs Monitorkabel da das alte iwo nen Kabelbruch.Bin gestern sicher ne Stunde im Netz verwirrt herumgeirrt wegen der Autoswap. Einmal stehts mit Backslash und Doppelpunkt dann wieder nur der Dateiname.....ist für nen Noob gar nicht so einfach
    8):D
    Auf alle Fälle danke für eure Tipps und sobald das Kabel da(heut oder morgrn) werde ichs direkt ausprobieren :)

  • Bin gestern sicher ne Stunde im Netz verwirrt herumgeirrt wegen der Autoswap. Einmal stehts mit Backslash und Doppelpunkt dann wieder nur der Dateiname.....ist für nen Noob gar nicht so einfach

    Backslash ist grundsätzlich falsch, kann aber in manchen Situationen trotzdem funktionieren weil der Teil vor dem Doppelpunkt ziemlich lax ausgewertet wird und komplett ungültige Angaben dort ignoriert werden.


    Doppelpunkt braucht es nur, wenn man einen kompletten Pfad zu einer Datei angeben will - wenn man das nicht macht, versucht sd2iec die benannte Datei im gleichen Verzeichnis wie die autoswap.lst zu finden. Die von dir verwendete Variante "//:bla.d64" steht z.B. dafür, dass die Datei auf jeden Fall im Hauptverzeichnis (unter Windows "\") der SD-Karte gesucht werden soll.

  • Cool :) So eine Beschreibung hätt ich gestern gesucht.


    Ich hoffe es klappt mit dem / . Falls das Kabel heut nicht kommt und der Sd2iec wieder nur das Grundbild zeigt ohne Reaktion aufs rein/raus der Sd bzw. Vor/ zurück: Kann ich das ohne Commodore feststellen wo der Fehler ist?Paar typische Fehlerquellen die man mittels Multimeter rausmessen kann (Pins für Cd und Cw sind auf Masse da der Reader diese nicht herausgeführt), würden den Ergeiz fürs Projekt erheblich im vorhinein steigern.


    Ist halt wie ne Fehlersuche bei nem alten Auto. Da sucht man sich tw zu nem Deppen und dann wars ein Massefehler....

  • So eine Beschreibung hätt ich gestern gesucht.

    Es gibt da dieses README zur Firmware...


    Quote

    Falls das Kabel heut nicht kommt und der Sd2iec wieder nur das Grundbild zeigt ohne Reaktion aufs rein/raus

    (...)

    Quote

    (Pins für Cd und Cw sind auf Masse da der Reader diese nicht herausgeführt)

    Wie soll sd2iec denn auf Einstecken bzw. Entfernen der SD-Karte reagieren können, wenn es davon nichts mitbekommen kann?


    Selbst wenn der Card Detect Pin angeschlossen wäre gäbe es allerdings beim Wechsel erstmal keine Reaktion, weil das in manchen Situationen den Zugriff auf andere Laufwerke deutlich verzögern könnte.


    Quote

    der Sd bzw. Vor/ zurück

    Die reagieren nicht, wenn keine autoswap.lst im aktuellen Verzeichnis gefunden wurde oder die Einträge daraus alle nicht mountbar sind (glaube ich, lange nicht getestet...).


    Ohne C64 dran wird man damit aber wahrscheinlich eh nichts erreichen können - dem Foto nach hast du eine Billigversion ohne vernünftige Bustreiber, da gibts an den IEC-Pins nicht mal Pullups. Wenn kein C64 angeschlossen ist, wird wahrscheinlich auf der ATN-Leitung ein Low-Pegel erkannt und deswegen wird die Firmware wahrscheinlich in einer Schleife auf weitere "Bewegung" auf dem Bus warten - an der Stelle werden die Tasten komplett ignoriert.


    Quote

    Paar typische Fehlerquellen die man mittels Multimeter rausmessen kann , würden den Ergeiz fürs Projekt erheblich im vorhinein steigern.

    Eine typische Fehlerquelle ist ein nicht oder falsch angeschlossener Card Detect-Schalter am SD-Sockel, so dass sd2iec gar keine Karte erkennt und nur Fehler liefert - deswegen gibts dafür einen Diagnosemodus (beim Einschalten "zurück" gedrückt halten). Eine weitere typische Fehlerquelle ist ein fest auf Masse gelegter Card Detect-Pin am AVR, durch den möglicherweise Datenverlust entstehen könnte - irgendwann muss ich mal testen, ob man zuverlässig eine ID von der Karte lesen kann und bei unerwartetem Wechsel der ID sämtliche weiteren Zugriffe bis zum nächsten Reset sperren.


    Quote

    Ist halt wie ne Fehlersuche bei nem alten Auto. Da sucht man sich tw zu nem Deppen und dann wars ein Massefehler....

    Das ist ein weiterer beliebter Fehler: Spannung von einem externen Netzteil, am IEC-Bus nur ATN/Clock/Data angeschlossen, aber keine Masseverbindung zwischen C64 und sd2iec.

  • Ich habe mir vor kurzem ein SD2IEC in der larsp Version inkl. LCD (bereits fertig zusammengebaut) zugelegt. Da noch die "alte" Version 0.10.3 installiert war, wollte ich die 1.0.0alpha0 ausprobieren, da sich ja inzwischen einiges im Projekt getan hat.


    Habe dann etwas recherchiert und bin auf diesen Thread gestoßen. Ich habe mir den Patch für 0.10.3 von hier geschnappt und für die aktuelle git Version von SD2IEC angepasst. Leider bin ich kein Entwickler, also bin ich mir nicht sicher, ob ich das "richtig" gemacht habe. Jedenfalls hat die Firmware einwandfrei kompiliert und ich habe eine passende "sd2iec.bin" erhalten. Diese habe ich kurzum auf eine 4GB SD-Karte kopiert, die ich mit einer 1GB Partition partitioniert und in FAT16 formatiert habe.


    Nun passiert beim Einschalten folgendes: Die grüne LED leuchtet etwa für 6 Sekunden kontinuierlich und geht dann wieder aus. Danach fährt das System normal hoch und zeigt wieder die alte Version (0.10.3) an. Wäre ja zu einfach gewesen :)


    Hat jemand von euch eine Idee, oder einen Tip?

  • Hat dein LCD-SD2IEC überhaupt einen Bootloader?
    Auch die Größe der Bin-datei muss speziell sein, ansonsten wird sie vom Bootloader nicht erkannt.


    Ansonsten hilft nur ein AVR-Programmer, wenn das Kompilat denn funktionstüchtig ist.
    Hatte letzte Woche auch so meine Schwierigkeiten, ich konnte es zum Beispiel nur ohne Eeprom-Filesystem kompilieren, eine funktionierende Bin-Datei ist dabei aber nie rausgekommen, dafür ging aber das Hex-File.


    PS: Kann erst wieder am Sonntag was schreiben, da Morgen DoReCo ist.

  • Nun passiert beim Einschalten folgendes: Die grüne LED leuchtet etwa für 6 Sekunden kontinuierlich und geht dann wieder aus. Danach fährt das System normal hoch und zeigt wieder die alte Version (0.10.3) an. Wäre ja zu einfach gewesen :)


    Hat jemand von euch eine Idee, oder einen Tip?

    Klingt so, als ob der Bootloader "Kandidaten-Dateien" auf der Karte findet (passende Dateigrösse), aber sie wegen falscher CRC, falscher Hardware-ID oder falscher Versionsnummer (kleiner als die installierte, aber nicht 0) ignoriert.


    Hatte letzte Woche auch so meine Schwierigkeiten, ich konnte es zum Beispiel nur ohne Eeprom-Filesystem kompilieren

    Meine Glaskugel vermutet, dass dein gcc zu alt ist und die Fehlermeldungen meinten, dass "_Static_assert" unbekannt wäre. Ist natürlich nur geraten, ohne die Fehlermeldungen zu kennen lässt sich sowas eher schlecht diagnostizieren.


    Quote

    eine funktionierende Bin-Datei ist dabei aber nie rausgekommen

    Ich rate nochmal: Beim CRCGEN-Schritt gabs eine Fehlermeldung?

  • Ich rate nochmal: Beim CRCGEN-Schritt gabs eine Fehlermeldung?

    Richtig geraten. "_Static_assert" kannte er nicht. Habe es unter Windows mit WinAVR kompiliert, das ist wohl das Problem, da es da schon lange keine Updates für gibt.


    Wie macht man es denn eigenlich richtig, unter Linux?

  • Richtig geraten. "_Static_assert" kannte er nicht. Habe es unter Windows mit WinAVR kompiliert, das ist wohl das Problem, da es da schon lange keine Updates für gibt.

    Ohje, dann ist das gcc 4.5 oder älter. Liefert Atmel nicht inzwischen selbst einen gcc mit ihrer Entwicklungsumgebung aus?


    Quote

    Wie macht man es denn eigenlich richtig, unter Linux?

    Ich compiliere unter Linux, es soll wohl auch mit *BSDs funktionieren. Mindestanforderung sind neben einem avr-gcc (mindestens Version 4.6, besser 4.8 weil der kleinere Binaries erzeugt) noch ein GNU make und Perl 5.10 oder neuer - prinzipiell sollte das auch unter Windows erfüllbar sein, notfalls mit Msys oder Cygwin.

  • Danke euch für die schnellen Antworten!


    Hat dein LCD-SD2IEC überhaupt einen Bootloader?
    Auch die Größe der Bin-datei muss speziell sein, ansonsten wird sie vom Bootloader nicht erkannt.


    Bootloader müsste drauf sein, sonst würde er ja beim Starten mit der eingelegten SD-Karte nicht über sechs Sekunden was "lesen", oder?


    Zur Dateigröße: Die entspricht der jeweiligen Datei aus den offiziellen SD2IEC nightlies. Insofern gehe ich mal nicht davon aus, dass es daran liegt :)


    $ du -b sd2iec*.bin
    126976 sd2iec-1.0.0alpha0-95-g73243ee-larsp-m1284p.bin
    126976 sd2iec.bin


    Klingt so, als ob der Bootloader "Kandidaten-Dateien" auf der Karte findet (passende Dateigrösse), aber sie wegen falscher CRC, falscher Hardware-ID oder falscher Versionsnummer (kleiner als die installierte, aber nicht 0) ignoriert.


    Die Versionsnummer müsste mit "1.0.0alpha0" ja höher sein als "0.10.3". Bzgl. CRC kann ich nicht viel sagen, CRCGEN ist ohne Fehler durchgelaufen. Bzgl. Hardware ID musst du mich aufklären ^^


    PS: Ich habe in der "Makefile.main" noch das "PRERELEASE" von "alpha0" auf "LCD" gesetzt, weil es im alten Patch auch so drin war. Diese Info liest der Bootloader aber sicher nicht aus, oder?


    EDIT: Erhalte gerade vom Ersteller der Platine den Hinweis, dass der Bootloader nicht geflasht wurde, na prima. Irgendwie aber unlogisch, denn dann würde er ja wohl kaum bei eingelegter SD-Karte mit der sd2iec.bin ein paar Sekunden beim Starten versuchen zu lesen, oder?

  • Die Versionsnummer müsste mit "1.0.0alpha0" ja höher sein als "0.10.3". Bzgl. CRC kann ich nicht viel sagen, CRCGEN ist ohne Fehler durchgelaufen. Bzgl. Hardware ID musst du mich aufklären ^^

    Die für den Bootloader interessante Versionsnummer ist ein 16-Bit-Wert, der sollte automatisch auf 0 ("Entwicklungsversion", wird immer geflasht) stehen wenn PRERELEASE ein nicht-leerer String ist. Die Hardware-ID ist eine Kennung die sagt, für welche Hardware-Variante das Binary ist - wenn das gleichzeitig erzeugte Hex-File auf deiner Platine funktioniert, dann hat das .bin-File auch die richtige Hardware-ID.


    Quote

    Erhalte gerade vom Ersteller der Platine den Hinweis, dass der Bootloader nicht geflasht wurde, na prima. Irgendwie aber unlogisch, denn dann würde er ja wohl kaum bei eingelegter SD-Karte mit der sd2iec.bin ein paar Sekunden beim Starten versuchen zu lesen, oder?

    Na ja, eine andere Variante wo es beim Einschalten noch hängen kann ist die Initialisierung der SD-Karte. Manche Karten sind frisch nach dem Einschalten etwas zickig.

  • Die für den Bootloader interessante Versionsnummer ist ein 16-Bit-Wert, der sollte automatisch auf 0 ("Entwicklungsversion", wird immer geflasht) stehen wenn PRERELEASE ein nicht-leerer String ist. Die Hardware-ID ist eine Kennung die sagt, für welche Hardware-Variante das Binary ist - wenn das gleichzeitig erzeugte Hex-File auf deiner Platine funktioniert, dann hat das .bin-File auch die richtige Hardware-ID.

    Danke dir für die Infos!


    Das Hex-File lässt sich laut Platinenersteller einwandfrei flashen und läuft auch wie gewünscht. Ich werde mir jetzt einen AVR Programmer besorgen und mir den Bootloader selbst drauf flashen, damit das mit den Updates über SD-Karte einfacher klappt.


    Habt ihr da eine Programmer Empfehlung? Würde gerne mit avrdude flashen, da ich hauptsächlich unter Linux arbeite. Chip ist ein ATmega 1284p.


    Na ja, eine andere Variante wo es beim Einschalten noch hängen kann ist die Initialisierung der SD-Karte. Manche Karten sind frisch nach dem Einschalten etwas zickig.


    Da hattest du natürlich recht: Wenn ich das sd2iec.bin von der Karte runter lösche, verhält es sich genauso. Wenn ich dann eine andere SD-Karte einlege, leuchtet die grüne LED nur für einen Sekundenbruchteil und der SD2IEC ist dann sofort betriebsbereit :)

  • Hallo,


    versuche gerade mit den Sourcen aus dem offiziellen Git-Repo die Firmware für den "zweiten" AVR zu bauen.
    Leider scheinen aber Dateien zu fehlen - oder ich mache irgendwas falsch?
    Probiert habe ich folgendes:
    1.) ins Verzeichnis "lcd-i2c" und dann:

    Code
    1. make CONFIG=config-example
    2. MKDIR obj-m644-example
    3. CONF2H config-example
    4. gawk: fatal: can't open source file `../conf2h.awk' for reading (No such file or directory)
    5. make: *** [obj-m644-example/autoconf.h] Error 2


    Hmm, fehlt also die Datei "../conf2h.awk".
    Nach kurzer Recherche habe ich diese dann in den Sourcen der alten Version "sd2iec-0.10.3.tar.gz" gefunden und entsprechend ins Hauptverzeichnis kopiert.
    2.) Also nochmal:


    Code
    1. make CONFIG=config-example
    2. MKDIR obj-m644-example
    3. CONF2H config-example
    4. CC encoder.c
    5. encoder.c:29:19: fatal error: timer.h: No such file or directory
    6. #include "timer.h"
    7. ^
    8. compilation terminated.
    9. make: *** [obj-m644-example/encoder.o] Error 1

    Jetzt fehlt also die Header Datei "timer.h" (zumindest eine im lcd-i2c Verzeichnis, relativ zu lcd-i2c/timer.c). Die Hauptfirmware(s) konnte ich fehlerfrei bauen, so dass meine Toolchain zumindest dort funktioniert.



    Hilfe wäre sehr willkommen,
    Gruß, trictas

  • versuche gerade mit den Sourcen aus dem offiziellen Git-Repo die Firmware für den "zweiten" AVR zu bauen.
    Leider scheinen aber Dateien zu fehlen - oder ich mache irgendwas falsch?

    Ja, das ist kaputt. Bau es aus den 0.10.3-Sourcen.

  • Hello guys, interesting read.


    If going for the simpler DOG-M display, the official firmware release won't handle that? Only the bin files in this thread?
    Anything from https://sd2iec.de/ will be a no go?
    ... or is this type also added into the official code and can be activated if compiling it yourself?


    (sorry for the English, my German isn't very good, hate to sound like a German four-year-old or something trying to find proper words and grammar)