├── Copy ├── TCAGBD.pdf ├── GBCPUman.pdf ├── GBCribSheet000129.pdf ├── TheNintendoGameboy.pdf ├── pandocs-Specifications.pdf ├── How to make a (GameBoy) emulator?.pdf ├── pastraiser Gameboy (LR35902) OPCODES.pdf ├── www.ladecadence.net_trastero_listado juegos gameboy.pdf ├── z80gboy.txt ├── istat98.txt ├── Nitty Gritty Gameboy VRAM Timing.txt └── gameboy.txt └── Readme.md /Copy/TCAGBD.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/h3nnn4n/gameboy_documentation/HEAD/Copy/TCAGBD.pdf -------------------------------------------------------------------------------- /Copy/GBCPUman.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/h3nnn4n/gameboy_documentation/HEAD/Copy/GBCPUman.pdf -------------------------------------------------------------------------------- /Copy/GBCribSheet000129.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/h3nnn4n/gameboy_documentation/HEAD/Copy/GBCribSheet000129.pdf -------------------------------------------------------------------------------- /Copy/TheNintendoGameboy.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/h3nnn4n/gameboy_documentation/HEAD/Copy/TheNintendoGameboy.pdf -------------------------------------------------------------------------------- /Copy/pandocs-Specifications.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/h3nnn4n/gameboy_documentation/HEAD/Copy/pandocs-Specifications.pdf -------------------------------------------------------------------------------- /Copy/How to make a (GameBoy) emulator?.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/h3nnn4n/gameboy_documentation/HEAD/Copy/How to make a (GameBoy) emulator?.pdf -------------------------------------------------------------------------------- /Copy/pastraiser Gameboy (LR35902) OPCODES.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/h3nnn4n/gameboy_documentation/HEAD/Copy/pastraiser Gameboy (LR35902) OPCODES.pdf -------------------------------------------------------------------------------- /Copy/www.ladecadence.net_trastero_listado juegos gameboy.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/h3nnn4n/gameboy_documentation/HEAD/Copy/www.ladecadence.net_trastero_listado juegos gameboy.pdf -------------------------------------------------------------------------------- /Copy/z80gboy.txt: -------------------------------------------------------------------------------- 1 | 2 | I was just reading your Z80 homepage, and I noticed that you wanted more 3 | details about the Gameboy CPU. I have a little bit of information that I 4 | thought you might like. 5 | 6 | The CPU is a Z80 workalike running at 4.19 MHz. The CPU has several 7 | registers missing and some instructions changes. These are as follows: 8 | 9 | * The "shadow" set of registers [BC',DE',HL',AF'] and the index registers 10 | [IX,IY] are missing and, consequently, there are no DD and FD opcode 11 | tables. 12 | 13 | * The I/O ports are gone and so are all IN/OUT opcodes. 14 | 15 | * HALT is interrupted even when interrupts are disabled. 16 | 17 | * Following Z80 opcodes are changed: 18 | --------------------------------------------------------------------------- 19 | Code Z80 operation GameBoy operation 20 | --------------------------------------------------------------------------- 21 | 08 xx xx EX AF,AF' LD (word),SP Save SP at given address 22 | 10 xx DJNZ offset STOP Meaning unknown 23 | 22 LD (word),HL LD (HLI),A Save A at (HL) and increment HL 24 | 2A LD HL,(word) LD A,(HLI) Load A from (HL) and increment HL 25 | 32 LD (word),A LD (HLD),A Save A at (HL) and decrement HL 26 | 3A LD A,(word) LD A,(HLD) Load A from (HL) and decrement HL 27 | D3 OUTA (byte) No operation 28 | D9 EXX RETI Enable interrupts and return 29 | DB INA (byte) No operation 30 | DD Prefix DD No operation 31 | E0 xx RET PO LD (byte),A Save A at (FF00+byte) 32 | E2 JP PO,word LD (C),A Save A at (FF00+C) 33 | E3 EX HL,(SP) No operation 34 | E4 CALL PO,word No operation 35 | E8 xx RET PE ADD SP,offset Add signed offset to SP 36 | EA xx xx JP PE,word LD (word),A Save A at given address 37 | EB EX DE,HL No operation 38 | EC CALL PE,word No operation 39 | F0 xx RET P LD A,(byte) Load A from (FF00+byte) 40 | F2 JP P,word No operation 41 | F4 CALL P,word No operation 42 | F8 xx RET M LDHL SP,offset Load HL with SP + signed offset 43 | FA xx xx JP M,word LD A,(word) Load A from given address 44 | FC CALL M,word No operation 45 | FD Prefix FD No operation 46 | --------------------------------------------------------------------------- 47 | 48 | Hope this helps, 49 | 50 | Pat Fagan 51 | 52 | 53 | -------------------------------------------------------------------------------- /Copy/istat98.txt: -------------------------------------------------------------------------------- 1 | ISTAT98.TXT 1998 BY MARTIN KORTH 2 | -------------------------------- 3 | 4 | 5 | Interrupt INT 48h - LCD STAT 6 | ---------------------------- 7 | 8 | 9 | The STAT register (FF41) selects the conditions that will generate this 10 | interrupt (expecting that interrupts are enabled via EI or RETI and that 11 | IE.1 (FFFF.1) is set). 12 | STAT.3 HBLANK (start of mode 0) 13 | STAT.4 VBLANK (start of mode 1) (additional to INT 40) 14 | STAT.5 OAM (start of mode 2 and mode 1) 15 | STAT.6 LY=LYC (see info about LY=00) 16 | 17 | 18 | If two STAT-condiditions come true at the same time only one INT 48 is 19 | generated. This happens in combinations 20 | LYC=01..90 and OAM at the same time (see info about LY=00) 21 | LYC=90 and VBLANK at the same time 22 | OAM and VBLANK at the same time 23 | HBLANK and LYC=00 and LYC=91..99 are off-grid and cannot hit others. 24 | 25 | 26 | Some STAT-conditions cause the following STAT-condition to be ignored: 27 | Past VBLANK following LYC=91..99,00 is ignored 28 | Past VBLANK following OAM (at 00) is ignored 29 | Past LYC=00 at 99.2 following OAMs (at 00 and 01) are ignored 30 | Past LYC=01..8F following OAM (at 02..90) is ignored 31 | Past LYC=00..8F following HBLANK (at 00..8F) is ignored 32 | Past LYC=8F following VBLANK is ignored 33 | Past HBLANK following OAM is ignored 34 | Past HBLANK at 8F following VBLANK is ignored 35 | 36 | 37 | If the OAM condition occurs, everything following -is- recognized. 38 | An ignored VBLANK condition means that INT 48h does not produce a V-Blank 39 | interrupt, INT 40h is not affected and still produces V-Blank interrupts. 40 | 41 | 42 | The last LY period (LY=99) is a shorter than normal LY periodes. It is followed 43 | by the first LY period (LY=00) this period is longer than normal periodes. 44 | LY value clks description 45 | ------------------------------- 46 | LY=01..8F 456 at the same moment than OAM 47 | LY=90 456 at the same moment than pseudo-OAM and VBLANK 48 | LY=91..98 456 during vblank (similiar to LY=01..8F) 49 | LY=99 ca.56 similiar to LY=91..98, but shorter 50 | LY=00 ca.856 starts during vblank, then present until second OAM 51 | Because of the pre-started long LY=00 period, LYC=00 occurs within vblank 52 | period and before first OAM (where we would have expected it) 53 | 54 | 55 | *EOF* 56 | 57 | 58 | 59 | -------------------------------------------------------------------------------- /Readme.md: -------------------------------------------------------------------------------- 1 | Gameboy Documentation 2 | ===================== 3 | 4 | This is a collection of documents regarding the working of the Gameboy handheld console. The aim of this repository 5 | is to gather as much data as possible in one point, and with the intuit of preserving the data found I will be storing a copy here 6 | also. In the case of webpages I will be storing a pdf copy here. 7 | 8 | 9 | Feel free to do push requests to improve the collection. 10 | 11 | Disclaimer 12 | ========= 13 | 14 | I do not claim to own any of the data here. The sole aim of this repository is to gather data in one point. I am also not responsible 15 | for the correctness of the data in this repository. 16 | 17 | The Docs 18 | ======== 19 | 20 | Misc: 21 | - [How do I write an emulator?](http://www.atarihq.com/danb/files/emu_vol1.txt) 22 | 23 | General console: 24 | - [Pandocs - HTML](http://gbdev.gg8.se/files/docs/mirrors/pandocs.html) and [here](http://gbdev.gg8.se/wiki/articles/Pan_Docs) 25 | - [Everything You Always Wanted To Know About GAME BOY - but were afraid to ask](http://www.emulatronia.com/doctec/consolas/gameboy/gameboy.txt) 26 | - [Wiki with about everything about the gameboy](http://gbdev.gg8.se/wiki) 27 | - [Densily packed cheat sheet with informaiton on the workins of CPU, APU, DMA, memory map and lots of other stuff](http://gbdev.gg8.se/files/docs/GBCribSheet000129.pdf) 28 | - [The cycle-accurate Gameboy Docs](https://github.com/AntonioND/giibiiadvance/raw/master/docs/TCAGBD.pdf), a hardware based documentation of the gameboy. Part of an emulator available [here](https://github.com/AntonioND/giibiiadvance) 29 | - [Opcode table](http://goldencrystal.free.fr/GBZ80Opcodes.pdf) 30 | - [Pastraiser's gameboy opcode table](www.pastraiser.com/cpu/gameboy/gameboy_opcodes.html) 31 | - [Collection of files related to the gameboy](http://gbdev.gg8.se/files/). Contains test roms, documentation, schematics, tools etc 32 | - [Writing a Game Boy emulator, Cinoop](https://cturt.github.io/cinoop.html) 33 | - [Site about gameboy dev](http://www.devrs.com/gb/) 34 | - [Differences between the Z80 and the gameboy's processor](http://www.z80.info/z80gboy.txt) 35 | - [Pdf with a bunch of info on the gameboy](http://meatfighter.com/gameboy/TheNintendoGameboy.pdf). It is a compilation of various others documents 36 | - [Develloping a Gameboy Emulator with JavaScript](http://imrannazar.com/GameBoy-Emulation-in-JavaScript:-The-CPU) 37 | - [Page with loads of information on the actual hardware](http://verhoeven272.nl/fruttenboel/Gameboy/index.html) and some custom boards to interface with the console. Also a [link hub here](http://verhoeven272.nl/fruttenboel/Gameboy/GBlinks.html) 38 | - [Build log of gmb emulator](https://realboyemulator.wordpress.com/2013/01/01/the-nintendo-game-boy-1/) 39 | - [Opcode table with timings and flags](http://www.devrs.com/gb/files/opcodes.html) 40 | - [CodeSlinger's build log/tutorial](http://www.codeslinger.co.uk/pages/projects/gameboy.html) 41 | - [Emu-Docs page on the Game Boy](https://emu-docs.org/?page=Game%20Boy) 42 | 43 | Emulators: 44 | - [Wadatsumi, gameboy emulator in Rust, very accurate](https://github.com/mehcode/wadatsumi) 45 | - [Gekkio's WIP emulator, based on his research on real hardware](https://github.com/Gekkio/mooneye-gb) 46 | - [5kloc emulator in C that passes most of the tests](https://github.com/binji/binjgb) 47 | - [BGB, well know Closed Source emulator, accurate and with a builtin debugger](http://bgb.bircd.org/) 48 | - [Accurate gameboy emulator, open source](https://github.com/sinamas/gambatte) 49 | - [How to make a (gameboy) emulator?](https://www.cl.cam.ac.uk/~pv273/slides/emulation.pdf) 50 | 51 | Test Roms: 52 | - [The famous Blargg's test roms](http://gbdev.gg8.se/files/roms/blargg-gb-tests/) 53 | - [Gekkio's emulator and test roms(source code only)](https://github.com/Gekkio/mooneye-gb). More info [here](https://gekkio.fi/blog/2015-01-13-mooneye-gb-a-gameboy-emulator-written-in-rust.html), binary files [here](https://gekkio.fi/files/mooneye-gb/nightly/tests/) 54 | 55 | Timings: 56 | - [Nitty Gritty Gameboy Cycle Timing](http://blog.kevtris.org/blogfiles/Nitty%20Gritty%20Gameboy%20VRAM%20Timing.txt) 57 | - [Mode3 Sprite Timing](https://www.reddit.com/r/EmuDev/comments/59pawp/gb_mode3_sprite_timing/) 58 | - [GameBoy Color DMA-Transfers v0.0.1](http://gameboy.mongenel.com/dmg/gbc_dma_transfers.txt) 59 | - [STAT interrupt timings](https://gist.github.com/drhelius/33678a2389a5fd0fcaea71eb106dd16c), original [here](http://gameboy.mongenel.com/dmg/istat98.txt) 60 | 61 | Sound: 62 | - [Gameboy sound system - PAPU](https://emu-docs.org/Game%20Boy/gb_sound.txt) 63 | 64 | Information on games and cartridges: 65 | - [List of game names, size of RAM and ROM, region and cartridge type](http://www.ladecadence.net/trastero/listado%20juegos%20gameboy.html) 66 | - [Game Boy/Game Boy Color ROMs](http://merwanachibet.net/gameboy-roms.html) 67 | - [Game Boy hardware database](https://gbhwdb.gekkio.fi/cartridges/) 68 | 69 | Peripherals: 70 | - [Game Boy Camera documentation](http://antoniond_blog.drunkencoders.com/?p=382), by AntonioND and his [emulator](https://github.com/AntonioND/giibiiadvance) 71 | - [Ben Heck Reverse Engineers Game Boy Printer](https://www.youtube.com/watch?v=43FfJvd-YP4) 72 | -------------------------------------------------------------------------------- /Copy/Nitty Gritty Gameboy VRAM Timing.txt: -------------------------------------------------------------------------------- 1 | Nitty Gritty Gameboy Cycle Timing 2 | --------------------------------- 3 | 4 | 5 | A document about the down and dirty timing of the Gameboy's video hardware. 6 | 7 | Written by: Kevin Horton 8 | Version: 0.01 (preliminary) 9 | 10 | My findings here are based on the original DMG, Super Gameboy, and GB 11 | Pocket. All three appear to behave identically during testing, and the 12 | SGB was used for all the reverse engineering. 13 | 14 | An HP54645D mixed signal oscilloscope/logic analyzer was connected to the 15 | SGB using a 16 wire pod. A 20 pin ribbon cable with IDC plug on the end 16 | was soldered to various points on the SGB, and a pin header was inserted 17 | into the IDC plug so that the pod connectors could be plugged in to 18 | monitor the goings-on of the hardware. 19 | 20 | --- 21 | 22 | 23 | I have discovered some interesting things about how the Gameboy fetches 24 | VRAM data in general. First, it will actually stop clocking the LCD and 25 | stall it if it needs to fetch something and is not ready to send the 26 | data out quite yet. 27 | 28 | Secondly, the window function is a restarting of the data fetching 29 | state machine, which is used to read the background tiles. The window 30 | is triggered N clocks after the start of rendering, where N is determined 31 | by the value in the xwindow register. 32 | 33 | So, without further delay... 34 | 35 | Scanline timing 36 | --------------- 37 | 38 | During the discussion of scanline timing, I will be ignoring Y timing 39 | totally, since Y timing is unrelated to VRAM access patterns. The Y 40 | timing only affects WHICH KIND of VRAM access occurs, and does not 41 | affect it in any other way. 42 | 43 | There are a couple cases that will be discussed, from simplest to most 44 | complex. 45 | 46 | * * * * * 47 | 48 | The first case is what I call the degenerate case: xwindow is set to 0ffh 49 | which disables the window totally, and then xscroll is adjusted. 50 | 51 | There are only 8 different possible cases. 52 | 53 | These types of access take from 173.5 to 180.5 cycles. The reasoning for 54 | the half cycle will be described later. 55 | 56 | The access pattern looks like this: 57 | 58 | B01 - (6 cycles) fetch Background nametable byte, then 2 tile planes 59 | B01s - (167.5 + (xscroll % 7) cycles) fetch another tile and sprite 60 | window. 61 | 62 | Where: 63 | B = reading the background tile # (i.e. out of 1800h from the first 64 | nametable) 65 | 0,1 = where the tile graphics are fetched. bitplanes 0 and 1. 66 | s = sprite window. the sprite hardware will insert reads here if needed. 67 | 68 | Each access to VRAM (B, 0, 1, s) takes 2 cycles to occur. A "cycle" is 69 | exactly 1 period of the main input clock to the gameboy CPU chip. This 70 | is nominally 4.19MHz approximately. 71 | 72 | The last four accesses (B01s) is repeated until the proper number of 73 | cycles has elapsed. 74 | 75 | In the xscroll = 0 case, it will run for 167.5 cycles. This has an 76 | interesting side effect- any tile access that is not complete just 77 | gets unceremoniously cut off. This means that there will be 20 complete 78 | tile accesses (B01s) and then 7.5 clocks worth of a 21st access, 79 | cutting off the last half cycle of the sprite window. 80 | 81 | In the xscroll = 2 case, it will run for 169.5 cycles. Similar to above, 82 | this will result in 21 complete B01s accesses, and then 1.5 cycles of the 83 | B fetch on a 22nd access. 84 | 85 | This pattern repeats until xscroll = 7 (taking a total of 180.5 cycles) 86 | until snapping back to 173.5 cycles when xscroll = 8. 87 | 88 | The total number of cycles taken is (173.5 + (xscroll % 7)). 89 | 90 | Now, you have been wondering what this extra 1/2 cycle business is about. 91 | Well, it has to do with how the display clock is generated. The display 92 | clock is generated via inverting the main input clock. I suspect it was 93 | done so that the video hardware can get the data to the LCD ready on the 94 | falling edge of the main clock. The display clocks data in on the RISING 95 | edge of the display clock, thus necessitating the inverted display clock 96 | relative to the main clock. 97 | 98 | That causes the vram access pattern to be extended 1/2 clock on the end 99 | to accommodate the inverted clock. 100 | 101 | * * * * * 102 | 103 | So, that takes care of the easy case. Now for what happens when the 104 | window is used. 105 | 106 | NOTE: When xwindow = 00h or xwindow = 0a6h, different things happen. 107 | I will explain them later on. For now, the following information 108 | holds when ((xwindow > 00h) && (xwindow < 0a6h)). 109 | 110 | Interestingly, adding the window does not change a whole lot- in fact, 111 | it simply restarts the whole fetch sequence over again, no matter where 112 | it was! The timing is generated like so: 113 | 114 | B01 (6 cycles) fetch background tile nametable+bitplanes 115 | B01_ (1 to 172 cycles) ((xscroll % 7) + xwindow + 1) 116 | W01 (6 cycles) fetch window tile nametable+bitplanes 117 | W01_ (1.5 to 166.5 cycles) (166.5 - xwindow) 118 | 119 | As can be seen, it's very similar to the first case. Only now, 120 | the number of B12_ accesses is controlled by the xscroll value 121 | and the xwindow value. As before, when the number of cycles has 122 | elapsed, the access pattern is just cut short, and the W12 (W = window 123 | nametable entry) access starts. 124 | 125 | This window access pattern is identical to the background one, except 126 | the window nametable is being accessed instead. 127 | 128 | Turning on the window incurs a 6 cycle penalty, so the total number of 129 | cycles taken is (173.5 + 6 + (xscroll % 7)). 130 | 131 | * * * * * 132 | 133 | OK, now things get slightly strange. When xwindow = 0, some slightly 134 | different rules come into effect. 135 | 136 | When (xscroll % 7) = 0 to 6, things work a bit different. Timing 137 | looks like this: 138 | 139 | B01B (7 cycles) technically the last B is part of the B01s pattern. 140 | W01 (6 cycles) as above, the start of the window access pattern 141 | W01s (167.5 to 173.5 cycles) (167.5 + (scroll % 7)) 142 | 143 | As before, the W01s pattern is repeated for the required number of 144 | cycles. When the count has expired, the access pattern is just cut off. 145 | 146 | This takes 180.5 to 186.5 cycles. 147 | 148 | When (xscroll % 7) = 7, then the timing is slightly modified version 149 | of the above. The access pattern is identical to when (xscroll % 7) = 6 150 | except an extra cycle is inserted in the first sprite window, causing 151 | the total amount to be 187.5 cycles. 152 | 153 | * * * * * 154 | 155 | When xwindow = 0a6h, then timing is identical to when the window is 156 | disabled, i.e. 173.5 to 180.5 cycles. The difference is the window 157 | nametable is used instead of the background nametable. Rendering 158 | starts from the SECOND tile of each line, however. The net effect of 159 | this is, the window register appears to be scrolled 8 pixels to the right 160 | (if xscroll = 0). 161 | 162 | Only the lower 3 bits of the xscroll register are used in this mode. 163 | It shifts the the window left 0-7 cycles. Taking into account the first 164 | paragraph above about the nametable, the net effect is the window appears 165 | to be xscrolled 8 to 15 pixels left. 166 | 167 | Effective xscroll = (xscroll % 7) + 8 168 | 169 | The top scanline of the screen is ALWAYS reflecting the very first 170 | scanline of the window, when ywindow is less than or equal to 08fh. 171 | 172 | The second scanline of the screen will reflect the second scanline of 173 | the window, but ONLY when ywindow = 00h. Any other ywindow value will 174 | result in the background showing for the first scanline. 175 | 176 | The other scanlines of the screen (lines 3-144) will show the window, 177 | *starting from the third window scanline* depending on the ywindow value. 178 | 179 | This is hard to describe, but the effect is simple: 180 | 181 | GB line: (ywindow = 0) 182 | 1 window 1 183 | 2 window 2 184 | 3 window 3 185 | 4 window 4 186 | 187 | GB line: (ywindow = 1) 188 | 1 window 1 189 | 2 background 2 190 | 3 window 3 191 | 4 window 4 192 | 193 | GB line: (ywindow = 2) 194 | 1 window 1 195 | 2 background 2 196 | 3 background 3 197 | 4 window 3 198 | 5 window 4 199 | 6 window 5 200 | 201 | GB line: (ywindow = 3) 202 | 1 window 1 203 | 2 background 2 204 | 3 background 3 205 | 4 background 4 206 | 5 window 3 207 | 6 window 4 208 | 209 | ---- 210 | 211 | 212 | What addresses are read during rendering 213 | ---------------------------------------- 214 | 215 | Referring back to the fetch patterns above, I will go through what 216 | addresses are read. 217 | 218 | For the degenerate case, the access pattern looks like this: 219 | 220 | B01 221 | B01s (repeated 20-22x) 222 | 223 | Assuming that xscroll = 0, and yscroll = 0, and we have the background 224 | reading the 9800h nametable: 225 | 226 | B01 (reads 9800h) 227 | B01s (reads 9800h, 9801h, 9802h, 9803h...9814h) 228 | 229 | This is fairly simple: it just starts at the very upper left char of the 230 | nametable and starts reading. It ends up reading 9800h TWICE. The 231 | first access is just thrown away and is never used. It's here, because 232 | it helps during windowing (I will describe later in the window section). 233 | 234 | The way the characters are read is performed something like this: 235 | 236 | At the start of the scanline: 237 | 238 | 1) latch the current character address 239 | 2) read a character from the address 240 | 3) read another character from the SAME address 241 | 4) increment address 242 | 5) read another character 243 | 6) repeat 4 and 5 20-22 times. 244 | 245 | In step 1, the address we latch is calculated like this: 246 | 247 | yscroll is the yscroll register on the GB CPU 248 | xscroll is the xscroll register on the GB CPU 249 | ycounter is the current scanline we are rendering (0-143) 250 | whichnt is bit 3 of the LCD control reg on the GB CPU 251 | 252 | ybase = (yscroll + ycounter) // calculates the effective vis. scanline 253 | 254 | charaddr = (0x9800 | (whichnt << 10) | ((ybase & 0xf8) << 2) | 255 | ((xscroll & 0xf8) >> 3) 256 | 257 | Another way to represent this address: 258 | 259 | 15 0 260 | ------------------- 261 | 1001 1NYY YYYX XXXX 262 | 263 | N = nametable # 264 | Y = upper 5 bits of ybase 265 | X = upper 5 bits of xscroll (which is then incremented between chars) 266 | 267 | 268 | In step 2, we read from charaddr, and throw the result away 269 | In step 3, we read from charaddr again and use it for the first vis. char 270 | In step 4, *only the lower 5 bits* of charaddr is incremented 271 | In step 5, we read the next character 272 | 273 | Then, we repeat it enough times to fill out the scanline. 274 | 275 | Once the nametable entry is fetched, we have to fetch the tile planes. 276 | 277 | Depending on the state of the "BG & Window Tile Data Select" register, 278 | which is LCD control bit 4, tile accesses are done one of two ways. 279 | 280 | 281 | ntbyte = the nametable byte we read from the above NT address. 282 | 283 | if (lcdcontrol[4]) tileaddr = (ntbyte << 4) | ((ysub & 0x7) << 1) 284 | else tileaddr = (0x1000 - (ntbyte << 4)) | ((ysub & 0x7) << 1) 285 | 286 | We will read the desired bytes for the tile data from tileaddr and 287 | tileaddr+1 288 | 289 | Notice that xscroll's lower 3 bits don't SEEM to play into any of the 290 | calculations above... this is because xscroll[2:0] does not affect 291 | which characters are fetched in any way. Fine xscroll (lower 3 bits 292 | of xscroll) only adjust the timing during LCD writing (explained 293 | below). 294 | 295 | 296 | * * * * * 297 | 298 | So, this is all fine and good.. but what happens during windowing? 299 | It's not much different than the above. 300 | 301 | During a typical VRAM access pattern with the window, it looks something 302 | like this: 303 | 304 | B01 305 | B01s (repeated N times) 306 | W01 307 | W01s (repeated M times) 308 | 309 | The background rendering sequence is identical to the background only 310 | sequence described previously. 311 | 312 | When the window accesses start, the address calculation is similar... 313 | 314 | First, a typical reading sequence: 315 | 316 | B01 (9800h) 317 | B01s (9800h, 9801h, 9802h, ...) 318 | W01 (9C00h) 319 | W01s (9C01h, 9C02h, ...) 320 | 321 | The first change is that the first W01 access is NOT thrown away. 322 | There is no duplicated read here as in the background read. 323 | 324 | The nametable read is calculated like so: 325 | 326 | windnt = the window nametable (LCD control bit 6) 327 | 328 | basew = (ycount - yscroll) // calculates the effective window scanline 329 | 330 | charaddr = (0x9800 | (windnt << 10) | ((basew & 0xf8) << 2) 331 | 332 | Another way to represent this address: 333 | 334 | 15 0 335 | ------------------- 336 | 1001 1NYY YYY0 0000 337 | 338 | N = nametable # 339 | Y = upper 5 bits of basew 340 | 341 | 342 | We simply read characters starting from the charaddr address, and 343 | increment it each time we read a character until the scanline is 344 | finished. 345 | 346 | The tile plane address is calculated the same as it is calculated for 347 | the background reads. 348 | 349 | 350 | That wraps up the actual VRAM access patterns. 351 | 352 | --- 353 | 354 | LCD write timing 355 | ---------------- 356 | 357 | Before I can describe how the LCD timing works, I have to first explain 358 | how the LCD itself works. 359 | 360 | The LCD is composed of a 2 bit wide by 159 bit deep shift register, 361 | where the input pixels are shifted. Each rising edge of the display 362 | clock, data is shifted one stage down the register. 363 | 364 | When the display latch signal is activated, this shift register's value 365 | is latched into the LCD column drivers. 366 | 367 | The shift register is only 159 bits- the input data is used as the 160th 368 | bit for latching into the LCD column drivers. 369 | 370 | * The first pixel shifted into the register appears on the first column 371 | * The last pixel shifted in appears on the second to last column 372 | * The input pixel data on the input lines appears on the first column 373 | 374 | Terrible ASCII: 375 | 376 | 377 | DCLK: the display pixel clock 378 | data0/1: the 2 bit pixel data 379 | lat: the latch signal. when pulsed, latches the shift reg. data 380 | bias: the LCD bias voltage (contrast wheel adjusts this) 381 | inv: the LCD inverse signal (explained later) 382 | 383 | 384 | +-----------------+ 385 | LCD DCLK o-------|CLK | 386 | | | 387 | | 159*2 bit S/R | 388 | LCD data0 o---*--|D0 | 389 | LCD data1 o-*-+--|D1 | 390 | | | | pix 1 -> 159 | 391 | | | +-----------------+ 392 | | | | ........... | 393 | +--------------------------+ 394 | | pix 0 pix 1 -> 159 | 395 | | | 396 | LCD lat o-|latch 160*2 bit latch | 397 | | | 398 | | 160*2 outputs | 399 | +--------------------------+ 400 | | .................... | 401 | +--------------------------+ 402 | | | 403 | | 160 output drivers | 404 | LCDbias o-|bias | 405 | LCD inv o-|invert | 406 | | | 407 | | LCD outputs | 408 | +--------------------------+ 409 | |||||||||||||||||||||||| 410 | +---------------------------------+ 411 | | col 159 <- col 0 | 412 | | LCD columns | 413 | | | 414 | | | 415 | | LCD display | 416 | | | 417 | | | 418 | | | 419 | | | 420 | | | 421 | +---------------------------------+ 422 | 423 | 424 | So now that the LCD column driving and latching has been explained, 425 | the display timing that follows should make a bit more sense. 426 | 427 | Because the LCD is clocked, unlike a CRT, this means that the hardware 428 | has the ability to stop clocking the LCD for awhile if it feels like it. 429 | The GB video hardware indeed does do this, and even uses it to advantage 430 | during scrolling, sprite fetching, and starting the window rendering. 431 | 432 | When windowing is disabled, the display clock always runs for the last 433 | 159 cycles. This is very interesting to me, because that means the 434 | video hardware is actively shifting pixels out to the display, but 435 | some of these pixels DO NOT HAVE A CORRESPONDING DCLK! This is how 436 | fine X scroll is achieved- the first 0 to 7 pixels are just thrown away. 437 | They get shifted out, but since the display clock is not running, they 438 | do not get shifted in. By delaying these cycles, the display data will 439 | shift left from 0 to 7 pixels. 440 | 441 | The windowing function works the same way- the pixel where the window 442 | is started will restart the rendering engine and thus allow single pixel 443 | precision on where the window starts on the LCD. 444 | 445 | During the first 6 cycles of the window fetch, the LCD clock is stalled. 446 | This lets the pipeline fill and then display clocking resumes after the 447 | 6 cycle delay. 448 | 449 | That takes care of the timing of display data clocking. 450 | 451 | Now for the interesting part about how data is read and shifted out the 452 | LCD data pins: 453 | 454 | When the nametable fetch starts, the LAST tile data read will be latched 455 | into two 8 bit shift registers, and then shift out the data pins one 456 | pixel per clock. No matter what. 457 | 458 | So, referring to the access pattern again: 459 | 460 | B01 read the first tile 461 | B01s latch the pixel data into the output shift registers 462 | B01s latch the pixel data into the output shift registers 463 | B01s... 464 | 465 | Since each B01s access takes exactly 8 cycles, the output shift registers 466 | will be exactly refilled when they are empty, and continue the output 467 | data sending without interruption. 468 | 469 | Fine xscroll is effected by controlling the point in this process where 470 | the display clocking is started relative to the start of the rendering 471 | phase. The data will always shift out the pixel data pins at the same 472 | point in the render cycle, but since the DCLK is started earlier or 473 | later, the point where the LCD starts latching data changes relative to 474 | the data. This causes a 0-7 shift in the data on the LCD. 475 | 476 | The afore-mentioned output shift registers will blindly shift out their 477 | 8 pixels of data without stopping, except when the LCD hardware is 478 | stalled by a sprite fetch (described later). Thus, the timing of the 479 | VRAM reads determines the amount of fine xscroll on the background 480 | and on the window. 481 | 482 | --- 483 | -------------------------------------------------------------------------------- /Copy/gameboy.txt: -------------------------------------------------------------------------------- 1 | 2 | 3 | ============================================================================== 4 | Everything You Always Wanted To Know About GAME BOY * 5 | ============================================================================== 6 | 7 | * but were afraid to ask 8 | 9 | 10 | Written by Dr. -Pan-/Anthrox 11 | 12 | Forward: The following was typed up for informational purposes regarding 13 | the inner workings on the hand-held game machine known as 14 | Game Boy, manufactured and designed by Nintendo Co., LTD. 15 | All files found in this package are presented to inform 16 | a user on how their Game Boy works and what makes it "tick". 17 | Game Boy is copyrighted by Nintendo Co., LTD. 18 | Any reference to copyrighted material is not presented 19 | for monetary gain, but for educational purposes and higher 20 | learning. 21 | 22 | 23 | If you do not ask, you will not know - -Pan-/ATX 24 | No askie, no learnie - someone must've said this... 25 | 26 | 1. What are the Game Boy's true specs? 27 | ----------------------------------- 28 | 29 | The Game Boy really is a powerful machine! FAQ files on Game Boy can be 30 | found on many Internet sites. Most FAQs contains wrong information. 31 | Such as claiming it only has 8 sprites. Here are the correct facts: 32 | 33 | The Game Boy uses a custom/updated/or modified Z80 processor. Comparing 34 | the Game Boy's Z80 instruction set with a book on the Z80 (circa 1982) 35 | shows that the GB Z80 has a few different instructions. Such as 36 | LD (HLI),#$xx 37 | LD (HLD),#$xx 38 | SWAP A through L 39 | LD A,($xx) 40 | 41 | Screen Size: Physical screen: 160*144 VRAM screen image: 256*256 42 | Screen scrolling is wrap around type; when a part of the image is off the 43 | screen it will be shown on the opposite side of the screen. 44 | 45 | Although the screen can contain 1024 tiles, only 256 of them may be UNIQUE. 46 | Each tile may have up to 4 colors. You may change the color of the pixel 47 | value. There are 4 shades of gray. You can select which shade you want 48 | for that pixel value. However, when you change the color for that pixel value 49 | EVERY tile that has a pixel with the same value will also be affected. 50 | This is good for a routine which fades out the screen or performs a GLOWING 51 | effect of some kind. 52 | The tile graphics are 8*8 pixels, each pixel contains 2 bits of data to 53 | create 4 numbers. Each number is the color value for that pixel. 54 | The graphics are stored as as bitmapped tiles much like the SNES. 55 | This is the confusing part for me. It is either like the 56 | 4 color SNES tile or it is INTERLEAVED. 57 | 58 | SNES 4 Color Tile: A INTERLEAVED 4 Color Tile: A 59 | 60 | .11111.. .11111.. <- first plane 61 | 11...11. ........ <- second plane 62 | 11...11. 11...11. 63 | 1111111. <- first plane ........ 64 | 11...11. 11...11. 65 | 11...11. ........ 66 | 11...11. 1111111. <- first plane 67 | ........ ........ <- second plane 68 | 69 | ........ 11...11. 70 | ........ ........ 71 | ........ 11...11. 72 | ........ ........ 73 | ........ <- second plane 11...11. 74 | ........ ........ 75 | ........ ........ 76 | ........ ........ 77 | 78 | You'll have to figure it out by yourself since I haven't gotten into it :) 79 | 80 | Graphics vram location for OBJ and BG tiles start at $8000 and end at $97FF 81 | 82 | 83 | 84 | Sprites: 40 Sprites! They may be 8*8 or 8*16. 85 | 86 | Each sprite has up to 4 colors. There are 2 palettes to chose from 87 | 88 | The sprites can be flipped on the X and/or Y axis 89 | 90 | Sprite OAM ram: Location: $FE00->$FE9F 91 | 92 | Each sprite data contains 4 bytes of info. They are: 93 | 94 | Byte 1: Y screen position; 8 bits 95 | Byte 2: X screen position; 8 bits 96 | Byte 3: Character code; tile number $00-$FF 97 | Byte 4: Palette, X, Y, Priority; Most Significant 4 bits. 98 | First 4 bits are NOT USED! 99 | 100 | Bit 7 - Priority 101 | Bit 6 - Y flip 102 | Bit 5 - X flip 103 | Bit 4 - Palette number; 0,1 104 | Bit 3-0 - NOT USED! 105 | 106 | Display Ram size: 64k bit 107 | Work Ram size: 64k bit 108 | 109 | There are 2 Memory Bank Controllers (MBC) that can be used. MBC1 is the 110 | standard that is used on most cartridges. 111 | MBC2 is used with cartridges which need Save-Ram. 112 | It controls extended Save-RAM banks. 113 | 114 | Extended Ram may go up to 256k bit. 115 | 116 | MBC1 - When controlling ROM only you may read up to 16 megabits! (2 MBYTES) 117 | When controlling RAM only you may read up to 4 megabits (512 kbytes) 118 | and read up to 256kbit RAM 119 | 120 | MBC2 - Controls Back-Up Ram (Save-RAM) (512 * 4 bit) which can be extended 121 | to 2 megabits (16 kbyte * 16) 256k byte 122 | 123 | Sound: There are only 2 channels; left and right. 124 | But there are 4 different ways to produce sound: 125 | Sound 1: produces quadrangular wave patterns with sweep and envelope 126 | functions 127 | Sound 2: produces quadrangular wave patterns with envelope functions 128 | Sound 3: produces a voluntary wave pattern (samples can be possible 129 | if done right) 130 | Sound 4: produces white noise 131 | 132 | You tell the channel which sound number you want to use and it 133 | will produce the sound when you've set the according data. 134 | 135 | Since I'm not a sound programmer I really can't get into the details 136 | of how to create waves patterns and such. It would confuse you more 137 | than me! 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 2. The Game Boy seems like a nice little system! But what are the registers? 150 | And what about the memory mapping? 151 | ------------------------------------------------------------------------- 152 | 153 | You can check out the memory mapping by viewing the 2 graphic diagrams 154 | included with this informational tutorial. They are called: 155 | Address1.IFF, Address1.PCX, Address2.IFF, Address2.PCX 156 | 157 | .IFF is for Amiga users. .PCX is for PC users. 158 | 159 | They will display how the memory is mapped out and how banking works. 160 | 161 | 162 | The registers: 163 | 164 | ------------------------------------------------------------------------------ 165 | Address - $FF00 166 | Name - P1 167 | Contents - Register for reading joy pad info. (R/W) 168 | 169 | Bit 7 - Not used 170 | Bit 6 - Not used 171 | Bit 5 - P15 out port 172 | Bit 4 - P14 out port 173 | Bit 3 - P13 in port 174 | Bit 2 - P12 in port 175 | Bit 1 - P11 in port 176 | Bit 0 - P10 in port 177 | 178 | This is a very strange way of reading joypad info. 179 | There are only 8 possible button/switches on the Game Boy. 180 | A, B, Select, Start, Up, Down, Left, Right. 181 | Why they made their joypad registers in this way I'll never know. 182 | They could have used all 8 bits and you just read which one is on. 183 | 184 | This is the matrix layout for register $FF00: 185 | 186 | 187 | P14 P15 188 | | | 189 | --P10-------O-Right------------O-A--------- 190 | | | 191 | --P11-------O-Left-------------O-B--------- 192 | | | 193 | --P12-------O-Up---------------O-Select---- 194 | | | 195 | --P13-------O-Down-------------O-Start----- 196 | | | 197 | 198 | 199 | This is the logic in reading joy pad data: 200 | 201 | Turn on P15 (bit 5) in $ff00 202 | Wait a few clock cycles 203 | read $ff00 into A 204 | invert A - same as EOR #$FF - just reverse all bits 205 | apparently the joy pad info returned is like the C64 206 | info. 0 means on, 1 means off. But logic tells us 207 | that it should be the other way around. So to make it 208 | less confusing we just flip the bits! 209 | 210 | AND A with #$0F - get only the first four bits 211 | By turning on P15 we are trying to read column 212 | P15 in the matrix layout. It contains A,B,SEL,STRT 213 | 214 | SWAP A - #$3f becomes #$f3, it swaps hi<->lo nibbles 215 | 216 | store A in B for backup 217 | 218 | 219 | Turn on P14 (bit 4) in $ff00 220 | Wait a few more clock cycles 221 | read $ff00 into A 222 | invert A - just as above 223 | AND A with #$0F - get first 4 bits 224 | - By turning on P14 we get the data for column P14 225 | in the matrix layout. It contains U,D,L,R 226 | 227 | OR A with B - put the two values together. 228 | 229 | turn on P14 and P15 in $ff00 to reset. 230 | 231 | The button values using the above method are such: 232 | $80 - Start $8 - Down 233 | $40 - Select $4 - Up 234 | $20 - B $2 - Left 235 | $10 - A $1 - Right 236 | 237 | Let's say we held down A, Start, and Up. 238 | The value returned in accumulator A would be $94 239 | 240 | 241 | Let's see this method in action! 242 | Game: Ms. Pacman 243 | Address: $3b1 244 | 245 | 0003B1: 0003B1: 3E 20 LD A,#$20 <- bit 5 = $20 246 | 0003B3: 0003B3: EA 00 FF LD ($FF00),A <- turn on P15 247 | 0003B6: 0003B6: FA 00 FF LD A,($FF00) 248 | 0003B9: 0003B9: FA 00 FF LD A,($FF00) <- wait a few cycles 249 | 0003BC: 0003BC: 2F CPL <- complement (invert) EOR #$ff 250 | 0003BD: 0003BD: E6 0F AND #$0F <- get only first 4 bits 251 | 0003BF: 0003BF: CB 37 SWAP A <- swap it 252 | 0003C1: 0003C1: 47 LD B,A <- store A in B 253 | 0003C2: 0003C2: 3E 10 LD A,#$10 <- bit 4 = $10 254 | 0003C4: 0003C4: EA 00 FF LD ($FF00),A <- turn on P14 255 | 0003C7: 0003C7: FA 00 FF LD A,($FF00) 256 | 0003CA: 0003CA: FA 00 FF LD A,($FF00) 257 | 0003CD: 0003CD: FA 00 FF LD A,($FF00) 258 | 0003D0: 0003D0: FA 00 FF LD A,($FF00) 259 | 0003D3: 0003D3: FA 00 FF LD A,($FF00) 260 | 0003D6: 0003D6: FA 00 FF LD A,($FF00) <- Wait a few MORE cycles 261 | 0003D9: 0003D9: 2F CPL <- complement (invert) 262 | 0003DA: 0003DA: E6 0F AND #$0F <- get first 4 bits 263 | 0003DC: 0003DC: B0 OR B <- put A and B together 264 | 265 | 266 | The following routine is common on SNES as well. It clarifies that you've 267 | only pressed the specified button(s) once every other frame. That way the 268 | Joypad is less sensitive to wrong/bad/false movements. 269 | 270 | 0003DD: 0003DD: 57 LD D,A <- store A in D 271 | 0003DE: 0003DE: FA 8B FF LD A,($FF8B) <- read old joy data from ram 272 | 0003E1: 0003E1: AA XOR D <- toggle w/current button bit 273 | 0003E2: 0003E2: A2 AND D <- get current button bit back 274 | 0003E3: 0003E3: EA 8C FF LD ($FF8C),A <- save in new Joydata storage 275 | 0003E6: 0003E6: 7A LD A,D <- put original value in A 276 | 0003E7: 0003E7: EA 8B FF LD ($FF8B),A <- store it as old joy data 277 | 278 | 279 | 280 | 0003EA: 0003EA: 3E 30 LD A,#$30 <- turn on P14 and P15 281 | 0003EC: 0003EC: EA 00 FF LD ($FF00),A <- RESET Joypad?! 282 | 0003EF: 0003EF: C9 RET <- Return from Subroutine 283 | 284 | ------------------------------------------------------------------------------ 285 | 286 | Address - $FF01 287 | Name - SB 288 | Contents - Serial transfer data (R/W) 289 | 290 | 8 Bits of data to be read/written 291 | 292 | Address - $FF02 293 | Name - SC 294 | Contents - SIO control (R/W) 295 | 296 | Bit 7 - Transfer start flag 297 | 0: Non transfer 298 | 1: Start transfer 299 | 300 | Bit 0 - Shift Clock 301 | 0: External Clock 302 | 1: Internal Clock 303 | 304 | ------------------------------------------------------------------------------ 305 | 306 | Address - $FF04 307 | Name - DIV 308 | Contents - Divider Register (R/W) 309 | 310 | ------------------------------------------------------------------------------ 311 | 312 | Address - $FF05 313 | Name - TIMA 314 | Contents - Timer counter (R/W) 315 | 316 | The timer generates an interrupt when it overflows. 317 | 318 | Address - $FF06 319 | Name - TMA 320 | Contents - Timer Modulo (R/W) 321 | 322 | When the TIMA overflows, this data will be loaded. 323 | 324 | Address - $FF07 325 | Name - TAC 326 | Contents - Timer Control 327 | 328 | Bit 2 - Timer Stop 329 | 0: Stop Timer 330 | 1: Start Timer 331 | 332 | Bits 1+0 - Input Clock Select 333 | 00: 4.096 khz 334 | 01: 262.144 khz 335 | 10: 65.536 khz 336 | 11: 16.384 khz 337 | 338 | ------------------------------------------------------------------------------ 339 | 340 | Address - $FF0F 341 | Name - IF 342 | Contents - Interrupt Flag (R/W) 343 | 344 | Bit 4: Transition from High to Low of Pin number P10-P13 345 | Bit 3: Serial I/O transfer end 346 | Bit 2: Timer Overflow 347 | Bit 1: LCDC (see STAT) 348 | Bit 0: V-Blank 349 | 350 | Address - $FFFF 351 | Name - IE 352 | Contents - Interrupt Enable (R/W) 353 | 354 | Bit 4: Transition from High to Low of Pin number P10-P13 355 | Bit 3: Serial I/O transfer end 356 | Bit 2: Timer Overflow 357 | Bit 1: LCDC (see STAT) 358 | Bit 0: V-Blank 359 | 360 | 0: disable 361 | 1: enable 362 | 363 | Address - XXXX (CPU instruction command) 364 | Name - IME 365 | Content - Interrupt Master Enable 366 | 367 | To prohibit ALL interrupts use CPU instruction DI 368 | To acknowledge interrupt settings use CPU instruction EI 369 | DI - Disable Interrupts 370 | EI - Enable Interrupts 371 | 372 | The priority and jump address for the above 5 interrupts are: 373 | 374 | Interrupt Priority Start Address 375 | 376 | V-Blank 1 $0040 377 | LCDC Status 2 $0048 - Modes 0, 01, 10 378 | LYC=LY coincide (selectable) 379 | 380 | Timer Overflow 3 $0050 381 | Serial Transfer 4 $0058 - when transfer is complete 382 | Hi-Lo Of Pin 5 $0060 383 | 384 | * When more than 1 interrupts occur at the same time ONLY the interrupt 385 | with the highest priority can be acknowledged. 386 | When an interrupt is used a '0' should be stored in the IF register 387 | before the IE register is set. 388 | 389 | 390 | ----------------------------------------------------------------------------- 391 | 392 | Address - $FF40 393 | Name - LCDC 394 | Contents - LCD Control (R/W) 395 | 396 | Bit 7 - LCD Control Operation 397 | 0: Stop completely (no picture on screen) 398 | 1: operation 399 | 400 | Bit 6 - Window Screen Display Data Select 401 | 0: $9800-$9BFF 402 | 1: $9C00-$9FFF 403 | 404 | Bit 5 - Window Display 405 | 0: off 406 | 1: on 407 | 408 | Bit 4 - BG Character Data Select 409 | 0: $8800-$97FF 410 | 1: $8000-$8FFF <- Same area as OBJ 411 | 412 | Bit 3 - BG Screen Display Data Select 413 | 0: $9800-$9BFF 414 | 1: $9C00-$9FFF 415 | 416 | Bit 2 - OBJ Construction 417 | 0: 8*8 418 | 1: 8*16 419 | 420 | Bit 1 - OBJ Display 421 | 0: off 422 | 1: on 423 | 424 | Bit 0 - BG Display 425 | 0: off 426 | 1: on 427 | 428 | 429 | Address - $FF41 430 | Name - STAT 431 | Contents - LCDC Status (R/W) 432 | 433 | Bits 6-3 - Interrupt Selection By LCDC Status 434 | 435 | Bit 6 - LYC=LY Coincidence (Selectable) 436 | Bit 5 - Mode 10 437 | Bit 4 - Mode 01 438 | Bit 3 - Mode 00 439 | 0: Non Selection 440 | 1: Selection 441 | 442 | Bit 2 - Coincidence Flag 443 | 0: LYC not equal to LCDC LY 444 | 1: LYC = LCDC LY 445 | 446 | Bit 1-0 - Mode Flag 447 | 00: Entire Display Ram can be accessed 448 | 01: During V-Blank 449 | 10: During Searching OAM-RAM 450 | 11: During Transfering Data to LCD Driver 451 | 452 | 453 | STAT shows the current status of the LCD controller. 454 | Mode 00: When the flag is 00 it is the H-Blank period and the CPU can 455 | access the display RAM ($8000-$9FFF) 456 | When it is not equal the display ram is being used by the 457 | LCD controller 458 | 459 | Mode 01: When the flag is 01 it is the V-Blank period and the CPU can 460 | access the display RAM ($800-$9FFF) 461 | 462 | Mode 10: When the flag is 10 then the OAM is being used ($FE00-$FE90) 463 | The CPU cannot access the OAM during this period 464 | 465 | Mode 11: When the flag is 11 both the OAM and CPU are being used. 466 | The CPU cannot access either during this period 467 | 468 | ----------------------------------------------------------------------------- 469 | 470 | Address - $FF42 471 | Name - SCY 472 | Contents - Scroll Y (R/W) 473 | 474 | 8 Bit value $00-$FF to scroll BG Y screen position 475 | 476 | Address - $FF43 477 | Name - SCX 478 | Contents - Scroll X (R/W) 479 | 480 | 8 Bit value $00-$FF to scroll BG X screen position 481 | 482 | Address - $FF44 483 | Name - LY 484 | Contents - LCDC Y-Coordinate (R) 485 | 486 | The LY indicates the vertical line to which the present data 487 | is transferred to the LCD Driver 488 | The LY can take on any value between 0 through 153. The values 489 | between 144 and 153 indicate the V-Blank period. Writing will 490 | reset the counter. 491 | 492 | This is just a RASTER register. The current line is thrown 493 | into here. But since there are no RASTERS on an LCD display..... 494 | it's called the LCDC Y-Coordinate. 495 | 496 | Address - $FF45 497 | Name - LYC 498 | Contents - LY Compare (R/W) 499 | 500 | The LYC compares itself with the LY. If the values are the same 501 | it causes the STAT to set the coincident flag. 502 | 503 | Address - $FF47 504 | Name - BGP 505 | Contents - BG Palette Data (W) 506 | 507 | Bit 7-6 - Data for Dot Data 11 508 | Bit 5-4 - Data for Dot Data 10 509 | Bit 3-2 - Data for Dot Data 01 510 | Bit 1-0 - Data for Dot Data 00 511 | 512 | This selects the shade of gray you what for your BG pixel. 513 | Since each pixel uses 2 bits, the corresponding shade will 514 | be selected from here. The Background Color (00) lies at 515 | Bits 1-0, just put a value from 0-$3 to change the color. 516 | 517 | Address - $FF48 518 | Name - OBP0 519 | Contents - Object Palette 0 Data (W) 520 | 521 | This selects the colors for sprite palette 0. 522 | It works exactly as BGP ($FF47). 523 | See BGP for details. 524 | 525 | Address - $FF49 526 | Name - OBP1 527 | Contents - Object Palette 1 Data (W) 528 | 529 | This Selects the colors for sprite palette 1. 530 | It works exactly as BGP ($FF47). 531 | See BGP for details. 532 | 533 | 534 | Address - $FF4A 535 | Name - WY 536 | Contents - Window Y Position (R/W) 537 | 538 | 0 <= WY <= 143 539 | 540 | WY must be greater than or equal to 0 and must be less than 541 | or equal to 143. 542 | 543 | Address - $FF4B 544 | Name - WX 545 | Contents - Window X Position (R/W) 546 | 547 | 7 <= WX <= 166 548 | 549 | WX must be greater than or equal to 7 and must be less than 550 | or equal to 166. 551 | 552 | 553 | Lets say WY = 80 and WX = 80. 554 | The window would be positioned as so: 555 | 556 | 0 80 159 557 | _________________________________________________ 558 | 0 | | | 559 | | | | 560 | | | | 561 | | | | 562 | | | | 563 | | | | 564 | | | | 565 | | | | 566 | | | | 567 | | |80 | 568 | 80 |-------------------+-----------------------------| 569 | | 80 | | 570 | | | | 571 | | | Window Display | 572 | | | | 573 | | | | 574 | | | Here | 575 | | | | 576 | | | | 577 | | | | 578 | 143 |___________________|_____________________________| 579 | 580 | 581 | OBJ Characters (Sprites) can still enter the window 582 | So can BG characters 583 | 584 | ----------------------------------------------------------------------------- 585 | 586 | Address - $FF46 587 | Name - DMA 588 | Contents - DMA Transfer and Start Address (W) 589 | 590 | The DMA Transfer (40*28 bit) from internal ROM or RAM ($0000-$F19F) 591 | to the OAM (address $FE00-$FE9F) can be performed. It takes 160 nano-seconds 592 | for the transfer. 593 | 594 | 40*28 bit = #140 or #$8C. As you can see, it only transfers $8C bytes 595 | of data. OAM data is $A0 bytes long, from $0-$9F. 596 | 597 | But if you examine the OAM data you see that 4 bits are not in use. 598 | 599 | 40*32 bit = #$A0, but since 4 bits for each OAM is not used it's 600 | 40*28 bit. 601 | 602 | It transfers all the OAM data to OAM RAM. 603 | 604 | The DMA transfer start address can be designated every $100 from address 605 | $0000-$F100. That means $0000, $0100, $0200, $0300.... 606 | 607 | Example program: 608 | DI <- Disable Interrupt 609 | LD A,#$04 <- transfer data from $0400 610 | LD ($FF46),A <- put A into DMA registers 611 | LD A,#40 <- #40 is the value to wait for. we need to wait 160 612 | Wait: <- nano seconds 613 | DEC A <- decrease A by 1 614 | JR NZ,Wait <- branch if Not Zero to Wait 615 | EI <- Enable Interrupt 616 | RET <- RETurn from sub-routine 617 | 618 | ----------------------------------------------------------------------------- 619 | 620 | Address - $FF10 621 | Name - NR 10 622 | Contents - Sound Mode 1 register, Sweep register (R/W) 623 | 624 | Bit 6-4 - Sweep Time 625 | Bit 3 - Sweep Increase/Decrease 626 | 0: Addition (frequency increases) 627 | 1: Subtraction (frequency increases) 628 | Bit 2-0 - Number of sweep shift (# 0-7) 629 | 630 | Sweep Time: 631 | 632 | 000: sweep off 633 | 001: 7.8 ms 634 | 010: 15.6 ms 635 | 011: 23.4 ms 636 | 100: 31.3 ms 637 | 101: 39.1 ms 638 | 110: 46.9 ms 639 | 111: 54.7 ms 640 | 641 | 642 | Address - $FF11 643 | Name - NR 11 644 | Contents - Sound Mode 1 register, Sound length/Wave pattern duty (R/W) 645 | 646 | Only Bits 7-6 can be read. 647 | 648 | Bit 7-6 - Wave Pattern Duty 649 | Bit 5-0 - Sound length data (# 0-63) 650 | 651 | Wave Duty: 652 | 653 | 00: 12.5% 654 | 01: 25% 655 | 10: 50% 656 | 11: 75% 657 | 658 | Address - $FF12 659 | Name - NR 12 660 | Contents - Sound Mode 1 register, Envelope (R/W) 661 | 662 | Bit 7-4 - Initial value of envelope 663 | Bit 3 - Envelope UP/DOWN 664 | 0: Decrease 665 | 1: Range of increase 666 | Bit 2-0 - Number of envelope sweep (# 0-7) 667 | 668 | Initial value of envelope is from %0000 to %1111 669 | 670 | Address - $FF13 671 | Name - NR 13 672 | Contents - Sound Mode 1 register, Frequency lo (W) 673 | 674 | lower 8 bits of 11 bit frequency. 675 | Next 3 bit or in NR 14 ($FF14) 676 | 677 | Address - $FF14 678 | Name - NR 14 679 | Contents - Sound Mode 1 register, Frequency hi (R/W) 680 | 681 | Only Bit 6 can be read. 682 | 683 | Bit 7 - Initial (when set, sound restarts) 684 | Bit 6 - Counter/consecutive selection 685 | Bit 2-0 - Frequency's higher 3 bits 686 | 687 | Address - $FF16 688 | Name - NR 21 689 | Contents - Sound Mode 2 register, Sound Length; Wave Pattern Duty (R/W) 690 | 691 | Only bits 7-6 can be read. 692 | 693 | Bit 7-6 - Wave pattern duty 694 | Bit 5-0 - Sound length (# 0-63) 695 | 696 | Address - $FF17 697 | Name - NR 22 698 | Contents - Sound Mode 2 register, envelope (R/W) 699 | 700 | Bit 7-4 - Initial envelope value 701 | Bit 3 - Envelope UP/DOWN 702 | 0: decrease 703 | 1: range of increase 704 | Bit 2-0 - Number of envelope step (# 0-7) 705 | 706 | 707 | Address - $FF18 708 | Name - NR 23 709 | Contents - Sound Mode 2 register, frequency lo data (W) 710 | 711 | Frequency's lower 8 bits of 11 bit data 712 | Next 3 bits are in NR 14 ($FF19) 713 | 714 | Address - $FF19 715 | Name - NR 24 716 | Contents - Sound Mode 2 register, frequency hi data (R/W) 717 | 718 | Only bit 6 can be read. 719 | 720 | Bit 7 - Initial 721 | Bit 6 - Counter/consecutive selection 722 | Bit 2-0 - Frequency's higher 3 bits 723 | 724 | Address - $FF1A 725 | Name - NR 30 726 | Contents - Sound Mode 3 register, Sound on/off (R/W) 727 | 728 | Only bit 7 can be read 729 | 730 | Bit 7 - Sound OFF 731 | 0: Sound 3 output stop 732 | 1: Sound 3 output OK 733 | 734 | Address - $FF1B 735 | Name - NR 31 736 | Contents - Sound Mode 3 register, sound length (R/W) 737 | 738 | Bit 7-0 - Sound length 739 | 740 | Address - $FF1C 741 | Name - NR 32 742 | Contents - Sound Mode 3 register, Select output level 743 | 744 | Only bits 6-5 can be read 745 | 746 | Bit 6-5 - Select output level 747 | 00: Mute 748 | 01: Produce Wave Pattern RAM Data as it is 749 | (4 bit length) 750 | 10: Produce Wave Pattern RAM data shifted once to the 751 | RIGHT (1/2) (4 bit length) 752 | 11: Produce Wave Pattern RAM data shifted twice to the 753 | RIGHt (1/4) (4 bit length) 754 | 755 | * - Wave Pattern RAM is located from $FF30-$FF3f 756 | 757 | Address - $FF1D 758 | Name - NR 33 759 | Contents - Sound Mode 3 register, frequency's lower data (W) 760 | 761 | Lower 8 bits of an 11 bit frequency 762 | 763 | Address - $FF1E 764 | Name - NR 34 765 | Contents - Sound Mode 3 register, frequency's higher data (R/W) 766 | 767 | Only bit 6 can be read. 768 | 769 | Bit 7 - Initial flag 770 | Bit 6 - Counter/consecutive flag 771 | Bit 2-0 - Frequency's higher 3 bits 772 | 773 | 774 | 775 | Address - $FF20 776 | Name - NR 41 777 | Contents - Sound Mode 4 register, sound length (R/W) 778 | 779 | Bit 5-0 - Sound length data (# 0-63) 780 | 781 | 782 | Address - $FF21 783 | Name - NR 42 784 | Contents - Sound Mode 4 register, envelope (R/W) 785 | 786 | Bit 7-4 - Initial value of envelope 787 | Bit 3 - Envelope UP/DOWN 788 | 0: decrease 789 | 1: range of increase 790 | Bit 2-0 - number of envelope step (# 0-7) 791 | 792 | Address - $FF22 793 | Name - NR 43 794 | Contents - Sound Mode 4 register, polynomial counter (R/W) 795 | 796 | Bit 7-4 - Selection of the shift clock frequency of the 797 | polynomial counter 798 | Bit 3 - Selection of the polynomial counter's step 799 | Bit 2-0 - Selection of the dividing ratio of frequencies 800 | 801 | Selection of the dividing ratio of frequencies: 802 | 000: f * 1/2^3 * 2 803 | 001: f * 1/2^3 * 1 804 | 010: f * 1/2^3 * 1/2 805 | 011: f * 1/2^3 * 1/3 806 | 100: f * 1/2^3 * 1/4 807 | 101: f * 1/2^3 * 1/5 808 | 110: f * 1/2^3 * 1/6 809 | 111: f * 1/2^3 * 1/7 f = 4.194304 Mhz 810 | 811 | Selection of the polynomial counter step: 812 | 0: 15 steps 813 | 1: 7 steps 814 | 815 | Selection of the shift clock frequency of the polynomial 816 | counter: 817 | 818 | 0000: dividing ratio of frequencies * 1/2 819 | 0001: dividing ratio of frequencies * 1/2^2 820 | 0010: dividing ratio of frequencies * 1/2^3 821 | 0011: dividing ratio of frequencies * 1/2^4 822 | : : 823 | : : 824 | : : 825 | 0101: dividing ratio of frequencies * 1/2^14 826 | 1110: prohibited code 827 | 1111: prohibited code 828 | 829 | Address - $FF30 830 | Name - NR 30 831 | Contents - Sound Mode 4 register, counter/consecutive; inital (R/W) 832 | 833 | Only bit 6 can be read. 834 | 835 | Bit 7 - Inital 836 | Bit 6 - Counter/consecutive selection 837 | 838 | 839 | Address - $FF24 840 | Name - NR 50 841 | Contents - Channel control / ON-OFF / Volume (R/W) 842 | 843 | Bit 7 - Vin->SO2 ON/OFF 844 | Bit 6-4 - SO2 output level (volume) (# 0-7) 845 | Bit 3 - Vin->SO1 ON/OFF 846 | Bit 2-0 - SO1 output level (volume) (# 0-7) 847 | 848 | Vin->SO1 (Vin->SO2) 849 | 850 | By synthesizing the sound from sound 1 through 4, the voice 851 | input from Vin terminal is put out. 852 | 0: no output 853 | 1: output OK 854 | 855 | Address - $FF25 856 | Name - NR 51 857 | Contents - Selection of Sound output terminal (R/W) 858 | 859 | Bit 7 - Output sound 4 to SO2 terminal 860 | Bit 6 - Output sound 3 to SO2 terminal 861 | Bit 5 - Output sound 2 to SO2 terminal 862 | Bit 4 - Output sound 1 to SO2 terminal 863 | Bit 3 - Output sound 4 to SO1 terminal 864 | Bit 2 - Output sound 3 to SO1 terminal 865 | Bit 1 - Output sound 2 to SO1 terminal 866 | Bit 0 - Output sound 0 to SO1 terminal 867 | 868 | Address - $FF26 869 | Name - NR 52 870 | Contents - Sound on/off (R/W) 871 | 872 | Only Bit 7, 3-0 can be read. 873 | 874 | Bit 7 - All sound on/off 875 | 0: stop all sound circuits 876 | 1: operate all sound circuits 877 | Bit 3 - Sound 4 ON flag 878 | Bit 2 - Sound 3 ON flag 879 | Bit 1 - Sound 2 ON flag 880 | Bit 0 - Sound 1 ON flag 881 | 882 | 883 | 884 | 885 | 886 | 887 | 888 | 889 | 890 | 891 | 892 | 893 | 3. Ok, so the Game Boy runs on a Z80, and that's an 8 bit processor... 894 | So how is it possible for an 8 bit processor to access 4 Mbits? 895 | ------------------------------------------------------------------- 896 | 897 | Simple! Bank switching! If you examine the graphic diagram Address1.xxx 898 | you will see some very strange stuff! 899 | 900 | The Z80 can only work with 16 bit addresses $0-$FFFF 901 | 902 | So to access the other data you must trick the machine into pointing 903 | to another piece of memory. 904 | 905 | ROM is located from $0000 - $7FFF, RAM is from $8000-$FFFF 906 | 907 | All game programs are ROM so we know it is from $0000-$7FFF 908 | 909 | But the Game Boy has a fixed memory area from $0000-$3FFF; when you 910 | access it, it will always be BANK 0. It is called the FIXED HOME ADDRESS. 911 | 912 | That means the only other ROM addresses available are $4000-$7FFF. 913 | 914 | Bank 0 is read by the CPU as being at $0000-$3FFF 915 | Bank 1 is read by the CPU as being at $4000-$7FFF 916 | Bank 2 is read by the CPU as being at $4000-$7FFF 917 | Bank 3 is read by the CPU as being at $4000-$7FFF 918 | 919 | See the pattern? Only the FIXED HOME ADDRESS has it's own special 920 | location. 921 | 922 | Banks and addresses starting at $4000 is called the CPU address. 923 | 924 | CPU Address $014000 is actually Bank #$01 address $4000 925 | 926 | CPU Address $014000 is equal to ROM address (offset) $004000 927 | 928 | CPU Address $024000 is equal to ROM address (offset) $008000 929 | 930 | CPU Address $044000 is equal to ROM address (offset) $010000 931 | 932 | The CPU uses the CPU ADDRESS. 933 | 934 | How to switch BANKS: 935 | 936 | Using MBC1 (Memory Bank Controller 1) 937 | 938 | Writing to ROM Address (CPU FIXED HOME ADDRESS) $2000-$3FFF 939 | the ROM bank can be selected. The values are from #$01-#$0F 940 | 941 | LD A,#$01 942 | LD ($2000),A <- this selects ROM BANK #$01 943 | 944 | 945 | Writing to ROM Address (CPU FIXED HOME ADDRESS) $4000-$5FFF 946 | the RAM bank can be selected. The values are from #$00-#$03 947 | 948 | LD A,#$03 949 | LD ($4000),A <- this select RAM BANK #$03 950 | 951 | Using MBC2 (Memory Bank Controller 2) 952 | 953 | Writing to ROM Address (CPU FIXED HOME ADDRESS) $2100-$21FF 954 | the ROM bank can be select. The values are from #$01-#$0F 955 | 956 | 957 | 958 | 959 | 960 | 961 | 962 | 4. The SNES and Genesis has an some cartridge information in the ROM. 963 | Does the Game Boy have some info, too? 964 | ------------------------------------------------------------------ 965 | 966 | Sure, why not?! 967 | 968 | The Internal Info block begins at $100 and it's format is as follows: 969 | 970 | $100-$101 - 00 C3 (2 bytes) 971 | $102-$102 - Lo Hi (Start Address for Game, usually $150 it would be written 972 | as 50 01) 973 | $100-$133 - Nintendo Character Area, if this does not exist the game 974 | will not run! 975 | 976 | 000100: 00 C3 50 01 CE ED 66 66 CC 0D 00 0B 03 73 00 83 977 | 000110: 00 0C 00 0D 00 08 11 1F 88 89 00 0E DC CC 6E E6 978 | 000120: DD DD D9 99 BB BB 67 63 6E 0E EC CC DD DC 99 9F 979 | 000130: BB B9 33 3E 980 | 981 | $134-$143 - Title Registration Area (title of the game in ASCII) 982 | $144-$146 - NOT USED 983 | $147 - CARTRIDGE TYPE 984 | 0 - ROM ONLY 985 | 1 - ROM+MBC1 986 | 2 - ROM+MBC1+RAM 987 | 3 - ROM+MBC1+RAM+BATTERY 988 | 5 - ROM+MBC2 989 | 6 - ROM+MBC2+BATTERY 990 | 991 | $148 - ROM SIZE 992 | 0 - 256kbit 993 | 1 - 512kbit 994 | 2 - 1M-Bit 995 | 3 - 2M-Bit 996 | 4 - 4M-Bit 997 | 998 | $149 - RAM SIZE 999 | 0 - NONE 1000 | 1 - 16kbit 1001 | 2 - 64kbit 1002 | 3 - 256kbit 1003 | 1004 | $14A-$14B - Maker Code - 2 bytes 1005 | $14C - Version Number 1006 | $14D - Complement Check 1007 | $14E-$14F - Checksum HI-LO (2 bytes in Big Endian format, high byte first) 1008 | 1009 | 1010 | 1011 | 1012 | 1013 | 1014 | 5. Are there any public development tools available for the Game Boy? 1015 | ------------------------------------------------------------------ 1016 | 1017 | I don't know of many Z80 cross-assemblers available, or if they support 1018 | instructions like SWAP A, or LD (HLI),A. 1019 | It could be possible to use a generic Z80 assembler and to write 1020 | the non-standard instructions by entering the op-code as a Declared Byte. 1021 | 1022 | The only publicly available disassembler I know of is the one I made 1023 | for the Amiga. It is included in a SNES 65816/SPC700 disassembler 1024 | and supports non-standard Z80 op-codes. The multi-processor disassembler 1025 | is called Super Magic Disassembler, it's current release version 1026 | is 1.4 and can be found on bulletin boards world-wide. 1027 | 1028 | 1029 | 1030 | 1031 | 1032 | 6. Are there any Game Boy Emulators available? 1033 | ------------------------------------------- 1034 | 1035 | NO! NO! NONONONO! The only SO-CALLED Emulator was on the AMIGA but was 1036 | a BIG FAKE! If you got it to work, it only played TETRIS. 1037 | It did NOT emulate a Game Boy. It was just a version of Tetris 1038 | played in a graphic rendition of a Game Boy. 1039 | According to some FAQ floating around the Emulator is called Toy-Boy 1040 | and it was made by Argonaut Software. Come on! Argonaut has 1 Amiga, 1041 | which was used for graphics.. but since they've gotten a Silicon Graphics 1042 | Workstation I highly doubt they use it anymore! 1043 | 1044 | 1045 | 1046 | 1047 | 1048 | 7. What about Super-Game Boy info? What are it's Specs? 1049 | ---------------------------------------------------- 1050 | 1051 | What am I, Master Brain of the World? I don't have info on everything! :) 1052 | 1053 | 1054 | 1055 | 1056 | 8. Wow! This was some cool info! Now I can sleep at night! 1057 | ------------------------------------------------------- 1058 | 1059 | Yeah! Now you can stop bugging me with all your questions! 1060 | 1061 | 1062 | 1063 | --------------------------------------------------------------------------------