Was passiert beim Umschalten des Kernels im Betrieb?

Meist a, manchmal c, sehr unwahrscheinlich b. Es gibt da zwei Faktoren:

- Was tut der Rechner grad, wenn für einige hundert Befehle keine gescheiten Daten aus dem ROM kommen? Da der Rechner meist im KERNAL unterwegs ist, wird er sich verheddern.

- Wenn das 'neue' KERNAL Daten braucht, die das alte nicht oder anders initialisiert hat, gibt es ebenfalls Fehlfunktionen bis hin zu Datenverlust oder Absturz. Desgleichen wenn noch alte Rücksprungadressen auf dem Stack liegen, die nicht zum neuen ROM passen.

Ich habe das 3er Kernal von Jood mit Dolphin, Original und Jiffy. Ich kann im laufenden Betrieb umschalten, oft reagiert sogar die Tastatur noch, aber viel mehr passiert nicht. Man sollte nach dem Umschalten schon vertrauensvoll auf Reset drücken

Quote from c64user

Danke für eure Antworten! So lange kein dauerhafter Schaden auftreten kann, finde ich das beruhigend. Vielleicht weiß kinzi was zur Frage bezüglich Hardwareschaden (bestimmt weiß er das).

Weiß er nicht "bestimmt", kann aber eine Vermutung abgeben:

Das schlimmste, was MMN passieren kann, ist, dass ROM 1 bereits auf "Ausgang" steht und Daten an den Bus liefert, und ROM 2 dann ebenfalls seleketiert wird durch die Umschaltung, während ROM 1 noch in der "Hold Time" ist. Da müsste ROM 2 dann aber schon sehr schnell sein, um da auch "auf Ausgang" zu schalten, und dann würden für ein paar ns beide ROMs "gegeneinander" arbeiten.

Analoges Beispiel: In der 1570 wird vom ROM-Code (werksseitig!) an den Stellen, wo "zweiseitig" (1571) auf "einseitig" (1570) umgepatcht wurde, von der CPU ins ROM geschrieben. Da ein ROM R/W nicht auswertet, fühlt es sich dabei zum Lesen angesprochen und legt Daten auf den Bus, während die CPU das auch tut. Ich hab noch von keiner 1570 gehört, wo die CPU deswegen abgeraucht wäre.

Halte ich daher für völlig unproblematisch, was "Hardwareschaden" betrifft.

Quote from c64user

Bevor ich es auf die harte Tour ausprobiere, frage ich lieber hier nach: was passiert, wenn ich den Kernal im laufenden Betrieb umschalte, also eine andere Adressleitung am EPROM aktiviere?

Absturz?

Hardwareschaden?

Nichts?

Ich habe bereits einige Kernal-Switches gebaut, z.B. den Tiny Reset, oder den MiniSWAP, und dabei immer:

1. Reset auf low ziehen

2. Kernal umschalten

3. kurze Wartezeit

4. Reset zurück auf High

Im MiniSWAP ist das z.B. so gelöst, im Normalfall wird das Kernal immer mit "optionalem Reboot" gewechselt,

lediglich beim Kaltstart erfolgt das Setzen des gespeicherten Kernal ohne Reset.

Hier wird über "RESET_OUT" ein Open Collector Ausgang simuliert wird, entweder "LOW" oder "INPUT"...

Mfg Jood

Quote from muffi

Ich habe das 3er Kernal von Jood mit Dolphin, Original und Jiffy. Ich kann im laufenden Betrieb umschalten, oft reagiert sogar die Tastatur noch, aber viel mehr passiert nicht.

Wenn du bei der Umschaltung von Jiffy auf Original vor dem Umschalten @q eingibst sollte die Umschaltung auch ohne Reset funktionieren. Für den Weg von Original zu Jiffy steht auch was in der Doku, aber das habe ich noch nie ausprobiert:

Quote from JiffyDOS manual

Switching to the Stock Kernal while in BASIC

To switch from the JiffyDOS Kernal to the stock Kernal while your computer is in BASIC direct mode, first disable the JiffyDOS commands by using the @Q command and then flip the Kernal Selector Switch to the stock position.

Switching to the JiffyDOS Kernal while in BASIC

To switch from the stock Kernal to the JiffyDOS Kernal while your computer is in BASIC direct mode, first flip the Kernal Selector Switch to the JifyDOS position and then type in one of the following commands:

