so far I haven't seen this timing option have any effect whatsoever (even in timing-sensitive games) besides slowing down the emulator a lot. I think the result it calculates gets max'ed away the vast majority of the time. And the thing it enables probably isn't very accurate anyway. So let's see if we can get away with leaving it disabled for the time being...

This commit is contained in:
nitsuja 2009-10-11 04:23:13 +00:00
parent 66d36f5989
commit 1a7bb26c39
1 changed files with 2 additions and 1 deletions

View File

@ -47,7 +47,7 @@
//(SOMETIMES THIS IS A BIG SPEED HIT!) //(SOMETIMES THIS IS A BIG SPEED HIT!)
// enables emulation of code fetch waits. // enables emulation of code fetch waits.
#define ACCOUNT_FOR_CODE_FETCH_CYCLES //#define ACCOUNT_FOR_CODE_FETCH_CYCLES
// makes access to DTCM (arm9 only) fast. // makes access to DTCM (arm9 only) fast.
#define ACCOUNT_FOR_DATA_TCM_SPEED #define ACCOUNT_FOR_DATA_TCM_SPEED
@ -255,6 +255,7 @@ extern MMU_struct_timing MMU_timing;
// calculates the time a single memory access takes, // calculates the time a single memory access takes,
// in units of cycles of the current processor. // in units of cycles of the current processor.
// this function replaces what used to be MMU_WAIT16 and MMU_WAIT32. // this function replaces what used to be MMU_WAIT16 and MMU_WAIT32.
// this may have side effects, so don't call it more than necessary.
template<int PROCNUM, MMU_ACCESS_TYPE AT, int READSIZE, MMU_ACCESS_DIRECTION DIRECTION> template<int PROCNUM, MMU_ACCESS_TYPE AT, int READSIZE, MMU_ACCESS_DIRECTION DIRECTION>
FORCEINLINE u32 _MMU_accesstime(u32 addr, bool sequential) FORCEINLINE u32 _MMU_accesstime(u32 addr, bool sequential)
{ {