riders: tmnt2 sprite support

[jotego]

Implement the protection module that handles sprites in tmnt2

[gyurco]

Looks like something is missing in k053246, too, as dma_en never turns to '1', so even the MCU starts filling the oram, sprite rendering never starts. BTW, it's not really a protection chip, but more like a coprocessor for sprite scaling.

[jotego]

Looks like something is missing in k053246, too, as dma_en never turns to '1', so even the MCU starts filling the oram, sprite rendering never starts.

The current jtriders_prot module only covers Sunset Riders based on MAME's source. I do not think it is compatible with the one in tmnt2, at least the program it has to run must be different.

[gyurco]

The current jtriders_prot module only covers Sunset Riders based on MAME's source. I do not think it is compatible with the one in tmnt2, at least the program it has to run must be different.

I know. The MCU reads some bytes from RAM/ROM according what's programmed from the main CPU, does some calculations and writes to ORAM. But the k053246 has to be enabled anyway, which is not.

[jotego]

What do you mean by enabling the k053246? What schematics are you looking at? TMNT2 uses 053244/5 for objects.

When the 053990/1 (protection chip) takes the bus, it will gain access to any device through the same address decoder the M68000 uses on the real board. On the core, however, I often restrict access to the device it needs only.

[gyurco]

Until dma_en is not turned on, it won't fetch data from the ORAM. It looks like it's common for all k05324x variants. However then k44_en should be '1', then

  .paroda     ( ssriders  ),

shouldn't be

  .paroda     ( ssriders | tmnt2 ),

?

As probably the whole bus is accessible by the MCU chip, MAME sources allows only ROM/RAM/ORAM access, so the dma_en in the k05324x should be turned on somewhere else. Needs some debugging, I think.

[gyurco]

Well, maybe not:

if (!(offs & 0x0031)) {
 offs = ((offs & 0x000e) >> 1) | ((offs & 0x1fc0) >> 3);
 m_k053245->k053245_word_w(offs, data, 0xffff);
}

The MCU can write to the register interface, too.

Probably it would be much cleaner to not duplicate the address decoder, but refactor the code for a shared bus between the CPU and MCU?

[jotego]

  .paroda     ( ssriders | tmnt2 ),

Yes, both ssriders and tmnt2 use the same object chipset as parodius. That change makes sense

Probably it would be much cleaner to not duplicate the address decoder, but refactor the code for a shared bus between the CPU and MCU?

Yes, until Furrtek comes out with the circuit for this chip, I favor a clean implementation of the behavior rather than the full connectivity.

[gyurco]

I did some work on it, made the protection module a real bus-master. TMNT2 shows some broken sprites for a while, then it collapses (no more sprites).

[gyurco]

Actually jt053246 stuck in scan_sub=1 state for a whole line (while 'done' is false). Looking at the code it should be not even possible...

[gyurco]

Hmm, indr=1 and scan_sub=1, so it stucks in default state for a whole line...

[gyurco]

Applying conv13 mangling to the dma address solves the crashing issue...but sprites are still not correct (maybe the sprite codes are good at least).

[gyurco]

BTW, the actual scaling code in mame has some FP calculations, I wonder how it's done originally. Maybe using LUTs or something else

    if (!xlock)
    {
        i = xzoom - 0x4f00;
        if (i > 0)
        {
            i >>= 8;
            xoffs += (int)(pow(i, /*1.898461*/1.891292) * xoffs / 599.250121);
        }
        else if (i < 0)
        {
            i = (i >> 3) + (i >> 4) + (i >> 5) + (i >> 6) + xzoom;
            xoffs = (i > 0) ? (xoffs * i / 0x4f00) : 0;
        }
    }

[jotego]

Is that code from the object co-processor emulation or from the video emulation?

I think the calculation itself is related to keeping the centre of the object constant while scaling. That requires adjusting the x/y coordinates for the sprite top-left corner. Of course, our implementation does not rely on floating point calculations.

[gyurco]

It's from the coprocessor code.

[gyurco]

The result is written to the sprite ram to be consumed by the k053244.