forums.marpirc.net

http://marp.retrogames.com/inp/a/4/6/mr ... _win89.zip

Appears to require NVRAM. Anyone else confirm this? (Can't be arsed changing settings back to using NVRAM)

http://marp.retrogames.com/inp/8/5/d/mr ... mame89.zip

Loses syncs at about 465m... probably due to the RTC at a guess.

off topic (haven't checked the playbackability yet) but should this game be split?

last upload playsback perfectly although horribly slow :(

What's the RTC, and how does it affect playback/recording? I'm guessing "real time clock" - but what's the story?

Also, the Mr. Driller game was recorded with MAME32 0.89u2, not MAME32 0.89. Could that be the problem?

Should people use the official releases, not "u" versions?

Chris.

i think rtc involves a command line option (need to do a search to figure out what it is or wait for sawys to respond), and i think it does affect playbackability, but i did not use it, nor did i used the NON official 89 release to play it back, in windows xp with sound.

EDIT, i DID use the official release to play it back btw.

Zwaxy wrote:
Should people use the official releases, not "u" versions?

IMO we have enough mame versions to deal with without "u" 's.
+possible playback problems
+where to get u releases
So I'd say, good heavens, no u's...

Zwaxy's right, it's a real time clock. Many Neo Geo games used its RTC for random number seeding, so around v0.60 someone fixed it so that on record/playback, the date and time was zeroed. I figure that the same thing could be happening here, especially since Mr Driller played back fine before the RTC was emulated.

If MAME is reading the PC's clock and using that to seed the random number generator in Mr. Driller, then how on earth did Chad get the game to play back correctly?

As an aside, why can't I get Mr. Driller to play at anything above 60% or so, even with full frame-skip? Mr.Driller (the player) tells me his latitude c840 laptop plays it at 100%. I've tried with the command-line and MAME32 versions. Didn't try WolfMAME, but apparently that's even worse. Is it just that my 2.2GHz P4 is too slow for Mr. Driller?

I just tried playing the recording back twice. I noticed that the very first thing that shows is the *current* time of day, plus one hour. The date's wrong, but the time changes each time you playback. So you're right - this probably is an RTC issue.

PSX-based hardware is very slow under MAME - You'll need 2.8GHz or so for good speed in most. And due to a lot of floating-point code, it's a far bit faster on Pentiums than on Athlons. Many high resolution PSX-based games (512x480) have an interlace setting, which will run the game at a lower resolution if disabled, making it run faster. With Mr Driller (and other Namco System 12 games) you'll find the option in the game's video output test.

Well, I found the code that needs changing.

For the neogeo real-time clock, src/machine/neogeo.c, around line 80 has
if( record != 0 || playback != 0 )
which only uses the current date/time if we're not recording or playing back.

For Mr. Driller we need to do something since around line 328 of src/drivers/namcos12.c.

What's the best place to report this to, so that it's most likely to get into the next version of MAME?

In general, it would be a good idea to scan all the MAME sources for calls to the time() function, to check whether any other drivers are accessing the PC's clock. I'll take a look later if I'm not too busy in work today.

Chris.

Not many, from memory. I heard somewhere that WWF Wrestlemania did, but I've never investigated that as yet. Also, I think the Kaneko Suepr Nova has an RTC too, but was written correctly to work with record/playback frm the start.

The easiest fix may be to add a new line to src/drivers/namcos12.c just before this line:
time(&curtime);
at line 325 saying this:
if( record != 0 || playback != 0 ) return 1;

'1' is a valid value for every field (hours, minutes, days, etc).

Maybe the game won't notice or care that the time is constantly set to 01:01:01 on the 1st Jan 01... At least recordings would playback correctly.

Chris.

Sounds good to me.