It is currently Tue Jun 18, 2019 4:00 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 8 posts ] 
Author Message
PostPosted: Sat Nov 10, 2018 9:55 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21441
Location: NE Indiana, USA (NTSC)
When the program turns on rendering by changing bit 7 of LCDC ($FF40) from 0 to 1, the PPU goes straight to the start of rendering (scanline 0). And for some reason, the LCD does not receive the first frame that the PPU generates, instead displaying a white screen for one frame. (On monochrome systems, this is the same whiter-than-white shade displayed when rendering is off.) Some games, such as Pokémon Pinball, use this blank frame to prepare things before the first visible frame, such as the sprite display list to be DMA copied to OAM during the first vblank.

Though recent BGB emulates this quirk, mGBA 0.8-5388-f92059be does not. This causes 1 frame of corruption to appear in Pokémon Pinball and numerous other games after a screen transition. Many games on KiGB's compatibility list are there because of this quirk.

So I've made a test ROM for this quirk. Expect a whiter-than-white screen on an authentic Game Boy or Game Boy Pocket, or a white screen on an authentic Game Boy Color, Game Boy Advance, or Game Boy Player. (I haven't tested it on my cousin's Super Game Boy yet.) On an emulator that does not emulate this quirk, it will instead speak truth.


Attachments:
firstwhite-0.01.zip [23.19 KiB]
Downloaded 227 times

_________________
Pin Eight | Twitter | GitHub | Patreon
Top
 Profile  
 
PostPosted: Sat Dec 29, 2018 3:39 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21441
Location: NE Indiana, USA (NTSC)
Version 0.02 features a less cheeky failure message.


Attachments:
firstwhite-0.02.zip [24.19 KiB]
Downloaded 129 times

_________________
Pin Eight | Twitter | GitHub | Patreon
Top
 Profile  
 
PostPosted: Sun Dec 30, 2018 3:33 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 915
Thinking about it... the combination of first+white in the filename sounds much more concerning... initiallyblankscreen or missingblackgraypixels would avoid possible associations with racism... though nintendo apparently didn't care about that either when inventing their hardware design with enforced whiteness - their backlight driven handhelds would look much nicer if they would default to black screens, or allow to use custom a backdrop color during forced blank.


Top
 Profile  
 
PostPosted: Fri Jan 04, 2019 6:37 pm 
Offline
User avatar

Joined: Fri Jan 04, 2019 5:31 pm
Posts: 35
Location: France, right of a pile of consoles
Quick note about this on SGB: the SGB appears to lose VSync when rapidly turning the LCD on and off, which causes the picture to scroll.

Testing during development of my homebrew game also led to the conclusion that disabling the LCD on SGB simply causes the picture to stop updating, as evidenced by a lack of blinking during screen transitions. There's probably investigation to be made regarding the ICD2 chip.

_________________
The French Lord of Laziness (and a huge Legend of Zelda fan)
https://github.com/ISSOtm
ASMu is laifu <3


Top
 Profile  
 
PostPosted: Sun Jan 13, 2019 9:51 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1475
Oooh, a very interesting test case. I wonder how higan emulates this in SGB mode.

It was very difficult to reverse engineer the ICD2 from scratch, and it's always felt incredibly hacky how to detect where to transfer uploaded Game Boy screen chunks to, based on the writes the SGB sends to the ICD2. Somehow it ended up stable enough to work with border uploads, game uploads, and even the weird >100% speed mode that causes skipped frames on a real SGB.

But I have a feeling this is going to push it even more, and not run correctly.


Top
 Profile  
 
PostPosted: Sun Jan 13, 2019 10:59 am 
Offline
User avatar

Joined: Fri Jan 04, 2019 5:31 pm
Posts: 35
Location: France, right of a pile of consoles
Higan doesn't emulate this correctly, according to this game I'm developing. Soft-resetting it causes it to enter a boot-loop until the key combo is released, and this triggers the same behavior tepple's ROM tests (turn the LCD off after that first frame).

Higan first shows a glitched frame (like, wrong tiles loaded? I can't tell exactly what's going on due to lacking a debugger) then a solid blank frame; this is roughly the same as BGB, which emulates the "white first frame" even on SGB.
On my SGB1, a garbled picture scrolls indefinitely (though the bottom tile line seems to behave differently?). This garbled picture appears to differ based on what's loaded in VRAM prior to resetting, though that might be a consequence of how my ROM works, I'm not sure.

