Topic: dink's FBN Development & Fixes thread

[Huggybaby]

Hello dink,

I'm checking in after quite some time and was thrilled to see the work you've done!!

I've reported a problem with The Simpsons a couple of times. There used to be some bad sound clipping which I think is fixed. But there is still a problem with left and right channels being swapped. A little bit into the game there's a TV and a character skates across, this is where it's easy to notice, but other effects are swapped too.

Thank you for all the awesome work; I have loved reading this thread!

[dink]

Huggybaby, thanks - I really appreciate the feedback   Also, thanks for the bug report, consider it fixed.

best regards,
- dink

[Arcadez]

dink it's come to my attention that as yet you've not been asked for a certain request that has plagued other FBA devs for years
so let me put that right by asking could you please port the Midway drivers across from MAME so we can play the Mortal Kombat
games in FBA


















Only joking 

[iq_132]

dink it's come to my attention that as yet you've not been asked for a certain request that has plagued other FBA devs for years
so let me put that right by asking could you please port the Midway drivers across from MAME so we can play the Mortal Kombat
games in FBA


















Only joking 

You like dead kittens? 'cause that's how you get dead kittens. Lol

[Huggybaby]

LOL 

[Arcadez]

You like dead kittens? 'cause that's how you get dead kittens. Lol

+ T +: Every time you mention Midway games in Final Burn, iq_132 kills a kitten!

Oh i forgot about that and well since it was only joke you leave them kittens alone now :lol:

[dink]

hehe!

Well, all funny things aside, I found yet another problem with the ym2151 and savestates.  Fix is incoming.. 

[dink]

Thunder Cross 2 (thndrx2 / konami/d_tmnt.cpp) has some really killer stereo sound+music, but it has to be enabled via the nvram settings in the game.  By default, the game is set to mono, but sounds only come out of one speaker, and this is horrible, because most people won't think of going into the service mode and setting it to stereo (its not a dip setting).  I would like to somehow set it to stereo mode by default, but I'm not too familiar with the inner workings of the eeprom serial interface.  All I know is that the 8th byte into thndrx2.nv should be changed from 0x2e to 0x0e to enable stereo mode.  Do you guys have any ideas how this idea/feature can be done?

best regards,
- dink

[dink]

re: the theory of some sort of internal timer overflow (or something of that sort)

There are a few games, notably varth, thunder cross 2, truxton 2, and several others which savestates work fine, and even closing and reloading fb, then loading the rom and savestate, works perfect.  Now that that has been established...

Turning off my computer, then turning it on several hours later, loading fb and the game & savestate, and now the game crawls at like 1/4 the speed.  Press f3 to reset it and start a new game, its still going slow as hell.

The investigation begins...  though I'd like to ask, does anyone have any ideas off the top of their heads why this may be happening?

[kev]

I wonder if its the frameskipping code getting confused? Are any of the variables used by it (at the burner side) defined in burn and missing from the save states? Maybe also if they are not missing they need to be reset when a state is loaded?

[iq_132]

Does the same thing happen when changing the windows system time?
Also, create the eprom settings you want for those games and I'll set up the default in the driver. (please post the actual file)

[dink]

I tried setting the time back, no dice   I'm about to do some investigating though, take a new snap, and compare the data, try to figure out where things are going wrong. EDIT: I believe its due to a compiler bug.  I had recompiled konami/d_tmnt.cpp with my script which had -Ofast (fast optimization), and this screwed up savestates for games even outside of that driver.  My savestates work again at the proper speed after changing it back to -O1 / recompiling / linking.  Very strange - though, I'm also very relieved

Here's the eeprom data for thunder cross 2 (thndrx2), thndrx2.newdefault is the one that should be the default data.  thanks

best regards,
- dink

[dink]

Re: savestate investigation revisited, aka I don't think its a compiler bug after all.

When making a savestate with SekScan(), it dumps the entire structure m68ki_cpu_core to the savestate.  At the bottom of the structure are a bunch of pointers:

Code: [Select]

uint8* cyc_instruction;
uint8* cyc_exception;

/* Callbacks to host */
int  (*int_ack_callback)(int int_line);           /* Interrupt Acknowledge */
void (*bkpt_ack_callback)(unsigned int data);     /* Breakpoint Acknowledge */
void (*reset_instr_callback)(void);               /* Called when a RESET instruction is encountered */
void (*cmpild_instr_callback)(unsigned int, int); /* Called when a CMPI.L #v, Dn instruction is encountered */
void (*rte_instr_callback)(void);                 /* Called when a RTE instruction is encountered */
void (*pc_changed_callback)(unsigned int new_pc); /* Called when the PC changes by a large amount */
void (*set_fc_callback)(unsigned int new_fc);     /* Called when the CPU function code changes */
void (*instr_hook_callback)(void);                /* Called every instruction cycle prior to execution */

so, what happens if you load the savestate on a different pc, or at a different time of the day when the operating system decides to load the code into a different segment?  problems.   I'm going to experiment with ignoring these pointers when loading a state, since they should already be set up in drvinit().etc. and see what happens...

EDIT: a little while later...

Success!!
I modified the 68k interface to preserve the pointers, save or load the cpu context data, then put the pointers back.
To make sure I wasn't seeing things, I disabled the new code in the 68k interface and tried loading a savestate between a fast-optimized FBA exe and a regular-optimized exe, and.. it exhibited the same symptoms as talked about a message or 2 back.  (so thats good! it proves that the new code does indeed work.)
This new fix should help with the portablilty of savestates between 64 and 32bit systems also.

So what did we learn today?  Savestate-scanning structures with pointers in them is bad, mm'kay!

[kev]

I suppose a terrible way of fixing this would of been changing the save state loading to load the roms, start the driver for a frame and then load the save state. Your fix is better

Edit : actually, that would still not work obviously. Yours is the only fix. I shouldn't drink on Sunday nights

[dink]

kev, thanks   well, at the time of loading or saving a state, the rom is already loaded and running.  But I kinda see what you mean.. if a game isn't running and you go to load a state, it should then load the game and then the state.  I like that idea

best regards,
- dink