felipesanches / mame

MAME - Multiple Arcade Machine Emulator
Other
4 stars 1 forks source link

[anotherworld] Investigate VM irregularities #17

Open felipesanches opened 7 years ago

felipesanches commented 7 years ago

There are some places in the VM implementation where VM vars are set to hardcoded values. Some comments on @fabiensanglard 's VM re-implementation make me believe those are hacks crafted to tweak the bytecode of specific releases at runtime. Idealy, I'd like to acchieve a VM implementation that is clean of hacks.

Towards that goal, I'll be wrapping these tweaks with #ifdefs so that we can temporarily disable them at compile-time and verify what are the differences at runtime.

Hopefully I'll end up figuring out a way of getting rid of all of these VM irregularities.

felipesanches commented 7 years ago

This is one example:

        case 0x10: /* blitFramebuffer */
        {
            uint8_t pageId = fetch_byte();

#ifdef VM_HACK_SWITCH_FROM_INTRO_TO_LAKE
            //Nasty hack....was this present in the original assembly  ??!!
            //This seems to be necessary for switching from the intro sequence to the lake stage
            if (m_currentPartId == GAME_PART(0) && read_vm_variable(0x67) == 1)
                write_vm_variable(0xDC, 0x21);
#endif
        [...]

I've just disabled this one and I can confirm that switching from intro sequence to lake stage actually fails without this both on MSDOS and Amiga bytecode.

felipesanches commented 7 years ago

On the other hand, in this same blitframebuffer instruction implementation we have this other hack which does not seem to be really needed:

#ifdef VM_HACK_BLITFRAMEBUFFER_VAR_F7
            //Why ?
            write_vm_variable(0xF7, 0x0000);
#endif

I disabled it and was unable to observe any difference at runtime. Unfortunately whoever put this in the VM code did not add a proper comment explaining why this is needed or how it would affect the VM execution or gameplay events.

cyxx commented 4 years ago

The 0xDC variable is part of the copy protection and must be set to 33 during gameplay. The checks can be found in the game bytecode.

Below are the expected values depending on the version -

if (_is3DO) {
    _scriptVars[0xDB] = 1;
    _scriptVars[0xE2] = 1;
    _scriptVars[0xF2] = 6000;
} else {
    _scriptVars[0xBC] = 0x10;
    _scriptVars[0xC6] = 0x80;
    _scriptVars[0xF2] = (_res->getDataType() == Resource::DT_AMIGA) ? 6000 : 4000;
    _scriptVars[0xDC] = 33;
}
cyxx commented 4 years ago

And a possible workaround for accepting any input in the copy protection screen https://github.com/cyxx/rawgl/blob/master/script.cpp#L153