Gameboy Advance / Nintendo DS - Technical Info - Extracted from no$gba version 2.6a [ GBA | DS | CPU ]
Overview GBA Technical Data GBA Memory Map GBA I/O Map Hardware Programming GBA LCD Video Controller GBA Sound Controller GBA Timers GBA DMA Transfers GBA Communication Ports GBA Keypad Input GBA Interrupt Control GBA System Control Other GBA Cartridges BIOS Functions Unpredictable Things External Connectors
CPU Modes ARM Mode ARM7TDMI 32bit RISC CPU, 16.78MHz, 32bit opcodes (GBA)Internal Memory BIOS ROM 16 KBytesVideo Display 240x160 pixels (2.9 inch TFT color LCD display)Sound Analogue 4 channel CGB compatible (3x square wave, 1x noise)Controls Gamepad 4 Direction Keys, 6 ButtonsCommunication Ports Serial Port Various transfer modes, 4-Player Link, Single Game Pak playExternal Memory GBA Game Pak max. 32MB ROM or flash ROM + max 64K SRAMCase Dimensions Size (mm) GBA: 145x81x25 - GBA SP: 82x82x24 (closed), 155x82x24 (stretch)Power Supply Battery GBA GBA: 2x1.5V DC (AA), Life-time approx. 15 hours ----------------------------------------------------------------------------The separate CPU modes cannot be operated simultaneously. Switching is allowed between ARM and THUMB modes only (that are the two GBA modes). This manual does not describe CGB and DMG modes, both are completely different than GBA modes, and both cannot be accessed from inside of GBA modes anyways. Gameboy Player An GBA Adapter for the Gamecube console; allowing to play GBA games on a television set. GBA Gameboy Player GBA SP Notes Deluxe version of the original GBA. With backlight, new folded laptop-style case, and built-in rechargeable battery. Appears to be 100% compatible with GBA, there seems to be no way to detect SPs by software.
General Internal Memory 00000000-00003FFF BIOS - System ROM (16 KBytes)Internal Display Memory 05000000-050003FF BG/OBJ Palette RAM (1 Kbyte)External Memory (Game Pak) 08000000-09FFFFFF Game Pak ROM/FlashROM (max 32MB) - Wait State 0Unused Memory Area 10000000-FFFFFFFF Not used (upper 4bits of address bus unused)Default WRAM Usage By default, the 256 bytes at 03007F00h-03007FFFh in Work RAM are reserved for Interrupt vector, Interrupt Stack, and BIOS Call Stack. The remaining WRAM is free for whatever use (including User Stack, which is initially located at 03007F00h). Address Bus Width and CPU Read/Write Access Widths Shows the Bus-Width, supported read and write widths, and the clock cycles for 8/16/32bit accesses. Region Bus Read Write CyclesTiming Notes: * Plus 1 cycle if GBA accesses video memory at the same time.All memory (except GamePak SRAM) can be accessed by 16bit and 32bit DMA. GamePak Memory Only DMA3 (and the CPU of course) may access GamePak ROM. GamePak SRAM can be accessed by the CPU only - restricted to bytewise 8bit transfers. The SRAM region is supposed for as external FLASH backup memory, or for battery-backed SRAM. For details about configuration of GamePak Waitstates, see: GBA System Control VRAM, OAM, and Palette RAM Access These memory regions can be accessed during H-Blank or V-Blank only (unless display is disabled by Forced Blank bit in DISPCNT register). There is an additional restriction for OAM memory: Accesses during H-Blank are allowed only if 'H-Blank Interval Free' in DISPCNT is set (which'd reduce number of display-able OBJs though). The CPU appears to be able to access VRAM/OAM/Palette at any time, a waitstate (one clock cycle) being inserted automatically in case that the display controller was accessing memory simultaneously. (Ie. unlike as in old 8bit gameboy, the data will not get lost.) CPU Mode Performance Note that the GamePak ROM bus is limited to 16bits, thus executing ARM instructions (32bit opcodes) from inside of GamePak ROM would result in a not so good performance. So, it'd be more recommended to use THUMB instruction (16bit opcodes) which'd allow each opcode to be read at once. (ARM instructions can be used at best performance by copying code from GamePak ROM into internal Work RAM) Data Format Even though the ARM CPU itself would allow to select between Little-Endian and Big-Endian format by using an external circuit, in the GBA no such circuit exists, and the data format is always Little-Endian. That is, when accessing 16bit or 32bit data in memory, the least significant bits are stored in the first byte (smallest address), and the most significant bits in the last byte. (Ie. same as for 80x86 and Z80 CPUs.)
LCD I/O Registers 4000000h 2 R/W DISPCNT LCD ControlSound Registers 4000060h 2 R/W SOUND1CNT_L Channel 1 Sweep register (NR10)DMA Transfer Channels 40000B0h 4 W DMA0SAD DMA 0 Source AddressTimer Registers 4000100h 2 R/W TM0CNT_L Timer 0 Counter/ReloadSerial Communication (1) 4000120h 4 R/W SIODATA32 SIO Data (Normal-32bit Mode) (shared with below!)Keypad Input 4000130h 2 R KEYINPUT Key StatusSerial Communication (2) 4000134h 2 R/W RCNT SIO Mode Select/General Purpose DataInterrupt, Waitstate, and Power-Down Control 4000200h 2 R/W IE Interrupt Enable RegisterAll further addresses at 4XXXXXXh are unused and do not contain mirrors of the I/O area, with the only exception that 4000800h is repeated each 64K (ie. mirrored at 4010800h, 4020800h, etc.)
Registers LCD I/O Display Control LCD I/O Interrupts and Status LCD I/O BG Control LCD I/O BG Scrolling LCD I/O BG Rotation/Scaling LCD I/O Window Feature LCD I/O Mosaic Function LCD I/O Color Special Effects VRAM LCD VRAM Overview LCD VRAM Character Data LCD VRAM BG Screen Data Format (BG Map) LCD VRAM Bitmap BG Modes Sprites LCD OBJ - Overview LCD OBJ - OAM Attributes LCD OBJ - OAM Rotation/Scaling Parameters LCD OBJ - VRAM Character (Tile) Mapping Other LCD Color Palettes LCD Dimensions and Timings
4000000h - DISPCNT - LCD Control (Read/Write) Bit Expl.The table summarizes the facilities of the separate BG modes (video modes). Mode Rot/Scal Layers Size Tiles Colors Features 0 No 0123 256x256..512x515 1024 16/16..256/1 SFMABP 1 Mixed 012- (BG0,BG1 as above Mode 0, BG2 as below Mode 2) 2 Yes --23 128x128..1024x1024 256 256/1 S-MABP 3 Yes --2- 240x160 1 32768 --MABP 4 Yes --2- 240x160 2 256/1 --MABP 5 Yes --2- 160x128 2 32768 --MABPFeatures: S)crolling, F)lip, M)osaic, A)lphaBlending, B)rightness, P)riority. BG Modes 0-2 are Tile/Map-based. BG Modes 3-5 are Bitmap-based, in these modes 1 or 2 Frames (ie. bitmaps, or 'full screen tiles') exists, if two frames exist, either one can be displayed, and the other one can be redrawn in background. Blanking Bits Setting Forced Blank (Bit 7) causes the video controller to display white lines, and all VRAM, Palette RAM, and OAM may be accessed. "When the internal HV synchronous counter cancels a forced blank during a display period, the display begins from the beginning, following the display of two vertical lines." What ? Setting H-Blank Interval Free (Bit 5) allows to access OAM during H-Blank time - using this feature reduces the number of sprites that can be displayed per line. Display Enable Bits By default, BG0-3 and OBJ Display Flags (Bit 8-12) are used to enable/disable BGs and OBJ. When enabling Window 0 and/or 1 (Bit 13-14), color special effects may be used, and BG0-3 and OBJ are controlled by the window(s). Frame Selection In BG Modes 4 and 5 (Bitmap modes), either one of the two bitmaps/frames may be displayed (Bit 4), allowing the user to update the other (invisible) frame in background. In BG Mode 3, only one frame exists. In BG Modes 0-2 (Tile/Map based modes), a similar effect may be gained by altering the base address(es) of BG Map and/or BG Character data. 4000002h - Undocumented - Green Swap (R/W) Normally, red green blue intensities for a group of two pixels is output as BGRbgr (uppercase for left pixel at even xloc, lowercase for right pixel at odd xloc). When the Green Swap bit is set, each pixel group is output as BgRbGr (ie. green intensity of each two pixels exchanged). Bit Expl.This feature appears to be applied to the final picture (ie. after mixing the separate BG and OBJ layers). Eventually intended for other display types (with other pin-outs). With normal GBA hardware it is just producing an interesting dirt effect. The NDS DISPCNT registers are 32bit (4000000h..4000003h), so Green Swap doesn't exist in NDS mode, however, the NDS does support Green Swap in GBA mode.
4000004h - DISPSTAT - General LCD Status (Read/Write) Display status and Interrupt control. The H-Blank conditions are generated once per scanline, including for the 'hidden' scanlines during V-Blank. Bit Expl.The V-Count-Setting value is much the same as LYC of older gameboys, when its value is identical to the content of the VCOUNT register then the V-Counter flag is set (Bit 2), and (if enabled in Bit 5) an interrupt is requested. Although the drawing time is only 960 cycles (240*4), the H-Blank flag is "0" for a total of 1006 cycles. 4000006h - VCOUNT - Vertical Counter (Read only) Indicates the currently drawn scanline, values in range from 160..227 indicate 'hidden' scanlines within VBlank area. Bit Expl.Note: This is much the same than the 'LY' register of older gameboys.
4000008h - BG0CNT - BG0 Control (R/W) (BG Modes 0,1 only) 400000Ah - BG1CNT - BG1 Control (R/W) (BG Modes 0,1 only) 400000Ch - BG2CNT - BG2 Control (R/W) (BG Modes 0,1,2 only) 400000Eh - BG3CNT - BG3 Control (R/W) (BG Modes 0,2 only) Bit Expl.Internal Screen Size (dots) and size of BG Map (bytes): Value Text Mode Rotation/Scaling ModeIn case that some or all BGs are set to same priority then BG0 is having the highest, and BG3 the lowest priority. In 'Text Modes', the screen size is organized as follows: The screen consists of one or more 256x256 pixel (32x32 tiles) areas. When Size=0: only 1 area (SC0), when Size=1 or Size=2: two areas (SC0,SC1 either horizontally or vertically arranged next to each other), when Size=3: four areas (SC0,SC1 in upper row, SC2,SC3 in lower row). Whereas SC0 is defined by the normal BG Map base address (Bit 8-12 of BG#CNT), SC1 uses same address +2K, SC2 address +4K, SC3 address +6K. When the screen is scrolled it'll always wraparound. In 'Rotation/Scaling Modes', the screen size is organized as follows, only one area (SC0) of variable size 128x128..1024x1024 pixels (16x16..128x128 tiles) exists. When the screen is rotated/scaled (or scrolled?) so that the LCD viewport reaches outside of the background/screen area, then BG may be either displayed as transparent or wraparound (Bit 13 of BG#CNT).
4000010h - BG0HOFS - BG0 X-Offset (W) 4000012h - BG0VOFS - BG0 Y-Offset (W) Bit Expl.Specifies the coordinate of the upperleft first visible dot of BG0 background layer, ie. used to scroll the BG0 area. 4000014h - BG1HOFS - BG1 X-Offset (W) 4000016h - BG1VOFS - BG1 Y-Offset (W) Same as above BG0HOFS and BG0VOFS for BG1 respectively. 4000018h - BG2HOFS - BG2 X-Offset (W) 400001Ah - BG2VOFS - BG2 Y-Offset (W) Same as above BG0HOFS and BG0VOFS for BG2 respectively. 400001Ch - BG3HOFS - BG3 X-Offset (W) 400001Eh - BG3VOFS - BG3 Y-Offset (W) Same as above BG0HOFS and BG0VOFS for BG3 respectively. The above BG scrolling registers are exclusively used in Text modes, ie. for all layers in BG Mode 0, and for the first two layers in BG mode 1. In other BG modes (Rotation/Scaling and Bitmap modes) above registers are ignored. Instead, the screen may be scrolled by modifying the BG Rotation/Scaling Reference Point registers.
4000028h - BG2X_L - BG2 Reference Point X-Coordinate, lower 16 bit (W) 400002Ah - BG2X_H - BG2 Reference Point X-Coordinate, upper 12 bit (W) 400002Ch - BG2Y_L - BG2 Reference Point Y-Coordinate, lower 16 bit (W) 400002Eh - BG2Y_H - BG2 Reference Point Y-Coordinate, upper 12 bit (W) These registers are replacing the BG scrolling registers which are used for Text mode, ie. the X/Y coordinates specify the source position from inside of the BG Map/Bitmap of the pixel to be displayed at upper left of the GBA display. The normal BG scrolling registers are ignored in Rotation/Scaling and Bitmap modes. Bit Expl.Because values are shifted left by eight, fractional portions may be specified in steps of 1/256 pixels (this would be relevant only if the screen is actually rotated or scaled). Normal signed 32bit values may be written to above registers (the most significant bits will be ignored and the value will be cut-down to 28bits, but this is no actual problem because signed values have set all MSBs to the same value). Internal Reference Point Registers The above reference points are automatically copied to internal registers during each vblank, specifying the origin for the first scanline. The internal registers are then incremented by dmx and dmy after each scanline. Caution: Writing to a reference point register by software outside of the Vblank period does immediately copy the new value to the corresponding internal register, that means: in the current frame, the new value specifies the origin of the <current> scanline (instead of the topmost scanline). 4000020h - BG2PA - BG2 Rotation/Scaling Parameter A (alias dx) (W) 4000022h - BG2PB - BG2 Rotation/Scaling Parameter B (alias dmx) (W) 4000024h - BG2PC - BG2 Rotation/Scaling Parameter C (alias dy) (W) 4000026h - BG2PD - BG2 Rotation/Scaling Parameter D (alias dmy) (W) Bit Expl.See below for details. 400003Xh - BG3X_L/H, BG3Y_L/H, BG3PA-D - BG3 Rotation/Scaling Parameters Same as above BG2 Reference Point, and Rotation/Scaling Parameters, for BG3 respectively. dx (PA) and dy (PC) When transforming a horizontal line, dx and dy specify the resulting gradient and magnification for that line. For example: Horizontal line, length=100, dx=1, and dy=1. The resulting line would be drawn at 45 degrees, f(y)=1/1*x. Note that this would involve that line is magnified, the new length is SQR(100^2+100^2)=141.42. Yup, exactly - that's the old a^2 + b^2 = c^2 formula. dmx (PB) and dmy (PD) These values define the resulting gradient and magnification for transformation of vertical lines. However, when rotating a square area (which is surrounded by horizontal and vertical lines), then the desired result should be usually a rotated <square> area (ie. not a parallelogram, for example). Thus, dmx and dmy must be defined in direct relationship to dx and dy, taking the example above, we'd have to set dmx=-1, and dmy=1, f(x)=-1/1*y. Area Overflow In result of rotation/scaling it may often happen that areas outside of the actual BG area become moved into the LCD viewport. Depending of the Area Overflow bit (BG2CNT and BG3CNT, Bit 13) these areas may be either displayed (by wrapping the BG area), or may be displayed transparent. This works only in BG modes 1 and 2. The area overflow is ignored in Bitmap modes (BG modes 3-5), the outside of the Bitmaps is always transparent. --- more details and confusing or helpful formulas --- The following parameters are required for Rotation/Scaling Rotation Center X and Y Coordinates (x0,y0)The display is rotated by 'alpha' degrees around the center. The displayed picture is magnified by 'xMag' along x-Axis (Y=y0) and 'yMag' along y-Axis (X=x0). Calculating Rotation/Scaling Parameters A-D A = Cos (alpha) / xMag ;distance moved in direction x, same lineCalculating the position of a rotated/scaled dot Using the following expressions, x0,y0 Rotation Centerthe following formula can be used to calculate x2,y2: x2 = A(x1-x0) + B(y1-y0) + x0
The Window Feature may be used to split the screen into four regions. The BG0-3,OBJ layers and Color Special Effects can be separately enabled or disabled in each of these regions. The DISPCNT Register DISPCNT Bits 13-15 are used to enable Window 0, Window 1, and/or OBJ Window regions, if any of these regions is enabled then the "Outside of Windows" region is automatically enabled, too. DISPCNT Bits 8-12 are kept used as master enable bits for the BG0-3,OBJ layers, a layer is displayed only if both DISPCNT and WININ/OUT enable bits are set. 4000040h - WIN0H - Window 0 Horizontal Dimensions (W) 4000042h - WIN1H - Window 1 Horizontal Dimensions (W) Bit Expl.Garbage values of X2>240 or X1>X2 are interpreted as X2=240. 4000044h - WIN0V - Window 0 Vertical Dimensions (W) 4000046h - WIN1V - Window 1 Vertical Dimensions (W) Bit Expl.Garbage values of Y2>160 or Y1>Y2 are interpreted as Y2=160. 4000048h - WININ - Control of Inside of Window(s) (R/W) Bit Expl.400004Ah - WINOUT - Control of Outside of Windows & Inside of OBJ Window (R/W) Bit Expl.The OBJ Window The dimension of the OBJ Window is specified by OBJs which are having the "OBJ Mode" attribute being set to "OBJ Window". Any non-transparent dots of any such OBJs are marked as OBJ Window area. The OBJ itself is not displayed. The color, palette, and display priority of these OBJs are ignored. Both DISPCNT Bits 12 and 15 must be set when defining OBJ Window region(s). Window Priority In case that more than one window is enabled, and that these windows do overlap, Window 0 is having highest priority, Window 1 medium, and Obj Window lowest priority. Outside of Window is having zero priority, it is used for all dots which are not inside of any window region.
400004Ch - MOSAIC - Mosaic Size (W) The Mosaic function can be separately enabled/disabled for BG0-BG3 by BG0CNT-BG3CNT Registers, as well as for each OBJ0-127 by OBJ attributes in OAM memory. Also, setting all of the bits below to zero effectively disables the mosaic function. Bit Expl.Example: When setting H-Size to 5, then pixels 0-5 of each display row are colorized as pixel 0, pixels 6-11 as pixel 6, pixels 12-17 as pixel 12, and so on. Normally, a 'mosaic-pixel' is colorized by the color of the upperleft covered pixel. In many cases it might be more desireful to use the color of the pixel in the center of the covered area - this effect may be gained by scrolling the background (or by adjusting the OBJ position, as far as upper/left rows/columns of OBJ are transparent).
Two types of Special Effects are supported: Alpha Blending (Semi-Transparency) allows to combine colors of two selected surfaces. Brightness Increase/Decrease adjust the brightness of the selected surface. 4000050h - BLDCNT - Color Special Effects Selection (R/W) Bit Expl.Selects the 1st Target layer(s) for special effects. For Alpha Blending/Semi-Transparency, it does also select the 2nd Target layer(s), which should have next lower display priority as the 1st Target. However, any combinations are possible, including that all layers may be selected as both 1st+2nd target, in that case the top-most pixel will be used as 1st target, and the next lower pixel as 2nd target. 4000052h - BLDALPHA - Alpha Blending Coefficients (W) Used for Color Special Effects Mode 1, and for Semi-Transparent OBJs. Bit Expl.For this effect, the top-most non-transparent pixel must be selected as 1st Target, and the next-lower non-transparent pixel must be selected as 2nd Target, if so - and only if so, then color intensities of 1st and 2nd Target are mixed together by using the parameters in BLDALPHA register, for each pixel each R, G, B intensities are calculated separately: I = MIN ( 31, I1st*EVA + I2nd*EVB )Otherwise - for example, if only one target exists, or if a non-transparent non-2nd-target pixel is moved between the two targets, or if 2nd target has higher display priority than 1st target - then only the top-most pixel is displayed (at normal intensity, regardless of BLDALPHA). 4000054h - BLDY - Brightness (Fade-In/Out) Coefficient (W) Used for Color Special Effects Modes 2 and 3. Bit Expl.For each pixel each R, G, B intensities are calculated separately: I = I1st + (31-I1st)*EVY ;For Brightness IncreaseThe color intensities of any selected 1st target surface(s) are increased or decreased by using the parameter in BLDY register. Semi-Transparent OBJs OBJs that are defined as 'Semi-Transparent' in OAM memory are always selected as 1st Target (regardless of BLDCNT Bit 4), and are always using Alpha Blending mode (regardless of BLDCNT Bit 6-7). The BLDCNT register may be used to perform Brightness effects on the OBJ (and/or other BG/BD layers). However, if a semi-transparent OBJ pixel does overlap a 2nd target pixel, then semi-transparency becomes priority, and the brightness effect will not take place (neither on 1st, nor 2nd target). The OBJ Layer Before special effects are applied, the display controller computes the OBJ priority ordering, and isolates the top-most OBJ pixel. In result, only the top-most OBJ pixel is recursed at the time when processing special effects. Ie. alpha blending and semi-transparency can be used for OBJ-to-BG or BG-to-OBJ , but not for OBJ-to-OBJ.
The GBA contains 96 Kbytes VRAM built-in, located at address 06000000-06017FFF, depending on the BG Mode used as follows: BG Mode 0,1,2 (Tile/Map based Modes) 06000000-0600FFFF 64 KBytes shared for BG Map and TilesThe shared 64K area can be split into BG Map area(s), and BG Tiles area(s), the respective addresses for Map and Tile areas are set up by BG0CNT-BG3CNT registers. The Map address may be specified in units of 2K (steps of 800h), the Tile address in units of 16K (steps of 4000h). BG Mode 0,1 (Tile/Map based Text mode) The tiles may have 4bit or 8bit color depth, minimum map size is 32x32 tiles, maximum is 64x64 tiles, up to 1024 tiles can be used per map. Item Depth Required MemoryBG Mode 1,2 (Tile/Map based Rotation/Scaling mode) The tiles may have 8bit color depth only, minimum map size is 16x16 tiles, maximum is 128x128 tiles, up to 256 tiles can be used per map. Item Depth Required MemoryBG Mode 3 (Bitmap based Mode for still images) 06000000-06013FFF 80 KBytes Frame 0 buffer (only 75K actually used)BG Mode 4,5 (Bitmap based Modes) 06000000-06009FFF 40 KBytes Frame 0 buffer (only 37.5K used in Mode 4)Note Additionally to the above VRAM, the GBA also contains 1 KByte Palette RAM (at 05000000h) and 1 KByte OAM (at 07000000h) which are both used by the display controller as well.
Each character (tile) consists of 8x8 dots (64 dots in total). The color depth may be either 4bit or 8bit (see BG0CNT-BG3CNT). 4bit depth (16 colors, 16 palettes) Each tile occupies 32 bytes of memory, the first 4 bytes for the topmost row of the tile, and so on. Each byte representing two dots, the lower 4 bits define the color for the left (!) dot, the upper 4 bits the color for the right dot. 8bit depth (256 colors, 1 palette) Each tile occupies 64 bytes of memory, the first 8 bytes for the topmost row of the tile, and so on. Each byte selects the palette entry for each dot.
The display background consists of 8x8 dot tiles, the arrangement of these tiles is specified by the BG Screen Data (BG Map). The separate entries in this map are as follows: Text BG Screen (2 bytes per entry) Specifies the tile number and attributes. Note that BG tile numbers are always specified in steps of 1 (unlike OBJ tile numbers which are using steps of two in 256 color/1 palette mode). Bit Expl.A Text BG Map always consists of 32x32 entries (256x256 pixels), 400h entries = 800h bytes. However, depending on the BG Size, one, two, or four of these Maps may be used together, allowing to create backgrounds of 256x256, 512x256, 256x512, or 512x512 pixels, if so, the first map (SC0) is located at base+0, the next map (SC1) at base+800h, and so on. Rotation/Scaling BG Screen (1 byte per entry) In this mode, only 256 tiles can be used. There are no x/y-flip attributes, the color depth is always 256 colors/1 palette. Bit Expl.The dimensions of Rotation/Scaling BG Maps depend on the BG size. For size 0-3 that are: 16x16 tiles (128x128 pixels), 32x32 tiles (256x256 pixels), 64x64 tiles (512x512 pixels), or 128x128 tiles (1024x1024 pixels). The size and VRAM base address of the separate BG maps for BG0-3 are set up by BG0CNT-BG3CNT registers.
In BG Modes 3-5 the background is defined in form of a bitmap (unlike as for Tile/Map based BG modes). Bitmaps are implemented as BG2, with Rotation/Scaling support. As bitmap modes are occupying 80KBytes of BG memory, only 16KBytes of VRAM can be used for OBJ tiles. BG Mode 3 - 240x160 pixels, 32768 colors Two bytes are associated to each pixel, directly defining one of the 32768 colors (without using palette data, and thus not supporting a 'transparent' BG color). Bit Expl.The first 480 bytes define the topmost line, the next 480 the next line, and so on. The background occupies 75 KBytes (06000000-06012BFF), most of the 80 Kbytes BG area, not allowing to redraw an invisible second frame in background, so this mode is mostly recommended for still images only. BG Mode 4 - 240x160 pixels, 256 colors (out of 32768 colors) One byte is associated to each pixel, selecting one of the 256 palette entries. Color 0 (backdrop) is transparent, and OBJs may be displayed behind the bitmap. The first 240 bytes define the topmost line, the next 240 the next line, and so on. The background occupies 37.5 KBytes, allowing two frames to be used (06000000-060095FF for Frame 0, and 0600A000-060135FF for Frame 1). BG Mode 5 - 160x128 pixels, 32768 colors Colors are defined as for Mode 3 (see above), but horizontal and vertical size are cut down to 160x128 pixels only - smaller than the physical dimensions of the LCD screen. The background occupies exactly 40 KBytes, so that BG VRAM may be split into two frames (06000000-06009FFF for Frame 0, and 0600A000-06013FFF for Frame 1). In BG modes 4,5, one Frame may be displayed (selected by DISPCNT Bit 4), the other Frame is invisible and may be redrawn in background.
General Objects (OBJs) are moveable sprites. Up to 128 OBJs (of any size, up to 64x64 dots each) can be displayed per screen, and under best circumstances up to 128 OBJs (of small 8x8 dots size) can be displayed per horizontal display line. Maximum Number of Sprites per Line The total available OBJ rendering cycles per line are 1210 (=304*4-6) If "H-Blank Interval Free" bit in DISPCNT register is 0The required rendering cycles are (depending on horizontal OBJ size) Cycles per <n> Pixels OBJ Type OBJ Type Screen Pixel RangeCaution: The maximum number of OBJs per line is also affected by undisplayed (offscreen) OBJs which are having higher priority than displayed OBJs. To avoid this, move displayed OBJs to the begin of OAM memory (ie. OBJ0 has highest priority, OBJ127 lowest). Otherwise (in case that the program logic expects OBJs at fixed positions in OAM) at least take care to set the OBJ size of undisplayed OBJs to 8x8 with Rotation/Scaling disabled (this reduces the overload). Does the above also apply for VERTICALLY OFFSCREEN (or VERTICALLY not on CURRENT LINE) sprites ? VRAM - Character Data OBJs are always combined of one or more 8x8 pixel Tiles (much like BG Tiles in BG Modes 0-2). However, OBJ Tiles are stored in a separate area in VRAM: 06010000-06017FFF (32 KBytes) in BG Mode 0-2, or 06014000-06017FFF (16 KBytes) in BG Mode 3-5. Depending on the size of the above area (16K or 32K), and on the OBJ color depth (4bit or 8bit), 256-1024 8x8 dots OBJ Tiles can be defined. OAM - Object Attribute Memory This memory area contains Attributes which specify position, size, color depth, etc. appearance for each of the 128 OBJs. Additionally, it contains 32 OBJ Rotation/Scaling Parameter groups. OAM is located at 07000000-070003FF (sized 1 KByte).
OBJ Attributes There are 128 entries in OAM for each OBJ0-OBJ127. Each entry consists of 6 bytes (three 16bit Attributes). Attributes for OBJ0 are located at 07000000, for OBJ1 at 07000008, OBJ2 at 07000010, and so on. As you can see, there are blank spaces at 07000006, 0700000E, 07000016, etc. - these 16bit values are used for OBJ Rotation/Scaling (as described in the next chapter) - they are not directly related to the separate OBJs. OBJ Attribute 0 (R/W) Bit Expl.Caution: A very large OBJ (of 128 pixels vertically, ie. a 64 pixels OBJ in a Double Size area) located at Y>128 will be treated as at Y>-128, the OBJ is then displayed parts offscreen at the TOP of the display, it is then NOT displayed at the bottom. OBJ Attribute 1 (R/W) Bit Expl.OBJ Attribute 2 (R/W) Bit Expl.Notes: OBJ Mode The OBJ Mode may be Normal, Semi-Transparent, or OBJ Window. Semi-Transparent means that the OBJ is used as 'Alpha Blending 1st Target' (regardless of BLDCNT register, for details see chapter about Color Special Effects). OBJ Window means that the OBJ is not displayed, instead, dots with non-zero color are used as mask for the OBJ Window, see DISPCNT and WINOUT for details. OBJ Tile Number There are two situations which may divide the amount of available tiles by two (by four if both situations apply): 1. When using the 256 Colors/1 Palette mode, only each second tile may be used, the lower bit of the tile number should be zero (in 2-dimensional mapping mode, the bit is completely ignored). 2. When using BG Mode 3-5 (Bitmap Modes), only tile numbers 512-1023 may be used. That is because lower 16K of OBJ memory are used for BG. Attempts to use tiles 0-511 are ignored (not displayed). Priority In case that the 'Priority relative to BG' is the same than the priority of one of the background layers, then the OBJ becomes higher priority and is displayed on top of that BG layer. Caution: Take care not to mess up BG Priority and OBJ priority. For example, the following would cause garbage to be displayed: OBJ No. 0 with Priority relative to BG=1 ;hi OBJ prio, lo BG prioThat is, OBJ0 is always having priority above OBJ1-127, so assigning a lower BG Priority to OBJ0 than for OBJ1-127 would be a bad idea.
As described in the previous chapter, there are blank spaces between each of the 128 OBJ Attribute Fields in OAM memory. These 128 16bit gaps are used to store OBJ Rotation/Scaling Parameters. Location of Rotation/Scaling Parameters in OAM Four 16bit parameters (PA,PB,PC,PD) are required to define a complete group of Rotation/Scaling data. These are spread across OAM as such: 1st Group - PA=07000006, PB=0700000E, PC=07000016, PD=0700001EBy using all blank space (128 x 16bit), up to 32 of these groups (4 x 16bit each) can be defined in OAM. OBJ Rotation/Scaling PA,PB,PC,PD Parameters (R/W) Each OBJ that uses Rotation/Scaling may select between any of the above 32 parameter groups. For details, refer to the previous chapter about OBJ Attributes. The meaning of the separate PA,PB,PC,PD values is identical as for BG, for details read the chapter about BG Rotation/Scaling. OBJ Reference Point & Rotation Center The OBJ Reference Point is the upper left of the OBJ, ie. OBJ X/Y coordinates: X+0, Y+0. The OBJ Rotation Center is always (or should be usually?) in the middle of the object, ie. for a 8x32 pixel OBJ, this would be at the OBJ X/Y coordinates: X+4, and Y+16. OBJ Double-Size Bit (for OBJs that use Rotation/Scaling) When Double-Size is zero: The sprite is rotated, and then display inside of the normal-sized (not rotated) rectangular area - the edges of the rotated sprite will become invisible if they reach outside of that area. When Double-Size is set: The sprite is rotated, and then display inside of the double-sized (not rotated) rectangular area - this ensures that the edges of the rotated sprite remain visible even if they would reach outside of the normal-sized area. (Except that, for example, rotating a 8x32 pixel sprite by 90 degrees would still cut off parts of the sprite as the double-size area isn't large enough.)
Each OBJ tile consists of 8x8 dots, however, bigger OBJs can be displayed by combining several 8x8 tiles. The horizontal and vertical size for each OBJ may be separately defined in OAM, possible H/V sizes are 8,16,32,64 dots - allowing 'square' OBJs to be used (such like 8x8, 16x16, etc) as well as 'rectangular' OBJs (such like 8x32, 64x16, etc.) When displaying an OBJ that contains of more than one 8x8 tile, one of the following two mapping modes can be used. In either case, the tile number of the upperleft tile must be specified in OAM memory. Two Dimensional Character Mapping (DISPCNT Bit 6 cleared) This mapping mode assumes that the 1024 OBJ tiles are arranged as a matrix of 32x32 tiles / 256x256 pixels (In 256 color mode: 16x32 tiles / 128x256 pixels). Ie. the upper row of this matrix contains tiles 00h-1Fh, the next row tiles 20h-3Fh, and so on. For example, when displaying a 16x16 pixel OBJ, with tile number set to 04h; The upper row of the OBJ will consist of tile 04h and 05h, the next row of 24h and 25h. (In 256 color mode: 04h and 06h, 24h and 26h.) One Dimensional Character Mapping (DISPCNT Bit 6 set) In this mode, tiles are mapped each after each other from 00h-3FFh. Using the same example as above, the upper row of the OBJ will consist of tile 04h and 05h, the next row of tile 06h and 07h. (In 256 color mode: 04h and 06h, 08h and 0Ah.)
Color Palette RAM BG and OBJ palettes are using separate memory regions: 05000000-050001FF - BG Palette RAM (512 bytes, 256 colors)Each BG and OBJ palette RAM may be either split into 16 palettes with 16 colors each, or may be used as a single palette with 256 colors. Note that some OBJs may access palette RAM in 16 color mode, while other OBJs may use 256 color mode at the same time. Same for BG0-BG3 layers. Transparent Colors Color 0 of all BG and OBJ palettes is transparent. Even though palettes are described as 16 (256) color palettes, only 15 (255) colors are actually visible. Backdrop Color Color 0 of BG Palette 0 is used as backdrop color. This color is displayed if an area of the screen is not covered by any non-transparent BG or OBJ dots. Color Definitions Each color occupies two bytes (same as for 32768 color BG modes): Bit Expl.Intensities Under normal circumstances (light source/viewing angle), the intensities 0-14 are practically all black, and only intensities 15-31 are resulting in visible medium..bright colors. Note: The intensity problem appears in the 8bit CGB "compatibility" mode either. The original CGB display produced the opposite effect: Intensities 0-14 resulted in dark..medium colors, and intensities 15-31 resulted in bright colors. Any "medium" colors of CGB games will appear invisible/black on GBA hardware, and only very bright colors will be visible.
Horizontal Dimensions The drawing time for each dot is 4 CPU cycles. Visible 240 dots, 57.221 us, 960 cycles - 78% of h-timeVRAM and Palette RAM may be accessed during H-Blanking. OAM can accessed only if "H-Blank Interval Free" bit in DISPCNT register is set. Vertical Dimensions Visible (*) 160 lines, 11.749 ms, 197120 cycles - 70% of v-timeAll VRAM, OAM, and Palette RAM may be accessed during V-Blanking. Note that no H-Blank interrupts are generated within V-Blank period. System Clock The system clock is 16.78MHz (16*1024*1024 Hz), one cycle is thus approx. 59.59ns. (*) Even though vertical screen size is 160 lines, the upper 8 lines are not <really> visible, these lines are covered by a shadow when holding the GBA orientated towards a light source, the lines are effectively black - and should not be used to display important information.
The GBA supplies four 'analogue' sound channels for Tone and Noise (mostly compatible to CGB sound), as well as two 'digital' sound channels (which can be used to replay 8bit DMA sample data). GBA Sound Channel 1 - Tone & Sweep GBA Sound Channel 2 - Tone GBA Sound Channel 3 - Wave Output GBA Sound Channel 4 - Noise GBA Sound Channel A and B - DMA Sound GBA Sound Control Registers GBA Comparison of CGB and GBA Sound The GBA includes only a single (mono) speaker built-in, each channel may be output to either left and/or right channels by using the external line-out connector (for stereo headphones, etc).
4000060h - SOUND1CNT_L (NR10) - Channel 1 Sweep register (R/W) Bit Expl.Sweep is disabled by setting Sweep Time to zero, if so, the direction bit should be set. The change of frequency (NR13,NR14) at each shift is calculated by the following formula where X(0) is initial freq & X(t-1) is last freq: X(t) = X(t-1) +/- X(t-1)/2^n4000062h - SOUND1CNT_H (NR11, NR12) - Channel 1 Duty/Len/Envelope (R/W) Bit Expl.Wave Duty: 0: 12.5% ( -_______-_______-_______ )The Length value is used only if Bit 6 in NR14 is set. 4000064h - SOUND1CNT_X (NR13, NR14) - Channel 1 Frequency/Control (R/W) Bit Expl.
This sound channel works exactly as channel 1, except that it doesn't have a Tone Envelope/Sweep Register. 4000068h - SOUND2CNT_L (NR21, NR22) - Channel 2 Duty/Length/Envelope (R/W) 400006Ah - Not used 400006Ch - SOUND2CNT_H (NR23, NR24) - Channel 2 Frequency/Control (R/W) For details, refer to channel 1 description.
This channel can be used to output digital sound, the length of the sample buffer (Wave RAM) can be either 32 or 64 digits (4bit samples). This sound channel can be also used to output normal tones when initializing the Wave RAM by a square wave. This channel doesn't have a volume envelope register. 4000070h - SOUND3CNT_L (NR30) - Channel 3 Stop/Wave RAM select (R/W) Bit Expl.The currently selected Bank Number (Bit 6) will be played back, while reading/writing to/from wave RAM will address the other (not selected) bank. When dimension is set to two banks, output will start by replaying the currently selected bank. 4000072h - SOUND3CNT_H (NR31, NR32) - Channel 3 Length/Volume (R/W) Bit Expl.The Length value is used only if Bit 6 in NR34 is set. 4000074h - SOUND3CNT_X (NR33, NR34) - Channel 3 Frequency/Control (R/W) Bit Expl.The above sample rate specifies the number of wave RAM digits per second, the actual tone frequency depends on the wave RAM content, for example: Wave RAM, single bank 32 digits Tone Frequency4000090h - WAVE_RAM0_L - Channel 3 Wave Pattern RAM (W/R) 4000092h - WAVE_RAM0_H - Channel 3 Wave Pattern RAM (W/R) 4000094h - WAVE_RAM1_L - Channel 3 Wave Pattern RAM (W/R) 4000096h - WAVE_RAM1_H - Channel 3 Wave Pattern RAM (W/R) 4000098h - WAVE_RAM2_L - Channel 3 Wave Pattern RAM (W/R) 400009Ah - WAVE_RAM2_H - Channel 3 Wave Pattern RAM (W/R) 400009Ch - WAVE_RAM3_L - Channel 3 Wave Pattern RAM (W/R) 400009Eh - WAVE_RAM3_H - Channel 3 Wave Pattern RAM (W/R) This area contains 16 bytes (32 x 4bits) Wave Pattern data which is output by channel 3. Data is played back ordered as follows: MSBs of 1st byte, followed by LSBs of 1st byte, followed by MSBs of 2nd byte, and so on - this results in a confusing ordering when filling Wave RAM in units of 16bit data - ie. samples would be then located in Bits 4-7, 0-3, 12-15, 8-11. In the GBA, two Wave Patterns exists (each 32 x 4bits), either one may be played (as selected in NR30 register), the other bank may be accessed by the users. After all 32 samples have been played, output of the same bank (or other bank, as specified in NR30) will be automatically restarted. Internally, Wave RAM is a giant shift-register, there is no pointer which is addressing the currently played digit. Instead, the entire 128 bits are shifted, and the 4 least significant bits are output. Thus, when reading from Wave RAM, data might have changed its position. And, when writing to Wave RAM all data should be updated (it'd be no good idea to assume that old data is still located at the same position where it has been written to previously).
This channel is used to output white noise. This is done by randomly switching the amplitude between high and low at a given frequency. Depending on the frequency the noise will appear 'harder' or 'softer'. It is also possible to influence the function of the random generator, so the that the output becomes more regular, resulting in a limited ability to output Tone instead of Noise. 4000078h - SOUND4CNT_L (NR41, NR42) - Channel 4 Length/Envelope (R/W) Bit Expl.The Length value is used only if Bit 6 in NR44 is set. 400007Ch - SOUND4CNT_H (NR43, NR44) - Channel 4 Frequency/Control (R/W) The amplitude is randomly switched between high and low at the given frequency. A higher frequency will make the noise to appear 'softer'. When Bit 3 is set, the output will become more regular, and some frequencies will sound more like Tone than Noise. Bit Expl.Frequency = 524288 Hz / r / 2^(s+1) ;For r=0 assume r=0.5 instead Noise Random Generator (aka Polynomial Counter) Noise randomly switches between HIGH and LOW levels, the output levels are calculated by a shift register (X), at the selected frequency, as such: 7bit: X=X SHR 1, IF carry THEN Out=HIGH, X=X XOR 60h ELSE Out=LOWThe initial value when (re-)starting the sound is X=40h (7bit) or X=4000h (15bit). The data stream repeats after 7Fh (7bit) or 7FFFh (15bit) steps.
The GBA contains two DMA sound channels (A and B), each allowing to replay digital sound (signed 8bit data, ie. -128..+127). Data can be transferred from INTERNAL memory (not sure if EXTERNAL memory works also ?) to FIFO by using DMA channel 1 or 2, the sample rate is generated by using one of the Timers. 40000A0h - FIFO_A_L - Sound A FIFO, Data 0 and Data 1 (W) 40000A2h - FIFO_A_H - Sound A FIFO, Data 2 and Data 3 (W) These two registers may receive 32bit (4 bytes) of audio data (Data 0-3, Data 0 being located in least significant byte which is replayed first). Internally, the capacity of the FIFO is 8 x 32bit (32 bytes), allowing to buffer a small amount of samples. As the name says (First In First Out), oldest data is replayed first. 40000A4h - FIFO_B_L - Sound B FIFO, Data 0 and Data 1 (W) 40000A6h - FIFO_B_H - Sound B FIFO, Data 2 and Data 3 (W) Same as above, for Sound B. Initializing DMA-Sound Playback - Select Timer 0 or 1 in SOUNDCNT_H control register. - Clear the FIFO. - Manually write a sample byte to the FIFO. - Initialize transfer mode for DMA 1 or 2. - Initialize DMA Sound settings in sound control register. - Start the timer. DMA-Sound Playback Procedure The pseudo-procedure below is automatically repeated. If Timer overflows thenThis playback mechanism will be repeated forever, regardless of the actual length of the sample buffer. Synchronizing Sample Buffers The buffer-end may be determined by counting sound Timer IRQs (each sample byte), or sound DMA IRQs (each 16th sample byte). Both methods would require a lot of CPU time (IRQ processing), and both would fail if interrupts are disabled for a longer period. Better solutions would be to synchronize the sample rate/buffer length with V-blanks, or to use a second timer (in count up/slave mode) which produces an IRQ after the desired number of samples. The Sample Rate The GBA hardware does internally re-sample all sound output to 32.768kHz (default SOUNDBIAS setting). It'd thus do not make much sense to use higher DMA/Timer rates. Best re-sampling accuracy can be gained by using DMA/Timer rates of 32.768kHz, 16.384kHz, or 8.192kHz (ie. fragments of the physical output rate).
4000080h - SOUNDCNT_L (NR50, NR51) - Channel L/R Volume/Enable (R/W) Bit Expl.4000082h - SOUNDCNT_H (GBA only) - DMA Sound Control/Mixing (R/W) Bit Expl.4000084h - SOUNDCNT_X (NR52) - Sound on/off (R/W) Bits 0-3 are automatically set when starting sound output, and are automatically cleared when a sound ends. (Ie. when the length expires, as far as length is enabled. The bits are NOT reset when an volume envelope ends.) Bit Expl.While Bit 7 is cleared, both PSG and FIFO sounds are disabled, and all PSG registers (4000060h..4000081h) are reset to zero (and must be re-initialized after re-enabling sound). However, registers 4000082h and 4000088h are kept read/write-able (of which, 4000082h has no function when sound is off, whilst 4000088h does work even when sound is off). 4000088h - SOUNDBIAS - Sound PWM Control (R/W, see below) This register controls the final sound output. The default setting is 0200h, it is normally not required to change this value. Bit Expl.Amplitude Resolution/Sampling Cycle (0-3): 0 9bit / 32.768kHz (Default, best for DMA channels A,B)For more information on this register, read the descriptions below. 400008Ch - Not used 400008Eh - Not used Max Output Levels (with max volume settings) Each of the two FIFOs can span the FULL output range (+/-200h). Each of the four PSGs can span one QUARTER of the output range (+/-80h). The current output levels of all six channels are added together by hardware. So together, the FIFOs and PSGs, could reach THRICE the range (+/-600h). The BIAS value is added to that signed value. With default BIAS (200h), the possible range becomes -400h..+800h, however, values that exceed the unsigned 10bit output range of 0..3FFh are clipped to MinMax(0,3FFh). Resampling to 32.768kHz / 9bit (default) The PSG channels 1-4 are internally generated at 262.144kHz, and DMA sound A-B could be theoretically generated at timer rates up to 16.78MHz. However, the final sound output is resampled to a rate of 32.768kHz, at 9bit depth (the above 10bit value, divided by two). If necessary, rates higher than 32.768kHz can be selected in the SOUNDBIAS register, that would result in a depth smaller than 9bit though. PWM (Pulse Width Modulation) Output 16.78MHz / 1bit Okay, now comes the actual output. The GBA can output only two voltages (low and high), these 'bits' are output at system clock speed (16.78MHz). If using the default 32.768kHz sampling rate, then 512 bits are output per sample (512*32K=16M). Each sample value (9bit range, N=0..511), would be then output as N low bits, followed by 512-N high bits. The resulting 'noise' is smoothed down by capacitors, by the speaker, and by human hearing, so that it will effectively sound like clean D/A converted 9bit voltages at 32kHz sampling rate. Changing the BIAS Level Normally use 200h for clean sound output. A value of 000h might make sense during periods when no sound is output (causing the PWM circuit to output low-bits only, which is eventually reducing the power consumption, and/or preventing 32KHz noise). Note: Using the SoundBias function (SWI 19h) allows to change the level by slowly incrementing or decrementing it (without hard scratch noise). Low Power Mode When not using sound output, power consumption can be reduced by setting both 4000084h (PSG/FIFO) and 4000088h (BIAS) to zero.
The GBA sound controller is mostly the same than that of older monochrome gameboy and CGB. The following changes have been done: New Sound Channels Two new sound channels have been added that may be used to replay 8bit digital sound. Sample rate and sample data must be supplied by using a Timer and a DMA channel. New Control Registers The SOUNDCNT_H register controls the new DMA channels - as well as mixing with the four old channels. The SOUNDBIAS register controls the final sound output. Sound Channel 3 Changes The length of the Wave RAM is doubled by dividing it into two banks of 32 digits each, either one or both banks may be replayed (one after each other), for details check NR30 Bit 5-6. Optionally, the sound may be output at 75% volume, for details check NR32 Bit 7. Changed Control Registers NR50 is not supporting Vin signals (that's been an external sound input from cartridge). Changed I/O Addresses The GBAs sound register are located at 04000060-040000AE instead of at FF10-FF3F as in CGB and monochrome gameboy. However, note that there have been new blank spaces inserted between some of the separate registers - therefore it is NOT possible to port CGB software to GBA just by changing the sound base address. Accessing I/O Registers In some cases two of the old 8bit registers are packed into a 16bit register and may be accessed as such.
The GBA includes four incrementing 16bit timers. Timer 0 and 1 can be used to supply the sample rate for DMA sound channel A and/or B. 4000100h - TM0CNT_L - Timer 0 Counter/Reload (R/W) 4000104h - TM1CNT_L - Timer 1 Counter/Reload (R/W) 4000108h - TM2CNT_L - Timer 2 Counter/Reload (R/W) 400010Ch - TM3CNT_L - Timer 3 Counter/Reload (R/W) Writing to these registers initializes the <reload> value (but does not directly affect the current counter value). Reading returns the current <counter> value (or the recent/frozen counter value if the timer has been stopped). The reload value is copied into the counter only upon following two situations: Automatically upon timer overflows, or when the timer start bit becomes changed from 0 to 1. Note: When simultaneously changing the start bit from 0 to 1, and setting the reload value at the same time (by a single 32bit I/O operation), then the newly written reload value is recognized as new counter value. 4000102h - TM0CNT_H - Timer 0 Control (R/W) 4000106h - TM1CNT_H - Timer 1 Control (R/W) 400010Ah - TM2CNT_H - Timer 2 Control (R/W) 400010Eh - TM3CNT_H - Timer 3 Control (R/W) Bit Expl.When Count-up Timing is enabled, the prescaler value is ignored, instead the time is incremented each time when the previous counter overflows. This function cannot be used for Timer 0 (as it is the first timer). F = System Clock (16.78MHz).
Overview The GBA includes four DMA channels, the highest priority is assigned to DMA0, followed by DMA1, DMA2, and DMA3. DMA Channels with lower priority are paused until channels with higher priority have completed. The CPU is paused when DMA transfers are active, however, the CPU is operating during the periods when Sound/Blanking DMA transfers are paused. Special features of the separate DMA channels DMA0 - highest priority, best for timing critical transfers (eg. HBlank DMA). DMA1 and DMA2 - can be used to feed digital sample data to the Sound FIFOs. DMA3 - can be used to write to Game Pak ROM/FlashROM (but not GamePak SRAM). Beside for that, each DMA 0-3 may be used for whatever general purposes. 40000B0h,0B2h - DMA0SAD - DMA 0 Source Address (W) (internal memory) 40000BCh,0BEh - DMA1SAD - DMA 1 Source Address (W) (any memory) 40000C8h,0CAh - DMA2SAD - DMA 2 Source Address (W) (any memory) 40000D4h,0D6h - DMA3SAD - DMA 3 Source Address (W) (any memory) The most significant address bits are ignored, only the least significant 27 or 28 bits are used (max 07FFFFFFh internal memory, or max 0FFFFFFFh any memory - except SRAM ?!). 40000B4h,0B6h - DMA0DAD - DMA 0 Destination Address (W) (internal memory) 40000C0h,0C2h - DMA1DAD - DMA 1 Destination Address (W) (internal memory) 40000CCh,0CEh - DMA2DAD - DMA 2 Destination Address (W) (internal memory) 40000D8h,0DAh - DMA3DAD - DMA 3 Destination Address (W) (any memory) The most significant address bits are ignored, only the least significant 27 or 28 bits are used (max. 07FFFFFFh internal memory or 0FFFFFFFh any memory - except SRAM ?!). 40000B8h - DMA0CNT_L - DMA 0 Word Count (W) (14 bit, 1..4000h) 40000C4h - DMA1CNT_L - DMA 1 Word Count (W) (14 bit, 1..4000h) 40000D0h - DMA2CNT_L - DMA 2 Word Count (W) (14 bit, 1..4000h) 40000DCh - DMA3CNT_L - DMA 3 Word Count (W) (16 bit, 1..10000h) Specifies the number of data units to be transferred, each unit is 16bit or 32bit depending on the transfer type, a value of zero is treated as max length (ie. 4000h, or 10000h for DMA3). 40000BAh - DMA0CNT_H - DMA 0 Control (R/W) 40000C6h - DMA1CNT_H - DMA 1 Control (R/W) 40000D2h - DMA2CNT_H - DMA 2 Control (R/W) 40000DEh - DMA3CNT_H - DMA 3 Control (R/W) Bit Expl.After changing the Enable bit from 0 to 1, wait 2 clock cycles before accessing any DMA related registers. When accessing OAM (7000000h) or OBJ VRAM (6010000h) by HBlank Timing, then the "H-Blank Interval Free" bit in DISPCNT register must be set. Source and Destination Address and Word Count Registers The SAD, DAD, and CNT_L registers are holding the initial start addresses, and initial length. The hardware does NOT change the content of these registers during or after the transfer. The actual transfer takes place by using internal pointer/counter registers. The initial values are copied into internal regs under the following circumstances: Upon DMA Enable (Bit 15) changing from 0 to 1: Reloads SAD, DAD, CNT_L. Upon Repeat: Reloads CNT_L, and optionally DAD (Increment+Reload). DMA Repeat bit If the Repeat bit is cleared: The Enable bit is automatically cleared after the specified number of data units has been transferred. If the Repeat bit is set: The Enable bit remains set after the transfer, and the transfer will be restarted each time when the Start condition (eg. HBlank, Fifo) becomes true. The specified number of data units is transferred <each> time when the transfer is (re-)started. The transfer will be repeated forever, until it gets stopped by software. Sound DMA (FIFO Timing Mode) (DMA1 and DMA2 only) In this mode, the DMA Repeat bit must be set, and the destination address must be FIFO_A (040000A0h) or FIFO_B (040000A4h). Upon DMA request from sound controller, 4 units of 32bits (16 bytes) are transferred (both Word Count register and DMA Transfer Type bit are ignored). The destination address will not be incremented in FIFO mode. Keep in mind that DMA channels of higher priority may offhold sound DMA. For example, when using a 64 kHz sample rate, 16 bytes of sound DMA data are requested each 0.25ms (4 kHz), at this time another 16 bytes are still in the FIFO so that there's still 0.25ms time to satisfy the DMA request. Thus DMAs with higher priority should not be operated for longer than 0.25ms. (This problem does not arise for HBlank transfers as HBlank time is limited to 16.212us.) Game Pak DMA Only DMA 3 may be used to transfer data to/from Game Pak ROM or Flash ROM - it cannot access Game Pak SRAM though (as SRAM data bus is limited to 8bit units). In normal mode, DMA is requested as long until Word Count becomes zero. When setting the 'Game Pack DRQ' bit, then the cartridge must contain an external circuit which outputs a /DREQ signal. Note that there is only one pin for /DREQ and /IREQ, thus the cartridge may not supply /IREQs while using DRQ mode. Video Capture Mode (DMA3 only) Intended to copy a bitmap from memory (or from external hardware/camera) to VRAM. When using this transfer mode, set the repeat bit, and write the number of data units (per scanline) to the word count register. Capture works similar like HBlank DMA, however, the transfer is started when VCOUNT=2, it is then repeated each scanline, and it gets stopped when VCOUNT=162. Transfer End The DMA Enable flag (Bit 15) is automatically cleared upon completion of the transfer. The user may also clear this bit manually in order to stop the transfer (obviously this is possible for Sound/Blanking DMAs only, in all other cases the CPU is stopped until the transfer completes by itself). Transfer Rate/Timing Except for the first data unit, all units are transferred by sequential reads and writes. For n data units, the DMA transfer time is: 2N+2(n-1)S+xIOf which, 1N+(n-1)S are read cycles, and the other 1N+(n-1)S are write cycles, actual number of cycles depends on the waitstates and bus-width of the source and destination areas (as described in CPU Instruction Cycle Times chapter). Internal time for DMA processing is 2I (normally), or 4I (if both source and destination are in gamepak memory area). DMA lockup when stopping while starting ??? Capture delayed, Capture Enable=AutoCleared ???
The GBAs Serial Port may be used in various different communication modes. Normal mode may exchange data between two GBAs (or to transfer data from master GBA to several slave GBAs in one-way direction). Multi-player mode may exchange data between up to four GBAs. UART mode works much like a RS232 interface. JOY Bus mode uses a standardized Nintendo protocol. And General Purpose mode allows to mis-use the 'serial' port as bi-directional 4bit parallel port. Note: The Nintendo DS does not include a Serial Port. SIO Normal Mode SIO Multi-Player Mode SIO UART Mode SIO JOY BUS Mode SIO General-Purpose Mode SIO Control Registers Summary Infrared Communication Adapters Even though early GBA prototypes have been intended to support IR communication, this feature has been removed. However, Nintendo is apparently considering to provide an external IR adapter (to be connected to the SIO connector, being accessed in General Purpose mode). Also, it'd be theoretically possible to include IR ports built-in in game cartridges (as done for some older 8bit/monochrome Hudson games).
This mode is used to communicate between two units. Transfer rates of 256Kbit/s or 2Mbit/s can be selected, however, the fast 2Mbit/s is intended ONLY for special hardware expansions that are DIRECTLY connected to the GBA link port (ie. without a cable being located between the GBA and expansion hardware). In normal cases, always use 256Kbit/s transfer rate which provides stable results. Transfer lengths of 8bit or 32bit may be used, the 8bit mode is the same as for older DMG/CGB gameboys, however, the voltages for "GBA cartridges in GBAs" are different as for "DMG/CGB cartridges in DMG/CGB/GBAs", ie. it is not possible to communicate between DMG/CGB games and GBA games. 4000134h - RCNT (R) - Mode Selection, in Normal/Multiplayer/UART modes (R/W) Bit Expl.4000128h - SIOCNT - SIO Control, usage in NORMAL Mode (R/W) Bit Expl.The Start bit is automatically reset when the transfer completes, ie. when all 8 or 32 bits are transferred, at that time an IRQ may be generated. 400012Ah - SIODATA8 - SIO Normal Communication 8bit Data (R/W) For 8bit normal mode. Contains 8bit data (only lower 8bit are used). Outgoing data should be written to this register before starting the transfer. During transfer, transmitted bits are shifted-out (MSB first), and received bits are shifted-in simultaneously. Upon transfer completion, the register contains the received 8bit value. 4000120h - SIODATA32_L - SIO Normal Communication lower 16bit data (R/W) 4000122h - SIODATA32_H - SIO Normal Communication upper 16bit data (R/W) Same as above SIODATA8, for 32bit normal transfer mode respectively. SIOCNT/RCNT must be set to 32bit normal mode <before> writing to SIODATA32. Initialization First, initialize RCNT register. Second, set mode/clock bits in SIOCNT with startbit cleared. For master: select internal clock, and (in most cases) specify 256KHz as transfer rate. For slave: select external clock, the local transfer rate selection is then ignored, as the transfer rate is supplied by the remote GBA (or other computer, which might supply custom transfer rates). Third, set the startbit in SIOCNT with mode/clock bits unchanged. Recommended Communication Procedure for SLAVE unit (external clock) - Initialize data which is to be sent to master. - Set Start flag. - Set SO to LOW to indicate that master may start now. - Wait for IRQ (or for Start bit to become zero). (Check timeout here!) - Set SO to HIGH to indicate that we are not ready. - Process received data. - Repeat procedure if more data is to be transferred. (or is so=high done automatically? would be fine - more stable - otherwise master may still need delay) Recommended Communication Procedure for SLAVE unit (external clock) - Initialize data which is to be sent to master. - Set Start=0 and SO=0 (SO=LOW indicates that slave is (almost) ready). - Set Start=1 and SO=1 (SO=HIGH indicates not ready, applied after transfer). (Expl. Old SO=LOW kept output until 1st clock bit received).- Set SO to LOW to indicate that master may start now. - Wait for IRQ (or for Start bit to become zero). (Check timeout here!) - Process received data. - Repeat procedure if more data is to be transferred. Recommended Communication Procedure for MASTER unit (internal clock) - Initialize data which is to be sent to slave. - Wait for SI to become LOW (slave ready). (Check timeout here!) - Set Start flag. - Wait for IRQ (or for Start bit to become zero). - Process received data. - Repeat procedure if more data is to be transferred. Cable Protocol During inactive transfer, the shift clock (SC) is high. The transmit (SO) and receive (SI) data lines may be manually controlled as described above. When master sends SC=LOW, each master and slave must output the next outgoing data bit to SO. When master sends SC=HIGH, each master and slave must read out the opponents data bit from SI. This is repeated for each of the 8 or 32 bits, and when completed SC will be kept high again. Transfer Rates Either 256KHz or 2MHz rates can be selected for SC, so max 32KBytes (256Kbit) or 128KBytes (2Mbit) can be transferred per second. However, the software must process each 8bit or 32bit of transmitted data separately, so the actual transfer rate will be reduced by the time spent on handling each data unit. Only 256KHz provides stable results in most cases (such like when linking between two GBAs). The 2MHz rate is intended for special expansion hardware (with very short wires) only. Using Normal mode for One-Way Multiplayer communication When using normal mode with multiplay-cables, data isn't exchanged between first and second GBA as usually. Instead, data is shifted from first to last GBA (the first GBA receives zero, because master SI is shortcut to GND). This behaviour may be used for fast ONE-WAY data transfer from master to all other GBAs. For example (3 GBAs linked): Step Sender 1st Recipient 2nd RecipientThe recipients should not output any own data, instead they should forward the previously received data to the next recipient during next transfer (just keep the incoming data unmodified in the data register). Due to the delayed forwarding, 2nd recipient should ignore the first incoming data. After the last transfer, the sender must send one (or more) dummy data unit(s), so that the last data is forwarded to the 2nd (or further) recipient(s).
Multi-Player mode can be used to communicate between up to 4 units. 4000134h - RCNT (R) - Mode Selection, in Normal/Multiplayer/UART modes (R/W) Bit Expl.Note: Even though undocumented, many Nintendo games are using Bit 0 to test current SC state in multiplay mode. 4000128h - SIOCNT - SIO Control, usage in MULTI-PLAYER Mode (R/W) Bit Expl.The ID Bits are undefined until the first transfer has completed. 400012Ah - SIOMLT_SEND - Data Send Register (R/W) Outgoing data (16 bit) which is to be sent to the other GBAs. 4000120h - SIOMULTI0 - SIO Multi-Player Data 0 (Parent) (R/W) 4000122h - SIOMULTI1 - SIO Multi-Player Data 1 (1st child) (R/W) 4000124h - SIOMULTI2 - SIO Multi-Player Data 2 (2nd child) (R/W) 4000126h - SIOMULTI3 - SIO Multi-Player Data 3 (3rd child) (R/W) These registers are automatically reset to FFFFh upon transfer start. After transfer, these registers contain incoming data (16bit each) from all remote GBAs (if any / otherwise still FFFFh), as well as the local outgoing SIOMLT_SEND data. Ie. after the transfer, all connected GBAs will contain the same values in their SIOMULTI0-3 registers. Initialization - Initialize RCNT Bit 14-15 and SIOCNT Bit 12-13 to select Multi-Player mode. - Read SIOCNT Bit 3 to verify that all GBAs are in Multi-Player mode. - Read SIOCNT Bit 2 to detect whether this is the Parent/Master unit. Recommended Transmission Procedure - Write outgoing data to SIODATA_SEND. - Master must set Start bit. - All units must process received data in SIOMULTI0-3 when transfer completed. - After the first successful transfer, ID Bits in SIOCNT are valid. - If more data is to be transferred, repeat procedure. The parent unit blindly sends data regardless of whether childs have already processed old data/supplied new data. So, parent unit might be required to insert delays between each transfer, and/or perform error checking. Also, slave units may signalize that they are not ready by temporarily switching into another communication mode (which does not output SD High, as Multi-Player mode does during inactivity). Transfer Protocol Beginning - The masters SI pin is always LOW. - When all GBAs are in Multiplayer mode (ready) SD is HIGH. - When master starts the transfer, it sets SC=LOW, slaves receive Busy bit. Step A - ID Bits in master unit are set to 0. - Master outputs Startbit (LOW), 16bit Data, Stopbit (HIGH) through SD. - This data is written to SIOMULTI0 of all GBAs (including master). - Master forwards LOW from its SO to 1st childs SI. - Transfer ends if next child does not output data after certain time. Step B - ID Bits in 1st child unit are set to 1. - 1st Child outputs Startbit (LOW), 16bit Data, Stopbit (HIGH) through SD. - This data is written to SIOMULTI1 of all GBAs (including 1st child). - 1st child forwards LOW from its SO to 2nd childs SI. - Transfer ends if next child does not output data after certain time. Step C - ID Bits in 2nd child unit are set to 2. - 2nd Child outputs Startbit (LOW), 16bit Data, Stopbit (HIGH) through SD. - This data is written to SIOMULTI2 of all GBAs (including 2nd child). - 2nd child forwards LOW from its SO to 3rd childs SI. - Transfer ends if next child does not output data after certain time. Step D - ID Bits in 3rd child unit are set to 3. - 3rd Child outputs Startbit (LOW), 16bit Data, Stopbit (HIGH) through SD. - This data is written to SIOMULTI3 of all GBAs (including 3rd child). - Transfer ends (this was the last child). Transfer end - Master sets SC=HIGH, all GBAs set SO=HIGH. - The Start/Busy bits of all GBAs are automatically cleared. - Interrupts are requested in all GBAs (as far as enabled). Error Bit This bit is set when a slave did not receive SI=LOW even though SC=LOW signalized a transfer (this might happen when connecting more than 4 GBAs, or when the previous child is not connected). Also, the bit is set when a Stopbit wasn't HIGH. The error bit may be undefined during active transfer - read only after transfer completion (the transfer continues and completes as normal even if errors have occurred for some or all GBAs). Don't know: The bit is automatically reset/initialized with each transfer, or must be manually reset? Transmission Time The transmission time depends on the selected Baud rate. And on the amount of Bits (16 data bits plus start/stop bits for each GBA), delays between data for each GBA, plus final timeout (if less than 4 GBAs). That is, depending on the number of connected GBAs: GBAs Bits Delays Timeout(The average Delay and Timeout periods are unknown?) Above is not counting the additional CPU time that must be spent on initiating and processing each transfer. Fast One-Way Transmission Beside for the actual SIO Multiplayer mode, you can also use SIO Normal mode for fast one-way data transfer from Master unit to all Child unit(s). See chapter about SIO Normal mode for details.
This mode works much like a RS232 port, however, the voltages are unknown, probably 0/3V rather than +/-12V ?. SI and SO are data lines (with crossed wires), SC and SD signalize Clear to Send (with crossed wires also, which requires special cable when linking between two GBAs ?) 4000134h - RCNT (R) - Mode Selection, in Normal/Multiplayer/UART modes (R/W) Bit Expl.4000128h - SCCNT_L - SIO Control, usage in UART Mode (R/W) Bit Expl.400012Ah - SIODATA8 - usage in UART Mode (R/W) Addresses the send/receive shift register, or (when FIFO is used) the send/receive FIFO. In either case only the lower 8bit of SIODATA8 are used, the upper 8bit are not used. The send/receive FIFO may store up to four 8bit data units each. For example, while 1 unit is still transferred from the send shift register, it is possible to deposit another 4 units in the send FIFO, which are then automatically moved to the send shift register one after each other. Send/Receive Enable, CTS Feedback The receiver outputs SD=LOW (which is input as SC=LOW at the remote side) when it is ready to receive data (that is, when Receive Enable is set, and the Receive shift register (or receive FIFO) isn't full. When CTS flag is set to always/blindly, then the sender transmits data immediately when Send Enable is set, otherwise data is transmitted only when Send Enable is set and SC is LOW. Error Flag The error flag is set when a bad stop bit has been received (stop bit must be 0), when a parity error has occurred (if enabled), or when new data has been completely received while the receive data register (or receive FIFO) is already full. The error flag is automatically reset when reading from SIOCNT register. Init & Initback The content of the FIFO is reset when FIFO is disabled in UART mode, thus, when entering UART mode initially set FIFO=disabled. The Send/Receive enable bits must be reset before switching from UART mode into another SIO mode!
This communication mode uses Nintendo's standardized JOY Bus protocol. When using this communication mode, the GBA is always operated as SLAVE! In this mode, SI and SO pins are data lines (apparently synchronized by Start/Stop bits?), SC and SD are set to low (including during active transfer?), the transfer rate is unknown? 4000134h - RCNT (R) - Mode Selection, in JOY BUS mode (R/W) Bit Expl.4000128h - SIOCNT - SIO Control, not used in JOY BUS Mode This register is not used in JOY BUS mode. 4000140h - JOYCNT - JOY BUS Control Register (R/W) Bit Expl.Bit 0-2 are working much like the bits in the IF register: Write a "1" bit to reset (acknowledge) the respective bit. UNCLEAR: Interrupts can be requested for Send/Receive commands also? 4000150h - JOY_RECV_L - Receive Data Register low (R/W) 4000152h - JOY_RECV_H - Receive Data Register high (R/W) 4000154h - JOY_TRANS_L - Send Data Register low (R/W) 4000156h - JOY_TRANS_H - Send Data Register high (R/W) Send/receive data registers. 4000158h - JOYSTAT - Receive Status Register (R/W) Bit Expl.Bit 1 is automatically set when writing to local JOY_TRANS. Bit 3 is automatically reset when reading from local JOY_RECV. Below are the four possible commands which can be received by the GBA. Note that the GBA (slave) cannot send any commands itself, all it can do is to read incoming data, and to provide 'reply' data which may (or may not) be read out by the master unit. Command FFh - Device Reset Receive FFh (Command)Command 00h - Type/Status Data Request Receive 00h (Command)Command 15h - GBA Data Write (to GBA) Receive 15h (Command)Command 14h - GBA Data Read (from GBA) Receive 14h (Command)
In this mode, the SIO is 'misused' as a 4bit bi-directional parallel port, each of the SI,SO,SC,SD pins may be directly controlled, each can be separately declared as input (with internal pull-up) or as output signal. 4000134h - RCNT (R) - SIO Mode, usage in GENERAL-PURPOSE Mode (R/W) Interrupts can be requested when SI changes from HIGH to LOW, as General Purpose mode does not require a serial shift clock, this interrupt may be produced even when the GBA is in Stop (low power standby) state. Bit Expl.SI should be always used as Input to avoid problems with other hardware which does not expect data to be output there. 4000128h - SIOCNT - SIO Control, not used in GENERAL-PURPOSE Mode This register is not used in general purpose mode. That is, the separate bits of SIOCNT still exist and are read- and/or write-able in the same manner as for Normal, Multiplay, or UART mode (depending on SIOCNT Bit 12,13), but are having no effect on data being output to the link port.
Mode Selection (by RCNT.15-14 and SIOCNT.13-12) R.15 R.14 S.13 S.12 ModeSIOCNT Bit 0 1 2 3 4 5 6 7 8 9 10 11
Early GBA prototypes have been intended to include a built-in IR port for sending and receiving IR signals. Among others, this port could have been used to communicate with other GBAs, or older CGB models, or TV Remote Controls, etc. [ THE INFRARED COMMUNICATION FEATURE IS -NOT- SUPPORTED ANYMORE ] Anyways, the prototype specifications have been as shown below... Keep in mind that the IR signal may be interrupted by whatever objects moved between sender and receiver - the IR port isn't recommended for programs that require realtime data exchange (such like action games). 4000136h - IR - Infrared Register (R/W) Bit Expl.When IRQ is enabled, an interrupt is requested if the incoming signal was 0.119us Off (2 cycles), followed by 0.536us On (9 cycles) - minimum timing periods each. Transmission Notes When transmitting an IR signal, note that it'd be not a good idea to keep the LED turned On for a very long period (such like sending a 1 second synchronization pulse). The recipient's circuit would treat such a long signal as "normal IR pollution which is in the air" after a while, and thus ignore the signal. Reception Notes Received data is internally latched. Latched data may be read out by setting both READ and AMP bits. Note: Provided that you don't want to receive your own IR signal, be sure to set Bit 0 to zero before attempting to receive data. Power-consumption After using the IR port, be sure to reset the register to zero in order to reduce battery power consumption.
The built-in GBA gamepad has 4 direction keys, and 6 buttons. 4000130h - KEYINPUT - Key Status (R) Bit Expl.It'd be usually recommended to read-out this register only once per frame, and to store the current state in memory. As a side effect, this method avoids problems caused by switch bounce when a key is newly released or pressed. 4000132h - KEYCNT - Key Interrupt Control (R/W) The keypad IRQ function is intended to terminate the very-low-power Stop mode, it is not suitable for processing normal user input, to do this, most programs are invoking their keypad handlers from within VBlank IRQ. Bit Expl.In logical OR mode, an interrupt is requested when at least one of the selected buttons is pressed. In logical AND mode, an interrupt is requested when ALL of the selected buttons are pressed. Notes In 8bit gameboy compatibility mode, L and R Buttons are used to toggle the screen size between normal 160x144 pixels and stretched 240x144 pixels. The GBA SP is additionally having a * Button used to toggle the backlight on and off (controlled by separate hardware logic, there's no way to detect or change the current backlight state by software).
4000208h - IME - Interrupt Master Enable Register (R/W) Bit Expl.4000200h - IE - Interrupt Enable Register (R/W) Bit Expl.Note that there is another 'master enable flag' directly in the CPUs Status Register (CPSR) accessible in privileged modes, see CPU reference for details. 4000202h - IF - Interrupt Request Flags / IRQ Acknowledge (R/W, see below) Bit Expl.Interrupts must be manually acknowledged by writing a "1" to one of the IRQ bits, the IRQ bit will then be cleared. "[Cautions regarding clearing IME and IE] A corresponding interrupt could occur even while a command to clear IME or each flag of the IE register is being executed. When clearing a flag of IE, you need to clear IME in advance so that mismatching of interrupt checks will not occur." ? "[When multiple interrupts are used] When the timing of clearing of IME and the timing of an interrupt agree, multiple interrupts will not occur during that interrupt. Therefore, set (enable) IME after saving IME during the interrupt routine." ? BIOS Interrupt handling Upon interrupt execution, the CPU is switched into IRQ mode, and the physical interrupt vector is called - as this address is located in BIOS ROM, the BIOS will always execute the following code before it forwards control to the user handler: 00000018 b 128h ;IRQ vector: jump to actual BIOS handlerAs shown above, a pointer to the 32bit/ARM-code user handler must be setup in [03007FFCh]. By default, 160 bytes of memory are reserved for interrupt stack at 03007F00h-03007F9Fh. Recommended User Interrupt handling - If necessary switch to THUMB state manually (handler is called in ARM state) - Determine reason(s) of interrupt by examining IF register - User program may freely assign priority to each reason by own logic - Process the most important reason of your choice - User MUST manually acknowledge by writing to IF register - If user wants to allow nested interrupts, save SPSR_irq, then enable IRQs. - If using other registers than BIOS-pushed R0-R3, manually save R4-R11 also. - Note that Interrupt Stack is used (which may have limited size) - So, for memory consuming stack operations use system mode (=user stack). - When calling subroutines in system mode, save LSR_usr also. - Restore SPSR_irq and/or R4-R11 if you've saved them above. - Finally, return to BIOS handler by BX LR (R14_irq) instruction. Default memory usage at 03007FXX (and mirrored to 03FFFFXX) Addr. Size Expl.Memory below 7F00h is free for User Stack and user data. The three stack pointers are initially initialized at the TOP of the respective areas: SP_svc=03007FE0hThe user may redefine these addresses and move stacks into other locations, however, the addresses for system data at 7FE0h-7FFFh are fixed. Not sure, is following free for user ? Registers R8-R12_fiq, R13_fiq, R14_fiq, SPSR_fiq Registers R13-R14_abt, SPSR_abt Registers R13-R14_und, SPSR_und Fast Interrupt (FIQ) The ARM CPU provides two interrupt sources, IRQ and FIQ. In the GBA only IRQ is used. In normal GBAs, the FIQ signal is shortcut to VDD35, ie. the signal is always high, and there is no way to generate a FIQ by hardware. The registers R8..12_fiq could be used by software (when switching into FIQ mode by writing to CPSR) - however, this might make the game incompatible with hardware debuggers (which are reportedly using FIQs for debugging purposes).
4000204h - WAITCNT - Waitstate Control (R/W) This register is used to configure game pak access timings. The game pak ROM is mirrored to three address regions at 08000000h, 0A000000h, and 0C000000h, these areas are called Wait State 0-2. Different access timings may be assigned to each area (this might be useful in case that a game pak contains several ROM chips with different access times each). Bit Expl.At startup, the default setting is 0000h. Currently manufactured cartridges are using the following settings: WS0/ROM=3,1 clks; SRAM=8 clks; WS2/EEPROM: 8,8 clks; prefetch enabled; that is, WAITCNT=4317h, for more info see "GBA Cartridges" chapter. First Access (Non-sequential) and Second Access (Sequential) define the waitstates for N and S cycles, the actual access time is 1 clock cycle PLUS the number of waitstates. GamePak uses 16bit data bus, so that a 32bit access is split into TWO 16bit accesses (of which, the second fragment is always sequential, even if the first fragment was non-sequential). GamePak Prefetch NOTES: The GBA forcefully uses non-sequential timing at the beginning of each 128K-block of gamepak ROM, eg. "LDMIA [801fff8h],r0-r7" will have non-sequential timing at 8020000h. The PHI Terminal output (PHI Pin of Gamepak Bus) should be disabled. 4000300h - POSTFLG - BYTE - Undocumented - Post Boot / Debug Control (R/W) After initial reset, the GBA BIOS initializes the register to 01h, and any further execution of the Reset vector (00000000h) will pass control to the Debug vector (0000001Ch) when sensing the register to be still set to 01h. Bit Expl.Normally the debug handler rejects control unless it detects Debug flags in cartridge header, in that case it may redirect to a cut-down boot procedure (bypassing Nintendo logo and boot delays, much like nocash burst boot for multiboot software). I am not sure if it is possible to reset the GBA externally without automatically resetting register 300h though. 4000301h - HALTCNT - BYTE - Undocumented - Low Power Mode Control (W) Writing to this register switches the GBA into battery saving mode. In Halt mode, the CPU is paused as long as (IE AND IF)=0, this should be used to reduce power-consumption during periods when the CPU is waiting for interrupt events. In Stop mode, most of the hardware including sound and video are paused, this very-low-power mode could be used much like a screensaver. Bit Expl.The current GBA BIOS addresses only the upper eight bits of this register (by writing 00h or 80h to address 04000301h), however, as the register isn't officially documented, some or all of the bits might have different meanings in future GBA models. For best forwards compatibility, it'd generally be more recommended to use the BIOS Functions SWI 2 (Halt) or SWI 3 (Stop) rather than writing to this register directly. 4000410h - Undocumented - Purpose Unknown ? 8bit (W) The BIOS writes the 8bit value 0FFh to this address. Purpose Unknown. Probably just another bug in the BIOS. 4000800h - 32bit - Undocumented - Internal Memory Control (R/W) Supported by GBA and GBA SP only - NOT supported by DS (even in GBA mode). Initialized to 0D000020h (by hardware). Unlike all other I/O registers, this register is mirrored across the whole I/O area (in increments of 64K, ie. at 4000800h, 4010800h, 4020800h, ..., 4FF0800h) Bit Expl.The value 0Dh in Bits 24-27 selects 2 waitstates for 256K WRAM (ie. 3/3/6 cycles 8/16/32bit accesses). The fastest possible setting would be 0Eh (1 waitstate, 2/2/4 cycles for 8/16/32bit). Note: One cycle equals approx. 59.59ns (ie. 16.78MHz clock).
GamePak Prefetch can be enabled in WAITCNT register. When prefetch buffer is enabled, the GBA attempts to read opcodes from Game Pak ROM during periods when the CPU is not using the bus (if any). Memory access is then performed with 0 Waits if the CPU requests data which is already stored in the buffer. The prefetch buffer stores up to eight 16bit values. GamePak ROM Opcodes The prefetch feature works only with <opcodes> fetched from GamePak ROM. Opcodes executed in RAM or BIOS are not affected by the prefetch feature (even if that opcodes read <data> from GamePak ROM). Prefetch Enable For GamePak ROM opcodes, prefetch may occur in two situations: 1) opcodes with internal cycles (I) which do not change R15, shift/rotatePrefetch Disable Bug When Prefetch is disabled, the Prefetch Disable Bug will occur for all "Opcodes in GamePak ROM with Internal Cycles which do not change R15"for those opcodes, the bug changes the opcode fetch time from 1S to 1N. Note: Affected opcodes (with I cycles) are: Shift/rotate register-by-register opcodes, multiply opcodes, and load opcodes (ldr,ldm,pop,swp).
ROM GBA Cartridge Header GBA Cartridge ROM Backup Media Aside from ROM, cartridges may also include one of the following backup medias, used to store game positions, highscore tables, options, or other data. GBA Cart Backup IDs GBA Cart Backup SRAM/FRAM GBA Cart Backup EEPROM GBA Cart Backup Flash ROM GBA Cart Backup DACS Add-Ons GBA Cart I/O Port (GPIO) GBA Cart Real-Time Clock (RTC) GBA Cart Solar Sensor GBA Cart Tilt Sensor GBA Cart Gyro Sensor GBA Cart Rumble GBA Cart e-Reader GBA Cart Unknown Devices Other Accessoires GBA Flashcards GBA Cheat Devices
The first 192 bytes at 8000000h-80000BFh in ROM are used as cartridge header. The same header is also used for Multiboot images at 2000000h-20000BFh (plus some additional multiboot entries at 20000C0h and up). Header Overview Address Bytes Expl.Note: With all entry points, the CPU is initially set into system mode. 000h - Entry Point, 4 Bytes Space for a single 32bit ARM opcode that redirects to the actual startaddress of the cartridge, this should be usually a "B <start>" instruction. Note: This entry is ignored by Multiboot slave GBAs (in fact, the entry is then overwritten and redirected to a separate Multiboot Entry Point, as described below). 004h..09Fh - Nintendo Logo, 156 Bytes Contains the Nintendo logo which is displayed during the boot procedure. Cartridge won't work if this data is missing or modified. In detail: This area contains Huffman compression data (but excluding the compression header which is hardcoded in the BIOS, so that it'd be probably not possible to hack the GBA by producing de-compression buffer overflows). A copy of the compression data is stored in the BIOS, the GBA will compare this data and lock-up itself if the BIOS data isn't exactly the same as in the cartridge (or multiboot header). The only exception are the two entries below which are allowed to have variable settings in some bits. 09Ch Bit 2,7 - Debugging Enable This is part of the above Nintendo Logo area, and must be commonly set to 21h, however, Bit 2 and Bit 7 may be set to other values. When both bits are set (ie. A5h), the FIQ/Undefined Instruction handler in the BIOS becomes unlocked, the handler then forwards these exceptions to the user handler in cartridge ROM (entry point defined in 80000B4h, see below). Other bit combinations currently do not seem to have special functions. 09Eh Bit 0,1 - Cartridge Key Number MSBs This is part of the above Nintendo Logo area, and must be commonly set to F8h, however, Bit 0-1 may be set to other values. During startup, the BIOS performs some dummy-reads from a stream of pre-defined addresses, even though these reads seem to be meaningless, they might be intended to unlock a read-protection inside of commercial cartridge. There are 16 pre-defined address streams - selected by a 4bit key number - of which the upper two bits are gained from 800009Eh Bit 0-1, and the lower two bits from a checksum across header bytes 09Dh..0B7h (bytewise XORed, divided by 40h). 0A0h - Game Title, Uppercase Ascii, max 12 characters Space for the game title, padded with 00h (if less than 12 chars). 0ACh - Game Code, Uppercase Ascii, 4 characters This is the same code as the AGB-UTTD code which is printed on the package and sticker on (commercial) cartridges (excluding the leading "AGB-" part). U Unique Code (usually "A" or "B" or special meaning)The first character (U) is usually "A" or "B", in detail: A Normal game; Older titles (mainly 2001..2003)The second/third characters (TT) are: Usually an abbreviation of the game title (eg. "PM" for "Pac Man") (unlessThe fourth character (D) indicates Destination/Language: J Japan P Europe/Elsewhere F French S Spanish0B0h - Maker code, Uppercase Ascii, 2 characters Identifies the (commercial) developer. For example, "01"=Nintendo. 0B2h - Fixed value, 1 Byte Must be 96h. 0B3h - Main unit code, 1 Byte Identifies the required hardware. Should be 00h for current GBA models. 0B4h - Device type, 1 Byte Normally, this entry should be zero. With Nintendo's hardware debugger Bit 7 identifies the debugging handlers entry point and size of DACS (Debugging And Communication System) memory: Bit7=0: 9FFC000h/8MBIT DACS, Bit7=1: 9FE2000h/1MBIT DACS. The debugging handler can be enabled in 800009Ch (see above), normal cartridges do not have any memory (nor any mirrors) at these addresses though. 0B5h - Reserved Area, 7 Bytes Reserved, zero filled. 0BCh - Software version number Version number of the game. Usually zero. 0BDh - Complement check, 1 Byte Header checksum, cartridge won't work if incorrect. Calculate as such: chk=0:for i=0A0h to 0BCh:chk=chk-[i]:next:chk=(chk-19h) and 0FFh 0BEh - Reserved Area, 2 Bytes Reserved, zero filled. Below required for Multiboot/slave programs only. For Multiboot, the above 192 bytes are required to be transferred as header-block (loaded to 2000000h-20000BFh), and some additional header-information must be located at the beginning of the actual program/data-block (loaded to 20000C0h and up). This extended header consists of Multiboot Entry point(s) which must be set up correctly, and of two reserved bytes which are overwritten by the boot procedure: 0C0h - Normal/Multiplay mode Entry Point This entry is used only if the GBA has been booted by using Normal or Multiplay transfer mode (but not by Joybus mode). Typically deposit a ARM-32bit "B <start>" branch opcode at this location, which is pointing to your actual initialization procedure. 0C4h (BYTE) - Boot mode The slave GBA download procedure overwrites this byte by a value which is indicating the used multiboot transfer mode. Value Expl.Typically set this byte to zero by inserting DCB 00h in your source. Be sure that your uploaded program does not contain important program code or data at this location, or at the ID-byte location below. 0C5h (BYTE) - Slave ID Number If the GBA has been booted in Normal or Multiplay mode, this byte becomes overwritten by the slave ID number of the local GBA (that'd be always 01h for normal mode). Value Expl.Typically set this byte to zero by inserting DCB 00h in your source. When booted in Joybus mode, the value is NOT changed and remains the same as uploaded from the master GBA. 0C6h..0DFh - Not used Appears to be unused. 0E0h - Joybus mode Entry Point If the GBA has been booted by using Joybus transfer mode, then the entry point is located at this address rather than at 20000C0h. Either put your initialization procedure directly at this address, or redirect to the actual boot procedure by depositing a "B <start>" opcode here (either one using 32bit ARM code). Or, if you are not intending to support joybus mode (which is probably rarely used), ignore this entry.
ROM Size The games F-ZERO and Super Mario Advance use ROMs of 4 MBytes each. Zelda uses 8 MBytes. Not sure if other sizes are manufactured. ROM Waitstates The GBA starts the cartridge with 4,2 waitstates (N,S) and prefetch disabled. The program may change these settings by writing to WAITCNT, the games F-ZERO and Super Mario Advance use 3,1 waitstates (N,S) each, with prefetch enabled. Third-party flashcards are reportedly running unstable with these settings. Also, prefetch and shorter waitstates are allowing to read more data and opcodes from ROM is less time, the downside is that it increases the power consumption. ROM Chip Because of how 24bit addresses are squeezed through the Gampak bus, the cartridge must include a circuit that latches the lower 16 address bits on non-sequential access, and that increments these bits on sequential access. Nintendo includes this circuit directly in the ROM chip. Also, the ROM must have 16bit data bus (or a circuit which converts two 8bit data units into one 16bit unit - by not exceeding the waitstate timings).
Nintendo didn't include a backup-type entry in the ROM header, however, the required type can be detected by ID strings in the ROM-image. Nintendo's tools are automatically inserting these strings (as part of their library headers). When using other tools, you may insert ID strings by hand. ID Strings The ID string must be located at a word-aligned memory location, the string length should be a multiple of 4 bytes (padded with zero's). EEPROM_Vnnn EEPROM 512 bytes or 8 Kbytes (4Kbit or 64Kbit)For Nintendo's tools, "nnn" is a 3-digit library version number. When using other tools, best keep it set to "nnn" rather than inserting numeric digits. Notes No$gba does auto-detect most backup types, even without ID strings, except for 128K FLASH (without ID "FLASH1M_Vnnn", the FLASH size defaults to 64K). Ideally, for faster detection, the ID should be put into the first some bytes of the ROM-image (ie. somewhere right after the ROM header).
SRAM - 32 KBytes (256Kbit) Lifetime: Depends on back-up battery FRAM - 32 KBytes (256Kbit) Lifetime: 10,000,000,000 read/write per bit Hyundai GM76V256CLLFW10 SRAM (Static RAM) (eg. F-Zero) Fujitsu MB85R256 FRAM (Ferroelectric RAM) (eg. Warioware Twisted) Addressing and Waitstates SRAM/FRAM is mapped to E000000h-E007FFFh, it should be accessed with 8 waitstates (write a value of 3 into Bit0-1 of WAITCNT). Databus Width The SRAM/FRAM databus is restricted to 8 bits, it should be accessed by LDRB, LDRSB, and STRB opcodes only. Reading and Writing Reading from SRAM/FRAM should be performed by code executed in WRAM only (but not by code executed in ROM). There is no such restriction for writing. Preventing Data Loss The GBA SRAM/FRAM carts do not include a write-protect function (unlike older 8bit gameboy carts). This seems to be a problem and may cause data loss when a cartridge is removed or inserted while the GBA is still turned on. As far as I understand, this is not so much a hardware problem, but rather a software problem, ie. theoretically you could remove/insert the cartridge as many times as you want, but you should take care that your program does not crash (and write blindly into memory). Recommended Workaround Enable the Gamepak Interrupt (it'll most likely get triggered when removing the cartridge), and hang-up the GBA in an endless loop when your interrupt handler senses a Gamepak IRQ. For obvious reason, your interrupt handler should be located in WRAM, ie. not in the (removed) ROM cartridge. The handler should process Gamepak IRQs at highest priority. Periods during which interrupts are disabled should be kept as short as possible, if necessary allow nested interrupts. When to use the above Workaround A program that relies wholly on code and data in WRAM, and that does not crash even when ROM is removed, may keep operating without having to use the above mechanism. Do NOT use the workaround for programs that run without a cartridge inserted (ie. single gamepak/multiboot slaves), or for programs that use Gamepak IRQ/DMA for other purposes. All other programs should use it. It'd be eventually a good idea to include it even in programs that do not use SRAM/FRAM themselves (eg. otherwise removing a SRAM/FRAM-less cartridge may lock up the GBA, and may cause it to destroy backup data when inserting a SRAM/FRAM cartridge). SRAM vs FRAM FRAM (Ferroelectric RAM) is a newer technology, used in newer GBA carts, unlike SRAM (Static RAM), it doesn't require a battery to hold the data. At software side, it is accessed exactly like SRAM, ie. unlike EEPROM/FLASH, it doesn't require any Write/Erase commands/delays. Note In SRAM/FRAM cartridges, the /REQ pin (Pin 31 of Gamepak bus) should be a little bit shorter as than the other pins; when removing the cartridge, this causes the gamepak IRQ signal to get triggered before the other pins are disconnected.
9853 - EEPROM 512 Bytes (0200h) (4Kbit) (eg. used by Super Mario Advance) 9854 - EEPROM 8 KBytes (2000h) (64Kbit) (eg. used by Boktai) Lifetime: 100,000 writes per address Addressing and Waitstates The eeprom is connected to Bit0 of the data bus, and to the upper 1 bit (or upper 17 bits in case of large 32MB ROM) of the cartridge ROM address bus, communication with the chip takes place serially. The eeprom must be used with 8 waitstates (set WAITCNT=X3XXh; 8,8 clks in WS2 area), the eeprom can be then addressed at DFFFF00h..DFFFFFFh. Respectively, with eeprom, ROM is restricted to 8000000h-9FFFeFFh (max. 1FFFF00h bytes = 32MB minus 256 bytes). On carts with 16MB or smaller ROM, eeprom can be alternately accessed anywhere at D000000h-DFFFFFFh. Data and Address Width Data can be read from (or written to) the EEPROM in units of 64bits (8 bytes). Writing automatically erases the old 64bits of data. Addressing works in units of 64bits respectively, that is, for 512 Bytes EEPROMS: an address range of 0-3Fh, 6bit bus width; and for 8KByte EEPROMs: a range of 0-3FFh, 14bit bus width (only the lower 10 address bits are used, upper 4 bits should be zero). Set Address (For Reading) Prepare the following bitstream in memory: 2 bits "11" (Read Request)Then transfer the stream to eeprom by using DMA. Read Data Read a stream of 68 bits from EEPROM by using DMA, then decipher the received data as follows: 4 bits - ignore theseWrite Data to Address Prepare the following bitstream in memory, then transfer the stream to eeprom by using DMA, it'll take ca. 108368 clock cycles (ca. 6.5ms) until the old data is erased and new data is programmed. 2 bits "10" (Write Request)After the DMA, keep reading from the chip, by normal LDRH [DFFFF00h], until Bit 0 of the returned data becomes "1" (Ready). To prevent your program from locking up in case of malfunction, generate a timeout if the chip does not reply after 10ms or longer. Using DMA Transferring a bitstream to/from the EEPROM by LDRH/STRH opcodes does not work, this might be because of timing problems, or because how the GBA squeezes non-sequential memory addresses through the external address/data bus. For this reason, a buffer in memory must be used (that buffer would be typically allocated temporarily on stack, one halfword for each bit, bit1-15 of the halfwords are don't care, only bit0 is of interest). The buffer must be transfered as a whole to/from EEPROM by using DMA3 (only DMA 3 is valid to read & write external memory), use 16bit transfer mode, both source and destination address incrementing (ie. DMA3CNT=80000000h+length). DMA channels of higher priority should be disabled during the transfer (ie. H/V-Blank or Sound FIFO DMAs). And, of course any interrupts that might mess with DMA registers should be disabled. Pin-Outs The EEPROM chips are having only 8 pins, these are connected, Pin 1..8, to ROMCS, RD, WR, AD0, GND, GND, A23, VDD of the GamePak bus. Carts with 32MB ROM must have A7..A22 logically ANDed with A23. Notes There seems to be no autodection mechanism, so that a hardcoded bus width must be used.
64 KBytes - 512Kbits Flash ROM - Lifetime: 10,000 writes per sector 128 KBytes - 1Mbit Flash ROM - Lifetime: ??? writes per sector Chip Identification (all device types) [E005555h]=AAh, [E002AAAh]=55h, [E005555h]=90h (enter ID mode)Used to detect the type (and presence) of FLASH chips. See Device Types below. Reading Data Bytes (all device types) dat=[E00xxxxh] (read byte from address xxxx)Erase Entire Chip (all device types) [E005555h]=AAh, [E002AAAh]=55h, [E005555h]=80h (erase command)Erases all memory in chip, erased memory is FFh-filled. Erase 4Kbyte Sector (all device types, except Atmel) [E005555h]=AAh, [E002AAAh]=55h, [E005555h]=80h (erase command)Erases memory at E00n000h..E00nFFFh, erased memory is FFh-filled. Erase-and-Write 128 Bytes Sector (only Atmel devices) old=IME, IME=0 (disable interrupts)Interrupts (and DMAs) should be disabled during command/write phase. Target address must be a multiple of 80h. Write Single Data Byte (all device types, except Atmel) [E005555h]=AAh, [E002AAAh]=55h, [E005555h]=A0h (write byte command)The target memory location must have been previously erased. Terminate Command after Timeout (only Macronix devices, ID=1CC2h) [E005555h]=F0h (force end of write/erase command)Use if timeout occurred during "wait until" periods, for Macronix devices only. Bank Switching (devices bigger than 64K only) [E005555h]=AAh, [E002AAAh]=55h, [E005555h]=B0h (select bank command)Specifies 64K bank number for read/write/erase operations. Required because gamepak flash/sram addressbus is limited to 16bit width. Device Types Nintendo puts different FLASH chips in commercial game cartridges. Developers should thus detect & support all chip types. For Atmel chips it'd be recommended to simulate 4K sectors by software, though reportedly Nintendo doesn't use Atmel chips in newer games anymore. Also mind that different timings should not disturb compatibility and performance. ID Name Size Sectors AverageTimings Timeouts/ms WaitsIdentification Codes MSB=Device Type, LSB=Manufacturer. Size in bytes, and numbers of sectors * sector size in bytes. Average medium Write, Erase Sector, Erase Chips timings are unknown? Timeouts in milliseconds for Write, Erase Sector, Erase Chips. Waitstates for Writes, and Reads in clock cycles. Accessing FLASH Memory FLASH memory is located in the "SRAM" area at E000000h..E00FFFFh, which is restricted to 16bit address and 8bit data buswidths. Respectively, the memory can be accessed <only> by 8bit read/write LDRB/STRB opcodes. Also, reading anything (data or status/busy information) can be done <only> by opcodes executed in WRAM (not from opcodes in ROM) (there's no such restriction for writing). FLASH Waitstates Use 8 clk waitstates for initial detection (WAITCNT Bits 0,1 both set). After detection of certain device types smaller wait values may be used for write/erase, and even smaller wait values for raw reading, see Device Types table. In practice, games seem to use smaller values only for write/erase (even though those operations are slow anyways), whilst raw reads are always done at 8 clk waits (even though reads could actually benefit slightly from smaller wait values). Verify Write/Erase and Retry Even though device signalizes the completion of write/erase operations, it'd be recommended to read/confirm the content of the changed memory area by software. In practice, Nintendo's "erase-write-verify-retry" function typically repeats the operation up to three times in case of errors. Also, for SST devices only, the "erase-write" and "erase-write-verify-retry" functions repeat the erase command up to 80 times, additionally followed by one further erase command if no retries were needed, otherwise followed by six further erase commands. Note FLASH (64Kbytes) is used by the game Sonic Advance, and possibly others.
128 KBytes - 1Mbit DACS - Lifetime: 100,000 writes. 1024 KBytes - 8Mbit DACS - Lifetime: 100,000 writes. DACS (Debugging And Communication System) is used in Nintendo's hardware debugger only, DACS is NOT used in normal game cartridges. Parts of DACS memory is used to store the debugging exception handlers (entry point/size defined in cartridge header), the remaining memory could be used to store game positions or other data. The address space is the upper end of the 32MB ROM area, the memory can be read directly by the CPU, including for ability to execute program code in this area.
4bit General Purpose I/O Port (GPIO) - contained in the ROM-chip Used by Boktai for RTC and Solar Sensor: GBA Cart Real-Time Clock (RTC) GBA Cart Solar Sensor And by Warioware Twisted for Rumble and Z-Axis Sensor: GBA Cart Rumble GBA Cart Gyro Sensor Might be also used by other games for other purposes, such like other sensors, or SRAM bank switching, etc. The I/O registers are mapped to a 6-byte region in the ROM-area at 80000C4h, the 6-byte region should be zero-filled in the ROM-image. In Boktai, the size of the zero-filled region is 0E0h bytes - that probably due to an incorrect definition (the additional bytes do not contain any extra ports, nor mirrors of the ports in the 6-byte region). Observe that ROM-bus writes are limited to 16bit/32bit access (STRB opocdes are ignored; that, only in DS mode?). 80000C4h - I/O Port Data (selectable W or R/W) bit0-3 Data Bits 0..3 (0=Low, 1=High)80000C6h - I/O Port Direction (for above Data Port) (selectable W or R/W) bit0-3 Direction for Data Port Bits 0..3 (0=In, 1=Out)80000C8h - I/O Port Control (selectable W or R/W) bit0 Register 80000C4h..80000C8h Control (0=Write-Only, 1=Read/Write)In write-only mode, reads return 00h (or possible other data, if the rom contains non-zero data at that location). Connection Examples GPIO | Boktai | WarioAside from the I/O Port, the ROM-chip also includes an inverter (used for inverting the RTC /IRQ signal), and some sort of an (unused) address decoder output (which appears to be equal or related to A23 signal) (ie. reacting on ROM A23, or SRAM D7, which share the same pin on GBA slot).
S3511 - 8pin RTC with 3-wire serial bus (used in Boktai) The RTC chip is (almost) the same as used in NDS consoles: DS Real-Time Clock (RTC) The chip is accessed via 4bit I/O port (only 3bits are used for RTC): GBA Cart I/O Port (GPIO) Comparision of RTC Registers NDS_________GBA_________GBA/Params___Control Register Bit Dir Expl.Setting after Battery-Shortcut is 82h. Setting after Force-Reset is 00h. Unused bits seem to be always zero, but might be read-only or write-only? Datetime and Time Registers Same as NDS, except AM/PM flag moved from hour.bit6 (NDS) to hour.bit7 (GBA). Force Reset/Irq Registers Used to reset all RTC registers (all used registers become 00h, except day/month which become 01h), or to drag the IRQ output LOW for a short moment. These registers are strobed by ANY access to them, ie. by both writing to, as well as reading from these registers. Pin-Outs / IRQ Signal The package has identical pin-outs as in NDS, although it is slightly larger than the miniature chip in the DS. For whatever reason, the RTC's /IRQ output is passed through an inverter (contained in the ROM-chip), the inverted signal is then passed to the /IRQ pin on the cartridge slot. So, IRQ's will be triggered on the "wrong" edge - possible somehow in relation with detecting cartridge-removal IRQs?
Uses a Photo Diode as Solar Sensor (used in Boktai, allowing to defeat vampires when the cartridge is exposed to sunlight). The cartridge comes in transparent case, and it's slightly longer than normal carts, so the sensor reaches out of the cartridge slot. According to the manual, the sensor works only with sunlight, but actually it works with any strong light source (eg. a 100 Watt bulb at 1-2 centimeters distance). The sensor is accessed via 4bit I/O port (only 3bits used), which is contained in the ROM-chip. GBA Cart I/O Port (GPIO) A/D Conversion The cartridge uses a self-made A/D converter, which is (eventually) better than measuring a capacitor charge-up time, and/or less expensive than a real ADC-chip: It contains a 74LV4040 12bit binary counter (clocked by CPU via the I/O port), of which only the lower 8bit are used, which are passed to a resistor ladder-type D/A converter, which is generating a linear increasing voltage, which is passed to a TLV272 voltage comparator, which is passing a signal to the I/O port when the counter voltage becomes greater than the sensor voltage. Example Code strh 0001h,[80000c8h] ;-enable R/W modeThe results vary depending on the clock rate used. In above example, ensure that IRQs or DMAs do not interrupt the function. Alternately, use a super-slow clock rate (eg. like 666Hz used in Boktai) so that additional small IRQ/DMA delays have little effect on the overall timing. Results should be somewhat: E8h total darkness (including daylight on rainy days)The exact values may change from cartridge to cartridge, so it'd be recommened to include a darkness calibration function, prompting the user to cover the sensor for a moment.
Yoshi's Universal Gravitation / Yoshi Topsy Turvy (X/Y-Axis) Koro Koro Puzzle (probably same as Yoshi, X/Y-Axis, too) (?) Yoshi-Type (X/Y-Axis) All of the registers are one byte wide, mapped into the top "half" of the SRAM memory range. E008000h (W) Write 55h to start samplingYou must set SRAM wait control to 8 clocks to access it correctly. You must also set the cartridge PHI terminal to 4 MHz to make it work. Sampling routine (typically executed once a frame during VBlank): wait until [E008300h].Bit7=1 or until timeout ;wait readyExample values (may vary on different carts and on temperature, etc): X ranged between 0x2AF to 0x477, center at 0x392. Huh?Thanks to Flubba for Yoshi-Type information. Unknown if the Yoshi-Type sensors are sensing rotation, or orientation, or motion, or something else? In case of rotation, rotation around X-axis would result in motion in Y-direction, so not too sure whether X and Y have which meaning? Most probably, the sensors are measuring (both) static acceleration (gravity), and dynamic acceleration (eg. shaking the device left/right). The X/Y values are likely to be mirrored depending on using a back-loading cartridge slot (original GBA), or front-loading cartridge slot (newer GBA SP, and NDS, and NDS-Lite).
Warioware Twisted (Z-Axis Gyro Sensor, plus Rumble) Wario-Type (Z-Axis) Uses a single-axis sensor, which senses rotation around the Z-axis. The sensor is connected to an analogue-in, serial-out ADC chip, which is accessed via lower 3 bits of the GPIO, GBA Cart I/O Port (GPIO) The four I/O Lines are connected like so, GPIO.Bit0 (W) Start ConversionThere should be at least <three sequential 32bit ARM opcodes executed in WS0 region> between the STRH opcodes which toggle the CLK signal. Wario uses WAITCNT=45B7h (SRAM=8clks, WS0/WS1/WS2=3,1clks, Prefetch=On, PHI=Off). The data stream consists of: 4 dummy bits (usually zero), followed by 12 data bits, followed by endless unused bits (usually zero). read_gyro:Example values (may vary on different carts, battery charge, temperature, etc): 354h rotated in anti-clockwise direction (shock-speed)For detection, values 000h and FFFh would indicate that there's no sensor. The Z-axis always points into same direction; no matter of frontloading or backloading cartridge slots. Thanks to Momo Vampire for contributing a Wario cartridge. X/Y/Z-Axes X-Axis and Y-Axis are meant to be following the screens X and Y coordinates, so the Z-Axis would point into the screens depth direction.
Warioware Twisted (Rumble, plus Z-Axis Gyro Sensor) Drill Dozer (Rumble only) GBA Rumble Carts are containing a small motor, which is causing some vibration when/while it is switched on (that, unlike DS Rumble, which must be repeatedly toggled on/off). In Warioware Twisted, rumble is controlled via GPIO.Bit3 (Data 0=Low=Off, 1=High=On) (and Direction 1=Output), the other GPIO Bits are used for the gyro sensor. GBA Cart I/O Port (GPIO) Note: GPIO3 is connected to an external pulldown resistor (so the HighZ level gets dragged to Low=Off when direction is set to Input). Unknown if Drill Dozer is controlled via GPIO.Bit3, too? DS Rumble Pak Additionally, there's a Rumble Pak for the NDS, which connects to the GBA slot, so it can be used also for GBA games (provided that the game doesn't require the GBA slot, eg. GBA multiboot games). DS Cart Rumble Pak Gamecube Rumble Moreover, GBA games that are running on a Gameboy Player are having access to the Rumble function of Gamecube joypads. GBA Gameboy Player
GBA Cart e-Reader Overview GBA Cart e-Reader I/O Ports GBA Cart e-Reader Dotcode Format GBA Cart e-Reader Data Format GBA Cart e-Reader Program Code GBA Cart e-Reader API Functions GBA Cart e-Reader VPK Decompression GBA Cart e-Reader Error Correction GBA Cart e-Reader File Formats ________________
The e-Reader is a large GBA cartridge (about as big as the GBA console), with built-in dotcode scanning hardware. Dotcodes are tiny strips of black and white pixels printed on the edges of cardboard cards. The cards have to be pulled through a slot on the e-Reader, which is giving it a feeling like using a magnet card reader. The binary data on the dotcodes contains small games, either in native GBA code (ARM/THUMB), or in software emulated 8bit Z80 or NES/Famicom (6502) code. The e-Reader Hardware The hardware consists of regular 8MByte ROM and 128KByte FLASH chips, two link ports, a custom PGA chip, the camera module (with two red LEDs, used as light source), and some analogue components for generating the LED voltages, etc. The camera supports 402x302 pixels with 7bit monochrome color depth, but the PGA clips it to max 320 pixels per scanline with 1bit color depth. Link Port Plug/Socket The e-Reader's two link ports are simply interconnected with each other; without connection to the rest of the e-Reader hardware. These ports are used only on the original GBA (where the large e-Reader cartridge would be covering the GBA's link socket). When trying to insert the e-Reader into an original NDS, then the e-Reader's link plug will hit against the case of the NDS, so it works only with some minor modification to the hardware. There's no such problem with GBA-SP and NDS-Lite. Region/Version There are 3 different e-Reader's: Japanese/Original, Japanese/Plus, and Non-Japanese. The Original version has only 64K FLASH, no Link Port, and reportedly supports only Z80 code, but no NES/GBA code. The Plus and Non-Japanese versions should be almost identical, except that they reject cards from the wrong region, and that the title strings aren't ASCII in Japan, the Plus version should be backwards compatible to the Original one. The Problem Nintendo's current programmers are definetly unable to squeeze a Pac-Man style game into less than 4MBytes. Their solution has been: MORE memory. That is, they've put a whopping 8MByte BIOS ROM into the e-Reader, which contains the User Interface, and software emulation for running some of their 20 years old 8bit NES and Game&Watch titles, which do fit on a few dotcode strips.
DF80000h Useless Register (R/W) 0 Output to PGA.Pin93 (which seems to be not connected to anything)DFA0000h Reset Register (R/W) 0 Always zero (0)DFC0000h..DFC0027h Scanline Data (R) Scanline data (40 bytes, for 320 pixels, 1bit per pixel, 0=black, 1=white). The first (leftmost) pixel is located in the LSB of the LAST byte. Port E00FFB1h.Bit1 (and [4000202h].Bit13) indicates when a new scanline is present, the data should be then transferred to RAM via DMA3 (SAD=DFC0000h, DAD=buf+y*28h, CNT=80000014h; a slower non-DMA transfer method would result in missed scanlines). After the DMA, software must reset E00FFB1h.Bit1. Note: The scanning resolution is 1000 DPI. DFC0028h+(0..2Fh*2) Brightest Pixels of 8x6 Blocks (R) 0-6 Max Brightness (00h..7Fh; 00h=All black, 7Fh=One or more white)Can be used to adjust the Port E00FF80h..E00FFAFh settings. DFC0088h Darkest Pixel of whole Image (R) 0-7 Max Darkness (00h..7Fh; 00h=One or more black, 7Fh=All white)Can be used to adjust the Port E00FF80h..E00FFAFh settings. E00FF80h..E00FFAFh Intensity Boundaries for 8x6 Blocks (R/W) The 320x246 pixel camera input is split into 8x6 blocks (40x41 pixels each), with Block00h=Upper-right, Block07h=Upper-left, ..., Block27h=Lower-left. The boundary values for the separate blocks are used for 128-grayscale to 2-color conversion, probably done like "IF Pixel>Boundary THEN white ELSE black". 0-6 Block Intensity Boundaries (0..7Fh; 7Fh=Whole block gets black)The default boundary values are stored in FLASH memory, the values are typically ranging from 28h (outer edges) to 34h (center image), that in respect to the light source (the two LEDs are emitting more light to the center region). E00FFB0h Control Register 0 (R/W) 0 Serial Data (Low/High)E00FFB1h Control Register 1 (R/W) 0 Not used (always 0)Bit1 can be SET by hardware only, software can only RESET that bit, the Gamepak IRQ flag (Port 4000202h.Bit13) becomes set on 0-to-1 transitions. E00FFB2h Light Source LED Kathode Duration (LSB) (R/W) E00FFB3h Light Source LED Kathode Duration (MSB) (R/W) Selects the LED Kathode=LOW Duration, aka the LED=ON Duration. That does act as pulse width modulated LED brightness selection (the camera seems to react slowly enough to view the light as being dimmed to medium, rather than seeing the actual light ON and OFF states). The PWM timer seems to be clocked at 8MHz. The hardware clips timer values 2000h..FFFFh to max 2000h (=1ms). Additionally, the e-Reader BIOS clips values to max 11B3h. Default setting is found in FLASH calibration data. A value of 0000h disables the LED. Serial Port Registers (Camera Type 1) (DV488800) (calib_data[3Ch]=1) All 16bit values are ordered MSB,LSB. All registers are whole 8bit Read/Write-able, except 00h,57h-5Ah (read only), and 53h-55h (2bit only). Port Expl. (e-Reader Setting)All other ports are unused, writes to those ports are ignored, and reads are returning data mirrored from other ports; that is typically data from 2 or more ports, ORed together. Serial Port Registers (Camera Type 2) (calib_data[3Ch]=2) All 16bit values are using more conventional LSB,MSB ordering, and port numbers are arranged in a more reasonable way. The e-Reader BIOS doesn't support (or doesn't require) brightness adjustment for this camera module. Port Expl. (e-Reader Setting)My own e-Reader uses a Type 1 camera module. Not sure if Nintendo has ever manufactured any e-Readers with Type 2 cameras? Calibration Data in FLASH Memory (Bank 0, Sector 0Dh) E00D000 14h ID String ('Card-E Reader 2001',0,0)
Begin of actual data (40h bytes)E00D016 8x6 [00h] Intensity Boundaries for 8x6 blocks ;see E00FF80h..AFhRemaining bytes in this Sector... E00D056 FAAh Not used (zerofilled) (included in above checksum)Flowchart for Overall Camera Access ereader_scan_camera: call ereader_power_onereader_power_on: [4000204h]=5803h ;Init waitstates, and enable Phi 16MHzereader_power_off: [E00FFB0h]=04h ;Power3V=Off, Disable Everything, SioDtaClkDir=LowLowOutereader_initialize: IF calib_data[3Ch] AND 03h = 1 THEN init_camera_type1init_camera_type1: x=MIN(0,calib_data[31h]-0Bh)init_camera_type2: Wait(0.5ms)Accessing Serial Registers via E00FFB0h Begin Write(A) Write(B) Read(C) Read(D) End Idle PwrOffFlowchart for accessing Serial Registers via E00FFB0h Delay:Caution: Accessing the SIO registers appears highly unstable, and seems to require error handling with retries. Not sure what is causing that problem, possibly the registers cannot be accessed during camera-data-scans...? WAITCNT The e-Reader BIOS uses WAITCNT [4000204h]=5803h when accessing the PGA, that is, gamepak 16.78MHz phi output (bit11-12=3), 8 waits for SRAM region (bit0-1=3), gamepak prefetch enabled (bit14=1), also sets WS0 to 4,2 waits (bit2-4=0), and sets WS2 to odd 4,8 waits (bit8-10=0). The WS2 (probably WS0 too) settings are nonsense, and should work with faster timings (the e-Reader can be accessed in NDS mode, which doesn't support that slow timings). e-Reader Memory and I/O Map (with all used/unused/mirrored regions) C000000h-C7FFFFFh ROM (8MB)Mind that WS2 should be accessed by LDRH/STRH, and SRAM region by LDRB/STRB. Additionally about 32 serial bus registers are contained in the camera module. Camera Module Notes The Type 1 initial setting on power-on is 402x302 pixels, the e-Reader uses only 320x246 pixels. The full vertical resolution could be probably used without problems. Port DFC0000h-DFC0027h are restricted to 320 pixels, so larger horizontal resolutions could be probably obtained only by changing the horizontal scroll offset on each 2nd scan. The camera output is 128 grayscales (via parallel 7bit databus), but the PGA converts it to 2 colors (1bit depth). For still images, it might be possible to get 4 grayshades via 3 scans with different block intensity boundary settings. No idea if the camera supports serial commands other than 22h and 23h. Namely, it <would> be a quite obvious and basic feature to allow to receive the bitmap via the 2-wire serial bus (alternately to the 7bit databus), if supported, it'd allow to get 7bit images, bypassing 1bit PGA conversion. When used as actual camera (by cutting an opening in the case), the main problem is the 1bit color depth, which allows only black and white schemes, when/if solving that problem, focusing might be also a problem. Either the camera or the PGA seem to have a problem on white-to-black transitions in vertical direction, the upper some black pixels are sorts of getting striped or dithered. For example, scanning the large sync marks appears as: Actual Shape Scanned ShapeThat appears only on large black shapes (the smaller data dots look better).
Resolution is 342.39 DPI (almost 10 blocks per inch). Resolution is 134.8 dots/cm (almost 4 blocks per centimeter). The width and height of the each block, and the spacing to the bottom edge of the card is ca. 1/10 inch, or ca. 4 millimeters. XXX BLOCK 1 XXX BLOCK 2 XXXAddress Columns Each Column consists of 26 dots. From top to bottom: 1 black dot, 8 blank dots, 16 address dots (MSB topmost), and 1 blank dot. The 16bit address values can be calculated as: addr[0] = 03FFhShort strips use addr[1..19], long strips use addr[25..53], left to right. Block Header The 18h-byte Block Header is taken from the 1st two bytes (20 dots) of the 1st 0Ch blocks (and is then repeated in the 1st two bytes of further blocks). 00h Unknown (00h)Data 4-Bit to 5-bit Conversion In the Block Header (HHHHH), and Data Region (.....), each 4bit are expanded to 5bit, so one byte occupies 10 dots, and each block (1040 data dots) contains 104 bytes. 4bit 00h 01h 02h 03h 04h 05h 06h 07h 08h 09h 0Ah 0Bh 0Ch 0Dh 0Eh 0FhThat formatting ensures that there are no more than two continous black dots (in horizontal direction), neither inside of a 5bit value, nor between two 5bit values, however, the address bars are violating that rule, and up to 5 continous black dots can appear at the (..A..) block boundaries. Data Order Data starts with the upper bit of the 5bit value for the upper 4bit of the first byte, which is located at the leftmost dot of the upper line of the leftmost block, it does then extend towards rightmost dot of that block, and does then continue in the next line, until reaching the bottom of the block, and does then continue in the next block. The 1st two bytes of each block contain a portion of the Block Header, the remaining 102 bytes in each block contain data. Data Size A long strip consists of 28 blocks (28*104 = 2912 bytes), a short strip of 18 blocks (18*104 = 1872 bytes). Of which, less than 75% can be actually used for program code, the remaing data contains error correction info, and various headers. See Data Format for more info. Interleaved Fragments The Interleave Value (I) specifies the number of fragments, and does also specify the step to the next byte inside of a fragment; except that, at the block boundaries (every 104 bytes), the step is 2 bigger (for skipping the next two Block Header bytes). RAW Offset ContentEach fragment consists of 48 actual data bytes, followed by 16 error correction bytes, followed by 0..2 unused bytes (since I*40h doesn't exactly match num_blocks*102).
Data Strip Format The size of the data region is I*48 bytes (I=Interleave Value, see Dotcode Format), the first 48-byte fragment contains the Data Header, the remaining (I-1) fragments are Data Fragments (which contain title(s), and VPK compressed program code). First Strip Data Header (48 bytes)Further Strip(s) Data Header (48 bytes)Data Header (30h bytes) (1st fragment) 00h-01h Fixed (00h,30h)Primary Type [03h] is 8bit, 0 Card Type (upper bit) (see below)Region/Type [0Ch..0Dh] is 16bit, 0-3 Unknown (don't care)Size Info [26h-29h] is 32bit, 0 Unknown (don't care)Flags [2Ah-2Dh] is 32bit, 0 Permission to save (0=Start Immediately, 1=Prompt for FLASH Saving)Data Checksum [13h-14h] is the complement (NOT) of the sum of all halfwords in all Data Fragments, however, it's all done in reversed byte order: checksum is calculated with halfwords that are read in MSB,LSB order, and the resulting checksum is stored in MSB,LSB order in the Header Fragment. Global Checksum [2Fh] is the complement (NOT) of the sum of the first 2Fh bytes in the Data Header plus the sum of all Data Fragment checksums; the Data Fragment checksums are all 30h bytes in a fragment XORed with each other. Titles (3+N bytes, or N bytes) Titles can be 33 bytes for both Main and Sub (Format 0Eh), or Main=17 bytes and Sub=3+18 bytes (Formats 02h..05h). In the 3+N bytes form, the first 3 bytes (24bit) are are used to display "stats" information in form of "HP: h1 ID: i1-i2-i3", defined as: Bit Expl.The N bytes portion contains the actual title, which must be terminated by 00h (so the max length is N-1 characters, if it is shorter than N-1, then the unused bytes are padded by further 00h's). The character set is normal ASCII for non-Japan (see Region/Version entry in header), and 2-byte SHIFT-JIS for Japanese long-titles (=max 16 2-byte chars) with values as so: 00h --> end-byteAnd 1-byte chars for Japanese short-titles, 00 = end-byteAdditionally to the Main-Title, optional Sub-Titles for each strip can be included (see Sub-Title Flag in header). If enabled, then ALL strip titles are included in each strip (allowing to show a preview of which strips have/haven't been scanned yet). The e-Reader can display maximum of 8 sub-titles, if the data consists of more than 8 strips, then sub-titles aren't displayed (so it'd be waste of space to include them in the dotcodes). The Main Title gets clipped to 128 pixels width (that are, circa 22 characters), and, the e-Reader BIOS acts confused on multi-strip games with Main Titles longer than 26 characters (so the full 33 bytes may be used only in Japan; with 16bit charset). If the title is empty (00h-filled), and there is only one card in the application, then the application is started immediately. That, without allowing the user to save it in FLASH memory. Caution: Although shorter Titles do save memory, they do act unpleasant: the text "(C) P-Letter" will be displayed at the bottom of the loading screen. On Japanese/Original, 8bit sub-titles can be up to 18 characters (without any end-byte) (or less when stats are enabled, due to limited screen width). Card Types (Primary Type.Bit0 and Region/Type.Bit12-15) 00h..01h Blank Screen (?)The 'Application' types are meant to be executable GBA/Z80/NES programs.
The GBA/Z80/NES program code is stored in the VPK compressed area. NES-type is indicated by header [2Ah].Bit2, GBA-type is indicated by the NULL value inserted between VPK Size and VPK Data, otherwise Z80-type is used. GBA Format Load Address and Entrypoint are at 2000000h (in ARM state). The 32bit word at 2000008h is eventually destroyed by the e-Reader. Namely, IF e-Reader is Non-Japanese,Existing multiboot-able GBA binaries can be converted to e-Reader format by, Store "B 20000C0h" at 2000000h ;redirect to RAM-entrypointThe GBA code has full access to the GBA hardware, and may additionally use whatever API functions contained in the e-Reader BIOS. With the incoming LR register value, "mov r0,N, bx lr" returns to the e-Reader BIOS (with N being 0=Restart, or 2=To_Menu). No idea if it's necessary to preserve portions of RAM when returning to the e-Reader BIOS? Caution: Unlike for normal GBA cartridges/multiboot files, the hardware is left uninitialized when booting dotcodes (among others: sound DMA is active, and brightness is set to zero), use "mov r0,0feh, swi 010000h" to get the normal settings. NES Format Emulates a NES (Nintendo Entertainment System) console (aka Family Computer). The visible 240x224 pixel NES/NTSC screen resolution is resampled to 240x160 to match the smaller vertical resolution of the GBA hardware. So, writing e-Reader games in NES format will result in blurred screen output. The screen/sound/joypad is accessed via emulated NES I/O ports, program code is running on an emulated 6502 8bit CPU, for more info on the NES hardware, see no$nes debugger specifications, or http://nocash.emubase.de/everynes.htmThe e-Reader's NES emulator supports only 16K PRG ROM, followed by 8K VROM. The emulation accuracy is very low, barely working with some of Nintendo's own NES titles; running the no$nes diagnostics program on it has successfully failed on ALL hardware tests ;-) The load address for the 16K PRG-ROM is C000h, the 16bit NMI vector at [FFFAh] is encrypted like so: for i=17h to 0The 16bit reset vector at [FFFCh] contains: Bit0-14 Lower bits of Entrypoint (0..7FFFh = Address 8000h..FFFFh)reportedly, (NES limitations, 1 16K program rom + 1-2 8K CHR rom, mapper 0 and 1)The L+R Button key-combination allows to reset the NES, however, there seems to be no way to return to the e-Reader BIOS. Z80/8080 Format The e-Reader doesn't support the following Z80 opcodes: CB [Prefix] E0 RET PO E2 JP PO,nn E4 CALL PO,nn 27 DAA 76 HALTThat is leaving not more than six supported Z80 opcodes (DJNZ, JR, JR c/nc/z/nz), everything else are 8080 opcodes. Custom opcodes are: 76 WAIT A frames, D3 WAIT n frames, and C7/CF RST 0/8 used for API calls.The load address and entrypoint are at 0100h in the emulated Z80 address space. The Z80 doesn't have direct access to the GBA hardware, instead video/sound/joypad are accessed via API functions, invoked via RST 0 and RST 8 opcodes, followed by an 8bit data byte, and with parameters in the Z80 CPU registers. For example, "ld a,02h, rst 8, db 00h" does return to the e-Reader BIOS. The Z80/8080 emulation is incredibly inefficient, written in HLL code, developed by somebody whom knew nothing about emulation nor about ARM nor about Z80/8080 processors. Running GBA-code on Japanese/Original e-Reader Original e-Reader supports Z80 code only, but can be tweaked to run GBA-code: retry:
Z80 Interface (Special Opcodes) db 76h ;Wait8bit AFor jap/ori, 9Fxxh isn't forwards compatible with jap/plus, so it'd be better to check joypad via IoRead. GBA Interface bx [30075FCh] ;ApiVector ;in: r0=func_no,r1,r2,r3,[sp+0],[sp+4],[sp+8]=paramsWait8bit/Wait16bit The various Wait opcodes and functions are waiting as many frames as specified. Many API functions have no effect until the next Wait occurs. Z80 RST0_xxh Functions / GBA Functions 02xxh RST0_00h FadeIn, A speed, number of frames (0..x)Z80 RST8_xxh Functions / GBA Functions 01xxh RST8_00h GBA: N/A - Z80: Exit ;[00C0h]=a ;(1=restart, 2=exit)GBA Functions 03xxh (none such in Z80 mode) RSTX_00h Wait8bit ;for 16bit: RST0_7Dh
vpk_decompress(src,dest) collected32bit=80000000h ;initially empty (endflag in bit31)read_bits(num) mov data=0read_tree(root_index) i=root_indexload_huffman_tree stacktop=spThe best values for the huffman trees that I've found are 6,9,12-bit displacements for method 0 (best for NES/Z80 code), and two less for method 1, ie. 4,7,10-bit (best for GBA code). And 2,4,10-bit for the length values. The smallest value in node 0, and the other values in node 10 and 11. Notes The decompression works similar to the GBA BIOS'es LZ77 decompression function, but without using fixed bit-widths of length=4bit and displacement=12bit, instead, the bit-widths are read from huffman trees (which can also define fixed bit-widths; if data is located directly in the root node). Unlike the GBA BIOS'es Huffman decompression function, the trees are starting with data entries, end are ending with the root entry. The above load function deciphers the data, and returns the root index. With the variable bit-widths, the VPK compression rate is quite good, only, it's a pity that the length/disp values are zero-based, eg. for 2bit and 4bit lengths, it'd be much better to assign 2bit as 2..5, and 4bit as 6..21. Non-VPK The e-Reader additionally supports an alternate decompression function, indicated by the absence of the "vpk0" ID, which supports compression of increasing byte-values, which isn't useful for program code. Bit15 of the VPK Size value seems to disable (de-)compression, the VPK Data field is then containing plain uncompressed data.
The Error Correction Information that is appended at the end of the Block Header & Data Fragments consists of standard Reed-Solomon codes, which are also used for CD/DVD disks, DSL modems, and digital DVB television signals. That info allows to locate and repair a number of invalid data bytes. Below code shows how to create and verify error-info (but not how to do the actual error correction). The dtalen,errlen values should be 18h,10h for the Block Header, and 40h,10h for Data Fragments; the latter settings might be possible to get changed to other values though? append_error_info(data,dtalen,errlen) reverse_byte_order(data,dtalen)verify_error_info(data,dtalen,errlen) reverse_byte_order(data,dtalen)make_rev(data,len) for i=0 to len-1, data[i]=rev[data[i]], next imake_pow(data,len) for i=0 to len-1, data[i]=pow[data[i]], next iinvert_error_bytes(data,len) for i=0 to len-1, data[i]=data[i] xor FFh, next izerofill_error_bytes(data,len) for i=0 to len-1, data[i]=00h, next ireverse_byte_order(data,len) for i=0 to (len-1)/2, x=data[i], data[i]=data[len-i], data[len-i]=x, next icreate_pow_and_rev_tables x=01h, pow[FFh]=00h, rev[00h]=FFhcreate_gg_table gg[0]=pow[78h]With above value of 78h, and errlen=10h, gg[00h..0Fh] will be always: 00h,4Bh,EBh,D5h,EFh,4Ch,71h,00h,F4h,00h,71h,4Ch,EFh,D5h,EBh,4BhSo using a hardcoded table should take up less memory than calculating it. Notes The actual error correction should be able to fix up to "errlen" errors at known locations (eg. data from blocks that haven't been scanned, or whose 5bit-to-4bit conversion had failed due to an invalid 5bit value), or up to "errlen/2" errors at unknown locations. The corrected data isn't guaranteed to be correct (even if it looks okay to the "verify" function), so the Data Header checksums should be checked, too. More Info For more info, I've found Reed-Solomon source code from Simon Rockliff, and an updated version from Robert Morelos-Zaragoza and Hari Thirumoorthy to be useful. For getting started with that source, some important relationships & differences are: pow = alpha_to, but generated as shown aboveAnd, the ereader processes data/errinfo backwards, starting at the last byte.
.BMP Files (homebrew 300 DPI strips) Contains a picture of the whole dotcode strip with address bars and sync marks (see Dotcode chapter) in Microsoft's Bitmap format. The image is conventionally surrounded by a blank 2-pixel border, resulting in a size of 989x44 pixels for long strips. The file should should have 1bit color depth. The pixels per meter entry should match the desired printing resolution, either 300 DPI or 360 DPI. But, resolution of printer hardware is typically specified in inch rather than in meters, so an exact match isn't supported by Microsoft. Most homebrew .BMP files contain nonsense resolutions like 200 DPI, or 300 dots per meter (ca. 8 DPI). .JPG Files (scanned 1200 DPI strips) Same as BMP, but should contain a dotcode scanned at 1200 DPI, with correct orientation (the card-edge side at the bottom of the image), and containing only the dotcode (not the whole card), so the JPG size should be about 3450x155 pixels for long strips. No$gba currently doesn't work with progressive JPGs. Scans with white background can be saved as monochrome JPG. Scans with red/yellow background should contain a correct RED layer (due to the red LED light source) (the brightness of the green/blue layers can be set to zero for better compression). .RAW Files Contains the "raw" information from the BMP format, that is, 2-byte block header, 102-byte data, 2-byte block header, 102-byte data, etc. The data portion is interleaved, and includes the full 48-byte data header, titles, vpk compressed data, error-info, and unused bytes. RAW files are excluding Address Bars, Sync Marks, and 4bit-to-5bit encoding. Each RAW file contains one or more strip(s), so the RAW filesize is either 18*104 bytes (short strip), or 28*104 bytes (long strip), or a multiple thereof (if it contains more than one strip) (although multi-strip games are often stored in separate files for each strip; named file1.raw, file2.raw, etc). .BIN Files Filesize should be I*30h, with I=1Ch for short strips, and I=2Ch for long strips, or a multiple thereof (if it contains more than one strip). Each strip consists of the 48-byte Data Header, followed by title(s), and vpk compressed data. Unlike .RAW files, .BIN files aren't interleaved, and do not contain Block Headers, nor error-info, nor unused bytes (in last block). The files do contain padding bytes to match a full strip-size of I*30h. Caution: Older .BIN files have been using a size-reduced 12-byte header (taken from entries 0Dh, 0Ch, 10h-11h, 26h-2Dh of the 48-byte Data Header; in that order), that files have never contained more than one strip per file, so the filesize should be exactly I*30h-36, the size-reduced header doesn't contain a Primary Type entry, so it's everyone's bet which Card Type is to be used (hint: the 12-byte headers were based on the assumption that Primary Type would be always 01h on Short Strips, and 02h on Long Strips). .SAV Files Contains a copy of the e-Reader's 128Kbyte FLASH memory. With the saved e-Reader application being located in the 2nd 64K-bank, the data consists of a header with title and gba/nes/z80 format info, followed by the vpk compressed data. The FLASH memory does also contain e-Reader calibration settings, the remaining 100Kbytes are typically FFh-filled.
GBA Infra-Red Port (AGB-006) No info? GBA Wireless Adapter (AGB-015 or OXY-004) No info?
Flashcards are re-writable cartridges using FLASH memory, allowing to test even multiboot-incompatible GBA software on real hardware, providing a good development environment when used in combination with a reasonable software debugger. The carts can be written to from external tools, or directly from GBA programs. Below are pseudo code flowcharts for detect, erase, and write operations. All flash reads/writes are meant to be 16bit (ldrh/strh) memory accesses. detect_flashcard: configure_flashcard(9E2468Ah,9413h) ;unlock flash advance cardsflashcard_erase(dest,len): FOR x=1 to len/erase_block_sizeflashcard_write(src,dest,len): siz=write_block_sizesend_command(adr,val): [adr]=valenter_read_mode: send_command(8000000h,FFh) ;exit status modeflashcard_wait_busy: start=timeconfigure_flashcard(adr,val): ;required for Flash Advance cards only [930ECA8h]=5354hinit_backup: ;no info how to use that exactly configure_flashcard(942468Ah,???)device_list: (id code, total/erase/write sizes in bytes) ID Code Total Erase Write NameNotes All flashcards should work at 4,2 waitstates (power on default), most commercial games change waits to 3,1 which may work unstable with some/older FA flashcards. Intel FLASH specified to have a lifetime of 100,000 erases, and average block erase time 1 second (up to 5 second in worst cases). Aside from the main FLASH memory, Flash Advance (FA) (aka Visoly) cards additionally contain battery buffered SRAM backup, and FLASH backup, and in some cases also EEPROM backup. Turbo FA cards are containing two chips interlaced (at odd/even halfword addresses), allowing to write/erase both chips simultaneously, resulting in twice as fast programming time. Standard Nintendo flash carts have to be modified before you can actually write to them. This is done by removing resistor R7 and putting it at empty location R8. Mind that write/erase/detect modes output status information in ROM area, so that in that modes all GBA program code (and any interrupt handlers) must be executed in WRAM, not in ROM. Thanks to Jeff Frohwein for his FAQ and CARTLIB sample in FLGBA at devrs.com
Codebreaker (US) aka Xploder (EUR). Gameshark (US) aka Action Replay (EUR). GBA Cheat Codes - General Info GBA Cheat Codes - Codebreaker/Xploder GBA Cheat Codes - Gameshark/Action Replay V1/V2 GBA Cheat Codes - Pro Action Replay V3
Cheat devices are external adapters, connected between the GBA and the game cartridge. The devices include a BIOS ROM which is, among others, used to prompt the user to enter cheat codes. These codes are used to patch specified memory locations for a certain GBA game, allowing the user to gain goodies such like Infinite sex, 255 Cigarettes, etc. ROM and RAM Patches For ROM Patches, the device watches the address bus, if it matches a specified address then it outputs a patched value to the data bus, that mechanism is implemented by hardware, aside from the Hook Enable Code some devices also allow a limited number of cheats to use ROM patches. Most cheat codes are RAM patches, each time when the hook procedure is executed it will process all codes and overwrite the specified addresses in RAM (or VRAM or I/O area) by the desired values. Enable Codes (Must Be On) Enable codes usually consist of the Game ID, Hook Address, and eventually a third code used to encrypt all following codes. The Game ID is used to confirm that the correct cartridge is inserted, just a verification, though the device may insist on the ID code. The Hook Address specifies an address in cartridge ROM, and should point to an opcode which is executed several times per second (eg. once per frame, many codes place the hook in the joypad handler). At the hook address, the device redirects to its own BIOS, processes the RAM patches, and does then return control to the game cartridge. Note: The hook address should not point to opcodes with relative addressing (eg. B, BL, LDR Rd,=Imm, ADD Rd,=Imm opcodes - which are all relative to PC program counter register). Alignment Addresses for 16bit or 32bit values should be properly aligned.
Codebreaker Codes 0000xxxx 000y Enable Code 1 - Game IDCodebreaker Enable Codes Hook Address 'aaaaaaa' is a 25bit offset in ROM-image (0-1FFFFFFh). Flag byte 'y' (usually 0Ah), Bit1=Disable IRQs, Bit3=CRC Exists. Code Handler Store Address 'z' (0-7, usually 7) (8000100h+z*400000h). Checksum 'xxxx' for first 64Kbytes of cartridge (no$gba pads by FFh if ROM is smaller than 64K). Calculated, by using unsigned 16bit values, as such: crc=FFFFhCodebreaker Encryption codebreaker_change_encryption: Encryption can be (optionally) activated by code "9xyyxxxx xxxx", for i=0 to 2Fh, swaplist[i]=i, next iThe above random function works like so: randomizer=randomizer*41C64E6Dh+3039h, x=(randomizer SHL 14 AND C0000000h)Once when encryption is activated, all following codes are decrypted like so: for i=2Fh to 0The above xlatlist is fixed: xlatlist[0..5] = 3,2,1,0,5,4
Gameshark RAW Codes (These codes must be encrypted before using them) 0aaaaaaa 000000xx [aaaaaaa]=xxEnable Code - Hook Routine Hook Address 'aaaaaaa' is a 28bit ROM address (8FFFFFFh-9FFFFFFh). Used to insert the GS code handler routine where it will be executed at least 20 times per second. Without this code, GSA can not write to RAM. y=1 - Executes code handler without backing up the LR register.ROM Patch This type allows GSA to intercept ROM reads and returns the value xxxx. y=0 wait for the code handler to enable the patchNote: V1/V2 hardware can only have up to 1 user-defined rom patch max. V3 can have up to 4. Some enable code types can shorten the amount of user-defined rom patches available. Gameshark Encryption A=Left half, and V=Right half of code. FOR I=1 TO 32Upon startup, the initial encryption seeds are: S0=09F4FBBDh S1=9681884Ah S2=352027E9h S3=F3DEE5A7hUpon DEADFACE 0000xxyy, the S0..S3 seeds are changed like so: FOR y=0 TO 3All calculations truncated to unsigned 32bit integer values. T1 and T2 are translation tables contained in the gameshark cartridge.
Pro Action Replay V3 - RAW Codes C4aaaaaa 0000yyyy Enable Code - Hook Routine at [8aaaaaa] 00000000 80aaaaaa 000000yy ssccssss repeat cc times [a0aaaaa]=yy 00000000 82aaaaaa 0000yyyy ssccssss repeat cc times [a0aaaaa]=yyyy 00000000 84aaaaaa yyyyyyyy ssccssss repeat cc times [a0aaaaa]=yyyyyyyyWarning: There is a bug on the real AR (v2 upgraded to v3, and maybe on real v3) with the 32bit Increment Slide code. You HAVE to add a code (best choice is 80000000 00000000 : add 0 to value at address 0) right after it, else the AR will erase the 2 last 8 digits lines of the 32 Bits Inc. Slide code when you enter it !!! Final Notes The 'turn off all codes' makes an infinite loop (that can't be broken, unless the condition becomes True). - How? By Interrupt? Huh? ROM Patch1 works on real V3 and, on V1/V2 upgraded to V3. ROM Patch2,3,4 work on real V3 hardware only. Pro Action Replay V3 Conditional Codes - iiaaaaaa yyyyyyyy The 'ii' is composed of <cond> + <value> + <action>. <cond> <value> <action>For example, ii=18h+02h+40h=5Ah, produces IF [a0aaaaa]<zzzz THEN next 2 codes. Always... Codes For the "Always..." codes:Code Format (ttaaaaaa xxxxyyzz) adr mask = 003FFFFFPro Action Replay V3 Encryption Works exactly as for Gameshark Encryption, but with different initial seeds, S0=7AA9648Fh S1=7FAE6994h S2=C0EFAAD5h S3=42712C57hAnd, the T1 and T2 translation tables are different, too.
The Gameboy Player is an "adapter" for the Gamecube console. It's basicly is a GBA in a black box without LCD screen and without buttons, connected to an expansion port at the bottom of the Gamecube. The Gamecube is then capturing the GBA video output (and passing it to the television set), and in the other direction, passing the Gamecube joypad input to the GBA inputs. Unlocking and Detecting Gameboy Player Functions Both unlocking and detection requires to display the 240x160 pixel Gameboy Player logo (44 colors) for a number of frames... maybe at least 3-4 frames? not sure if it checks the color of the logo... so maybe it can be hidden by using dark gray on black background? While displaying this logo, the joypad data will switch between values 03FFh (2 frames duration) and 030Fh (1 frame duration). The latter value (left, right, up, down all pressed) indicates that it's a Gameboy Player. Palette Knowing Nintendo, they've probably not reproduced the blurred GBA colors (?), so the games won't look as desired on the TV screen. Unless the game does detect the Gameboy Player, and adjust the colors accordingly by software. Rumble The only known existing special function is the joypad rumble function, still, it's unknown HOW it works exactly - it's somehow (?) controlled by sending data through the serial port (the normal GBA port, even though it also has the connectors). Note If it's having a similar range of functions as the 8bit Super Gameboy, then the Gameboy Player might be also able to access analogue joypad input, and to access other features of the Gamecube hardware, up to possibly executing code on the Gamecube CPU...?
The GBA BIOS includes several System Call Functions which can be accessed by SWI instructions. Incoming parameters are usually passed through registers R0,R1,R2,R3. Outgoing registers R0,R1,R3 are typically containing either garbage, or return value(s). All other registers (R2,R4-R14) are kept unchanged. Caution When invoking SWIs from inside of ARM state specify SWI NN*10000h, instead of SWI NN as in THUMB state. Overview BIOS Function Summary BIOS Differences between GBA and NDS functions All Functions Described BIOS Arithmetic Functions BIOS Rotation/Scaling Functions BIOS Decompression Functions BIOS Memory Copy BIOS Halt Functions BIOS Reset Functions BIOS Misc Functions BIOS Multi Boot (Single Game Pak) BIOS Sound Functions How BIOS Processes SWIs SWIs can be called from both within THUMB and ARM mode. In ARM mode, only the upper 8bit of the 24bit comment field are interpreted. Each time when calling a BIOS function 4 words (SPSR, R11, R12, R14) are saved on Supervisor stack (_svc). Once it has saved that data, the SWI handler switches into System mode, so that all further stack operations are using user stack. In some cases the BIOS may allow interrupts to be executed from inside of the SWI procedure. If so, and if the interrupt handler calls further SWIs, then care should be taken that the Supervisor Stack does not overflow.
GBA NDS7 NDS9 Function 00h 00h 00h SoftReset 01h - - RegisterRamReset 02h 06h 06h Halt 03h 07h - Stop/Sleep 04h 04h 04h IntrWait 05h 05h 05h VBlankIntrWait 06h 09h 09h Div 07h - - DivArm 08h 0Dh 0Dh Sqrt 09h - - ArcTan 0Ah - - ArcTan2 0Bh 0Bh 0Bh CpuSet 0Ch 0Ch 0Ch CpuFastSet 0Dh - - GetBiosChecksum 0Eh - - BgAffineSet 0Fh - - ObjAffineSet 10h 10h 10h BitUnPack 11h 11h 11h LZ77UnCompWram 12h 12h 12h LZ77UnCompVram 13h 13h 13h HuffUnComp 14h 14h 14h RLUnCompWram 15h 15h 15h RLUnCompVram 16h - 16h Diff8bitUnFilterWram 17h - - Diff8bitUnFilterVram 18h - 18h Diff16bitUnFilter 19h 08h - SoundBias 1Ah - - SoundDriverInit 1Bh - - SoundDriverMode 1Ch - - SoundDriverMain 1Dh - - SoundDriverVSync 1Eh - - SoundChannelClear 1Fh - - MidiKey2Freq 20h - - SoundWhatever0 21h - - SoundWhatever1 22h - - SoundWhatever2 23h - - SoundWhatever3 24h - - SoundWhatever4 25h - - MultiBoot 26h - - HardReset 27h 1Fh - CustomHalt 28h - - SoundDriverVSyncOff 29h - - SoundDriverVSyncOn 2Ah - - SoundGetJumpList - 03h 03h WaitByLoop - 0Eh 0Eh GetCRC16 - 0Fh 0Fh IsDebugger - 1Ah - GetSineTable - 1Bh - GetPitchTable - 1Ch - GetVolumeTable - 1Dh - GetBootProcs - - 1Fh CustomPostThe BIOS SWI handler does not perform any range checks, so calling GBA SWI 2Bh-FFh or NDS SWI 20h-FFh will blindly jump to garbage addresses. Also, NDS7 SWI 01h, 02h, 0Ah, 16h-19h, 1Eh, and NDS9 SWI 01h, 02h, 07h, 08h, 0Ah, 17h, 19h-1Eh will jump to zero (ie. to the NDS7 reset vector, or to NDS9 unused (usually PU-locked ITCM) memory, which will be both redirected to the debug handler, if any).
Differences between GBA and NDS BIOS functions - SoftReset uses different addresses - SWI numbers for Halt, Stop/Sleep, Div, Sqrt have changed - Halt destroys r0 on NDS9, IntrWait bugged on NDS9 - CpuFastSet allows 4-byte blocks (nice), but... - CpuFastSet works very SLOW because of a programming bug (uncool) - LZ77UnCompVram, HuffUnComp, RLUnCompVram use callbacks - SoundBias uses new delay parameter And, a number of GBA functions have been removed, and some new NDS functions have been added, see: BIOS Function Summary
Div DivArm Sqrt ArcTan ArcTan2 SWI 06h (GBA) or SWI 09h (NDS7/NDS9) - Div Signed Division, r0/r1. r0 signed 32bit NumberReturn: r0 Number DIV Denom ;signedFor example, incoming -1234, 10 should return -123, -4, +123. The function usually gets caught in an endless loop upon division by zero. Note: The NDS9 additionally supports hardware division, by math coprocessor, accessed via I/O Ports, however, the SWI function is a raw software division. SWI 07h (GBA) - DivArm Same as above (SWI 06h Div), but incoming parameters are exchanged, r1/r0 (r0=Denom, r1=number). For compatibility with ARM's library. Slightly slower (3 clock cycles) than SWI 06h. SWI 08h (GBA) or SWI 0Dh (NDS7/NDS9) - Sqrt Calculate square root. r0 unsigned 32bit numberReturn: r0 unsigned 16bit numberThe result is an integer value, so Sqrt(2) would return 1, to avoid this inaccuracy, shift left incoming number by 2*N as much as possible (the result is then shifted left by 1*N). Ie. Sqrt(2 shl 30) would return 1.41421 shl 15. Note: The NDS9 additionally supports hardware square root calculation, by math coprocessor, accessed via I/O Ports, however, the SWI function is a raw software calculation. SWI 09h (GBA) - ArcTan Calculates the arc tangent. r0 Tan, 16bit (1bit sign, 1bit integral part, 14bit decimal part)Return: r0 "-PI/2<THETA/<PI/2" in a range of C000h-4000h.Note: there is a problem in accuracy with "THETA<-PI/4, PI/4<THETA". SWI 0Ah (GBA) - ArcTan2 Calculates the arc tangent after correction processing. Use this in normal situations. r0 X, 16bit (1bit sign, 1bit integral part, 14bit decimal part)Return: r0 0000h-FFFFh for 0<=THETA<2PI.
BgAffineSet ObjAffineSet SWI 0Eh (GBA) - BgAffineSet Used to calculate BG Rotation/Scaling parameters. r0 Pointer to Source Data Field with entries as follows:Return: No return value, Data written to destination address. SWI 0Fh (GBA) - ObjAffineSet Calculates and sets the OBJ's affine parameters from the scaling ratio and angle of rotation. The affine parameters are calculated from the parameters set in Srcp. The four affine parameters are set every Offset bytes, starting from the Destp address. If the Offset value is 2, the parameters are stored contiguously. If the value is 8, they match the structure of OAM. When Srcp is arrayed, the calculation can be performed continuously by specifying Num. r0 Source Address, pointing to data structure as such:Return: No return value, Data written to destination address. For both Bg- and ObjAffineSet, Rotation angles are specified as 0-FFFFh (covering a range of 360 degrees), however, the GBA BIOS recurses only the upper 8bit; the lower 8bit may contain a fractional portion, but it is ignored by the BIOS.
BitUnPack Diff8bitUnFilterWram Diff8bitUnFilterVram Diff16bitUnFilter HuffUnComp LZ77UnCompWram LZ77UnCompVram RLUnCompVram RLUnCompWram SWI 10h (GBA/NDS7/NDS9) - BitUnPack Used to increase the color depth of bitmaps or tile data. For example, to convert a 1bit monochrome font into 4bit or 8bit GBA tiles. The Unpack Info is specified separately, allowing to convert the same source data into different formats. r0 Source Address (no alignment required)Data is written in 32bit units, Destination can be Wram or Vram. The size of unpacked data must be a multiple of 4 bytes. The width of source units (plus the offset) should not exceed the destination width. Return: No return value, Data written to destination address. SWI 16h (GBA/NDS9) - Diff8bitUnFilterWram SWI 17h (GBA) - Diff8bitUnFilterVram SWI 18h (GBA/NDS9) - Diff16bitUnFilter These aren't actually real decompression functions, destination data will have exactly the same size as source data. However, assume a bitmap or wave form to contain a stream of increasing numbers such like 10..19, the filtered/unfiltered data would be: unfiltered: 10 11 12 13 14 15 16 17 18 19In this case using filtered data (combined with actual compression algorithms) will obviously produce better compression results. Data units may be either 8bit or 16bit used with Diff8bit or Diff16bit functions respectively. The 8bitVram function allows to write to VRAM directly (which uses 16bit data bus) by writing two 8bit values at once, the downside is that it is eventually slower as the 8bitWram function. r0 Source address (must be aligned by 4) pointing to data as follows:Return: No return value, Data written to destination address. SWI 13h (GBA/NDS7/NDS9) - HuffUnComp (NDS: with Callback) The decoder starts in root node, the separate bits in the bitstream specify if the next node is node0 or node1, if that node is a data node, then the data is stored in memory, and the decoder is reset to the root node. The most often used data should be as close to the root node as possible. For example, the 4-byte string "Huff" could be compressed to 6 bits: 10-11-0-0, with root.0 pointing directly to data "f", and root.1 pointing to a child node, whose nodes point to data "H" and data "u". Data is written in units of 32bits, if the size of the compressed data is not a multiple of 4, please adjust it as much as possible by padding with 0. Align the source address to a 4Byte boundary. r0 Source Address, aligned by 4, pointing to:Return: No return value, Data written to destination address. lea ebx,[esi+1] ;\@@data_lop: mov dword ptr [@@data],0@@lop: mov al,byte ptr ds:[ebx] ;\@@collect_back: ;/ jnc short @@node0 ;\@@node0: ;/ add ch,ch ;bit7 to cy ;\check if next node is data;XXX AND AL,MASK(bitwidth) ; or byte ptr [@@data],al ;@@done: ret;--- @@collect_bits: ;in: cy=1 (stop-bit) lodsd ;cy=same (!);--- SWI 11h (GBA/NDS7/NDS9) - LZ77UnCompWram SWI 12h (GBA/NDS7/NDS9) - LZ77UnCompVram (NDS: with Callback) Expands LZ77-compressed data. The Wram function is faster, and writes in units of 8bits. For the Vram function the destination must be halfword aligned, data is written in units of 16bits. If the size of the compressed data is not a multiple of 4, please adjust it as much as possible by padding with 0. Align the source address to a 4-Byte boundary. r0 Source address, pointing to data as such:Return: No return value. SWI 14h (GBA/NDS7/NDS9) - RLUnCompWram SWI 15h (GBA/NDS7/NDS9) - RLUnCompVram (NDS: with Callback) Expands run-length compressed data. The Wram function is faster, and writes in units of 8bits. For the Vram function the destination must be halfword aligned, data is written in units of 16bits. If the size of the compressed data is not a multiple of 4, please adjust it as much as possible by padding with 0. Align the source address to a 4Byte boundary. r0 Source Address, pointing to data as such:Return: No return value, Data written to destination address. NDS Decompression Callbacks On NDS7/NDS9, the SWI 12h, 13h, 15h functions are reading source data from callback functions (rather than directly from memory). The callback functions may read normal data from memory, or from other devices, such like directly from the gamepak bus, without storing the source data in memory. The downside is that the callback mechanism makes the function very slow, furthermore, NDS7/NDS9 SWI 12h, 13h, 15h are using THUMB code, and variables on stack, alltogether that makes the whole shit very-very-very slow. r2 = user defined callback parameter (passed on to Open function)Callback structure (five 32bit pointers to callback functions) Open_and_get_32bit (eg. LDR r0,[r0], get header)All functions may use ARM or THUMB code (indicated by address bit0). The current source address (r0) is passed to all callback functions. Additionally, the initial destination address (r1), and a user defined parameter (r2) are passed to the Open function. All functions have return values in r0. The Open function normally returns the first word (containing positive length and type), alternatively it may return a negative error code to abort/reject decompression. The Close function, if it is defined, should return zero (or any positive value), or a negative errorcode. The other functions return raw data, without errorcodes. The SWI returns the length of decompressed data, or the signed errorcode from the Open/Close functions.
CpuFastSet CpuSet SWI 0Ch (GBA/NDS7/NDS9) - CpuFastSet Memory copy/fill in units of 32 bytes. Memcopy is implemented as repeated LDMIA/STMIA [Rb]!,r2-r9 instructions. Memfill as single LDR followed by repeated STMIA [Rb]!,r2-r9. After processing all 32-byte-blocks, the NDS additonally processes the remaining words as 4-byte blocks. BUG: The NDS uses the fast 32-byte-block processing only for the first N bytes (not for the first N words), so only the first quarter of the memory block is FAST, the remaining three quarters are SLOWLY copied word-by-word. The length is specifed as wordcount, ie. the number of bytes divided by 4. On the GBA, the length must be a multiple of 8 words (32 bytes). On NDS, the length may be any number of words (4 bytes). r0 Source address (must be aligned by 4)Return: No return value, Data written to destination address. SWI 0Bh (GBA/NDS7/NDS9) - CpuSet Memory copy/fill in units of 4 bytes or 2 bytes. Memcopy is implemented as repeated LDMIA/STMIA [Rb]!,r3 or LDRH/STRH r3,[r0,r5] instructions. Memfill as single LDMIA or LDRH followed by repeated STMIA [Rb]!,r3 or STRH r3,[r0,r5]. The length must be a multiple of 4 bytes (32bit mode) or 2 bytes (16bit mode). The (half)wordcount in r2 must be length/4 (32bit mode) or length/2 (16bit mode), ie. length in word/halfword units rather than byte units. r0 Source address (must be aligned by 4 for 32bit, by 2 for 16bit)Return: No return value, Data written to destination address. Note: On GBA and NDS7, these two functions will silently reject to do anything if the source start or end addresses are reaching into the BIOS area. The NDS9 doesn't have such read-proctection.
Halt IntrWait VBlankIntrWait Stop/Sleep CustomHalt SWI 02h (GBA) or SWI 06h (NDS7/NDS9) - Halt Halts the CPU until an interrupt request occurs. The CPU is switched into low-power mode, all other circuits (video, sound, timers, serial, keypad, system clock) are kept operating. Halt mode is terminated when any enabled interrupts are requested, that is when (IE AND IF) is not zero, the GBA locks up if that condition doesn't get true. However, the state of CPUs IRQ disable bit in CPSR register, and the IME register are don't care, Halt passes through even if either one has disabled interrupts. On GBA and NDS7, Halt is implemented by writing to HALTCNT, Port 4000301h. On NDS9, Halt is implemted by writing to System Control Coprocessor (mov p15,0,c7,c0,4,r0 opcode), this opcode hangs if IME=0. No parameters, no return value. (GBA/NDS7: all registers unchanged, NDS9: R0 destroyed) SWI 04h (GBA/NDS7/NDS9) - IntrWait Continues to wait in Halt state until one (or more) of the specified interrupt(s) do occur. The function forcefully sets IME=1. When using multiple interrupts at the same time, this function is having less overhead than repeatedly calling the Halt function. r0 0=Return immediately if an old flag was already set (NDS9: bugged!)Caution: When using IntrWait or VBlankIntrWait, the user interrupt handler MUST update the BIOS Interrupt Flags value in RAM; when acknowleding processed interrupt(s) by writing a value to the IF register, the same value should be also ORed to the BIOS Interrupt Flags value, at following memory location: Host GBA (16bit) NDS7 (32bit) NDS9 (32bit)NDS9: BUG: No Discard (r0=0) doesn't work. The function always waits for at least one IRQ to occur (no matter which, including IRQs that are not selected in r1), even if the desired flag was already set. NB. the same bug is also found in the GBA/NDS7 functions, but it's compensated by a second bug, ie. the GBA/NDS7 functions are working okay because their "bug doesn't work". Return: No return value, the selected flag(s) are automatically reset in BIOS Interrupt Flags value in RAM upon return. SWI 05h (GBA/NDS7/NDS9) - VBlankIntrWait Continues to wait in Halt status until a new V-Blank interrupt occurs. The function sets r0=1 and r1=1 and then executes IntrWait (SWI 04h), see IntrWait for details. No parameters, no return value. SWI 03h (GBA) - Stop Switches the GBA into very low power mode (to be used similar as a screen-saver). The CPU, System Clock, Sound, Video, SIO-Shift Clock, DMAs, and Timers are stopped. Stop state can be terminated by the following interrupts only (as far as enabled in IE register): Joypad, Game Pak, or General-Purpose-SIO. "The system clock is stopped so the IF flag is not set." Preparation for Stop: Disable Video before implementing Stop (otherwise Video just freezes, but still keeps consuming battery power). Possibly required to disable Sound also? Obviously, it'd be also recommended to disable any external hardware (such like Rumble or Infra-Red) as far as possible. No parameters, no return value. SWI 07h (NDS7) - Sleep No info, probably similar as GBA SWI 03h (Stop). Sleep is implemented for NDS7 only, not for NDS9, not sure if the functions stops BOTH NDS7 and NDS9? SWI 27h (GBA) or SWI 1Fh (NDS7) - CustomHalt (Undocumented) Writes the 8bit parameter value to HALTCNT, below values are equivalent to Halt and Stop/Sleep functions, other values reserved, purpose unknown. r2 8bit parameter (GBA: 00h=Halt, 80h=Stop) (NDS7: 80h=Halt, C0h=Sleep)No return value.
SoftReset RegisterRamReset HardReset SWI 00h - SoftReset Clears 200h bytes of RAM (containing stacks, and BIOS IRQ vector/flags), initializes system, supervisor, and irq stack pointers, sets R0-R12, LR_svc, SPSR_svc, LR_irq, and SPSR_irq to zero, and enters system mode. Note that the NDS9 stack registers are hardcoded (the DTCM base should be set to the default setting of 0800000h). The NDS9 function additionally flushes caches and write buffer, and sets the CP15 control register to 12078h. Host sp_svc sp_irq sp_sys zerofilled area return addressThe NDS7/NDS9 return addresses at [27FFE34h/27FFE24h] are usually containing copies of Cartridge Header [034h/024h] entry points, which may select ARM/THUMB state via bit0. The GBA return address 8bit flag is interpreted as 00h=8000000h (ROM), or 01h-FFh=2000000h (RAM), entered in ARM state. Note: The reset is applied only to the CPU that has executed the SWI (ie. on the NDS, the other CPU will remain unaffected). Return: Does not return to calling procedure, instead, loads the above return address into R14, and then jumps to that address by a "BX R14" opcode. SWI 01h (GBA) - RegisterRamReset Resets the I/O registers and RAM specified in ResetFlags. However, it does not clear the CPU internal RAM area from 3007E00h-3007FFFh. r0 ResetFlagsReturn: No return value. Bug: LSBs of SIODATA32 are always destroyed, even if Bit5 of R0 was cleared. The function always switches the screen into forced blank by setting DISPCNT=0080h (regardless of incoming R0, screen becomes white). SWI 26h (GBA) - HardReset (Undocumented) This function reboots the GBA (including for getting through the time-consuming nintendo intro, which is making the function particularly useless and annoying). Parameters: None. Return: Never/Reboot. Execution Time: About 2 seconds (!)
GetBiosChecksum WaitByLoop GetCRC16 IsDebugger GetSineTable GetPitchTable GetVolumeTable CustomPost GetBootProcs SWI 0Dh (GBA) - GetBiosChecksum (Undocumented) Calculates the checksum of the BIOS ROM (by reading in 32bit units, and adding up these values). IRQ and FIQ are disabled during execution. The checksum is BAAE187Fh (GBA and GBA SP), or BAAE1880h (DS in GBA mode, whereas the only difference is that the byte at [3F0Ch] is changed from 00h to 01h, otherwise the BIOS is 1:1 same as GBA BIOS, it does even include multiboot code). Parameters: None. Return: r0=Checksum. SWI 03h (NDS7/NDS9) - WaitByLoop Performs a "LOP: SUB R0,1 / BGT LOP" wait loop, the loop is executed in BIOS memory, which provides reliable timings (regardless of the memory waitstates & cache state of the calling procedure). Intended only for short delays (eg. flash memory programming cycles). r0 Delay value (should be in range 1..7FFFFFFFh)Execution Time: NDS7: R0*4 cycles, plus some overload on SWI handling. Execution Time: NDS9: R0*2 (cache on), or R0*8 (cache off), plus overload. Note: Both NDS7 and NDS9 timings are counted in 33.51MHz units. Return: No return value. SWI 0Eh (NDS7/NDS9) - GetCRC16 r0 Initial CRC value (16bit, usually FFFFh)CRC16 checksums can be calculated as such: val[0..7] = C0C1h,C181h,C301h,C601h,CC01h,D801h,F001h,A001hReturn: r0 Calculated 16bit CRC ValueAdditionally, if the length is nonzero, r3 contains the last processed halfword at [addr+len-2]. Unlike most other NDS7 SWI functions which reject to read from BIOS memory, this allows to dump the NDS7 BIOS (except for the memory region that is locked via BIOSPROT Port 4000308h). SWI 0Fh (NDS7/NDS9) - IsDebugger Detects if 4MB (normal) or 8MB (debug version) Main RAM installed. Return: r0 = result (0=normal console 4MB, 1=debug version 8MB) Destroys halfword at [27FFFFAh] (NDS7) or [27FFFF8h] (NDS9)! The SWI 0Fh function doesn't work stable if it gets interrupted by an interrupt which is calling SWI 0Fh, which would destroy the above halfword scratch value (unless the IRQ handler has saved/restored the halfword). SWI 1Ah (NDS7) - GetSineTable r0 Index (0..3Fh) (must be in that range, otherwise returns garbage)Return: r0 = Desired Entry (0000h..7FF5h) ;SIN(0 .. 88.6 degrees)*8000h SWI 1Bh (NDS7) - GetPitchTable r0 Index (0..2FFh) (must be in that range, otherwise returns garbage)Return: r0 = Desired Entry (0000h..FF8Ah) (unsigned) SWI 1Ch (NDS7) - GetVolumeTable r0 Index (0..2D3h) (must be in that range, otherwise returns garbage)Return: r0 = Desired Entry (00h..7Fh) (unsigned) SWI 1Fh (NDS9) - CustomPost Writes to the POSTFLG register, probably for use by Firmware boot procedure. r0 32bit value, to be written to POSTFLG, Port 4000300hReturn: No return value. SWI 1Dh (NDS7) - GetBootProcs Returns addresses of Gamecart boot procedure/interrupt handler, probably for use by Firmware boot procedure. The return values are somewhat XORed by each other. Most of the returned functions won't work if the POSTFLG register is set.
MultiBoot SWI 25h (GBA) - MultiBoot This function uploads & starts program code to slave GBAs, allowing to launch programs on slave units even if no cartridge is inserted into the slaves (this works because all GBA BIOSes contain built-in download procedures in ROM). However, the SWI 25h BIOS upload function covers only 45% of the required Transmission Protocol, the other 55% must be coded in the master cartridge (see Transmission Protocol below). r0 Pointer to MultiBootParam structureReturn: r0 0=okay, 1=failedSee below for more details. Multiboot Parameter Structure Size of parameter structure should be 4Ch bytes (the current GBA BIOS uses only first 44h bytes though). The following entries must be set before calling SWI 25h: Addr Size Name/Expl.The transfer length (excluding header data) should be a multiple of 10h, minimum length 100h, max 3FF40h (ca. 256KBytes). Set palette_data as "81h+color*10h+direction*8+speed*2", or as "0f1h+color*2" for fixed palette, whereas color=0..6, speed=0..3, direction=0..1. The other entries (handshake_data, client_data[1-3], and client_bit) must be same as specified in Transmission Protocol (see below hh,cc,y). Multiboot Transfer Protocol Below describes the complete transfer protocol, normally only the Initiation part must be programmed in the master cartridge, the main data transfer can be then performed by calling SWI 25h, the slave program is started after SWI 25h completion. The ending handshake is normally not required, when using it, note that you will need custom code in BOTH master and slave programs. Times Send Receive Expl.Legend for above Protocol y client_bit, bit(s) 1-3 set if slave(s) 1-3 detectedBelow automatically calculated by SWI 25h BIOS function (don't care about) llll download length/4-34hPseudo Code for SWI 25h Transfer with Checksum and Encryption calculations if normal_mode then c=C387h:x=C37Bh:k=43202F2FhWhereas, explained: c=chksum,x=chkxor,f=chkfin,k=keyxor,m=keymul Multiboot Communication In Multiplay mode, master sends 16bit data, and receives 16bit data from each slave (or FFFFh if none). In Normal mode, master sends 32bit data (upper 16bit zero, lower 16bit as for multipay mode), and receives 32bit data (upper 16bit as for multiplay mode, and lower 16bit same as lower 16bit previously sent by master). Because SIODATA32 occupies same addresses as SIOMULTI0-1, the same transfer code can be used for both multiplay and normal mode (in normal mode SIOMULTI2-3 should be forced to FFFFh though). After each transfer, master should wait for Start bit cleared in SIOCNT register, followed by a 36us delay. Note: The multiboot slave would also recognize data being sent in Joybus mode, however, master GBAs cannot use joybus mode (because GBA hardware cannot act as master in joybus mode). Multiboot Slave Header The transferred Header block is written to 2000000-20000BFh in slave RAM, the header must contain valid data (identically as for normal ROM-cartridge headers, including a copy of the Nintendo logo, correct header CRC, etc.), in most cases it'd be recommended just to transfer a copy of the master cartridges header from 8000000h-80000BFh. Multiboot Slave Program/Data The transferred main program/data block is written to 20000C0h and up (max 203FFFFh) in slave RAM, note that absolute addresses in the program must be then originated at 2000000h rather than 8000000h. In case that the master cartridge is 256K or less, it could just transfer a copy of the whole cartridge at 80000C0h and up, the master should then copy & execute its own ROM data into RAM as well. Multiboot Slave Extended Header For Multiboot slaves, separate Entry Point(s) must be defined at the beginning of the Program/Data block (the Entry Point in the normal header is ignored), also some reserved bytes in this section are overwritten by the Multiboot procedure. For more information see chapter about Cartridge Header. Multiboot Slave with Cartridge Beside for slaves without cartridge, multiboot can be also used for slaves which do have a cartridge inserted, if so, SELECT and START must be kept held down during power-on in order to switch the slave GBA into Multiboot mode (ie. to prevent it from starting the cartridge as normally). The general idea is to enable newer programs to link to any existing older GBA programs, even if these older programs originally didn't have been intended to support linking. The uploaded program may access the slaves SRAM, Flash ROM, or EEPROM (if any, allowing to read out or modify slave game positions), as well as cartridge ROM at 80000A0h-8000FFFh (the first 4KBytes, excluding the nintendo logo, allowing to read out the cartridge name from the header, for example). The main part of the cartridge ROM is meant to be locked out in order to prevent software pirates from uploading "intruder" programs which would send back a copy of the whole cartridge to the master, however, for good or evil, at present time, current GBA models and GBA carts do not seem to contain any such protection. Uploading Programs from PC Beside for the ability to upload a program from one GBA to another, this feature can be also used to upload small programs from a PC to a GBA. For more information see chapter about External Connectors. Nintendo DS The GBA multiboot function requires a link port, and so, works on GBA and GBA SP only. The Nintendo DS in GBA mode does include the multiboot BIOS function, but it won't be of any use as the DS doesn't have a link port.
MidiKey2Freq SoundBias SoundChannelClear SoundDriverInit SoundDriverMain SoundDriverMode SoundDriverVSync SoundDriverVSyncOff SoundDriverVSyncOn SoundWhatever0..4 SoundGetJumpList SWI 1Fh (GBA) - MidiKey2Freq Calculates the value of the assignment to ((SoundArea)sa).vchn[x].fr when playing the wave data, wa, with the interval (MIDI KEY) mk and the fine adjustment value (halftones=256) fp. r0 WaveData* waReturn: r0 u32This function is particularly popular because it allows to read from BIOS memory without copy protection range checks. The formula to read one byte (a) from address (i, 0..3FFF) is: a = (MidiKey2Freq(i-(((i AND 3)+1)OR 3), 168, 0) * 2) SHR 24 SWI 19h (GBA) or SWI 08h (NDS7) - SoundBias Increments or decrements the current level of the SOUNDBIAS register (with short delays) until reaching the desired new level. The upper bits of the register are kept unchanged. r0 BIAS level (0=Level 000h, any other value=Level 200h)Return: No return value. SWI 1Eh (GBA) - SoundChannelClear Clears all direct sound channels and stops the sound. This function may not operate properly when the library which expands the sound driver feature is combined afterwards. In this case, do not use it. No parameters, no return value. SWI 1Ah (GBA) - SoundDriverInit Initializes the sound driver. Call this only once when the game starts up. It is essential that the work area already be secured at the time this function is called. You cannot execute this driver multiple times, even if separate work areas have been prepared. r0 Pointer to work area for sound driver, SoundArea structure as follows:Return: No return value. SWI 1Ch (GBA) - SoundDriverMain Main of the sound driver. Call every 1/60 of a second. The flow of the process is to call SoundDriverVSync, which is explained later, immediately after the V-Blank interrupt. After that, this routine is called after BG and OBJ processing is executed. No parameters, no return value. SWI 1Bh (GBA) - SoundDriverMode Sets the sound driver operation mode. r0 Sound driver operation modeReturn: No return value. SWI 1Dh (GBA) - SoundDriverVSync An extremely short system call that resets the sound DMA. The timing is extremely critical, so call this function immediately after the V-Blank interrupt every 1/60 second. No parameters, no return value. SWI 28h (GBA) - SoundDriverVSyncOff Due to problems with the main program if the V-Blank interrupts are stopped, and SoundDriverVSync cannot be called every 1/60 a second, this function must be used to stop sound DMA. Otherwise, even if you exceed the limit of the buffer the DMA will not stop and noise will result. No parameters, no return value. SWI 29h (GBA) - SoundDriverVSyncOn This function restarts the sound DMA stopped with the previously described SoundDriverVSyncOff. After calling this function, have a V-Blank occur within 2/60 of a second and call SoundDriverVSync. No parameters, no return value. SWI 20h..24h (GBA) - SoundWhatever0..4 (Undocumented) Whatever undocumented sound-related BIOS functions. SWI 2Ah (GBA) - SoundGetJumpList (Undocumented) Receives pointers to 36 additional sound-related BIOS functions. r0 Destination address (must be aligned by 4) (120h bytes buffer)
Forward Most of the below is caused by 'traces' from previous operations which have used the databus. No promises that the results are stable on all current or future GBA models, and/or under all temperature and interference circumstances. Also, below specifies 32bit data accesses only. When reading units less than 32bit, data is rotated depending on the alignment of the originally specified address, and 8bit or 16bit are then isolated from the 32bit value as usually. Reading from BIOS Memory (00000000-00003FFF) The BIOS memory is protected against reading, the GBA allows to read opcodes or data only if the program counter is located inside of the BIOS area. If the program counter is not in the BIOS area, reading will return the most recent successfully fetched BIOS opcode (eg. the opcode at [00DCh+8] after startup and SoftReset, the opcode at [0134h+8] during IRQ execution, and opcode at [013Ch+8] after IRQ execution, and opcode at [0188h+8] after SWI execution). Reading from Unused Memory (00004000-1FFFFFF0,10000000-FFFFFFFF) Accessing unused memory returns the recently pre-fetched opcode, ie. the 32bit opcode at $+8 in ARM state, or the 16bit-opcode at $+4 in THUMB state, in the later case the 16bit opcode is mirrored across both upper/lower 16bits of the returned 32bit data. The same effect occurs on disabled WRAM (2000000h-3FFFFFFh), see Port 4000800h. Note: This is caused by the prefetch pipeline in the CPU itself, not by the external gamepak prefetch, ie. it works for code in RAM as well. Reading from Unused or Write-Only I/O Ports Works like above unused memory when the entire 32bit memory fragment is Unused (eg. 0E0h) and/or Write-Only (eg. DMA0SAD). And otherwise, returns zero if the lower 16bit fragment is readable (eg. 04C=MOSAIC, 04E=NOTUSED/ZERO). Reading from GamePak ROM when no Cartridge is inserted Because Gamepak uses the same signal-lines for both 16bit data and for lower 16bit halfword address, the entire gamepak ROM area is effectively filled by incrementing 16bit values (Address/2 AND FFFFh). Memory Mirrors Most internal memory is mirrored across the whole 24bit/16MB address space in which it is located: Slow On-board RAM at 2XXXXXX, Fast In-Chip RAM at 3XXXXXXh, Palette RAM at 5XXXXXXh, VRAM at 6XXXXXXh, and OAM at 7XXXXXXh. Even though VRAM is sized 96K (64K+32K), it is repeated in steps of 128K (64K+32K+32K, the two 32K blocks itself being mirrors of each other). BIOS ROM, Normal ROM Cartridges, and I/O area are NOT mirrored, the only exception is the undocumented I/O port at 4000800h (repeated each 64K). The 64K SRAM area is mirrored across the whole 32MB area at E000000h-FFFFFFFh, also, inside of the 64K SRAM field, 32K SRAM chips are repeated twice. Writing 8bit Data to Video Memory Video Memory (BG, OBJ, OAM, Palette) can be written to in 16bit and 32bit units only. Attempts to write 8bit data (by STRB opcode) won't work: Writes to OBJ (6010000h-6017FFFh) (or 6014000h-6017FFFh in Bitmap mode) and to OAM (7000000h-70003FFh) are ignored, the memory content remains unchanged. Writes to BG (6000000h-600FFFFh) (or 6000000h-6013FFFh in Bitmap mode) and to Palette (5000000h-50003FFh) are writing the new 8bit value to BOTH upper and lower 8bits of the addressed halfword, ie. "[addr AND NOT 1]=data*101h". Using Invalid Tile Numbers In Text mode, large tile numbers (combined with a non-zero character base setting in BGnCNT register) may exceed the available 64K of BG VRAM. On GBA and GBA SP, such invalid tiles are displayed as if the character data is filled by the 16bit BG Map entry value (ie. as vertically striped tiles). Above applies only if there is only one BG layer enable, with two or more layers, things are getting much more complicated: tile-data is then somehow derived from the other layers, depending on their priority order and scrolling offsets. On NDS (in GBA mode), such invalid tiles are displayed as if the character data is zero-filled (ie. as invisible/transparent tiles). Accessing SRAM Area by 16bit/32bit Reading retrieves 8bit value from specified address, multiplied by 0101h (LDRH) or by 01010101h (LDR). Writing changes the 8bit value at the specified address only, being set to LSB of (source_data ROR (address*8)).
External Connectors AUX GBA Game Pak Bus AUX DS Game Card Slot AUX Link Port AUX Sound/Headphone Socket and Battery/Power Supply Getting access to Internal Pins AUX Opening the GBA AUX Mainboard More Internal Stuff Pinouts - CPU - Signal Summary Pinouts - CPU - Pinouts Pinouts - Audio Amplifiers Pinouts - LCD Cables Pinouts - Power Switches, DC/DC Converters, Reset Generators Pinouts - Wifi Pinouts - Various Xboo Multiboot Cable AUX Xboo PC-to-GBA Multiboot Cable AUX Xboo Flashcard Upload AUX Xboo Burst Boot Backdoor DS Xboo
Game Pak Bus - 32pin cartridge slot The cartridge bus may be used for both CGB and GBA game paks. In GBA mode, it is used as follows: Pin Name Dir Expl.When accessing game pak SRAM, a 16bit address is output through AD0-AD15, then 8bit of data are transferred through A16-A23. When accessing game pak ROM, a 24bit address is output through AD0-AD15 and A16-A23, then 16bit of data are transferred through AD0-AD15. The 24bit address is formed from the actual 25bit memory address (byte-steps), divided by two (halfword-steps). 8bit-Gamepak-Switch (GBA, GBA SP only) (not DS) A small switch is located inside of the cartridge slot, the switch is pushed down when an 8bit cartridge is inserted, it is released when a GBA cartridge is inserted (or if no cartridge is inserted). The switch mechanically controls whether VDD3 or VDD5 are output at VDD35; ie. in GBA mode 3V power supply/signals are used for the cartridge slot and link port, while in 8bit mode 5V are used. The switch additionally drags IN35 to 3V when an 8bit cart is inserted, the current state of IN35 can be determined in GBA mode via Port 4000204h (WAITCNT), if the switch is pushed, then CGB mode can be activated via Port 4000000h (DISPCNT.3), this bit can be set ONLY by opcodes in BIOS region (eg. via CpuSet SWI function). In 8bit mode, the cartridge bus works much like for GBA SRAM, however, the 8bit /CS signal is expected at Pin 5, while GBA SRAM /CS2 at Pin 30 is interpreted as /RESET signal by the 8bit MBC chip (if any). In practice, this appears to result in 00h being received as data when attempting to read-out 8bit cartridges from inside of GBA mode.
Pin Dir Name Connection in cartridgeChipselect High-to-Low transitions are invoking commands, which are transmitted through data lines during next following eight CLK pulses, after the command transmission, further CLK pulses are used to transfer data, the data transfer ends at chipselect Low-to-High transition. Data should be stable during CLK=LOW period throughout CLK rising edge. Note: Supply Pins (1,8,17) are slightly longer than other pins. The DS does also have a 32pin cartridge slot, that slot is used to run GBA carts in GBA mode, it can be also used as expansion port in DS mode.
Serial Link Port Pin-Out (GBA:"EXT" - GBA SP:"EXT.1") Pin Name CableNote: The pin numbers and names are printed on the GBA mainboard, colors as used in Nintendo's AGB-005 and older 8bit cables. Cable Diagrams (Left: GBA Cable, Right: 8bit Gameboy Cable) Big Plug Middle Socket Small Plug Plug 1 Plug 2Normal Connection Just connect the plugs to the two GBAs and leave the Middle Socket disconnected, in this mode both GBAs may behave as master or slave, regardless of whether using big or small plugs. The GBA is (NOT ???) able to communicate in Normal mode with MultiPlay cables which do not have crossed SI/SO lines. Multi-Play Connection Connect two GBAs as normal, for each further GBAs connect an additional cable to the Middle socket of the first (or further) cable(s), up to four GBAs may be connected by using up to three cables. The GBA which is connected to a Small Plug is master, the slaves are all connected to Large Plugs. (Only small plugs fit into the Middle Socket, so it's not possible to mess up something here). Multi-Boot Connection MultiBoot (SingleGamepak) is typically using Multi-Play communication, in this case it is important that the Small plug is connected to the master/sender (ie. to the GBA that contains the cartridge). Non-GBA Mode Connection First of all, it is not possible to link between 32bit GBA games and 8bit games, parts because of different cable protocol, and parts because of different signal voltages. However, when a 8bit cartridge is inserted (the GBA is switched into 8bit compatibility mode) it may be connected to other 8bit games (monochrome gameboys, CGBs, or to other GBAs which are in 8bit mode also, but not to GBAs in 32bit mode). When using 8bit link mode, an 8bit link cable must be used. The GBA link cables won't work, see below modification though. Using a GBA 32bit cable for 8bit communication Open the middle socket, and disconnect Small Plugs SI from GND, and connect SI to Large Plugs SO instead. You may also want to install a switch that allows to switch between SO and GND, the GND signal should be required for MultiPlay communication only though. Also, cut off the plastic ledge from the plugs so that they fit into 8bit gameboy sockets. Using a GBA 8bit cable for 32bit communication The cable should theoretically work as is, as the grounded SI would be required for MultiPlay communication only. However, software that uses SD for Slave-Ready detection won't work unless when adding a SD-to-SD connection (the 8bit plugs probably do not even contain SD pins though).
GBA and NDS and NDS-Lite: Stereo Sound Connector (3.5mm, female) Tip Audio Left ___ ___ _____+-----------+The NDS socket doesn't fully match regular 3.5mm plugs, one needs to cut-off a portion of the DS case to be able to fully insert the plug, which still requires a lot of pressure, furthermore, when fully inserted, left/right become shortcut to mono, so one needs to pull-back the plug a bit to gain stereo output. GBA SP and NDS - Power/Headphone Socket (EXT.2) Pin SP NDS Expl.External power input is used to charge the built-in battery, it cannot be used to run the SP without that battery. NDS-Lite - Power Socket Pin Expl. __________External Power Supply GBA: DC 3.3V (no separate power socket, requires 2xAA-battery-shaped adapter) GBA-SP/NDS: DC 5.2V (or DC 5V) (special connector on power/headphone socket) NDS-Lite: DC 5.2V (or DC 5V) (another special connector on power socket) Internal Battery Supply GBA: 2xAA (3V) GBA-SP: Li-ion 3.7V, 600mAh (built-in, recharge-able) NDS: Li-ion 3.7V, 850mAh (built-in, recharge-able) NDS-Lite: Li-ion 3.7V, 1000mAh (built-in, recharge-able) Using PC +5V DC as Power Supply Developers whom are using a PC for GBA programming will probably want to use the PC power supply (gained from disk drive power supply cable) for the GBA as well rather than dealing with batteries or external power supplies. GBA: To lower the voltage to approximately 3 Volts use two diodes, type 1N 4004 or similar, the ring printed onto the diodes points towards the GBA side, connected as such: PC +5V (red) --------|>|---|>|-------- GBA BT+GBA SP and DS: Works directly at +5V connected to EXT.2 socket (not to the internal battery pins), without any diodes.
Since Nintendo uses special screws with Y-shaped heads to seal the GBA (as well as older 8bit gameboys), it's always a bit difficult to loosen these screws. Using Screwdrivers One possible method is to use a small flat screwdriver, which might work, even though it'll most likely damage the screwdriver. Reportedly, special Y-shaped screwdrivers for gameboys are available for sale somewhere (probably not at your local dealer, but you might find some in the internet or elsewhere). Destroying the Screws A more violent method is to take an electric drill, and drill-off the screw heads, this might also slightly damage the GBA plastic chase, also take care that the metal spoons from the destroyed screws don't produce shortcuts on the GBA mainboard. Using a selfmade Screwdriver A possible method is to take a larger screw (with a normal I-shaped, or X-shaped head), and to cut the screw-tip into Y-shape, you'll then end up with an "adapter" which can be placed in the middle between a normal screwdriver and gameboy screws. Preferably, first cut the screw-tip into a shape like a "sharp three sided pyramid", next cut notches into each side. Access to a grinding-machine will be a great benefit, but you might get it working by using a normal metal-file as well.
Other possibly useful signals on the mainboard... FIQ Signal The FIQ (Fast Interrupt) signal (labeled FIQ on the mainboard) could be used as external interrupt (or debugging break) signal. Caution: By default, the FIQ input is directly shortcut to VDD35 (+3V or +5V power supply voltage), this can be healed by scratching off the CL1 connection located close to the FIQ pin (FIQ still appears to have an internal pull-up, so that an external resistor is not required). The GBA BIOS rejects FIQs if using normal ROM cartridge headers (or when no cartridge is inserted). When using a FIQ-compatible ROM header, Fast Interrupts can be then requested by pulling FIQ to ground, either by a push button, or by remote controlled signals. RESET Signal The RESET signal (found on the mainboard) could be used to reset the GBA by pulling the signal to ground for a few microseconds (or longer). The signal can be directly used (it is not shortcut to VDD35, unlike FIQ). Note: A reset always launches Nintendo's time-consuming and annoying boot/logo procedure, so that it'd be recommend to avoid this "feature" when possible. Joypad Signals The 10 direction/button signals are each directly shortcut to ground when pressed, and pulled up high otherwise (unlike 8bit gameboys which used a 2x4 keyboard matrix), it'd be thus easy to connect a remote keyboard, keypad, joypad, or read-only 12bit parallel port.
Advance Gameboy CPU Signal Summary Cart Bus: D0-D7, A0-A15, /CS, /RD, /WR (different usage in GBA/DMG mode) WRAM Bus: WA0-WA16, WD0-WD15, /WLB, /WUB, /WWE, /WOE (used in GBA mode only) LCD Bus : LDR1-5, LDG1-5, LDB1-5, DCK, LP, PS, SPL, CLS, SPS, MOD, REVC Joypad: TP0-3 (Buttons), TP4-7 (Directions), TP8-9 (L/R-Buttons, via R43/R44) Serial Link: SC, SD (aka P14?), SI, SO - Audio: SO1-2, Vin Other: CK1-2, PHI, IN35, VCNT5, /FIQ (via CL1 to VDD3), /RESET (IN), /RES (OUT) Supply: VDD35, VDD3, VDD2, GND (some are probably undoc inputs) GBA SP: Same as GBA, plus VDD1, plus duplicated supply pins, plus pin 152.
Advance Gameboy CPU Pinouts (CPU AGB) 1 VDD3 17 D0 33 A0 49 WA4 65 VDD2 81 WD9 97 LDB5 113 CK1GBA SP CPU Pinouts (CPU AGB B) 1 IN35 21 D0 41 A0 61 WA4 81 WD13 101 GND 121 LDB4 141 GNDPin 152 seems to be not connected on the mainboard, maybe an undoc output. NDS CPU Pinouts Unknown. The CPU is hidden underneath of the DS Cartridge Slot - and to the worst, the CPU Pins are hidden underneath of the CPU itself.
Advance Gameboy Audio Amplifier (AMP AGB IR3R60N) (U6) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18SW=Headphone Switch (grounded when none connected). GBA SP Audio Amplifier (uses AMB AGB IR3R60N, too) (U3) Same connection as in GBA, except that pin14/16 connect to VR21 (instead VCC3), and pin1/9 connect to different capacitors. NDS - National Semiconductor LM4880M Dual 250mW Audio Power Amplifier (U12) 1-OUT A 2-IN A 3-BYPASS 4-GND 5-SHUTDOWN 6-IN B 7-OUT A 8-VDD.VQ5NDS-Lite: No external amplifier (Mitsumi 3205B Powermanagment Device contains internal amplifier).
Advance Gameboy Display Socket 1 ? 6 GND 11 LDR2 16 LDG2 21 LDB3 26 SPS 31 P2-VSS 36 V4GBA SP Display Socket 1 VSHD 5 VSHD 9 LDR3 13 LDG4 17 GND 21 LDB2 25 SPS 29 P2VSS 33 U83NDS Upper/Lower Display Sockets ___NDS upper screen/upper backlight/speakers socket (P3)_____________________NDS-Lite Upper/Lower Display Sockets ___NDS-Lite upper screen/upper backlight/speakers socket (P3)________________
Advance Gameboy Power Switch (2-position slider, with two common pins) GBA SP Power Switch (same as GBA) 1 via resistor to GND (OFF)GBA Micro Power Switch Same as GBA and GBA SP, but Pin 1 and 2 exchanged. Advance Gameboy Cartridge Slot Switch (integrated 4pin micro switch) GBA SP Cartridge Slot Switch (separate 4pin micro switch) C1 VDD35 (to S2 when PRESSED, to S1 when RELEASED)Pressed=8bit DMG/MGB/CGB cart, Released=32bit GBA cart (or no cart inserted) GBA: switch integrated in cart socket, GBA-SP: separate switch next to socket. Advance Gameboy Power Controller (M 121 514X) (U4) 1-VIN 2-VOUT5 3-CSS5 4-VDRV5 5-GND 6-VDRV3 7-CSS3 8-VOUT3/RESET is passed to the CPU, and then forwarded to /RES pin on cart slot. Advance Gameboy LCD Regulator (AGB-REG IR3E09N) (U3) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18GBA SP Power Controller 1 (S6403 AU227 9276) (U4) 1-VCC 2-SCP1 3-SCP2 4-VDRV3 5-VOUT3/VDD3 6-VDD2 7-VOUT1/VDD1 8-VDRV1GBA SP Power Controller 2 (2253B 2808) (U5) 1-TIN 2-U5C3 3-ADJ 4-U5VDD 5-VIN 6-? 7-U57 8-?NDS Powermanagment Device (Mitsumi 3152A) (U3) 1 R50-EXTB+ 17 33 LEDC1 49 VCNT5NDS-LITE Powermanagment Device (Mitsumi 3205B) (U3) 1 SW 17 33 LEDC1 49 VCNT5NDS-LITE Power Switch 1 PWSW (grounded when switch is pulled)
NDS RFU Daughter Board (Firmware FLASH, Wifi BB/RF Chips) 1 N/A 6 FMW.CLK 11 ENABLE 16 RX.DTA? 21 BB./CS 26 22MHz 31 GNDNDS-Lite RFU Daughter Board (Firmware FLASH, Wifi BB/RF Chip) 1 GND 6 GND 11 BB.RF.WR 16 VDD3.3 21 hi? 26 FMW.QWifi RF Chip: RF9008, 0441, E0121Q (32 pin) 1 5 9 13 17 21 RF.CLK 25 29Pin19 RF.RD (oops, should be WR, maybe I've exchanged RD-WR?) Pin20 RF./CS (via 10ohm) Pin21 RF.CLK (via 10ohm) Wifi BB Chip: Mitsumi, Japan, 4418, MM3155 (48 pins) 1 GND 7 13 GND 19 25 31 37 TX.MAIN 43Pin15 BB.CLK (via 10ohm to RFU.23) Pin16 BB.WR (RFU.25) Pin17 BB.RD (RFU.24) Pin18 22MHz (via 50ohm) Pin28 RST (same as FMW./RES) Pin32 BB./CS (RFU.21) NDS-LITE BB/RF-Chip Mitsumi MM3218 (56 pins) 1- 8-GND 15- 22-GND 29- 36- 43- 50-TX Signal/Timing Chart (Host Game) RX.DTA? __________________________________________________________This example shows a host sending beacons. The pre-beacon receive period is probably to sense conflicts with other transmitters. The post-beacon receive period is to get responses from other players. The two transmit parts are: The hardware header, followed by inactivity on the tx pins during the rest of the preamble period, then followed by the actual IEEE frame. The rest of the time is spend in idle mode to reduce power consumption. RX Signal/Timing Chart (Join Game) RX.DTA? __________________________________________________________This example shows a client trying to receive beacons, so most of the time is spent in receive mode (the short idle periods are probably occuring when it is switching to another channel). Once when it has associated with a host, the client may spend more time in idle mode, and needs to be in receive mode only when expecting to receive beacons or other data.
Advance Gameboy 256Kbytes RAM 128Kx16bit (NEC D442012LGY-B85x-MJH) (wide) GBA SP 256Kbytes RAM 128Kx16bit (F 82D12160-10FN) (square) 1 A15 7 A9 13 IC 19 A6 25 A0 31 D2 37 VCC 43 D15Connection in GBA and GBA SP: IC-GND, /CE1-GND, CE2-VDD2, VCC-VDD2, Pin16-VDD2, the other NC pins seem to be actually not connected, all other pins connect to the corresponding Wxx CPU pins. Note: Both GBA and GBA SP have soldering points for wide (12x18mm) and square (12x14mm) RAMs, so either could be used. The GBA additionally contains 32K built-in WRAM, and built-in VRAM, so the above 256K RAM chip is probably not used in 8bit classic/color gameboy mode. Advance Gameboy Schematic Fragments P2-VSS = VDD-15 VIN = VCC3 via R33 REGEXT (on my modified board, REGEXT underneath of my diodes) /RES (OUT) (via R40) /CS (via R39) /WR (via R38) SC (via Rxx) SD (via Rxx) SI (via Rxx) SO (via Rxx) DCK (via R36) A-GND via CP4 (100uF) to GND (used speaker, and on headphone socket) GBA SP Schematic Fragments P2VDD = VDD13 P2VSS = VDD15 /RES via R46 /CS via R45 /WR via R44 DCK via R20 VS=BT+ In my repaired GBA-SP: CK1 test-point is disconnected (instead GND'ed). In my repaired GBA-SP: broken oscillator replaced In my repaired GBA-SP: broken r1 1mOhm replaced (near oscillator) In my repaired GBA-SP: broken EXT2 socket metal-spring/snapper removed CL1 FIQ (near SW4) CL2 ? CL3 ? CL4 VOUT1/VDD1 (near U4) CL5 VOUT3/VDD3 (near U4) CL6 VOUT5/VDD5 (near U4) DL1-red (power low) ---R32--Q4--R6-- DL2-green (power good) ---Q6--LOWBAT/R34-VDD3 DL3-orange (charge) --R24--Q2--VIN/U57 P2VDD--VDD13 P2VSS--VDD15 S+ and S- are (almost) shortcut by R23 (1.0 ohm) S+ via Q1 to VIN VS via D1 to S- A-GND via CP1 (100uF) to GND U4 pin 12 to r6 (towards red led) U4 pin 14 to D6---to U7 SC (CPU pin48) with R7 100K ohm pullup to VDD35 P35 via Q11 to SW (speaker disable) GBA SP Backlight-Button Schematic (U6,U8,Q12) ______ _____
Below describes how to connect a PC parallel port to the GBA link port, allowing to upload small programs (max 256 KBytes) from no$gba's Utility menu into real GBAs. This is possible because the GBA BIOS includes a built-in function for downloading & executing program code even when no cartridge is inserted. The program is loaded to 2000000h and up in GBA memory, and must contain cartridge header information just as for normal ROM cartridges (nintendo logo, checksum, etc., plus some additional multiboot info). Basic Cable Connection The general connection is very simple (only needs four wires), the only problem is that you need a special GBA plug or otherwise need to solder wires directly to the GBA mainboard (see Examples below). GBA Name Color SUBD CNTR NameOptionally, also connect the following signals (see notes below): 4 SD Brown ------------- 17 36 /SELECT (double speed burst)Notes: The GBA Pins are arranged from left to right as 2,4,6 in upper row, and 1,3,5 in lower row; outside view of GBA socket; flat side of socket upside. The above "Colors" are as used in most or all standard Nintendo link cables, note that Red/Orange will be exchanged at one end in cables with crossed SO/SI lines. At the PC side, use the SUBD pin numbers when connecting to a 25-pin SUBD plug, or CNTR pin numbers for 36-pin Centronics plug. Optional SD Connection (Double Speed Burst) The SD line is used for Double Speed Burst transfers only, in case that you are using a gameboy link plug for the connection, and if that plug does not have a SD-pin (such like from older 8bit gameboy cables), then you may leave out this connection. Burst Boot will then only work half as fast though. Optional Pull-Ups (Improves Low-to-High Transition Speed) If your parallel port works only with medium or slow delay settings, try to connect 560 Ohm resistors to SI/SC/SD inputs each, and the other resistor pin to any or all of the parallel port data lines (no$gba outputs high to pins 2..9). Optional Reset Connection (CAUTION: Connection changed September 2004) The Reset connection allows to automatically reset & upload data even if a program in the GBA has locked up (or if you've loaded a program that does not support nocash burst boot), without having to reset the GBA manually by switching it off and on (and without having to press Start+Select if a cartridge is inserted). The two diodes should be 1N4148 or similar, the capacitor should be 300nF (eg. three 100nF capacitors in parallel). The signals are labeled on the mainboard, and can be found at following names / CPU pin numbers: RESET/CPU.125, SELECT/TP2/CPU.126, START/TP3/CPU.127. Optional Power Supply Connection Also, you may want to connect the power supply to parallel port data lines, see chapter Power Supply for details. Transmission Speed The first transfer will be very slow, and the GBA BIOS will display the boot logo for at least 4 seconds, even if the transfer has completed in less time. Once when you have uploaded a program with burst boot backdoor, further transfers will be ways faster. The table below shows transfer times for 0KByte - 256KByte files: Boot Mode_____Delay 0_______Delay 1_______Delay 2_____All timings measured on a 66MHz computer, best possible transmission speed should be 150KBytes/second. Timings might slightly vary depending on the CPU speed and/or operating system. Synchronization is done by I/O waitstates, that should work even on faster computers. Non-zero delays are eventually required for cables without pull-ups. Requirements Beside for the cable and plugs, no special requirements. The cable should work with all parallel ports, including old-fashioned one-directional printer ports, as well as modern bi-directional EPP ports. Transfer timings should work stable regardless of the PCs CPU speed (see above though), and regardless of multitasking interruptions. Both no$gba and the actual transmission procedure are using some 32bit code, so that either one currently requires 80386SX CPUs or above. Connection Examples As far as I can imagine, there are four possible methods how to connect the cable to the GBA. The first two methods don't require to open the GBA, and the other methods also allow to connect optional power supply and reset signal. 1) Connect it to the GBA link port. Advantage: No need toPersonally, I've decided to use the lastmost method as I don't like ending up with hundreds of special cables for different purposes, and asides, it's been fun to damage the GAB as much as possible. Note The above used PC parallel port signals are typically using 5V=HIGH while GBA link ports deal with 3V=HIGH. From my experiences, the different voltages do not cause communication problems (and do not damage the GBA and/or PC hardware), and after all real men don't care about a handful of volts, however, use at own risk.
Flashcard Upload Allows to write data to flashcards which are plugged into GBA cartridge slot, cartridge is automatically started after writing. On initial power-up, hold down START+SELECT to prevent the GBA from booting the old program in the flashcard. The Upload function in Utility menu uses flashcard mode for files bigger than 256KB (otherwise uses multiboot mode automatically). Also, there's a separate Upload to Flashcard function in Remote Access submenu, allowing to write files of 256KB or less to flashcard if that should be desired. Supported Flashcards Function currently tested with Visoly Flash Advance (FA) 256Mbit (32MB) Turbo cartridge. Should also work with older FA versions. Please let me know if you are using other flashcards which aren't yet supported. Flashcard Performance Writing to flashcards may become potentially slow because of chip erase/write times, cable transmission time, and the sheer size of larger ROM-images. However, developers whom are testing different builts of their project usually won't need to rewrite the complete flashcard, Xboo uses a highspeed checksum mechanism (16MB/sec) to determine which flashcard sector(s) have changed, and does then re-write only these sector(s). To eliminate transmission time, data transfer takes place in the erase phases. Erase/write time depends on the flashcard type, should be circa 1-2 seconds per 256KB sector. Because the cartridge is programmed directly in the GBA there's no need to remove it from the GBA when writing to it. Developers Advice Locate your program fragments at fixed addresses, for example, code and data blocks each aligned to 64K memory boundaries, so that data remains at the same location even when the size of code changes. Fill any blank spaces by value FFh for faster write time. Reduce the size of your ROM-image by efficient memory use (except for above alignment trick). Include the burst boot backdoor in your program, allowing to re-write the flashcard directly without resetting the GBA. Lamers Advice Xboo Flashcard support does not mean to get lame & to drop normal multiboot support, if your program fits into 256KB then make it <both> flashcard <and> multiboot compatible - multiboot reduces upload time, increases your flashcard lifetime, and will also work for people whom don't own flashcards.
When writing Xboo compatible programs, always include a burst boot "backdoor", this will allow yourself (and other people) to upload programs much faster as when using the normal GBA BIOS multiboot function. Aside from the improved transmission speed, there's no need to reset the GBA each time (eventually manually if you do not have reset connect), without having to press Start+Select (if cartridge inserted), and, most important, the time-consuming nintendo-logo intro is bypassed. The Burst Boot Protocol In your programs IRQ handler, add some code that watches out for burst boot IRQ requests. When sensing a burst boot request, download the actual boot procedure, and pass control to that procedure. Send (PC) Reply (GBA)Use normal mode, 32bit, external clock for all transfers. The received highspeed loader (currently approx. 180h bytes) is to be loaded to and started at 3000000h, which will then handle the actual download operation. Below is an example program which works with multiboot, burstboot, and as normal rom/flashcard. The source can be assembled with a22i (the no$gba built-in assembler, see no$gba utility menu). When using other/mainstream assemblers, you'll eventually have to change some directives, convert numbers from NNNh into 0xNNN format, and define the origin somewhere in linker/makefile instead of in source code. .arm ;select 32bit ARM instruction set |