My favorites | Sign in
Project Home Downloads Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
  Advanced search   Search tips   Subscriptions
Issue 11: Need more control over NVRAM use
1 person starred this issue and may be notified of changes. Back to list
Status:  Accepted
Owner:  ----


 
Project Member Reported by dammi...@hotmail.com, Nov 5, 2009
Whenever you begin playback (or begin recording) fba-rr 0.0.3.03 reloads
the ROM and reads the NVRAM (.nv files) under ./config/games. Whatever is
in there will be used in the movie. If there a dirty nv, and if the movie
adjusts settings before play, there will certainly be desync.

Optimally there should be a choice whether to use dirty nvram when
beginning recording.

* Start from savestate
* Start from power-on with nvram
* Start from power-on without nvram (< should be default)

If it is to be used, it should probably be added into the fbm file rather
than reading the contents of the config folder.

Fortunately there's a workaround: delete the game's .nv file prior to
playback every time.

More discussion:
http://tasvideos.org/forum/viewtopic.php?p=203234

Dipswitches are apparently (?) not a problem because their state is stored
as inputs, like button presses.
Nov 6, 2009
Project Member #1 dammi...@hotmail.com
I discovered the cause of everyone's desyncs in SDR's XvSF movie. You need to start
from his dirty nvram for it to sync.

The dirty nvram starts with difficulty set to Expert (level 8), then the fbm sets it
to Hard2 (level 4). Then the movie syncs. (This also means the movie wasn't played at
hardest.)

If there is no .nv file initially, the movie never even reaches the config menu and
desyncs early.

If there is a default/clean .nv file present (created automatically after loading the
ROM again), then the fbm sets difficulty from Normal (level 2) to Hard4 (level 6).
The movie will desync around the middle.

The fact that there is a sync difference between null nvram and clean nvram is
serious and implies that the workaround mentioned above is not reliable.

The movie's thread:
http://tasvideos.org/forum/viewtopic.php?t=8206
Nov 10, 2009
Project Member #2 mauzus@gmail.com
Desyncs issues should be fixed in r33.

I'll leave this open as a request for adding "Start from power-on with nvram".
Status: Accepted
Labels: -Type-Defect -Priority-Medium Type-Enhancement Priority-Low
Nov 21, 2009
Project Member #3 dammi...@hotmail.com
OK, just to reiterate all the findings so far:

The new version (004a) enforces null nvram/flash for both from-power-on recording and
playback, as was intended. I verified this with a CPS-2 game (.nv) and a NeoGeo game
(.fs). This will make recording and playback of new movies much more reliable.

However, this causes SDR's XvSF and error1's SFZ2A movies to desync, because the
former expects dirty nvram while the latter presumably expects clean, non-null nvram.

Xipo's GnG game doesn't have nvram at all and is unaffected. Angerfist's MS-X movie
also syncs.

At some point a distinction in the fbm spec will be need to be made between "use the
userdata" and "don't use the userdata". Where userdata means nvram, flash, or
whatever other kind of medium was used for the game in question.

SDR's and error1's fbms will need to be corrected eventually to either include the nv
data internally or to redo the startup parts, because they are unsyncable in their
current forms.

Powered by Google Project Hosting