Virtua Racing

[arcadez2003]

Without rabbiting on here i've added support for Virtua Racing the game has two issues which i'll get to shortly this is how they fixed it...

0.114: Ernesto Corvi updated Virtua Racing to use the TGP core, based on guessing from the Daytona TGP code with some modifications needed for Virtua Racing, the real TGP program is an internal ROM and still needs dumping - Game now playable. Added MB86233 (16MHz) CPU3 and 8k TGP rom (vr-tgp.bin).

We dont have that CPU so @mahoneyt944 @MistyDreams @grant2258 do one of ya's fancy taking a look at the track logic
code i've added to model1 machine sometime with a view to maybe tweaking it to sort two issues which are preventing the game from being 100% playable....

First and most serious bug.......

The game freezes if you crash and to race again you have to do an ingame reset and start over

Im thinking it's a respawn issue with the track logic the code is either wrong or incomplete hence the game doesn't know
where to put the car back on the track after you crash hence it just stalls..

Second bug lesser of the two...

The game forces you into the pit on the second lap...

Now i've never really played this game in the arcades or home console so i dont know if this is meant to happen
i suspect not, but certainly after the wheels are changed etc etc you dont have much time to finish the lap making it difficult to win a race however it might just be the overall race time was set too low via the dips.

That's the two bugs more or less if ya's fancy taking a peek at the code it can be found in model1_machine.c f65ef6d

[arcadez2003]

0.114: Ernesto Corvi updated Virtua Racing to use the TGP core, based on guessing from the Daytona TGP code with some modifications needed for Virtua Racing, the real TGP program is an internal ROM and still needs dumping - Game now playable. Added MB86233 (16MHz) CPU3 and 8k TGP rom (vr-tgp.bin).

Hmm hacked code taken from Daytona USA which was hooked up to the TGP CPU core around the same time...

0.113u2: Guru and David Haywood added clone Daytona USA (With Saturn Adverts). Fixed cpu3 and user2 roms and rom loading.

Im assuming the track logic for Daytona was very close to Virtua Racing, there is no mention of when Daytona was made playable in MAME previous commits to the above sound as if it was playable beforehand http://adb.arcadeitalia.net/dettaglio_mame.php?game_name=daytona%20&arcade_only=0&autosearch=1

Which makes me wonder was it using a sim previously.?? and if so would that give some pointers for VR.??

[grant2258]

Im guessing you have ported the 0.107u3: Olivier Galibert fixed track lookup implementation in Virtua Racing, bringing the game much closer to playable. That was the last simulation update before the dsp. I can grab mame108 at some point and check if has the same bugs. I would say we would need the dsp for any progress to be honest. This core is a royal pain for adding sound and cpu cores with the workload involved. It should be an easy port for you xbox prot though. I really wish we where 079 or above thing like this would be easy and not a big workload.

[arcadez2003]

Im guessing you have ported the 0.107u3: Olivier Galibert fixed track lookup implementation in Virtua Racing, bringing the game much closer to playable. That was the last simulation update before the dsp. I can grab mame108 at some point and check if has the same bugs. I would say we would need the dsp for any progress to be honest. This core is a royal pain for adding sound and cpu cores with the workload involved. It should be an easy port for you xbox prot though. I really wish we where 079 or above thing like this would be easy and not a big workload.

Funny enough everytime i attempted to backport the CPU and hook it upto the game it would freeze on boot
backporting MAME CPU's from MAME114 to either 84 or 78 is a nightmare right enough.

[grant2258]

Its too big of a job for this core. I can look into porting it to mame084 if you want it working on the xbox the interfaces are far too different on our core, it is doable though on your ole xbox core though. It easy enough for me to compile mame 084 and run it on wine to test if its working or not.

[arcadez2003]

You'll run into a shitload of hurdles as the CPU would need to be radically reworked not to mention the driver and machine
will need updated also in all honestly i would not ask you to undertake so much graft TBH but thanks for offering.

[arcadez2003]

Right as per this commit i've tinkered with some of the code adding in the changes from MAME114 allbeit slightly modded
380fa90

Could one of ya's try the game with these changes to see how it goes, PS i'd do it myself but my Xbox died so im snookered.
all you have to do is start a race and then crash if it's still bad i have one more idea then i'll give ya's peace about this :)

[grant2258]

the new code just crashes it shows the initial text screen though. Ill try find out where is freaking out if you want that info.

[arcadez2003]

the new code just crashes it shows the initial text screen though. Ill try find out where is freaking out if you want that info.

Thanks for trying it can you do so one last time 4512961

Im trying to see what the changes from MAME114 will do allbeit without the hookup to the CPU.

mamedev/historic-mame@31acddd#diff-1fd6187d1054d74a109c37c5566067ee2ae99ff6c32f3c2974c3858bba0271a2

[grant2258]

still crashing

[arcadez2003]

It's no biggie this TBH some user tagged me elsewhere and asked me if i could port the Virtua Racing code
i had on the xbox across to here, i told em it was broken but since the game was playable to an extent they
were happy enough to play it.

I thought it was worth trying out some ideas at the same time im all out now unless one of ya's can think of
something to improve the game somewhat if not then it's no big deal.

[arcadez2003]

still crashing

Aye nae worries then i'll revert back to the original commit

[grant2258]

looks like i still have the mame095 libretro source on the old pc. Might get that up and running several things need fixed in it though lost the latest version when I deleted my github account. If I get it polished up ill add it add it too github so anyone can mess about with it.

[grant2258]

Had quick look looks like the new dps and v60 needs updated for vr to work it needs the v60_stall that was added in the updated in 114. Also managed to get the 95 core up so test things my end for your core as well.

I dont think ill be doing much with it might do the neogeo, cps and system16 updates. Dont think there is much difference in the speed of thinks from 078 but the bare bones are there if anyone ever has interested down the line.

[arcadez2003]

