System32 improvements

[mahoneyt944]

I've been messing with our old video code the last few days, and managed to fix the flickery jeep in jpark. This makes playing the game a little more enjoyable. However I noticed when the jeep is hit or bounces, it shudders down the screen instead of up like it should. I believe it's even wrapping to the top of the screen, which is why we see the tailgate graphics flash at the top. Seems to me that we need to change the direction this is moving and it might fix most of the remaining issues in jpark, but I'm not sure where the "shake" of the screen is in the video code? It must be shifting the graphics a certain amount somewhere for this effect.

[mahoneyt944]

Also just pushed an update to fix the sprites in alien3. If we hooked up zooming, as far as I can tell, this would get it looking pretty good on the old video code.

[arcadez2003]

Nice work the system 32 video code is complex stuff, fancy taking a peek at SlipStream some time down the road.?? the colour mixing is wrong for that one i looked in to it a while back but could not advance it any.

[mahoneyt944]

Yeah I'll look. Still need to refine alien3, thought I had it but it still has some issues at the end of the game. So now I need to reel in to the exact bit we need to mix like I did for jpark

[mahoneyt944]

Well alien3 is a bust, the fix I had breaks later levels. reverted

[mahoneyt944]

Slip stream is completely jacked in this core, does it play better in your Xbox core?

[arcadez2003]

As you may or may not recall i have two of these drivers the same ole one we have here plus i have a seperate segas32 driver and video so that Golden Axe RODA is 100% in the gfx dept i also use that for Dark Edge and SlipStream so yeah it's fine on the xbox.

If only we could port my Segas32 across to here it would solve all the problems Jpark included :)

This is what stands in the way "ofcourse there might be some other hurdles" but this is the big one input tagging......

static WRITE16_HANDLER( analog_custom_io_w ) { static const char names[] = { "ANALOG1", "ANALOG2", "ANALOG3", "ANALOG4" }; switch (offset) { case 0x10/2: case 0x12/2: case 0x14/2: case 0x16/2: analog_value[offset & 3] = readinputportbytag(names[offset & 3], 0); return; } logerror("%06X:unknown analog_custom_io_w(%X) = %04X & %04X\n", activecpu_get_pc(), offset2, data, mem_mask ^ 0xffff); }

[mahoneyt944]

Im guessing each one of those cases are the individual inputs, so we'd have to set each one individually, not as neat but should be the same. Not sure what ports we use here but should just need matched up

[arcadez2003]

Yip combined inputs into a single define it's splitting them i was never sure about how to handle that even after looking at the ole system32 driver input handling, but there are other nasties for us to deal with should we try to backport this....

ADDRESS_MAP_FLAGS( AMEF_UNMAP(1) )
ADDRESS_MAP_FLAGS( AMEF_UNMAP(1) | AMEF_ABITS(8) )
    AM_MIRROR's all over the place
AM_RANGE(0xf00000, 0xffffff) AM_ROM AM_REGION(REGION_CPU1, 0) a couple of these by looks
    and my ole faves some mem and rom banking

[arcadez2003]

https://github.com/libretro/mame2003-plus-libretro/commit/dd704f41f3fd8787e96086223511d6092e920ac3

Fixed the sprite decryption the color mixing is still wrong and no sound as yet

[mahoneyt944]

Nice, I'll poke around with the colors

[mahoneyt944]

I'm wondering if there's a magic value needing set for system32_mixerShift. Haven't found one though. Seems like the sprites are inverting the colors or something.

[mahoneyt944]

This seems to fix the bounce on the jeep https://github.com/libretro/mame2003-plus-libretro/commit/77826515fb8ebdd02e977f2359d972d80c544cb1

Need to test more games though for regression with this

[mahoneyt944]

That last commit also fixes the background for ga2, happy accident :) though still some color issues on the shadows to figure out, maybe related to slipstrm color issue?

[mahoneyt944]

Also fixes the windshield logo and sonic toy lean on the banks in radm

[mahoneyt944]

Picking up the color issues of #407 here now.

[arcadez2003]

Your on a roll im wanting to see what you fix next :)

[mahoneyt944]

Seems like the color issues are all related. I notice black, such as the shadow of the slipstrm cars turn white, and the lighter characters in ga2 turn black. Reminds me of the black shadows you noted in darkedge. Wonder if we could log the palette ram from a newer mame and test it in this core, might help roll that out anyway.

[arcadez2003]

Yeah those are noticable on Air Rescue with the bg's being blacked out on some levels, i guess with our video code the mixing and merging of certain shadow and colour effects are displaying incorrectly hence it's either the sprite layer or the background which is incorrect on the games.

