FF4C and FF6C

Discussion of programming and development for the original Game Boy and Game Boy Color.
Post Reply
windwakr2
Posts: 6
Joined: Sun Mar 29, 2020 9:38 am

FF4C and FF6C

Post by windwakr2 »

Hey all. I saw an image on 4chan in a discussion of some Pokemon leaks that described some GB registers. I will not embed the image here, but this is what it had to say on these two registers(the others shown on the image are already known).

edit: removed

Cheers.
Last edited by windwakr2 on Fri Jul 24, 2020 11:10 am, edited 1 time in total.
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: FF4C and FF6C

Post by nocash »

Did somebody already try to translate the japanese text?

Some of my own findings...

Code: Select all

Undocumented Registers
----------------------

Many of the undocumented registers work only in conjunction with ROMDIS,
--> Pinouts - CPU - ROMDIS Pin

FF50 - POST - Boot BIOS Disable (Write-able only once after Reset) (R/W)
  Bit 0   - Boot BIOS Region (0=Boot BIOS, 1=Cartridge ROM)
  Bit 1-7 - Not used
Internally used by all BIOSes, selects whether Boot BIOS (ie. the Nintendo
Intro), or normal cartridge ROM is mapped to 0000h-00FFh (on CGB additionally
to 0200h-08FFh). The register can be written to only once.

FF60 - JOYC - Joypad Mode (W) (enabled while ROMDIS=HIGH only)
Exists on all gameboy types. Register is write-only (even when it is enabled,
reading always returns FFh).
  Bit 0   - Joypad Mode (0=Normal/Read-only, 1=Read/Write)
  Bit 1-7 - Not used
On older gameboys (those with 2x4bit joypad pinout), the lower 4bit of FF00h
become read/write-able. On color gameboy and up (those with 8bit joypad
pinout), register FF61h becomes R/W (if it is enabled by ROMDIS).
Although FF60h is write-able only while ROMDIS=HIGH, the setting keeps working
even after releasing ROMDIS.

--- Below Registers on CGB only ---

FF4C - DMG1 - CGB Mode / DMG Mode (R/W only until FF50h is written)
Internally used by CGB-BIOS. Set to 04h in DMG-mode. Set to Cart[0143h] in
CGB-mode (for CGB carts, that is usually 80h or C0h) (so the three
read/write-able bits are usually zero in CGB mode).
Settings like Cart[0143h]=88h, would allow to enter a special mode, but, in
that case, the BIOS boots up with a locked blank palette, so that mode is of no
good use.
  Bit 0   - Unknown                     (0=Normal, 1=No effect?)
  Bit 1   - Not used
  Bit 2   - Disable All CGB Functions   (0=CGB, 1=DMG)
  Bit 3   - Disable Some CGB Functions  (0=Normal, 1=Extended DMG Mode)
  Bit 4-7 - Not used
Bit3 disables HDMA, BGPD, OBPD, and KEY1. Bit2 does the same, and additionally
disables RP(IR), VBK(VRAM), SVBK(WRAM), and FF6Ch. If both bits are set, Bit3
has priority over Bit2. FF4Ch is write-able (and read-able) only until FF50h is
written to for the 1st time.
...one or more of the bits probably affect FF02h serial-speed... ?

FF6C - DMG2 - Unknown (R, or R/W, depending on FF4Ch.Bit2)
  Bit 0   - Whatever CGB/DMG Mode related (0=CGB, 1=DMG)
  Bit 1-7 - Not used
Internally used by CGB-BIOS. Set to 01h in DMG mode. This register becomes
read-only if FF4Ch.Bit2 has been set to 1 prior to the first write to FF50h. In
other words: FF6Ch is R/W in CGB mode, and read-only in non-CGB mode. The
function of the bit is unknown?

FF61 - JOY8 - 8bit-Joypad (R, or R/W) (enabled while ROMDIS=HIGH only)
  0 - Right     (0=Low/Pressed, 1=High/Released/Disabled)
  1 - Left      ("")
  2 - Up        ("")
  3 - Down      ("")
  4 - Button A  ("")
  5 - Button B  ("")
  6 - Select    ("")
  7 - Start     ("")
The register is normally disabled. When enabled via ROMDIS, it can be either
read-only (input), or read/write (output), depending on FF60h setting.

FF63 - ? - Undocumented Ext.Configuration (enabled while ROMDIS=HIGH only)
This register is normally deactivated (value FFh, read-only).
  0 - Unknown (0=Normal, 1=No effect?)
  1 - Unknown (0=Normal, 1=Disable Video?)
  2 - Unknown (0=Normal, 1=Disable Video?)
  3 - Unknown (0=Normal, 1=Disable Video?)
  4 - Unknown (0=Normal, 1=Disable Video?)
  5 - Unknown (0=Normal, 1=Crash?)
  6 - Unknown (0=Normal, 1=No effect?)
  7 - Unknown (0=Normal, 1=No effect?)
When ROMDIS is high, reading returns 00h, and writing non-zero values seems to
crash the program (or disable video) in most cases.