Had quick look looks like the new dps and v60 needs updated for vr to work it needs the v60_stall that was added in the updated in 114. Also managed to get the 95 core up so test things my end for your core as well.

Yeah im aware of this i did update the model 1 code to handle the new TGP CPU and hooked up V60 stall the problem
was and still is i suppose the CPU had so much incompatable code being from MAME114 as it was written after the
major overhall to the CPU core handling which came several builds previously.

I had to change and attempt to rollback so much code to get it to compile for MAME84 i likely messed up somewhere
along the road hence why i could never get VR to boot with it, anyway dont waste your time on this buddy i only meant to
look at whether it was possible to mess around with the sim code to see if one of ya's could improve it somewhat.

Anyway i'll close this down

[grant2258]

im going to tinker with it got the v60 done at least Ill need to look a little bit more into the interface changes for the dsp think the changes where around 104 ish from a brief look at it.

[arcadez2003]

im going to tinker with it got the v60 done at least Ill need to look a little bit more into the interface changes for the dsp think the changes where around 104 ish from a brief look at it.

Progress eh it's a pity i always tended to dump the code i could not get to work as i had it all done eg the driver / machine
V60 and i'd had the TGP CPU compilling and hooked up to the driver, i could have sent it all your way and you'd likely
have spotted where i went wrong with the CPU but alas i deleted it all years back...

There will be a few niggles to iron out which are easy enough but this is where you'll run into real trouble as MAME95
will not support a cpu_init written in the style below so you'd have to attempt to roll it back to what 95 would expect.

static void mb86233_init(int index, int clock, const void *config, int (*irqcallback)(int))
{
struct mb86233_config * _config = (struct mb86233_config *)config;
(void)index;
(void)clock;
(void)irqcallback;

memset(&mb86233, 0, sizeof( MB86233_REGS ) );

if ( _config )
{
	mb86233.fifo_read_cb = _config->fifo_read_cb;
	mb86233.fifo_write_cb = _config->fifo_write_cb;
}

mb86233.RAM = auto_malloc(2 * 0x200 * sizeof(UINT32));		/* 2x 2KB */
memset( mb86233.RAM, 0, 2 * 0x200 * sizeof(UINT32) );
mb86233.ARAM = &mb86233.RAM[0];
mb86233.BRAM = &mb86233.RAM[0x200];

state_save_register_global_pointer(mb86233.RAM,2 * 0x200 * sizeof(UINT32));

}

[grant2258]

well passing the config will defo be an issue still need to work round the interface the v60 and dsp are in this branch https://github.com/grant2258/mame2005/tree/v60. Running it you get a blue title screen and a freeze if osd_die isint implemented. I fixed up osd die and am getting this.

OSD_DIE) cpu #2 uses wrong 32-bit handlers for address space 0 (should be 8-bit)!

need to setup the rest of the interface just hacked in vf fifo from the driver I know its cheating! I really should also put the the rom that was originally in the driver. No for the joys of looking up the interface changes.

[arcadez2003]

well passing the config will defo be an issue still need to work round the interface the v60 and dsp are in this branch https://github.com/grant2258/mame2005/tree/v60. Running it you get a blue title screen and a freeze if osd_die isint implemented. I fixed up osd die and am getting this.

OSD_DIE) cpu #2 uses wrong 32-bit handlers for address space 0 (should be 8-bit)!

need to setup the rest of the interface just hacked in vf fifo from the driver I know its cheating! I really should also put the the rom that was originally in the driver. No for the joys of looking up the interface changes.

I've added the MB68233 CPU and the relevent code to hook it upto model1 driver and machine i'll send ya what i have
shortly i just need to mod it slightly so it will compile for MAME95

[grant2258]

Ive already got tit compiling just need to hunt the interface stuff down. I didnt mean to give you a workload it just peaked my interest. Its is appreciated though!

[arcadez2003]

Ive already got tit compiling just need to hunt the interface stuff down. I didnt mean to give you a workload it just peaked my interest. Its is appreciated though!

So you have i wish i'd seen those commits earlier it would saved me wasting an hour of my life ha ha ha oh well not to worry.

[grant2258]

Yea ive got it compiling fine no errors just looking at the interfacing differences atm

[grant2258]

looka like CPUINFO_PTR_REGISTER_LAYOUT needs done will look next weekend sick of looking at cpu interface and related code in different versions of mame!

[KMFDManic]

@arcadez2003 @grant2258 If you choose to revisit this, these cheats work, and I was able to finish levels successfully with them, in testing. I added to the cheat.dat, then deleted cheat.rzip, so they would properly update.

; [ Virtua Racing ]
:vr:00100000:50116C:0000F9E3:FFFFFFFF:Infinite Time
:vr:00000000:400E23:00000000:FFFFFFFF:Always finish in 1st Place:Note you must finish though to see the end credits - so use in conjunction with Infinite Time. NOTE - the display during play won't reflect this cheat though

[arcadez2003]

@KMFDManic Daft question did you check the dip switch options to see of there is one to increase the lap timer.??

[grant2258]

