Kega Fusion Inaccurate VRAM Copy Emulation

[Random64]

I found an inaccuracy with Kega Fusion’s Genesis/Mega Drive emulation. On real hardware, during VRAM to VRAM copies, the address’s least significant bit is effectively inverted. Kega Fusion emulates VRAM to VRAM copies without inverting this bit. For copies starting from an even address, with an even length, and the auto increment register set to 1, it makes no difference. For transfers that don’t meet these criteria, it produces incorrect results.

Example: 4 byte copy from 0x2000 to 0x4000 with the auto increment register set to 1
Here, bytes are copied in a different order, but the results are effectively the same.

Kega Fusion:
(source -> destination)
0x2000 -> 0x4000
0x2001 -> 0x4001
0x2002 -> 0x4002
0x2003 -> 0x4003

Real hardware (least significant bit is inverted):
0x2001 -> 0x4001
0x2000 -> 0x4000
0x2003 -> 0x4003
0x2002 -> 0x4002

Example: 4 byte copy from 0x2000 to 0x4000 with the auto increment register set to 2
Here, bytes are copied to incorrect addresses.

Kega Fusion:
0x2000 -> 0x4000
0x2001 -> 0x4002
0x2002 -> 0x4004
0x2003 -> 0x4006

Real hardware (least significant bit is inverted):
0x2001 -> 0x4001
0x2000 -> 0x4003
0x2003 -> 0x4005
0x2002 -> 0x4007

I made a ROM (linked here) to test this. It displays two copies of the same image. The image on the left is transferred to VRAM and displayed as is. The image on the right is transferred to VRAM and then rearranged using 4 separate VRAM copies with the auto increment register set to 4. After rearranging the image, it should look identical to the image on the left.

This screenshot from Gens matches what I saw running this ROM on real hardware.

This screenshot shows the result of not inverting the least significant bit.

[King]

Kega hasn’t been updated in 6 years now, so this isn’t surprising.

[Author]

Posts