SYS 58551 (64 mode)

SYS 65137 (128 mode)

Display More

Ich habe hier noch eine alte Umschaltplatine, die aktuell leider nicht mehr funktioniert, aber damals absturzfrei umschalten konnte.
Vorraussetzung war allerdings, daß sich zwei Kernals auf einem Eprom befanden (ich glaub 256KB) und die eigentlichen Rom Routinen identisch waren.
Ich hatte damals das Speeddos Rom modifiziert, um mir Speicherbereiche unter dem Rom sowie Bildschirmspeicher nach einem Reset in das Ram zu kopieren.

Auf ein anderes Eprom umschalten führte allerdings immer zu einem Absturz.
Die Hardware habe ich mir damit aber nie geschossen.

Quote from c64user

Bevor ich es auf die harte Tour ausprobiere, frage ich lieber hier nach: was passiert, wenn ich den Kernal im laufenden Betrieb umschalte, also eine andere Adressleitung am EPROM aktiviere?

was für eine sehr schöne frage

Quote from c64user

Absturz?

normal ja.

wenn man es richtig macht, nie.

wenn man kundenprobleme lösen muss, die etwas steuern und bestimmte kernal routinen benutzen müssen.

wenn man etwas steuert und nicht genug platz im kernal hat, dann muss man manches, auf mehrere kernal (im PET oder den CBM geräten auf die roms, z.b. dem $Fxxx) verteilen, wenn man nicht wertvollen speicherplatz verschwenden möchte, der oft ja schon durch vorhandene (fremd) software benutzt wird.

man kann sogar mehrere kernal parallel laufen lassen oder kernals multi-switchen.

man muss es nur richtig machen. dann hängt sich nichts auf.

Quote from c64user

Hardwareschaden?

nie.

Quote from c64user

Nichts?

ja, wenn man es richtig macht
dann passiert nichts und alles läuft weiter.

gruß
helmut

Quote from kinzi

Analoges Beispiel: In der 1570 wird vom ROM-Code (werksseitig!) an den Stellen, wo "zweiseitig" (1571) auf "einseitig" (1570) umgepatcht wurde, von der CPU ins ROM geschrieben. Da ein ROM R/W nicht auswertet, fühlt es sich dabei zum Lesen angesprochen und legt Daten auf den Bus, während die CPU das auch tut. Ich hab noch von keiner 1570 gehört, wo die CPU deswegen abgeraucht wäre.

wenn die ausgänge ttl kompatibel sind, dann gibt es keine probleme, dafür sind die auch gemacht worden, damit nichts kaputt geht.

die meisten ausgänge treiben immer weniger strom bei einem high pegel als bei einem low pegel.
ist er gleich, ist es sowiso egal. ist der eine auf high und der andere auf low, gewinnt der low, der hat mehr wums.

vor vielen jahren, musste ich mich hier mal einmischen, da wurde behauptet, eine eprom pla, würde bauteile zerstören, da musste ich dann mich einmischen, da viel blödsinn von angeblichen fachleuten erzählt wurde.

sieht man sich den datenbus einer cpu an, dann sieht man nur solche ausgangs timing usw. kollisionen.
es gibt fast nie saubere daten signale auf dem datenbus zu sehen.
man sieht high und low signale, dann welche dazwischen, die können durchs tristaste oder dadurch entstehen, das der eine noch etwas angelegt hat und der andere zuschnell ist.
je langsammer einer reagiert, die daten anlegt, umso langsammer reagiert er auch, um die daten wieder wegzunehmen. nichts läuft da pegelmäßig so perfekt und sauber ab. es zählt nur, wann etwas spätestens da sein muss und wie lange es mindestens da sein muss. alles andere ist egal.

Quote from kinzi

Halte ich daher für völlig unproblematisch, was "Hardwareschaden" betrifft.

ja, ich auch, ich habe solchen schaltungsmisst auch manchmal machen müssen.

gruß
helmut

edit......

bei modernen cmos ausgängen sieht es aber ganz anders aus. da die bei low und bei einem high oft den gleichen strom treiben können. das sollte man z.b. bei einer alten schaltung gut sich überlegen, ob man ein ttl ic z.b. einen 74ls... problemlos da durch einen 74hct (hc) ersetzen kann.
in den datenblätter kann man es gut sehen und die nicht überlasten.

