Need some help.

[mahoneyt944]

@grant2258 @arcadez2003

So I managed to backport segas32 video code and patched it into our old drivers for system32 and multi32. I decided to only focus on the video portions for now, and I'll look into the irq controllers and IO in a later update....

All system32 games are working. However I can't figure out how to configure the mem maps for multi32 when converting them from 16 to 32. Here's my branch https://github.com/libretro/mame2003-plus-libretro/compare/master...Segas32v

And the WIP map for multi32, the /* fix me */ notes are just because the handlers are not converted to 32 yet, wanted to get the games at least booting first.

static MEMORY_READ32_START( multi32_readmem )
    { 0x000000, 0x1fffff, MRA32_ROM },
    { 0x200000, 0x21ffff, MRA32_RAM }, /* work RAM*/
    { 0x300000, 0x31ffff, multi32_videoram_r },
    { 0x400000, 0x41ffff, multi32_spriteram_r },
    { 0x500000, 0x50000f, multi32_sprite_control_r },
    { 0x600000, 0x60ffff, multi32_paletteram_0_r },
    { 0x610000, 0x61007f, multi32_mixer_0_r },
    { 0x680000, 0x68ffff, multi32_paletteram_1_r },
    { 0x690000, 0x69007f, multi32_mixer_1_r },
    { 0x700000, 0x701fff, shared_ram_32_r },    /* Shared ram with the z80*/
/* fix me */    { 0xc00000, 0xc0003f, /*multi32_io_r*/MRA32_RAM },
/* fix me */    { 0xc00050, 0xc0005f, /*multi32_io_analog_r*/MRA32_RAM },
/* fix me */    { 0xc00060, 0xc0007f, /*multi32_io_2_r*/MRA32_RAM },
/* fix me */    { 0xc80000, 0xc8007f, /*multi32_io_B_r*/MRA32_RAM },
    { 0xd80000, 0xdfffff, random_number_32_r },
    { 0xf00000, 0xffffff, MRA32_BANK1 }, /* High rom mirror*/
MEMORY_END

static MEMORY_WRITE32_START( multi32_writemem )
    { 0x000000, 0x1fffff, MWA32_ROM },
    { 0x200000, 0x21ffff, MWA32_RAM }, /* work RAM */
    { 0x300000, 0x31ffff, multi32_videoram_w, (data32_t **)&system32_videoram },
    { 0x400000, 0x41ffff, multi32_spriteram_w, (data32_t **)&system32_spriteram },
    { 0x500000, 0x50000f, multi32_sprite_control_w },
    { 0x600000, 0x60ffff, multi32_paletteram_0_w, (data32_t **)&system32_paletteram[0] },
    { 0x610000, 0x61007f, multi32_mixer_0_w },
    { 0x680000, 0x68ffff, multi32_paletteram_1_w, (data32_t **)&system32_paletteram[1] },
    { 0x690000, 0x69007f, multi32_mixer_1_w },
    { 0x700000, 0x701fff, shared_ram_32_w }, /* Shared ram with the z80*/
/* fix me */    { 0xc00000, 0xc0003f, /*multi32_io_w*/MWA32_RAM },
/* fix me */    { 0xc00050, 0xc0005f, /*multi32_io_analog_w*/MWA32_RAM },
/* fix me */    { 0xc00060, 0xc0007f, /*multi32_io_2_w*/MWA32_RAM },
/* fix me */    { 0xc80000, 0xc8007f, /*multi32_io_B_w*/MWA32_RAM },
/* fix me */    { 0xd00006, 0xd00007, irq_ack_32_w },
    { 0xd80000, 0xdfffff, random_number_32_w },
    { 0xf00000, 0xffffff, MWA32_ROM },
MEMORY_END

[arcadez2003]

As you'll likely know they merged multi32 with segas32 it might be easier to update further to use the same video code for all of the games.?? if not then @grant2258 will likely have the advice on how to procede with the 32bit mem maps.

Great work BTW this has long been a big want for users of this core.

[mahoneyt944]

@arcadez2003 yes both drivers are using the new video code for everything I just didn't lump them into one file yet.

[mahoneyt944]

I think the issue is that the mapping expects a 32 bit address but our game isn't using the high side so it's treating it as 16 bit which fails the validity check.

[grant2258]

WRITE16_HANDLER () READ16_HANDLER just need changed too WRITE32_HANDLER () READ32_HANDLER() and any masking that is needed to the code that's in them. If you can be more specific on the driver because the cpu basically will decide the read and write handle sizes on this core.

[mahoneyt944]

@grant2258 seems like the mem map itself needs a mask, because the mapper thinks it's 16 when we're specifying 32. Later mame uses mask and unmap high macros. I think that's why it's failing.

[grant2258]

If its asking for 16 it is 16 we dont have address spaces on this core you need to make trampolines on cpus with different address widths.

[mahoneyt944]

I'll keep trying to get the map to validate for multi32. For now I'm updating this as a part 1, all system32 games are working. Hopefully I can get multi going soon. https://github.com/libretro/mame2003-plus-libretro/commit/b6aac3b86951e1b09b93372aa3fcc3dd55484e0d

[grant2258]

thats perfectly fine the v60 probably has 8/16bit io I would need to look at the source to confirm it.

