PC Engine - Raiden Crashes when setting palette.

[xrip]

Raiden (USA/Japan) for PC-Engine crashes when setting palette.

Setting palette with index greater than 0x200 predictably crashes emulator:

retro-go/retro-core/components/pce-go/pce.c

Lines 542 to 568 in 7d409d7

	case 4: // Color table data (LSB)
	PCE.VCE.regs[PCE.VCE.reg].B.l = V;
	{
	size_t n = PCE.VCE.reg;
	size_t c = PCE.VCE.regs[n].W >> 1;
	if (n == 0) {
	for (int i = 0; i < 256; i += 16)
	PCE.Palette[i] = c;
	} else if (n & 15)
	PCE.Palette[n] = c;
	}
	return;
	case 5: // Color table data (MSB)
	PCE.VCE.regs[PCE.VCE.reg].B.h = V;
	{
	size_t n = PCE.VCE.reg;
	size_t c = PCE.VCE.regs[n].W >> 1;
	if (n == 0) {
	for (int i = 0; i < 256; i += 16)
	PCE.Palette[i] = c;
	} else if (n & 15)
	PCE.Palette[n] = c;
	}
	PCE.VCE.reg = (PCE.VCE.reg + 1) & 0x1FF;
	return;

Simply monkey patching both with

            if (PCE.VCE.reg > 0x200) return;

fixes the issue, but i think it's not right.

[ducalex]

Thanks for tracking down the problem! I think the actual bug would be on line 539 PCE.VCE.reg |= V << 8. Raiden probably uses a value greater than 1 because the value is already in a register, expecting the hardware to discard the upper 7 bits. The documentation says:

 $0402 - Color table address (LSB)
 $0403 - Color table address (MSB)
 (Both are write-only, reads return $FF)
 These two registers form a 16-bit value, of which the lower 9 bits are
 used as an index into the color table for subsequent reads and writes
 by the data register. The remaining upper 7 bits are ignored.

So changing line 539 to PCE.VCE.reg |= (V & 1) << 8; should be the correct behavior, I think.

The other option would be to mask PCE.VCE.reg every time it's accessed (eg instead of your return it'd be PCE.VCE.reg &= 0x1FF;) but that's a bit cumbersome.

What do you think?

[xrip]

Looks like discarding upper 7 bits from V would not broke anything and will have minimum performance impact.

Madnafen PCE emulator did the same:

https://github.com/libretro/beetle-supergrafx-libretro/blob/e41f864c0abb36aef20f8e37cd9d9a92c00a9221/mednafen/pce_fast/vdc.cpp#L292

Checked some other games after that patch and it seems theres no glitches or so on.

Btw, i have bunch of intersting emulators for RP2040 you might be intersting in.
For example Watara Supervision, Wonderswan Color, Neogeo Pocket Color :) May be you want to port them to retro-go :)

[ducalex]

Looks like discarding upper 7 bits from V would not broke anything and will have minimum performance impact.

Madnafen PCE emulator did the same:

https://github.com/libretro/beetle-supergrafx-libretro/blob/e41f864c0abb36aef20f8e37cd9d9a92c00a9221/mednafen/pce_fast/vdc.cpp#L292

Checked some other games after that patch and it seems theres no glitches or so on.

Thanks for testing. Since you did all the work do you want to create a PR to get credited as contributor? Otherwise I'll commit the fix in a few days/weeks when I get back to the project, we can keep this issue open until then.

---

Btw, i have bunch of intersting emulators for RP2040 you might be intersting in.
For example Watara Supervision, Wonderswan Color, Neogeo Pocket Color :) May be you want to port them to retro-go :)

I'll definitely check your ports, thanks!

How's your Gwenesis performance? I never could get my port to full speed with a reasonable frameskip despite trying so many things, but I believe the PICO is a fair amount faster (when running at equal clock).

[xrip]

I'll definitely check your ports, thanks!

You're welcome :)

How's your Gwenesis performance? I never could get my port to full speed with a reasonable frameskip despite trying so many things, but I believe the PICO is a fair amount faster (when running at equal clock).

RP2040 not strong as you think, i belive ESP32 outplays RP2040 with raw cpu performance at same CPU speed. Also, there's only 256Kb ram. But, pico have great ability to overclock to >= x3.0 of stock CPU speed (125Mhz => 378Mhz stable for 99.99(9)% of SoC's and 416Mhz for 90%). Also Pico always has 2nd core overwhelming cause of software Video output (my ports have Composite TV, VGA, HDMI, TFT outputs)

Regarding Gwenesis (which is very cpu MHZ depended), the only way to achieve good performance (50 stable fps for UMK3) is

1. 416Mhz
2. Completly disable sound
3. Frameskip every third frame
4. Interlace scanlines between frames

Some games works greate with full sound enabled with Z80 disabled, but most of games requires Z80 to work. Maybe other Z80 engine will increase performance.

Platformers like Boogerman works good with overclocking, interlace and frameskip, but with sound.

[ducalex]

On the esp32, if I overclock to 320Mhz I can achieve full speed (ntsc fs:1, so 30fps) in Sonic with YFM enabled and Z80 disabled.

But overclocking isn't as well documented as it is on the PICO, I have no idea what the average ESP32 chip can sustain. 280Mhz seems to be ok on all chips, 320 works on most of my devices, 360 on some, and 400Mhz always crashes.

I'll likely look into your NGPC port, I always wanted to support that in retro-go! I'll ping you when I get there, thanks again :).

Edit: BTW I tried a few other Z80 implementations, like the one from my smsplus fork that I optimized a fair amount. It helped but not that much. I tried other random Z80 but again it wasn't magical. Though in your case you might be able to find a Z80 implemented in thumb assembly!

[xrip]

I'll likely look into your NGPC port, I always wanted to support that in retro-go! I'll ping you when I get there, thanks again :).

You're welcome to contact me directly. Site with contacts in my github profile.

Edit: BTW I tried a few other Z80 implementations, like the one from my smsplus fork that I optimized a fair amount. It helped but not that much. I tried other random Z80 but again it wasn't magical. Though in your case you might be able to find a Z80 implemented in thumb assembly!

It wouldn't do the magic, just 1-3 fps. Cause there is very limited usage of Z80, mainly for pushing samples to YM chip in a loop, nothing more.
Also, i dont think theres Cortext-M0 Z80 realisation :)