SD2IEC LCD-Ansteuerung

Es gibt 25 Antworten in diesem Thema, welches 4.790 mal aufgerufen wurde. Der letzte Beitrag (9. November 2009 um 08:58) ist von Diddl.

  • 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.

    Code
    KERNAL 1 ... PD5, PD4 -> HI
                 PD3, PD2 -> LO
    KERNAL 2 ... PD5 -> HI
                 PD5, PD3, PD2 -> LO
    KERNAL 3 ... PD5 -> HI
                 PD4, PD3, PD2 -> LO
    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

    Nur, wie gehts weiter?

    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen.

    Nichts hält länger als ein Provisorium

  • Warum so umständlich ?

    Ich würde einen (halben) 74LS139 verwenden.

    Code
    pd2   pd3    Kernal
       0       0        0
       0       1        1
       1       0        2
       1       1        3

    Zum C-Code kann ich Dir nichts sagen. Ist nicht meine Baustelle.

    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. |

  • 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.

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • 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.

  • 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.

    Zitat

    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.

    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen.

    Nichts hält länger als ein Provisorium

  • 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!

  • 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 ...


    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.

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • 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.

    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen.

    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*

  • Genau so wäre es angedacht.
    Unseen hat das ja bereits in einen seiner früheren Projekte realisiert.

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen.

    Nichts hält länger als ein Provisorium

  • jo kenn ich den thread.

    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.

    oder wie soll das werden?

  • 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.

    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen.

    Nichts hält länger als ein Provisorium

  • 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.

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

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Wenn der ATMEL die Kernal-Umschaltung macht, wäre es dann icht sinvoller er gibt den C64 (128) Reset.

    Also, Rechner einschalten, ATMEL startet und gibt dem CEVI erst einmal einen Reset und
    wenn der ATMEL stabil läuft, gibt er den CEVI mit dem gewünschten Kernal frei.

  • Also, Rechner einschalten, ATMEL startet und gibt dem CEVI erst einmal einen Reset und
    wenn der ATMEL stabil läuft, gibt er den CEVI mit dem gewünschten Kernal frei.

    tja, genau das wurde vorgeschlagen wenn du den thread gelesen hättest

  • 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?

    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen.

    Nichts hält länger als ein Provisorium

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


    Nur wenn ich es mal selbst brauche.

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

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Zitat

    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?

    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen.

    Nichts hält länger als ein Provisorium

  • 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.

    Zitat

    Würde das so in etwa hinkommen?


    Theoretisch...

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

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Ich hab mit mal die Pinbelegung angesehen.

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

    Sind das SEL0 - SEL3 ?

    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen.

    Nichts hält länger als ein Provisorium