@arcadez2003 having a issue here. Ive added some debugging and fixed mame validation that wasnt working. The cpu isint even calling the init function whencor the cpu when mame starts. ( and it basically the first thing that starts in mame only the resource tracking starts before it.

int cpuintrf_init(void)

debugging I added is here

cpu_interface cpuintrf is defined here

https://github.com/grant2258/mame2005/blob/4c994717a889881f4489278428759c0b4ffe5a13/src/cpuintrf.c#L439-L445C13

cpu info is set here
https://github.com/grant2258/mame2005/blob/4c994717a889881f4489278428759c0b4ffe5a13/src/cpuintrf.c#L875

results of the output

All these cpus set to dummy (witch is sometime ok if a cpu isint complete) it not for me though lol.

cpuintrf[7].get_info == NULL (CPU_M65SC02)
cpuintrf[8].get_info == NULL (CPU_M65CE02)
cpuintrf[9].get_info == NULL (CPU_M6509)
cpuintrf[11].get_info == NULL (CPU_M6510T)
cpuintrf[12].get_info == NULL (CPU_M7501)
cpuintrf[13].get_info == NULL (CPU_M8502)
cpuintrf[16].get_info == NULL (CPU_M4510)
cpuintrf[21].get_info == NULL (CPU_I188)
cpuintrf[22].get_info == NULL (CPU_I286)
cpuintrf[52].get_info == NULL (CPU_M68008)
cpuintrf[60].get_info == NULL (CPU_TI990_10)
cpuintrf[61].get_info == NULL (CPU_TMS9900)
cpuintrf[62].get_info == NULL (CPU_TMS9940)
cpuintrf[64].get_info == NULL (CPU_TMS9985)
cpuintrf[65].get_info == NULL (CPU_TMS9989)
cpuintrf[67].get_info == NULL (CPU_TMS99100)
cpuintrf[68].get_info == NULL (CPU_TMS99105A)
cpuintrf[69].get_info == NULL (CPU_TMS99110A)
cpuintrf[104].get_info == NULL (CPU_PIC16C54)
cpuintrf[106].get_info == NULL (CPU_PIC16C56)
cpuintrf[108].get_info == NULL (CPU_PIC16C58)
cpuintrf[112].get_info == NULL (CPU_E116XT)
cpuintrf[113].get_info == NULL (CPU_E116XS)
cpuintrf[114].get_info == NULL (CPU_E116XSR)
cpuintrf[116].get_info == NULL (CPU_E132T)
cpuintrf[117].get_info == NULL (CPU_E132XN)
cpuintrf[119].get_info == NULL (CPU_E132XS)
cpuintrf[120].get_info == NULL (CPU_E132XSR)
cpuintrf[122].get_info == NULL (CPU_GMS30C2132)
cpuintrf[123].get_info == NULL (CPU_GMS30C2216)
cpuintrf[124].get_info == NULL (CPU_GMS30C2232)
cpuintrf[135].get_info == NULL (CPU_MB86233)

The validation (which I had to fix) gives us
src/drivers/model1.c: vr uses non-present CPU

the memory system bails with a which is safe to ignore since it set with the dummy cpu data.

src/drivers/model1.c: vr cpu #2 uses wrong data width memory handlers! (width = 8, memory = 000c0005)
src/drivers/model1.c: vformula uses non-present CPU
src/drivers/model1.c: vformula cpu #2 uses wrong data width memory handlers! (width = 8, memory = 000c0005)

Unless im reading this source wrong this should be pointing to a function that is set in cpu info structure. I dont see how this can possibly be null. Ill try look more at the weekend though.

other relevant info will just keep this here so i dont forget it all and start again when I come back to it.

src/cpuintrf.c:333:void mb86233_get_info(UINT32 state, union cpuinfo *info);
src/cpuintrf.c:875:	{ CPU_MB86233, mb86233_get_info },
src/cpu/mb86233/mb86233.c:1491:void mb86233_get_info(UINT32 state, union cpuinfo *info)
src/cpu/mb86233/mb86233.h:51:extern void mb86233_get_info(UINT32 state, union cpuinfo *info);

@KMFDManic ill have a look at your core when I get the time as well as looking into this more.

[KMFDManic]

@arcadez2003 I would have to poke around again. I opened the test menu, and was able to choose options to change there, such as difficulty, etc. But, I didn't notice any dipswitches, in my initial tests. Will check again:)

@grant2258 Thanks so much for humoring me on the cpu2, etc, as it is clearly gonna make things a lot cooler:) Also, this is a bit of an anomaly. But, remember how daphne didn't work with sound? I poked around a bit, and may have worked out how to "trigger" sound in the core. If it all works out, I will update my Repo, and hopefully, others can make use of it. But, successfully tested Dragon's Lair and Space Ace, WITH sound, on Daphne Libretro Core!

Lastly, I may have to check out your Repo for MAME 2005. Curious on how that will play out, once you get it off the ground:)

[arcadez2003]

@grant2258 when first starting out i used to get a similar message about memory handlers when trying to boot up the
seibuspi games another dev knew the reason for this but would not tell me ah Xbox scene drama :)

In the end it turned out i didn't know i had to declare any CPU being used by the core in a file called VCCPMAME.h
if it had not been done already, this file might be gone circa MAME95 or was only used for Xbox cores to compile with VS.?? but im wondering if you have to declare the new CPU in another file in the src that you've missed.?? hence it seems
to be dead and not functioning.??

EDIT check rules.mak there are HAS CPU calls in there for example https://github.com/search?q=repo%3Agrant2258%2Fmame2005%20HAS_I8051&type=code

[grant2258]

thanks for the updates @arcadez2003 I have done these adds. I still have the old mame files in place but te work is done in Makefile.common and the works been done in the v60 branch.

https://github.com/grant2258/mame2005/blob/4c994717a889881f4489278428759c0b4ffe5a13/Makefile.common#L166

https://github.com/grant2258/mame2005/blob/4c994717a889881f4489278428759c0b4ffe5a13/Makefile.common#L1450-L1456

i even added a check of the makefile to see what cpus where defined

