zilmar, what I've been thinking is, could you possibly make a full list of all RDB settings and their possible configurations? That would help me understand better what everything does (specially those weird options that don't appear on the GUI and are not documented anywhere).

Also, would people still like to see an updated 1.6 RDB (which is already done)? Or should I start working on a 2.0 one right away?

would people still like to see an updated 1.6 RDB (which is already done)? Or should I start working on a 2.0 one right away?

You can just release it if it is done, no need to bin it.

I am happy to integrate other peoples fixes in to the main rdb file (2.0) so that we have lots of rdb files floating around, tho on the other hand not sure I will release the new rdb with all the changes till 2.1 gets released.

Originally Posted by Fanatic 64

zilmar, what I've been thinking is, could you possibly make a full list of all RDB settings and their possible configurations? That would help me understand better what everything does (specially those weird options that don't appear on the GUI and are not documented anywhere).

I am happy to integrate other peoples fixes in to the main rdb file (2.0) so that we have lots of rdb files floating around, tho on the other hand not sure I will release the new rdb with all the changes till 2.1 gets released.

The config is general just an override of what is in the rdb, so once you get the game settings correct using the config window, most of the time you can just cut and paste the settings from the config to rdb.

The only thing is that say 32bit (any Boolean setting) in config is set to 0 and 1, in the rdb it is Yes or No

save the rdb, run the emu, reset your settings, you should see the values that you expect there because it will be reading them off the rdb if you do not see what you expect then it needs tweaking in the rdb

I know how to copy settings from the CGF to the RDB, I'm not a n00b. What I want to know is what those settings actually do, just as how the SMCM changes the way Self-Modifying Code is handled, thus either gaining speed or removing crashes.

Was not meaning to apply you were! There can be some quirks at times .. tho most of the time just a cut and paste will work

Originally Posted by Fanatic 64

What I want to know is what those settings actually do, just as how the SMCM changes the way Self-Modifying Code is handled, thus either gaining speed or removing crashes.

the old self mods (in 1.6) where combinations of these

Cache - Clear the address of code on a cache write
PI DMA - Clear the code if it is replace via a dma from the rom
Start Changed - When executing a block check if the first 4 instructions are the same, clear if different.
TLB Unmapped - if the virtual address is unmapped from rdram then flush those blocks
Protect Memory - Change the 4k block where any code is written to read only, writing to that block will generate an execption, the emu picks that exception up, flushes the code if any write to the block

there was another option in 1.6 that is mostly still in the code, where it will change the actually memory to have pointers to the block, so if the first instruction is changed it will pick it up.