mit einer kleinen hardware erkennung, kann man dafür sorgen, das wenn cs fürs kernal nicht aktiv ist und man sich in der phi2 high phase befindet, man problemlos umschalten kann.

denn in der phi2 phase und nicht cs kernal aktiviert, bedeutet, die cpu ist ganz woanders beschäftigt.

man muss aber dafür sorgen, das es keine normale schalter umschaltung ist, denn schalter prellen und dann ist man schon in der phase wo ein kernal angesprochen wird und dann geht es oft schief.

man schaltet prellfrei mit einem rs flip flop um. am besten nur wenn cs kernal high ist. dann geht es immer.

möchte man zwischen mehreren kernals, währen dem betrieb, hin und her wechseln, z.b. durch pokes im programm, weil man etwas benutzen möchte, was in einem anderen kernal nicht vorhanden ist, dann muss man nur einen kernal bereich zum umschalten ausselektieren der bei allen kernals gleich ist.
ohne das man irgendwelche routinen oder den irq dazu benutzen muss.

wenn man etwas hardwaremässig löst, dann geht es immer, wenn man es per software löst, dann weiß man nicht ob nicht ein anderes program in die quere kommt. besonders wenn man verschiedene programme benutzt. routinen von verschiedenen programmierern usw.

oft habe ich für diese speziellen boards die pla geändert oder besser ausdekodiert.
von den 8 pla ausgängen kann man manche sich freimachen für ganz andere zwecke.

eigentlich benötigt man nur 4 pla ausgänge und man hat 4 frei, für jeden misst, den einem einfällt.

spontan fällt mir nur ein, ohne jetzt mir den schaltplan anzusehen, ist es write color ram, was extra behandelt werden muss. alle anderen können nur immer ein mal gleichzeitig vorkommen.

man nehme ein schnelles eprom, oder eine 82s100 pla und man legt nicht den dekodierten wert an die 7 ausgänge, sondern einen bcd wert für einen 74138. so hat man nun 8 ausgänge, sogar einen zusätzlichen zu verfügung und hat nur drei ausgänge dafür benutzt. plus den write color ram, dann sind es 4.
benutzt man zwei 74138 oder einen 74154, dann hat man mit 4 pla / eprom ausgängen nun 16 getrennte cs pins. so kann man nun vieles auch genauer ausdekodieren.

ich habe die pla ersatz schaltung mit zwei gals gesehen, weil wohl nicht genug in und out pins für einen alleine vorhanden sind. falls es logisch zu verknüpfen geht, würde ich nur einen entsprechenden gal nehmen und dann nur 4 ausgänge benutzen, drei für einen 74138.

eine pla im c64 und den anderen rechnern hat ja 16 eingänge und 8 ausgänge, so benötigt man ja mindestens 24 pins plus +5v und masse. ein gal hat aber nur 24 pins für alles, somit schon zu wenig um eine pla 82s100 zu ersetzen. da aber immer nur ein ausgang low aktiv ist, geht es mit dem 74138.

gruß
helmut

edit......
euch allen wünsche ich einen schönen tag und ich hoffe meine zweite schlaftablette wirkt bald und ich kann endlich bald schlafen.

ich möchte doch so gerne wieder schnell einschlafen können wie früher.
wie andi Shadow-aSc , zack nur eine minute hat es gedauert und er war am schlafen obwohl ich ihn vorher vollgequatscht habe.

Ich zähle immer bis drei und dann schlafe ich.

Manchmal auch bis halb vier. 🙈

Quote from axorp

ich möchte doch so gerne wieder schnell einschlafen können wie früher.
wie andi Shadow-aSc , zack nur eine minute hat es gedauert und er war am schlafen obwohl ich ihn vorher vollgequatscht habe.

..war ja auch ein 28 Stunden-Tag vorher....

Quote from Shadow-aSc

..war ja auch ein 28 Stunden-Tag vorher....

Hättest du die Pausen durchgemacht, wäre er 45min. länger gewesen.

Quote from axorp

ich möchte doch so gerne wieder schnell einschlafen können wie früher.
wie andi Shadow-aSc , zack nur eine minute hat es gedauert und er war am schlafen obwohl ich ihn vorher vollgequatscht habe.

obwohl? oder weil?

Quote from Shadow-aSc