make                                                                                                  
-DHAS_Z80=1 -DHAS_Z180=1 -DHAS_8080=1 -DHAS_8085A=1 -DHAS_M6502=1 -DHAS_M65C02=1 -DHAS_M65SC02=0 -DHAS_M65CE02=0 -DHAS_M6509=0 -DHAS_M6510=1 -DHAS_M6510T=0 -DHAS_M7501=0 -DHAS_M8502=0 -DHAS_N2A03=1 -DHAS_DECO16=1 -DHAS_M4510=0 -DHAS_H6280=1 -DHAS_I86=1 -DHAS_I88=1 -DHAS_I186=1 -DHAS_I188=0 -DHAS_I286=0 -DHAS_I386=1 -DHAS_V20=1 -DHAS_V30=1 -DHAS_V33=1 -DHAS_V60=1 -DHAS_V70=1 -DHAS_I8035=1 -DHAS_I8039=1 -DHAS_I8048=1 -DHAS_N7751=1 -DHAS_I8X41=1 -DHAS_I8051=1 -DHAS_I8052=1 -DHAS_I8751=1 -DHAS_I8752=1 -DHAS_M6800=1 -DHAS_M6801=1 -DHAS_M6802=1 -DHAS_M6803=1 -DHAS_M6808=1 -DHAS_HD63701=1 -DHAS_NSC8105=1 -DHAS_M6805=1 -DHAS_M68705=1 -DHAS_HD63705=1 -DHAS_HD6309=1 -DHAS_M6809=1 -DHAS_M6809E=1 -DHAS_KONAMI=1 -DHAS_M68000=1 -DHAS_M68008=0 -DHAS_M68010=1 -DHAS_M68EC020=1  -DHAS_M68020=1 -DHAS_T11=1 -DHAS_S2650=1 -DHAS_TMS34010=1 -DHAS_TMS34020=1 -DHAS_TMS9900=0 -DHAS_TMS9940=0 -DHAS_TMS9980=1 -DHAS_TMS9985=0 -DHAS_TMS9989=0 -DHAS_TMS9995=1 -DHAS_TMS99000=0 -DHAS_TI990_10=0 -DHAS_TMS99105A=0 -DHAS_TMS99110A=0 -DHAS_Z8000=1 -DHAS_TMS32010=1 -DHAS_TMS32025=1 -DHAS_TMS32026=1 -DHAS_TMS32031=1 -DHAS_CCPU=1 -DHAS_ADSP2100=1 -DHAS_ADSP2101=1 -DHAS_ADSP2104=1 -DHAS_ADSP2105=1 -DHAS_ADSP2115=1 -DHAS_ADSP2181=1 -DHAS_PSXCPU=1 -DHAS_ASAP=1 -DHAS_UPD7810=1 -DHAS_UPD7807=1 -DHAS_ARM=1 -DHAS_ARM7=1 -DHAS_JAGUAR=1 -DHAS_R3000=1 -DHAS_R4600=1 -DHAS_R4700=1 -DHAS_R5000=1 -DHAS_QED5271=1 -DHAS_RM7000=1 -DHAS_SH2=1 -DHAS_DSP32C=1 -DHAS_PIC16C54=0 -DHAS_PIC16C55=1 -DHAS_PIC16C56=0 -DHAS_PIC16C57=1 -DHAS_PIC16C58=0 -DHAS_G65816=1 -DHAS_SPC700=1 -DHAS_E116T=1 -DHAS_E116XT=0 -DHAS_E116XS=0 -DHAS_E116XSR=0 -DHAS_E132N=1 -DHAS_E132T=0 -DHAS_E132XN=0 -DHAS_E132XT=1 -DHAS_E132XS=0 -DHAS_E132XSR=0 -DHAS_GMS30C2116=1 -DHAS_GMS30C2132=0 -DHAS_GMS30C2216=0 -DHAS_GMS30C2232=0 -DHAS_I960=1 -DHAS_H83002=1 -DHAS_V810=1 -DHAS_M37710=1 -DHAS_PPC403=1 -DHAS_PPC602=1 -DHAS_PPC602=1 -DHAS_PPC603=1 -DHAS_SE3208=1 -DHAS_MC68HC11=1 -DHAS_MB86233=1

i even tried removing the #if condition here.

https://github.com/grant2258/mame2005/blob/4c994717a889881f4489278428759c0b4ffe5a13/src/cpuintrf.c#L875 to be double sure. The good thing is ive tracked down the failure so I know where to start looking when I have time!

edit @KMFDManic the core need some polish it was a test core I done years ago the analog scaling needs tweaked but games will boot and play. This core has mirror and sharing in the memory maps so is just handy to have. It just means I can test things my end if arcadez has niggles with his xbox core as a bonus. @arcadez2003 what kind if xbox is your cor for the original or 360?

[arcadez2003]

@grant2258 latest testing.....

results
clockork aquario
plays fine and the sound is good.compared it to the official ps4 release i have and it certainly is a good as that version. sound might be slightly better on mameoxtras as the rom uses hacked samples.

virtua racing
loads up fine now,it plays slower compared to older version and the sound can be rather glitchy at times. the glitch from the previous version where if you crashed your car it would then bug out the game is not there anymore thank goodness. if you set frameskip to 1 in the options it smoothens things out somewhat and certainly plays better that way,but still a bit slower than previous version.

Thanks again for your help with these it's a pity as i suspected Virtua Racing would take a hit on
performance with the MB86233 but better slower and working than faster and not.

[grant2258]

No problems glad it worked out in the end. I think the system18/16 mixing levels need fixed on general on the test core im using. Ill look into that dark winds always on the hunt for decent things to watch. I got my chuck delivered started eating and watching tv and fell asleep typical waste of a friday!

[arcadez2003]

here is the memory map for if you need it for plus `` A00000-A03FFF (00C000) = I/O space 800000-801FFF (00E000) = color RAM 400000-40FFFF (000000) = tile RAM 410000-410FFF (00F000) = text RAM 600000-6007FF (00F800) = object RAM FF0000-FF3FFF (00C000) = work RAM C00000-C0000F (00FFF0) = VDP 200000-2FFFFF (100000) = ROM 1/banking 000000-0FFFFF (100000) = ROM 0

edit: I updated to the latest hbmame roms and it runs fine with them as well but it also works on the original ones you gave me as well. So its up to you which ones you prefare to use.

Well im not really sure how i would implement the above into our ole driver as we dont have the
generic mem mapping which multible games hang off circa 95, in 78 it's done on a game to game basis
for example Shadow Dancer.

