Open Shoegzer opened 6 years ago
they are not "the same Hitachi SH-4 hardware" but only uses same SH-4 CPU, actually 2x such CPUs. in other - they are completely different hardware compared to Dreamcast/Naomi/etc.
the only DC-like hardware left is SystemSP
Thanks, good to know. I've updated the issue summary.
welcome. Smashing Drive uses SH-4's MMU so current reicast's sh4 emulation core will be not really useful.
there exists one more arcade hardware which uses SH-4 as main CPU - Capcom Medalusion. and also Aristocrat MKVI gambling machines, in general similar to Gaelco hardware but use single SH-4.
Interesting. That's highly specific so I'll keep it out of the issue summary for now, but again it's good to know. I really had no idea there was so much SH-4 out there beyond the obvious.
NAOMI 2 is even better.
The infamous SH3 (3rd generation Cave shmups) would also be a great addition. Maybe one of the talented devs that originally added it to Demul could help.
The infamous SH3 (3rd generation Cave shmups) would also be a great addition. Maybe one of the talented devs that originally added it to Demul could help.
SH3 games are now supported in MAME: http://www.progettoemma.net/indice.php?source=cv1k.cpp
They've been supported in mame since 10 years ago. I'm talking Flycast.
This is entirely off-topic given that the issue involves SH-4, not SH-3. The kind of hardware being emulated by Flycast has very little to do with SH-3, strictly speaking.
That said: @eadmaster does have a point, however the SH-3 games run too fast in MAME as the driver has timing-related issues that prevent slowdown per hardware limitations. Given that Cave's games took deliberate advantage of this slowdown by design, it's a critical flaw even though they appear to "play". Some other emulator dev that attempts SH-3 emulation might encounter a breakthrough that overcomes this issue, though it's non-trivial to do or MAMdevs would have done it years ago, and it won't change in MAME anytime in the near future.
Again though, we're off-topic, so please keep future SH-3 discussions out of this issue.
though it's non-trivial to do or MAMdevs would have done it years ago, and it won't change in MAME anytime in the near future.
it is trivial, its just there was no single person cared enough to benchmark CV1000 hardware.
Ah, fair enough, thanks. I recall discussions about this soon after the driver first hit the repo that led me to believe otherwise, but I'll defer to you. Perhaps it might happen someday then, would be nice to see these games actually "playable" as they had been, though I guess if nobody cares then it's the same condition either way.
Ok guys, so two things (bare with me).
It is not my intention to be offtopic, but Flyinghead merged my opened issue, regarding SH3 emulation in Flycast, with this one, so as a result i assume talk about it could be considered on topic.
Now, regarding the myth about these games being unplayable or VERY far from original speeds, these are simply exagerrations. Ever since many years ago when cv1000 driver got CPU % options, the games could be set to play very VERY close to original speeds. I have extensively tested the games (and on my mobile phone of all things) and got excelent results, very playable and very close to PCB speed values. Here are some examples. Mushihimesama: https://m.youtube.com/watch?v=huEORRBOeBY
Espgaluda 2: https://m.youtube.com/watch?v=VVh8NyNPLi0
Futari 1.5 (that small 2 second stutter are a recording issue): https://m.youtube.com/watch?v=XeHmynI_2oA
Now, as far as improvement in emulation, my observations led me to strongly believe that all these games run underclocked to values very close to the ones i found, for basically 99% of the time, with 'small' exceptions when the CPU is ramped up to deal with some realtime loading of certain assets. Not the other way around. There is some sort of small code that the emulator doesn't do, BUT even without it, MAME can set the games pretty close to originals, with the risc of some small and rare stuttering (Espgaluda 2, Muchi Pork, Deathsmiles) when CPU has to deal with some extra stuff.
P1pkin, are you MetalliC? The original coder for the SH3 driver? If so, then allow me to thank you sincerely for bringing these wonderful games to some of us, that wouldn't have been able to experience them otherwise ^_^
@RaduNastase As the OP of this issue I need you to STOP posting about SH-3. Not only did you misinterpret my comments about speed and playability, but again SH-3 has little to do with SH-4-hardware based core development per flycast's scope. Post your comments somewhere else, but NOT here.
@flyinghead please moderate accordingly, thanks.
@Shoegzer well, i don't think cv1k is off topic :
@barbudreadmon mame's sh3/sh4 codebase is indeed shared, and while afaik sh-3 has never been discussed as in flycast's scope, it's really flyinghead's call. Given the long laundy list of hardware that IS sh-4 related (such as was my intent in opening this issue), there are far more relevant targets if/when others are ever considered.
That said, even if sh-3 were in scope, the (misinterpreted) comments above were in reference to mame's capabilities, not flycast's, and only diffuse from the focus of this issue. They belong in mame's forums or github repo, not here.
there are far more relevant targets if/when others are ever considered.
cv1k is far more feasible :
I didn't say feasible. I said relevant.
Tbh, with sh3 being close to sh4, and cv1k's arch being closer to naomi (1 CPU + 1 GPU + 1 APU), i wouldn't consider it any less relevant than the others. It has been discussed several times on discord, cv1k might be implemented in flycast.
Tbh, with sh3 being close to sh4
tbh, SH3 is much closer to SH2 - same instruction set, while SH4 got FPU added. in general, I'd say SH-3 is SH-2 with MMU, and a bit improved peripherals.
oh, and you probably forgot - reicast also have an ARM core, so you should add to the list GBA, NDS, etc :D
reicast also have an ARM core, so you should add to the list GBA, NDS, etc :D
It's far fetched :), this morning i was thinking about cps3 & psikyosh though.
System Bord Y2. YATA-2 RISC SOC Based on SH-4 CPU. Can this Emulate for DC Emulator? Thanks. Also SH-3 could better work for FBN(FBN Team is working for Add SH-3 Core)
Hi, quick question, if Demul is at not just the Naiomi2 stage but the Hikaru stage but running slow, what's the merit in teaming up to crack it?
Failing that, how on Earth did they do it?!
there are far more relevant targets if/when others are ever considered.
cv1k is far more feasible :
- naomi2 is pretty much impossible without reverse engineering the elan chip, and we currently have no idea on how we could do that
- hikaru & gaelco 3d use dual sh4, not impossible but it will require more work than cv1k
- system sp, capcom medal hardware & the gambling machines use hard-to-emulate controls
Guessing you might be the best person to shed light?
guys, i think System Sp is now can be emulated but some Medal and redemption games the only possible part to be emulated is the in game screen of the game while some parts are the outside of the screen also theres is no dump version of any medal and redemption games with SystemSP
Thanks for the reminder @Thetouchedjoe. AFAIK SystemSP support is undocumented. I haven't much time to test it yet but would be good to know if anyone's had experience getting it working.
Also it's hard to capture the original experience of medal/redemption games, but emulating where possible can at least preserve them. I'm sure dumps will be made eventually, as they commonly do for this kind of thing.
This would support the following arcade systems that use the same SH-4 CPU as the Dreamcast. Many of these games feature interesting and unique game mechanics, graphic styles etc. and would be great to see running in Reicast.
Incidentally, I understand Stefano Teso's open-source "Valkyrie" emulator was written to support the Hikaru platform, though I'm not sure how far it got and its original GitHub site is now gone. The closed-source Demul emulator supports Hikaru and Gaelco 3D games too.
NAOMI 2 support would require reverse engineering the system's ELAN chip, which would involve disclosure of the register list and understanding other aspects of the platform. @p1pkin provided some support towards this effort at the bottom of this thread.