I dont these games are 100% even with current MAME.?? certainly i know the bg's were totally blanked out with Title Fight but maybe that has been sorted now.

[arcadez2003]

https://github.com/libretro/mame2003-plus-libretro/commit/756ccb779c3728fee38241ba61ea49cd18181b8b

Last code changes in system32 video before the big rewrite might as well have these fixes for the Rad Mobile / Rally games which from memory are circa MAME81 or so and not mentioned on the WIP.

[mahoneyt944]

Seems to be buggy, the colors wig out then correct after a second or so each time it's loaded.

[mahoneyt944]

Maybe it needs something tweaked in the condition? Or a delay

[mahoneyt944]

Idk it causes issues in other games too, might need to comment it out until we can figure out what's wrong. I get the feeling it was experimental work.

[arcadez2003]

Yeah might as well revert it then i'll do it tomorrow unless you beat me too it :)

[mahoneyt944]

@arcadez2003 good news, I ended up copying the videoram and palette from what I think is a "ready state" and apply that to radr to fix the issues, this allows radr and radm to work without effecting other games as well :) looks good now. 👍 https://github.com/libretro/mame2003-plus-libretro/commit/b9966def4ef88cd09c84ec506736f088e47f4e4e

[wn2000]

That last commit also fixes the background for ga2, happy accident :) though still some color issues on the shadows to figure out, maybe related to slipstrm color issue?

Finally a breakthrough in fixing ga2! This is awesome!

[mahoneyt944]

@arcadez2003 do you have any insight on the networking issue radr has when the game first starts up? You can skip it with a service button press but I believe we need a read/ write handler on a comm port or something to bypass it automatically?

[arcadez2003]

Im not sure TBH for F1 Superlap there was a dip switch option which if defaulted to off skipped the comms check so that's how i set it up to make sure the game didn't get locked into this check upon bootup, maybe we could do something similar for Rad Mobile.??

[mahoneyt944]

There has to be something like that, since newer mame and fbneo skips this screen. Just haven't found how this works. Wonder what dink has in fbneo for this?

[MistyDreams]

its fixed in mame090 and above there is input changes among other things.

[arcadez2003]

They also added Eeprom's for both Rad games which i assume might have default settings which include bypassing the comms check.?? but as Misty said we also have to factor in all those input changes when the driver was rewritten circa MAME90 - 98.

Which reminds me i'll have to check over the sound code in this period which will likely have the fix i need for SlipStream

[MistyDreams]

@arcadez2003 here is dump from mame current.

hexdump ~/Desktop/eeprom-radr.ic76 -v -e '15/1 "0x%02X, " 1/1 " 0x%02X,\n"'

0x45, 0x53, 0x41, 0x47, 0x00, 0x03, 0x00, 0x01, 0x04, 0x43, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x01, 0xFF, 0x01, 0x01, 0x01, 0x00, 0x00, 0x01, 0x00, 0x01, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00,
0x75, 0x07, 0x07, 0x07, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00,
0x45, 0x53, 0x41, 0x47, 0x00, 0x03, 0x00, 0x01, 0x04, 0x43, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x01, 0xFF, 0x01, 0x01, 0x01, 0x00, 0x00, 0x01, 0x00, 0x01, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00,
0x75, 0x07, 0x07, 0x07, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00,

mame 090

unsigned char radr_default_eeprom[128] = {
0x45, 0x53, 0x41, 0x47, 0x00, 0x03, 0x00, 0x01, 0x04, 0x43, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x01, 0xFF, 0x01, 0x01, 0x01, 0x00, 0x00, 0x01, 0x00, 0x01, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00,
0x75, 0x07, 0x07, 0x07, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00,
0x45, 0x53, 0x41, 0x47, 0x00, 0x03, 0x00, 0x01, 0x04, 0x43, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x01, 0xFF, 0x01, 0x01, 0x01, 0x00, 0x00, 0x01, 0x00, 0x01, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00,
0x75, 0x07, 0x07, 0x07, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00
};

[mahoneyt944]

Here's a workaround hack if we can't figure it out.

