Show: Today's Messages :: Show Polls :: Message Navigator |
[VB] Emulated VIP displays wrong FB on reset [message #6739] | Thu, 28 July 2022 00:49 | |||
| ||||
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.
(Size: 1.00KB, Downloaded 32 time(s)) [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 | |||
| ||||
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.)
(Size: 2.00KB, Downloaded 39 time(s)) [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 | |||
| ||||
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 | ||||
| |||||
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: 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.
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.
(Size: 3.87KB, Downloaded 168 time(s)) Attachment: fb1test_220804013829.vb (Size: 1.00KB, Downloaded 34 time(s)) Attachment: fb1test_220804014304.vb (Size: 1.00KB, Downloaded 36 time(s)) | |||||
|
Re: [VB] Emulated VIP displays wrong FB on reset [message #6744 is a reply to message #6743 ] | Tue, 09 August 2022 23:17 | |||
| ||||
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.
(Size: 0.67KB, Downloaded 36 time(s)) | ||||
|
Re: [VB] Emulated VIP displays wrong FB on reset [message #6745 is a reply to message #6744 ] | Wed, 10 August 2022 23:48 | |||
| ||||
Do you have anything that tests XPRST without ever enabling drawing, to test the attached fix vs yours?
(Size: 0.82KB, Downloaded 42 time(s)) | ||||
|
Re: [VB] Emulated VIP displays wrong FB on reset [message #6746 is a reply to message #6745 ] | Thu, 11 August 2022 01:40 | |||
| ||||
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:
(Size: 1.00KB, Downloaded 34 time(s)) Attachment: vip-fb-flip.patch (Size: 0.76KB, Downloaded 34 time(s)) Attachment: fb1test_220811052209 (XPRST twice).vb (Size: 1.00KB, Downloaded 33 time(s)) Attachment: fb1test_220811060844 (4 nops).vb (Size: 1.00KB, Downloaded 35 time(s)) Attachment: fb1test_220811060653 (5 nops).vb (Size: 1.00KB, Downloaded 36 time(s)) | ||||
|
Previous Topic: | [md] Light Crusader (rus) Don't work srm saves (The problem is in the srm-saving mechanism) |
Next Topic: | ST-V Shienryu |