FF4C and FF6C

Discussion of programming and development for the original Game Boy and Game Boy Color.
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: 1494
Joined: Fri Feb 24, 2012 12:09 pm

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: 616
Joined: Sun Dec 12, 2010 10:27 pm
Location: Hong Kong

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: 1494
Joined: Fri Feb 24, 2012 12:09 pm

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: 1789
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: 1494
Joined: Fri Feb 24, 2012 12:09 pm

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: 23011
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)

Re: FF4C and FF6C

Post by tepples »

To support something like the Game Gear TV Tuner perhaps?
Pokun
Posts: 3486
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: 1080
Joined: Wed Feb 13, 2008 9:10 am
Location: Norway (50 and 60Hz compatible :P)

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: 261
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?
nocash
Posts: 1494
Joined: Fri Feb 24, 2012 12:09 pm

Re: FF4C and FF6C

Post by nocash »

Pinouts

Code: Select all

Pinouts - CPU - Pinouts
-----------------------

Classic Gameboy CPU Pinout (DMG-CPU B)
Super Gameboy CPU Pinout (SGB-CPU 01)
  01 A0   11 A10  21 D4    31 MD1   41 MA7   51 LD0   61 VIN   71 /RES
  02 A1   12 A11  22 D5    32 GND   42 MA12  52 CPG   62 P15   72 GND
  03 A2   13 A12  23 D6    33 MD0   43 /MCS  53 CP    63 P14   73 X0
  04 A3   14 A13  24 D7    34 MA0   44 MA10  54 ST    64 P13   74 X1
  05 A4   15 A14  25 MD7   35 MA1   45 /MRD  55 CPL   65 P12   75 PHI
  06 A5   16 A15  26 MD6   36 MA2   46 MA11  56 FR    66 P11   76 ROMDIS
  07 A6   17 D0   27 MD5   37 MA3   47 MA9   57 S     67 P10   77 CRASH
  08 A7   18 D1   28 MD4   38 MA4   48 MA8   58 VDD5  68 SCLK  78 /WR
  09 A8   19 D2   29 MD3   39 MA5   49 /MWR  59 ROUT  69 SIN   79 /RD
  10 A9   20 D3   30 MD2   40 MA6   50 LD1   60 LOUT  70 SOUT  80 /CS

Pocket Gameboy CPU Pinout (CPU MGB)
  01 A0   11 A10  21 D4    31 MD5   41 CPG   51 MA2   61 /MRD  71 P12
  02 A1   12 A11  22 D5    32 GND   42 CPL   52 MA3   62 MA11  72 GND
  03 A2   13 A12  23 D6    33 MD4   43 ST    53 VDD5  63 MA9   73 P11
  04 A3   14 A13  24 D7    34 MD3   44 LD0   54 MA4   64 MA8   74 P10
  05 A4   15 A14  25 /RES  35 MD2   45 LD1   55 MA5   65 /MWR  75 ROMDIS
  06 A5   16 A15  26 Vin   36 MD1   46 CP    56 MA6   66 CK0   76 CRASH
  07 A6   17 D0   27 SO1   37 MD0   47 FR    57 MA7   67 CK1   77 PHI
  08 A7   18 D1   28 SO2   38 SOUT  48 S     58 MA12  68 P15   78 /WR
  09 A8   19 D2   29 MD7   39 SCK   49 MA0   59 /MCS  69 P14   79 /RD
  10 A9   20 D3   30 MD6   40 SIN   50 MA1   60 MA10  70 P13   80 /CS
