#1171 C64 Kernel patching does not work correctly

[Martin Erzberger]

When trying to patch the kernal, VICE thinks it's already on the correct kernal and does not patch. It's better visible when I show the output. See that VICE shows revision 67 (the one it should patch to) in the log. But then it tries to patch to revision 3, which it is already on, so it does nothing.
It looks like two variables are swapped in the source code.

/usr/local/Cellar/vice/3.4/bin/x64sc -default -verbose -kernalrev sx
...

*** VICE Version 3.4 ***

Welcome to x64sc, the free portable C64 Emulator.

...

Loading system file `/usr/local/Cellar/vice/3.4/bin/../lib/vice/C64/kernal'.
loaded known kernal revision:3 chksum: 50954
set_kernal_revision val:3 kernal_revision: 67
Trying Kernal ROM patch: id:3/sum:50954 to id:3.
ROM not patched: Already revision #3.

Value "0" has the same problem:

set_kernal_revision val:3 kernal_revision: -1
Trying Kernal ROM patch: id:3/sum:50954 to id:3.
ROM not patched: Already revision #3.

[Querino]

i think it's the combination of parameters that actually makes problems.

for example,

x64sc -config vicetest.ini

works fine, whereas in

x64sc -kernalrev sx -config vicetest.ini

the -config simply is ignored.

[Martin Erzberger]

Yes, -config not in first place is ignored, I learned this too. But I invoke VICE without -config, so this should not be an issue.

But I found something: When I set "sx64" via GUI and save the config file, I get these two entries:

KernalName="sxkernal"
KernalRev=67

This way, the kernal gets patched correctly. For me this is good enough.

Still, I want to mention that the above does not work via command line:

/usr/local/Cellar/vice/3.4/bin/x64sc -kernalname "sxkernal" -kernalrev 67

This results in:

Unknown option '-kernalname'.

Seems strange that one can specify the kernal revision on the command line, but not the (apparently mandatory) kernal name as well.

[Greg King]

/usr/local/Cellar/vice/3.4/bin/x64sc -kernalname "sxkernal" -kernalrev 67

This results in:

Unknown option '-kernalname'.

Seems strange that one can specify the kernal revision on the command line, but not the (apparently mandatory) kernal name as well.

Enter this command:

/usr/local/Cellar/vice/3.4/bin/x64sc -help|more

Then, tell "more" to find kernal. You will see the correct options.

[Martin Erzberger]

Ah, thanks! Looks like the property "KernalName" is set on the command line with "-kernal".

I'm struggling a bit with the documentation. I could not find any listing of valid "KernalName" values, or the valid "KernalRev" for any particular "KernalName" that I select.

The "KernalRev" also has contradicting values (resources http://vice-emu.sourceforge.net/vice_7.html#SEC132 have different values compared to the command line option http://vice-emu.sourceforge.net/vice_7.html#SEC133).

Regardless of the manual, all values that I select for "KernalRev" load the v3 kernal (with "KernalName left unspecified, i.e. using the default of "kernal").

[Querino]

check folder /C64/

kernal
gskernal
edkernal
jpkernal
sxkernal

those are kernals included by default, but you can use any other valid other kernal (file)

i'm still confused with KernalRev... earlier VICE versions did load the sx kernal when param

-kernalrev sx

was used, but not anymore. so what is correct? now it works with

-kernal sxkernal

i never used this... obviously.

[Martin Erzberger]

Thanks again! I was mistaken in believing that "KernalName" is some sort of predefined internal property. In fact it's more of a "KernalFile" property, in that it contains the path to the ROM file to be loaded.

The "KernalRev" documentation seems to be outdated. It states "... VICE is able to automatically convert one ROM revision into another, by manually patching the loaded image. This way, it is possible to use any of the ROM revisions without changing the ROM set. "

Based on the above, my understanding was that if I say rev "67", it will take the "kernal" rom file and patch it on the fly into rev 67. Apparently this is not the case. Instead one has to load another rom file, namely sxkernal.

For "kernal" itself there is only one ROM, so here patching into Rev 1 or 2 should be possible, but does not work on my system.

[Greg King]

The "model" option works: -model sx64, -model sx64pal, and -model sx64ntsc.

• -kernalrev tries to patch the Kernal before the file is loaded; then, it pretends that it succeeded.
• KernalRev is ignored. Its value is replaced by the actual revision number from the loaded file.

---

The attached patch fixes the -kernalrev bug. (A KernalRev from the settings file still is ignored.)

[gpz]

should be fixed in r37310, please test again

[Martin Erzberger]

Sorry for a noob question: So far I used the SDL2 binary distribution, provided by homebrew.

To test, I went with the --HEAD option. brew fetched r37316, and then built the Gtk version. For a reliable test, I would need the SDL2 version here.

Do you know how I can build this one, instead of the Gtk version?

[Querino]

firing up

x64sc -kernalrev sx

i get the following in the log:

Installing ROM patch for revision #67:

after saving the settings / restarting the emu the "KernalRev" entry is ignored, same as in Greg's patch.

[dqh]

Hi Martin,

You can edit the brew formula for vice:

$ brew edit vice

there's a code block like this:

if build.head?
  configure_flags << "--enable-native-gtk3ui"
else
  configure_flags << "--enable-sdlui2"
end

change it to just

  configure_flags << "--enable-sdlui2"

then save and reinstall the --HEAD version.

[Martin Erzberger]

Thanks for the instructions!
I can confirm that the command line parameter now works as expected.
The KernalRev in the config file does not work. I expected this, because it's explained above that only the command line part was fixed so far.

Apparently for kernal 67 I have two options now: Directly load the sxkernal, or load the kernal and then have it patched. Is this as expected?
Thanks! Martin

[gpz]

two options is expected. the -kernal option actually looks for a file of that name and loads it, while the kernalrev option tries to patch the already loaded kernal. the later should probably be removed at some point - its quite redundant

[Martin Erzberger]

Agree; For people that really want to experiment with kernal rev 1 or 2 it would probably be less of an effort to just add the two additional ROM files, compared to maintain code to patch a kernal.

[gpz]

the resource loading cant be fixed properly... its fighting with the "kernalname" resource over who is the one to define whats right. meh

[Martin Erzberger]

I see... Not my call, but I would really eliminate both -kernalrev and the KernalRev resource. In return, add the two (or three?) kernal rom files that can no longer be patched into. It's way more transparent this way, and it's also more robust.
It's also much easier to properly combine into a "model".:I think (but have not tested this) that currently "oldntsc" loads kernal v3, but v1 would probably be more appropriate.

[gpz]

yes, thats pretty much what i am planning to do :)

[gpz]

r42129 changes the behaviour like this:

• no more patching. when changing KernalRev or using -kernalrev simply a new ROM will be loaded and the KernalName resource changed accordingly
• when changing KernalName, KernalRev is adjusted accordingly

please test, reopen when there is still a problem