MAME95
static const struct segaic16_memory_map_entry rom_171_shad_info[] =
{
{ 0x3d/2, 0x00000, 0x04000, 0xffc000, ~0, misc_io_r, misc_io_w, NULL, "I/O space" },
{ 0x39/2, 0x00000, 0x02000, 0xffe000, ~0, MRA16_BANK10, segaic16_paletteram_w, &paletteram16, "color RAM" },
{ 0x35/2, 0x00000, 0x10000, 0xfe0000, ~0, MRA16_BANK11, segaic16_tileram_0_w, &segaic16_tileram_0, "tile RAM" },
{ 0x35/2, 0x10000, 0x01000, 0xfef000, ~0, MRA16_BANK12, segaic16_textram_0_w, &segaic16_textram_0, "text RAM" },
{ 0x31/2, 0x00000, 0x00800, 0xfff800, ~0, MRA16_BANK13, MWA16_BANK13, &segaic16_spriteram_0, "object RAM" },
{ 0x2d/2, 0x00000, 0x04000, 0xffc000, ~0, MRA16_BANK14, MWA16_BANK14, &workram, "work RAM" },
{ 0x29/2, 0x00000, 0x10000, 0xff0000, ~0, NULL, NULL, NULL, "????" },
{ 0x25/2, 0x00000, 0x00010, 0xfffff0, ~0, segac2_vdp_r, segac2_vdp_w, NULL, "VDP" },
{ 0x21/2, 0x00000, 0x80000, 0xf80000, 0x00000, MRA16_BANK17, MWA16_ROM, NULL, "ROM 0" },
{ 0 }
};

MAME78

static MEMORY_READ16_START( shdancer_readmem )
{ 0x000000, 0x07ffff, MRA16_ROM },
{ 0x400000, 0x40ffff, SYS16_MRA16_TILERAM },
{ 0x410000, 0x410fff, SYS16_MRA16_TEXTRAM },
{ 0x440000, 0x440fff, SYS16_MRA16_SPRITERAM },
{ 0x840000, 0x840fff, SYS16_MRA16_PALETTERAM },
{ 0xc00000, 0xc0ffff, vdp_r },
{ 0xe40000, 0xe4ffff, sys18_io_r },
{ 0xffc000, 0xffffff, SYS16_MRA16_WORKINGRAM },
MEMORY_END

static MEMORY_WRITE16_START( shdancer_writemem )
{ 0x000000, 0x07ffff, MWA16_ROM },
{ 0x400000, 0x40ffff, SYS16_MWA16_TILERAM, &sys16_tileram },
{ 0x410000, 0x410fff, SYS16_MWA16_TEXTRAM, &sys16_textram },
{ 0x440000, 0x440fff, SYS16_MWA16_SPRITERAM, &sys16_spriteram },
{ 0x840000, 0x840fff, SYS16_MWA16_PALETTERAM, &paletteram16 },
{ 0xc00000, 0xc0ffff, vdp_w },
{ 0xe40000, 0xe4ffff, sys18_io_w },
{ 0xfe0006, 0xfe0007, sound_command_nmi_w },
{ 0xfe0020, 0xfe003f, MWA16_NOP }, /* config regs */
{ 0xffc000, 0xffffff, SYS16_MWA16_WORKINGRAM, &sys16_workingram },
MEMORY_END

/***************************************************************************/

static void shdancer_update_proc( void ){
sys16_fg_scrolly = sys16_textram[0x0e90/2];
sys16_bg_scrolly = sys16_textram[0x0e92/2];
sys16_fg_scrollx = sys16_textram[0x0e98/2];
sys16_bg_scrollx = sys16_textram[0x0e9a/2];

set_fg_page( sys16_textram[0x0e80/2] );
set_bg_page( sys16_textram[0x0e82/2] );

sys16_fg2_scrollx = sys16_textram[0x0e9c/2];
sys16_bg2_scrollx = sys16_textram[0x0e9e/2];
sys16_fg2_scrolly = sys16_textram[0x0e94/2];
sys16_bg2_scrolly = sys16_textram[0x0e96/2];

set_fg2_page( sys16_textram[0x0e84/2] );
set_bg2_page( sys16_textram[0x0e86/2] );

sys18_bg2_active=0;
sys18_fg2_active=0;

if(sys16_fg2_scrollx | sys16_fg2_scrolly | sys16_textram[0x0e84/2]) sys18_fg2_active=1;
if(sys16_bg2_scrollx | sys16_bg2_scrolly | sys16_textram[0x0e86/2]) sys18_bg2_active=1;

}

static MACHINE_INIT( shdancer ){
sys16_update_proc = shdancer_update_proc;

sys18_io_reset();

}

static READ16_HANDLER( shdancer_skip_r ){
if (activecpu_get_pc()==0x2f76) {cpu_spinuntil_int(); return 0xffff;}
return sys16_workingram[0];
}

static DRIVER_INIT( shdancer ){
unsigned char RAM = memory_region(REGION_CPU2);
static const int shdancer_sound_info[] =
{
0x0f, 0x00000, / ROM #1 = 128K /
0x1f, 0x20000, / ROM #2 = 256K /
0x1f, 0x60000, / ROM #3 = 256K /
0x1f, 0xA0000 / ROM #4 = 256K */
};

sys18_splittab_fg_x=&sys16_textram[0x0f80/2];
sys18_splittab_bg_x=&sys16_textram[0x0fc0/2];
sys16_MaxShadowColors=0;
install_mem_read16_handler(0, 0xffc000, 0xffc001, shdancer_skip_r );

memcpy(sys18_sound_info, shdancer_sound_info, sizeof(sys18_sound_info));
memcpy(RAM,&RAM[0x10000],0xa000);

}

