Switching the model in the settings model dialog does not properly update the model. It seems related to the kernal but I'm not sure. Saving settings and restarting after changing model does change stuff but it still seems incorrrect.
On a PAL machine $F33F (ROM) is supposed to be $08, which is copied into $FF07 on startup. $FF80 (ROM) is supposed to have MSB set.
See this thread: https://plus4world.powweb.com/forum/40025
After direct startup of xplus4 configured for Plus4 PAL I get:
$F33F=$08, $FF07=$08 and $FF80=$85, lightblueish border
switching to Plus4 NTSC:
$F33F=$48, $FF07=$48 and $FF80=$05, lightblueish border
After direct startup of xplus4 configured for Plus4 NTSC I get:
$F33F=$48, $FF07=$48 and $FF80=$05, pinkish border
switching to Plus4 PAL:
$F33F=$48, $FF07=$48 and $FF80=$05, pinkish border, i.e no change of values(!)
I addition, the model dialog seems to update TED PAL/NTSC with the selected machine, but it will set the amount of RAM to 16K for all machines whenever you exit and reenter the dialog.
I couldn't wrap my head around the embed stuff in the source but I doesn't seem to reference the data/PLUS4/kernal.005 that is supposedly used on NTSC. May I just misunderstand how it is supposed to work though.
xplus4 r37618 (GTK3, --enable-embedded) on ubuntu 18.04 LTS. Seems to behave in a similar fashion in the stock ubuntu supplied v3.1 GTK.
Diff:
--enable-embedded is the problem here. this is NOT ment for endusers. it will NOT embed all and every ROM, nor is switching them possible at all.
so try again without it and see if the problem persists :)
edit: pal/ntsc switching works here. the RAM radiobutton is broken, will try to fix that :)
edit++: make sure to test this using the emulated machine, not VICE monitor - the memory mapping stuff was broken until recently (and i have no idea if its actually 100% correct now)
Last edit: gpz 2020-04-13
Aha, ok. It used to work IIRC. I'm running vice from the build tree and struggled a bit with it finding it's libraries. Is there a better way to do something like that? Installing into a local dir would work I suppose but it'd be quicker directly from the tree.
The Ubuntu factory supplied xplus4 does seem to switch properly, however the color issue is still there. Am I supposed to switch CRT emulation manually between PAL and NTSC?
you'll have to install it, its not made to work without installing.
the colors are different because... they ARE different :) remember what they say about NTSC =)
(this happens because the same color angles are used for YUV and for YIQ - its the same for all cbm computers, ie slightly different colors in PAL and NTSC)
Last edit: gpz 2020-04-13
oh forgot, for a quick test you can also copy all required files into one directory, and then point vice to it using the -directory option. its a bit ugly, but it works :)
Ok, could work but I would have loved it to be able to specify where the "data/" root is and that it could find it's way from there. OT here I suppose.
About the colors: yes, but if I start the emulator in NTSC mode and switch over to PAL the colors stay NTSC (and vice versa).
OH!, starting it in NTSC mode is the key to reproduce it... i can confirm. thats really weird, the crt emulation does use the same resource as the machine timing for this shrug
r37625 fixes the color switching., please try again :)
Seems to be working now, good work! (My kernal issue persists but we'll assume that is due to the --enable-embedded.)
all is fine now? (model switching behaviour too?) can we close this? :)
It looks like it works but the colors are strange in PAL vs NTSC compared to xplus4 v3.1. It could be that my "embedded" kernal issue messes up the palette PAL vs NTSC and I have no hardware to compare with.
Someone with hardware or at least experience of the actual hardware should test it.
that could be the different pal/ntsc decoders you are seeing now,... i dont remember when i added this stuff. i also corrected some color angles recently (according to peptos new measurements)
asking again, can we close it? :)
I think it's working based on what is saw then, but I don't have the hardware to compare to. For me ok to close. Will write a new ticket if I find anything else.
ok, will closed. embedded roms have been killed with fire anyway :)