Hallo Besucher, der Thread wurde 2,5k mal aufgerufen und enthält 19 Antworten

letzter Beitrag von Gerrit am

Kernel Ersatz

    Kernel Ersatz
    So wie ich das sehe, besteht keine Möglichkeit, den Kernel "von außen", also über den Cartridge Port zu ersetzen.


    Nicht mal dann, wenn ich den internen Kernel entferne.


    ---


    Wenn ich nun den CS des internen Kernel auftrenne, zwei Drähte zum Expansions Port führe ...
    ... rein theoretisch könnte ich dann wahlweise das interne Kernel oder irgendwas anderes verwenden.


    Oder sehe ich das falsch?


    Aus Elektroniker Sicht, - wären die Kabellängen ein Problem? Wenn ja, könnte man das Problem lösen? Wenn ja, wie?





    Selbe Frage gilt natürlich für das BASIC ROM auch. Aber ich denke die Antworten müssten dieselben sein?

    Das müsste gehen, ja. Bedingt aber, daß du zwei freie Pins am Ex-Port hast.


    Kabellängen... Nun, man sollte es nicht übertreiben, also so kurz wie möglich halten, wobei einer der 74LS138 das _CS liefert, der sollte genug Treiberleistung haben.


    Ansonsten kannst du natürlich in die Leitung einen Treiber einschleifen. Ein Gatter eines 74LS32 z.B. Sollte aber nicht nötig sein. Beim C64 liegen zwischen dem 74LS139 (der unter anderem I/O-Selects am Expansion-Port bereitstellt) und dem Port auch einiges an Strecke und es funktioniert.


    Mit dem Basic-ROM sollte das genauso gehen, mit dem Char-ROM hingegen nicht.

    Zitat von Gerrit

    Das müsste gehen, ja. Bedingt aber, daß du zwei freie Pins am Ex-Port hast.


    Ja da sind zwei frei. Ich hab mich gewundert, warum bei dem Bastel VC20 hier zwei Drähte von der CPU zum Expansionport gehen. Bei dem VC20 war auch ein Buch, wo das beschrieben wird :) Es sind A14 und A15, die sonst nicht dort zu finden sind. Das soll für externe Speicherkarten die Dekodierung erleichtern.

    Zitat von x1541

    Es sind A14 und A15, die sonst nicht dort zu finden sind. Das soll für externe Speicherkarten die Dekodierung erleichtern.


    Da die dann ja nicht über die Bustreiber gehen ... Könnte man die von extern auch auf L ziehen, und so der internen Dekoderlogik vorgaukeln, dass nicht ROM $c000-$ffff, sondern z.B. externes RAM $4000-$7fff. Dass dann nicht externes RAM sondern externes ROM adressiert wird, kann man ja wieder extern verwurschteln. Und ich meine diesen "ziehe Adressen extern auf L" verwendet auch das Chameleon am C64, weshalb es am C128 mit dessen translated adress bus nicht funktioniert.

    Zitat von Diddl

    Kernel Ersatz
    So wie ich das sehe, besteht keine Möglichkeit, den Kernel "von außen", also über den Cartridge Port zu ersetzen.


    Nicht mal dann, wenn ich den internen Kernel entferne.

    Warum soll das nicht gehen? Die Module können die internen ROM's komplett deaktivieren, und stattdessen die eigenen ROM's aktivieren. Final-Cartridge macht das ja z. B. auch so.

    Zitat von kbr

    Warum soll das nicht gehen? Die Module können die internen ROM's komplett deaktivieren, und stattdessen die eigenen ROM's aktivieren. Final-Cartridge macht das ja z. B. auch so.


    ???? wir sprechen hier vom VC-20 ...



    Zitat von x1541

    Ja da sind zwei frei. Ich hab mich gewundert, warum bei dem Bastel VC20 hier zwei Drähte von der CPU zum Expansionport gehen. Bei dem VC20 war auch ein Buch, wo das beschrieben wird :) Es sind A14 und A15, die sonst nicht dort zu finden sind. Das soll für externe Speicherkarten die Dekodierung erleichtern.


    Das wäre überhaupt genial, mit A14/A15 draußen könnte man eigentlich alles machen.


    Der Nachteil ist, man müsste beim internen Kernel das CS abzwicken und pullup. Damit würde der VC-20 ohne Cartridge nicht mehr funktionieren.



    Zitat von Gerrit

    Mit dem Basic-ROM sollte das genauso gehen, mit dem Char-ROM hingegen nicht.


    An das Char ROM habe ich noch gar nicht gedacht ...
    Warum geht das nicht? Wäre auch schön wenn man das einfach customizen könnte.

    Zitat von Diddl

    Der Nachteil ist, man müsste beim internen Kernel das CS abzwicken und pullup. Damit würde der VC-20 ohne Cartridge nicht mehr funktionieren.


    Nein, mit dem "ziehe A15 extern auf L" üblen hack musst du da nichts abkneifen. Aber das timing dieser Aktion will erst noch erforscht werden.


    Hier mal die Anleitung zu externem A14/A15 damit Du nicht die falsche Belegung wählst ;)


    Das ist nicht ganz so einfach, schliesslich muss du erstmal erkennen, daß A15 in diesem Zyklus HIGH ist uind dein ROM gemeint ist, dir das merken und dann A15 nach GND ziehen (und hoffen, daß die CPU das auf Dauer mitmacht).


    Allerdings bedeutet das dann leider Kampf auf dem Datenbus weil sich mit A15 = LOW ein anderer Baustein angesprochen fühlt und seine Daten loswerden will.

    Zitat von Gerrit

    Allerdings bedeutet das dann leider Kampf auf dem Datenbus weil sich mit A15 = LOW ein anderer Baustein angesprochen fühlt und seine Daten loswerden will.


    Nein, beim VC20 nicht. Da ist intern dann leerer Adressraum, und was man extern macht, entscheidet die externe Logik.


    Der kritische Punkt wird eben sein, mit sicherheit extern die Adressen für z.B. den Kernalzugriff zu erkennen, und dann für den Rest des Zyklus das mit A15=L zu übersteuern, so dass das Kernal ROM vom Bus geht und die CPU letztendlich die richtigen Daten rechtzeitig bekommt.

    Das liegt dann in der Verantwortung des einzelnen. Beim externen Ausbau seh ich kein Problem wenn es über die gleiche Schaltung gemacht wird. Interne Erweiterungen sind selten und man würde sie finden beim nachrüsten der Adressleitungen.


    Gruß x1541


    per tapatalk 2 versendet

    Zitat von Diddl

    Zitat von »kbr«




    Warum soll das nicht gehen? Die Module können die internen ROM's komplett deaktivieren, und stattdessen die eigenen ROM's aktivieren. Final-Cartridge macht das ja z. B. auch so.


    Zitat von Diddl

    ???? wir sprechen hier vom VC-20 ...

    sorry, my fault, hab die Rubrik nicht beachtet. Davon hab ich keine Ahnung...

    Zitat von Gerrit

    [...]
    (und hoffen, daß die CPU das auf Dauer mitmacht).


    Bei NMOS werden die High-Pegel, anders als bei CMOS, nicht in dem Chip selbst generiert, sondern über Pullups.
    Die High-Flanke ist deswegen relativ langsam, wogegen die Low-Flanke sehr schnell ist, da die Transistoren die Leitung direkt auf GND ziehen. (OC-Prinzip)
    Selbst bei einem Pullup von 470 Ohm fließen weniger als 10mA, was so ein Chip locker schafft.


    Gruß,
    crasbe

    Zitat von crasbe

    Bei NMOS werden die High-Pegel, anders als bei CMOS, nicht in dem Chip selbst generiert, sondern über Pullups.


    Du denkst gerade an Open Collector- bzw. Open Drain-Logik. NMOS-Chips können auch ohne Pullups High-Pegel erzeugen, allerdings sind NMOS-Transistoren als Highside-Treiber ungünstig und daher können die Pins im High-Zustand weniger Strom liefern als im Low-Zustand.

    Wer so einen Hack mit 'A15 auf GND ziehen' benutzt muss aber einen dicken Warnhinweis hinschreiben, daß das nur mit einer NMOS-CPU funktioniert. Jemand der einen 65C02 verbaut hat (warum auch immer) wird diesen Hack nicht witzig finden.


    @crasbe: Doch, NMOS erzeugt seine HIGH-Pegel selbst, aber den kann man dort eben nach GND ziehen ohne daß das (meist) zu Schäden führt.

    Auch hier gilt wieder, wer ne 65c02 oder derartiges im vc20 hat, darf eben die a15 Leitung erst gar nicht nach draussen legen.


    Ich bin aber auch der Meinung, ein derartiges Modul sollte erstmal die beiden slotpins überwachen ob da plausible signale anliegen und erst dann daten auf den bus legen. Sonst kracht es wirklich.


    Gruß x1541


    per tapatalk 2 versendet

    Würde mich wundern wenn es bei der Bezeichnung 'NMOS-kompatibel' nicht nur um die Pegel geht, aber die Ausgangstreiber trotzdem CMOS sind.


    Womit der hier beschriebene schmutzige Trick nicht gut für die CPU ist.


    Achja... Alles was nicht NMOS ist hat auch keine illegalgen Opcodes mehr. Je nach CPU sind die dann entweder alles NOP oder ein paar neue Opcodes plus ansonsten NOP.