Mednafen Members Members   Search Search   Help Help   Register Register   Login Login   Home Home
Home » Mednafen » Bugs » [VB] Emulated VIP displays wrong FB on reset
Show: Today's Messages  :: Show Polls :: Message Navigator
Switch to threaded view of this topic Create a new topic Submit Reply
[VB] Emulated VIP displays wrong FB on reset [message #6739] Thu, 28 July 2022 00:49 Go to next message
blitter  [PM]
There is a minor bug in the emulation of the Virtual Boy's VIP. In VIP_Power, both DisplayFB and DrawingFB are initialized to zero, but this is at odds with the following behavior in VIP_Update, where these two values are made to be inverses of each other:

      if(XPCTRL & XPCTRL_XP_EN)
      {
       DisplayFB ^= 1;

       DrawingBlock = 0;
       DrawingActive = true;
       DrawingCounter = 1120 * 4;
       DrawingFB = DisplayFB ^ 1;
      }


On hardware, when setting XPEN after reset, the VIP performs the above logic, after which it draws to frame buffer 1 while scanning out frame buffer 0. Although it seems no commercial games depend on this behavior, nevertheless Mednafen's VB core is inaccurate here. Fortunately the fix is simple: just initialize DisplayFB to 1 inside VIP_Power.

I've attached a patch against 1.29.0 along with a test ROM that demonstrates this bug. On hardware and in Mednafen with my patch applied, pressing a button should animate the screen changing patterns. On an unpatched Mednafen 1.29.0, pressing a button produces no animation.

[Updated on: Tue, 09 August 2022 23:12]

Re: [VB] Emulated VIP displays wrong FB on reset [message #6740 is a reply to message #6739 ] Thu, 28 July 2022 15:46 Go to previous messageGo to next message
blitter  [PM]
Fixing this bug reveals yet another minor bug in VIP emulation. On hardware, in addition to clearing SBHIT, XPEND, and TIMEERR, setting XPRST will flip the VIP's internal frame buffer pointers. Mednafen 1.29.0 just leaves them as-is, which is inaccurate.

The patch for this is likewise relatively simple, which I have attached along with another test ROM demonstrating this bug. On hardware and in Mednafen with both this patch and the first patch from above applied, pressing a button first cuts to a different visual pattern, then pressing a button a second time animates back to the original pattern. Without this second patch applied, during every other animation in Mednafen this ROM will animate to the same frame buffer that the VIP is drawing to, causing very noticeable tearing artifacts. (On an unpatched Mednafen, no animation is produced; this test ROM is based on the same test ROM from my original post.)

[Updated on: Tue, 09 August 2022 23:12]

Re: [VB] Emulated VIP displays wrong FB on reset [message #6742 is a reply to message #6739 ] Wed, 03 August 2022 16:19 Go to previous messageGo to next message
Administrator  [PM]
Could you be more specific about what unfixed Mednafen should look like after pressing a button with buffertest_220728051801.vb? Are you saying that no change is visible at all when pressing a button, or the change that does show is wrong?

Also, did you directly check that framebuffer 1, instead of framebuffer 0, is the one displayed after reset/power-on, before any drawing occurs?

[Updated on: Wed, 03 August 2022 19:01]

Re: [VB] Emulated VIP displays wrong FB on reset [message #6743 is a reply to message #6742 ] Wed, 03 August 2022 20:52 Go to previous messageGo to next message
blitter  [PM]
Administrator wrote on Wed, 03 August 2022 16:19

Could you be more specific about what unfixed Mednafen should look like after pressing a button with buffertest_220728051801.vb? Are you saying that no change is visible at all when pressing a button, or the change that does show is wrong?


Going back and retrying myself, it looks like I was wrong-- while a patched Mednafen and hardware displays a smooth rolling animation from one pattern to another, an unpatched Mednafen will animate, but with tearing artifacts, looking a bit like this:

index.php?t=getfile&id=1380&private=0

Mea culpa! I think what happened there was I was testing on a fresh install of 1.29.0, which didn't have my controls configured.

Quote:

Also, did you directly check that framebuffer 1, instead of framebuffer 0, is the one displayed after reset/power-on, before any drawing occurs?


I did not. I just now wrote a pair of ROMs (attached) testing that case, and before any drawing occurs, indeed framebuffer 0 is what is drawn. fb1test_220804013829.vb clears framebuffer 1 to a solid color, whereas fb1test_220804014304.vb clears framebuffer 0 to a solid color. On hardware, fb1test_220804013829.vb displays garbage and Mednafen displays black, whereas fb1test_220804014304.vb displays a consistent bright pattern on both hardware and Mednafen. Seems that enabling drawing is mucking with the internal framebuffer pointers.

Re: [VB] Emulated VIP displays wrong FB on reset [message #6744 is a reply to message #6743 ] Tue, 09 August 2022 23:17 Go to previous messageGo to next message
blitter  [PM]
I removed the previous two patches and instead combined them into a new patch which I've attached here, accounting for the fact that frame buffer 0 is displayed first before any drawing occurs.

On hardware, the ROMs posted earlier behave consistently with a patched version of Mednafen 1.29.0 with one exception: fb1test_220804013829.vb displays garbage on hardware but displays a black screen on Mednafen. This is because Mednafen doesn't emulate there being garbage in VRAM on startup. My patch doesn't set out to fix that.

Re: [VB] Emulated VIP displays wrong FB on reset [message #6745 is a reply to message #6744 ] Wed, 10 August 2022 23:48 Go to previous messageGo to next message
Administrator  [PM]
Do you have anything that tests XPRST without ever enabling drawing, to test the attached fix vs yours?

Re: [VB] Emulated VIP displays wrong FB on reset [message #6746 is a reply to message #6745 ] Thu, 11 August 2022 01:40 Go to previous message
blitter  [PM]
Administrator wrote on Wed, 10 August 2022 23:48

Do you have anything that tests XPRST without ever enabling drawing, to test the attached fix vs yours?




I do, yes-- it's attached as "fb1test_220810024452 (XPRST once).vb"

Unfortunately your test patch does not reflect XPRST's behavior on hardware. In what came as a surprise to me, XPRST appears to behave differently than XPEN on startup. It looks as though XPRST always flips the framebuffers; XPEN apparently only does after the very first frame. I've attached a revised version of your patch to reflect this (vip-fb-flip.patch).

I was curious whether I could hit XPRST a consecutive time to flip the framebuffers back to their initial state of displaying framebuffer 0. It turns out that yes, this is possible, but only after waiting a minimum of 5 CPU cycles on hardware after the first XPRST. Mednafen seems to assume that XPRST / DPRST are instantaneous (I've done further research on DPRST's behavior here: https://www.virtual-boy.com/forums/t/dprst-demystified/) but a fix that counts cycles doesn't look as trivial to me so I haven't addressed that in my patch.

I've attached three additional test ROMs (based on "fb1test_220810024452 (XPRST once).vb") that demonstrate what happens when XPRST is hit twice in a row, with and without an appropriate number of nops in between:
  • "fb1test_220811052209 (XPRST twice).vb" hits XPRST twice in a row without any delay in between. This leaves hardware on the same garbage screen that "fb1test_220810024452 (XPRST once).vb" sets up with its single hit to XPRST.
  • "fb1test_220811060844 (4 nops).vb" hits XPRST twice in a row, waiting four cycles/nops in between. This leaves hardware on the same garbage screen that "fb1test_220810024452 (XPRST once).vb" sets up with its single hit to XPRST.
  • "fb1test_220811060653 (5 nops).vb" hits XPRST twice in a row, waiting five cycles/nops in between. This switches hardware back to framebuffer 0, which is initialized to a colored pattern on startup.

  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic:[md] Light Crusader (rus) Don't work srm saves (The problem is in the srm-saving mechanism)
Next Topic:ST-V Shienryu
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ ]

Current Time: Sat May 11 04:33:08 CDT 2024
.:: Contact :: Home ::.

Powered by FUDforum.
Copyright © FUDforum Bulletin Board Software