FF72 - Undocumented (00h) - Bit 0-7 (Read/Write)
FF73 - Undocumented (00h) - Bit 0-7 (Read/Write)
FF74 - Undocumented (00h) - Bit 0-7 (Read/Write) - CGB Mode Only
FF75 - Undocumented (8Fh) - Bit 4-6 (Read/Write)
FF76 - Undocumented (00h) - Always 00h (Read Only)
FF77 - Undocumented (00h) - Always 00h (Read Only)
Further undocumented CGB Registers. The numbers in brackets () indicate the
initial values. Purpose of these registers is unknown (if any).

Registers FF6C and FF74 are always FFh if the CGB is in Non CGB Mode.
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty
User avatar
Gilbert
Posts: 564
Joined: Sun Dec 12, 2010 10:27 pm
Location: Hong Kong
Contact:

Re: FF4C and FF6C

Post by Gilbert »

I'll try to do a rough translation. (Correct me if I am wrong.)

Code: Select all

KEY0 FF4C CPU mode register
Bits 2 and 3
CPU mode select
00: CGB mode (Mode used by carts supporting CGB)
01: DMG/MGB mode (Mode used by DMG/MGB-only carts)
10: PGB1 mode (STOP the CPU, with the LCD operated by an external signal)
11: PGB2 mode (CPU still running, with the LCD operated by an external signal)


OPRI FF6C OBJ priority mode select register
Bit 0
OBJ priority mode select (when X coordinates are different)
0: smaller OBJ-NO has higher priority
1: smaller X coordinate has higher priority
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: FF4C and FF6C

Post by nocash »

OBJ priority sounds good. I haven't tried it, but as it is R/W, one could easily check that (now that it is known what it is supposed to do).

Not sure what the external LCD signal flag could be good for. It isn't R/W after booting, but it could be set via cart header.
My best guess would be that it might be for streaming video through the cart edge connector?
Don't know how that could work with the CPU kept running though.
It might work when mapping external video memory to parts of the ROM space, and running CPU code in the remaining ROM space during vblank?
That could be tested when using a ROM filled with nonzero/random data, that might display something (unless it needs palette init somehow).
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: FF4C and FF6C

Post by calima »

Maybe that's how these kiosks operated?

Image
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: FF4C and FF6C

Post by nocash »

That is the opposite, the internal LCD signal passed to an external monitor (and the FF4C/FF6C registers exist on CGB only anyways).
The CGB feature sounds more like support for something alike coprocessors on SNES, where one could DMA data from cartridge to VRAM.
Or perhaps more ideally, completely disable internal VRAM, and instead DMA pixels directly from cartridge to the LCD hardware.
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: FF4C and FF6C

Post by tepples »

To support something like the Game Gear TV Tuner perhaps?
Pokun
Posts: 2675
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: FF4C and FF6C

Post by Pokun »

Yeah I also thought of a TV Tuner. But it just says "driving the liquid crystal externally", I'm not sure if it means you can fully access the LCD screen or just use the LCDC hardware like the CPU uses it. Many video chips like the NES PPU can combine it's video output with an external video source, but this seems different?

I did a quick test of OPRI on my GBC by quickly modifying a DMG project I had into a CGB ROM, but I could not get it to work. It was very hard to see on the small LCD though and there are many things that might have went wrong since I didn't properly initialize all CGB registers and stuff.
User avatar
TmEE
Posts: 960
Joined: Wed Feb 13, 2008 9:10 am
Location: Norway (50 and 60Hz compatible :P)
Contact:

Re: FF4C and FF6C

Post by TmEE »

Game Gear TV tuner drives the LCD directly, cartslot becomes passthrough directly to the LCD interface. I imagine similar thing is possible here too.
windwakr2
Posts: 6
Joined: Sun Mar 29, 2020 9:38 am

Re: FF4C and FF6C

Post by windwakr2 »

So the full source code to the GBC bootstrap(along with A LOT of other stuff) leaked today along with documentation that contained the bits of info I had posted in the OP. So now that it's confirmed that info comes from the result of theft I have removed it from my post. I will not link to the leaked files.
nitro2k01
Posts: 252
Joined: Sat Aug 28, 2010 9:01 am

Re: FF4C and FF6C

Post by nitro2k01 »

Hi. People over in the GB Dev Discord server are researching manually entering GBA's GBC mode. One of the mystery bits in 0x04000800 disbales the boot ROM whereas the other two mystery bits apparently do nothing. My own theory is that those three bits correspond to the test pins (TEST0-TEST2) of the GBC CPU. So I sat down to test this on an actual GBC. The results were not what I expected. TEST0 and TEST1 produce a white screen, with seemingly no code execution. (The cartridge slot contained a ROM with an entry point at 0 which should have executed.) TEST2 produced a flashing screen, also seemingly without executing my code.

Question to nocash, just to be clear. Which pin on the CPU is ROMDIS? Is it one of the test pins? (TEST0-TEST2, aka 49-51.) Are there any additional timing or other requirements in your testing that I might have missed?
Post Reply