I know what you mean with regards to the mem addresses but we'd then have to write some
new proc code as per above to handle some of the games gfx and sound routines im not sure
i'd know how to do that off the top of my head TBH.

400000-40FFFF (000000) = tile RAM
{ 0x400000, 0x40ffff, SYS16_MRA16_TILERAM },

[arcadez2003]

here is the memory map for if you need it for plus `` A00000-A03FFF (00C000) = I/O space 800000-801FFF (00E000) = color RAM 400000-40FFFF (000000) = tile RAM 410000-410FFF (00F000) = text RAM 600000-6007FF (00F800) = object RAM FF0000-FF3FFF (00C000) = work RAM C00000-C0000F (00FFF0) = VDP 200000-2FFFFF (100000) = ROM 1/banking 000000-0FFFFF (100000) = ROM 0
edit: I updated to the latest hbmame roms and it runs fine with them as well but it also works on the original ones you gave me as well. So its up to you which ones you prefare to use.

Well im not really sure how i would implement the above into our ole driver as we dont have the generic mem mapping which multible games hang off circa 95, in 78 it's done on a game to game basis for example Shadow Dancer.

MAME95 static const struct segaic16_memory_map_entry rom_171_shad_info[] = { { 0x3d/2, 0x00000, 0x04000, 0xffc000, ~0, misc_io_r, misc_io_w, NULL, "I/O space" }, { 0x39/2, 0x00000, 0x02000, 0xffe000, ~0, MRA16_BANK10, segaic16_paletteram_w, &paletteram16, "color RAM" }, { 0x35/2, 0x00000, 0x10000, 0xfe0000, ~0, MRA16_BANK11, segaic16_tileram_0_w, &segaic16_tileram_0, "tile RAM" }, { 0x35/2, 0x10000, 0x01000, 0xfef000, ~0, MRA16_BANK12, segaic16_textram_0_w, &segaic16_textram_0, "text RAM" }, { 0x31/2, 0x00000, 0x00800, 0xfff800, ~0, MRA16_BANK13, MWA16_BANK13, &segaic16_spriteram_0, "object RAM" }, { 0x2d/2, 0x00000, 0x04000, 0xffc000, ~0, MRA16_BANK14, MWA16_BANK14, &workram, "work RAM" }, { 0x29/2, 0x00000, 0x10000, 0xff0000, ~0, NULL, NULL, NULL, "????" }, { 0x25/2, 0x00000, 0x00010, 0xfffff0, ~0, segac2_vdp_r, segac2_vdp_w, NULL, "VDP" }, { 0x21/2, 0x00000, 0x80000, 0xf80000, 0x00000, MRA16_BANK17, MWA16_ROM, NULL, "ROM 0" }, { 0 } };

MAME78

static MEMORY_READ16_START( shdancer_readmem ) { 0x000000, 0x07ffff, MRA16_ROM }, { 0x400000, 0x40ffff, SYS16_MRA16_TILERAM }, { 0x410000, 0x410fff, SYS16_MRA16_TEXTRAM }, { 0x440000, 0x440fff, SYS16_MRA16_SPRITERAM }, { 0x840000, 0x840fff, SYS16_MRA16_PALETTERAM }, { 0xc00000, 0xc0ffff, vdp_r }, { 0xe40000, 0xe4ffff, sys18_io_r }, { 0xffc000, 0xffffff, SYS16_MRA16_WORKINGRAM }, MEMORY_END

static MEMORY_WRITE16_START( shdancer_writemem ) { 0x000000, 0x07ffff, MWA16_ROM }, { 0x400000, 0x40ffff, SYS16_MWA16_TILERAM, &sys16_tileram }, { 0x410000, 0x410fff, SYS16_MWA16_TEXTRAM, &sys16_textram }, { 0x440000, 0x440fff, SYS16_MWA16_SPRITERAM, &sys16_spriteram }, { 0x840000, 0x840fff, SYS16_MWA16_PALETTERAM, &paletteram16 }, { 0xc00000, 0xc0ffff, vdp_w }, { 0xe40000, 0xe4ffff, sys18_io_w }, { 0xfe0006, 0xfe0007, sound_command_nmi_w }, { 0xfe0020, 0xfe003f, MWA16_NOP }, /* config regs */ { 0xffc000, 0xffffff, SYS16_MWA16_WORKINGRAM, &sys16_workingram }, MEMORY_END

/***************************************************************************/

static void shdancer_update_proc( void ){ sys16_fg_scrolly = sys16_textram[0x0e90/2]; sys16_bg_scrolly = sys16_textram[0x0e92/2]; sys16_fg_scrollx = sys16_textram[0x0e98/2]; sys16_bg_scrollx = sys16_textram[0x0e9a/2];

set_fg_page( sys16_textram[0x0e80/2] );
set_bg_page( sys16_textram[0x0e82/2] );

sys16_fg2_scrollx = sys16_textram[0x0e9c/2];
sys16_bg2_scrollx = sys16_textram[0x0e9e/2];
sys16_fg2_scrolly = sys16_textram[0x0e94/2];
sys16_bg2_scrolly = sys16_textram[0x0e96/2];

set_fg2_page( sys16_textram[0x0e84/2] );
set_bg2_page( sys16_textram[0x0e86/2] );

sys18_bg2_active=0;
sys18_fg2_active=0;

if(sys16_fg2_scrollx | sys16_fg2_scrolly | sys16_textram[0x0e84/2]) sys18_fg2_active=1;
if(sys16_bg2_scrollx | sys16_bg2_scrolly | sys16_textram[0x0e86/2]) sys18_bg2_active=1;

}

static MACHINE_INIT( shdancer ){ sys16_update_proc = shdancer_update_proc;

sys18_io_reset();

}

static READ16_HANDLER( shdancer_skip_r ){ if (activecpu_get_pc()==0x2f76) {cpu_spinuntil_int(); return 0xffff;} return sys16_workingram[0]; }

