Quartet and quartet2 title kludge disabled

[mahoneyt944]

This code has been commented out. Do we want to re-enable it or fix it another way?

[MistyDreams]

there is no code for it only variables remove the variables or add the code if there is an issue

[mahoneyt944]

There was an extram hook up in mame2000 (0xc40000, 0xc4ffff) which was used to toggle the kludge variable. Our mem maps are using sound and coinctrl here so probably need to hook it differently.

[MistyDreams]

whats actually wrong with the title sceen though

[mahoneyt944]

After the hiscore screen and before the titlescreen, the screen should do a swirl effect for a few seconds or "kludge". Run the game in mame2000 to see what I mean. A screenshot doesn't do it justice

[mahoneyt944]

Later mame hooks up a ppi port to handle this. But mame2000 just did it down and dirty with extram, we probably should also for simplicity.

[MistyDreams]

its fine fir me on master @ 4bba11d28dad8b2b0decea0e7e741063dc35fd05 and my branch ill update my repo to lastest master and try

[mahoneyt944]

The whole screen should spin.

[MistyDreams]

yea its should but im getting no corruption like you. It does say unprotected emulation anyway

[mahoneyt944]

I'm not getting corruption either. That picture is from mame2000 during a spin.

[MistyDreams]

just port it if you think its ok it looks bad from that shot though

[mahoneyt944]

How it's hooked changed in later mame to a ppi port, ideally I'd like to just hook the extram like they did in mame2000 instead of back porting the custom io.

Or I guess we would use read and write mem installers in the driver init.

[mahoneyt944]

Here's a video of the kludge https://youtu.be/uvc2IyQuUqc

[MistyDreams]

https://github.com/libretro/mame2000-libretro/blob/dd9d6612c29bf5b29bc2f94cab2d43fe3dcd69ee/src/vidhrdw/system16.c#L1904-L1910

youll need to port this portion of code

[mahoneyt944]

I'm thinking we make a custom video update for quartet so it doesn't get tangled in to the standard update. Much like the other misfit games.

[MistyDreams]

think you better hooking up the segas16a for this and bodyslam up to you though

[arcadez2003]

yea its should but im getting no corruption like you. It does say unprotected emulation anyway

Yip i think we need the I8051 CPU in order to run the protection MCU otherwise the game will fail a prot check on the later levels "missing platforms i think" and you cant progress, one version of Quartet 2 is unprotected so that is the version to use as it's fully playable right to the end.

https://github.com/mamedev/mame/commit/65238350c713151e1dc9a3b4f1e2966295173990

[MistyDreams]

does the i8051 have any practical use beyond quartet?

[arcadez2003]

does the i8051 have any practical use beyond quartet?

It's the protection mcu for quite a few Sega games of this era and many more besides, i was just shooting the breeze here with regards to why Quartet is broken, the I8051 cpu is not a realistic backport target due to the workload required

[MistyDreams]

I mean beyond sega in general the port doesnt look that bad to be honest. If it helps beyond this it might be worth doing. The problem is if you implement this youll also need to do the memory management configs at least partially in the drivers. As far as i can see if you have the 8751 the fd can be done with suicide repair sets. I think we should remove any references to the fd protected sets that dont work on this core anyway dont know how you feel about that seems pointless keeping them till there actually supported.

[MistyDreams]

@arcadez2003 I can see what you mean why adding other cpu and soundcores isharder in this core. I just started testing and got the multiple definitions speal. The good news its a two line fix. Its a pitty this wasnt addressed sooner. I can see that start of the core done it the hard way and renamed everything instead of removing the duplicates in the list which is standard practice in makefiles like this.

[mahoneyt944]

Whatever you guys prefer on that. If it's not available probably shouldn't have it. Keep things simple lol.

[arcadez2003]

I mean beyond sega in general the port doesnt look that bad to be honest. If it helps beyond this it might be worth doing. The problem is if you implement this youll also need to do the memory management configs at least partially in the drivers. As far as i can see if you have the 8751 the fd can be done with suicide repair sets. I think we should remove any references to the fd protected sets that dont work on this core anyway dont know how you feel about that seems pointless keeping them till there actually supported.

It's mostly used as a protection MCU looking at my core it seems i added it to support the official versions of Sega's Micheal Jackson's Moon Walker and then for good measure i used it so that the non bootleg versions of Taito's Super Qix would work.

So not much then after adding it but for me it was a simple drop in at anyrate, however there are tons of games that have since had their MCU's dumped and read out over the years so it can also be used to remove protection sim codes and replace it with the real thing but i've not yet got around to looking at those.

[MistyDreams]

the code is drop in just the cpu context differences in our core. Will need a lot more than a mcu for system18 on this core though

[arcadez2003]

Yip alotta graft then you'd need to update the soundcore and all the other drivers that use it for good measure, is it worth it though.?? as the best games on that system are already playable allbeit Alien Storm is missing some VDP gfx as the bootleggers just ripped em out.

Other than that the games we'd gain are not exactly top notch :)

Bloxeed (already have an Sega C2 version) Clutch Hitter (baseball) Desert Breaker (decent enough) D.D Crew (not bad) Hammer Away (extra tiles wont work with the older video code) Laser Ghost (alright) Where's Wally (not good)

