+++ /dev/null
-<HTML><HEAD>\r
- <TITLE>Specifications</TITLE>\r
- <META NAME="GENERATOR" CONTENT="nocash XED2HTM converter">\r
-</HEAD><BODY bgcolor="#ffffff" text="#000000" link="#0033cc" vlink="#0033cc" alink="#0033cc">\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="pandocs"></A><FONT SIZE=+2> Pan Docs</FONT></TD></TR></TABLE><BR>\r
-<B>Overview<BR>\r
-</B><A HREF="#aboutthepandocs">About the Pan Docs</A><BR>\r
-<A HREF="#gameboytechnicaldata">Game Boy Technical Data</A><BR>\r
-<A HREF="#memorymap">Memory Map</A><BR>\r
-<BR>\r
-<B>I/O Ports<BR>\r
-</B><A HREF="#videodisplay">Video Display</A><BR>\r
-<A HREF="#soundcontroller">Sound Controller</A><BR>\r
-<A HREF="#joypadinput">Joypad Input</A><BR>\r
-<A HREF="#serialdatatransferlinkcable">Serial Data Transfer (Link Cable)</A><BR>\r
-<A HREF="#timeranddividerregisters">Timer and Divider Registers</A><BR>\r
-<A HREF="#interrupts">Interrupts</A><BR>\r
-<A HREF="#cgbregisters">CGB Registers</A><BR>\r
-<A HREF="#sgbfunctions">SGB Functions</A><BR>\r
-<BR>\r
-<B>CPU Specifications<BR>\r
-</B><A HREF="#cpuregistersandflags">CPU Registers and Flags</A><BR>\r
-<A HREF="#cpuinstructionset">CPU Instruction Set</A><BR>\r
-<A HREF="#cpucomparisionwithz80">CPU Comparision with Z80</A><BR>\r
-<BR>\r
-<B>Cartridges<BR>\r
-</B><A HREF="#thecartridgeheader">The Cartridge Header</A><BR>\r
-<A HREF="#memorybankcontrollers">Memory Bank Controllers</A><BR>\r
-<A HREF="#gamegeniesharkcheats">Gamegenie/Shark Cheats</A><BR>\r
-<BR>\r
-<B>Other<BR>\r
-</B><A HREF="#powerupsequence">Power Up Sequence</A><BR>\r
-<A HREF="#reducingpowerconsumption">Reducing Power Consumption</A><BR>\r
-<A HREF="#spriterambug">Sprite RAM Bug</A><BR>\r
-<A HREF="#externalconnectors">External Connectors</A><BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="aboutthepandocs"></A><FONT SIZE=+2> About the Pan Docs</FONT></TD></TR></TABLE><BR>\r
-<TABLE><TR><TD><PRE> =================================================================\r
- Everything You Always Wanted To Know About GAMEBOY *\r
- =================================================================\r
-</TD></TR></TABLE><BR>\r
-<TABLE><TR><TD><PRE> * but were afraid to ask\r
-</TD></TR></TABLE><BR>\r
-<TABLE><TR><TD><PRE> Pan of -ATX- Document Updated by contributions from:\r
- Marat Fayzullin, Pascal Felber, Paul Robson, Martin Korth\r
- CPU, SGB, CGB, AUX specs by Martin Korth\r
-</TD></TR></TABLE><BR>\r
-<TABLE><TR><TD><PRE> Last updated 10/2001 by nocash\r
- Previously updated 4-Mar-98 by kOOPa\r
-</TD></TR></TABLE><BR>\r
-<B>Forward<BR>\r
-</B>The following was typed up for informational purposes regarding the \r
-inner workings on the hand-held game machine known as GameBoy, \r
-manufactured and designed by Nintendo Co., LTD. This info is presented \r
-to inform a user on how their Game Boy works and what makes it "tick". \r
-GameBoy is copyrighted by Nintendo Co., LTD. Any reference to \r
-copyrighted material is not presented for monetary gain, but for \r
-educational purposes and higher learning.<BR>\r
-<BR>\r
-<B>Available Document Formats<BR>\r
-</B>The present version of this document is available in Text and Html format:<BR>\r
-<TABLE><TR><TD><PRE> http://www.work.de/nocash/pandocs.txt\r
- http://www.work.de/nocash/pandocs.htm\r
-</TD></TR></TABLE>Also, a copy of this document is included in the manual of newer \r
-versions of the no$gmb debugger, because of recent piracy attacks (many \r
-thanks and best wishes go to hell) I have currently no intention to \r
-publish any such or further no$gmb updates though.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="gameboytechnicaldata"></A><FONT SIZE=+2> Game Boy Technical Data</FONT></TD></TR></TABLE><BR>\r
-<TABLE><TR><TD><PRE> CPU - 8-bit (Similar to the Z80 processor)\r
- Clock Speed - 4.194304MHz (4.295454MHz for SGB, max. 8.4MHz for CGB)\r
- Work RAM - 8K Byte (32K Byte for CGB)\r
- Video RAM - 8K Byte (16K Byte for CGB)\r
- Screen Size - 2.6"\r
- Resolution - 160x144 (20x18 tiles)\r
- Max sprites - Max 40 per screen, 10 per line\r
- Sprite sizes - 8x8 or 8x16\r
- Palettes - 1x4 BG, 2x3 OBJ (for CGB: 8x4 BG, 8x3 OBJ)\r
- Colors - 4 grayshades (32768 colors for CGB)\r
- Horiz Sync - 9198 KHz (9420 KHz for SGB)\r
- Vert Sync - 59.73 Hz (61.17 Hz for SGB)\r
- Sound - 4 channels with stereo sound\r
- Power - DC6V 0.7W (DC3V 0.7W for GB Pocket, DC3V 0.6W for CGB)\r
-</TD></TR></TABLE><BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="memorymap"></A><FONT SIZE=+2> Memory Map</FONT></TD></TR></TABLE><BR>\r
-The gameboy is having a 16bit address bus, that is used to address ROM, \r
-RAM, and I/O registers.<BR>\r
-<BR>\r
-<B>General Memory Map<BR>\r
-</B><TABLE><TR><TD><PRE> 0000-3FFF 16KB ROM Bank 00 (in cartridge, fixed at bank 00)\r
- 4000-7FFF 16KB ROM Bank 01..NN (in cartridge, switchable bank number)\r
- 8000-9FFF 8KB Video RAM (VRAM) (switchable bank 0-1 in CGB Mode)\r
- A000-BFFF 8KB External RAM (in cartridge, switchable bank, if any)\r
- C000-CFFF 4KB Work RAM Bank 0 (WRAM)\r
- D000-DFFF 4KB Work RAM Bank 1 (WRAM) (switchable bank 1-7 in CGB Mode)\r
- E000-FDFF Same as C000-DDFF (ECHO) (typically not used)\r
- FE00-FE9F Sprite Attribute Table (OAM)\r
- FEA0-FEFF Not Usable\r
- FF00-FF7F I/O Ports\r
- FF80-FFFE High RAM (HRAM)\r
- FFFF Interrupt Enable Register\r
-</TD></TR></TABLE><BR>\r
-<B>Jump Vectors in First ROM Bank<BR>\r
-</B>The following addresses are supposed to be used as jump vectors:<BR>\r
-<TABLE><TR><TD><PRE> 0000,0008,0010,0018,0020,0028,0030,0038 for RST commands\r
- 0040,0048,0050,0058,0060 for Interrupts\r
-</TD></TR></TABLE>However, the memory may be used for any other purpose in case that your \r
-program doesn't use any (or only some) RST commands or Interrupts. RST \r
-commands are 1-byte opcodes that work similiar to CALL opcodes, except \r
-that the destination address is fixed.<BR>\r
-<BR>\r
-<B>Cartridge Header in First ROM Bank<BR>\r
-</B>The memory at 0100-014F contains the cartridge header. This area \r
-contains information about the program, its entry point, checksums, \r
-information about the used MBC chip, the ROM and RAM sizes, etc. Most of \r
-the bytes in this area are required to be specified correctly. For more \r
-information read the chapter about The Cartridge Header.<BR>\r
-<BR>\r
-<B>External Memory and Hardware<BR>\r
-</B>The areas from 0000-7FFF and A000-BFFF may be used to connect external \r
-hardware. The first area is typically used to address ROM (read only, of \r
-course), cartridges with Memory Bank Controllers (MBCs) are additionally \r
-using this area to output data (write only) to the MBC chip. The second \r
-area is often used to address external RAM, or to address other external \r
-hardware (Real Time Clock, etc). External memory is often battery \r
-buffered, and may hold saved game positions and high scrore tables \r
-(etc.) even when the gameboy is turned of, or when the cartridge is \r
-removed. For specific information read the chapter about Memory Bank \r
-Controllers.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="videodisplay"></A><FONT SIZE=+2> Video Display</FONT></TD></TR></TABLE><BR>\r
-<B>Video I/O Registers<BR>\r
-</B><A HREF="#lcdcontrolregister">LCD Control Register</A><BR>\r
-<A HREF="#lcdstatusregister">LCD Status Register</A><BR>\r
-<A HREF="#lcdinterrupts">LCD Interrupts</A><BR>\r
-<A HREF="#lcdpositionandscrolling">LCD Position and Scrolling</A><BR>\r
-<A HREF="#lcdmonochromepalettes">LCD Monochrome Palettes</A><BR>\r
-<A HREF="#lcdcolorpalettescgbonly">LCD Color Palettes (CGB only)</A><BR>\r
-<A HREF="#lcdvrambankcgbonly">LCD VRAM Bank (CGB only)</A><BR>\r
-<A HREF="#lcdoamdmatransfers">LCD OAM DMA Transfers</A><BR>\r
-<A HREF="#lcdvramdmatransferscgbonly">LCD VRAM DMA Transfers (CGB only)</A><BR>\r
-<BR>\r
-<B>Video Memory<BR>\r
-</B><A HREF="#vramtiledata">VRAM Tile Data</A><BR>\r
-<A HREF="#vrambackgroundmaps">VRAM Background Maps</A><BR>\r
-<A HREF="#vramspriteattributetableoam">VRAM Sprite Attribute Table (OAM)</A><BR>\r
-<A HREF="#accessingvramandoam">Accessing VRAM and OAM</A><BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="lcdcontrolregister"></A><FONT SIZE=+2> LCD Control Register</FONT></TD></TR></TABLE><BR>\r
-<B>FF40 - LCDC - LCD Control (R/W)<BR>\r
-</B><TABLE><TR><TD><PRE> Bit 7 - LCD Display Enable (0=Off, 1=On)\r
- Bit 6 - Window Tile Map Display Select (0=9800-9BFF, 1=9C00-9FFF)\r
- Bit 5 - Window Display Enable (0=Off, 1=On)\r
- Bit 4 - BG & Window Tile Data Select (0=8800-97FF, 1=8000-8FFF)\r
- Bit 3 - BG Tile Map Display Select (0=9800-9BFF, 1=9C00-9FFF)\r
- Bit 2 - OBJ (Sprite) Size (0=8x8, 1=8x16)\r
- Bit 1 - OBJ (Sprite) Display Enable (0=Off, 1=On)\r
- Bit 0 - BG Display (for CGB see below) (0=Off, 1=On)\r
-</TD></TR></TABLE><BR>\r
-<B>LCDC.7 - LCD Display Enable<BR>\r
-</B>CAUTION: Stopping LCD operation (Bit 7 from 1 to 0) may be performed \r
-during V-Blank ONLY, disabeling the display outside of the V-Blank \r
-period may damage the hardware. This appears to be a serious issue, \r
-Nintendo is reported to reject any games that do not follow this rule.<BR>\r
-V-blank can be confirmed when the value of LY is greater than or equal \r
-to 144. When the display is disabled the screen is blank (white), and \r
-VRAM and OAM can be accessed freely.<BR>\r
-<BR>\r
---- LCDC.0 has different Meanings depending on Gameboy Type ---<BR>\r
-<BR>\r
-<B>LCDC.0 - 1) Monochrome Gameboy and SGB: BG Display<BR>\r
-</B>When Bit 0 is cleared, the background becomes blank (white). Window and \r
-Sprites may still be displayed (if enabled in Bit 1 and/or Bit 5).<BR>\r
-<BR>\r
-<B>LCDC.0 - 2) CGB in CGB Mode: BG and Window Master Priority<BR>\r
-</B>When Bit 0 is cleared, the background and window lose their priority - \r
-the sprites will be always displayed on top of background and window, \r
-independently of the priority flags in OAM and BG Map attributes.<BR>\r
-<BR>\r
-<B>LCDC.0 - 3) CGB in Non CGB Mode: BG and Window Display<BR>\r
-</B>When Bit 0 is cleared, both background and window become blank (white), \r
-ie. the Window Display Bit (Bit 5) is ignored in that case. Only Sprites \r
-may still be displayed (if enabled in Bit 1).<BR>\r
-This is a possible compatibility problem - any monochrome games (if any) \r
-that disable the background, but still want to display the window \r
-wouldn't work properly on CGBs.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="lcdstatusregister"></A><FONT SIZE=+2> LCD Status Register</FONT></TD></TR></TABLE><BR>\r
-<B>FF41 - STAT - LCDC Status (R/W)<BR>\r
-</B><TABLE><TR><TD><PRE> Bit 6 - LYC=LY Coincidence Interrupt (1=Enable) (Read/Write)\r
- Bit 5 - Mode 2 OAM Interrupt (1=Enable) (Read/Write)\r
- Bit 4 - Mode 1 V-Blank Interrupt (1=Enable) (Read/Write)\r
- Bit 3 - Mode 0 H-Blank Interrupt (1=Enable) (Read/Write)\r
- Bit 2 - Coincidence Flag (0:LYC<>LY, 1:LYC=LY) (Read Only)\r
- Bit 1-0 - Mode Flag (Mode 0-3, see below) (Read Only)\r
- 0: During H-Blank\r
- 1: During V-Blank\r
- 2: During Searching OAM-RAM\r
- 3: During Transfering Data to LCD Driver\r
-</TD></TR></TABLE><BR>\r
-The two lower STAT bits show the current status of the LCD controller.<BR>\r
-<TABLE><TR><TD><PRE> Mode 0: The LCD controller is in the H-Blank period and\r
- the CPU can access both the display RAM (8000h-9FFFh)\r
- and OAM (FE00h-FE9Fh)\r
-</TD></TR></TABLE><BR>\r
-<TABLE><TR><TD><PRE> Mode 1: The LCD contoller is in the V-Blank period (or the\r
- display is disabled) and the CPU can access both the\r
- display RAM (8000h-9FFFh) and OAM (FE00h-FE9Fh)\r
-</TD></TR></TABLE><BR>\r
-<TABLE><TR><TD><PRE> Mode 2: The LCD controller is reading from OAM memory.\r
- The CPU <cannot> access OAM memory (FE00h-FE9Fh)\r
- during this period.\r
-</TD></TR></TABLE><BR>\r
-<TABLE><TR><TD><PRE> Mode 3: The LCD controller is reading from both OAM and VRAM,\r
- The CPU <cannot> access OAM and VRAM during this period.\r
- CGB Mode: Cannot access Palette Data (FF69,FF6B) either.\r
-</TD></TR></TABLE><BR>\r
-The following are typical when the display is enabled:<BR>\r
-<TABLE><TR><TD><PRE> Mode 2 2_____2_____2_____2_____2_____2___________________2____\r
- Mode 3 _33____33____33____33____33____33__________________3___\r
- Mode 0 ___000___000___000___000___000___000________________000\r
- Mode 1 ____________________________________11111111111111_____\r
-</TD></TR></TABLE><BR>\r
-The Mode Flag goes through the values 0, 2, and 3 at a cycle of about \r
-109uS. 0 is present about 48.6uS, 2 about 19uS, and 3 about 41uS. This \r
-is interrupted every 16.6ms by the VBlank (1). The mode flag stays set \r
-at 1 for about 1.08 ms.<BR>\r
-<BR>\r
-Mode 0 is present between 201-207 clks, 2 about 77-83 clks, and 3 about \r
-169-175 clks. A complete cycle through these states takes 456 clks. \r
-VBlank lasts 4560 clks. A complete screen refresh occurs every 70224 \r
-clks.)<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="lcdinterrupts"></A><FONT SIZE=+2> LCD Interrupts</FONT></TD></TR></TABLE><BR>\r
-<B>INT 40 - V-Blank Interrupt<BR>\r
-</B>The V-Blank interrupt occurs ca. 59.7 times a second on a regular GB and \r
-ca. 61.1 times a second on a Super GB (SGB). This interrupt occurs at \r
-the beginning of the V-Blank period (LY=144).<BR>\r
-During this period video hardware is not using video ram so it may be \r
-freely accessed. This period lasts approximately 1.1 milliseconds.<BR>\r
-<BR>\r
-<B>INT 48 - LCDC Status Interrupt<BR>\r
-</B>There are various reasons for this interrupt to occur as described by \r
-the STAT register ($FF40). One very popular reason is to indicate to the \r
-user when the video hardware is about to redraw a given LCD line. This \r
-can be useful for dynamically controlling the SCX/SCY registers \r
-($FF43/$FF42) to perform special video effects.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="lcdpositionandscrolling"></A><FONT SIZE=+2> LCD Position and Scrolling</FONT></TD></TR></TABLE><BR>\r
-<B>FF42 - SCY - Scroll Y (R/W)<BR>\r
-FF43 - SCX - Scroll X (R/W)<BR>\r
-</B>Specifies the position in the 256x256 pixels BG map (32x32 tiles) which \r
-is to be displayed at the upper/left LCD display position.<BR>\r
-Values in range from 0-255 may be used for X/Y each, the video \r
-controller automatically wraps back to the upper (left) position in BG \r
-map when drawing exceeds the lower (right) border of the BG map area.<BR>\r
-<BR>\r
-<B>FF44 - LY - LCDC Y-Coordinate (R)<BR>\r
-</B>The LY indicates the vertical line to which the present data is \r
-transferred to the LCD Driver. The LY can take on any value between 0 \r
-through 153. The values between 144 and 153 indicate the V-Blank period. \r
-Writing will reset the counter.<BR>\r
-<BR>\r
-<B>FF45 - LYC - LY Compare (R/W)<BR>\r
-</B>The gameboy permanently compares the value of the LYC and LY registers. \r
-When both values are identical, the coincident bit in the STAT register \r
-becomes set, and (if enabled) a STAT interrupt is requested.<BR>\r
-<BR>\r
-<B>FF4A - WY - Window Y Position (R/W)<BR>\r
-FF4B - WX - Window X Position minus 7 (R/W)<BR>\r
-</B>Specifies the upper/left positions of the Window area. (The window is an \r
-alternate background area which can be displayed above of the normal \r
-background. OBJs (sprites) may be still displayed above or behinf the \r
-window, just as for normal BG.)<BR>\r
-The window becomes visible (if enabled) when positions are set in range \r
-WX=0..166, WY=0..143. A postion of WX=7, WY=0 locates the window at \r
-upper left, it is then completly covering normal background.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="lcdmonochromepalettes"></A><FONT SIZE=+2> LCD Monochrome Palettes</FONT></TD></TR></TABLE><BR>\r
-<B>FF47 - BGP - BG Palette Data (R/W) - Non CGB Mode Only<BR>\r
-</B>This register assigns gray shades to the color numbers of the BG and \r
-Window tiles.<BR>\r
-<TABLE><TR><TD><PRE> Bit 7-6 - Shade for Color Number 3\r
- Bit 5-4 - Shade for Color Number 2\r
- Bit 3-2 - Shade for Color Number 1\r
- Bit 1-0 - Shade for Color Number 0\r
-</TD></TR></TABLE>The four possible gray shades are:<BR>\r
-<TABLE><TR><TD><PRE> 0 White\r
- 1 Light gray\r
- 2 Dark gray\r
- 3 Black\r
-</TD></TR></TABLE>In CGB Mode the Color Palettes are taken from CGB Palette Memory \r
-instead.<BR>\r
-<BR>\r
-<B>FF48 - OBP0 - Object Palette 0 Data (R/W) - Non CGB Mode Only<BR>\r
-</B>This register assigns gray shades for sprite palette 0. It works exactly \r
-as BGP (FF47), except that the lower two bits aren't used because sprite \r
-data 00 is transparent.<BR>\r
-<BR>\r
-<B>FF49 - OBP1 - Object Palette 1 Data (R/W) - Non CGB Mode Only<BR>\r
-</B>This register assigns gray shades for sprite palette 1. It works exactly \r
-as BGP (FF47), except that the lower two bits aren't used because sprite \r
-data 00 is transparent.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="lcdcolorpalettescgbonly"></A><FONT SIZE=+2> LCD Color Palettes (CGB only)</FONT></TD></TR></TABLE><BR>\r
-<B>FF68 - BCPS/BGPI - CGB Mode Only - Background Palette Index<BR>\r
-</B>This register is used to address a byte in the CGBs Background Palette \r
-Memory. Each two byte in that memory define a color value. The first 8 \r
-bytes define Color 0-3 of Palette 0 (BGP0), and so on for BGP1-7.<BR>\r
-<TABLE><TR><TD><PRE> Bit 0-5 Index (00-3F)\r
- Bit 7 Auto Increment (0=Disabled, 1=Increment after Writing)\r
-</TD></TR></TABLE>Data can be read/written to/from the specified index address through \r
-Register FF69. When the Auto Increment Bit is set then the index is \r
-automatically incremented after each <write> to FF69. Auto Increment has \r
-no effect when <reading> from FF69, so the index must be manually \r
-incremented in that case.<BR>\r
-<BR>\r
-<B>FF69 - BCPD/BGPD - CGB Mode Only - Background Palette Data<BR>\r
-</B>This register allows to read/write data to the CGBs Background Palette \r
-Memory, addressed through Register FF68.<BR>\r
-Each color is defined by two bytes (Bit 0-7 in first byte).<BR>\r
-<TABLE><TR><TD><PRE> Bit 0-4 Red Intensity (00-1F)\r
- Bit 5-9 Green Intensity (00-1F)\r
- Bit 10-14 Blue Intensity (00-1F)\r
-</TD></TR></TABLE>Much like VRAM, Data in Palette Memory cannot be read/written during the \r
-time when the LCD Controller is reading from it. (That is when the STAT \r
-register indicates Mode 3).<BR>\r
-Note: Initially all background colors are initialized as white.<BR>\r
-<BR>\r
-<B>FF6A - OCPS/OBPI - CGB Mode Only - Sprite Palette Index<BR>\r
-FF6B - OCPD/OBPD - CGB Mode Only - Sprite Palette Data<BR>\r
-</B>These registers are used to initialize the Sprite Palettes OBP0-7, \r
-identically as described above for Background Palettes. Note that four \r
-colors may be defined for each OBP Palettes - but only Color 1-3 of each \r
-Sprite Palette can be displayed, Color 0 is always transparent, and can \r
-be initialized to a don't care value.<BR>\r
-Note: Initially all sprite colors are uninitialized.<BR>\r
-<BR>\r
-<B>RGB Translation by CGBs<BR>\r
-</B>When developing graphics on PCs, note that the RGB values will have \r
-different appearance on CGB displays as on VGA monitors:<BR>\r
-The highest intensity will produce Light Gray color rather than White. \r
-The intensities are not linear; the values 10h-1Fh will all appear very \r
-bright, while medium and darker colors are ranged at 00h-0Fh.<BR>\r
-The CGB display will mix colors quite oddly, increasing intensity of \r
-only one R,G,B color will also influence the other two R,G,B colors.<BR>\r
-For example, a color setting of 03EFh (Blue=0, Green=1Fh, Red=0Fh) will \r
-appear as Neon Green on VGA displays, but on the CGB it'll produce a \r
-decently washed out Yellow.<BR>\r
-<BR>\r
-<B>RGB Translation by GBAs<BR>\r
-</B>Even though GBA is described to be compatible to CGB games, most CGB \r
-games are completely unplayable on GBAs because most colors are \r
-invisible (black). Of course, colors such like Black and White will \r
-appear the same on both CGB and GBA, but medium intensities are arranged \r
-completely different.<BR>\r
-Intensities in range 00h..0Fh are invisible/black (unless eventually \r
-under best sunlight circumstances, and when gazing at the screen under \r
-obscure viewing angles), unfortunately, these intensities are regulary \r
-used by most existing CGB games for medium and darker colors.<BR>\r
-Newer CGB games may avoid this effect by changing palette data when \r
-detecting GBA hardware. A relative simple method would be using the \r
-formula GBA=CGB/2+10h for each R,G,B intensity, probably the result \r
-won't be perfect, and (once colors became visible) it may turn out that \r
-the color mixing is different also, anyways, it'd be still ways better \r
-than no conversion.<BR>\r
-Asides, this translation method should have been VERY easy to implement \r
-in GBA hardware directly, even though Nintendo obviously failed to do \r
-so. How did they say, This seal is your assurance for excellence in \r
-workmanship and so on?<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="lcdvrambankcgbonly"></A><FONT SIZE=+2> LCD VRAM Bank (CGB only)</FONT></TD></TR></TABLE><BR>\r
-<B>FF4F - VBK - CGB Mode Only - VRAM Bank<BR>\r
-</B>This 1bit register selects the current Video Memory (VRAM) Bank.<BR>\r
-<TABLE><TR><TD><PRE> Bit 0 - VRAM Bank (0-1)\r
-</TD></TR></TABLE>Bank 0 contains 192 Tiles, and two background maps, just as for \r
-monochrome games. Bank 1 contains another 192 Tiles, and color attribute \r
-maps for the background maps in bank 0.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="lcdoamdmatransfers"></A><FONT SIZE=+2> LCD OAM DMA Transfers</FONT></TD></TR></TABLE><BR>\r
-<B>FF46 - DMA - DMA Transfer and Start Address (W)<BR>\r
-</B>Writing to this register launches a DMA transfer from ROM or RAM to OAM \r
-memory (sprite attribute table). The written value specifies the \r
-transfer source address divided by 100h, ie. source & destination are:<BR>\r
-<TABLE><TR><TD><PRE> Source: XX00-XX9F ;XX in range from 00-F1h\r
- Destination: FE00-FE9F\r
-</TD></TR></TABLE>It takes 160 microseconds until the transfer has completed (80 \r
-microseconds in CGB Double Speed Mode), during this time the CPU can \r
-access only HRAM (memory at FF80-FFFE). For this reason, the programmer \r
-must copy a short procedure into HRAM, and use this procedure to start \r
-the transfer from inside HRAM, and wait until the transfer has finished:<BR>\r
-<TABLE><TR><TD><PRE> ld (0FF46h),a ;start DMA transfer, a=start address/100h\r
- ld a,28h ;delay...\r
- wait: ;total 5x40 cycles, approx 200ms\r
- dec a ;1 cycle\r
- jr nz,wait ;4 cycles\r
-</TD></TR></TABLE>Most programs are executing this procedure from inside of their VBlank \r
-procedure, but it is possible to execute it during display redraw also, \r
-allowing to display more than 40 sprites on the screen (ie. for example \r
-40 sprites in upper half, and other 40 sprites in lower half of the \r
-screen).<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="lcdvramdmatransferscgbonly"></A><FONT SIZE=+2> LCD VRAM DMA Transfers (CGB only)</FONT></TD></TR></TABLE><BR>\r
-<B>FF51 - HDMA1 - CGB Mode Only - New DMA Source, High<BR>\r
-FF52 - HDMA2 - CGB Mode Only - New DMA Source, Low<BR>\r
-FF53 - HDMA3 - CGB Mode Only - New DMA Destination, High<BR>\r
-FF54 - HDMA4 - CGB Mode Only - New DMA Destination, Low<BR>\r
-FF55 - HDMA5 - CGB Mode Only - New DMA Length/Mode/Start<BR>\r
-</B>These registers are used to initiate a DMA transfer from ROM or RAM to \r
-VRAM. The Source Start Address may be located at 0000-7FF0 or A000-DFF0, \r
-the lower four bits of the address are ignored (treated as zero). The \r
-Destination Start Address may be located at 8000-9FF0, the lower four \r
-bits of the address are ignored (treated as zero), the upper 3 bits are \r
-ignored either (destination is always in VRAM).<BR>\r
-<BR>\r
-Writing to FF55 starts the transfer, the lower 7 bits of FF55 specify \r
-the Transfer Length (divided by 10h, minus 1). Ie. lengths of 10h-800h \r
-bytes can be defined by the values 00h-7Fh. And the upper bit of FF55 \r
-indicates the Transfer Mode:<BR>\r
-<BR>\r
-<B>Bit7=0 - General Purpose DMA<BR>\r
-</B>When using this transfer method, all data is transferred at once. The \r
-execution of the program is halted until the transfer has completed. \r
-Note that the General Purpose DMA blindly attempts to copy the data, \r
-even if the LCD controller is currently accessing VRAM. So General \r
-Purpose DMA should be used only if the Display is disabled, or during \r
-V-Blank, or (for rather short blocks) during H-Blank.<BR>\r
-The execution of the program continues when the transfer has been \r
-completed, and FF55 then contains a value if FFh.<BR>\r
-<BR>\r
-<B>Bit7=1 - H-Blank DMA<BR>\r
-</B>The H-Blank DMA transfers 10h bytes of data during each H-Blank, ie. at \r
-LY=0-143, no data is transferred during V-Blank (LY=144-153), but the \r
-transfer will then continue at LY=00. The execution of the program is \r
-halted during the separate transfers, but the program execution \r
-continues during the 'spaces' between each data block.<BR>\r
-Note that the program may not change the Destination VRAM bank (FF4F), \r
-or the Source ROM/RAM bank (in case data is transferred from bankable \r
-memory) until the transfer has completed!<BR>\r
-Reading from Register FF55 returns the remaining length (divided by 10h, \r
-minus 1), a value of 0FFh indicates that the transfer has completed. It \r
-is also possible to terminate an active H-Blank transfer by writing zero \r
-to Bit 7 of FF55. In that case reading from FF55 may return any value \r
-for the lower 7 bits, but Bit 7 will be read as "1".<BR>\r
-<BR>\r
-<B>Confirming if the DMA Transfer is Active<BR>\r
-</B>Reading Bit 7 of FF55 can be used to confirm if the DMA transfer is \r
-active (1=Not Active, 0=Active). This works under any circumstances - \r
-after completion of General Purpose, or H-Blank Transfer, and after \r
-manually terminating a H-Blank Transfer.<BR>\r
-<BR>\r
-<B>Transfer Timings<BR>\r
-</B>In both Normal Speed and Double Speed Mode it takes about 8us to \r
-transfer a block of 10h bytes. That are 8 cycles in Normal Speed Mode, \r
-and 16 'fast' cycles in Double Speed Mode.<BR>\r
-Older MBC controllers (like MBC1-4) and slower ROMs are not guaranteed \r
-to support General Purpose or H-Blank DMA, that's because there are \r
-always 2 bytes transferred per microsecond (even if the itself program \r
-runs it Normal Speed Mode).<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="vramtiledata"></A><FONT SIZE=+2> VRAM Tile Data</FONT></TD></TR></TABLE><BR>\r
-Tile Data is stored in VRAM at addresses 8000h-97FFh, this area defines \r
-the Bitmaps for 192 Tiles. In CGB Mode 384 Tiles can be defined, because \r
-memory at 0:8000h-97FFh and at 1:8000h-97FFh is used.<BR>\r
-<BR>\r
-Each tile is sized 8x8 pixels and has a color depth of 4 colors/gray \r
-shades. Tiles can be displayed as part of the Background/Window map, \r
-and/or as OAM tiles (foreground sprites). Note that foreground sprites \r
-may have only 3 colors, because color 0 is transparent.<BR>\r
-<BR>\r
-As it was said before, there are two Tile Pattern Tables at $8000-8FFF \r
-and at $8800-97FF. The first one can be used for sprites and the \r
-background. Its tiles are numbered from 0 to 255. The second table can \r
-be used for the background and the window display and its tiles are \r
-numbered from -128 to 127.<BR>\r
-<BR>\r
-Each Tile occupies 16 bytes, where each 2 bytes represent a line:<BR>\r
-<TABLE><TR><TD><PRE> Byte 0-1 First Line (Upper 8 pixels)\r
- Byte 2-3 Next Line\r
- etc.\r
-</TD></TR></TABLE>For each line, the first byte defines the least significant bits of the \r
-color numbers for each pixel, and the second byte defines the upper bits \r
-of the color numbers. In either case, Bit 7 is the leftmost pixel, and \r
-Bit 0 the rightmost.<BR>\r
-<BR>\r
-So, each pixel is having a color number in range from 0-3. The color \r
-numbers are translated into real colors (or gray shades) depending on \r
-the current palettes. The palettes are defined through registers \r
-FF47-FF49 (Non CGB Mode), and FF68-FF6B (CGB Mode).<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="vrambackgroundmaps"></A><FONT SIZE=+2> VRAM Background Maps</FONT></TD></TR></TABLE><BR>\r
-The gameboy contains two 32x32 tile background maps in VRAM at addresses \r
-9800h-9BFFh and 9C00h-9FFFh. Each can be used either to display "normal" \r
-background, or "window" background.<BR>\r
-<BR>\r
-<B>BG Map Tile Numbers<BR>\r
-</B>An area of VRAM known as Background Tile Map contains the numbers of \r
-tiles to be displayed. It is organized as 32 rows of 32 bytes each. Each \r
-byte contains a number of a tile to be displayed. Tile patterns are \r
-taken from the Tile Data Table located either at $8000-8FFF or \r
-$8800-97FF. In the first case, patterns are numbered with unsigned \r
-numbers from 0 to 255 (i.e. pattern #0 lies at address $8000). In the \r
-second case, patterns have signed numbers from -128 to 127 (i.e. pattern \r
-#0 lies at address $9000). The Tile Data Table address for the \r
-background can be selected via LCDC register.<BR>\r
-<BR>\r
-<B>BG Map Attributes (CGB Mode only)<BR>\r
-</B>In CGB Mode, an additional map of 32x32 bytes is stored in VRAM Bank 1 \r
-(each byte defines attributes for the corresponding tile-number map \r
-entry in VRAM Bank 0):<BR>\r
-<TABLE><TR><TD><PRE> Bit 0-2 Background Palette number (BGP0-7)\r
- Bit 3 Tile VRAM Bank number (0=Bank 0, 1=Bank 1)\r
- Bit 4 Not used\r
- Bit 5 Horizontal Flip (0=Normal, 1=Mirror horizontally)\r
- Bit 6 Vertical Flip (0=Normal, 1=Mirror vertically)\r
- Bit 7 BG-to-OAM Priority (0=Use OAM priority bit, 1=BG Priority)\r
-</TD></TR></TABLE>When Bit 7 is set, the corresponding BG tile will have priority above \r
-all OBJs (regardless of the priority bits in OAM memory). There's also \r
-an Master Priority flag in LCDC register Bit 0 which overrides all other \r
-priority bits when cleared.<BR>\r
-<BR>\r
-As one background tile has a size of 8x8 pixels, the BG maps may hold a \r
-picture of 256x256 pixels, an area of 160x144 pixels of this picture can \r
-be displayed on the LCD screen.<BR>\r
-<BR>\r
-<B>Normal Background (BG)<BR>\r
-</B>The SCY and SCX registers can be used to scroll the background, allowing \r
-to select the origin of the visible 160x144 pixel area within the total \r
-256x256 pixel background map. Background wraps around the screen (i.e. \r
-when part of it goes off the screen, it appears on the opposite side.)<BR>\r
-<BR>\r
-<B>The Window<BR>\r
-</B>Besides background, there is also a "window" overlaying the background. \r
-The window is not scrollable i.e. it is always displayed starting from \r
-its left upper corner. The location of a window on the screen can be \r
-adjusted via WX and WY registers. Screen coordinates of the top left \r
-corner of a window are WX-7,WY. The tiles for the window are stored in \r
-the Tile Data Table. Both the Background and the window share the same \r
-Tile Data Table.<BR>\r
-<BR>\r
-Both background and window can be disabled or enabled separately via \r
-bits in the LCDC register.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="vramspriteattributetableoam"></A><FONT SIZE=+2> VRAM Sprite Attribute Table (OAM)</FONT></TD></TR></TABLE><BR>\r
-GameBoy video controller can display up to 40 sprites either in 8x8 or \r
-in 8x16 pixels. Because of a limitation of hardware, only ten sprites \r
-can be displayed per scan line. Sprite patterns have the same format as \r
-BG tiles, but they are taken from the Sprite Pattern Table located at \r
-$8000-8FFF and have unsigned numbering.<BR>\r
-<BR>\r
-Sprite attributes reside in the Sprite Attribute Table (OAM - Object \r
-Attribute Memory) at $FE00-FE9F. Each of the 40 entries consists of four \r
-bytes with the following meanings:<BR>\r
-<BR>\r
-<B>Byte0 - Y Position<BR>\r
-</B>Specifies the sprites vertical position on the screen (minus 16).<BR>\r
-An offscreen value (for example, Y=0 or Y>=160) hides the sprite.<BR>\r
-<BR>\r
-<B>Byte1 - X Position<BR>\r
-</B>Specifies the sprites horizontal position on the screen (minus 8).<BR>\r
-An offscreen value (X=0 or X>=168) hides the sprite, but the sprite<BR>\r
-still affects the priority ordering - a better way to hide a sprite is \r
-to set its Y-coordinate offscreen.<BR>\r
-<BR>\r
-<B>Byte2 - Tile/Pattern Number<BR>\r
-</B>Specifies the sprites Tile Number (00-FF). This (unsigned) value selects \r
-a tile from memory at 8000h-8FFFh. In CGB Mode this could be either in \r
-VRAM Bank 0 or 1, depending on Bit 3 of the following byte.<BR>\r
-In 8x16 mode, the lower bit of the tile number is ignored. Ie. the upper \r
-8x8 tile is "NN AND FEh", and the lower 8x8 tile is "NN OR 01h".<BR>\r
-<BR>\r
-<B>Byte3 - Attributes/Flags:<BR>\r
-</B><TABLE><TR><TD><PRE> Bit7 OBJ-to-BG Priority (0=OBJ Above BG, 1=OBJ Behind BG color 1-3)\r
- (Used for both BG and Window. BG color 0 is always behind OBJ)\r
- Bit6 Y flip (0=Normal, 1=Vertically mirrored)\r
- Bit5 X flip (0=Normal, 1=Horizontally mirrored)\r
- Bit4 Palette number **Non CGB Mode Only** (0=OBP0, 1=OBP1)\r
- Bit3 Tile VRAM-Bank **CGB Mode Only** (0=Bank 0, 1=Bank 1)\r
- Bit2-0 Palette number **CGB Mode Only** (OBP0-7)\r
-</TD></TR></TABLE><BR>\r
-<B>Sprite Priorities and Conflicts<BR>\r
-</B>When sprites with different x coordinate values overlap, the one with \r
-the smaller x coordinate (closer to the left) will have priority and \r
-appear above any others. This applies in Non CGB Mode only.<BR>\r
-When sprites with the same x coordinate values overlap, they have \r
-priority according to table ordering. (i.e. $FE00 - highest, $FE04 - \r
-next highest, etc.) In CGB Mode priorities are always assigned like \r
-this.<BR>\r
-<BR>\r
-Only 10 sprites can be displayed on any one line. When this limit is \r
-exceeded, the lower priority sprites (priorities listed above) won't be \r
-displayed. To keep unused sprites from affecting onscreen sprites set \r
-their Y coordinate to Y=0 or Y=>144+16. Just setting the X coordinate to \r
-X=0 or X=>160+8 on a sprite will hide it but it will still affect other \r
-sprites sharing the same lines.<BR>\r
-<BR>\r
-<B>Writing Data to OAM Memory<BR>\r
-</B>The recommened method is to write the data to normal RAM first, and to \r
-copy that RAM to OAM by using the DMA transfer function, initiated \r
-through DMA register (FF46).<BR>\r
-Beside for that, it is also possible to write data directly to the OAM \r
-area by using normal LD commands, this works only during the H-Blank and \r
-V-Blank periods. The current state of the LCD controller can be read out \r
-from the STAT register (FF41).<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="accessingvramandoam"></A><FONT SIZE=+2> Accessing VRAM and OAM</FONT></TD></TR></TABLE><BR>\r
-<B>CAUTION<BR>\r
-</B>When the LCD Controller is drawing the screen it is directly reading \r
-from Video Memory (VRAM) and from the Sprite Attribute Table (OAM). \r
-During these periods the Gameboy CPU may not access the VRAM and OAM. \r
-That means, any attempts to write to VRAM/OAM are ignored (the data \r
-remains unchanged). And any attempts to read from VRAM/OAM will return \r
-undefined data (typically a value of FFh).<BR>\r
-<BR>\r
-For this reason the program should verify if VRAM/OAM is accessable \r
-before actually reading or writing to it. This is usually done by \r
-reading the Mode Bits from the STAT Register (FF41). When doing this (as \r
-described in the examples below) you should take care that no interrupts \r
-occur between the wait loops and the following memory access - the \r
-memory is guaranted to be accessable only for a few cycles directly \r
-after the wait loops have completed.<BR>\r
-<BR>\r
-<B>VRAM (memory at 8000h-9FFFh) is accessable during Mode 0-2<BR>\r
-</B><TABLE><TR><TD><PRE> Mode 0 - H-Blank Period,\r
- Mode 1 - V-Blank Period, and\r
- Mode 2 - Searching OAM Period\r
-</TD></TR></TABLE>A typical procedure that waits for accessibility of VRAM would be:<BR>\r
-<TABLE><TR><TD><PRE> ld hl,0FF41h ;-STAT Register\r
- @@wait: ;\\r
- bit 1,(hl) ; Wait until Mode is 0 or 1\r
- jr nz,@@wait ;/\r
-</TD></TR></TABLE>Even if the procedure gets executed at the <end> of Mode 0 or 1, it is \r
-still proof to assume that VRAM can be accessed for a few more cycles \r
-because in either case the following period is Mode 2 which allows \r
-access to VRAM either.<BR>\r
-In CGB Mode an alternate method to write data to VRAM is to use the HDMA \r
-Function (FF51-FF55).<BR>\r
-<BR>\r
-<B>OAM (memory at FE00h-FE9Fh) is accessable during Mode 0-1<BR>\r
-</B><TABLE><TR><TD><PRE> Mode 0 - H-Blank Period, and\r
- Mode 1 - V-Blank Period\r
-</TD></TR></TABLE>Beside for that, OAM can be accessed at any time by using the DMA \r
-Function (FF46). When directly reading or writing to OAM, a typical \r
-procedure that waits for accessibilty or OAM Memory would be:<BR>\r
-<TABLE><TR><TD><PRE> ld hl,0FF41h ;-STAT Register\r
- @@wait1: ;\\r
- bit 1,(hl) ; Wait until Mode is -NOT- 0 or 1\r
- jr z,@@wait1 ;/\r
- @@wait2: ;\\r
- bit 1,(hl) ; Wait until Mode 0 or 1 -BEGINS-\r
- jr nz,@@wait2 ;/\r
-</TD></TR></TABLE>The two wait loops ensure that Mode 0 or 1 will last for a few clock \r
-cycles after completion of the procedure. In V-Blank period it might be \r
-recommended to skip the whole procedure - and in most cases using the \r
-above mentioned DMA function would be more recommended anyways.<BR>\r
-<BR>\r
-<B>Note<BR>\r
-</B>When the display is disabled, both VRAM and OAM are accessable at any \r
-time. The downside is that the screen is blank (white) during this \r
-period, so that disabling the display would be recommended only during \r
-initialization.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="soundcontroller"></A><FONT SIZE=+2> Sound Controller</FONT></TD></TR></TABLE><BR>\r
-<A HREF="#soundoverview">Sound Overview</A><BR>\r
-<A HREF="#soundchannel1tonesweep">Sound Channel 1 - Tone & Sweep</A><BR>\r
-<A HREF="#soundchannel2tone">Sound Channel 2 - Tone</A><BR>\r
-<A HREF="#soundchannel3waveoutput">Sound Channel 3 - Wave Output</A><BR>\r
-<A HREF="#soundchannel4noise">Sound Channel 4 - Noise</A><BR>\r
-<A HREF="#soundcontrolregisters">Sound Control Registers</A><BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="soundoverview"></A><FONT SIZE=+2> Sound Overview</FONT></TD></TR></TABLE><BR>\r
-There are two sound channels connected to the output terminals SO1 and \r
-SO2. There is also a input terminal Vin connected to the cartridge. It \r
-can be routed to either of both output terminals. GameBoy circuitry \r
-allows producing sound in four different ways:<BR>\r
-<BR>\r
-<TABLE><TR><TD><PRE> Quadrangular wave patterns with sweep and envelope functions.\r
- Quadrangular wave patterns with envelope functions.\r
- Voluntary wave patterns from wave RAM.\r
- White noise with an envelope function.\r
-</TD></TR></TABLE><BR>\r
-These four sounds can be controlled independantly and then mixed \r
-separately for each of the output terminals.<BR>\r
-<BR>\r
-Sound registers may be set at all times while producing sound.<BR>\r
-<BR>\r
-(Sounds will have a 2.4% higher frequency on Super GB.)<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="soundchannel1tonesweep"></A><FONT SIZE=+2> Sound Channel 1 - Tone & Sweep</FONT></TD></TR></TABLE><BR>\r
-<B>FF10 - NR10 - Channel 1 Sweep register (R/W)<BR>\r
-</B><TABLE><TR><TD><PRE> Bit 6-4 - Sweep Time\r
- Bit 3 - Sweep Increase/Decrease\r
- 0: Addition (frequency increases)\r
- 1: Subtraction (frequency decreases)\r
- Bit 2-0 - Number of sweep shift (n: 0-7)\r
-</TD></TR></TABLE>Sweep Time:<BR>\r
-<TABLE><TR><TD><PRE> 000: sweep off - no freq change\r
- 001: 7.8 ms (1/128Hz)\r
- 010: 15.6 ms (2/128Hz)\r
- 011: 23.4 ms (3/128Hz)\r
- 100: 31.3 ms (4/128Hz)\r
- 101: 39.1 ms (5/128Hz)\r
- 110: 46.9 ms (6/128Hz)\r
- 111: 54.7 ms (7/128Hz)\r
-</TD></TR></TABLE><BR>\r
-The change of frequency (NR13,NR14) at each shift is calculated by the \r
-following formula where X(0) is initial freq & X(t-1) is last freq:<BR>\r
-<TABLE><TR><TD><PRE> X(t) = X(t-1) +/- X(t-1)/2^n\r
-</TD></TR></TABLE><BR>\r
-<B>FF11 - NR11 - Channel 1 Sound length/Wave pattern duty (R/W)<BR>\r
-</B><TABLE><TR><TD><PRE> Bit 7-6 - Wave Pattern Duty (Read/Write)\r
- Bit 5-0 - Sound length data (Write Only) (t1: 0-63)\r
-</TD></TR></TABLE>Wave Duty:<BR>\r
-<TABLE><TR><TD><PRE> 00: 12.5% ( _-------_-------_------- )\r
- 01: 25% ( __------__------__------ )\r
- 10: 50% ( ____----____----____---- ) (normal)\r
- 11: 75% ( ______--______--______-- )\r
-</TD></TR></TABLE>Sound Length = (64-t1)*(1/256) seconds<BR>\r
-The Length value is used only if Bit 6 in NR14 is set.<BR>\r
-<BR>\r
-<B>FF12 - NR12 - Channel 1 Volume Envelope (R/W)<BR>\r
-</B><TABLE><TR><TD><PRE> Bit 7-4 - Initial Volume of envelope (0-0Fh) (0=No Sound)\r
- Bit 3 - Envelope Direction (0=Decrease, 1=Increase)\r
- Bit 2-0 - Number of envelope sweep (n: 0-7)\r
- (If zero, stop envelope operation.)\r
-</TD></TR></TABLE>Length of 1 step = n*(1/64) seconds<BR>\r
-<BR>\r
-<B>FF13 - NR13 - Channel 1 Frequency lo (Write Only)<BR>\r
-</B><BR>\r
-Lower 8 bits of 11 bit frequency (x).<BR>\r
-Next 3 bit are in NR14 ($FF14)<BR>\r
-<BR>\r
-<B>FF14 - NR14 - Channel 1 Frequency hi (R/W)<BR>\r
-</B><TABLE><TR><TD><PRE> Bit 7 - Initial (1=Restart Sound) (Write Only)\r
- Bit 6 - Counter/consecutive selection (Read/Write)\r
- (1=Stop output when length in NR11 expires)\r
- Bit 2-0 - Frequency's higher 3 bits (x) (Write Only)\r
-</TD></TR></TABLE>Frequency = 131072/(2048-x) Hz<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="soundchannel2tone"></A><FONT SIZE=+2> Sound Channel 2 - Tone</FONT></TD></TR></TABLE><BR>\r
-This sound channel works exactly as channel 1, except that it doesn't \r
-have a Tone Envelope/Sweep Register.<BR>\r
-<BR>\r
-<B>FF16 - NR21 - Channel 2 Sound Length/Wave Pattern Duty (R/W)<BR>\r
-</B><TABLE><TR><TD><PRE> Bit 7-6 - Wave Pattern Duty (Read/Write)\r
- Bit 5-0 - Sound length data (Write Only) (t1: 0-63)\r
-</TD></TR></TABLE>Wave Duty:<BR>\r
-<TABLE><TR><TD><PRE> 00: 12.5% ( _-------_-------_------- )\r
- 01: 25% ( __------__------__------ )\r
- 10: 50% ( ____----____----____---- ) (normal)\r
- 11: 75% ( ______--______--______-- )\r
-</TD></TR></TABLE>Sound Length = (64-t1)*(1/256) seconds<BR>\r
-The Length value is used only if Bit 6 in NR24 is set.<BR>\r
-<BR>\r
-<B>FF17 - NR22 - Channel 2 Volume Envelope (R/W)<BR>\r
-</B><TABLE><TR><TD><PRE> Bit 7-4 - Initial Volume of envelope (0-0Fh) (0=No Sound)\r
- Bit 3 - Envelope Direction (0=Decrease, 1=Increase)\r
- Bit 2-0 - Number of envelope sweep (n: 0-7)\r
- (If zero, stop envelope operation.)\r
-</TD></TR></TABLE>Length of 1 step = n*(1/64) seconds<BR>\r
-<BR>\r
-<B>FF18 - NR23 - Channel 2 Frequency lo data (W)<BR>\r
-</B>Frequency's lower 8 bits of 11 bit data (x).<BR>\r
-Next 3 bits are in NR24 ($FF19).<BR>\r
-<BR>\r
-<B>FF19 - NR24 - Channel 2 Frequency hi data (R/W)<BR>\r
-</B><TABLE><TR><TD><PRE> Bit 7 - Initial (1=Restart Sound) (Write Only)\r
- Bit 6 - Counter/consecutive selection (Read/Write)\r
- (1=Stop output when length in NR21 expires)\r
- Bit 2-0 - Frequency's higher 3 bits (x) (Write Only)\r
-</TD></TR></TABLE>Frequency = 131072/(2048-x) Hz<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="soundchannel3waveoutput"></A><FONT SIZE=+2> Sound Channel 3 - Wave Output</FONT></TD></TR></TABLE><BR>\r
-This channel can be used to output digital sound, the length of the \r
-sample buffer (Wave RAM) is limited to 32 digits. This sound channel can \r
-be also used to output normal tones when initializing the Wave RAM by a \r
-square wave. This channel doesn't have a volume envelope register.<BR>\r
-<BR>\r
-<B>FF1A - NR30 - Channel 3 Sound on/off (R/W)<BR>\r
-</B><TABLE><TR><TD><PRE> Bit 7 - Sound Channel 3 Off (0=Stop, 1=Playback) (Read/Write)\r
-</TD></TR></TABLE><BR>\r
-<B>FF1B - NR31 - Channel 3 Sound Length<BR>\r
-</B><TABLE><TR><TD><PRE> Bit 7-0 - Sound length (t1: 0 - 255)\r
-</TD></TR></TABLE>Sound Length = (256-t1)*(1/256) seconds<BR>\r
-This value is used only if Bit 6 in NR34 is set.<BR>\r
-<BR>\r
-<B>FF1C - NR32 - Channel 3 Select output level (R/W)<BR>\r
-</B><TABLE><TR><TD><PRE> Bit 6-5 - Select output level (Read/Write)\r
-</TD></TR></TABLE>Possible Output levels are:<BR>\r
-<TABLE><TR><TD><PRE> 0: Mute (No sound)\r
- 1: 100% Volume (Produce Wave Pattern RAM Data as it is)\r
- 2: 50% Volume (Produce Wave Pattern RAM data shifted once to the right)\r
- 3: 25% Volume (Produce Wave Pattern RAM data shifted twice to the right)\r
-</TD></TR></TABLE><BR>\r
-<B>FF1D - NR33 - Channel 3 Frequency's lower data (W)<BR>\r
-</B>Lower 8 bits of an 11 bit frequency (x).<BR>\r
-<BR>\r
-<B>FF1E - NR34 - Channel 3 Frequency's higher data (R/W)<BR>\r
-</B><TABLE><TR><TD><PRE> Bit 7 - Initial (1=Restart Sound) (Write Only)\r
- Bit 6 - Counter/consecutive selection (Read/Write)\r
- (1=Stop output when length in NR31 expires)\r
- Bit 2-0 - Frequency's higher 3 bits (x) (Write Only)\r
-</TD></TR></TABLE>Frequency = 4194304/(64*(2048-x)) Hz = 65536/(2048-x) Hz<BR>\r
-<BR>\r
-<B>FF30-FF3F - Wave Pattern RAM<BR>\r
-</B>Contents - Waveform storage for arbitrary sound data<BR>\r
-<BR>\r
-This storage area holds 32 4-bit samples that are played back upper 4 \r
-bits first.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="soundchannel4noise"></A><FONT SIZE=+2> Sound Channel 4 - Noise</FONT></TD></TR></TABLE><BR>\r
-This channel is used to output white noise. This is done by randomly \r
-switching the amplitude between high and low at a given frequency. \r
-Depending on the frequency the noise will appear 'harder' or 'softer'.<BR>\r
-<BR>\r
-It is also possible to influence the function of the random generator, \r
-so the that the output becomes more regular, resulting in a limited \r
-ability to output Tone instead of Noise.<BR>\r
-<BR>\r
-<B>FF20 - NR41 - Channel 4 Sound Length (R/W)<BR>\r
-</B><TABLE><TR><TD><PRE> Bit 5-0 - Sound length data (t1: 0-63)\r
-</TD></TR></TABLE>Sound Length = (64-t1)*(1/256) seconds<BR>\r
-The Length value is used only if Bit 6 in NR44 is set.<BR>\r
-<BR>\r
-<B>FF21 - NR42 - Channel 4 Volume Envelope (R/W)<BR>\r
-</B><TABLE><TR><TD><PRE> Bit 7-4 - Initial Volume of envelope (0-0Fh) (0=No Sound)\r
- Bit 3 - Envelope Direction (0=Decrease, 1=Increase)\r
- Bit 2-0 - Number of envelope sweep (n: 0-7)\r
- (If zero, stop envelope operation.)\r
-</TD></TR></TABLE>Length of 1 step = n*(1/64) seconds<BR>\r
-<BR>\r
-<B>FF22 - NR43 - Channel 4 Polynomial Counter (R/W)<BR>\r
-</B>The amplitude is randomly switched between high and low at the given \r
-frequency. A higher frequency will make the noise to appear 'softer'.<BR>\r
-When Bit 3 is set, the output will become more regular, and some \r
-frequencies will sound more like Tone than Noise.<BR>\r
-<TABLE><TR><TD><PRE> Bit 7-4 - Shift Clock Frequency (s)\r
- Bit 3 - Counter Step/Width (0=15 bits, 1=7 bits)\r
- Bit 2-0 - Dividing Ratio of Frequencies (r)\r
-</TD></TR></TABLE>Frequency = 524288 Hz / r / 2^(s+1) ;For r=0 assume r=0.5 instead<BR>\r
-<BR>\r
-<B>FF23 - NR44 - Channel 4 Counter/consecutive; Inital (R/W)<BR>\r
-</B><TABLE><TR><TD><PRE> Bit 7 - Initial (1=Restart Sound) (Write Only)\r
- Bit 6 - Counter/consecutive selection (Read/Write)\r
- (1=Stop output when length in NR41 expires)\r
-</TD></TR></TABLE><BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="soundcontrolregisters"></A><FONT SIZE=+2> Sound Control Registers</FONT></TD></TR></TABLE><BR>\r
-<B>FF24 - NR50 - Channel control / ON-OFF / Volume (R/W)<BR>\r
-</B>The volume bits specify the "Master Volume" for Left/Right sound output.<BR>\r
-<TABLE><TR><TD><PRE> Bit 7 - Output Vin to SO2 terminal (1=Enable)\r
- Bit 6-4 - SO2 output level (volume) (0-7)\r
- Bit 3 - Output Vin to SO1 terminal (1=Enable)\r
- Bit 2-0 - SO1 output level (volume) (0-7)\r
-</TD></TR></TABLE>The Vin signal is received from the game cartridge bus, allowing \r
-external hardware in the cartridge to supply a fifth sound channel, \r
-additionally to the gameboys internal four channels. As far as I know \r
-this feature isn't used by any existing games.<BR>\r
-<BR>\r
-<B>FF25 - NR51 - Selection of Sound output terminal (R/W)<BR>\r
-</B><TABLE><TR><TD><PRE> Bit 7 - Output sound 4 to SO2 terminal\r
- Bit 6 - Output sound 3 to SO2 terminal\r
- Bit 5 - Output sound 2 to SO2 terminal\r
- Bit 4 - Output sound 1 to SO2 terminal\r
- Bit 3 - Output sound 4 to SO1 terminal\r
- Bit 2 - Output sound 3 to SO1 terminal\r
- Bit 1 - Output sound 2 to SO1 terminal\r
- Bit 0 - Output sound 1 to SO1 terminal\r
-</TD></TR></TABLE><BR>\r
-<B>FF26 - NR52 - Sound on/off<BR>\r
-</B>If your GB programs don't use sound then write 00h to this register to \r
-save 16% or more on GB power consumption. Disabeling the sound \r
-controller by clearing Bit 7 destroys the contents of all sound \r
-registers. Also, it is not possible to access any sound registers \r
-(execpt FF26) while the sound controller is disabled.<BR>\r
-<TABLE><TR><TD><PRE> Bit 7 - All sound on/off (0: stop all sound circuits) (Read/Write)\r
- Bit 3 - Sound 4 ON flag (Read Only)\r
- Bit 2 - Sound 3 ON flag (Read Only)\r
- Bit 1 - Sound 2 ON flag (Read Only)\r
- Bit 0 - Sound 1 ON flag (Read Only)\r
-</TD></TR></TABLE>Bits 0-3 of this register are read only status bits, writing to these \r
-bits does NOT enable/disable sound. The flags get set when sound output \r
-is restarted by setting the Initial flag (Bit 7 in NR14-NR44), the flag \r
-remains set until the sound length has expired (if enabled). A volume \r
-envelopes which has decreased to zero volume will NOT cause the sound \r
-flag to go off.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="joypadinput"></A><FONT SIZE=+2> Joypad Input</FONT></TD></TR></TABLE><BR>\r
-<B>FF00 - P1/JOYP - Joypad (R/W)<BR>\r
-</B>The eight gameboy buttons/direction keys are arranged in form of a 2x4 \r
-matrix. Select either button or direction keys by writing to this \r
-register, then read-out bit 0-3.<BR>\r
-<TABLE><TR><TD><PRE> Bit 7 - Not used\r
- Bit 6 - Not used\r
- Bit 5 - P15 Select Button Keys (0=Select)\r
- Bit 4 - P14 Select Direction Keys (0=Select)\r
- Bit 3 - P13 Input Down or Start (0=Pressed) (Read Only)\r
- Bit 2 - P12 Input Up or Select (0=Pressed) (Read Only)\r
- Bit 1 - P11 Input Left or Button B (0=Pressed) (Read Only)\r
- Bit 0 - P10 Input Right or Button A (0=Pressed) (Read Only)\r
-</TD></TR></TABLE>Note: Most programs are repeatedly reading from this port several times \r
-(the first reads used as short delay, allowing the inputs to stabilize, \r
-and only the value from the last read actually used).<BR>\r
-<BR>\r
-<B>Usage in SGB software<BR>\r
-</B>Beside for normal joypad input, SGB games mis-use the joypad register to \r
-output SGB command packets to the SNES, also, SGB programs may read out \r
-gamepad states from up to four different joypads which can be connected \r
-to the SNES.<BR>\r
-See SGB description for details.<BR>\r
-<BR>\r
-<B>INT 60 - Joypad Interrupt<BR>\r
-</B>Joypad interrupt is requested when any of the above Input lines changes \r
-from High to Low. Generally this should happen when a key becomes \r
-pressed (provided that the button/direction key is enabled by above \r
-Bit4/5), however, because of switch bounce, one or more High to Low \r
-transitions are usually produced both when pressing or releasing a key.<BR>\r
-<BR>\r
-<B>Using the Joypad Interrupt<BR>\r
-</B>It's more or less useless for programmers, even when selecting both \r
-buttons and direction keys simultaneously it still cannot recognize all \r
-keystrokes, because in that case a bit might be already held low by a \r
-button key, and pressing the corresponding direction key would thus \r
-cause no difference. The only meaningful purpose of the keystroke \r
-interrupt would be to terminate STOP (low power) standby state.<BR>\r
-Also, the joypad interrupt does not appear to work with CGB and GBA \r
-hardware (the STOP function can be still terminated by joypad keystrokes \r
-though).<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="serialdatatransferlinkcable"></A><FONT SIZE=+2> Serial Data Transfer (Link Cable)</FONT></TD></TR></TABLE><BR>\r
-<B>FF01 - SB - Serial transfer data (R/W)<BR>\r
-</B>8 Bits of data to be read/written<BR>\r
-<BR>\r
-<B>FF02 - SC - Serial Transfer Control (R/W)<BR>\r
-</B><TABLE><TR><TD><PRE> Bit 7 - Transfer Start Flag (0=No Transfer, 1=Start)\r
- Bit 1 - Clock Speed (0=Normal, 1=Fast) ** CGB Mode Only **\r
- Bit 0 - Shift Clock (0=External Clock, 1=Internal Clock)\r
-</TD></TR></TABLE>The clock signal specifies the rate at which the eight data bits in SB \r
-(FF01) are transferred. When the gameboy is communicating with another \r
-gameboy (or other computer) then either one must supply internal clock, \r
-and the other one must use external clock.<BR>\r
-<BR>\r
-<B>Internal Clock<BR>\r
-</B>In Non-CGB Mode the gameboy supplies an internal clock of 8192Hz only \r
-(allowing to transfer about 1 KByte per second). In CGB Mode four \r
-internal clock rates are available, depending on Bit 1 of the SC \r
-register, and on whether the CGB Double Speed Mode is used:<BR>\r
-<TABLE><TR><TD><PRE> 8192Hz - 1KB/s - Bit 1 cleared, Normal\r
- 16384Hz - 2KB/s - Bit 1 cleared, Double Speed Mode\r
- 262144Hz - 32KB/s - Bit 1 set, Normal\r
- 524288Hz - 64KB/s - Bit 1 set, Double Speed Mode\r
-</TD></TR></TABLE><BR>\r
-<B>External Clock<BR>\r
-</B>The external clock is typically supplied by another gameboy, but might \r
-be supplied by another computer (for example if connected to a PCs \r
-parallel port), in that case the external clock may have any speed. Even \r
-the old/monochrome gameboy is reported to recognizes external clocks of \r
-up to 500KHz. And there is no limitiation into the other direction - \r
-even when suppling an external clock speed of "1 bit per month", then \r
-the gameboy will still eagerly wait for the next bit(s) to be \r
-transferred. It isn't required that the clock pulses are sent at an \r
-regular interval either.<BR>\r
-<BR>\r
-<B>Timeouts<BR>\r
-</B>When using external clock then the transfer will not complete until the \r
-last bit is received. In case that the second gameboy isn't supplying a \r
-clock signal, if it gets turned off, or if there is no second gameboy \r
-connected at all) then transfer will never complete. For this reason the \r
-transfer procedure should use a timeout counter, and abort the \r
-communication if no response has been received during the timeout \r
-interval.<BR>\r
-<BR>\r
-<B>Delays and Synchronization<BR>\r
-</B>The gameboy that is using internal clock should always execute a small \r
-delay between each transfer, in order to ensure that the opponent \r
-gameboy has enough time to prepare itself for the next transfer, ie. the \r
-gameboy with external clock must have set its transfer start bit before \r
-the gameboy with internal clock starts the transfer. Alternately, the \r
-two gameboys could switch between internal and external clock for each \r
-transferred byte to ensure synchronization.<BR>\r
-<BR>\r
-Transfer is initiated by setting the Transfer Start Flag. This bit is \r
-automatically set to 0 at the end of Transfer. Reading this bit can be \r
-used to determine if the transfer is still active.<BR>\r
-<BR>\r
-<B>INT 58 - Serial Interrupt<BR>\r
-</B>When the transfer has completed (ie. after sending/receiving 8 bits, if \r
-any) then an interrupt is requested by setting Bit 3 of the IF Register \r
-(FF0F). When that interrupt is enabled, then the Serial Interrupt vector \r
-at 0058 is called.<BR>\r
-<BR>\r
-<B>XXXXXX...<BR>\r
-</B><BR>\r
-Transmitting and receiving serial data is done simultaneously. The \r
-received data is automatically stored in SB.<BR>\r
-<BR>\r
-The serial I/O port on the Gameboy is a very simple setup and is crude \r
-compared to standard RS-232 (IBM-PC) or RS-485 (Macintosh) serial ports. \r
-There are no start or stop bits.<BR>\r
-<BR>\r
-During a transfer, a byte is shifted in at the same time that a byte is \r
-shifted out. The rate of the shift is determined by whether the clock \r
-source is internal or external.<BR>\r
-The most significant bit is shifted in and out first.<BR>\r
-<BR>\r
-When the internal clock is selected, it drives the clock pin on the game \r
-link port and it stays high when not used. During a transfer it will go \r
-low eight times to clock in/out each bit.<BR>\r
-<BR>\r
-The state of the last bit shifted out determines the state of the output \r
-line until another transfer takes place.<BR>\r
-<BR>\r
-If a serial transfer with internal clock is performed and no external \r
-GameBoy is present, a value of $FF will be received in the transfer.<BR>\r
-<BR>\r
-The following code causes $75 to be shifted out the serial port and a \r
-byte to be shifted into $FF01:<BR>\r
-<BR>\r
-<TABLE><TR><TD><PRE> ld a,$75\r
- ld ($FF01),a\r
- ld a,$81\r
- ld ($FF02),a\r
-</TD></TR></TABLE><BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="timeranddividerregisters"></A><FONT SIZE=+2> Timer and Divider Registers</FONT></TD></TR></TABLE><BR>\r
-<B>FF04 - DIV - Divider Register (R/W)<BR>\r
-</B>This register is incremented at rate of 16384Hz (~16779Hz on SGB). In \r
-CGB Double Speed Mode it is incremented twice as fast, ie. at 32768Hz. \r
-Writing any value to this register resets it to 00h.<BR>\r
-<BR>\r
-<B>FF05 - TIMA - Timer counter (R/W)<BR>\r
-</B>This timer is incremented by a clock frequency specified by the TAC \r
-register ($FF07). When the value overflows (gets bigger than FFh) then \r
-it will be reset to the value specified in TMA (FF06), and an interrupt \r
-will be requested, as described below.<BR>\r
-<BR>\r
-<B>FF06 - TMA - Timer Modulo (R/W)<BR>\r
-</B>When the TIMA overflows, this data will be loaded.<BR>\r
-<BR>\r
-<B>FF07 - TAC - Timer Control (R/W)<BR>\r
-</B><TABLE><TR><TD><PRE> Bit 2 - Timer Stop (0=Stop, 1=Start)\r
- Bits 1-0 - Input Clock Select\r
- 00: 4096 Hz (~4194 Hz SGB)\r
- 01: 262144 Hz (~268400 Hz SGB)\r
- 10: 65536 Hz (~67110 Hz SGB)\r
- 11: 16384 Hz (~16780 Hz SGB)\r
-</TD></TR></TABLE><BR>\r
-<B>INT 50 - Timer Interrupt<BR>\r
-</B>Each time when the timer overflows (ie. when TIMA gets bigger than FFh), \r
-then an interrupt is requested by setting Bit 2 in the IF Register \r
-(FF0F). When that interrupt is enabled, then the CPU will execute it by \r
-calling the timer interrupt vector at 0050h.<BR>\r
-<BR>\r
-<B>Note<BR>\r
-</B>The above described Timer is the built-in timer in the gameboy. It has \r
-nothing to do with the MBC3s battery buffered Real Time Clock - that's a \r
-completely different thing, described in the chapter about Memory \r
-Banking Controllers.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="interrupts"></A><FONT SIZE=+2> Interrupts</FONT></TD></TR></TABLE><BR>\r
-<B>IME - Interrupt Master Enable Flag (Write Only)<BR>\r
-</B><TABLE><TR><TD><PRE> 0 - Disable all Interrupts\r
- 1 - Enable all Interrupts that are enabled in IE Register (FFFF)\r
-</TD></TR></TABLE>The IME flag is used to disable all interrupts, overriding any enabled \r
-bits in the IE Register. It isn't possible to access the IME flag by \r
-using a I/O address, instead IME is accessed directly from the CPU, by \r
-the following opcodes/operations:<BR>\r
-<TABLE><TR><TD><PRE> EI ;Enable Interrupts (ie. IME=1)\r
- DI ;Disable Interrupts (ie. IME=0)\r
- RETI ;Enable Ints & Return (same as the opcode combination EI, RET)\r
- <INT> ;Disable Ints & Call to Interrupt Vector\r
-</TD></TR></TABLE>Whereas <INT> means the operation which is automatically executed by the \r
-CPU when it executes an interrupt.<BR>\r
-<BR>\r
-<B>FFFF - IE - Interrupt Enable (R/W)<BR>\r
-</B><TABLE><TR><TD><PRE> Bit 0: V-Blank Interrupt Enable (INT 40h) (1=Enable)\r
- Bit 1: LCD STAT Interrupt Enable (INT 48h) (1=Enable)\r
- Bit 2: Timer Interrupt Enable (INT 50h) (1=Enable)\r
- Bit 3: Serial Interrupt Enable (INT 58h) (1=Enable)\r
- Bit 4: Joypad Interrupt Enable (INT 60h) (1=Enable)\r
-</TD></TR></TABLE><BR>\r
-<B>FF0F - IF - Interrupt Flag (R/W)<BR>\r
-</B><TABLE><TR><TD><PRE> Bit 0: V-Blank Interrupt Request (INT 40h) (1=Request)\r
- Bit 1: LCD STAT Interrupt Request (INT 48h) (1=Request)\r
- Bit 2: Timer Interrupt Request (INT 50h) (1=Request)\r
- Bit 3: Serial Interrupt Request (INT 58h) (1=Request)\r
- Bit 4: Joypad Interrupt Request (INT 60h) (1=Request)\r
-</TD></TR></TABLE>When an interrupt signal changes from low to high, then the \r
-corresponding bit in the IF register becomes set. For example, Bit 0 \r
-becomes set when the LCD controller enters into the V-Blank period.<BR>\r
-<BR>\r
-<B>Interrupt Requests<BR>\r
-</B>Any set bits in the IF register are only <requesting> an interrupt to be \r
-executed. The actual <execution> happens only if both the IME flag, and \r
-the corresponding bit in the IE register are set, otherwise the \r
-interrupt 'waits' until both IME and IE allow its execution.<BR>\r
-<BR>\r
-<B>Interrupt Execution<BR>\r
-</B>When an interrupt gets executed, the corresponding bit in the IF \r
-register becomes automatically reset by the CPU, and the IME flag \r
-becomes cleared (disabeling any further interrupts until the program \r
-re-enables the interrupts, typically by using the RETI instruction), and \r
-the corresponding Interrupt Vector (that are the addresses in range \r
-0040h-0060h, as shown in IE and IF register decriptions above) becomes \r
-called.<BR>\r
-<BR>\r
-<B>Manually Requesting/Discarding Interrupts<BR>\r
-</B>As the CPU automatically sets and cleares the bits in the IF register it \r
-is usually not required to write to the IF register. However, the user \r
-may still do that in order to manually request (or discard) interrupts. \r
-As for real interrupts, a manually requested interrupt isn't executed \r
-unless/until IME and IE allow its execution.<BR>\r
-<BR>\r
-<B>Interrupt Priorities<BR>\r
-</B>In the following three situations it might happen that more than 1 bit \r
-in the IF register are set, requesting more than one interrupt at once:<BR>\r
-<TABLE><TR><TD><PRE> 1) More than one interrupt signal changed from Low\r
- to High at the same time.\r
- 2) Several interrupts have been requested during a\r
- time in which IME/IE didn't allow these interrupts\r
- to be executed directly.\r
- 3) The user has written a value with several "1" bits\r
- (for example 1Fh) to the IF register.\r
-</TD></TR></TABLE>Provided that IME and IE allow the execution of more than one of the \r
-requested interrupts, then the interrupt with the highest priority \r
-becomes executed first. The priorities are ordered as the bits in the IE \r
-and IF registers, Bit 0 (V-Blank) having the highest priority, and Bit 4 \r
-(Joypad) having the lowest priority.<BR>\r
-<BR>\r
-<B>Nested Interrupts<BR>\r
-</B>The CPU automatically disables all other interrupts by setting IME=0 \r
-when it executes an interrupt. Usually IME remains zero until the \r
-interrupt procedure returns (and sets IME=1 by the RETI instruction). \r
-However, if you want any other interrupts of lower or higher (or same) \r
-priority to be allowed to be executed from inside of the interrupt \r
-procedure, then you can place an EI instruction into the interrupt \r
-procedure.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="cgbregisters"></A><FONT SIZE=+2> CGB Registers</FONT></TD></TR></TABLE><BR>\r
-<B>Forward<BR>\r
-</B>This chapter describes only CGB (Color Gameboy) registers that didn't \r
-fit into normal categories - most CGB registers are described in the \r
-chapter about Video Display (Color Palettes, VRAM Bank, VRAM DMA \r
-Transfers, and changed meaning of Bit 0 of LCDC Control register). Also, \r
-a changed bit is noted in the chapter about the Serial/Link port.<BR>\r
-<BR>\r
-<B>Unlocking CGB functions<BR>\r
-</B>When using any CGB registers (including those in the Video/Link \r
-chapters), you must first unlock CGB features by changing byte 0143h in \r
-the cartridge header. Typically use a value of 80h for games which \r
-support both CGB and monochrome gameboys, and C0h for games which work \r
-on CGBs only. Otherwise, the CGB will operate in monochrome "Non CGB" \r
-compatibility mode.<BR>\r
-<BR>\r
-<B>Detecting CGB (and GBA) functions<BR>\r
-</B>CGB hardware can be detected by examing the CPU accumulator (A-register) \r
-directly after startup. A value of 11h indicates CGB (or GBA) hardware, \r
-if so, CGB functions can be used (if unlocked, see above).<BR>\r
-When A=11h, you may also examine Bit 0 of the CPUs B-Register to \r
-separate between CGB (bit cleared) and GBA (bit set), by that detection \r
-it is possible to use 'repaired' color palette data matching for GBA \r
-displays.<BR>\r
-<BR>\r
-<B>FF4D - KEY1 - CGB Mode Only - Prepare Speed Switch<BR>\r
-</B><TABLE><TR><TD><PRE> Bit 7: Current Speed (0=Normal, 1=Double) (Read Only)\r
- Bit 0: Prepare Speed Switch (0=No, 1=Prepare) (Read/Write)\r
-</TD></TR></TABLE>This register is used to prepare the gameboy to switch between CGB \r
-Double Speed Mode and Normal Speed Mode. The actual speed switch is \r
-performed by executing a STOP command after Bit 0 has been set. After \r
-that Bit 0 will be cleared automatically, and the gameboy will operate \r
-at the 'other' speed. The recommended speed switching procedure in \r
-pseudo code would be:<BR>\r
-<TABLE><TR><TD><PRE> IF KEY1_BIT7 <> DESIRED_SPEED THEN\r
- IE=00H ;(FFFF)=00h\r
- JOYP=30H ;(FF00)=30h\r
- KEY1=01H ;(FF4D)=01h\r
- STOP ;STOP\r
- ENDIF\r
-</TD></TR></TABLE>The CGB is operating in Normal Speed Mode when it is turned on. Note \r
-that using the Double Speed Mode increases the power consumption, it \r
-would be recommended to use Single Speed whenever possible. However, the \r
-display will flicker (white) for a moment during speed switches, so this \r
-cannot be done permanentely.<BR>\r
-In Double Speed Mode the following will operate twice as fast as normal:<BR>\r
-<TABLE><TR><TD><PRE> The CPU (2.10 MHz, 1 Cycle = approx. 0.5us)\r
- Timer and Divider Registers\r
- Serial Port (Link Cable)\r
- DMA Transfer to OAM\r
-</TD></TR></TABLE>And the following will keep operating as usual:<BR>\r
-<TABLE><TR><TD><PRE> LCD Video Controller\r
- HDMA Transfer to VRAM\r
- All Sound Timings and Frequencies\r
-</TD></TR></TABLE><BR>\r
-<B>FF56 - RP - CGB Mode Only - Infrared Communications Port<BR>\r
-</B>This register allows to input and output data through the CGBs built-in \r
-Infrared Port. When reading data, bit 6 and 7 must be set (and obviously \r
-Bit 0 must be cleared - if you don't want to receive your own gameboys \r
-IR signal). After sending or receiving data you should reset the \r
-register to 00h to reduce battery power consumption again.<BR>\r
-<TABLE><TR><TD><PRE> Bit 0: Write Data (0=LED Off, 1=LED On) (Read/Write)\r
- Bit 1: Read Data (0=Receiving IR Signal, 1=Normal) (Read Only)\r
- Bit 6-7: Data Read Enable (0=Disable, 3=Enable) (Read/Write)\r
-</TD></TR></TABLE>Note that the receiver will adapt itself to the normal level of IR \r
-pollution in the air, so if you would send a LED ON signal for a longer \r
-period, then the receiver would treat that as normal (=OFF) after a \r
-while. For example, a Philips TV Remote Control sends a series of 32 LED \r
-ON/OFF pulses (length 10us ON, 17.5us OFF each) instead of a permanent \r
-880us LED ON signal.<BR>\r
-Even though being generally CGB compatible, the GBA does not include an \r
-infra-red port.<BR>\r
-<BR>\r
-<B>FF70 - SVBK - CGB Mode Only - WRAM Bank<BR>\r
-</B>In CGB Mode 32 KBytes internal RAM are available. This memory is divided \r
-into 8 banks of 4 KBytes each. Bank 0 is always available in memory at \r
-C000-CFFF, Bank 1-7 can be selected into the address space at D000-DFFF.<BR>\r
-<TABLE><TR><TD><PRE> Bit 0-2 Select WRAM Bank (Read/Write)\r
-</TD></TR></TABLE>Writing a value of 01h-07h will select Bank 1-7, writing a value of 00h \r
-will select Bank 1 either.<BR>\r
-<BR>\r
-<B>FF6C - Undocumented (FEh) - Bit 0 (Read/Write) - CGB Mode Only<BR>\r
-FF72 - Undocumented (00h) - Bit 0-7 (Read/Write)<BR>\r
-FF73 - Undocumented (00h) - Bit 0-7 (Read/Write)<BR>\r
-FF74 - Undocumented (00h) - Bit 0-7 (Read/Write) - CGB Mode Only<BR>\r
-FF75 - Undocumented (8Fh) - Bit 4-6 (Read/Write)<BR>\r
-FF76 - Undocumented (00h) - Always 00h (Read Only)<BR>\r
-FF77 - Undocumented (00h) - Always 00h (Read Only)<BR>\r
-</B>These are undocumented CGB Registers. The numbers in brackets () \r
-indicate the initial values. Purpose of these registers is unknown (if \r
-any). Registers FF6C and FF74 are always FFh if the CGB is in Non CGB \r
-Mode.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="sgbfunctions"></A><FONT SIZE=+2> SGB Functions</FONT></TD></TR></TABLE><BR>\r
-<B>General Information<BR>\r
-</B><A HREF="#sgbdescription">SGB Description</A><BR>\r
-<A HREF="#sgbunlockinganddetectingsgbfunctions">SGB Unlocking and Detecting SGB Functions</A><BR>\r
-<A HREF="#sgbcommandpackettransfers">SGB Command Packet Transfers</A><BR>\r
-<A HREF="#sgbvramtransfers">SGB VRAM Transfers</A><BR>\r
-<A HREF="#sgbcommandsummary">SGB Command Summary</A><BR>\r
-<A HREF="#sgbcolorpalettesoverview">SGB Color Palettes Overview</A><BR>\r
-<BR>\r
-<B>SGB Commands<BR>\r
-</B><A HREF="#sgbpalettecommands">SGB Palette Commands</A><BR>\r
-<A HREF="#sgbcolorattributecommands">SGB Color Attribute Commands</A><BR>\r
-<A HREF="#sgbsoundfunctions">SGB Sound Functions</A><BR>\r
-<A HREF="#sgbsystemcontrolcommands">SGB System Control Commands</A><BR>\r
-<A HREF="#sgbmultiplayercommand">SGB Multiplayer Command</A><BR>\r
-<A HREF="#sgbborderandobjcommands">SGB Border and OBJ Commands</A><BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="sgbdescription"></A><FONT SIZE=+2> SGB Description</FONT></TD></TR></TABLE><BR>\r
-<B>General Description<BR>\r
-</B>Basically, the SGB (Super Gameboy) is an adapter cartridge that allows \r
-to play gameboy games on a SNES (Super Nintendo Entertainment System) \r
-gaming console. In detail, you plug the gameboy cartridge into the SGB \r
-cartridge, then plug the SGB cartridge into the SNES, and then connect \r
-the SNES to your TV Set. In result, games can be played and viewed on \r
-the TV Set, and are controlled by using the SNES joypad(s).<BR>\r
-<BR>\r
-<B>More Technical Description<BR>\r
-</B>The SGB cartridge just contains a normal gameboy CPU and normal gameboy \r
-video controller. Normally the video signal from this controller would \r
-be sent to the LCD screen, however, in this special case the SNES read \r
-out the video signal and displays it on the TV set by using a special \r
-SNES BIOS ROM which is located in the SGB cartridge. Also, normal \r
-gameboy sound output is forwared to the SNES and output to the TV Set, \r
-vice versa, joypad input is forwared from the SNES controller(s) to the \r
-gameboy joypad inputs.<BR>\r
-<BR>\r
-<B>Normal Monochrome Games<BR>\r
-</B>Any gameboy games which have been designed for normal monochrome \r
-handheld gameboys will work with the SGB hardware as well. The SGB will \r
-apply a four color palette to these games by replacing the normal four \r
-grayshades. The 160x144 pixel gamescreen is displayed in the middle of \r
-the 256x224 pixel SNES screen (the unused area is filled by a screen \r
-border bitmap). The user may access built-in menues, allowing to change \r
-color palette data, to select between several pre-defined borders, etc.<BR>\r
-<BR>\r
-Games that have been designed to support SGB functions may also access \r
-the following additional features:<BR>\r
-<BR>\r
-<B>Colorized Game Screen<BR>\r
-</B>There's limited ability to colorize the gamescreen by assigning custom \r
-color palettes to each 20x18 display characters, however, this works \r
-mainly for static display data such like title screens or status bars, \r
-the 20x18 color attribute map is non-scrollable, and it is not possible \r
-to assign separate colors to moveable foreground sprites (OBJs), so that \r
-animated screen regions will be typically restricted to using a single \r
-palette of four colors only.<BR>\r
-<BR>\r
-<B>SNES Foreground Sprites<BR>\r
-</B>Up to 24 foreground sprites (OBJs) of 8x8 or 16x16 pixels, 16 colors can \r
-be displayed. When replacing (or just overlaying) the normal gameboy \r
-OBJs by SNES OBJs it'd be thus possible to display OBJs with other \r
-colors than normal background area. This method doesn't appear to be \r
-very popular, even though it appears to be quite easy to implement, \r
-however, the bottommost character line of the gamescreen will be masked \r
-out because this area is used to transfer OAM data to the SNES.<BR>\r
-<BR>\r
-<B>The SGB Border<BR>\r
-</B>The possibly most popular and most impressive feature is to replace the \r
-default SGB screen border by a custom bitmap which is stored in the game \r
-cartridge.<BR>\r
-<BR>\r
-<B>Multiple Joypads<BR>\r
-</B>Up to four joypads can be conected to the SNES, and SGB software may \r
-read-out each of these joypads separately, allowing up to four players \r
-to play the same game simultaneously. Unlike for multiplayer handheld \r
-games, this requires only one game cartridge and only one SGB/SNES, and \r
-no link cables are required, the downside is that all players must share \r
-the same display screen.<BR>\r
-<BR>\r
-<B>Sound Functions<BR>\r
-</B>Beside for normal gameboy sound, a number of digital sound effects is \r
-pre-defined in the SNES BIOS, these effects may be accessed quite \r
-easily. Programmers whom are familiar with SNES sounds may also access \r
-the SNES sound chip, or use the SNES MIDI engine directly in order to \r
-produce other sound effects or music.<BR>\r
-<BR>\r
-<B>Taking Control of the SNES CPU<BR>\r
-</B>Finally, it is possible to write program code or data into SNES memory, \r
-and to execute such program code by using the SNES CPU.<BR>\r
-<BR>\r
-<B>SGB System Clock<BR>\r
-</B>Because the SGB is synchronized to the SNES CPU, the gameboy system \r
-clock is directly chained to the SNES system clock. In result, the \r
-gameboy CPU, video controller, timers, and sound frequencies will be all \r
-operated approx 2.4% faster as by normal gameboys.<BR>\r
-Basically, this should be no problem, and the game will just run a \r
-little bit faster. However sensitive musicians may notice that sound \r
-frequencies are a bit too high, programs that support SGB functions may \r
-avoid this effect by reducing frequencies of gameboy sounds when having \r
-detected SGB hardware.<BR>\r
-Also, I think that I've heard that SNES models which use a 50Hz display \r
-refresh rate (rather than 60Hz) are resulting in respectively slower \r
-SGB/gameboy timings ???<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="sgbunlockinganddetectingsgbfunctions"></A><FONT SIZE=+2> SGB Unlocking and Detecting SGB Functions</FONT></TD></TR></TABLE><BR>\r
-<B>Cartridge Header<BR>\r
-</B>SGB games are required to have a cartridge header with Nintendo and \r
-proper checksum just as normal gameboy games. Also, two special entries \r
-must be set in order to unlock SGB functions:<BR>\r
-<TABLE><TR><TD><PRE> 146h - SGB Flag - Must be set to 03h for SGB games\r
- 14Bh - Old Licensee Code - Must be set 33h for SGB games\r
-</TD></TR></TABLE>When these entries aren't set, the game will still work just like all \r
-'monochrome' gameboy games, but it cannot access any of the special SGB \r
-functions.<BR>\r
-<BR>\r
-<B>Detecting SGB hardware<BR>\r
-</B>The recommended detection method is to send a MLT_REQ command which \r
-enables two (or four) joypads. A normal handheld gameboy will ignore \r
-this command, a SGB will now return incrementing joypad IDs each time \r
-when deselecting keyboard lines (see MLT_REQ description for details).<BR>\r
-Now read-out joypad state/IDs several times, and if the ID-numbers are \r
-changing, then it is a SGB (a normal gameboy would typically always \r
-return 0Fh as ID). Finally, when not intending to use more than one \r
-joypad, send another MLT_REQ command in order to re-disable the \r
-multi-controller mode.<BR>\r
-Detection works regardless of whether and how many joypads are \r
-physically connected to the SNES. However, detection works only when \r
-having unlocked SGB functions in the cartridge header, as described \r
-above. <BR>\r
-<BR>\r
-<B>Separating between SGB and SGB2<BR>\r
-</B>It is also possible to separate between SGB and SGB2 models by examining \r
-the inital value of the accumulator (A-register) directly after startup.<BR>\r
-<TABLE><TR><TD><PRE> 01h SGB or Normal Gameboy (DMG)\r
- FFh SGB2 or Pocket Gameboy\r
- 11h CGB or GBA\r
-</TD></TR></TABLE>Because values 01h and FFh are shared for both handhelds and SGBs, it is \r
-still required to use the above MLT_REQ detection procedure. As far as I \r
-know the SGB2 doesn't have any extra features which'd require separate \r
-SGB2 detection except for curiosity purposes, for example, the game \r
-"Tetris DX" chooses to display an alternate SGB border on SGB2s.<BR>\r
-<BR>\r
-Reportedly, some SGB models include link ports (just like handheld \r
-gameboy) (my own SGB does not have such an port), possibly this feature \r
-is available in SGB2-type models only ???<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="sgbcommandpackettransfers"></A><FONT SIZE=+2> SGB Command Packet Transfers</FONT></TD></TR></TABLE><BR>\r
-Command packets (aka Register Files) are transferred from the gameboy to \r
-the SNES by using P14 and P15 output lines of the JOYPAD register \r
-(FF00h), these lines are normally used to select the two rows in the \r
-gameboy keyboard matrix (which still works).<BR>\r
-<BR>\r
-<B>Transferring Bits<BR>\r
-</B>A command packet transfer must be initiated by setting both P14 and P15 \r
-to LOW, this will reset and start the SNES packet receiving program. \r
-Data is then transferred (LSB first), setting P14=LOW will indicate a \r
-"0" bit, and setting P15=LOW will indicate a "1" bit. For example:<BR>\r
-<TABLE><TR><TD><PRE> RESET 0 0 1 1 0 1 0\r
- P14 --_---_---_-----------_-------_--...\r
- P15 --_-----------_---_-------_------...\r
-</TD></TR></TABLE>Data and reset pulses must be kept LOW for at least 5us. P14 and P15 \r
-must be kept both HIGH for at least 15us between any pulses.<BR>\r
-Obviously, it'd be no good idea to access the JOYPAD register during the \r
-transfer, for example, in case that your VBlank interrupt procedure \r
-reads-out joypad states each frame, be sure to disable that interrupt \r
-during the transfer (or disable only the joypad procedure by using a \r
-software flag).<BR>\r
-<BR>\r
-<B>Transferring Packets<BR>\r
-</B>Each packet is invoked by a RESET pulse, then 128 bits of data are \r
-transferred (16 bytes, LSB of first byte first), and finally, a "0"-bit \r
-must be transferred as stop bit. The structure of normal packets is:<BR>\r
-<TABLE><TR><TD><PRE> 1 PULSE Reset\r
- 1 BYTE Command Code*8+Length\r
- 15 BYTES Parameter Data\r
- 1 BIT Stop Bit (0)\r
-</TD></TR></TABLE>The above 'Length' indicates the total number of packets (1-7, including \r
-the first packet) which will be sent, ie. if more than 15 parameter \r
-bytes are used, then further packet(s) will follow, as such:<BR>\r
-<TABLE><TR><TD><PRE> 1 PULSE Reset\r
- 16 BYTES Parameter Data\r
- 1 BIT Stop Bit (0)\r
-</TD></TR></TABLE>By using all 7 packets, up to 111 data bytes (15+16*6) may be sent.<BR>\r
-Unused bytes at the end of the last packet must be set to zero.<BR>\r
-A 60ms (4 frames) delay should be invoked between each packet transfer.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="sgbvramtransfers"></A><FONT SIZE=+2> SGB VRAM Transfers</FONT></TD></TR></TABLE><BR>\r
-<B>Overview<BR>\r
-</B>Beside for the packet transfer method, larger data blocks of 4KBytes can \r
-be transferred by using the video signal. These transfers are invoked by \r
-first sending one of the commands with the ending _TRN (by using normal \r
-packet transfer), the 4K data block is then read-out by the SNES from \r
-gameboy display memory during the next frame.<BR>\r
-<BR>\r
-<B>Transfer Data<BR>\r
-</B>Normally, transfer data should be stored at 8000h-8FFFh in gameboy VRAM,<BR>\r
-even though the SNES receives the data in from display scanlines, it \r
-will automatically re-produce the same ordering of bits and bytes, as \r
-being originally stored at 8000h-8FFFh in gameboy memory.<BR>\r
-<BR>\r
-<B>Preparing the Display<BR>\r
-</B>The above method works only when recursing the following things: BG Map \r
-must display unsigned characters 00h-FFh on the screen; 00h..13h in \r
-first line, 14h..27h in next line, etc. The gameboy display must be \r
-enabled, the display may not be scrolled, OBJ sprites should not overlap \r
-the background tiles, the BGP palette register must be set to E4h.<BR>\r
-<BR>\r
-<B>Transfer Time<BR>\r
-</B>Note that the transfer data should be prepared in VRAM <before> sending \r
-the transfer command packet. The actual transfer starts at the beginning \r
-of the next frame after the command has been sent, and the transfer ends \r
-at the end of the 5th frame after the command has been sent (not \r
-counting the frame in which the command has been sent).<BR>\r
-<BR>\r
-<B>Avoiding Screen Garbage<BR>\r
-</B>The display will contain 'garbage' during the transfer, this dirt-effect \r
-can be avoided by freezing the screen (in the state which has been \r
-displayed before the transfer) by using the MASK_EN command.<BR>\r
-Of course, this works only when actually executing the game on a SGB \r
-(and not on normal handheld gameboys), it'd be thus required to detect \r
-the presence of SGB hardware before blindly sending VRAM data.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="sgbcommandsummary"></A><FONT SIZE=+2> SGB Command Summary</FONT></TD></TR></TABLE><BR>\r
-<B>SGB System Command Table<BR>\r
-</B><TABLE><TR><TD><PRE> Code Name Expl.\r
- 00 PAL01 Set SGB Palette 0,1 Data\r
- 01 PAL23 Set SGB Palette 2,3 Data\r
- 02 PAL03 Set SGB Palette 0,3 Data\r
- 03 PAL12 Set SGB Palette 1,2 Data\r
- 04 ATTR_BLK "Block" Area Designation Mode\r
- 05 ATTR_LIN "Line" Area Designation Mode\r
- 06 ATTR_DIV "Divide" Area Designation Mode\r
- 07 ATTR_CHR "1CHR" Area Designation Mode\r
- 08 SOUND Sound On/Off\r
- 09 SOU_TRN Transfer Sound PRG/DATA\r
- 0A PAL_SET Set SGB Palette Indirect\r
- 0B PAL_TRN Set System Color Palette Data\r
- 0C ATRC_EN Enable/disable Attraction Mode\r
- 0D TEST_EN Speed Function\r
- 0E ICON_EN SGB Function\r
- 0F DATA_SND SUPER NES WRAM Transfer 1\r
- 10 DATA_TRN SUPER NES WRAM Transfer 2\r
- 11 MLT_REG Controller 2 Request\r
- 12 JUMP Set SNES Program Counter\r
- 13 CHR_TRN Transfer Character Font Data\r
- 14 PCT_TRN Set Screen Data Color Data\r
- 15 ATTR_TRN Set Attribute from ATF\r
- 16 ATTR_SET Set Data to ATF\r
- 17 MASK_EN Game Boy Window Mask\r
- 18 OBJ_TRN Super NES OBJ Mode\r
-</TD></TR></TABLE><BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="sgbcolorpalettesoverview"></A><FONT SIZE=+2> SGB Color Palettes Overview</FONT></TD></TR></TABLE><BR>\r
-<B>Available SNES Palettes<BR>\r
-</B>The SGB/SNES provides 8 palettes of 16 colors each, each color may be \r
-defined out of a selection of 34768 colors (15 bit). Palettes 0-3 are \r
-used to colorize the gamescreen, only the first four colors of each of \r
-these palettes are used. Palettes 4-7 are used for the SGB Border, all \r
-16 colors of each of these palettes may be used.<BR>\r
-<BR>\r
-<B>Color 0 Restriction<BR>\r
-</B>Color 0 of each of the eight palettes is transparent, causing the \r
-backdrop color to be displayed instead. The backdrop color is typically \r
-defined by the most recently color being assigned to Color 0 (regardless \r
-of the palette number being used for that operation).<BR>\r
-Effectively, gamescreen palettes can have only three custom colors each, \r
-and SGB border palettes only 15 colors each, additionally, color 0 can \r
-be used for for all palettes, which will then all share the same color \r
-though.<BR>\r
-<BR>\r
-<B>Translation of Grayshades into Colors<BR>\r
-</B>Because the SGB/SNES reads out the gameboy video controllers display \r
-signal, it translates the different grayshades from the signal into SNES \r
-colors as such:<BR>\r
-<TABLE><TR><TD><PRE> White --> Color 0\r
- Light Gray --> Color 1\r
- Dark Gray --> Color 2\r
- Black --> Color 3\r
-</TD></TR></TABLE>Note that gameboy colors 0-3 are assigned to user-selectable grayshades \r
-by the gameboys BGP, OBP1, and OBP2 registers. There is thus no fixed \r
-relationship between gameboy colors 0-3 and SNES colors 0-3.<BR>\r
-<BR>\r
-<B>Using Gameboy BGP/OBP Registers<BR>\r
-</B>A direct translation of color 0-3 into color 0-3 may be produced by \r
-setting BGP/OBP registers to a value of 0E4h each. However, in case that \r
-your program uses black background for example, then you may internally \r
-assign background as "White" at the gameboy side by BGP/OBP registers \r
-(which is then interpreted as SNES color 0, which is shared for all SNES \r
-palettes). The advantage is that you may define Color 0 as Black at the \r
-SNES side, and may assign custom colors for Colors 1-3 of each SNES \r
-palette.<BR>\r
-<BR>\r
-<B>System Color Palette Memory<BR>\r
-</B>Beside for the actually visible palettes, up to 512 palettes of 4 colors \r
-each may be defined in SNES RAM. Basically, this is completely \r
-irrelevant because the palettes are just stored in RAM whithout any \r
-relationship to the displayed picture, anyways, these pre-defined colors \r
-may be transferred to actually visible palettes slightly faster as when \r
-transferring palette data by separate command packets.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="sgbpalettecommands"></A><FONT SIZE=+2> SGB Palette Commands</FONT></TD></TR></TABLE><BR>\r
-<B>SGB Command 00h - PAL01<BR>\r
-</B>Transmit color data for SGB palette 0, color 0-3, and for SGB palette 1, \r
-color 1-3 (without separate color 0).<BR>\r
-<TABLE><TR><TD><PRE> Byte Content\r
- 0 Command*8+Length (fixed length=01h)\r
- 1-E Color Data for 7 colors of 2 bytes (16bit) each:\r
- Bit 0-4 - Red Intensity (0-31)\r
- Bit 5-9 - Green Intensity (0-31)\r
- Bit 10-14 - Blue Intensity (0-31)\r
- Bit 15 - Not used (zero)\r
- F Not used (00h)\r
-</TD></TR></TABLE>The value transferred as color 0 will be applied for all eight palettes.<BR>\r
-<BR>\r
-<B>SGB Command 01h - PAL23<BR>\r
-</B>Same as above PAL01, but for Palettes 2 and 3 respectively.<BR>\r
-<BR>\r
-<B>SGB Command 02h - PAL03<BR>\r
-</B>Same as above PAL01, but for Palettes 0 and 3 respectively.<BR>\r
-<BR>\r
-<B>SGB Command 03h - PAL12<BR>\r
-</B>Same as above PAL01, but for Palettes 1 and 2 respectively.<BR>\r
-<BR>\r
-<B>SGB Command 0Ah - PAL_SET<BR>\r
-</B>Used to copy pre-defined palette data from SGB system color palette to \r
-actual SGB palette.<BR>\r
-<TABLE><TR><TD><PRE> Byte Content\r
- 0 Command*8+Length (fixed length=1)\r
- 1-2 System Palette number for SGB Color Palette 0 (0-511)\r
- 3-4 System Palette number for SGB Color Palette 1 (0-511)\r
- 5-6 System Palette number for SGB Color Palette 2 (0-511)\r
- 7-8 System Palette number for SGB Color Palette 3 (0-511)\r
- 9 Attribute File\r
- Bit 0-5 - Attribute File Number (00h-2Ch) (Used only if Bit7=1)\r
- Bit 6 - Cancel Mask (0=No change, 1=Yes)\r
- Bit 7 - Use Attribute File (0=No, 1=Apply above ATF Number)\r
- A-F Not used (zero)\r
-</TD></TR></TABLE>Before using this function, System Palette data should be initialized by \r
-PAL_TRN command, and (when used) Attribute File data should be \r
-initialized by ATTR_TRN.<BR>\r
-<BR>\r
-<B>SGB Command 0Bh - PAL_TRN<BR>\r
-</B>Used to initialize SGB system color palettes in SNES RAM.<BR>\r
-System color palette memory contains 512 pre-defined palettes, these \r
-palettes do not directly affect the display, however, the PAL_SET \r
-command may be later used to transfer four of these 'logical' palettes \r
-to actual visible 'physical' SGB palettes. Also, the OBJ_TRN function \r
-will use groups of 4 System Color Palettes (4*4 colors) for SNES OBJ \r
-palettes (16 colors).<BR>\r
-<TABLE><TR><TD><PRE> Byte Content\r
- 0 Command*8+Length (fixed length=1)\r
- 1-F Not used (zero)\r
-</TD></TR></TABLE>The palette data is sent by VRAM-Transfer (4 KBytes).<BR>\r
-<TABLE><TR><TD><PRE> 000-FFF Data for System Color Palette 0-511\r
-</TD></TR></TABLE>Each Palette consists of four 16bit-color definitions (8 bytes).<BR>\r
-Note: The data is stored at 3000h-3FFFh in SNES memory.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="sgbcolorattributecommands"></A><FONT SIZE=+2> SGB Color Attribute Commands</FONT></TD></TR></TABLE><BR>\r
-<B>SGB Command 04h - ATTR_BLK<BR>\r
-</B>Used to specify color attributes for the inside or outside of one or \r
-more rectangular screen regions.<BR>\r
-<TABLE><TR><TD><PRE> Byte Content\r
- 0 Command*8+Length (length=1..7)\r
- 1 Number of Data Sets (01h..12h)\r
- 2-7 Data Set #1\r
- Byte 0 - Control Code (0-7)\r
- Bit 0 - Change Colors inside of surrounded area (1=Yes)\r
- Bit 1 - Change Colors of surrounding character line (1=Yes)\r
- Bit 2 - Change Colors outside of surrounded area (1=Yes)\r
- Bit 3-7 - Not used (zero)\r
- Exception: When changing only the Inside or Outside, then the\r
- Surrounding line becomes automatically changed to same color.\r
- Byte 1 - Color Palette Designation\r
- Bit 0-1 - Palette Number for inside of surrounded area\r
- Bit 2-3 - Palette Number for surrounding character line\r
- Bit 4-5 - Palette Number for outside of surrounded area\r
- Bit 6-7 - Not used (zero)\r
- Data Set Byte 2 - Coordinate X1 (left)\r
- Data Set Byte 3 - Coordinate Y1 (upper)\r
- Data Set Byte 4 - Coordinate X2 (right)\r
- Data Set Byte 5 - Coordinate Y2 (lower)\r
- Specifies the coordinates of the surrounding rectangle.\r
- 8-D Data Set #2 (if any)\r
- E-F Data Set #3 (continued at 0-3 in next packet) (if any)\r
-</TD></TR></TABLE>When sending three or more data sets, data is continued in further \r
-packet(s). Unused bytes at the end of the last packet should be set to \r
-zero. The format of the separate Data Sets is described below.<BR>\r
-<BR>\r
-<B>SGB Command 05h - ATTR_LIN<BR>\r
-</B>Used to specify color attributes of one or more horizontal or vertical \r
-character lines.<BR>\r
-<TABLE><TR><TD><PRE> Byte Content\r
- 0 Command*8+Length (length=1..7)\r
- 1 Number of Data Sets (01h..6Eh) (one byte each)\r
- 2 Data Set #1\r
- Bit 0-4 - Line Number (X- or Y-coordinate, depending on bit 7)\r
- Bit 5-6 - Palette Number (0-3)\r
- Bit 7 - H/V Mode Bit (0=Vertical line, 1=Horizontal Line)\r
- 3 Data Set #2 (if any)\r
- 4 Data Set #3 (if any)\r
- etc.\r
-</TD></TR></TABLE>When sending 15 or more data sets, data is continued in further \r
-packet(s). Unused bytes at the end of the last packet should be set to \r
-zero. The format of the separate Data Sets (one byte each) is described \r
-below.<BR>\r
-The length of each line reaches from one end of the screen to the other \r
-end. In case that some lines overlap each other, then lines from \r
-lastmost data sets will overwrite lines from previous data sets.<BR>\r
-<BR>\r
-<B>SGB Command 06h - ATTR_DIV<BR>\r
-</B>Used to split the screen into two halfes, and to assign separate color \r
-attributes to each half, and to the division line between them.<BR>\r
-<TABLE><TR><TD><PRE> Byte Content\r
- 0 Command*8+Length (fixed length=1)\r
- 1 Color Palette Numbers and H/V Mode Bit\r
- Bit 0-1 Palette Number below/right of division line\r
- Bit 2-3 Palette Number above/left of division line\r
- Bit 4-5 Palette Number for division line\r
- Bit 6 H/V Mode Bit (0=split left/right, 1=split above/below)\r
- 2 X- or Y-Coordinate (depending on H/V bit)\r
- 3-F Not used (zero)\r
-</TD></TR></TABLE><BR>\r
-<B>SGB Command 07h - ATTR_CHR<BR>\r
-</B>Used to specify color attributes for separate characters.<BR>\r
-<TABLE><TR><TD><PRE> Byte Content\r
- 0 Command*8+Length (length=1..6)\r
- 1 Beginning X-Coordinate\r
- 2 Beginning Y-Coordinate\r
- 3-4 Number of Data Sets (1-360)\r
- 5 Writing Style (0=Left to Right, 1=Top to Bottom)\r
- 6 Data Sets 1-4 (Set 1 in MSBs, Set 4 in LSBs)\r
- 7 Data Sets 5-8 (if any)\r
- 8 Data Sets 9-12 (if any)\r
- etc.\r
-</TD></TR></TABLE>When sending 41 or more data sets, data is continued in further \r
-packet(s). Unused bytes at the end of the last packet should be set to \r
-zero. Each data set consists of two bits, indicating the palette number \r
-for one character.<BR>\r
-Depending on the writing style, data sets are written from left to \r
-right, or from top to bottom. In either case the function wraps to the \r
-next row/column when reaching the end of the screen.<BR>\r
-<BR>\r
-<B>SGB Command 15h - ATTR_TRN<BR>\r
-</B>Used to initialize Attribute Files (ATFs) in SNES RAM. Each ATF consists \r
-of 20x18 color attributes for the gameboy screen. This function does not \r
-directly affect display attributes. Instead, one of the defined ATFs may \r
-be copied to actual display memory at a later time by using ATTR_SET or \r
-PAL_SET functions.<BR>\r
-<TABLE><TR><TD><PRE> Byte Content\r
- 0 Command*8+Length (fixed length=1)\r
- 1-F Not used (zero)\r
-</TD></TR></TABLE>The ATF data is sent by VRAM-Transfer (4 KBytes).<BR>\r
-<TABLE><TR><TD><PRE> 000-FD1 Data for ATF0 through ATF44 (4050 bytes)\r
- FD2-FFF Not used\r
-</TD></TR></TABLE>Each ATF consists of 90 bytes, that are 5 bytes (20x2bits) for each of \r
-the 18 character lines of the gameboy window. The two most significant \r
-bits of the first byte define the color attribute (0-3) for the first \r
-character of the first line, the next two bits the next character, and \r
-so on.<BR>\r
-<BR>\r
-<B>SGB Command 16h - ATTR_SET<BR>\r
-</B>Used to transfer attributes from Attribute File (ATF) to gameboy window.<BR>\r
-<TABLE><TR><TD><PRE> Byte Content\r
- 0 Command*8+Length (fixed length=1)\r
- 1 Attribute File Number (00-2Ch), Bit 6=Cancel Mask\r
- 2-F Not used (zero)\r
-</TD></TR></TABLE>When above Bit 6 is set, the gameboy screen becomes re-enabled after the \r
-transfer (in case it has been disabled/frozen by MASK_EN command).<BR>\r
-Note: The same functions may be (optionally) also included in PAL_SET \r
-commands, as described in the chapter about Color Palette Commands.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="sgbsoundfunctions"></A><FONT SIZE=+2> SGB Sound Functions</FONT></TD></TR></TABLE><BR>\r
-<B>SGB Command 08h - SOUND<BR>\r
-</B>Used to start/stop internal sound effect, start/stop sound using \r
-internal tone data.<BR>\r
-<TABLE><TR><TD><PRE> Byte Content\r
- 0 Command*8+Length (fixed length=1)\r
- 1 Sound Effect A (Port 1) Decrescendo 8bit Sound Code\r
- 2 Sound Effect B (Port 2) Sustain 8bit Sound Code\r
- 3 Sound Effect Attributes\r
- Bit 0-1 - Sound Effect A Pitch (0..3=Low..High)\r
- Bit 2-3 - Sound Effect A Volume (0..2=High..Low, 3=Mute on)\r
- Bit 4-5 - Sound Effect B Pitch (0..3=Low..High)\r
- Bit 6-7 - Sound Effect B Volume (0..2=High..Low, 3=Not used)\r
- 4 Music Score Code (must be zero if not used)\r
- 5-F Not used (zero)\r
-</TD></TR></TABLE>See Sound Effect Tables below for a list of available pre-defined effects.<BR>\r
-"Notes"<BR>\r
-1) Mute is only active when both bits D2 and D3 are 1.<BR>\r
-2) When the volume is set for either Sound Effect A or Sound Effect B, \r
-mute is turned off.<BR>\r
-3) When Mute on/off has been executed, the sound fades out/fades in.<BR>\r
-4) Mute on/off operates on the (BGM) which is reproduced by Sound Effect \r
-A, Sound Effect B, and the Super NES APU. A "mute off" flag does not \r
-exist by itself. When mute flag is set, volume and pitch of Sound Effect \r
-A (port 1) and Sound Effect B (port 2) must be set.<BR>\r
-<BR>\r
-<B>SGB Command 09h - SOU_TRN<BR>\r
-</B>Used to transfer sound code or data to SNES Audio Processing Unit memory \r
-(APU-RAM).<BR>\r
-<TABLE><TR><TD><PRE> Byte Content\r
- 0 Command*8+Length (fixed length=1)\r
- 1-F Not used (zero)\r
-</TD></TR></TABLE>The sound code/data is sent by VRAM-Transfer (4 KBytes).<BR>\r
-<TABLE><TR><TD><PRE> 000 One (or two ???) 16bit expression(s ???) indicating the\r
- transfer destination address and transfer length.\r
- ...-... Transfer Data\r
- ...-FFF Remaining bytes not used\r
-</TD></TR></TABLE>Possible destinations in APU-RAM are:<BR>\r
-<TABLE><TR><TD><PRE> 0400h-2AFFh APU-RAM Program Area (9.75KBytes)\r
- 2B00h-4AFFh APU-RAM Sound Score Area (8Kbytes)\r
- 4DB0h-EEFFh APU-RAM Sampling Data Area (40.25 Kbytes)\r
-</TD></TR></TABLE>This function may be used to take control of the SNES sound chip, and/or \r
-to access the SNES MIDI engine. In either case it requires deeper \r
-knowledge of SNES sound programming.<BR>\r
-<BR>\r
-<B>SGB Sound Effect A/B Tables<BR>\r
-</B>Below lists the digital sound effects that are pre-defined in the \r
-SGB/SNES BIOS, and which can be used with the SGB "SOUND" Command.<BR>\r
-Effect A and B may be simultaneously reproduced.<BR>\r
-The P-column indicates the recommended Pitch value, the V-column \r
-indicates the numbers of Voices used. Sound Effect A uses voices 6,7. \r
-Sound Effect B uses voices 0,1,4,5. Effects that use less voices will \r
-use only the upper voices (eg. 4,5 for Effect B with only two voices).<BR>\r
-<BR>\r
-<B>Sound Effect A Flag Table<BR>\r
-</B><TABLE><TR><TD><PRE> Code Description P V Code Description P V\r
- 00 Dummy flag, re-trigger - 2 18 Fast Jump 3 1\r
- 80 Effect A, stop/silent - 2 19 Jet (rocket) takeoff 0 1\r
- 01 Nintendo 3 1 1A Jet (rocket) landing 0 1\r
- 02 Game Over 3 2 1B Cup breaking 2 2\r
- 03 Drop 3 1 1C Glass breaking 1 2\r
- 04 OK ... A 3 2 1D Level UP 2 2\r
- 05 OK ... B 3 2 1E Insert air 1 1\r
- 06 Select...A 3 2 1F Sword swing 1 1\r
- 07 Select...B 3 1 20 Water falling 2 1\r
- 08 Select...C 2 2 21 Fire 1 1\r
- 09 Mistake...Buzzer 2 1 22 Wall collapsing 1 2\r
- 0A Catch Item 2 2 23 Cancel 1 2\r
- 0B Gate squeaks 1 time 2 2 24 Walking 1 2\r
- 0C Explosion...small 1 2 25 Blocking strike 1 2\r
- 0D Explosion...medium 1 2 26 Picture floats on & off 3 2\r
- 0E Explosion...large 1 2 27 Fade in 0 2\r
- 0F Attacked...A 3 1 28 Fade out 0 2\r
- 10 Attacked...B 3 2 29 Window being opened 1 2\r
- 11 Hit (punch)...A 0 2 2A Window being closed 0 2\r
- 12 Hit (punch)...B 0 2 2B Big Laser 3 2\r
- 13 Breath in air 3 2 2C Stone gate closes/opens 0 2\r
- 14 Rocket Projectile...A 3 2 2D Teleportation 3 1\r
- 15 Rocket Projectile...B 3 2 2E Lightning 0 2\r
- 16 Escaping Bubble 2 1 2F Earthquake 0 2\r
- 17 Jump 3 1 30 Small Laser 2 2\r
-</TD></TR></TABLE>Sound effect A is used for formanto sounds (percussion sounds).<BR>\r
-<BR>\r
-<B>Sound Effect B Flag Table<BR>\r
-</B><TABLE><TR><TD><PRE> Code Description P V Code Description P V\r
- 00 Dummy flag, re-trigger - 4 0D Waterfall 2 2\r
- 80 Effect B, stop/silent - 4 0E Small character running 3 1\r
- 01 Applause...small group 2 1 0F Horse running 3 1\r
- 02 Applause...medium group 2 2 10 Warning sound 1 1\r
- 03 Applause...large group 2 4 11 Approaching car 0 1\r
- 04 Wind 1 2 12 Jet flying 1 1\r
- 05 Rain 1 1 13 UFO flying 2 1\r
- 06 Storm 1 3 14 Electromagnetic waves 0 1\r
- 07 Storm with wind/thunder 2 4 15 Score UP 3 1\r
- 08 Lightning 0 2 16 Fire 2 1\r
- 09 Earthquake 0 2 17 Camera shutter, formanto 3 4\r
- 0A Avalanche 0 2 18 Write, formanto 0 1\r
- 0B Wave 0 1 19 Show up title, formanto 0 1\r
- 0C River 3 2\r
-</TD></TR></TABLE>Sound effect B is mainly used for looping sounds (sustained sounds).<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="sgbsystemcontrolcommands"></A><FONT SIZE=+2> SGB System Control Commands</FONT></TD></TR></TABLE><BR>\r
-<B>SGB Command 17h - MASK_EN<BR>\r
-</B>Used to mask the gameboy window, among others this can be used to freeze \r
-the gameboy screen before transferring data through VRAM (the SNES then \r
-keeps displaying the gameboy screen, even though VRAM doesn't contain \r
-meaningful display information during the transfer).<BR>\r
-<TABLE><TR><TD><PRE> Byte Content\r
- 0 Command*8+Length (fixed length=1)\r
- 1 Gameboy Screen Mask (0-3)\r
- 0 Cancel Mask (Display activated)\r
- 1 Freeze Screen (Keep displaying current picture)\r
- 2 Blank Screen (Black)\r
- 3 Blank Screen (Color 0)\r
- 2-F Not used (zero)\r
-</TD></TR></TABLE>Freezing works only if the SNES has stored a picture, ie. if necessary \r
-wait one or two frames before freezing (rather than freezing directly \r
-after having displayed the picture).<BR>\r
-The Cancel Mask function may be also invoked (optionally) by completion \r
-of PAL_SET and ATTR_SET commands.<BR>\r
-<BR>\r
-<B>SGB Command 0Ch - ATRC_EN<BR>\r
-</B>Used to enable/disable Attraction mode. It is totally unclear what an \r
-attraction mode is ???, but it is enabled by default.<BR>\r
-<TABLE><TR><TD><PRE> Byte Content\r
- 0 Command*8+Length (fixed length=1)\r
- 1 Attraction Disable (0=Enable, 1=Disable)\r
- 2-F Not used (zero)\r
-</TD></TR></TABLE><BR>\r
-<B>SGB Command 0Dh - TEST_EN<BR>\r
-</B>Used to enable/disable test mode for "SGB-CPU variable clock speed \r
-function". This function is disabled by default.<BR>\r
-<TABLE><TR><TD><PRE> Byte Content\r
- 0 Command*8+Length (fixed length=1)\r
- 1 Test Mode Enable (0=Disable, 1=Enable)\r
- 2-F Not used (zero)\r
-</TD></TR></TABLE>Maybe intended to determine whether SNES operates at 50Hz or 60Hz \r
-display refresh rate ??? Possibly result can be read-out from joypad \r
-register ???<BR>\r
-<BR>\r
-<B>SGB Command 0Eh - ICON_EN<BR>\r
-</B>Used to enable/disable ICON function. Possibly meant to enable/disable \r
-SGB/SNES popup menues which might otherwise activated during gameboy \r
-game play. By default all functions are enabled (0).<BR>\r
-<TABLE><TR><TD><PRE> Byte Content\r
- 0 Command*8+Length (fixed length=1)\r
- 1 Disable Bits\r
- Bit 0 - Use of SGB-Built-in Color Palettes (1=Disable)\r
- Bit 1 - Controller Set-up Screen (0=Enable, 1=Disable)\r
- Bit 2 - SGB Register File Transfer (0=Receive, 1=Disable)\r
- Bit 3-6 - Not used (zero)\r
- 2-F Not used (zero)\r
-</TD></TR></TABLE>Above Bit 2 will suppress all further packets/commands when set, this \r
-might be useful when starting a monochrome game from inside of the \r
-SGB-menu of a multi-gamepak which contains a collection of different \r
-games.<BR>\r
-<BR>\r
-<B>SGB Command 0Fh - DATA_SND<BR>\r
-</B>Used to write one or more bytes directly into SNES Work RAM.<BR>\r
-<TABLE><TR><TD><PRE> Byte Content\r
- 0 Command*8+Length (fixed length=1)\r
- 1 SNES Destination Address, low\r
- 2 SNES Destination Address, high\r
- 3 SNES Destination Address, bank number\r
- 4 Number of bytes to write (01h-0Bh)\r
- 5 Data Byte #1\r
- 6 Data Byte #2 (if any)\r
- 7 Data Byte #3 (if any)\r
- etc.\r
-</TD></TR></TABLE>Unused bytes at the end of the packet should be set to zero, this \r
-function is restricted to a single packet, so that not more than 11 \r
-bytes can be defined at once.<BR>\r
-Free Addresses in SNES memory are Bank 0 1800h-1FFFh, Bank 7Fh \r
-0000h-FFFFh.<BR>\r
-<BR>\r
-<B>SGB Command 10h - DATA_TRN<BR>\r
-</B>Used to transfer binary code or data directly into SNES RAM.<BR>\r
-<TABLE><TR><TD><PRE> Byte Content\r
- 0 Command*8+Length (fixed length=1)\r
- 1 SNES Destination Address, low\r
- 2 SNES Destination Address, high\r
- 3 SNES Destination Address, bank number\r
- 4-F Not used (zero)\r
-</TD></TR></TABLE>The data is sent by VRAM-Transfer (4 KBytes).<BR>\r
-<TABLE><TR><TD><PRE> 000-FFF Data\r
-</TD></TR></TABLE>Free Addresses in SNES memory are Bank 0 1800h-1FFFh, Bank 7Fh \r
-0000h-FFFFh. The transfer length is fixed at 4KBytes ???, so that directly \r
-writing to the free 2KBytes at 0:1800h would be a not so good idea ???<BR>\r
-<BR>\r
-<B>SGB Command 12h - JUMP<BR>\r
-</B>Used to set the SNES program counter to a specified address. Optionally, \r
-it may be used to set a new address for the SNES NMI handler, the NMI \r
-handler remains unchanged if all bytes 4-6 are zero.<BR>\r
-<TABLE><TR><TD><PRE> Byte Content\r
- 0 Command*8+Length (fixed length=1)\r
- 1 SNES Program Counter, low\r
- 2 SNES Program Counter, high\r
- 3 SNES Program Counter, bank number\r
- 4 SNES NMI Handler, low\r
- 5 SNES NMI Handler, high\r
- 6 SNES NMI Handler, bank number\r
- 7-F Not used, zero\r
-</TD></TR></TABLE>Note: The game "Space Invaders 94" uses this function when selecting \r
-"Arcade mode" to execute SNES program code which has been previously \r
-transferred from the SGB to the SNES. The type of the CPU which is used \r
-in the SNES is unknown ???<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="sgbmultiplayercommand"></A><FONT SIZE=+2> SGB Multiplayer Command</FONT></TD></TR></TABLE><BR>\r
-<B>SGB Command 11h - MLT_REQ<BR>\r
-</B>Used to request multiplayer mode (ie. input from more than one joypad).<BR>\r
-Because this function provides feedback from the SGB/SNES to the gameboy \r
-program, it is also used to detect SGB hardware.<BR>\r
-<TABLE><TR><TD><PRE> Byte Content\r
- 0 Command*8+Length (fixed length=1)\r
- 1 Multiplayer Control (0-3) (Bit0=Enable, Bit1=Two/Four Players)\r
- 0 = One player\r
- 1 = Two players\r
- 3 = Four players\r
- 2-F Not used (zero)\r
-</TD></TR></TABLE>In one player mode, the second joypad (if any) is used for the SGB \r
-system program. In two player mode, both joypads are used for the game. \r
-Because SNES have only two joypad sockets, four player mode requires an \r
-external "Multiplayer 5" adapter.<BR>\r
-<BR>\r
-<B>Reading Multiple Controllers (Joypads)<BR>\r
-</B>When having enabled multiple controllers by MLT_REQ, data for each \r
-joypad can be read out through JOYPAD register (FF00) as follows: First \r
-set P14 and P15 both HIGH (deselect both Buttons and Cursor keys), you \r
-can now read the lower 4bits of FF00 which indicate the joypad ID for \r
-the following joypad input:<BR>\r
-<TABLE><TR><TD><PRE> 0Fh Joypad 1\r
- 0Eh Joypad 2\r
- 0Dh Joypad 3\r
- 0Ch Joypad 4\r
-</TD></TR></TABLE>Next, set P14 and P15 low (one after each other) to select Buttons and \r
-Cursor lines, and read-out joypad state as normally. When completed, set \r
-P14 and P15 back HIGH, this automatically increments the joypad number \r
-(or restarts counting once reached the lastmost joypad). Repeat the \r
-procedure until you have read-out states for all two (or four) joypads.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="sgbborderandobjcommands"></A><FONT SIZE=+2> SGB Border and OBJ Commands</FONT></TD></TR></TABLE><BR>\r
-<B>SGB Command 13h - CHR_TRN<BR>\r
-</B>Used to transfer tile data (characters) to SNES Tile memory in VRAM. This \r
-normally used to define BG tiles for the SGB Border (see PCT_TRN), but \r
-might be also used to define moveable SNES foreground sprites (see \r
-OBJ_TRN).<BR>\r
-<TABLE><TR><TD><PRE> Byte Content\r
- 0 Command*8+Length (fixed length=1)\r
- 1 Tile Transfer Destination\r
- Bit 0 - Tile Numbers (0=Tiles 00h-7Fh, 1=Tiles 80h-FFh)\r
- Bit 1 - Tile Type (0=BG Tiles, 1=OBJ Tiles)\r
- Bit 2-7 - Not used (zero)\r
- 2-F Not used (zero)\r
-</TD></TR></TABLE>The tile data is sent by VRAM-Transfer (4 KBytes).<BR>\r
-<TABLE><TR><TD><PRE> 000-FFF Bitmap data for 128 Tiles\r
-</TD></TR></TABLE>Each tile occupies 16bytes (8x8 pixels, 16 colors each).<BR>\r
-When intending to transfer more than 128 tiles, call this function twice \r
-(once for tiles 00h-7Fh, and once for tiles 80h-FFh). Note: The BG/OBJ \r
-Bit seems to have no effect and writes to the same VRAM addresses for \r
-both BG and OBJ ???<BR>\r
-<BR>\r
-<B>SGB Command 14h - PCT_TRN<BR>\r
-</B>Used to transfer tile map data and palette data to SNES BG Map memory in \r
-VRAM to be used for the SGB border. The actual tiles must be separately \r
-transferred by using the CHR_TRN function.<BR>\r
-<TABLE><TR><TD><PRE> Byte Content\r
- 0 Command*8+Length (fixed length=1)\r
- 1-F Not used (zero)\r
-</TD></TR></TABLE>The map data is sent by VRAM-Transfer (4 KBytes).<BR>\r
-<TABLE><TR><TD><PRE> 000-7FF BG Map 32x32 Entries of 16bit each (2048 bytes)\r
- 800-87F BG Palette Data (Palettes 4-7, each 16 colors of 16bits each)\r
- 880-FFF Not used, don't care\r
-</TD></TR></TABLE>Each BG Map Entry consists of a 16bit value as such:<BR>\r
-<TABLE><TR><TD><PRE> Bit 0-9 - Character Number (use only 00h-FFh, upper 2 bits zero)\r
- Bit 10-12 - Palette Number (use only 4-7, officially use only 4-6)\r
- Bit 13 - BG Priority (use only 0)\r
- Bit 14 - X-Flip (0=Normal, 1=Mirror horizontally)\r
- Bit 15 - Y-Flip (0=Normal, 1=Mirror vertically)\r
-</TD></TR></TABLE>Even though 32x32 map entries are transferred, only upper 32x28 are \r
-actually used (256x224 pixels, SNES screen size). The 20x18 entries in \r
-the center of the 32x28 area should be set to 0000h as transparent space \r
-for the gameboy window to be displayed inside. Reportedly, \r
-non-transparent border data will cover the gameboy window.<BR>\r
-<BR>\r
-<B>SGB Command 18h - OBJ_TRN<BR>\r
-</B>Used to transfer OBJ attributes to SNES OAM memory. Unlike all other \r
-functions with the ending _TRN, this function does not use the usual \r
-one-shot 4KBytes VRAM transfer method.<BR>\r
-Instead, when enabled (below execute bit set), data is permanently (each \r
-frame) read out from the lower character line of the gameboy screen. To \r
-suppress garbage on the display, the lower line is masked, and only the \r
-upper 20x17 characters of the gameboy window are used - the masking \r
-method is unknwon - frozen, black, or recommended to be covered by the \r
-SGB border, or else ??? Also, when the function is enabled, "system \r
-attract mode is not performed" - whatever that means ???<BR>\r
-<TABLE><TR><TD><PRE> Byte Content\r
- 0 Command*8+Length (fixed length=1)\r
- 1 Control Bits\r
- Bit 0 - SNES OBJ Mode enable (0=Cancel, 1=Enable)\r
- Bit 1 - Change OBJ Color (0=No, 1=Use definitions below)\r
- Bit 2-7 - Not used (zero)\r
- 2-3 System Color Palette Number for OBJ Palette 4 (0-511)\r
- 4-5 System Color Palette Number for OBJ Palette 5 (0-511)\r
- 6-7 System Color Palette Number for OBJ Palette 6 (0-511)\r
- 8-9 System Color Palette Number for OBJ Palette 7 (0-511)\r
- These color entries are ignored if above Control Bit 1 is zero.\r
- Because each OBJ palette consists of 16 colors, four system\r
- palette entries (of 4 colors each) are transferred into each\r
- OBJ palette. The system palette numbers are not required to be\r
- aligned to a multiple of four, and will wrap to palette number\r
- 0 when exceeding 511. For example, a value of 511 would copy\r
- system palettes 511, 0, 1, 2 to the SNES OBJ palette.\r
- A-F Not used (zero)\r
-</TD></TR></TABLE>The recommended method is to "display" gameboy BG tiles F9h..FFh from \r
-left to right as first 7 characters of the bottom-most character line of \r
-the gameboy screen. As for normal 4KByte VRAM transfers, this area \r
-should not be scrolled, should not be overlapped by gameboy OBJs, and \r
-the gameboy BGP palette register should be set up properly. By following \r
-that method, SNES OAM data can be defined in the 70h bytes of the \r
-gameboy BG tile memory at following addresses:<BR>\r
-<TABLE><TR><TD><PRE> 8F90-8FEF SNES OAM, 24 Entries of 4 bytes each (96 bytes)\r
- 8FF0-8FF5 SNES OAM MSBs, 24 Entries of 2 bits each (6 bytes)\r
- 8FF6-8FFF Not used, don't care (10 bytes)\r
-</TD></TR></TABLE>The format of SNES OAM Entries is:<BR>\r
-<TABLE><TR><TD><PRE> Byte 0 OBJ X-Position (0-511, MSB is separately stored, see below)\r
- Byte 1 OBJ Y-Position (0-255)\r
- Byte 2-3 Attributes (16bit)\r
- Bit 0-8 Tile Number (use only 00h-FFh, upper bit zero)\r
- Bit 9-11 Palette Number (use only 4-7)\r
- Bit 12-13 OBJ Priority (use only 3)\r
- Bit 14 X-Flip (0=Normal, 1=Mirror horizontally)\r
- Bit 15 Y-Flip (0=Normal, 1=Mirror vertically)\r
-</TD></TR></TABLE>The format of SNES OAM MSB Entries is:<BR>\r
-<TABLE><TR><TD><PRE> Actually, the format is unknown ??? However, 2 bits are used per entry:\r
- One bit is the most significant bit of the OBJ X-Position.\r
- The other bit specifies the OBJ size (8x8 or 16x16 pixels).\r
-</TD></TR></TABLE><BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="cpuregistersandflags"></A><FONT SIZE=+2> CPU Registers and Flags</FONT></TD></TR></TABLE><BR>\r
-<B>Registers<BR>\r
-</B><TABLE><TR><TD><PRE> 16bit Hi Lo Name/Function\r
- AF A - Accumulator & Flags\r
- BC B C BC\r
- DE D E DE\r
- HL H L HL\r
- SP - - Stack Pointer\r
- PC - - Program Counter/Pointer\r
-</TD></TR></TABLE>As shown above, most registers can be accessed either as one 16bit \r
-register, or as two separate 8bit registers.<BR>\r
-<BR>\r
-<B>The Flag Register (lower 8bit of AF register)<BR>\r
-</B><TABLE><TR><TD><PRE> Bit Name Set Clr Expl.\r
- 7 zf Z NZ Zero Flag\r
- 6 n - - Add/Sub-Flag (BCD)\r
- 5 h - - Half Carry Flag (BCD)\r
- 4 cy C NC Carry Flag\r
- 3-0 - - - Not used (always zero)\r
-</TD></TR></TABLE>Conatins the result from the recent instruction which has affected \r
-flags.<BR>\r
-<BR>\r
-<B>The Zero Flag (Z)<BR>\r
-</B>This bit becomes set (1) if the result of an operation has been zero \r
-(0). Used for conditional jumps.<BR>\r
-<BR>\r
-<B>The Carry Flag (C, or Cy)<BR>\r
-</B>Becomes set when the result of an addition became bigger than FFh (8bit) \r
-or FFFFh (16bit). Or when the result of a subtraction or comparision \r
-became less than zero (much as for Z80 and 80x86 CPUs, but unlike as for \r
-65XX and ARM CPUs). Also the flag becomes set when a rotate/shift \r
-operation has shifted-out a "1"-bit.<BR>\r
-Used for conditional jumps, and for instructions such like ADC, SBC, RL, \r
-RLA, etc.<BR>\r
-<BR>\r
-<B>The BCD Flags (N, H)<BR>\r
-</B>These flags are (rarely) used for the DAA instruction only, N Indicates \r
-whether the previous instruction has been an addition or subtraction, \r
-and H indicates carry for lower 4bits of the result, also for DAA, the C \r
-flag must indicate carry for upper 8bits.<BR>\r
-After adding/subtracting two BCD numbers, DAA is intended to convert the \r
-result into BCD format; BCD numbers are ranged from 00h to 99h rather \r
-than 00h to FFh.<BR>\r
-Because C and H flags must contain carry-outs for each digit, DAA cannot \r
-be used for 16bit operations (which have 4 digits), or for INC/DEC \r
-operations (which do not affect C-flag).<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="cpuinstructionset"></A><FONT SIZE=+2> CPU Instruction Set</FONT></TD></TR></TABLE><BR>\r
-Tables below specify the mnemonic, opcode bytes, clock cycles, affected \r
-flags (ordered as znhc), and explanatation.<BR>\r
-The timings assume a CPU clock frequency of 4.194304 MHz (or 8.4<BR>\r
-MHz for CGB in double speed mode), as all gameboy timings are divideable<BR>\r
-by 4, many people specify timings and clock frequency divided by 4.<BR>\r
-<BR>\r
-<B>GMB 8bit-Loadcommands<BR>\r
-</B><TABLE><TR><TD><PRE> ld r,r xx 4 ---- r=r\r
- ld r,n xx nn 8 ---- r=n\r
- ld r,(HL) xx 8 ---- r=(HL)\r
- ld (HL),r 7x 8 ---- (HL)=r\r
- ld (HL),n 36 nn 12 ----\r
- ld A,(BC) 0A 8 ----\r
- ld A,(DE) 1A 8 ----\r
- ld A,(nn) FA 16 ----\r
- ld (BC),A 02 8 ----\r
- ld (DE),A 12 8 ----\r
- ld (nn),A EA 16 ----\r
- ld A,(FF00+n) F0 nn 12 ---- read from io-port n (memory FF00+n)\r
- ld (FF00+n),A E0 nn 12 ---- write to io-port n (memory FF00+n)\r
- ld A,(FF00+C) F2 8 ---- read from io-port C (memory FF00+C)\r
- ld (FF00+C),A E2 8 ---- write to io-port C (memory FF00+C)\r
- ldi (HL),A 22 8 ---- (HL)=A, HL=HL+1\r
- ldi A,(HL) 2A 8 ---- A=(HL), HL=HL+1\r
- ldd (HL),A 32 8 ---- (HL)=A, HL=HL-1\r
- ldd A,(HL) 3A 8 ---- A=(HL), HL=HL-1\r
-</TD></TR></TABLE><BR>\r
-<B>GMB 16bit-Loadcommands<BR>\r
-</B><TABLE><TR><TD><PRE> ld rr,nn x1 nn nn 12 ---- rr=nn (rr may be BC,DE,HL or SP)\r
- ld SP,HL F9 8 ---- SP=HL\r
- push rr x5 16 ---- SP=SP-2 (SP)=rr (rr may be BC,DE,HL,AF)\r
- pop rr x1 12 (AF) rr=(SP) SP=SP+2 (rr may be BC,DE,HL,AF)\r
-</TD></TR></TABLE><BR>\r
-<B>GMB 8bit-Arithmetic/logical Commands<BR>\r
-</B><TABLE><TR><TD><PRE> add A,r 8x 4 z0hc A=A+r\r
- add A,n C6 nn 8 z0hc A=A+n\r
- add A,(HL) 86 8 z0hc A=A+(HL)\r
- adc A,r 8x 4 z0hc A=A+r+cy\r
- adc A,n CE nn 8 z0hc A=A+n+cy\r
- adc A,(HL) 8E 8 z0hc A=A+(HL)+cy\r
- sub r 9x 4 z1hc A=A-r\r
- sub n D6 nn 8 z1hc A=A-n\r
- sub (HL) 96 8 z1hc A=A-(HL)\r
- sbc A,r 9x 4 z1hc A=A-r-cy\r
- sbc A,n DE nn 8 z1hc A=A-n-cy\r
- sbc A,(HL) 9E 8 z1hc A=A-(HL)-cy\r
- and r Ax 4 z010 A=A & r\r
- and n E6 nn 8 z010 A=A & n\r
- and (HL) A6 8 z010 A=A & (HL)\r
- xor r Ax 4 z000\r
- xor n EE nn 8 z000\r
- xor (HL) AE 8 z000\r
- or r Bx 4 z000 A=A | r\r
- or n F6 nn 8 z000 A=A | n\r
- or (HL) B6 8 z000 A=A | (HL)\r
- cp r Bx 4 z1hc compare A-r\r
- cp n FE nn 8 z1hc compare A-n\r
- cp (HL) BE 8 z1hc compare A-(HL)\r
- inc r xx 4 z0h- r=r+1\r
- inc (HL) 34 12 z0h- (HL)=(HL)+1\r
- dec r xx 4 z1h- r=r-1\r
- dec (HL) 35 12 z1h- (HL)=(HL)-1\r
- daa 27 4 z-0x decimal adjust akku\r
- cpl 2F 4 -11- A = A xor FF\r
-</TD></TR></TABLE><BR>\r
-<B>GMB 16bit-Arithmetic/logical Commands<BR>\r
-</B><TABLE><TR><TD><PRE> add HL,rr x9 8 -0hc HL = HL+rr ;rr may be BC,DE,HL,SP\r
- inc rr x3 8 ---- rr = rr+1 ;rr may be BC,DE,HL,SP\r
- dec rr xB 8 ---- rr = rr-1 ;rr may be BC,DE,HL,SP\r
- add SP,dd E8 16 00hc SP = SP +/- dd ;dd is 8bit signed number\r
- ld HL,SP+dd F8 12 00hc HL = SP +/- dd ;dd is 8bit signed number\r
-</TD></TR></TABLE><BR>\r
-<B>GMB Rotate- und Shift-Commands<BR>\r
-</B><TABLE><TR><TD><PRE> rlca 07 4 000c rotate akku left\r
- rla 17 4 000c rotate akku left through carry\r
- rrca 0F 4 000c rotate akku right\r
- rra 1F 4 000c rotate akku right through carry\r
- rlc r CB 0x 8 z00c rotate left\r
- rlc (HL) CB 06 16 z00c rotate left\r
- rl r CB 1x 8 z00c rotate left through carry\r
- rl (HL) CB 16 16 z00c rotate left through carry\r
- rrc r CB 0x 8 z00c rotate right\r
- rrc (HL) CB 0E 16 z00c rotate right\r
- rr r CB 1x 8 z00c rotate right through carry\r
- rr (HL) CB 1E 16 z00c rotate right through carry\r
- sla r CB 2x 8 z00c shift left arithmetic (b0=0)\r
- sla (HL) CB 26 16 z00c shift left arithmetic (b0=0)\r
- swap r CB 3x 8 z000 exchange low/hi-nibble\r
- swap (HL) CB 36 16 z000 exchange low/hi-nibble\r
- sra r CB 2x 8 z00c shift right arithmetic (b7=b7)\r
- sra (HL) CB 2E 16 z00c shift right arithmetic (b7=b7)\r
- srl r CB 3x 8 z00c shift right logical (b7=0)\r
- srl (HL) CB 3E 16 z00c shift right logical (b7=0)\r
-</TD></TR></TABLE><BR>\r
-<B>GMB Singlebit Operation Commands<BR>\r
-</B><TABLE><TR><TD><PRE> bit n,r CB xx 8 z01- test bit n\r
- bit n,(HL) CB xx 12 z01- test bit n\r
- set n,r CB xx 8 ---- set bit n\r
- set n,(HL) CB xx 16 ---- set bit n\r
- res n,r CB xx 8 ---- reset bit n\r
- res n,(HL) CB xx 16 ---- reset bit n\r
-</TD></TR></TABLE><BR>\r
-<B>GMB CPU-Controlcommands<BR>\r
-</B><TABLE><TR><TD><PRE> ccf 3F 4 -00c cy=cy xor 1\r
- scf 37 4 -001 cy=1\r
- nop 00 4 ---- no operation\r
- halt 76 N*4 ---- halt until interrupt occurs (low power)\r
- stop 10 00 ? ---- low power standby mode (VERY low power)\r
- di F3 4 ---- disable interrupts, IME=0\r
- ei FB 4 ---- enable interrupts, IME=1\r
-</TD></TR></TABLE><BR>\r
-<B>GMB Jumpcommands<BR>\r
-</B><TABLE><TR><TD><PRE> jp nn C3 nn nn 16 ---- jump to nn, PC=nn\r
- jp HL E9 4 ---- jump to HL, PC=HL\r
- jp f,nn xx nn nn 16;12 ---- conditional jump if nz,z,nc,c\r
- jr PC+dd 18 dd 12 ---- relative jump to nn (PC=PC+/-7bit)\r
- jr f,PC+dd xx dd 12;8 ---- conditional relative jump if nz,z,nc,c\r
- call nn CD nn nn 24 ---- call to nn, SP=SP-2, (SP)=PC, PC=nn\r
- call f,nn xx nn nn 24;12 ---- conditional call if nz,z,nc,c\r
- ret C9 16 ---- return, PC=(SP), SP=SP+2\r
- ret f xx 20;8 ---- conditional return if nz,z,nc,c\r
- reti D9 16 ---- return and enable interrupts (IME=1)\r
- rst n xx 16 ---- call to 00,08,10,18,20,28,30,38\r
-</TD></TR></TABLE><BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="cpucomparisionwithz80"></A><FONT SIZE=+2> CPU Comparision with Z80</FONT></TD></TR></TABLE><BR>\r
-<B>Comparision with 8080<BR>\r
-</B>Basically, the gameboy CPU works more like an older 8080 CPU rather than \r
-like a more powerful Z80 CPU. It is, however, supporting CB-prefixed \r
-instructions. Also, all known gameboy assemblers using the more obvious \r
-Z80-style syntax, rather than the chaotic 8080-style syntax.<BR>\r
-<BR>\r
-<B>Comparision with Z80<BR>\r
-</B>Any DD-, ED-, and FD-prefixed instructions are missing, that means no \r
-IX-, IY-registers, no block commands, and some other missing commands.<BR>\r
-All exchange instructions have been removed (including total absence of \r
-second register set), 16bit memory accesses are mostly missing, and \r
-16bit arithmetic functions are heavily cut-down.<BR>\r
-The gameboy has no IN/OUT instructions, instead I/O ports are accessed \r
-directly by normal LD instructions, or by special LD (FF00+n) opcodes.<BR>\r
-The sign and parity/overflow flags have been removed.<BR>\r
-The gameboy operates approximately as fast as a 4MHz Z80 (8MHz in CGB \r
-double speed mode), execution time of all instructions has been rounded \r
-up to a multiple of 4 cycles though.<BR>\r
-<BR>\r
-<B>Moved, Removed, and Added Opcodes<BR>\r
-</B><TABLE><TR><TD><PRE> Opcode Z80 GMB\r
- ---------------------------------------\r
- 08 EX AF,AF LD (nn),SP\r
- 10 DJNZ PC+dd STOP\r
- 22 LD (nn),HL LDI (HL),A\r
- 2A LD HL,(nn) LDI A,(HL)\r
- 32 LD (nn),A LDD (HL),A\r
- 3A LD A,(nn) LDD A,(HL)\r
- D3 OUT (n),A -\r
- D9 EXX RETI\r
- DB IN A,(n) -\r
- DD <IX> -\r
- E0 RET PO LD (FF00+n),A\r
- E2 JP PO,nn LD (FF00+C),A\r
- E3 EX (SP),HL -\r
- E4 CALL P0,nn -\r
- E8 RET PE ADD SP,dd\r
- EA JP PE,nn LD (nn),A\r
- EB EX DE,HL -\r
- EC CALL PE,nn -\r
- ED <pref> -\r
- F0 RET P LD A,(FF00+n)\r
- F2 JP P,nn LD A,(FF00+C)\r
- F4 CALL P,nn -\r
- F8 RET M LD HL,SP+dd\r
- FA JP M,nn LD A,(nn)\r
- FC CALL M,nn -\r
- FD <IY> -\r
- CB3X SLL r/(HL) SWAP r/(HL)\r
-</TD></TR></TABLE>Note: The unused (-) opcodes will lock-up the gameboy CPU when used.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="thecartridgeheader"></A><FONT SIZE=+2> The Cartridge Header</FONT></TD></TR></TABLE><BR>\r
-An internal information area is located at 0100-014F in<BR>\r
-each cartridge. It contains the following values:<BR>\r
-<BR>\r
-<B>0100-0103 - Entry Point<BR>\r
-</B>After displaying the Nintendo Logo, the built-in boot procedure jumps to \r
-this address (100h), which should then jump to the actual main program \r
-in the cartridge. Usually this 4 byte area contains a NOP instruction, \r
-followed by a JP 0150h instruction. But not always.<BR>\r
-<BR>\r
-<B>0104-0133 - Nintendo Logo<BR>\r
-</B>These bytes define the bitmap of the Nintendo logo that is displayed \r
-when the gameboy gets turned on. The hexdump of this bitmap is:<BR>\r
-<TABLE><TR><TD><PRE> CE ED 66 66 CC 0D 00 0B 03 73 00 83 00 0C 00 0D\r
- 00 08 11 1F 88 89 00 0E DC CC 6E E6 DD DD D9 99\r
- BB BB 67 63 6E 0E EC CC DD DC 99 9F BB B9 33 3E\r
-</TD></TR></TABLE>The gameboys boot procedure verifies the content of this bitmap (after \r
-it has displayed it), and LOCKS ITSELF UP if these bytes are incorrect. \r
-A CGB verifies only the first 18h bytes of the bitmap, but others (for \r
-example a pocket gameboy) verify all 30h bytes.<BR>\r
-<BR>\r
-<B>0134-0143 - Title<BR>\r
-</B>Title of the game in UPPER CASE ASCII. If it is less than 16 characters \r
-then the remaining bytes are filled with 00's. When inventing the CGB, \r
-Nintendo has reduced the length of this area to 15 characters, and some \r
-months later they had the fantastic idea to reduce it to 11 characters \r
-only. The new meaning of the ex-title bytes is described below.<BR>\r
-<BR>\r
-<B>013F-0142 - Manufacturer Code<BR>\r
-</B>In older cartridges this area has been part of the Title (see above), in \r
-newer cartridges this area contains an 4 character uppercase \r
-manufacturer code. Purpose and Deeper Meaning unknown.<BR>\r
-<BR>\r
-<B>0143 - CGB Flag<BR>\r
-</B>In older cartridges this byte has been part of the Title (see above). In \r
-CGB cartridges the upper bit is used to enable CGB functions. This is \r
-required, otherwise the CGB switches itself into Non-CGB-Mode. Typical \r
-values are:<BR>\r
-<TABLE><TR><TD><PRE> 80h - Game supports CGB functions, but works on old gameboys also.\r
- C0h - Game works on CGB only (physically the same as 80h).\r
-</TD></TR></TABLE>Values with Bit 7 set, and either Bit 2 or 3 set, will switch the \r
-gameboy into a special non-CGB-mode with uninitialized palettes. Purpose \r
-unknown, eventually this has been supposed to be used to colorize \r
-monochrome games that include fixed palette data at a special location \r
-in ROM.<BR>\r
-<BR>\r
-<B>0144-0145 - New Licensee Code<BR>\r
-</B>Specifies a two character ASCII licensee code, indicating the company or \r
-publisher of the game. These two bytes are used in newer games only \r
-(games that have been released after the SGB has been invented). Older \r
-games are using the header entry at 014B instead.<BR>\r
-<BR>\r
-<B>0146 - SGB Flag<BR>\r
-</B>Specifies whether the game supports SGB functions, common values are:<BR>\r
-<TABLE><TR><TD><PRE> 00h = No SGB functions (Normal Gameboy or CGB only game)\r
- 03h = Game supports SGB functions\r
-</TD></TR></TABLE>The SGB disables its SGB functions if this byte is set to another value \r
-than 03h.<BR>\r
-<BR>\r
-<B>0147 - Cartridge Type<BR>\r
-</B>Specifies which Memory Bank Controller (if any) is used in the \r
-cartridge, and if further external hardware exists in the cartridge.<BR>\r
-<TABLE><TR><TD><PRE> 00h ROM ONLY 13h MBC3+RAM+BATTERY\r
- 01h MBC1 15h MBC4\r
- 02h MBC1+RAM 16h MBC4+RAM\r
- 03h MBC1+RAM+BATTERY 17h MBC4+RAM+BATTERY\r
- 05h MBC2 19h MBC5\r
- 06h MBC2+BATTERY 1Ah MBC5+RAM\r
- 08h ROM+RAM 1Bh MBC5+RAM+BATTERY\r
- 09h ROM+RAM+BATTERY 1Ch MBC5+RUMBLE\r
- 0Bh MMM01 1Dh MBC5+RUMBLE+RAM\r
- 0Ch MMM01+RAM 1Eh MBC5+RUMBLE+RAM+BATTERY\r
- 0Dh MMM01+RAM+BATTERY FCh POCKET CAMERA\r
- 0Fh MBC3+TIMER+BATTERY FDh BANDAI TAMA5\r
- 10h MBC3+TIMER+RAM+BATTERY FEh HuC3\r
- 11h MBC3 FFh HuC1+RAM+BATTERY\r
- 12h MBC3+RAM\r
-</TD></TR></TABLE><BR>\r
-<B>0148 - ROM Size<BR>\r
-</B>Specifies the ROM Size of the cartridge. Typically calculated as "32KB \r
-shl N".<BR>\r
-<TABLE><TR><TD><PRE> 00h - 32KByte (no ROM banking)\r
- 01h - 64KByte (4 banks)\r
- 02h - 128KByte (8 banks)\r
- 03h - 256KByte (16 banks)\r
- 04h - 512KByte (32 banks)\r
- 05h - 1MByte (64 banks) - only 63 banks used by MBC1\r
- 06h - 2MByte (128 banks) - only 125 banks used by MBC1\r
- 07h - 4MByte (256 banks)\r
- 52h - 1.1MByte (72 banks)\r
- 53h - 1.2MByte (80 banks)\r
- 54h - 1.5MByte (96 banks)\r
-</TD></TR></TABLE><BR>\r
-<B>0149 - RAM Size<BR>\r
-</B>Specifies the size of the external RAM in the cartridge (if any).<BR>\r
-<TABLE><TR><TD><PRE> 00h - None\r
- 01h - 2 KBytes\r
- 02h - 8 Kbytes\r
- 03h - 32 KBytes (4 banks of 8KBytes each)\r
-</TD></TR></TABLE>When using a MBC2 chip 00h must be specified in this entry, even though \r
-the MBC2 includes a built-in RAM of 512 x 4 bits.<BR>\r
-<BR>\r
-<B>014A - Destination Code<BR>\r
-</B>Specifies if this version of the game is supposed to be sold in japan, \r
-or anywhere else. Only two values are defined.<BR>\r
-<TABLE><TR><TD><PRE> 00h - Japanese\r
- 01h - Non-Japanese\r
-</TD></TR></TABLE><BR>\r
-<B>014B - Old Licensee Code<BR>\r
-</B>Specifies the games company/publisher code in range 00-FFh. A value of \r
-33h signalizes that the New License Code in header bytes 0144-0145 is \r
-used instead.<BR>\r
-(Super GameBoy functions won't work if <> $33.)<BR>\r
-<BR>\r
-<B>014C - Mask ROM Version number<BR>\r
-</B>Specifies the version number of the game. That is usually 00h.<BR>\r
-<BR>\r
-<B>014D - Header Checksum<BR>\r
-</B>Contains an 8 bit checksum across the cartridge header bytes 0134-014C. \r
-The checksum is calculated as follows:<BR>\r
-<TABLE><TR><TD><PRE> x=0:FOR i=0134h TO 014Ch:x=x-MEM[i]-1:NEXT\r
-</TD></TR></TABLE>The lower 8 bits of the result must be the same than the value in this \r
-entry. The GAME WON'T WORK if this checksum is incorrect.<BR>\r
-<BR>\r
-<B>014E-014F - Global Checksum<BR>\r
-</B>Contains a 16 bit checksum (upper byte first) across the whole cartridge \r
-ROM. Produced by adding all bytes of the cartridge (except for the two \r
-checksum bytes). The Gameboy doesn't verify this checksum.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="memorybankcontrollers"></A><FONT SIZE=+2> Memory Bank Controllers</FONT></TD></TR></TABLE><BR>\r
-As the gameboys 16 bit address bus offers only limited space for ROM and \r
-RAM addressing, many games are using Memory Bank Controllers (MBCs) to \r
-expand the available address space by bank switching. These MBC chips \r
-are located in the game cartridge (ie. not in the gameboy itself), \r
-several different MBC types are available:<BR>\r
-<BR>\r
-<A HREF="#none32kbyteromonly">None (32KByte ROM only)</A><BR>\r
-<A HREF="#mbc1max2mbyteromandor32kbyteram">MBC1 (max 2MByte ROM and/or 32KByte RAM)</A><BR>\r
-<A HREF="#mbc2max256kbyteromand512x4bitsram">MBC2 (max 256KByte ROM and 512x4 bits RAM)</A><BR>\r
-<A HREF="#mbc3max2mbyteromandor32kbyteramandtimer">MBC3 (max 2MByte ROM and/or 32KByte RAM and Timer)</A><BR>\r
-<A HREF="#huc1mbcwithinfraredcontroller">HuC1 (MBC with Infrared Controller)</A><BR>\r
-<BR>\r
-<A HREF="#mbctimingissues">MBC Timing Issues</A><BR>\r
-<BR>\r
-In each cartridge, the required (or preferred) MBC type should be \r
-specified in byte at 0147h of the ROM. (As described in the chapter \r
-about The Cartridge Header.)<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="none32kbyteromonly"></A><FONT SIZE=+2> None (32KByte ROM only)</FONT></TD></TR></TABLE><BR>\r
-Small games of not more than 32KBytes ROM do not require a MBC chip for \r
-ROM banking. The ROM is directly mapped to memory at 0000-7FFFh. \r
-Optionally up to 8KByte of RAM could be connected at A000-BFFF, even \r
-though that could require a tiny MBC-like circuit, but no real MBC chip.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="mbc1max2mbyteromandor32kbyteram"></A><FONT SIZE=+2> MBC1 (max 2MByte ROM and/or 32KByte RAM)</FONT></TD></TR></TABLE><BR>\r
-This is the first MBC chip for the gameboy. Any newer MBC chips are \r
-working similiar, so that is relative easy to upgrade a program from one \r
-MBC chip to another - or even to make it compatible to several different \r
-types of MBCs.<BR>\r
-<BR>\r
-Note that the memory in range 0000-7FFF is used for both reading from \r
-ROM, and for writing to the MBCs Control Registers.<BR>\r
-<BR>\r
-<B>0000-3FFF - ROM Bank 00 (Read Only)<BR>\r
-</B>This area always contains the first 16KBytes of the cartridge ROM.<BR>\r
-<BR>\r
-<B>4000-7FFF - ROM Bank 01-7F (Read Only)<BR>\r
-</B>This area may contain any of the further 16KByte banks of the ROM, \r
-allowing to address up to 125 ROM Banks (almost 2MByte). As described \r
-below, bank numbers 20h, 40h, and 60h cannot be used, resulting in the \r
-odd amount of 125 banks.<BR>\r
-<BR>\r
-<B>A000-BFFF - RAM Bank 00-03, if any (Read/Write)<BR>\r
-</B>This area is used to address external RAM in the cartridge (if any). \r
-External RAM is often battery buffered, allowing to store game positions \r
-or high score tables, even if the gameboy is turned off, or if the \r
-cartridge is removed from the gameboy. Available RAM sizes are: 2KByte \r
-(at A000-A7FF), 8KByte (at A000-BFFF), and 32KByte (in form of four 8K \r
-banks at A000-BFFF).<BR>\r
-<BR>\r
-<B>0000-1FFF - RAM Enable (Write Only)<BR>\r
-</B>Before external RAM can be read or written, it must be enabled by \r
-writing to this address space. It is recommended to disable external RAM \r
-after accessing it, in order to protect its contents from damage during \r
-power down of the gameboy. Usually the following values are used:<BR>\r
-<TABLE><TR><TD><PRE> 00h Disable RAM (default)\r
- 0Ah Enable RAM\r
-</TD></TR></TABLE>Practically any value with 0Ah in the lower 4 bits enables RAM, and any \r
-other value disables RAM.<BR>\r
-<BR>\r
-<B>2000-3FFF - ROM Bank Number (Write Only)<BR>\r
-</B>Writing to this address space selects the lower 5 bits of the ROM Bank \r
-Number (in range 01-1Fh). When 00h is written, the MBC translates that \r
-to bank 01h also. That doesn't harm so far, because ROM Bank 00h can be \r
-always directly accessed by reading from 0000-3FFF.<BR>\r
-But (when using the register below to specify the upper ROM Bank bits), \r
-the same happens for Bank 20h, 40h, and 60h. Any attempt to address \r
-these ROM Banks will select Bank 21h, 41h, and 61h instead.<BR>\r
-<BR>\r
-<B>4000-5FFF - RAM Bank Number - or - Upper Bits of ROM Bank Number (Write Only)<BRBR>\r
-</B>This 2bit register can be used to select a RAM Bank in range from \r
-00-03h, or to specify the upper two bits (Bit 5-6) of the ROM Bank \r
-number, depending on the current ROM/RAM Mode. (See below.)<BR>\r
-<BR>\r
-<B>6000-7FFF - ROM/RAM Mode Select (Write Only)<BR>\r
-</B>This 1bit Register selects whether the two bits of the above register \r
-should be used as upper two bits of the ROM Bank, or as RAM Bank Number.<BR>\r
-<TABLE><TR><TD><PRE> 00h = ROM Banking Mode (up to 8KByte RAM, 2MByte ROM) (default)\r
- 01h = RAM Banking Mode (up to 32KByte RAM, 512KByte ROM)\r
-</TD></TR></TABLE>The program may freely switch between both modes, the only limitiation \r
-is that only RAM Bank 00h can be used during Mode 0, and only ROM Banks \r
-00-1Fh can be used during Mode 1.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="mbc2max256kbyteromand512x4bitsram"></A><FONT SIZE=+2> MBC2 (max 256KByte ROM and 512x4 bits RAM)</FONT></TD></TR></TABLE><BR>\r
-<B>0000-3FFF - ROM Bank 00 (Read Only)<BR>\r
-</B>Same as for MBC1.<BR>\r
-<BR>\r
-<B>4000-7FFF - ROM Bank 01-0F (Read Only)<BR>\r
-</B>Same as for MBC1, but only a total of 16 ROM banks is supported.<BR>\r
-<BR>\r
-<B>A000-A1FF - 512x4bits RAM, built-in into the MBC2 chip (Read/Write)<BR>\r
-</B>The MBC2 doesn't support external RAM, instead it includes 512x4 bits of \r
-built-in RAM (in the MBC2 chip itself). It still requires an external \r
-battery to save data during power-off though.<BR>\r
-As the data consists of 4bit values, only the lower 4 bits of the \r
-"bytes" in this memory area are used.<BR>\r
-<BR>\r
-<B>0000-1FFF - RAM Enable (Write Only)<BR>\r
-</B>The least significant bit of the upper address byte must be zero to \r
-enable/disable cart RAM. For example the following addresses can be used \r
-to enable/disable cart RAM: 0000-00FF, 0200-02FF, 0400-04FF, ..., \r
-1E00-1EFF.<BR>\r
-The suggested address range to use for MBC2 ram enable/disable is \r
-0000-00FF.<BR>\r
-<BR>\r
-<B>2000-3FFF - ROM Bank Number (Write Only)<BR>\r
-</B>Writing a value (XXXXBBBB - X = Don't cares, B = bank select bits) into \r
-2000-3FFF area will select an appropriate ROM bank at 4000-7FFF.<BR>\r
-<BR>\r
-The least significant bit of the upper address byte must be one to \r
-select a ROM bank. For example the following addresses can be used to \r
-select a ROM bank: 2100-21FF, 2300-23FF, 2500-25FF, ..., 3F00-3FFF.<BR>\r
-The suggested address range to use for MBC2 rom bank selection is \r
-2100-21FF.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="mbc3max2mbyteromandor32kbyteramandtimer"></A><FONT SIZE=+2> MBC3 (max 2MByte ROM and/or 32KByte RAM and Timer)</FONT></TD></TR></TABLE><BR>\r
-Beside for the ability to access up to 2MB ROM (128 banks), and 32KB RAM \r
-(4 banks), the MBC3 also includes a built-in Real Time Clock (RTC). The \r
-RTC requires an external 32.768 kHz Quartz Oscillator, and an external \r
-battery (if it should continue to tick when the gameboy is turned off).<BR>\r
-<BR>\r
-<B>0000-3FFF - ROM Bank 00 (Read Only)<BR>\r
-</B>Same as for MBC1.<BR>\r
-<BR>\r
-<B>4000-7FFF - ROM Bank 01-7F (Read Only)<BR>\r
-</B>Same as for MBC1, except that accessing banks 20h, 40h, and 60h is \r
-supported now.<BR>\r
-<BR>\r
-<B>A000-BFFF - RAM Bank 00-03, if any (Read/Write)<BR>\r
-A000-BFFF - RTC Register 08-0C (Read/Write)<BR>\r
-</B>Depending on the current Bank Number/RTC Register selection (see below), \r
-this memory space is used to access an 8KByte external RAM Bank, or a \r
-single RTC Register.<BR>\r
-<BR>\r
-<B>0000-1FFF - RAM and Timer Enable (Write Only)<BR>\r
-</B>Mostly the same as for MBC1, a value of 0Ah will enable reading and \r
-writing to external RAM - and to the RTC Registers! A value of 00h will \r
-disable either.<BR>\r
-<BR>\r
-<B>2000-3FFF - ROM Bank Number (Write Only)<BR>\r
-</B>Same as for MBC1, except that the whole 7 bits of the RAM Bank Number \r
-are written directly to this address. As for the MBC1, writing a value \r
-of 00h, will select Bank 01h instead. All other values 01-7Fh select the \r
-corresponding ROM Banks.<BR>\r
-<BR>\r
-<B>4000-5FFF - RAM Bank Number - or - RTC Register Select (Write Only)<BR>\r
-</B>As for the MBC1s RAM Banking Mode, writing a value in range for 00h-03h \r
-maps the corresponding external RAM Bank (if any) into memory at \r
-A000-BFFF.<BR>\r
-When writing a value of 08h-0Ch, this will map the corresponding RTC \r
-register into memory at A000-BFFF. That register could then be \r
-read/written by accessing any address in that area, typically that is \r
-done by using address A000.<BR>\r
-<BR>\r
-<B>6000-7FFF - Latch Clock Data (Write Only)<BR>\r
-</B>When writing 00h, and then 01h to this register, the current time \r
-becomes latched into the RTC registers. The latched data will not change \r
-until it becomes latched again, by repeating the write 00h->01h \r
-procedure.<BR>\r
-This is supposed for <reading> from the RTC registers. It is proof to \r
-read the latched (frozen) time from the RTC registers, while the clock \r
-itself continues to tick in background.<BR>\r
-<BR>\r
-<B>The Clock Counter Registers<BR>\r
-</B><TABLE><TR><TD><PRE> 08h RTC S Seconds 0-59 (0-3Bh)\r
- 09h RTC M Minutes 0-59 (0-3Bh)\r
- 0Ah RTC H Hours 0-23 (0-17h)\r
- 0Bh RTC DL Lower 8 bits of Day Counter (0-FFh)\r
- 0Ch RTC DH Upper 1 bit of Day Counter, Carry Bit, Halt Flag\r
- Bit 0 Most significant bit of Day Counter (Bit 8)\r
- Bit 6 Halt (0=Active, 1=Stop Timer)\r
- Bit 7 Day Counter Carry Bit (1=Counter Overflow)\r
-</TD></TR></TABLE>The Halt Flag is supposed to be set before <writing> to the RTC \r
-Registers.<BR>\r
-<BR>\r
-<B>The Day Counter<BR>\r
-</B>The total 9 bits of the Day Counter allow to count days in range from \r
-0-511 (0-1FFh). The Day Counter Carry Bit becomes set when this value \r
-overflows. In that case the Carry Bit remains set until the program does \r
-reset it.<BR>\r
-Note that you can store an offset to the Day Counter in battery RAM. For \r
-example, every time you read a non-zero Day Counter, add this Counter to \r
-the offset in RAM, and reset the Counter to zero. This method allows to \r
-count any number of days, making your program Year-10000-Proof, provided \r
-that the cartridge gets used at least every 511 days.<BR>\r
-<BR>\r
-<B>Delays<BR>\r
-</B>When accessing the RTC Registers it is recommended to execute a 4ms \r
-delay (4 Cycles in Normal Speed Mode) between the separate accesses.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="huc1mbcwithinfraredcontroller"></A><FONT SIZE=+2> HuC1 (MBC with Infrared Controller)</FONT></TD></TR></TABLE><BR>\r
-This controller (made by Hudson Soft) appears to be very similar to an \r
-MBC1 with the main difference being that it supports infrared LED input \r
-/ output. (Similiar to the infrared port that has been later invented in \r
-CGBs.)<BR>\r
-<BR>\r
-The Japanese cart "Fighting Phoenix" (internal cart name: SUPER B DAMAN) \r
-is known to contain this chip.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="mbctimingissues"></A><FONT SIZE=+2> MBC Timing Issues</FONT></TD></TR></TABLE><BR>\r
-<B>Using MBCs with CGB Double Speed Mode<BR>\r
-</B>The MBC5 has been designed to support CGB Double Speed Mode.<BR>\r
-There have been rumours that older MBCs (like MBC1-3) wouldn't be fast \r
-enough in that mode. If so, it might be nethertheless possible to use \r
-Double Speed during periods which use only code and data which is \r
-located in internal RAM.<BR>\r
-However, despite of the above, my own good old selfmade MBC1-EPROM card \r
-appears to work stable and fine even in Double Speed Mode though.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="gamegeniesharkcheats"></A><FONT SIZE=+2> Gamegenie/Shark Cheats</FONT></TD></TR></TABLE><BR>\r
-Game Shark and Gamegenie are external cartridge adapters that can be \r
-plugged between the gameboy and the actual game cartridge. Hexadecimal \r
-codes can be then entered for specific games, typically providing things \r
-like Infinite Sex, 255 Cigarettes, or Starting directly in Wonderland \r
-Level PRO, etc.<BR>\r
-<BR>\r
-<B>Gamegenie (ROM patches)<BR>\r
-</B>Gamegenie codes consist of nine-digit hex numbers, formatted as \r
-ABC-DEF-GHI, the meaning of the separate digits is:<BR>\r
-<TABLE><TR><TD><PRE> AB New data\r
- FCDE Memory address, XORed by 0F000h\r
- GI Old data, XORed by 0BAh and rotated left by two\r
- H Don't know, maybe checksum and/or else\r
-</TD></TR></TABLE>The address should be located in ROM area 0000h-7FFFh, the adapter \r
-permanently compares address/old data with address/data being read by \r
-the game, and replaces that data by new data if necessary. That method \r
-(more or less) prohibits unwanted patching of wrong memory banks. \r
-Eventually it is also possible to patch external RAM ?<BR>\r
-Newer devices reportedly allow to specify only the first six digits \r
-(optionally). As far as I rememeber, around three or four codes can be \r
-used simultaneously.<BR>\r
-<BR>\r
-<B>Game Shark (RAM patches)<BR>\r
-</B>Game Shark codes consist of eight-digit hex numbers, formatted as \r
-ABCDEFGH, the meaning of the separate digits is:<BR>\r
-<TABLE><TR><TD><PRE> AB External RAM bank number\r
- CD New Data\r
- GHEF Memory Address (internal or external RAM, A000-DFFF)\r
-</TD></TR></TABLE>As far as I understand, patching is implement by hooking the original \r
-VBlank interrupt handler, and re-writing RAM values each frame. The \r
-downside is that this method steals some CPU time, also, it cannot be \r
-used to patch program code in ROM.<BR>\r
-As far as I rememeber, somewhat 10-25 codes can be used simultaneously.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="powerupsequence"></A><FONT SIZE=+2> Power Up Sequence</FONT></TD></TR></TABLE><BR>\r
-When the GameBoy is powered up, a 256 byte program starting at memory \r
-location 0 is executed. This program is located in a ROM inside the \r
-GameBoy. The first thing the program does is read the cartridge \r
-locations from $104 to $133 and place this graphic of a Nintendo logo on \r
-the screen at the top. This image is then scrolled until it is in the \r
-middle of the screen. Two musical notes are then played on the internal \r
-speaker. Again, the cartridge locations $104 to $133 are read but this \r
-time they are compared with a table in the internal rom. If any byte \r
-fails to compare, then the GameBoy stops comparing bytes and simply \r
-halts all operations. If all locations compare the same, then the \r
-GameBoy starts adding all of the bytes in the cartridge from $134 to \r
-$14d. A value of 25 decimal is added to this total. If the least \r
-significant byte of the result is a not a zero, then the GameBoy will \r
-stop doing anything. If it is a zero, then the internal ROM is disabled \r
-and cartridge program execution begins at location $100 with the \r
-following register values:<BR>\r
-<BR>\r
-<TABLE><TR><TD><PRE> AF=$01B0\r
- BC=$0013\r
- DE=$00D8\r
- HL=$014D\r
- Stack Pointer=$FFFE\r
- [$FF05] = $00 ; TIMA\r
- [$FF06] = $00 ; TMA\r
- [$FF07] = $00 ; TAC\r
- [$FF10] = $80 ; NR10\r
- [$FF11] = $BF ; NR11\r
- [$FF12] = $F3 ; NR12\r
- [$FF14] = $BF ; NR14\r
- [$FF16] = $3F ; NR21\r
- [$FF17] = $00 ; NR22\r
- [$FF19] = $BF ; NR24\r
- [$FF1A] = $7F ; NR30\r
- [$FF1B] = $FF ; NR31\r
- [$FF1C] = $9F ; NR32\r
- [$FF1E] = $BF ; NR33\r
- [$FF20] = $FF ; NR41\r
- [$FF21] = $00 ; NR42\r
- [$FF22] = $00 ; NR43\r
- [$FF23] = $BF ; NR30\r
- [$FF24] = $77 ; NR50\r
- [$FF25] = $F3 ; NR51\r
- [$FF26] = $F1-GB, $F0-SGB ; NR52\r
- [$FF40] = $91 ; LCDC\r
- [$FF42] = $00 ; SCY\r
- [$FF43] = $00 ; SCX\r
- [$FF45] = $00 ; LYC\r
- [$FF47] = $FC ; BGP\r
- [$FF48] = $FF ; OBP0\r
- [$FF49] = $FF ; OBP1\r
- [$FF4A] = $00 ; WY\r
- [$FF4B] = $00 ; WX\r
- [$FFFF] = $00 ; IE\r
-</TD></TR></TABLE><BR>\r
-It is not a good idea to assume the above values will always exist. A \r
-later version GameBoy could contain different values than these at \r
-reset. Always set these registers on reset rather than assume they are \r
-as above.<BR>\r
-<BR>\r
-Please note that GameBoy internal RAM on power up contains random data. \r
-All of the GameBoy emulators tend to set all RAM to value $00 on entry.<BR>\r
-<BR>\r
-Cart RAM the first time it is accessed on a real GameBoy contains random \r
-data. It will only contain known data if the GameBoy code initializes it \r
-to some value.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="reducingpowerconsumption"></A><FONT SIZE=+2> Reducing Power Consumption</FONT></TD></TR></TABLE><BR>\r
-The following can be used to recude the power consumption of the \r
-gameboy, and to extend the life of the batteries.<BR>\r
-<BR>\r
-<A HREF="#pwrusingthehaltinstruction">PWR Using the HALT Instruction</A><BR>\r
-<A HREF="#pwrusingthestopinstruction">PWR Using the STOP Instruction</A><BR>\r
-<A HREF="#pwrdisabelingthesoundcontroller">PWR Disabeling the Sound Controller</A><BR>\r
-<A HREF="#pwrnotusingcgbdoublespeedmode">PWR Not using CGB Double Speed Mode</A><BR>\r
-<A HREF="#pwrusingtheskills">PWR Using the Skills</A><BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="pwrusingthehaltinstruction"></A><FONT SIZE=+2> PWR Using the HALT Instruction</FONT></TD></TR></TABLE><BR>\r
-It is recommended that the HALT instruction be used whenever possible to \r
-reduce power consumption & extend the life of the batteries. This \r
-command stops the system clock reducing the power consumption of both \r
-the CPU and ROM.<BR>\r
-<BR>\r
-The CPU will remain suspended until an interrupt occurs at which point \r
-the interrupt is serviced and then the instruction immediately following \r
-the HALT is executed.<BR>\r
-<BR>\r
-Depending on how much CPU time is required by a game, the HALT \r
-instruction can extend battery life anywhere from 5 to 50% or possibly \r
-more.<BR>\r
-<BR>\r
-When waiting for a vblank event, this would be a BAD example:<BR>\r
-<TABLE><TR><TD><PRE> @@wait:\r
- ld a,(0FF44h) ;LY\r
- cp a,144\r
- jr nz,@@wait\r
-</TD></TR></TABLE><BR>\r
-A better example would be a procedure as shown below. In this case the \r
-vblank interrupt must be enabled, and your vblank interrupt procedure \r
-must set vblank_flag to a non-zero value.<BR>\r
-<TABLE><TR><TD><PRE> ld hl,vblank_flag ;hl=pointer to vblank_flag\r
- xor a ;a=0\r
- @@wait: ;wait...\r
- halt ;suspend CPU - wait for ANY interrupt\r
- cp a,(hl) ;vblank flag still zero?\r
- jr z,@@wait ;wait more if zero\r
- ld (hl),a ;set vblank_flag back to zero\r
-</TD></TR></TABLE>The vblank_flag is used to determine whether the HALT period has been \r
-terminated by a vblank interrupt, or by another interrupt. In case that \r
-your program has all other interrupts disabled, then it would be proof \r
-to replace the above procedure by a single HALT instruction.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="pwrusingthestopinstruction"></A><FONT SIZE=+2> PWR Using the STOP Instruction</FONT></TD></TR></TABLE><BR>\r
-The STOP instruction is intended to switch the gameboy into VERY low \r
-power standby mode. For example, a program may use this feature when it \r
-hasn't sensed keyboard input for a longer period (assuming that somebody \r
-forgot to turn off the gameboy).<BR>\r
-<BR>\r
-Before invoking STOP, it might be required to disable Sound and Video \r
-manually (as well as IR-link port in CGB). Much like HALT, the STOP \r
-state is terminated by interrupt events - in this case this would be \r
-commonly a joypad interrupt. The joypad register might be required to be \r
-prepared for STOP either.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="pwrdisabelingthesoundcontroller"></A><FONT SIZE=+2> PWR Disabeling the Sound Controller</FONT></TD></TR></TABLE><BR>\r
-If your programs doesn't use sound at all (or during some periods) then \r
-write 00h to register FF26 to save 16% or more on GB power consumption.<BR>\r
-Sound can be turned back on by writing 80h to the same register, all \r
-sound registers must be then re-initialized.<BR>\r
-When the gameboy becomes turned on, sound is enabled by default, and \r
-must be turned off manually when not used.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="pwrnotusingcgbdoublespeedmode"></A><FONT SIZE=+2> PWR Not using CGB Double Speed Mode</FONT></TD></TR></TABLE><BR>\r
-Because CGB Double Speed mode consumes more power, it'd be recommended \r
-to use normal speed when possible.<BR>\r
-There's limited ability to switch between both speeds, for example, a \r
-game might use normal speed in the title screen, and double speed in the \r
-game, or vice versa.<BR>\r
-However, during speed switch the display collapses for a short moment, \r
-so that it'd be no good idea to alter speeds within active game or title \r
-screen periods.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="pwrusingtheskills"></A><FONT SIZE=+2> PWR Using the Skills</FONT></TD></TR></TABLE><BR>\r
-Most of the above power saving methods will produce best results when \r
-using efficient and tight assembler code which requires as less CPU \r
-power as possible. Thus, experienced old-school programmers will \r
-(hopefully) produce lower power consumption, as than HLL-programming \r
-teenagers, for example.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="spriterambug"></A><FONT SIZE=+2> Sprite RAM Bug</FONT></TD></TR></TABLE><BR>\r
-There is a flaw in the GameBoy hardware that causes trash to be written \r
-to OAM RAM if the following commands are used while their 16-bit content \r
-is in the range of $FE00 to $FEFF:<BR>\r
-<TABLE><TR><TD><PRE> inc rr dec rr ;rr = bc,de, or hl\r
- ldi a,(hl) ldd a,(hl)\r
- ldi (hl),a ldd (hl),a\r
-</TD></TR></TABLE>Only sprites 1 & 2 ($FE00 & $FE04) are not affected by these \r
-instructions.<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="externalconnectors"></A><FONT SIZE=+2> External Connectors</FONT></TD></TR></TABLE><BR>\r
-<B>Cartridge Slot<BR>\r
-</B><TABLE><TR><TD><PRE> Pin Name Expl.\r
- 1 VDD Power Supply +5V DC\r
- 2 PHI System Clock\r
- 3 /WR Write\r
- 4 /RD Read\r
- 5 /CS Chip Select\r
- 6-21 A0-A15 Address Lines\r
- 22-29 D0-D7 Data Lines\r
- 30 /RES Reset signal\r
- 31 VIN External Sound Input\r
- 32 GND Ground\r
-</TD></TR></TABLE><BR>\r
-<B>Link Port<BR>\r
-</B>Pin numbers are arranged as 2,4,6 in upper row, 1,3,5 un lower row; \r
-outside view of gameboy socket; flat side of socket upside.<BR>\r
-Colors as used in most or all standard link cables, because SIN and SOUT \r
-are crossed, colors Red and Orange are exchanged at one cable end.<BR>\r
-<TABLE><TR><TD><PRE> Pin Name Color Expl.\r
- 1 VCC - +5V DC\r
- 2 SOUT red Data Out\r
- 3 SIN orange Data In\r
- 4 P14 - Not used\r
- 5 SCK green Shift Clock\r
- 6 GND blue Ground\r
-</TD></TR></TABLE>Note: The original gameboy used larger plugs (unlike pocket gameboys and \r
-newer), linking between older/newer gameboys is possible by using cables \r
-with one large and one small plug though.<BR>\r
-<BR>\r
-<B>Stereo Sound Connector (3.5mm, female)<BR>\r
-</B><TABLE><TR><TD><PRE> Pin Expl.\r
- Tip Sound Left\r
- Middle Sound Right\r
- Base Ground\r
-</TD></TR></TABLE><BR>\r
-<B>External Power Supply<BR>\r
-</B>...<BR>\r
-<BR>\r
-<BR>\r
-<BR>\r
-<TABLE WIDTH=100%><TR bgcolor="#cccccc"><TD><A NAME="end"></A><FONT SIZE=+2> END</FONT></TD></TR></TABLE></BODY></HTML>\r
-\1a
\ No newline at end of file
projects / wenboi.git / commitdiff