Tracked down the Alundra problem! It can been seen using the no$psx Vram Viewer window: Stop the emu immediately after starting to save. Open the vram viewer. Run the emu in single frame steps (via keypad "/" key), until the letters "Save your p" are displayed, then run a few more frames until a black rectangle is drawn in lower left of the lower frame buffer. The frame buffer in the vram viewer shows the current vram content (ie. vram for the current, incomplete command list), whilst the command list in the vram viewer shows the must recent complete command list (for the previous frame). So, to see the command list that has drawn that black rectangle, run one more frame via keypad "/". The two problematic commands can be then seen directly at the bottom of the command list: Two "CpuToVram64x16" commands with destination x=03E0h. These will draw 32 pixels at x=3E0h..3FFh, and will then wrap to left vram edge, and draw 32 more pixels at x=000h..01Fh, destroying the CLUT memory (which is located right underneath of the lower frame buffer in this game). Real hardware apparently doesn't do that wrapping, or maybe it wraps differently (to same Y destination coord, instead of to next line at Y+1). I'll still need to check how that wrapping is handled on real hardware - but at least I figured out what went wrong there. EDIT: Just checked back: I did have already tested that wrapping cases for FillVram and CopyCpuToVram, they are wrapping from X=3FFh to X=0, with Y=same. But in the emulator, I did have implemented Y=same only for FillVram, not for CpuToVram; which is causing the problem in Alundra.