|
|
| (6 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| [[Category:in NesCartDB]][[Category:ASIC mappers]][[Category:Mappers with cycle IRQs]] | | [[Category:in NesCartDB]][[Category:ASIC mappers]][[Category:Mappers with cycle IRQs]] |
| Bandai FCG boards are used largely by Bandai for ''Dragon Ball'' and ''Gundam'' games, as well as a few others. One IREM title uses it as well. | | [[Bandai FCG board]]s are used largely by Bandai for ''Dragon Ball'' and ''Gundam'' games, as well as a few others. One Irem title uses it as well. |
|
| |
|
| == Overview ==
| | All of these games were originally assigned to [[INES Mapper 016]] before the subtle differences, that are nonetheless relevant for fully functional emulation, became known. Please refer to the [[INES Mapper 016]] page for a general description of all registers, and to the [[INES Mapper 153]], [[INES Mapper 157]] and [[INES Mapper 159]] pages for information on the differences of those particular mappers compared to mapper 16. |
| * PRG ROM size: 256 KiB normally; 512KiB in one variant | | * [[INES Mapper 016]] submapper 4: FCG-1/2 ASIC, no serial EEPROM, banked CHR-ROM |
| * PRG ROM bank size: 16 KiB
| | * [[INES Mapper 016]] submapper 5: LZ93D50 ASIC and no or 256-byte serial EEPROM, banked CHR-ROM |
| * Nonvolatile memory: 0, 128, 256, or 8192 bytes | | * [[INES Mapper 159]]: LZ93D50 ASIC and 128-byte serial EEPROM, banked CHR-ROM |
| * CHR capacity: Up to 256 KiB ROM or 8 KiB RAM [[Category:Mappers with CHR RAM]] | | * [[INES Mapper 153]]: LZ93D50 ASIC and 8 KiB battery-backed WRAM, unbanked CHR-RAM |
| * CHR bank size: 1 KiB
| | * [[INES Mapper 157]] (Datach Joint ROM System): LZ93D50 ASIC and 256-byte serial EEPROM on Datach Main Unit, optional additional 128-byte serial EEPROM on game cartridge, unbanked CHR-RAM, barcode reader |
| * Nametable [[mirroring]]: Controlled by mapper | |
| * Subject to [[bus conflict]]s: No | |
|
| |
|
| == Hardware Types == | | {| class="wikitable sortable" |
| | | ! Name !! ASIC !! CHR Memory !! Save Data !! Mapper.Submapper !! [[NES_2.0#Byte_10_.28RAM_size.29|NES 2.0 Byte 10]] |
| There are at least 6 different varieties of FCG board:
| | |- |
| # [[Bandai FCG pinout|FCG-1 and FCG-2]]: Registers are at $6000-$7FFF. No persistent writable storage.
| | |''Akuma-kun: Makai no Wana'' || FCG-2 || CHR-ROM || - || 16.4 || $00 |
| # [[Bandai LZ93D50 pinout|LZ93D50]], sometimes erroneously known as FCG-3: Registers are at $8000-$FFFF. No persistent writable storage.
| | |- |
| # LZ93D50 with 24C01: Registers are at $8000-$FFFF. 24C01 128-byte serial [[ROM#Solid state ROM|EEPROM]] is attached to $6000-$7FFF.
| | |''Crayon Shin-chan: Ora to Poi Poi'' || LZ93D50 || CHR-ROM || - || 16.5 || $00 |
| # LZ93D50 with 24C02: Registers are at $8000-$FFFF. 24C02 256-byte serial [[ROM#Solid state ROM|EEPROM]] is attached to $6000-$7FFF.
| | |- |
| # LZ93D50 with SRAM: Registers are at $8000-$FFFF. Conventional battery backed SRAM is at $6000-$7FFF. This board also exceeds the 256KiB PRG ROM limit by repurposing CHR select lines.
| | |''Dragon Ball: Daimaou Fukkatsu'' || FCG-1 || CHR-ROM || - || 16.4 || $00 |
| # [[wikipedia:Datach|Datach Joint ROM System]] boards, which have a 24C02 serial [[ROM#Solid state ROM|EEPROM]] on the main board and the game itself on a daughterboard, possibly with another 24C01 serial [[ROM#Solid state ROM|EEPROM]].
| | |- |
| | | |''Dragon Ball 3: Gokuu Den'' || FCG-2 || CHR-ROM || - || 16.4 || $00 |
| Mappers describe these boards as follow:
| | |- |
| | | |''Dragon Ball Z II: Gekishin Freezer!!'' || LZ93D50 || CHR-ROM || 24C02 || 16.5 || $20 |
| Four mappers are used to describe these boards:
| | |- |
| * [[iNES Mapper 016]] is used for 1, 2, and 4.
| | |''Dragon Ball Z III: Ressen Jinzou Ningen'' || LZ93D50 || CHR-ROM || 24C02 || 16.5 || $20 |
| * [[iNES Mapper 153]] is a rarely used assignment for 5.
| | |- |
| * [[iNES Mapper 157]] is used for 6.
| | |''Dragon Ball Z Gaiden: Saiya-jin Zetsumetsu Keikaku'' || LZ93D50 || CHR-ROM || 24C02 || 16.5 || $20 |
| * [[iNES Mapper 159]] is used for 3.
| | |- |
| | | |''Famicom Jump: Hero Retsuden'' || FCG-2 || CHR-ROM || - || 16.4 || $00 |
| You may encounter ROMs with the mapper assignments mixed up. There used to be no distinction when 016 was first assigned. The distinction was introduced later to distinguish the 128-byte boards from the 256-byte or no-EEPROM boards. In [[NES 2.0]] format, only 157 differs, because the "battery backed PRG RAM size" field disambiguates these boards enough to run all known games that used them, though emulators MAY display a warning when the RAM size field is abnormal for a given mapper.
| | |- |
| | | |''Meimon! Dai-3 Yakyuu-bu'' || FCG-1 || CHR-ROM || - || 16.4 || $00 |
| FCEUX does not emulate the EEPROM. It seems that returning 0x00 from EEPROM registers suffices to get most games booting.
| | |- |
| | | |''Nishimura Kyoutarou Mystery: Blue Train Satsujin Jiken '' || FCG-1 || CHR-ROM || - || 16.4 || $00 |
| == Banks ==
| | |- |
| * CPU $6000-$7FFF: varies, see below
| | |''Rokudenashi Blues'' || LZ93D50 || CHR-ROM || 24C02 || 16.5 || $20 |
| * CPU $8000-$BFFF: 16 KiB switchable PRG ROM bank
| | |- |
| * CPU $C000-$FFFF: 16 KiB PRG ROM bank, fixed to the last bank
| | |''Sakigake!! Otoko Juku: Shippu 1-gou Sei'' || FCG-1 || CHR-ROM || - || 16.4 || $00 |
| * Either:
| | |- |
| ** PPU $0000-$03FF: 1 KiB switchable CHR ROM bank
| | |''SD Gundam Gaiden - Knight Gundam Monogatari 2: Hikari no Kishi'' || LZ93D50 || CHR-ROM || 24C02 || 16.5 || $20 |
| ** PPU $0400-$07FF: 1 KiB switchable CHR ROM bank
| | |- |
| ** PPU $0800-$0BFF: 1 KiB switchable CHR ROM bank
| | |''SD Gundam Gaiden - Knight Gundam Monogatari 3: Densetsu no Kishidan'' || LZ93D50 || CHR-ROM || 24C02 || 16.5 || $20 |
| ** PPU $0C00-$0FFF: 1 KiB switchable CHR ROM bank
| | |- |
| ** PPU $1000-$13FF: 1 KiB switchable CHR ROM bank
| | |''Dragon Ball Z: Kyoushuu! Saiya-jin'' || LZ93D50 || CHR-ROM || 24C01 || 159 || $10 |
| ** PPU $1400-$17FF: 1 KiB switchable CHR ROM bank
| | |- |
| ** PPU $1800-$1BFF: 1 KiB switchable CHR ROM bank
| | |''Magical Taruruuto-kun: Fantastic World!!'' || LZ93D50 || CHR-ROM || 24C01 || 159 || $10 |
| ** PPU $1C00-$1FFF: 1 KiB switchable CHR ROM bank
| | |- |
| * or
| | |''Magical Taruruuto-kun 2: Mahou Daibouken'' || LZ93D50 || CHR-ROM || 24C01 || 159 || $10 |
| ** PPU $0000-$1FFF: 8 KiB unbankable CHR RAM
| | |- |
| | | |''SD Gundam Gaiden - Knight Gundam Monogatari'' || LZ93D50 || CHR-ROM || 24C01 || 159 || $10 |
| == Registers ==
| | |- |
| | | |''Famicom Jump II: Saikyou no 7-nin'' || LZ93D50 || CHR-RAM || 8 KiB WRAM || 153 || $70 |
| See the notes about hardware above. Because [[iNES Mapper 016]] covers the capabilities of multiple differing boards, it must be emulated with the mapper's writable ports across all off $6000-$FFFF, and a 24C02 present at $6000-$7FFF. This configuration will run all known games that used one of these boards.
| |
| | |
| For [[iNES Mapper 153]] (with SRAM), the writeable ports must only be mirrored across $8000-$FFFF.
| |
| | |
| Mappers [[iNES Mapper 157|157]] and [[iNES Mapper 159|159]] do not need to support the FCG-1 and -2 and so should only mirror the ports across $8000-$FFFF.
| |
| | |
| The registers are mirrored every 16 bytes, regardless of where they start.
| |
| | |
| === CHR bank select (BASE+0 … BASE+7) ===
| |
| ==== Mappers [[iNES Mapper 016|16]] and [[iNES Mapper 159|159]]: ====
| |
| | |
| 7 bit 0
| |
| ---- ----
| |
| CCCC CCCC
| |
| |||| ||||
| |
| ++++-++++-- Select 8KiB CHR ROM bank at appropriate PPU address.
| |
| | |
| {| class="wikitable"
| |
| ! Write to register offset !! 1KiB CHR bank affected
| |
| |- | | |- |
| | 0 || $0000-$03FF | | |''Datach Crayon Shin-chan: Ora to Poi Poi'' || LZ93D50 || CHR-RAM || Datach Main Unit's 24C02 || 157 || $00 |
| |- | | |- |
| | 1 || $0400-$07FF | | |''Dragon Ball Z: Gekitou Tenkaichi Budoukai'' || LZ93D50 || CHR-RAM || Datach Main Unit's 24C02 || 157 || $00 |
| |- | | |- |
| | 2 || $0800-$0BFF | | |''J-League Super Top Players'' || LZ93D50 || CHR-RAM || Datach Main Unit's 24C02 || 157 || $00 |
| |- | | |- |
| | 3 || $0C00-$0FFF | | |''SD Gundam Wars'' || LZ93D50 || CHR-RAM || Datach Main Unit's 24C02 || 157 || $00 |
| |- | | |- |
| | 4 || $1000-$13FF | | |''Ultraman Club: Spokon Fight!!'' || LZ93D50 || CHR-RAM || Datach Main Unit's 24C02 || 157 || $00 |
| |- | | |- |
| | 5 || $1400-$17FF | | |''Yuu Yuu Hakusho - Bakutou Ankoku Bujutsu-kai'' || LZ93D50 || CHR-RAM || Datach Main Unit's 24C02 || 157 || $00 |
| |- | | |- |
| | 6 || $1800-$1BFF | | |''Battle Rush: Build up Robot Tournament'' || LZ93D50 || CHR-RAM || Datach Main Unit's 24C02+24C01 on cartridge || 157 || $10 |
| |- | | |- |
| | 7 || $1C00-$1FFF
| |
| |} | | |} |
|
| |
| ==== Mapper [[iNES Mapper 153|153]] ($8000-$8003 only): ====
| |
|
| |
| 7 bit 0
| |
| ---- ----
| |
| xxxx xxxP
| |
| |
| |
| +-- Select 256KiB PRG ROM outer bank
| |
|
| |
| As this mapper has no CHR ROM and only 8KiB fixed CHR RAM, the CHR ROM selection lines are repurposed similarly to [[SUROM]]. So CHR A10 OUT is connected to PRG A18 out on the mapper IC. The mapper's PPU A12 and PPU A13 inputs are tied to ground, but the PPU A11 and PPU A10 inputs are still connected, so the first 4 CHR bank 'P' bits should be set to the same value, or the game will flip between 256KiB PRG outer banks while rendering.
| |
|
| |
| ==== External Serial EEPROM Clock ($8000 … $8003) ====
| |
| 7 bit 0
| |
| ---- ----
| |
| xxxx Cxxx
| |
| |
| |
| +----- External I²C Clock
| |
|
| |
| As with mapper 153, [[iNES Mapper 157]] grounds the PPU A12 and A13 inputs. CHR A13 OUT is provided on the subcartridge header, and is used in one game as an external I²C clock.
| |
| PPU rendering must either be disabled during traffic to the external EEPROM, or the same value must be written to all four registers.
| |
| No CHR banking is available.
| |
|
| |
| It's conceivable that a game could have used this extra signal to provide 512 KiB of PRG instead of a serial EEPROM, but none have been found.
| |
|
| |
| === PRG Bank select (BASE+8) ===
| |
| 7 bit 0
| |
| ---- ----
| |
| .... PPPP
| |
| ||||
| |
| ++++-- Select 16KiB PRG ROM bank mapped to CPU $8000-$BFFF
| |
|
| |
|
| |
| === Mirroring Control (BASE+9) ===
| |
| 7 bit 0
| |
| ---- ----
| |
| .... ..MM
| |
| ||
| |
| ++-- 0: Vertical (A10), 1: Horizontal (A11), 2: Single screen 1 (ground), 3: Single screen 2 (VCC)
| |
|
| |
| === IRQ Control (BASE+$A) ===
| |
| 7 bit 0
| |
| ---- ----
| |
| .... ...C
| |
| |
| |
| +-- 1: Count down, 0: pause
| |
|
| |
| Writes also acknowledge a currently-asserted interrupt.
| |
|
| |
| === IRQ Counter (BASE+$B … BASE+$C) ===
| |
|
| |
| $C $B
| |
| 7 bit 0 7 bit 0
| |
| ---- ---- ---- ----
| |
| CCCC CCCC CCCC CCCC
| |
| |||| |||| |||| ||||
| |
| ++++-++++--++++-++++-- The 16 bits of the current value of the counter (little-endian)
| |
|
| |
| The IRQ counter is clocked by M2.
| |
| There is no reload value, nor does it stop: after it becomes 0, it becomes 65535.
| |
| <strike>Writes are not shadowed, so you either need to be careful about timing or pause the counter while you manually reload.</strike> See [https://forums.nesdev.org/viewtopic.php?t=15967].
| |
|
| |
| It is not known precisely which of the following are true:
| |
| * Is /IRQ asserted while the timer is 0 ?
| |
| * Is /IRQ asserted when the counter goes from 1 to 0 ?
| |
| * Is /IRQ asserted when it changes from anything to 0 ?
| |
|
| |
| === EEPROM Control ($800D) ===
| |
| For games with serial EEPROMs:
| |
|
| |
| 7 bit 0
| |
| ---- ----
| |
| RDC. ....
| |
| |||
| |
| ||+-------- I²C SCL (Datach: internal EEPROM only)
| |
| |+--------- I²C SDA
| |
| +---------- Enable Read
| |
|
| |
| === PRG RAM Enable ($800D) ===
| |
| For games with PRG RAM:
| |
|
| |
| 7 bit 0
| |
| ---- ----
| |
| RxE. ....
| |
| |||
| |
| ||+-------- PRG RAM +CE
| |
| |+--------- don't care
| |
| +---------- probably should always be 0
| |
|
| |
| === Serial EEPROM ($6000-$7FFF) ===
| |
| Read-only; for games using the LZ93D50 but without PRG RAM.
| |
|
| |
| 7 bit 0
| |
| ---- ----
| |
| xxxE Bxxx
| |
| |||| ||||
| |
| +++|-|+++- Open bus
| |
| | +---- Data out from Barcode reader (or open bus)
| |
| +------ Data out from I²C EEPROM
| |
|
| |
| == Implementing EEPROM communication ==
| |
| ''Datach - Battle Rush - Build Up Robot Tournament (J)'' is one of the games (only?) that needs bots EEPROMs to be present.
| |
| *If no EEPROMs are present and reading $6000 is not implemented, game will hang at black screen (even no Datach logo will be shown)
| |
| *If no EEPROMs are present but reading $6000.4 returns always 0, game will run and allow to create robot, but no playing will be available (that's what FCEUX does [https://www.youtube.com/watch?v=XkekbUXmHDY])
| |
|
| |
| If you want to implement this mapper in hardware, you might consider to emulate EPROM access in FPGA. However, this would need:
| |
| * state machine and I2C protocol to be implemented,
| |
| * resources in FPGA to emulate 1024 + 2048 bits of memory.
| |
| Easier approach is to connect external AT24C01 and AT24C02 chips to FPGA.
| |
|
| |
| While 24C02 is standard I2C memory which behaves in the same way among different manufacturers, 24C01 is quite special as it is not addresses before access like other I2C devices. Atmel's AT24C01 behaves like that way however different datasheets states contradictory description [http://www.alldatasheet.com/datasheet-pdf/pdf/56094/ATMEL/24C01.html], [http://www.atmel.com/Images/doc0180.pdf]), so you should probably stick to AT24C01, not AT24C01A.
| |
|
| |
| Wiring diagram:
| |
| +-----V------+ +-----V------+
| |
| | AT24C01 | | AT24C02 |
| |
| | | | |
| |
| GND->|1 A0 VCC 8|<-5V/3.3V GND->|1 A0 VCC 8|<-5V/3.3V
| |
| GND->|2 A1 WP 7|<-GND GND->|2 A1 WP 7|<-GND
| |
| GND->|3 A2 SCL 6|<---+ GND->|3 A2 SCL 6|<---+
| |
| GND->|4 GND SDA 5|<-+ | VCC GND->|4 GND SDA 5|<-+ |
| |
| +------------+ | | | +------------+ | |
| |
| | | R | +--- SCL2
| |
| | +---|------------------------|----- SCL1
| |
| +-----+------------------------+----- SDA
| |
|
| |
| Notes:
| |
| * Game expects A0/A1/A2 of 24C02's to be 0 (write protection via WP pin should be also disabled)
| |
| * 24C01's does not have A0/A2/A2/WP (it's still safe to tie them to GND)
| |
| * Both EEPROMs share common SDA data bus.
| |
| * AT24C01's SCL1 clock is $8000.3, AT24C02's SCL2 clock is $800D.5.
| |
| * If $800D.7 = 1 then FPGA does not drive SDA bus and current bus value can be read via $6000.4
| |
| * If $800D.7 = 0 then FPGA drive SDA bus with $800D.6.
| |
| * Game does not require any of the EPROMs to have preprogrammed any content
| |
| * Add pull resistor to VCC on SDA
| |
|
| |
| Below are sample communication waveforms (signal `rd` is $800D.7)
| |
| [[File:Battle Rush EEPROM waveform.png|200px|thumb|right]]
| |
|
| |
| == Extra comments ==
| |
| Some patterns observed in the games' save code:
| |
| * Start I/O: $00 $40 $60 $20 $00
| |
| * Write 0 bit: $00 $20 $00
| |
| * Write 1 bit: $00 $40 $60 $40 $00
| |
| * Acknowledge: $00 $20 $A0 Read $00
| |
| * Read bit: $60 $E0 Read $40
| |
| * Stop I/O: $00 $20 $60 $40 $C0
| |
|
| |
| When implementing the EEPROM, use the datasheets for the 24C01 and 24C02 used by Bandai:
| |
| * 24C01, has no device address/uses device address as memory address: [http://pdf.datasheetcatalog.com/datasheet/Xicor/mXyyzyrx.pdf Xicor], [http://www.alldatasheet.com/datasheet-pdf/pdf/56094/ATMEL/24C01.html Atmel]
| |
| ** The 24C01 is NOT little endian, despite what Disch wrote below. This is due to a mistake at Bandai, not a deviation from the datasheet.
| |
| * 24C02, with device address: [http://pdf.datasheetcatalog.com/datasheets/70/289981_DS.pdf Xicor], [http://www.atmel.com/Images/doc0180.pdf Atmel]
| |
|
| |
| == Disch's notes ==
| |
| Below, Disch was unfamiliar with I²C, so a number of his comments are solely from the point of view of someone unfamiliar with it.
| |
| Here is a lightly-edited version of Disch's original notes:
| |
| ========================
| |
| = Mapper 016 =
| |
| = + 153 =
| |
| = + 159 =
| |
| ========================
| |
|
| |
| aka
| |
| --------------------------
| |
| Bandai (something or other)
| |
|
| |
|
| |
| Example Games:
| |
| --------------------------
| |
| Dragon Ball - Dai Maou Jukkatsu (016)
| |
| Dragon Ball Z Gaiden (016)
| |
| Dragon Ball Z 2 (016)
| |
| Rokudenashi Blues (016)
| |
| Akuma-kun - Makai no Wana (016)
| |
| Famicom Jump II: Saikyou no 7 Nin (153)
| |
| Dragon Ball Z - Kyoushuu! Saiya Jin (159)
| |
| SD Gundam Gaiden (159)
| |
| Magical Taruruuto Kun 1, 2 (159)
| |
|
| |
|
| |
| Three Mappers:
| |
| ---------------------------
| |
| 016 and 159 are mapped the exact same way. Registers are all the same and whatnot. And in fact, for a
| |
| while, both mappers were assigned the same mapper number (016). Therefore, you may come across mapper 159
| |
| games that are still marked as mapper 016.
| |
|
| |
| The difference between the two is in the EEPROM. These mappers don't have traditional SRAM (I couldn't tell
| |
| you why). Instead, they have an I²C EEPROM that has to be written to one bit at a time, resulting in very
| |
| strange-seeming register writes.
| |
|
| |
| Mapper 016 has 256 bytes of EEPROM, and is accessed high bit first
| |
| Mapper 159 has 128 bytes of EEPROM, and is accessed low bit first
| |
| Mapper 153 (as far as we know used exclusively for Famicom Jump II: Saikyou no 7 Nin) has SRAM instead of an EEPROM.
| |
|
| |
| For further details, see the section at the bottom.
| |
|
| |
| Apart from save mechanism, the mappers are 100% identical in function.
| |
|
| |
|
| |
| Notes:
| |
| ---------------------------
| |
| Since there's EEPROM, there's no SRAM (EEPROM is used to save games).
| |
|
| |
|
| |
| Registers:
| |
| ---------------------------
| |
|
| |
| Range,Mask: $6000-FFFF, $000F
| |
|
| |
| Note: below regs are listed as $800x, but note they also exist at $6000-7FFF
| |
|
| |
|
| |
| $8000-8007: CHR Regs
| |
| $8008: PRG Reg (16k @ $8000)
| |
|
| |
| $8009: [.... ..MM] Mirroring:
| |
| %00 = Vert
| |
| %01 = Horz
| |
| %10 = 1ScA
| |
| %11 = 1ScB
| |
|
| |
| $800A: [.... ...E] IRQ Enable (0=disabled)
| |
| $800B: Low 8 bits of IRQ Counter
| |
| $800C: High 8 bits of IRQ Counter
| |
|
| |
| $800D: EEPROM I/O
| |
|
| |
| another note: since PRG is mapped to $8000-FFFF, EEPROM I/O reg can only be read via $6xxx or $7xxx. To my
| |
| knowledge no other registers are readable. It also appears that reading from *ANY* address in $6xxx-7xxx
| |
| will read the EEPROM I/O reg. Rokudenashi Blues will poll $7F00 and will wait for bit 4 to be 0 before
| |
| continuing (so if you're giving open bus @ 7F00, the game will deadlock)
| |
|
| |
| CHR Setup:
| |
| ---------------------------
| |
|
| |
| $0000 $0400 $0800 $0C00 $1000 $1400 $1800 $1C00
| |
| +-------+-------+-------+-------+-------+-------+-------+-------+
| |
| | $8000 | $8001 | $8002 | $8003 | $8004 | $8005 | $8006 | $8007 |
| |
| +-------+-------+-------+-------+-------+-------+-------+-------+
| |
|
| |
|
| |
| PRG Setup:
| |
| ---------------------------
| |
|
| |
| $8000 $A000 $C000 $E000
| |
| +---------------+---------------+
| |
| | $8008 | { -1} |
| |
| +---------------+---------------+
| |
|
| |
|
| |
|
| |
| IRQs:
| |
| ---------------------------
| |
| IRQs are nice and simple.
| |
|
| |
| When enabled, the 16-bit IRQ counter counts down every CPU cycle, wrapping from $0000->FFFF. When the
| |
| counter makes the transition from $0001->$0000, an IRQ is generated.
| |
|
| |
| When disabled, the IRQ counter does not count.
| |
|
| |
| Any write to $800A will acknowledge the IRQ
| |
|
| |
| $800B and $800C change the IRQ counter directly -- not a reload value.
| |
|
| |
|
| |
| EEPROM:
| |
| ---------------------------
| |
| EEPROM is a real nightmare. Nobody knew exactly how it worked -- but by examining the game code,
| |
| patterns surface. Games do a series of extremely cryptic writes to $800D, and occasionally read a single
| |
| bit from $800D. By examining some logs I made of the games I've noticed a small bit of patterns which I
| |
| list below, along with my guess as to what the game is attempting to do by performing that pattern:
| |
|
| |
|
| |
| write $00
| |
| write $40
| |
| write $60 Start I/O
| |
| write $20
| |
| write $00
| |
|
| |
| write $00
| |
| write $20 Output '0' bit
| |
| write $00
| |
|
| |
| write $00
| |
| write $40
| |
| write $60 Output '1' bit
| |
| write $40
| |
| write $00
| |
|
| |
| write $00
| |
| write $20
| |
| write $A0 I have absolutly no clue
| |
| Read
| |
| write $00
| |
|
| |
| write $60
| |
| write $E0 Read a single bit
| |
| Read
| |
| write $40
| |
|
| |
| write $00
| |
| write $20
| |
| write $60 Stop I/O
| |
| write $40
| |
| write $C0
| |
|
| |
|
| |
| These likely aren't the only patterns that games perform. I recall seeing occasional writes of $80 and
| |
| other stuff thrown in there in some games. Also -- not all games follow this pattern, so looking for these
| |
| specific writes will not work for at least one other game.
| |
|
| |
| It seems that only bits 5-7 of the written value are relevent (hereon, they will be referred to as D5 - D7).
| |
| Bit 4 ($10) is the only significant bit when read. Other bits are most likely open bus.
| |
|
| |
|
| |
| When writing bytes to EEPROM, games will generally perform 8 "output" patterns (either output 0 or output 1,
| |
| depending on the bits it wants to write), followed by a 9th output pattern, which I would assume finalizes
| |
| the write and/or possibly moves the 8 bits from a latch to EEPROM.
| |
|
| |
| When reading bytes, games will generally perform 8 "read" patterns, followed by a single output pattern
| |
| (which I would assume finalizes the read).
| |
|
| |
| Sometimes when the game is writing bits, it's writing data to be stored on EEPROM, and other times it's
| |
| setting the desired EEPROM address and/or read/write mode. Knowing which it's doing involves keeping track
| |
| of the state it's currently it and what it has done last, etc, etc.
| |
|
| |
| But again -- nobody *really* knows how it works. The method I've employed in my emu is outlined below -- and
| |
| it appears to work for every game I've tried, but I *KNOW* it's not accurate. But, short of some hardware
| |
| guru acquiring a handful of these carts and doing a thorough RE job, that's about the best anyone can do.
| |
|
| |
|
| |
| Emulating EEPROM:
| |
| -----------------------
| |
|
| |
| SUPER FAT IMPORTANT NOTE: This is just the method of EEPROM emulation I employ in my emu.
| |
|
| |
| ***THIS IS NOT HOW THE ACTUAL HARDWARE WORKS***
| |
|
| |
| Do not use this as a final word or anything -- this is simply the product of lots of guesswork, speculation,
| |
| and trial and error.
| |
|
| |
|
| |
| D5 appears to be the "trigger" bit, and D6 appears to be the "signal" bit. I have no clue what D7 does, and
| |
| ignoring it completely has worked for me (though I'm sure it does have some purpose). "Commands" are sent
| |
| by toggling D5 (0->1->0). Two states of D6 are observed -- one when D5 rises (0->1), and one when it falls
| |
| (1->0). Using these two observed states, you get 4 possible commands. The command is sent when D5 falls.
| |
|
| |
| Example:
| |
|
| |
| byte D6 D5
| |
| write: $00 0 0
| |
| write: $40 1 0
| |
| write: $60 1 1 <-- D5 rise: D6=1
| |
| write: $40 1 0 <-- D5 fall: D6=1, command "1,1" sent here
| |
| write: $00 0 0
| |
|
| |
| The above sequence would issue a "1,1" command.
| |
|
| |
| Commands:
| |
|
| |
| Name rise,fall example write sequence
| |
| ------------------------------------------------
| |
| Write 0 0,0 $00, $20, $00
| |
| Write 1 1,1 $00, $40, $60, $40, $00
| |
| Open 1,0 $00, $40, $60, $20, $00
| |
| Close 0,1 $00, $20, $60, $40, $C0
| |
|
| |
|
| |
| The unit can be in one of several modes:
| |
|
| |
| - Closed
| |
| - Select
| |
| - Address
| |
| - Write
| |
| - Read
| |
|
| |
| I also use an 8-bit temporary value, an 8-bit address (or 7-bit address, if 128 byte EEPROM) and 9-step bit
| |
| counter.
| |
|
| |
| I would assume the unit is Closed on startup (and possibly reset).
| |
|
| |
|
| |
| Basic Concept overview:
| |
|
| |
|
| |
| "Write 0" and "Write 1" commands advance the 9-step bit counter. The first 8 writes fill the appropriate
| |
| bit in the temporary value. The 9th write will take the temp value and move it to either the address (if in
| |
| Address mode), or to the desired area in EEPROM (if in Write mode), and the mode will update accordingly.
| |
| Basically the first 8 writes fill the temp value and the 9th moves it to where it needs to go.
| |
|
| |
| Reads operate similarly... but the temp buffer isn't affected by the writes, and the 9th step doesn't copy
| |
| the temp value anywhere. Note however that games will perform a write between each bit read (presumably to
| |
| advance it to the next bit) -- so you should do nothing but return the appropriate bit when the game reads
| |
| the EEPROM I/O Reg (do not advance it to the next bit on read).
| |
|
| |
| "Select" mode exists on 256 byte EEPROM only (mapper 016). It is used to select between read/write mode.
| |
| Bit 0 of the 8-bit value written when in Select mode determines read/write mode. On 128 byte EEPROM (mapper
| |
| 159), the high bit of the address selects read/write mode. In both cases, 1=read mode, 0=write mode.
| |
|
| |
| Remember that on 128 byte, values are written low bit first... but on 256 byte, they're written high bit
| |
| first. Bits are read the same order they're written.
| |
|
| |
| Doing anything but opening when the unit is closed has no effect.
| |
|
| |
|
| |
| Logic Flow Details (256-byte ... mapper 016)
| |
| --------------------------------------------
| |
|
| |
| Opening from Closed Mode:
| |
| a) Enter Select Mode
| |
|
| |
| Opening from non-Closed Mode:
| |
| a) if in Select Mode, increment address by 1
| |
| b) enter Select Mode.
| |
| c) Reset bit counter (next write is the first write in the 9-write sequence)
| |
|
| |
| Writing in Select Mode:
| |
| a) If low bit of written value = 1
| |
| -) Enter Read Mode
| |
| b) otherwise...
| |
| -) Enter Address Mode
| |
|
| |
| Writing in Address Mode:
| |
| a) written value becomes address
| |
| b) Enter Write mode
| |
|
| |
| Writing in Write Mode:
| |
| a) written value moves to current address of EEPROM
| |
| b) mode is not changed
| |
|
| |
| Writing in Read Mode:
| |
| a) Enter Select Mode
| |
|
| |
|
| |
|
| |
| Logic Flow Details (128-byte ... mapper 159)
| |
| --------------------------------------------
| |
|
| |
| Opening from Closed Mode:
| |
| a) Enter Address Mode
| |
|
| |
| Opening from non-Closed Mode:
| |
| a) increment address by 1 (wrap $7F->00)
| |
| b) do not change mode
| |
| c) Reset bit counter (next write is the first write in the 9-write sequence)
| |
|
| |
| Writing in Address Mode:
| |
| a) written value becomes address (low 7 bits only)
| |
| b) if high bit of written value is set...
| |
| -) Enter Read Mode
| |
| c) otherwise...
| |
| -) Enter Write Mode
| |
|
| |
| Writing in Write Mode:
| |
| a) written value moves to current address of EEPROM
| |
| b) Enter Address mode
| |
|
| |
| Writing in Read Mode:
| |
| a) Enter Address Mode
| |
|
| |
| == See Also ==
| |
| * [http://nesdev.org/bandai-e.txt Bandai Mapper] By goroh, translated by Sgt. Bowhack.
| |
| * [http://www.romhacking.net/documents/362/ NES mapper list] by Disch
| |
|
| |
| Japanese only :
| |
|
| |
| * [http://nesdev.org/16.txt Bandai Mapper] by goroh.
| |
| * Naruko's notes:
| |
| ** http://w.livedoor.jp/famicomcartridge/d/Bandai%20FCG%20series
| |
| ** http://w.livedoor.jp/famicomcartridge/d/Bandai%20FCG-1
| |
| ** http://w.livedoor.jp/famicomcartridge/d/Bandai%20FCG-2
| |
| ** http://w.livedoor.jp/famicomcartridge/d/Bandai%20LZ93D50%20standard
| |
| ** http://w.livedoor.jp/famicomcartridge/d/Bandai%20BA-JUMP2 ([[iNES Mapper 153]])
| |
| ** http://w.livedoor.jp/famicomcartridge/d/Bandai%20Datach ([[iNES Mapper 157]])
| |
