It is currently Sat Dec 16, 2017 8:03 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: Wed Apr 06, 2016 12:21 pm 
Offline

Joined: Mon Jan 18, 2016 5:36 pm
Posts: 23
I'm trying to figure out how registers FF4C and FF6C work in order to emulate them better in SameBoy. These registers are related to DMG emulation on a CGB.

Here's what I already know about these two:
  • The CGB boot ROM considers a game a CGB "enabled" game if bit 7 is on in byte 143.
  • If the game is a CGB enabled game, 1 is written to register FF6C; otherwise it remains as 0.
  • FF6C is readable and writeable in all states; its mask is FE, so only bit 0 is accessible.
  • If the game is a CGB enabled game, the value of 143 is written to register FF4C; otherwise, 04 is written. This means it is possible to make the boot ROM write any value in the range 80-FF, as well as 04, to this register.
  • It appears that by the time the boot ROM has finished running, register FF4C is locked. It can't be written anymore, and can't be read anymore (returns FF).
  • I have failed to find the effect of register FF6C, despite it being writable freely after boot.
  • This means that register FF4C is extremely likely to be the register that controls enabling the following compatibility features:
    • Alternate OAM sprite ordering
    • Taking BGP/OBP0/OBP1 into account when applying colors to tiles.
    • Accessibility of registers SVBK, VBK and KEY1. (They're not writable or readable in DMG mode)

As an experiment, I modified one of my test ROMs to use %11100100 as its DMG BG palette. This means that it in DMG mode, it will display in inverted colors. I also gave it the capability to (try to) modify registers FF4C and FF6C in runtime. The results were disappointing: writing 04 or 80 to register FF4C did not toggle DMG mode. Writing 0/1 to FF6C did affect the value read from that register, but nothing else. This pretty much confirms FF4C is not readable or writable after booting.

And there comes that real surprise. I assumed that bit 2 had an effect on DMG emulation, and since that value is controlled by my ROM when it boots, I tried making the CGB boot write C4 to FF4C instead of the usual C0; expecting it to run the game in DMG mode. But after I booted the modified ROM – the Gameboy displayed absolutely nothing! The ROM was still running indeed, as my button presses did generate sounds as expected, but the screen was completely blank.

I have yet to run any tests on other values for this register.

Does anyone have any other information on these two registers? Does FF6C really do nothing? Any idea about what the specific bits of FF4C do, and why does writing C4 to that register make the screen blank?

Waiting for your insights. :)


Last edited by LIJI on Thu Apr 07, 2016 5:48 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Wed Apr 06, 2016 6:20 pm 
Offline

Joined: Sun Jan 26, 2014 9:31 am
Posts: 267
Maybe look through the CGB Boot ROM's disassembly (Emu Docs on GitHub has a copy). As far as I know, it's been fully disassembled. Maybe it checks to see if byte 0x143 is valid (Nintendo says to only use 0x0, 0x80, and 0xC0 if I recall correctly) and if it's not, it boots up in an unexpected way? It's worth examining further, I'd say. Since you say you got everything but visual output, perhaps the LCD isn't initialized properly on invalid values for 0x143. If you're still able to trigger VBLANK and STAT IRQs, then that means it's definitely clocking the LCD, just drawing nothing, which sounds like something happening deep in the LCD controller.

Perhaps I say this too much, but gekkio would probably have some helpful insight into this, especially since he is probing the LCD in-depth, the last I heard. I can only guess what's really going on underneath the surface though.


Top
 Profile  
 
PostPosted: Thu Apr 07, 2016 2:15 am 
Offline

Joined: Mon Jan 18, 2016 5:36 pm
Posts: 23
Emu Docs doesn't have much info about it unfortunately. I actually disassembled the CGB boot ROM completely myself (I even reimplemented it), and it doesn't get any more complex than I explained – the boot ROM does not validate 143 at all. It simply writes it if bit 7 is on, or write 04 otherwise.

Checking if interrupts occur seems like a great idea though, I will try to see if any of them trigger. :)


Top
 Profile  
 
PostPosted: Thu Apr 07, 2016 3:57 am 
Offline

Joined: Fri Oct 16, 2015 6:18 am
Posts: 43
A very interesting find!
Unfortunately I don't have any more information about these registers, since CGB-specific stuff is outside my current research scope.
One minor thing:

Quote:
FF6C is readable and writeable in all states; its mask is FE, so only bit 0 is accessible.


As proven by my unused_hwio-C test ROM (run in DMG mode), FF6C is not accessible in DMG mode. I find this interesting, because it means FF4C also affects the accessibility of FF6C, and all this hints towards FF6C being specific to CGB mode.

What we really need is a way to bypass the boot ROM consistently on real hardware before any writes happen to interesting registers. This would allow us to peek and poke registers at will without the boot ROM interfering with things. I have plans to do this with DMG, but CGB is more complicated since it involves more than glitching the clock.


Top
 Profile  
 
PostPosted: Thu Apr 07, 2016 4:52 am 
Offline

Joined: Mon Jan 18, 2016 5:36 pm
Posts: 23
Grr, I probably missed FF6C not being writable in DMG mode! :oops:

How would you bypass the DMG boot ROM on a Gameboy? I tried to find code-execuation "vulnerabilities" while reversing the CGB boot ROM, but I found none.

I'll also try modifying CGB-only ROMs to set register FF6C to 1 at boot to see if I can tie it to any DMG-emulation capability. Currently my only suspect is the OAM sprite ordering mode, since I proved register accessibility and BGP support to not be related to that register.


Top
 Profile  
 
PostPosted: Thu Apr 07, 2016 5:43 am 
Offline

Joined: Fri Oct 16, 2015 6:18 am
Posts: 43
Quote:
How would you bypass the DMG boot ROM on a Gameboy? I tried to find code-execuation "vulnerabilities" while reversing the CGB boot ROM, but I found none.


By using the same techniques used when dumping the boot ROM (see Costis Sideris' SGB dumping page or my SGB2 dumping page). By glitching the clock (and power if necessary), it is possible to skip instructions and even randomize PC in order to skip most of the boot ROM completely. It's random and very invasive, but can be used to get the GB into a state where the boot ROM and other interesting things are still accessible.


Top
 Profile  
 
PostPosted: Thu Apr 07, 2016 3:45 pm 
Offline

Joined: Mon Jan 18, 2016 5:36 pm
Posts: 23
Well FF6C is not related to sprite priority order. I also ran Pokémon Puzzle Challenge (a CGB-only game) modified to run with FF6C turned on, and it functioned perfectly. I'm pretty much out of ideas about FF6C. =/


Top
 Profile  
 
PostPosted: Thu Jul 14, 2016 11:22 am 
Offline

Joined: Sat Jun 27, 2015 1:09 pm
Posts: 70
Any news on this ? Seems like an interesting find, maybe some graphic behaviour that got cancelled before release ?


Top
 Profile  
 
PostPosted: Thu Jul 14, 2016 11:34 am 
Offline

Joined: Mon Jan 18, 2016 5:36 pm
Posts: 23
Nothing yet. I'll investigate further once I finish some hardware-related project I'm planning that would help debug it.

Cancelled behavior? Probably not. Interesting undocumented behavior about DMG compatibility? Probably yes.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


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