I forgot to mention I downloaded that program, but didn’t know what you wanted me to do with it, if anything. That was for the VDC? I thought it was for the VICII. I’ll check it again if it would help.
All the links I've provided are just for peoples information. I use those programs along with many others for testing the emulation accuracy of Z64K. I've already confirmed VDCDUMP shares the results of the author of the program on my real hardware. It is always useful to get other peoples results but I have no real need for it at this stage. VDCDUMP should be run in 40 column mode so it doesn't mess with the VDC memory during test. The test does take a long time to complete, seemed like an hour from memory on real hardware. I warp it on Z64K. I've actually just fixed the memory mapping of Z64K when using the 16/64 Ram configuration bit of register 28 to allow it to successfully run VDCDUMP (each test has a result of OK 64K, same as real hardware). I still need to do some more testing to make sure it hasn't broken anything else but I will upload a new version of Z64K soon with the fix. That will probably be when I get back home on Monday though.
I also don't think VICE emulates the memory corruption that happens when you set the VDC into 64k mode, so you can have a program that appears to work perfectly on VICE but has corrupted fonts on real hardware.
I'm not sure about the latest builds of VICE, but I fully concur that most/previous VICE versions fail in regards to 16K versus 64K RAM "mode". On real hardware, switching the VDC from 16K to 64K (or vice-versa) results in "corrupt" memory (garbage display), but in most/previous VICE versions everything is fine. It is not that switching RAM mode actually corrupts data, it is just that the RAM is accessed in a very different manner... which LOOKS like garbage to the unsuspecting programmer, but is actually the same (non-corrupt) data displayed in a very different way. Err, sorry I didn't add anything new but I did want to verify @pyrofer's claim.