static DRIVER_INIT( shdancer ){ unsigned char RAM = memory_region(REGION_CPU2); static const int shdancer_sound_info[] = { 0x0f, 0x00000, / ROM #1 = 128K / 0x1f, 0x20000, / ROM #2 = 256K / 0x1f, 0x60000, / ROM #3 = 256K / 0x1f, 0xA0000 / ROM #4 = 256K */ };

sys18_splittab_fg_x=&sys16_textram[0x0f80/2];
sys18_splittab_bg_x=&sys16_textram[0x0fc0/2];
sys16_MaxShadowColors=0;
install_mem_read16_handler(0, 0xffc000, 0xffc001, shdancer_skip_r );

memcpy(sys18_sound_info, shdancer_sound_info, sizeof(sys18_sound_info));
memcpy(RAM,&RAM[0x10000],0xa000);

}

I know what you mean with regards to the mem addresses but we'd then have to write some new proc code as per above to handle some of the games gfx and sound routines im not sure i'd know how to do that off the top of my head TBH.

400000-40FFFF (000000) = tile RAM
{ 0x400000, 0x40ffff, SYS16_MRA16_TILERAM },

Also the game uses the same gfx handling as Clutch Hitter and Desert Breaker those are similar to
DD Crew in the sense the make heavy use of the sega VDP gfx, im not sure we have those VDP
gfx routines for segas18 and if the game needs em that will be another hurdle to cross :)

[grant2258]

Well I looked at the sega thread the sega ic is available. It look likes mahoneyt944 is keen to not use the new code and use the old code for most things and the new code for things that have issues.

mame2003-plus-libretro/src/drivers/segas16b.c

Lines 1456 to 1466 in 32fa606

	static MACHINE_INIT( generic_5704 )
	{
	int i;
	segaic16_tilemap_reset(0);
	for (i = 0; i < 16; i++)
	segaic16_sprites_set_bank(0, i, default_banklist[i]);
	sys16_soundbanktype=2;
	disable_screen_blanking = 0;
	}

so the tiles and sprites can be setup with no issues as far as i can see. I suppose youll need to ask him if he is willing to make the new proc to be honest I would personally use the new code that misty provided.

[arcadez2003]

Well I looked at the sega thread the sega ic is available. It look likes mahoneyt944 is keen to not use the new code and use the old code for most things and the new code for things that have issues.

mame2003-plus-libretro/src/drivers/segas16b.c

Lines 1456 to 1466 in 32fa606

	static MACHINE_INIT( generic_5704 )
	{
	int i;
	segaic16_tilemap_reset(0);
	for (i = 0; i < 16; i++)
	segaic16_sprites_set_bank(0, i, default_banklist[i]);
	sys16_soundbanktype=2;
	disable_screen_blanking = 0;
	}

so the tiles and sprites can be setup with no issues as far as i can see. I suppose youll need to ask him if he is willing to make the new proc to be honest I would personally use the new code that misty provided.

Yeah i know we have that code which is for the system 16 games for this game we'd also need the
firstly the system18 drawing as well as the VDP which from memory hangs off Sega C2 gfx might be too much graft for just one game though.

However there is a hack from MAME88.u1 for DD Crew and Clutch Hitter before they rewrote most
of the Sega code, it can hang off our ole system18 code with minimal changes i suppose whether it'll
work for Clock Work Aquario will depend on how much use it makes of the VDP.

[grant2258]

here is rough plug guide the game should display something. The input arent done and the vdp isint pluged and ill need to look into the system18 banks but this is how you plug into the tile system.

grant2258@a152984

[arcadez2003]

Im trying to plug it in via our existing system18 hookup with the addition of the system18 VDP via
Segac2 video with the per game hacks which were done for DDCREW Clutch Hitter via system16 video
for no other reason than it'll be easier to port across to the XBOX360 MAME72 src.

This will likely blowup in a million ways but there is the small chance it might just work :)

[grant2258]

well got the memory maps there if thats any use to you was just a quick smash up a few things will need fixed pretty sure the sound nmi is { 0xf00006, 0xf00007, sound_command_nmi_w },

[arcadez2003]

Yeah thanks for the headsup that's the address im using here, this is what i have it's untested
and might blow up :)

EDIT forgot to roll back the mem map and machine start done that now
WIP.zip

[grant2258]

Just seen this but here is my update looked into the banking for this core all im drawing is the tiles and system16 sprites. all the vdp is missing.

bank changes 9a61f5a

Ill have a look at your code in a bit dinners about ready but will get back to you. Its probably better your way can reach more cores that way.

[arcadez2003]

Just seen this but here is my update looked into the banking for this core all im drawing is the tiles and system16 sprites. all the vdp is missing.

bank changes 9a61f5a

Ill have a look at your code in a bit dinners about ready but will get back to you. Its probably better your way can reach more cores that way.

It's looking good if it doesnt need the VDP then that should make things easier, as for ease of porting
dont worry about that all i have to do is take all the SEGA updates from this core and fire em across
to MAME72 if need be.

Someone asked if i could do that but TBH he can just use MAME84 on the xbox for that anyhow
the main thing is getting the game to play for this core and it looks like your more or less there

Good job as always.!!!

[grant2258]

does need the vpd the platforms are missing ect your codes seg faulting though ill try trace it. The sounds also not working but that can go on the back burner for now.

src/vidhrdw/system16_vidhrdw.c:1419:4: runtime error: null pointer passed as argument 2, which is declared to never be null

[grant2258]

ok got your code up and running. The system16 sprites need fixed though ill leave that to @mahoneyt944 since he tends to use that old segas video code. Its not something I really want to waste time chasing when the newer video code works.

The sound is still an issue though need to compare the maps on on your xbox core since it works there.

the branch is here https://github.com/grant2258/mame2003-plus-libretro/tree/arcadez_aqua so you can see what ive changed and ill include the file update system18.c with the updates.