multi32.c:459:36: warning: excess elements in struct initializer
  459 |         { 0xe000, 0xffff, MRA_RAM, &z80_shared_ram },

you cant use the &z80_shared_ram reads only the writes you need to return the array itself with the read on this core. It could be added though in the memory related code.

[mahoneyt944]

thats perfectly fine the v60 probably has 8/16bit io I would need to look at the source to confirm it.

multi32.c:459:36: warning: excess elements in struct initializer
  459 |         { 0xe000, 0xffff, MRA_RAM, &z80_shared_ram },

you cant use the &z80_shared_ram reads only the writes you need to return the array itself with the read on this core. It could be added though in the memory related code.

I did this https://github.com/libretro/mame2003-plus-libretro/commit/96034b6efec636f5b10274e26481a8bcd436f4d3

Maybe it should be a read handler instead though?

[grant2258]

yea you need to put read handlers in case different cpu change the data you need to handle the masks of different widths though when sharing memory. This core doesnt have shared memory or address spaces so you have to respect the cpu data width as well.

cpu #0 uses wrong data width memory read handlers! (width = 16, memory = 50000003)

I fixed the logging for you the cpu is requesting 16 bit

@mahoneyt944 system32 has no WRITE32_HANDLER or READ32_HANDLER not sure why your setting it to 32 should be 16 like the cpu is asking.

cpu0 define: https://github.com/libretro/mame2003-plus-libretro/blob/a510183a5378c4648d4077c924178aebce3b4732/src/cpuintrf.c#L257

V60 params https://github.com/libretro/mame2003-plus-libretro/blob/a510183a5378c4648d4077c924178aebce3b4732/src/cpuintrf.c#L411-L412

as you can see its data width is 16 bit for this core.

The v70 is 32 bit though check what cpu the source your updating from is if its v70 it will be 32 bit

https://github.com/libretro/mame2003-plus-libretro/blob/a510183a5378c4648d4077c924178aebce3b4732/src/cpuintrf.c#L414-L415

[mahoneyt944]

The v70 is 32 bit though check what cpu the source your updating from is if its v70 it will be 32 bit

Mame 97u5 is where the video code is compatible . Yes it's V70. Let me try. Totally forgot to switch that.

Edit: yup now it's getting past the mem maps, need to fix the irq / inputs and it might work now. The "fix me" stuff in the mem map

[grant2258]

you might want to undo the the recent v60mem change so your consistent with the memread and writes code needs this. Ill fixe it properly for LE BE at some point anyway when your done. This change will break the dbzvrvs fix that was work round it being wrong.

I ll do any fixes when your finished working on what youve done it will only be an issue if your accessing reads via cpu_writemem and cpu_readmem functions on your part.

[mahoneyt944]

you might want to undo the the recent v60mem change so your consistent with the memread and writes code needs this. Ill fixe it properly for LE BE at some point anyway when your done. This change will break the dbzvrvs fix that was work round it being wrong.

I ll do any fixes when your finished working on what youve done it will only be an issue if your accessing reads via cpu_writemem and cpu_readmem functions on your part.

Grab the current master and PR whatever you think. I need a break from this anyhow.

Here: https://github.com/libretro/mame2003-plus-libretro/commit/a3e1bdecc25fc11ecc7eaa55cab7cf14903827da

[mahoneyt944]

Here: a3e1bde

Might just be the irq now. I'll try

[mahoneyt944]

I logged irq_ack_32_w, it's alive! Just need to use the proper masking to call the irq.

mem_mask.  Data
ff00ffff    40000
  ffffff        0
ffffff00       1c
ffff00ff        0

[mahoneyt944]

@grant2258 I fixed the video update for multi32, turns out it was a slight difference between screens noted here https://github.com/libretro/mame2003-plus-libretro/commit/f3bbd6284a0fe80a111c97973934664f22e3e3ff

I'm forcing the video to start with displayenable always on and the reads returning 0xffffffff and we get video and sound for harddunk!

So all that's left is to fix the mem_masks for all the read and write handlers noted as "fix me" in the multi32 main mem map. These have read32 and write32 headers but haven't actually been converted

[grant2258]

The code in mame097 and mem_mask should work properly here as well its just a matter of back porting it.

[mahoneyt944]

No luck on getting it to work.

[grant2258]

you could just use the old video code for the multi32 and leave a note in the driver that it needs converted to the new code if your not getting any traction in getting it to work.

[grant2258]

I looked at the video code @mahoneyt944 the mame097u5 code can be copy pasted to this core the was no dual display at that point in time in mame. It will most likely be the videoram and spriteram conversions as we dont have address spaces in this core it needs done manually.

[mahoneyt944]

@grant2258 it occured to me that once I fixed the video update undefined behavior in #1763 that the V60 model might work again for multi32. #1766 fixes multi32 games 😀. Probably better this way anyhow since its noted that V60 is 100% compatible and faster than V70.

[grant2258]

Well if it works it works. There is a bigger issue I want to look into and that is why all the LSB_FIRST where changed in the code. Things arent working like they should but I do know how to work round it when its an issue. x64 and x86 should be handling unaligned ints without issues. Ill port the original mame078 code at some point to check out if its a 64 bit issue or some kind of libretro understanding retro_inline seeing things differently.