_________________
The French Lord of Laziness (and a huge Legend of Zelda fan)
https://github.com/ISSOtm
ASMu is laifu <3


Top
 Profile  
 
PostPosted: Wed Feb 13, 2019 7:06 pm 
Offline
User avatar

Joined: Fri Jan 04, 2019 5:31 pm
Posts: 35
Location: France, right of a pile of consoles
gekkio recently figured out the exact behavior behind the "blank frame": when turning the PPU/LCD on, no VSync signal is generated. The LCD screens respond by doing absolutely nothing, but the ICD2 works differently.

Liji created two test ROMs, which turn the PPU off at specific LY values1. Notably, no VSync signal is sent ever.
Turning the PPU off so it generates 64 scanlines before aborting the frame creates a stable2 picture.
Generating one less line before aborting causes the picture to instead scroll upwards by 1 pixel each frame.
Liji also noticed that turning the LCD off on the first VBlank after turning it off causes the picture to shift upwards by 112 pixels. If you're savvy, you will have noticed that 112 + 144 = 256. Hmm...

To explain the current theory we believe in, I will start by quoting a bit of fullsnes:
Quote:
SGB Port 6000h - LCD Character Row and Buffer Write-Row (R)

7-3 Current Character Row on Gameboy LCD (0..11h) (11h=Last Row, or Vblank)
2 Seems to be always zero
1-0 Current Character Row WRITE Buffer Number (0..3)
The ICD2 appears to track the Game Boy's LY value (divided by 8). How can it, since it only has access to LCD lines? The theory is simply that the ICD2 has a counter that gets incremented each time 8 scanlines are recieved (= each time a new character row is pushed to one of the four buffers), and reset when it recieves a VSync signal.
When turning the LCD off then on again, the VSync signal is never recieved, so the counter simply increases without resetting. It's then assumed that the SGB firmware simply ignores those rows, which explains why 122 lines are dropped when full frames are generated without VSync.
That last part has been confirmed, as the following is present in the firmware:
Code:
ReadCHRRows:
.80:B9BE                 LDA     ICD2CURROW
.80:B9C2                 STA     CurLYAndBufNum ; orig=0x0290
.80:B9C5                 LDA     ICD2CURROW
.80:B9C9                 CMP     CurLYAndBufNum ; orig=0x0290
.80:B9CC                 BNE     ReadCHRRows
.80:B9CE                 CMP     #$11 << 3
.80:B9D0                 BCS     locret_80BA0C

The rest of this theory should be somewhat easily verifiable by checking if the "GB row number" in $6000 indeed goes past 0x11. I have in mind to upload code to the SNES that would enabled forced blanking as soon as a row number greater than 0x11 is read, but I haven't got time to write it yet.


Does higan emulate this correctly? Apparently, no.


1 This means the PPU is turned off mid-frame repeatedly, which Nintendo's programming manual refers to as "strictly forbidden". It's therefore strongly discouraged to run those on a DMG/MGB; CGB and later should be fine according to the same document.
2 The picture flickers and is somewhat inconsistent on SGB1, but I'm tempted to blame the different clock rates on both sides of the ICD2.


Attachments:
File comment: WARNING: do NOT run on a DMG/MGB, possible LCD damage.
The picture should scroll upwards at a rate of 1 pixel per frame.

sgb_sync(1).gb [32 KiB]
Downloaded 103 times
File comment: WARNING: do NOT run on a DMG/MGB, possible LCD damage.
The picture should be static on SGB2, and somewhat flicker on SGB1.

sgb_sync.gb [32 KiB]
Downloaded 102 times

_________________
The French Lord of Laziness (and a huge Legend of Zelda fan)
https://github.com/ISSOtm
ASMu is laifu <3
Top
 Profile  
 
PostPosted: Fri Feb 22, 2019 3:34 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1475
Exceelent work in figuring this out. I would love to commit a patch for this if anyone had some free time.

Unfortunately I am absolutely swamped at the moment, so if you need me to get to this, it'll probably be a while ...


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group