..war ja auch ein 28 Stunden-Tag vorher....

bitte eure Bettgeschichten für euch behalten

und nun

Quote from axorp

denn in der phi2 phase und nicht cs kernal aktiviert, bedeutet, die cpu ist ganz woanders beschäftigt.
...

möchte man zwischen mehreren kernals, währen dem betrieb, hin und her wechseln, z.b. durch pokes im programm, weil man etwas benutzen möchte, was in einem anderen kernal nicht vorhanden ist, dann muss man nur einen kernal bereich zum umschalten ausselektieren der bei allen kernals gleich ist.

Naja ersteres klappt schon nicht, während der KERNAL z.B. ein lda $dc00 macht; zweiteres klappt nicht, wenn KERNAL A z.B. irgendwelche Utility-Pointer in der Zeropage anders benutzt/setzt als KERNAL B. Kommt also immer drauf an.

Quote from mc71

Was tut der Rechner grad, wenn für einige hundert Befehle keine gescheiten Daten aus dem ROM kommen?

Wieso einige hundert Befehle?

So ein Umschalten einer Adressleitung geschieht doch sofort. Gut, so ein Schalter kann prellen, aber sofern man nicht gerade in einer Routine unterwegs ist, die sich in beiden KERNALs unterscheidet, merkt die CPU von der Umschaltung nichtmal was. Die Chancen stehen also gut, daß der Rechner nicht abstürzt, wenn man nicht gerade in der Laderoutine oder so umschaltet.

Anders sieht es aus, wenn man zwischen mehreren EPROMs umschaltet, da dann andere Leitungen geschaltet werden müssen, was ohne zusätzlichen Aufwand nicht nahtlos passiert.

Ein Reset nach der Umschaltung ist jedoch immer ratsam, da man nicht 100%ig vorher sagen kann, was beim Umschalten genau passiert, bzw. wie kompatibel die RAM-Konfiguration ist, die das jeweils andere KERNAL hinterlassen hat.

Problematischer ist es, das Floppy-ROM im laufenden Betrieb umzuschalten. Da habe ich schon Fälle erlebt, wo dabei die Daten geschrottet wurden. Da ist es ratsam, vor dem Umschalten die Diskette zu entfernen und erst nach einem Floppy-Reset wieder einzulegen.

Quote from 1570

Naja ersteres klappt schon nicht, während der KERNAL z.B. ein lda $dc00 macht; zweiteres klappt nicht, wenn KERNAL A z.B. irgendwelche Utility-Pointer in der Zeropage anders benutzt/setzt als KERNAL B. Kommt also immer drauf an.

ich meinte ja, wenn er in einem bestimmten bereich ist, wo es auch problemlos geht.
um zu erkennen das er in diesem bereich auch ist, muss man den adressbereich auch genau ausdekodieren.
benutzt man dann ein flip flop, wird genau bei dieser adresse erst umgeschaltet.

ich gehe mal davon aus, das hier keiner so etwas selbst bauen möchte, so wollte ich nicht eine schaltung klein klein, sondern nur grob, erklären.

ich habe aber ja schon meine damaligen tricks erwähnt, wie man aus der pla mehr herausholen kann, damit man einen bereich besser ausdekodieren kann. was ich nicht erwähnte, das man noch weitere adressleitungen dann dafür benutzt um sogar byteweise es machen zu können.

meine boards wurden ja für steuerungen usw. benutzt, so gab es huckepack platinen auf diesen.
das expansions port benutzte ich nicht gerne, damit eine konkurez, es nicht einfach nachbauen kann.
für meine kunden war es auch so viel sicherer und stabiler dann konstruiert.

gruß
helmut

Ja, dass das mit bestimmten Kombinationen von ROMs und gestimmten ggf. darauf zugeschnittenen Logiken geht, ist klar - aber auch relativ trivial. Z.B. zwischen Kernals, die sich allesamt nur durch Krams im Tape-Bereich unterscheiden und keine bestimmten Zeropage-Konfigurationen erwarten, lässt sich natürlich "immer" umschalten. Bei anderen Kernals, die z.B. den LOAD-Pointer immer verbogen lassen, lässt sich aber gar nicht im Betrieb daraus wegschalten, auch nicht mit einer "komplizierten" Logik, weil danach der Standard-Kernal natürlich bei LOAD abstürzt.