static READ16_HANDLER( system32_io_r )
{
/* I/O Control port at 0xc00000

    { 0xc00000, 0xc00001, input_port_1_word_r },
    { 0xc00002, 0xc00003, input_port_2_word_r },
    { 0xc00004, 0xc00007, sys32_read_ff },
    { 0xc00008, 0xc00009, input_port_3_word_r },
    { 0xc0000a, 0xc0000b, system32_eeprom_r },
    { 0xc0000c, 0xc0004f, sys32_read_ff },
*/
    switch(offset) {
    case 0x00:

        return readinputport(0x01);
    case 0x01:
        return readinputport(0x02);
    case 0x02:
        return 0xffff;
    case 0x03:
        /* f1lap*/
        return 0xffff;
    case 0x04:
        return readinputport(0x03);
    case 0x05:
        if (cpu_getcurrentframe()==10 && (!strcmp(Machine->gamedrv->name,"radr"))) return 95;
        return (EEPROM_read_bit() << 7) | readinputport(0x00);
    case 0x06:
        return 0xffff;
    case 0x07:
        /* scross*/
        return sys32_tilebank_external;
    case 0x0e:
        /* f1lap*/
        return 0xffff;
    default:
        log_cb(RETRO_LOG_DEBUG, LOGPRE "Port A1 %d [%d:%06x]: read (mask %x)\n", offset, cpu_getactivecpu(), activecpu_get_pc(), mem_mask);
        return 0xffff;
    }
}

[MistyDreams]

I dont have any interest in updating the driver for one game to boot.

[mahoneyt944]

Ok pushed the hack to bypass the network check and updated the dip for the transmission selection. Game plays very nice now 😃 https://github.com/libretro/mame2003-plus-libretro/commit/a2f76b2c4e99e2ce2589cb430c417501ecebd7be

All the remaining issues I believe is from the colors, I think priority bits are flagged in the colors, so when the colors are not handled right we get some priority issues as well like in alien3 first boss, and likely the color issues we have in ga2 and slipstrm etc

[MistyDreams]

you could bring in the mame090 segas32 video the segas 6 is already in see that on how how to plug it all up.

[arcadez2003]

I tried that a few years back then again i did attempt to keep everything else in the driver circa MAME78 that was likely my mistake but as i was unsure how to convert the tagged inputs for use in our core i was kinda hitting a brick wall.

i suppose someone with more between the ears than me might just pull it off but for the record we need the video code from MAME98 as it has all the fixes then a few extra commits from slightly later builds to fix the palette in GA 2 etc etc.

As i said earlier there are some hurdles in the rewritten driver......... ADDRESS_MAP_FLAGS( AMEF_UNMAP(1) ) ADDRESS_MAP_FLAGS( AMEF_UNMAP(1) | AMEF_ABITS(8) ) AM_MIRROR's all over the place AM_RANGE(0xf00000, 0xffffff) AM_ROM AM_REGION(REGION_CPU1, 0) a couple of these by looks and my ole faves some mem and rom banking

From memory the video code is tied in with the V60 commands the IO ports for the inputs and likely some other stuff which escapes me what im sayin is im not sure we can just backport the video code alone but i stand to be corrected :)

[arcadez2003]

Here is my Xbox Segas32 the code has been hacked to work alongside the older system and multi32 code the CPU has been underclocked to speedup the games on the xbox there are some dummy inputs as i had to work around my core not supporting the later safe tagging method.

I only support Dark Edge Golden Axe RODA and SlipStream as yet. Xbox Segas32.zip

[mahoneyt944]

Yeah I looked at it as well, and it's funny because each version has its ups and downs with segas32. I think title fight graphics are worse, radm was missing the winners don't do drugs in some newer versions and stuff like that. I was considering using arrays to do the input by name stuff and just initing the correct ports for each game. But I think with some more work I could get the color thing sorted with what we have. Most games play really well all things considered.

Just port the color stuff and see what that gets us?

[arcadez2003]

Yeah I looked at it as well, and it's funny because each version has its ups and downs with segas32. I think title fight graphics are worse, radm was missing the winners don't do drugs in some newer versions and stuff like that. I was considering using arrays to do the input by name stuff and just initing the correct ports for each game. But I think with some more work I could get the color thing sorted with what we have. Most games play really well all things considered.

Just port the color stuff and see what that gets us?

Multi32 eg Title Fight is only affected after the merge before that those games were still using the older system32 video drawing see my post above i kinda found a best of both worlds kinda deal and the option is there to expand more games into that driver however we need to factor in the performance drop with the rewritten video drawing.

But ofcourse ideally you would sort the colours in the older video code then we would not need to update :)

[mahoneyt944]

Need a list of bugs so I can look into them I know about: Ga2 - colors Alien3 - priorities 1st boss, and alot of big gates/ doors Slipstrm- colors Sonicp- some priority stuff here and there Support for Zooming

Most of these I believe are all related to color and priorities, we do some odd mixing with brightness too. I've already experimented with hacking the indirect palette to corrected some of these, but would need to actually hook it up properly to fix it.

[arcadez2003]

