SD2IEC LCD-Ansteuerung


  • DerSchatten
  • 1369 Aufrufe 25 Antworten

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • SD2IEC LCD-Ansteuerung

    Grüß euch,
    die Frage richtet sich in erster Linie an Unseen da er die Software entwickelt hat, bin aber auch für jede andere Hilfe sehr dankbar.

    Ich möchte gerne die LCD-Ansteuerung um den MENÜ-Punkt "KERNAL" erweitern. Damit soll es dann möglich sein zwischen 4 KERNALs zu wechseln.
    Und zwar habe ich mir überlegt die noch freien PINs (PD5 PD4 PD3 PD2) am Display-ATMEGA zu verwenden.
    Diese müßen je nach Auswahl auf HI gelegt werden.

    Quellcode

    1. KERNAL 1 ... PD5, PD4 -> HI
    2. PD3, PD2 -> LO
    3. KERNAL 2 ... PD5 -> HI
    4. PD5, PD3, PD2 -> LO
    5. KERNAL 3 ... PD5 -> HI
    6. PD4, PD3, PD2 -> LO
    7. KERNAL 4 ... PD5, PD4, PD3, PD2 -> LO


    Das ganze sollte dann im Prinzip so wie die Auswahl der Floppyadresse aussehen.
    Also zuerst das Menü KERNAL und dann das Untermenü zur KERNAL-Auswahl.
    Nach der Auswahl sollte Formhalber ein Reset durchgeführt werden.

    Bisher habe ich folgende Einträge gemacht:
    display.c

    Quellcode

    1. static const PROGMEM char systemmenu[] = {
    2. "\xc3""HANGE DIRECTORY\0"
    3. "\xc3""HANGE ADDRESS\0"
    4. "\xc3""HANGE KERNAL\0"
    5. "\xd3""TORE SETTINGS\0"
    6. "\xc3""ANCEL\0"
    7. };
    8. #define SYSMENU_CHDIR 0
    9. #define SYSMENU_CHADDR 1
    10. #define SYSMENU_KERNAL 2
    11. #define SYSMENU_STORE 3
    12. #define SYSMENU_CANCEL 4
    13. static enum { MENU_NONE = 0, MENU_SYSTEM, MENU_CHDIR, MENU_CHADDR, MENU_CHKERN } menustate;
    Alles anzeigen


    Nur, wie gehts weiter?

    -= Neu in meiner Sammlung / Modding =-

    Nichts hält länger als ein Provisorium
  • Keine schlechte Idee wenn man das SD2IEC direkt im CeVi verbaut, so spart man den Kernel Umschalter. Von der Bedienung her dürfte aber der Kernelumschalter einfacher sein.


    Den letzten aktivierten Kernel sollte man im EEPROM speichern und beim neustart wieder herstellen.
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung
  • DerSchatten schrieb:

    Nur, wie gehts weiter?


    Auf jeden Fall erst mal erst mal die entsprechenden Ausgänge in der Init-Routine des Controllers als Ausgänge definieren - soweit mir bekannt, sind die nach Reset erst mal hochohmig und dann hängen Deine Adressleitungen in der Luft.
    Dann mit einem definierten Wert, z.B. dem letzten gewählten aus dem EEPROM initialisieren.
    Das wird nur dann klappen, wenn die 6502 etwas später startet als der Atmel - sonst schaltet der Atmel den Kernel um, wenn die 6502 schon läuft. Über die Fuses kannst Du aber in einem gewissen Rahmen an der Start-up Zeit drehen, und bei Commodore-Seite könnte man zur Not einen Widerstand tauschen um Einfluss auf die Dauer zu nehmen, die Reset nach power-on low ist.
  • for(;;) schrieb:

    Das wird nur dann klappen, wenn die 6502 etwas später startet als der Atmel - sonst schaltet der Atmel den Kernel um, wenn die 6502 schon läuft. Über die Fuses kannst Du aber in einem gewissen Rahmen an der Start-up Zeit drehen, und bei Commodore-Seite könnte man zur Not einen Widerstand tauschen um Einfluss auf die Dauer zu nehmen, die Reset nach power-on low ist.
    Das wäre ja nicht das problem. Man kann ja nach dem einschalten und dem auslesen der Einstellung einen kurzen Reset initieren.
    Die Speicheroption ins EEPROM existiert auch bereits im Code.

    Auf jeden Fall erst mal erst mal die entsprechenden Ausgänge in der Init-Routine des Controllers als Ausgänge definieren

    Daran habe ich auch als ersters gedfacht. Nur leider bin ich des C nicht so mächtig das ich jetzt auf Anhieb wüßte wo das definiert wird.

    -= Neu in meiner Sammlung / Modding =-

    Nichts hält länger als ein Provisorium
  • DerSchatten schrieb:

    Das wäre ja nicht das problem. Man kann ja nach dem einschalten und dem auslesen der Einstellung einen kurzen Reset initieren.
    Die Speicheroption ins EEPROM existiert auch bereits im Code.


    wäre es nicht sinnvoller um schreibzugriffe aufs eprom zu minimieren, wenn man NUR ins eprom schreibt wenn der inhalt ein anderer ist? sprich anderer kernel?

    zudem.... den reset auch NUR wenn ein anderer kernel aktiv ist... sonst macht er ja IMMER den reset... ich zb nutze zu 99% jiffydos... dann bräuchte der da nicht dauernd resetten


    ps: hatte da auch schon dran gedacht an so ne schaltung... jedoch dachte ich halt, der atmel bekommt seinen strom zum gleichen zeitpunkt wie der c64 selbst.. somit ist der kernel bereits "aktiv"
    ist kernelschaltung bei eingeschaltetem c64 denn ungefährlich?
    ich meine in der jiffy anleitung steht, daß jiffy das sogar unterstützen würde!
  • jackdaniels schrieb:

    ist kernelschaltung bei eingeschaltetem c64 denn ungefährlich?
    ich meine in der jiffy anleitung steht, daß jiffy das sogar unterstützen würde!

    Im Falle von Jiffy kann das mit einer großen wahrscheinlichkeit gut gehen. Der Atmel schaltet ja ziemlich schnell und prellfrei um und der Jiffy Kernel ist ziemlich ähnlich dem Normalen. Nur wenn gerade eine Floppy oder Kassettenroutine ausgeführt wird kracht es.

    Wenn man erst Jiffy initialisiert und dann auf normales kernel switched wird es aber vermutlich wegen der F-tasten belegung krachen.

    Ohne Reset ist es nie ganz sauber ...


    jackdaniels schrieb:

    wäre es nicht sinnvoller um schreibzugriffe aufs eprom zu minimieren, wenn man NUR ins eprom schreibt wenn der inhalt ein anderer ist? sprich anderer kernel?

    Der EEPROM verträgt 100.000 Schreibzugriffe auf dieselbe Zelle. Aber prinzipiell gebe ich dir Recht.
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung
  • jackdaniels schrieb:

    wäre es nicht sinnvoller um schreibzugriffe aufs eprom zu minimieren, wenn man NUR ins eprom schreibt wenn der inhalt ein anderer ist? sprich anderer kernel?
    Das wird ja sowieso nur dann gemacht wenn die Einstellung bewusst gespeichert wird.

    -= Neu in meiner Sammlung / Modding =-

    Nichts hält länger als ein Provisorium
  • achso, man wählt also quasi einen "standardkernel" aus und speichert den...
    ähnlich dem sd2iec mit der laufwerksadresse welche softwareseitig gespeichert werden kann ja?

    das wäre praktisch! der cevi startet immer mit dem gleichen kernel solange man nicht umschaltet! wenn man am display also dann umschaltet wird der cevi automatisch resetet und man landet im neuen kernel?

    ist das so gemeint? das wäre sehr genial finde ich! muß man nur drauf achten, daß man den kernel auswählt und dann noch bestätigen muß, sonst klickt man sich durch die kernel und der cevi macht jedesmal einen reset dabei

    das ganze dann in kombination mit docs flash adapter.... dann kann man ne MENGE kernel per display mit namen anwählen!


    GEIL :dafuer: :dafuer: :dafuer: :hammer: :hammer: :bia *habenwill*
  • Wenn man die Displayansteuerung des SD2IEC verwendet dann nicht ganz.
    Das MENÜ selbst ist in der SD2IEC-Software integriert. (Wird schon seine Gründe haben.)

    Mit dem Aufbau von dem Link unten funktioniert es auch Standalone. Dann müßte man aber auf die SD-Funktionen verzichten.

    -= Neu in meiner Sammlung / Modding =-

    Nichts hält länger als ein Provisorium
  • jackdaniels schrieb:

    die firmware für die umschaltung wäre dann im "lcd-atmel" untergebracht?
    das sd2iec sollte ja ansich unverändert bleiben oder? dann könnte man diese displayschaltung an jedes sd2iec hängen.

    Das war einer der Gründe, das Display so weit zu abstrahieren, dass sd2iec keine Ahnung hat wie die Daten dort angezeigt werden. Um zusätzliche Funktionen nur auf Displayseite unterzubringen müsste man dort natürlich ein wenig umbauen, damit nicht jede User-Aktion sofort einen Menuaufruf beim sd2iec erzeugt sondern die ggfs. lokal behandelt werden. Für meinen schon lange vor mir hergeschobenen C128D-Umbau mit Frontdisplay war so etwas in der Art als System-Controller geplant, der evtl. noch nebenbei als sd2iec-Display arbeiten soll wenn mal kein PC in der Nähe steht, der die sd2iec-Debug-Ausgaben anzeigt.

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Unseen, wieviel Aufwand wäre das, dies in der jetzigen SD2IEC Software zu integrieren?
    Der Display AVR bietet sich ja diesbezüglich richtig an erweitert zu werden, damit der auch mal was zu tun bekommt :)

    Würdest du das vielleicht von deiner Seite aus in Erwägung ziehen?

    -= Neu in meiner Sammlung / Modding =-

    Nichts hält länger als ein Provisorium
  • Nur wenn ich es mal selbst brauche.
    Du hast es ja schon in deinem 1541 Projekt verwendet. Ich nehme mal an das es dort ähnlich funktioniert.

    Nur mal so grob überlegt, was müßte man alles implementieren?

    .) AVR Ausgänge definieren
    .) Menüpunkt erstellen
    .) Funktion für die Auswahl hinzufügen (inkl. Reset)
    .) Speicherfunktion integrieren

    Würde das so in etwa hinkommen?

    -= Neu in meiner Sammlung / Modding =-

    Nichts hält länger als ein Provisorium
  • DerSchatten schrieb:

    Du hast es ja schon in deinem 1541 Projekt verwendet. Ich nehme mal an das es dort ähnlich funktioniert.

    Ja, von da stammen LCD-Ansteuerung und Menüroutinen.

    Würde das so in etwa hinkommen?

    Theoretisch...

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Ich hab mit mal die Pinbelegung angesehen.

    Welche davon hast du für die Kernal-Umschaltung verwendet?

    Brainfuck-Quellcode

    1. +----_----+
    2. EncA | 1 40| LCD-D4
    3. EncB | 2 39| LCD-D5
    4. Key | 3 38| LCD-D6
    5. FRESET | 4 37| LCD-D6
    6. SS | 5 36| LCD-RS
    7. MOSI | 6 35| LCD-RW
    8. MISO | 7 A 34| LCD-E
    9. SCK | 8 T 33| (pa7)
    10. ARESET | 9 m 32|
    11. VCC |10 e 31| GND
    12. GND |11 g 30| VCC
    13. |12 a 29| (pc7)
    14. |13 1 28|
    15. MOT_ON |14 6 27|
    16. txd |15 26|
    17. STEP1 |16 25| SEL3
    18. STEP0 |17 24| SEL2
    19. DENS0 |18 23| SEL1
    20. DENS1 |19 22| SEL0 (pc0)
    21. DEV0 |20 21| DEV1 (pd7)
    22. +---------+
    Alles anzeigen


    Sind das SEL0 - SEL3 ?

    -= Neu in meiner Sammlung / Modding =-

    Nichts hält länger als ein Provisorium