FF4C and FF6C
-
windwakr2
- Posts: 6
- Joined: Sun Mar 29, 2020 9:38 am
FF4C and FF6C
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.
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
Did somebody already try to translate the japanese text?
Some of my own findings...
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.
-
Gilbert
- Posts: 616
- Joined: Sun Dec 12, 2010 10:27 pm
- Location: Hong Kong
Re: FF4C and FF6C
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
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).
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).
-
calima
- Posts: 1789
- Joined: Tue Oct 06, 2015 10:16 am
Re: FF4C and FF6C
Maybe that's how these kiosks operated?


-
nocash
- Posts: 1494
- Joined: Fri Feb 24, 2012 12:09 pm
Re: FF4C and FF6C
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.
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.
-
Pokun
- Posts: 3486
- Joined: Tue May 28, 2013 5:49 am
- Location: Hokkaido, Japan
Re: FF4C and FF6C
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.
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.
-
TmEE
- Posts: 1080
- Joined: Wed Feb 13, 2008 9:10 am
- Location: Norway (50 and 60Hz compatible :P)
Re: FF4C and FF6C
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
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
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?
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
Pinouts
Notes on ROMDIS pin...
And other special pins...
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.
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?
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).
-
nitro2k01
- Posts: 261
- Joined: Sat Aug 28, 2010 9:01 am
Re: FF4C and FF6C
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.
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
On which one, Gameboy, Pocket Gameboy, Color Gameboy?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).
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 probably means that the CPU tries to read from the external bus but without pulling A15 (aka "ROMCS") low
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?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.
Btw. do older (pre-CGB) gameboys support NMI, too? Like on the test pins?
-
nitro2k01
- Posts: 261
- Joined: Sat Aug 28, 2010 9:01 am
Re: FF4C and FF6C
Oops, my mistake. I was looking at Pocket and thought I was looking at DMG/SGB. So no problem.
Yes. Tested it once more now to make sure and the button still works.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?
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.
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.nocash wrote: Wed Dec 25, 2024 12:47 pmBtw. do older (pre-CGB) gameboys support NMI, too? Like on the test pins?