Virtualc64: VICE test VICII/split-tests/modesplit fails

[dirkwhoffmann]

VICE 3.1 (model "C64 PAL")

VirtualC64 2.5

Most notably differences are in the upper right white section.

[dirkwhoffmann]

Seems to be similar now 🤔...

To make this test pass, I had to adapt the following from VICE:

if ((vicii.regs[0x11] ^ vicii.reg11_delay) & 0x20) {
        /* 6569 fetch magic! (FIXME: proper explanation)
           When changing from RAM to (char)ROM fetches, the LSB of the
           fetch address is (apparently) latched using the mode from
           the previous cycle, and the upper bits come from the current
           mode, due to ...

           TODO: test with $d018 splits and fix above test if needed.
        */
        uint16_t addr_from, addr_to;

        addr_from = g_fetch_addr(vicii.reg11_delay);
        addr_to = g_fetch_addr(vicii.regs[0x11]);

        if (!is_char_rom(addr_from) && is_char_rom(addr_to)) {
            addr = (addr_from & 0xff) | (addr_to & 0x3f00);
        }
    }

[Alessandro1970]

To be closed ...for my eyes is ok

[mortinus]

Yes, to be closed, I do not see sensible differences.

[dirkwhoffmann]

Broken in V3.0 🙁. (New mismatch in line 6).

Does anybody has the 3.0 beta executables at hand? Unfortunately, I deleted them on my machine and would need to recreate them from the git repro. We need to find out which checkin has broken the test.

[Alessandro1970]

VirtualC64_3.0_beta1.zip
VirtualC64_3.0_beta2.zip
VirtualC64_3.0_beta4.zip
I have found these 3 beta

[dirkwhoffmann]

For reference:

Beta 4: broken
Beta 3: OK
Beta 2: OK
Beta 1: OK

[dirkwhoffmann]

"Bug" is caused by clearing the processor stack:

// Make the screen look nice on startup
memset(&ram[0x400], 32, 40*25); // Screen 
memset(&ram[0x100], 0, 256);    // Processor stack

445 is a follow up.

[dirkwhoffmann]

Everything looks pretty good with the following fix:

// Make the screen look nice on startup
memset(&ram[0x400], 1, 40*25);