Opciones de búsqueda (Página 508 de 915)

The Steam version of Belle has received a number of cool new upgrades as well.

To make matters worse, the once mighty Steam has become a cesspool of shovelware and asset flips, where good games go to die. This has been weighing heavily on my morale to the point were I had to do something: in order to secure further financing for LOI development, and probe new avenues of distribution, I have partnered with WayForward to port Mystik Bell to consoles.

fwiw the c-chip has 2 parts as there are multiple parts inside the package, a UPD78C11 with internal rom, an ASIC, and an EPROM. The 78C11 rom was dumped visually by decapping, and the internal code heavily analysed (that's how we had some clues to attempt other failed exploits) this is likely the same between games. The EPROM, containing game specific code has never been fully dumped, we have half a dump from Operation Wolf done by trying to wire up the die directly, but complications meant we were never able to obtain a full dump.

For overview of how each game uses the protection, read below

> B20 | Operation Wolf | 1987

uses it for a lot of game critical things, recently the simulation was improved (after 15+ years of being entirely incorrect) based on a prototype version that showed up. There could still be secrets the c-chip holds tho, so a real dump would help.

> B22 | Rainbow Islands / EX | 1987

Simulation was written by somebody who had extensively studied the games (both uses different c-chips with different internal data) should in theory be mostly correct, but there are some doubts over how some of the random number generation works, which, if you're serious about the game will actually matter, so a real dump will help.

> B41 | Bonze Adventure / Jigoku Meguri | 1988

Simulation has never been 100%, restart points are incorrect, sometimes the game will crash. Some of the alt MAME builds have different hacks to work around this, but in all honesty none are correct, emulation definitely won't be correct without a real dump.

> B61 | Superman | 1988

C-Chip just seems to supply a chunk of 68k code, very lazy, while the actual 68k code has never been verified against a PCB it's function is very simple, so while a real dump would be good for the sake of completeness, the emulation probably isn't 'incorrect' right now with the simulation code.

> C04 | Volfied | 1989

C-chip seems to manage some game counters / timers that aren't accurately emulated, some commands are basically just ignored right now. Exactly how this impacts the gameplay is unknown, but it's almost guaranteed that current simulation isn't accurate and game isn't playing exactly right.

> C11 | Mega Blast | 1989

C-chip could easily have a blank internal EPROM, game code only ever checks that the c-chip exists via the initial startup check that is handled entirely by the MCU part of the chip, it doesn't even matter if the chip crashes after that, the game never checks anything beyond startup, very, very lazy on the part of Taito. It will be interesting to see if anything exists in the EPROM, maybe code they never used. Alternatively they might have just recycled old c-chips on this game, not bothering to reprogram them because the game never triggers any commands.

overall, if we can work how to read the roms from some of these games, which are becoming increasingly uncommon, it will greatly benefit their emulation. even in cases where the emulation is probably ok with the current simulation code we might be able to find some interesting secrets in the undumped part of the rom that could tell us more about the development of the games and their protection.

I'm confident I can get detailed timing measurements [of 1st generation Cave hardware] 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.