updatey.zip

its pretty impressive that segaic code being backported something I would consider a rabbit hole before even trying!

[mahoneyt944]

The point is to fix more games than we break, my issue was never the new video code, it was pushing big full driver updates without testing all the effected games. If a person isn't willing to test for regressions (which includes significant performance drops) then it's just a burden on others.

[grant2258]

I managed to fixed it anyway was the region set to 16_be that was causing the issue in this core. I dont really care what video code is used to be honest. Path of least resistance works for me. The sound need looked at though.

@arcadez2003 here is the update file
updatey.zip

[grant2258]

The point is to fix more games than we break, my issue was never the new video code, it was pushing big full driver updates without testing all the effected games. If a person isn't willing to test for regressions (which includes significant performance drops) then it's just a burden on others.

This is a medical clinical response the code obviously is fine performance wise arcadez core uses the sega ic. But if the old code is going that fine too.

[mahoneyt944]

The point is to use whatever code you want, just test your changes and watch for regressions. That's all. I don't care what code we use.

[arcadez2003]

It's possible that the sound rom loading from HBMAME in their original form would be good for here

ROM_REGION( 0x200000, REGION_CPU2, ROMREGION_ERASEFF ) /* sound cpu*/
ROM_LOAD( "c7.bin",   0x000000, 0x040000, CRC(f1183938) SHA1(9409f0dc02773892803bc6d37f1bdbd894cf1805) )
ROM_LOAD( "c6.bin",   0x080000, 0x080000, CRC(39f11291) SHA1(3b4680bd2e20bd297644dda0a26f958c74826d47) )
ROM_LOAD( "c5.bin",   0x100000, 0x080000, CRC(6a380dca) SHA1(4589efc9e994ef9d07d4033e20c21afca4875005) )
ROM_LOAD( "c4.bin",   0x180000, 0x080000, CRC(1bd081f8) SHA1(e5b0b5d8334486f813d7c430bb7fce3f69605a21) )

Similar to some system16 games bodyslam for example...

ROM_REGION( 0x20000, REGION_SOUND1, 0 ) /* 7751 sound data */
ROM_LOAD( "epr10029.c1", 0x00000, 0x8000, CRC(7e4aca83) SHA1(703486b96d493941ee87267e8363220a851f008e) )
ROM_LOAD( "epr10030.c2", 0x08000, 0x8000, CRC(dcc1df0b) SHA1(a82a557fa48f4b3e1ab38f61b84d749cd417e80f) )
ROM_LOAD( "epr10031.c3", 0x10000, 0x8000, CRC(ea3c4472) SHA1(ad8eac2d3d14fd6aba713f4d624861c17aabf757) )
ROM_LOAD( "epr10032.c4", 0x18000, 0x8000, CRC(0aabebce) SHA1(fab12df8f4eab270be491c6c025d832c338e1e83) )

[grant2258]

yea that seems to get us sound thats one less thing to do. Seems to me the vdp isint even hooked up until you done this update might be priorities with moon walker.

[arcadez2003]

The point is to use whatever code you want, just test your changes and watch for regressions. That's all. I don't care what code we use.

If the changes i've ported and grant has amended are good then i can assure you nothing will be broken or experience a performance drop as it's the code i've used on the Xbox for years since 2016 or so without one single user ever reporting a bug.

The bonus here is the code will hang off the existing video code we have for system18 and a new
hookup via segac2 is all that is required for the system18 vdp.

[arcadez2003]

Oh i forgot to say i grabbed the system18 changes from MAME88 and then pasted in the hacks from this changelog...

088u1_diff.zip

This code is just before the segas18 rewrite which also uses the same VDP via segac2.

[arcadez2003]

yea that seems to get us sound thats one less thing to do. Seems to me the vdp isint even hooked up until you done this update might be priorities with moon walker.

FYI the original Moonwalker sets are using an I8051 "or one of those varients" type CPU for an extra level of protection and we dont have it.

[grant2258]

Cant really look intro this much tonight but will try at the weekend. Ill see if I can get this working. There are gfx glitches in the system16 for shadowdancer when you get the dog to grab someone(not related to this) there are also some of these glitches in aquario with the old system16 video code. Hopefully that can be traced.

[arcadez2003]

Cant really look intro this much tonight but will try at the weekend. Ill see if I can get this working. There are gfx glitches in the system16 for shadowdancer when you get the dog to grab someone(not related to this) there are also some of these glitches in aquario with the old system16 video code. Hopefully that can be traced.

Sure mate we'll plod along on this there is no great hurry, i know what ya mean with Shadow Dancer
it's the ole rob peter to pay paul there are glitches with the ole video code but it's faster vs the newer code which is slower i also noticed a screen tearing issue in the game when using the newer code also.

In the end i decided to leave the parent set using the ole code and the two clones the new and that
way users could choose which versions they wanted.

[grant2258]

ok thats it done in dusted if anyone wants to improved the banking and the old sys16 gfx code its up to them. here is the finished goods.
updatey.zip

[arcadez2003]

@grant2258 ported it across to the MAME106 core
amadvance/advancemame#113

[grant2258]

nice to see things get filtered around its thankless way to pass your time though. Ill look more into the plus port of aquario. Need to get ready for work not floods or winds prevented that monday morning fate haha.

[mahoneyt944]

It occured to me that the segas32 video code was mostly adapted from pulling info from the modeler, an old model 1 emulator, which had many issues and no 3D support. It's to my understanding that model 1 was the successor to the system32 board and likely shares many similarities. I wonder if it would be possible to use the segas32 video code and adapt some of the model1 logic to it and get VF or VR to boot with different results?

[arcadez2003]

Well VF is playable as the simulation of the TGP logic is good whereas VR's is incomplete hence
it has problems, i suppose it would be worth checking if the sim is better in modler.?? as TBH
if it isn't then we're snookered withot the TGP logic CPU.