[MistyDreams]

to be honest the vdp is an issue its connected to so many drivers just too much testing to think about

[MistyDreams]

we already have the n7751 cpu what version you need dropped in ? as far as i can see system16a doesnt use the 7752

[arcadez2003]

The n7751 is not the same as the I8751 which is based off the Intel I8051 CPU, so without rabbiting on to fix the protected versions of Quartet and Quartet 2 you need to......

A) port the I8051 CPU core B) hook up the I8051 MCU's for both games C) add in the mcu io code which contains the fix

Check the latest segas16a to see what i mean

[MistyDreams]

yea sorry put the i there by mistake we have it defined in i8039 just asking what version we need of it. https://github.com/libretro/mame2003-plus-libretro/blob/58ecbbb74eae6e454643b81660983e67df8b0f8f/src/cpu/i8039/i8039.c#L1058

[MistyDreams]

too many sim numbers am with you now. very odd quartet is doing this though! It snot really a great game looked up what i needed to know to add it if we needed too. CPU doesnt look too bad to do to be honest but can probably be covered in sim code

[MistyDreams]

there are some limitations we should update in this core think at least mame079 memory handling and cpu/sound interfaces is doable depends how you all feel about it really. Think this core is stuck without these types of updates

[arcadez2003]

TBH Quartet 2 is more or less the same game and there is an unprotected set better just to be happy we have that at least as for the memory update feel free to knock yourself out on that i for one will bow out gracefully :)

[MistyDreams]

you make it sound like updating these things are hard when its not just seems senseless having no shared memory, mirroring ect.drivers can be converted easy with sed supports the old way as well

[arcadez2003]

Well it's not gonna be straightforward is it.?? and what do we gain exactly.??

When it comes to backporting the later code then sure it'll make things far easier but the input handling here will still create a barrier between this core and potential game or code targets so you'd need to update that stuff also, in some ways it would be easier to just create a new core using my xbox MAME Sources as the baseline ;)

But being straight with ya here i just dont wanna work on this full stop im winding down nowadays more or less and my desire to put in the hours i used to have kinda waned for several reasons hence not interested in taking this on.

As i said if you wanna take a stab at this then feel free

[MistyDreams]

Well to be honest it also the limitations of the cpu io ports and such and ports being treated like they are 16 bit when they are really 8 bit.

Again moving on to a new mame works as well but thats beyond the scope of this core. I kinda get the feeling your fed up with all this all together. I get like that as well at times then come back fresh. You done a lot of good work here thought you might be interested is all. You seem to have been doing this a long time.

My nieces are in pie mode I did tell them to try FBN/FBA as well but FBN is pants on a rapsberry pie 3b so its fba or this core. I might port your ole core for them certainly will give them more options as far as the work you have put into it.

The interrupts are a bit haywire in this system as well.

[arcadez2003]

My feeling is we're trying to put a square peg into a round socket, as you've eluded to before many times previously this core is kinda at the end of the end of the road with regards to what can be added i mean if you updated the mem and the inputs i still cant think off all that much extra we could gain over and above the Sega drivers and likely Seibuspi

Yeah your right i've been doin this for a long time nearly 10 years now i still enjoy it i just think rather than go down this road it would be easier to just create a new core based off later MAME which will still perform well enough on the sorta hardware this core is aimed at.

MAME105 is a good solid version BTW perfect for your familes uses and anything not supported we have here can easily be dropped in from my xbox src with a few minor modifications.

[MistyDreams]

Well the cpu we can add are limited because of how they are hooked up. Problems with cpu port reads in certain conditions and interrupts to them are bogey in certain conditions. * bit ports are treated like 16 bit as well.

Addressing this will fix many issues. There is no concept of address space so no memory sharing or common cpu interface between cpus you need to lookup the cpu tables to find out how to read the alignment properly ect.

If this core was mame079 you could put anything thats in your 084 core its doesnt have these same limitations. I think mame105 is a bit high loads a stuff got transparency layers and slowed things down on older hardware. I see no real issue in the input code tags can be worked around easily. The analog could use some updates decoupling analog devices from each other instead of sharing them.

Again workable things could be updated going to mame0105 would make some games unplayable on a pi that are playable now. I dont think the original xbox360 hardware would coupe well with this either. I could just make them play mame on a real pc thats an ideal solution. 64 bit computers will likely suffer from mame105 using a 32bit like the ole xbox wouldn't be an issue though.

mame is reasonably modular so the gfx and input code doesnt change for the os much at all. I would need to check a few versions to make that choice if was going to take that route. Maybe just get them a pc and tell em to use mame current haha. They seen cotton2 and cotton boomerang i just said no haha!

[arcadez2003]

I thought it was MAME107 for the graphical changes alotta folks didn't like which were blamed for a big loss in performance but hey ho MAME92 also happens to be decent solid build surely that one would still perform at a decent enough level.??

[MistyDreams]

suppose just needs testing on pie started the segas16a update hooked up the ppi ect just need to do the 8751 get the sega16a up to speed. What I will say is 90 and above is maybe an issue with 64 bit could be fixing needing for the pie 4 so many thing to take into account. Using code from pre 64 bit era always needs looking at