VRAM is built-in in the CPU (external Mxx pins do exist, but aren't used).

Color Gameboy CPU Pinout (CPU CGB B)
  01 P00  17 A8   33 D6    49 GNDed 65 ?     81 LDG3   97 WA2   113 WA11
  02 P03  18 A9   34 D7    50 GNDed 66 ?     82 LDG4   98 WA1   114 WA9
  03 P02  19 GND  35 /RES  51 GNDed 67 ?     83 LDG5   99 WA0   115 WA8
  04 P01  20 VDD5 36 Vin   52 CK1   68 MOD   84 GND   100 WD0   116 WA13
  05 PHI  21 A10  37 SO1   52 CK2   69 SPS   85 VDD3  101 WD1   117 /WWR
  06 /WR  22 A11  38 SO2   54 GNDed 70 CLS   86 LDB0  102 WD2   118 WA14
  07 /RD  23 A12  39 ?     55 GNDed 71 SPL   87 LDB1  103 WD3   119 WA12
  08 /CS  24 A13  40 SCK   56 M1    72 LDR0  88 LDB2  104 WD4   120 WA7
  09 A0   25 A14  41 SIN   57 /NMI  73 LDR1  89 LDB3  105 WD5   121 WA6
  10 A1   26 A15  42 SOUT  58 GNDed 74 LDR2  90 LDB4  106 WD6   122 WA5
  11 A2   27 D0   43 VDD5  59 GNDed 75 LDR3  91 LDB5  107 VDD3  123 WA4
  12 A3   28 D1   44 GND   60 ?     76 LDR4  92 PS    108 GND   124 WA3
  13 A4   29 D2   45 R0    61 ?     77 LDR5  93 LP    109 WD7   125 P10
  14 A5   30 D3   46 R1    62 ?     78 LDG0  94 DCK   110 /WCS  126 P11
  15 A6   31 D4   47 R2    63 ?     79 LDG1  95 REVC  111 WA10  127 P13
  16 A7   32 D5   48 R3    64 ?     80 LDG2  96 R4    112 /WRD  128 P12

Advance Gameboy CPU Pinouts (CPU AGB)
  1 VDD3  17 D0   33 A0    49 WA4   65 VDD2  81 WD9   97 LDB5   113 CK1
  2 IN35  18 A15  34 /CS   50 WA5   66 WD5   82 WD1   98 LDB4   114 CK2
  3 TP8   19 A14  35 /RD   51 WA6   67 WD13  83 /WOE  99 LDB3   115 VDD2
  4 TP0   20 A13  36 /WR   52 WA7   68 WD6   84 DCK   100 LDB2  116 GND
  5 TP1   21 A12  37 PHI   53 /WLB  69 WD14  85 LP    101 LDB1  117 VDD2
  6 SO1   22 A11  38 VDD35 54 /WUB  70 WD7   86 PS    102 GND   118 VCNT5
  7 SO2   23 A10  39 GND   55 /WWE  71 WD15  87 LDR5  103 VDD3  119 TP9
  8 Vin   24 A9   40 SC    56 WA8   72 WD8   88 LDR4  104 SPL   120 TP6
  9 /RES  25 A8   41 SD    57 WA9   73 WD16  89 LDR3  105 CLS   121 TP5
  10 D7   26 A7   42 SI    58 WA10  74 WA16  90 LDR2  106 SPS   122 TP7
  11 D6   27 A6   43 SO    59 WA11  75 WD12  91 LDR1  107 MOD   123 TP4
  12 D5   28 A5   44 VDD2  60 WA12  76 WD4   92 LDG5  108 REVC  124 /FIQ
  13 D4   29 A4   45 WA0   61 WA13  77 WD11  93 LDG4  109 GNDed 125 /RESET
  14 D3   30 A3   46 WA1   62 WA14  78 WD3   94 LDG3  110 GNDed 126 TP2
  15 D2   31 A2   47 WA2   63 WA15  79 WD10  95 LDG2  111 GNDed 127 TP3
  16 D1   32 A1   48 WA3   64 GND   80 WD2   96 LDG1  112 GNDed 128 GND

GBA SP CPU Pinouts (CPU AGB B)
  1 IN35   21 D0    41 A0    61 WA4   81 WD13  101 GND   121 LDB4  141 GND
  2 TP8    22 A15   42 /CS   62 WA5   82 WD6   102 VDD1  122 LDB3  142 VDD3
  3 TP0    23 A14   43 /RD   63 WA6   83 WD14  103 GND   123 LDB2  143 GND
  4 TP1    24 A13   44 /WR   64 WA7   84 WD7   104 VDD3  124 LDB1  144 VCNT5
  5 SO1    25 A12   45 PHI   65 /WLB  85 WD15  105 DCK   125 GND   145 TP9
  6 SO2    26 A11   46 VDD35 66 /WUB  86 WD8   106 LP    126 VDD3  146 TP6
  7 Vin    27 GND   47 GND   67 GND   87 WD16  107 PS    127 SPL   147 TP5
  8 VDD1   28 VDD35 48 SC    68 VDD2  88 WA16  108 LDR5  128 CLS   148 TP7
  9 GND    29 A10   49 SD    69 /WWE  89 VDD2  109 LDR4  129 SPS   149 TP4
  10 VDD35 30 A9    50 SI    70 WA8   90 GND   110 LDR3  130 MOD   150 /FIQ
  11 /RES  31 A8    51 SO    71 WA9   91 WD12  111 LDR2  131 REVC  151 /RESET
  12 D7    32 A7    52 VDD35 72 WA10  92 WD4   112 LDR1  132 GND   152 ?
  13 D6    33 A6    53 GND   73 WA11  93 WD11  113 LDG5  133 GND   153 TP3
  14 D5    34 A5    54 VDD1  74 WA12  94 WD3   114 LDG4  134 GND   154 TP2
  15 D4    35 A4    55 GND   75 WA13  95 WD10  115 LDG3  135 GND   155 VDD3
  16 D3    36 GND   56 VDD2  76 WA14  96 WD2   116 LDG2  136 VDD1  156 GND
  17 D2    37 VDD35 57 WA0   77 WA15  97 WD9   117 LDG1  137 GND
  18 GND   38 A3    58 WA1   78 GND   98 WD1   118 GND   138 CK1
  19 VDD35 39 A2    59 WA2   79 VDD2  99 /WOE  119 VDD3  139 CK2
  20 D1    40 A1    60 WA3   80 WD5   100 VDD2 120 LDB5  140 VDD2
Pin 152 seems to be not connected on the mainboard, maybe an undoc output.
Notes on ROMDIS pin...

Code: Select all

Pinouts - CPU - ROMDIS Pin
--------------------------

romdis discovered 1/2007 by nocash
ROMDIS is a grounded pin on gameboy CPUs. When disconnecting it from ground, it
can be used to bypass the Nintendo intro, and to start the cartridge directly
without boot delays.
However, the entry point, the initial register settings (especially FF60h), and
entry time (distance to VBlank) will be different than usually. So, ROMDIS will
work only with programs that are specifically made compatible to it, ie. it
does not work with any currently existing games.

ROMDIS Functionality (while and as long as ROMDIS is HIGH)
 - disables boot bios (if it wasn't already disabled via FF50h)
 - disables portions of OAM (or at least makes DMA to OAM unstable?)
 - disables internal VRAM (that on pocket gameboy only, not on DMG/CGB)
 - enables undocumented port FF60h (on CGB also ports FF61h/FF63h)
 - enables Cart ROM on CGB only (unlike DMG/MGB FFh-filled effect)
 - does NOT enable Cart ROM on DMG/MGB (so boot region gets FFh-filled)
 - hangs CPU on /RES (ROMDIS works only after reset)

Classic Gameboy ROMDIS (Pin 76)
Disables boot rom, but without enabeling cart rom. In result, databus seems to
get HIGH-Z, so that a series of RST 38h instructions (opcode FFh) will be
passed to the CPU, the first RST pushes the current PC on stack, all further
RST's will push 0039h on stack, this goes through HRAM, and unused I/O region
(including port FF60h, so joypad is forced into R/W-mode), until 0039h is
pushed to port FF50h, which does enable Cart ROM, with an entrypoint of 0038h
(set like so from the last RST).

Super Gameboy ROMDIS
Not sure if it works. Parts of the boot delays relies on the SNES BIOS (rather
than on the SGB BIOS).
After ROMDIS, the SGB software would still need to forward the SGB flag, and
the nintendo logo from cartheader to the SNES BIOS.
Note: On the SGB, the length of SGB intro varies on cold-boot (power-on), and
warm-boot (reset-button), the latter one skips portions of the intro.

Pocket Gameboy ROMDIS (Pin 75)
Same as on DMG, but additionally disables internal VRAM (neither the CPU nor
the LCD controller can access VRAM while ROMDIS is HIGH).

Color Gameboy ROMDIS (Pin 50)
Doesn't execute a series of RST 38h opcodes, and doesn't fill HRAM and I/O
region by 0039h, instead, cart ROM seems to be directly enabled. Not sure if
the entrypoint is 0038h (in case 1-2 RST's are still executed) (in my test
proggy, it still somehow reaches my entrypoint, though that might be just
fool's luck).
Respectively, RST 38h won't write to FF50h nor FF60h, so the joypad maintains
normal functionality, and the Boot BIOS is still enabled (as soon as ROMDIS is
released), allowing to dump the CGB-BIOS by software (by reading from
0000h-00FFh and 0200h-08FFh). Otherwise, before launching the program, write
01h or 11h to FF50h to disable the BIOS (for mono games, first initialize mono
palette and DMG-Mode registers).

ROMDIS on Gameboy Advance
Didn't test undoc pins on GBA yet. Some might be of some use in 8bit mode,
although most are probably for 32bit mode. Pin 109-112 (normally grounded) seem
to be undoc inputs, there may be further inputs though.
GBA Port 4000800h.bit3 can disable the CGB bootrom (see gbatek), the cart
starts at 0000h (and Ports FF60h, FF61h, FF63h are unlocked, alike as when CGB
ROMDIS=HIGH).

Initialization after ROMDIS
I/O Ports, CPU Registers, RAM and VRAM may be initialized differently than
usually, so everything should be initialized, if that isn't done already.
Respectively, detecting the gameboy-type by examining A won't work as such. On
CGB, monochrome games must be manually switched into DMG mode (see CGB bios).

Automatic ROMDIS
Currently, I am dragging the pin high by hand. More comfortable would some
logic that sets it LOW on /RES, and /HIGH on first /RD from ROM, and back LOW
on fifth /RD from ROM (allowing to re-init FF60h while ROMDIS is still on).
My current idea is using a 74xx165 shift register, loaded with 00011110 on
/RES. Any ideas for using smaller or cheaper chips, or using more simplified
transistor circuits?
And other special pins...

Code: Select all

Pinouts - CPU - Other Special Pins
----------------------------------

CRASH Pin (DMG,MGB,SGB)
This might be an external IRQ, NMI, BREAK, or ABORT input. Or, it might be
simply disabling Video Output and/or HIRAM and/or OAM and/or IO-ports in the
upper 200h bytes of memory? The pin is normally grounded. Dragging it High
seems to crash the program (any time, before, during, or after intro).
The pin appears to have some sort of WAIT functionality?

/NMI Pin (CGB Only)
Probably used as debug break signal. Normally wired to VDD3 via CL1. Even when
disconnecting it, I wasn't able to get any reaction to NMI signals. Possibly
NMIs must be unlocked by whatever I/O ports, and/or by special values in
cartridge header? The address of the NMI vector is unknown (on a real Z80, it
would be at 0066h).
Don't know if the GBA's FIQ pin can be used as NMI input when in CGB mode?

M1 Pin (CGB Only)
Probably used to notify debug hardware on opcode fetches, would be allowing to
monitor when (and which) opcodes are executed (which opcodes could be
determined only if the opcode is output to the data bus, that is probably not
true for code in bios, vram, and hiram; and code in wram probably shows up only
on wram bus).

GNDed Pins on CGB
The seven grounded pins at 49..59 are NOT interconnected with supply ground,
nor with each other (verified); these pins seem to be undocumented inputs,
pin 50 is ROMDIS, dragging the other 6 pins to HIGH seems to:
  Pin 49 - crash - Crash (any time when asserted)
  Pin 51,58 - confuse - Crash sometimes (but not always)
  Pin 54,55,59 - rescrash - Crash on reset ONLY (no effect within/after intro)
The other four grounded pins (those coupled with VDD3/VDD5 pins) are probably
supply pins, and are probably interconnected with each other inside of the chip
(not verified).
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty
nitro2k01
Posts: 261
Joined: Sat Aug 28, 2010 9:01 am

Re: FF4C and FF6C

Post by nitro2k01 »

nocash: Wow! You should've released this much earlier. This would've been groundbreaking stuff in 2007, or even just half of that ago. Now, a lot of that stuff is well understood, at least some parts. I don't know if you saw the other thread, but I've tried to collect as much info as I can on these kinds of topics over on my wiki, using your and other people's notes. If for some reason my wiki doesn't work for you for internet related reasons, I can try to produce an offline copy for you, maybe a zip file with the raw wiki text or whatever works for you.

https://gbdev.gg8.se/wiki/articles/Game ... d_features

Some notes on your notes above:

ROMDIS and CRASH are called T1 and T2 in the original schematic. I think you maybe got the pin numbers wrong in your notes (swapped ROMDIS and PHI). Regardless, those were probably used for factory testing, or in the DMG dev kit to do debug functionality like reading/writing memory while the CPU is not clocked for example.

> does NOT enable Cart ROM on DMG/MGB (so boot region gets FFh-filled)

This part is interesting. It probably means that the CPU tries to read from the external bus but without pulling A15 (aka "ROMCS") low, so the ROM doesn't know to respond with data. This vaguely matches gekkio's description of how he bypassed the DMG boot ROM to be able to dump it. I think what he did was pull that pin high, and then present data for CPU instructions while single step clocking the CPU, despite having the "wrong" address.

> /NMI Pin (CGB Only)

To use this pin, CL1. Then solder a high value resistor over CL1. (10k-100k should be fine.) Then connect a button between the side of CL1 that's connected to the NMI signal and ground. Instead you can also use the NMI test point on the other side of the board for connecting the button, which may be easier to route a wire to. Pressing the button triggers a NMI which has interrupt vector $0080. In NMI mode, both regular interrupts and NMI are disable. To return from NMI, execute a RETI instruction. Simply executing an EI is not enough to re-enable interrupts. If using a button, you often get a second NMI request due to switch bounce, that's pending and immediately executed when you execute the RETI.

> GNDed Pins on CGB

These have official names according to the service schematic.

https://wiki.console5.com/tw/images/e/e ... ematic.png

Pins 49-51 are test pins, so probably intended for factory testing and/or debug equipment.

The other have names as follows:
54=PSMO0
55=PSMO1
58=/MCS0
59=/MCS1

According to people who have analyzed photos of the GBC die, those seems to be connected to the LCD controller, so they might be for accessing a LCD test mode, or they might intended for something like the possibility of controlling external video RAM. No one really knows.

Another thing, in case you missed seeing it somehow. PGB mode has been confirmed to be a thing. After writing the right value to $ff4c then running STOP, the cartridge bus becomes a passthrough to the LCD, which means that a specially designed cartridge could output data directly to the screen. No one has yet tested this to the point of outputting something useful on the screen, though.
nocash
Posts: 1494
Joined: Fri Feb 24, 2012 12:09 pm

Re: FF4C and FF6C

Post by nocash »

nitro2k01 wrote: Wed Dec 25, 2024 2:28 am I think you maybe got the pin numbers wrong in your notes (swapped ROMDIS and PHI).
On which one, Gameboy, Pocket Gameboy, Color Gameboy?
nitro2k01 wrote: Wed Dec 25, 2024 2:28 am probably means that the CPU tries to read from the external bus but without pulling A15 (aka "ROMCS") low
I guess so, too. Then one could modify the cartridge to ignore A15 on power-up, or install a boot ROM inside of the console. I don't know if it outputs a valid address on A0-A14 though (if so, it should probably start at 0000h or 0100h). And I wasn't sure if it reads from the databus at all (but if gekkio was able to inject opcodes then it does apparently do so).
nitro2k01 wrote: Wed Dec 25, 2024 2:28 am CL1. Then solder a high value resistor over CL1. (10k-100k should be fine.) Then connect a button between the side of CL1 that's connected to the NMI signal and ground. Instead you can also use the NMI test point on the other side of the board for connecting the button, which may be easier to route a wire to. Pressing the button triggers a NMI which has interrupt vector $0080.
Hmmm, I thought that I had done that on my CGB (using a wire and tapping it to GND or VCC). I didn't knew about 0080h, but I had zeropadded more than 32 of bytes of memory from 0066h and up, and then placed my NMI handler thereafter (which should have displayed a text message on the screen and then lock up, but somehow it did never do that). But it's tested, and working?
Btw. do older (pre-CGB) gameboys support NMI, too? Like on the test pins?
homepage - patreon - you can think of a bit as a bottle that is either half full or half empty
nitro2k01
Posts: 261
Joined: Sat Aug 28, 2010 9:01 am

Re: FF4C and FF6C

Post by nitro2k01 »

nocash wrote: Wed Dec 25, 2024 12:47 pm On which one, Gameboy, Pocket Gameboy, Color Gameboy?
Oops, my mistake. I was looking at Pocket and thought I was looking at DMG/SGB. So no problem.
nocash wrote: Wed Dec 25, 2024 12:47 pmHmmm, I thought that I had done that on my CGB (using a wire and tapping it to GND or VCC). I didn't knew about 0080h, but I had zeropadded more than 32 of bytes of memory from 0066h and up, and then placed my NMI handler thereafter (which should have displayed a text message on the screen and then lock up, but somehow it did never do that). But it's tested, and working?
Yes. Tested it once more now to make sure and the button still works. :)
Maybe the pullup resistor is important. Never tried without it. Also, maybe if your code does some special things it won't work. For example: use halt opcode to wait for next VBlank. Never tried after NMI, but maybe won't work. Or if you used just ei to enable interrupts thinking it would work as normal.
nocash wrote: Wed Dec 25, 2024 12:47 pmBtw. do older (pre-CGB) gameboys support NMI, too? Like on the test pins?
No. Someone figured out from looking at the die photos, or maybe reading old Sharp documents of what we suspect is the same CPU, that it should have NMI support. But it's not bonded out to any pins. Maybe it can be triggered as a proof of concept if someone decaps a DMG CPU and puts a probe needle on the right spot on the die.