Sonicp will lockup on level 4 the game will just freeze basically a fix was done for this in the video code i'd need find the commit to remind myself of what changed i think it's the palette though.

Edit the fix was after the rewrite hence we dont have it.

Fixed the official non proto release 0.79u1: Roger Sanders emulated the protection in Segasonic (Japan rev. C) - still crashes due to video emulation bug.

Gfx fix for the above no mention of sorting the crash though 0.104u7: Fixed indirect palettes in the System 32 driver [Anonymous]. This fixes SegaSonic The Hedgehog graphics finally. 0.101u5: Fixed SegaSonic so it works as well as the prototype version (still major graphics issues) [Anonymous] - Game now playable.

[mahoneyt944]

Oh and darkedge colors, which reminds me we should add the protection is to get that one booting as well.

Sonics lockup could probably be worked around, I'd need the details on the fix and see if we could manipulate our code or even implement a hack workaround.

[arcadez2003]

Oh and darkedge colors, which reminds me we should add the protection is to get that one booting as well.

Sonics lockup could probably be worked around, I'd need the details on the fix and see if we could manipulate our code or even implement a hack workaround.

Did that a while back as someone asked about it as i recall it would use system32_mixerShift = 4; colours are messed up with some characters and Bg's while fine with some others.

But there was an issue as the game would lockup i assumed it was down to the vblank-prot however maybe it's related to the sonic crash the vblank prot is good for F1 Lap though so in theory should be fine to use as a hookup for DarkEdge although F1lap only used it for the comms check DarkEdge could be doin more with it.

I never added the test code to this core so we'd need to startover sometime.

[mahoneyt944]

Ok. Wonder if plays any different with some of our recent changes, bgs really improved with ga2. I've been able to fix the screen transitions too, related to color and priorities on the indirect palette

[MistyDreams]

mistake but as i was unsure how to convert the tagged inputs for use in our core i was kinda hitting a brick wall.

the taginputs can easily be done just number the inputs instead of a string

static WRITE16_HANDLER( analog_custom_io_w )
{
    static const char *names[] = { "ANALOG1", "ANALOG2", "ANALOG3", "ANALOG4" };
    switch (offset)
    {
        case 0x10/2:
        case 0x12/2:
        case 0x14/2:
        case 0x16/2:
            analog_value = readinputportbytag_safe(names[offset & 3], 0);
            return;
    }
    logerror("%06X:unknown analog_custom_io_w(%X) = %04X & %04X\n", activecpu_get_pc(), offset*2, data, mem_mask ^ 0xffff);
}

static WRITE16_HANDLER( analog_custom_io_w )
{
    static const char names[] = { 0, 1, 2, 3 };
    switch (offset)
    {
        case 0x10/2:
        case 0x12/2:
        case 0x14/2:
        case 0x16/2:
            analog_value = readinputport(names[offset & 3);
            return;
    }
    logerror("%06X:unknown analog_custom_io_w(%X) = %04X & %04X\n", activecpu_get_pc(), offset*2, data, mem_mask ^ 0xffff);
}

not sure if there is a specific case you need to work around though

[mahoneyt944]

0.104u7: Fixed indirect palettes in the System 32 driver [Anonymous]. This fixes SegaSonic The Hedgehog graphics finally.

Don't think this is it, the fix I can see was to skip two entries when we are drawing "indirect and indlocal". This from what I can tell is already what we do in our old code, so that must have been a regression after the rewrite https://github.com/mamedev/historic-mame/blob/f65b917f602203c0f1d44f0b94ac6e684cecab21/src/vidhrdw/segas32.c#L1894

https://github.com/libretro/mame2003-plus-libretro/blob/a2f76b2c4e99e2ce2589cb430c417501ecebd7be/src/vidhrdw/system32_vidhrdw.c#L761-L766

[arcadez2003]

Hmm no mention of a game specific fix for the crash i'd usually have checked the driver wip but that is now gone on the Arcade database site the page is blank if it's clicked on there is always mametesters i suppose i'll look it up

EDIT nothing on mametesters no matter even if we fixed the crash the inputs for this game kinda suck anyhow making it more or less impossible to play i'll focus on DarkEdge.

[mahoneyt944]

Our indirect palette seems wrong, which is all the color issues in ga2. Need to look into it more.

[mahoneyt944]

Here's an update to the clipping

https://github.com/libretro/mame2010-libretro/blob/5f524dd5fca63ec1dcf5cca63885286109937587/src/mame/video/segas32.c#L1929-L1949

[arcadez2003]

Good job im currently hooking up Darkedge and the other non working game Dragon Ball Z: V.R. V.S.