|
DU: Cave 1st Gen emulation accuracy project launch
#370592 - 10/27/17 01:52 AM
|
|
|
With many Cave games it is especially important to get extremely accurate emulation because they were programmed with the pushed limitations of the original hardware in mind when making them, maxing them out to the point of slowdown often. In order to get mame closer to the PCBs we can send boards to Phil Bennett and he'll add them to his work list and will be able to perfect things like video timings and pixel data. For example in ESP Ra.De. the game slows down more on the PCB than in mame, and it sometimes has sprites disappear when there is "too much" on screen, and it actually makes a cool looking overload effect on the PCB and a timing that makes survival slightly easier, something obviously important if acuracy is your goal. Something similar happens with Progear and other games. We need a deeper testing by Phil.
I sent the CPS1 setup mentioned here a while ago to Phil, it will arrive in a few days. I hooked up a mix of *several* CPS1 games. He will be able to get a large range of testing done and the emulation updates I'm sure will be awesome.
If anyone has a 1st Gen Cave game PCB they will *loan* to Phil (not asking for donations with these wildly expensive PCBs), let me know, and let's get this emulation of these games perfected so when your board dies your heart doesn't. :-)
You can also donate paypal and I will offer the donations as shipping payments for any board owners who don't feel like paying shipping but will otherwise loan it out. Let's get the accuracy updated.
http://smitdogg.mameworld.info/dumping/union.html
http://www.world-of-arcades.net/Cave/cave.htm
|
|
|
| Dullaron |
|
Diablo III - Dunard #1884
|
|
|
|
|
Reged: 07/22/05
|
|
Posts: 6125
|
|
Loc: Fort Worth, Tx
|
|
|
|
Send PM
|
|
|
Hope the Espgaluda sounds get fix someday.
[Re: Smitdogg]
#370593 - 10/27/17 02:35 AM
|
|
|
Imperfect stage.
|
W11 Home 64-bit + Nobara OS / AMD Radeon RX 5700 XT / AMD Ryzen 7 3700X 8-Core 3.59 GHz / RAM 64 GB
|
|
|
Re: DU: Cave 1st Gen emulation accuracy project launch
[Re: Smitdogg]
#370594 - 10/27/17 02:48 AM
|
|
|
> With many Cave games it is especially important to get extremely accurate emulation
> because they were programmed with the pushed limitations of the original hardware in
> mind when making them, maxing them out to the point of slowdown often. In order to
> get mame closer to the PCBs we can send boards to Phil Bennett and he'll add them to
> his work list and will be able to perfect things like video timings and pixel data.
> For example in ESP Ra.De. the game slows down more on the PCB than in mame, and it
> sometimes has sprites disappear when there is "too much" on screen, and it actually
> makes a cool looking overload effect on the PCB and a timing that makes survival
> slightly easier, something obviously important if acuracy is your goal. Something
> similar happens with Progear and other games. We need a deeper testing by Phil.
>
> I sent the CPS1 setup mentioned here a while ago to Phil, it will arrive in a few
> days. I hooked up a mix of *several* CPS1 games. He will be able to get a large range
> of testing done and the emulation updates I'm sure will be awesome.
>
> If anyone has a 1st Gen Cave game PCB they will *loan* to Phil (not asking for
> donations with these wildly expensive PCBs), let me know, and let's get this
> emulation of these games perfected so when your board dies your heart doesn't. :-)
>
> You can also donate paypal and I will offer the donations as shipping payments for
> any board owners who don't feel like paying shipping but will otherwise loan it out.
> Let's get the accuracy updated.
>
> http://smitdogg.mameworld.info/dumping/union.html
>
> http://www.world-of-arcades.net/Cave/cave.htm
So all those cave games will be emulated to the full extent of the jam? 
|
"Note to Noobs:
We are glad to help you but simply posting that something does not work is not going to lead to you getting help. The more information you can supply defining your problem, the less likely it will be that you will get smart-alec replies.
C.D.~"
|
|
|
Re: DU: Cave 1st Gen emulation accuracy project launch
[Re: Master O]
#370595 - 10/27/17 02:52 AM
|
|
|
|
|
|
Re: Hope the Espgaluda sounds get fix someday.
[Re: Dullaron]
#370596 - 10/27/17 02:54 AM
|
|
|
|
|
| Dullaron |
|
Diablo III - Dunard #1884
|
|
|
|
|
|
Reged: 07/22/05
|
|
Posts: 6125
|
|
Loc: Fort Worth, Tx
|
|
|
|
Send PM
|
|
|
|
> Which bug?
Espgaluda (2003/10/15 Master Ver) - espgal_igs027a.bin need to be redump. (Note: I didn't see this until I check it out. I don't know it have anything to do with the sounds or not.)
Edit: Heh. There more.
Ketsui: Kizuna Jigoku Tachi (2003/01/01. Master Ver.) - ket_igs027a.bin need to be redump.
DoDonPachi III (World, 2002.05.15 Master Ver) - ddp3_igs027a.bin need to be redump.
That 3 with Imperfect sounds.
Don't worry about it. Unless someone lean those boards out to you. 
All the rest of Cave games no problem on the dumps.
[ATTACHED IMAGE - CLICK FOR FULL SIZE]
|
W11 Home 64-bit + Nobara OS / AMD Radeon RX 5700 XT / AMD Ryzen 7 3700X 8-Core 3.59 GHz / RAM 64 GB
|
|
|
Re: Edited.
[Re: Dullaron]
#370605 - 10/27/17 02:59 PM
|
|
|
> > Which bug?
>
> Espgaluda (2003/10/15 Master Ver) - espgal_igs027a.bin need to be redump. (Note: I
> didn't see this until I check it out. I don't know it have anything to do with the
> sounds or not.)
>
> Edit: Heh. There more.
>
> Ketsui: Kizuna Jigoku Tachi (2003/01/01. Master Ver.) - ket_igs027a.bin need to be
> redump.
>
> DoDonPachi III (World, 2002.05.15 Master Ver) - ddp3_igs027a.bin need to be redump.
>
> That 3 with Imperfect sounds.
>
> Don't worry about it. Unless someone lean those boards out to you.
>
> All the rest of Cave games no problem on the dumps.
Imperfect sounds, yeah the ICS2115 emulation isn't perfect.
NO DUMP files, they're the protection device, simulation should be fine for the game in question, we have no way to dump those specific MCUs as they don't use an external code or exploitable commands (and they're the later type with Execute Only area, so we wouldn't get a complete dump even if they did have)
I think maybe more important to state with all these things is that even if Phil gets the boards it might not really be something that's easy to measure.
People have tried to measure waitstate / DMA impact etc. with other systems and found it to be a horribly complex subject, something that the MAME cpu cores (and general architecture) isn't really up to supporting. It can be complex even for a Z80 case (hence why MAME can't do ZX Spectrum properly right now) and for 68K level with DMA operations from different speeds or RAM & ROM it can really become nasty to work out.
You might get a closer approximation, but I wouldn't be surprised if Phil ended up with inconclusive information for some cases, as others have before him. Cases like this can even end up being different for repaired boards if different types of RAM / ROM were used than the original. Some NeoGeo bootlegs for example have raster glitches and crazy slowdown which can seemingly only be attributed to the ROM chips they use having worse access times than the original and the hardware actually stalling on reading from ROM as the actual code is the same.
|
|
|
|
Re: Edited.
[Re: Haze]
#370612 - 10/27/17 07:58 PM
|
|
|
> I think maybe more important to state with all these things is that even if Phil gets
> the boards it might not really be something that's easy to measure.
>
> People have tried to measure waitstate / DMA impact etc. with other systems and found
> it to be a horribly complex subject, something that the MAME cpu cores (and general
> architecture) isn't really up to supporting. It can be complex even for a Z80 case
> (hence why MAME can't do ZX Spectrum properly right now) and for 68K level with DMA
> operations from different speeds or RAM & ROM it can really become nasty to work out.
I'm confident I can get detailed timing measurements but as you say, actually implementing the timing in MAME may prove challenging.
Timing aside, I would otherwise be able to confirm whether or not our video emulation is pixel-exact under whatever cases I can test.
> You might get a closer approximation, but I wouldn't be surprised if Phil ended up
> with inconclusive information for some cases, as others have before him.
Has anybody looked at the Cave hardware specifically? If so, I'd be curious to hear about their methods and results.
|
|
|
|
|
> > I think maybe more important to state with all these things is that even if Phil
> gets
> > the boards it might not really be something that's easy to measure.
> >
> > People have tried to measure waitstate / DMA impact etc. with other systems and
> found
> > it to be a horribly complex subject, something that the MAME cpu cores (and general
> > architecture) isn't really up to supporting. It can be complex even for a Z80 case
> > (hence why MAME can't do ZX Spectrum properly right now) and for 68K level with DMA
> > operations from different speeds or RAM & ROM it can really become nasty to work
> out.
>
> I'm confident I can get detailed timing measurements but as you say, actually
> implementing the timing in MAME may prove challenging.
>
> Timing aside, I would otherwise be able to confirm whether or not our video emulation
> is pixel-exact under whatever cases I can test.
>
>
> > You might get a closer approximation, but I wouldn't be surprised if Phil ended up
> > with inconclusive information for some cases, as others have before him.
>
> Has anybody looked at the Cave hardware specifically? If so, I'd be curious to hear
> about their methods and results.
not the Cave hardware, I seem to recall Charles tried to measure some CPS1 stuff tho, without much success.
|
|
|
Previous 
Index 
Next 
Threaded 
DU: Cave 1st Gen emulation accuracy project launch
Reply
[Re: 
