KrzysioCart - Home made cartridge that support>80% NES games

KrzysioCart Micro SD (Chris' MicroSD Cartridge) - revolution for Famicom players


I would proudly like to present my latest project - KrzysioCart Micro SD - Famiclone cartridge, that should be the last one you'll ever buy - no more carts will you ever need. Cartridge is compatible with 82% of all games that have been ever released for NES / Famicom / Famiclones. Following mappers (chips that extends console's abilities) are supported


Moreover, this is the first and only cart that supports famous Famiclone multicart: Contra Function 168-in-1, which is more familiar to Polish and Russian players and every child that had been playing famiclone, cannot imagine his childchood without this cart. Adding support for this cart is my gift to Polish players:


Good news for impatient readers - this cart is available for sale (scroll to end of article for more details). The whole set that I am offering to sale consists of:
- cartridge printed circuit board with plastic shell,
- MicroSD 4 GB memory card
- MicroSD USB reader, which will let you put files on MicroSD card.
This is all you need to begin playing your favourite games.

Cartridge had been tested on most famous Famiclones:
- MT777DX
- IQ502 rev2/3
- SP60 (version based on integration circuits),
- RINCO (Thompsonic)
- two blob-top consoles (a'ka NOC = Nes on a Chip).
There were no problems whatsoever. The cartridge has also possibility for firmware update directly from SD cart. No one has ever invented something that in Europe and I am the second person that started works at it in 2012 (NES PowerPak was first).

History
My first steps at NES developing scene began in 2012, when I created huge cartridge, that was my Master of Thesis at High School. It was based on Xilinx XC3S400 (Spartan 3) kit. I implemented support for over 95% games, including mappers like MMC5, VRC6. Unfortunately, complex design and huge size and also second faculty made me abandon this project.


Few years later I came up with the idea of creating simpler cartridge - based on Xilinx XC9572XL chip - 72 macrocells (more info here: http://www.elektroda.pl/rtvforum/topic3094839.html)

The aim was to support: Contra Function 168-in-1 multicart, Golden 5 / 4 (Camerica's 5-in-1 and 4-in-1 multicarts) - mapper Camerica #71 & #232) and UNROM. The common for all those games is to contain 8 KB CHR-RAM. Later I've included support for NROM games, which in short was just a modification that after selecting game from menu, but before leaving control to it, the cartridge's software preprogrammed CHR-RAM with graphics of this game (NROM games contain 8 kB ROM with graphic data). Later, after updating SRAM from 6264 (8 kB) to 62256 (32 kB) and connecting two highest address lines to FPA, I could support also CNROM games. Next modification was to add MMC1 mapper support (but only for games that use 8 kB CHR-RAM). Later, by adding 8 kB PRG-RAM mapped at $6000-$7FFF I was able to support MMC1 games with additional RAM, like Legends of Zelda, Dyna Blaster. Adding support for MMC1 games with CHR-ROM and MMC3 mapper (which is unfortunately majority of games) was not possible due to insufficient number of macrocells in CPLD and also lack of I/O pins - all of pins has been already used. I had to also do some hacks, like changing obvious multiplexation formula (in VHDL) from: Y <= A when in = '0' else B
to Y <= A when in = '0' else 'Z', with Y being pull-up to B with external resistor.

Unfortunately, my source of XC9572 chips was ended and availability of these chips in Poland in rational price was als limited. I tried to order them FOUR times from aliexpress, each time the seller said the chips were bad or just the parcel did not arrived (buying other things from Aliexpress worked great for me). So I had to search for some kind of alternative.

Construction - beginning, first troubles and first milestones
I tried to buy similar CPLS chip from Altera - Max II, which contains more macrocells (192) and around 2 times more I/O pins. Despite fact that Altera's chips have more dense package (TQFP100) than Xilinx (PLCC44), I found soldering Altera easier and faster because I can use flag soldering tip and solder all legs in one phase, instead of soldering them separately like in Xilinx.


After few tries with those chips I had mixed feelings - the same logic structure, that in Xilinx was fitted in 60 makrocel, needed 120 macrocells in Altera. One macrocell is the most basic capacitance unit in CPLD/FPGA circuit that allows storing one bit of information or controlling one output. I had to change my style of describing logic. In Xilinx I was trying to use as less registers as possible - for example by using alias function or shift registers instead of counters. Unfortunately those tricks in Altera lead to weird results - sometimes formula than might seem to be easier, was translated to larger amount of macrocells than more complex formula. I was using Quartus 9 at first, then I migrated to Quartus 13 and some problems were solved, some were still happening - for example slight change in code unrelated to SD card support leaded to compatibility issues with them, but changing `Fitter Seed` to different value canceled these problems.
When I finished MMC1 mapper implementation and was able to support CHR-ROM games and then finished full MMC3 mapper support (CHR-ROM + scanline counter), I was unable to get in limit of the available amount of macrocells. Applying various kind of optimization bring me to success - currently 95% of total chip resources are used.


MMC3 mapper - scanline counter
The next milestone problem was to add support to MMC3 scanline counter - some kind of unique add-on that enriched games with possibility to notify CPU using interrupt that rendering scanline (horizontal line of image) with given number has just been started. This is very useful when determining proper time to switch nametables or tile set, for example during status bar display or when more complex screen need to be rendered.


My knowledge about MMC3 specification is gained from nesdev.com - the scanline counter is clocked by rising edge of PPU's A12 signal, however some very quick successive edges need to ignored.

Slight modification of moment in time that the interrupt is fired lead to proper picture displaying. However, there were still issues in some games that resulted in image shaking. Testing on famiclones with integrated circuits gave better result (less shaking) that on those with blob-tops. I think that longest tracks in PCB with DIL chips causes larger capacitances on those tracks with respect to ground and longer capacitances do not allow quick spikes to be propagated. After applying my own-invented analog filter (additional components on cartridge) + digital filter (additional logic in FPGA), the games started to look exactly like in emulator. Comparing my own implementation of MMC3 with the AX5208 chip (this is DIL40 chips that is MMC3 mapper) I can honestly say that my implementation is ideal - image is as good as in emulator.

Left image - AX5202P implementation - should be good, but image is shaking and interrupt is not fired in correct time. Right image - my own implmenetation - ideal gameplay.


Micro SD cart support
MicroSD cart support is done by:
- entity in FPGA that is responsible for converting single byte, sent by console's CPU into serial 8 bit communication done via SPI (this block was written in extreme optimal way to be fast and not consume more macrocell - it is clocked by clock from console),
- lots of lines of code written in 6502 assemler, responsible for communication with sd cart (detecting presence and type of cart, sending packets to cart),
- much more lines responsible for detecting partition, listing directories, reading files, traversing FAT entries (full FAT16/32 support, cluster size from 512 bytes to 64 KB), full VFAT Long File Name Entries.
All those elements were written by me from scratch. SD cart support (earlier: MMC cart) were written by me in 2012 during writing my Master of Thesis - at that time I had only MMC cart. Later, when I gathered some SD cards to test (<= 2 GB) I found out that they works fine without any changes in communication. Just after testing larger SDHC >4GB cards I found out they use different addressing mode - block number, instead of 0, 512, 1024 like on MMC is set 0, 1, 2, 3 (which is logical because block number is 32 bit number and the largest cart that can be addressed using old method is 4 GB).

Also, I had couple of 4 GB cards (mainly made by SanDisk company) that were causing troubles in communication, when much larger 32 GB Kingston card worked fine.

Slight protocol modification that consited in adding additional idle clock cycles before each packet bring me to success.

Optimalizing loading game time
Initially, game loading time was not satisfacting. For example Contra Function 168-in-1 multicart took 2 minutes to load. During loading game time:
- flash memory is erased (few seconds),
- portion of game program code is being read from selected ROM from SD cart sector-by-secttor and PRG-ROM memory is being programmed with this data,
- portion of game graphics data is being read from selected ROM from SD cart sector-by-secttor and CHR-RAM memory is being written with this data.

Initially, writing algorithm was simple: read single byte, program it and then check if:
- reading next sector is neccessary?,
- switching to next memory bank is neccesary?
- is it end of programming?
If none of above, just read next byte and do another check, et cetera. Those series of checks after each byte reading was not very efficient. I remember spending one of evenings on thinking how to modify that. Replacing byte-by-byte algorithm by block-by-block (where one block is portion of 256 or less bytes to be programmed at once) would increase speed. Hovewer, before each block programming, its size need to be calculated and stored in Y register and then the main programming loop might look like:

Even if calculating block size is not trivial and short, this algorithm has the advantage that each iteration of the loop above is very fast. But can it be speed up even more? Yes - because the whole programming routine is placed in RAM (it is impossible to both - program ROM and execute code from it), we can change the long, 5-cycle opcode of indirect read-write by zero-page pointer and Y register `lda (ptr_src), y` into absolute opcode `lda $ffff, y`, where $ffff address will be changed in RAM before each block-program algorithm start. On each loop we gain 1 extra cycle on read and 1 on write, and there are up to 256 read-write cycles, so this will be faster by 512 cycles.

Programming Super Mario Bros 3 game (256 KB PRG-ROM + 128 KB CHR-ROM): 17 seconds:

Zoom showing what parts it consists of:

More zooming showing detailed sector operation:

Comparing with CHR-RAM - writing to CHR-RAM is faster than programming PRG-ROM because it is 1 cycle instruction in contrary to 2 cycle and then polling PRG-ROM.


Additional mappers
Adding support for additional mappers is not possible due to insufficient number of macrocells left in FPGA. Although, the cartridge PCB was projected in such manner that all CPU's address lines are wired to CPLD. Maximum granularity of PRG-Bank switching is 8 kB, CHR bank: 1 kB. This can be used to adding support for almost any other mapper in place of one of the currently implemented ones, for example VRC6 could be done instead of mapper 15/232 and maybe some others. Of course MMC5 is out of reach due to the lackness of external 1 kB of dual-port SRAM.

Conclussion
After doing prototype that was working 100% as expected I thought of making more units for sale as there is lack of programmable cartridges for famiclone consoles on the market (at least in Poland). Hard to buy and expensive competetive product (everdrive) is not in the reach of many people, so my project might be revolution - I made a lot more PCBs for each of you that is reading that!




Promotion movie - english subtitles available:
[youtube]https://www.youtube.com/watch?v=NnNOtOE3YIQ[/youtube]

------------------------------------------------------------
KrzysioCart Micro SD - FAQ:

1. How to order:
Feel free to send email at: krzysiocart@gmail.com

2. What is the price, what is contained in set
Price is 250zl (65$) with included shipping to Poland. Shipping to other countries: + 5$,
The set contains of: PCB with shell (color can be chosen) + 4 GB micro SD card (random manufacturer) + MicroSD USB cart reader (random manufacturer and design)
Paypal payment accepted! I've sold a lot of those devices and no problems were encountered.

3. What games are supported?
Mapper #0 (NROM), #1 (MMC1), #2 (UNROM/UOROM), #3 (CNROM), #4 (MMC3), #7 (ANROM/AOROM), #15 (Contra 100/168-in-1), #71 (Camerica), #232 (Camerica Quattro).
Cart contains 1 MB PRG-ROM + 256 kB CHR-RAM/ROM + 8 kB PRG-RAM
No 4 screen mirroring or battery backed up RAM is supported.

4. Will it work on my console??
The cartridge was tested on the following console models:
- MT777DX
- IQ502 rev2/3
- SP60 (version based on integration circuits),
- RINCO (Thompsonic)
- two blob-top consoles (a'ka NOC = Nes on a Chip).
and no problems were discovered. I cannot guarantee that it will work on every one famiclone on Earth, because manufacturers are using different tricks for cutting-off price, which result in less compatibility, like replacing 7805 voltage regulator with zener diode, bypassing SND-OUT/IT pins from cart connector, bypassing CIRAM-!CE pin from cart connector. It should work on 99% of consoles from market. The cartridge does not draw a lot of current so it should also work on hand-held portable famiclones! After putting it on 60-to-72 pin adapter (with CIC), you can even play in on NES.

5. Is it safe for my console?
Yes! The cartridge was made out of 1 mm thickness PCB, so it wont expand the pins on your connector. Well fitted shell holds the cart firmly in the connector. I included voltage translating buffers for converting 5 V logic signals (from cartridge connector) to 3.3 V logic for low-voltage chips (memories, CPLD). It is protecting your console and the cartridge itself and is not driving any additinal current, like for example on cheap ali-express carts, which use 3.3 V memories connected to 5 V using zener diode (or even worse - without it) and driven with 5 V logicw ithout any series resistors limiting clamp diodes current

6. Will any larger memory card be working?
All microSD cart up to 32 GB should be working fine, as long as it is formatted as FAT16 or FAT21 with cluster site from 512 bytes to 64 KBs. Larger cards needs to be formatted in different filesystem and they are not supported at the moment. Cart must be capable of communicating over SPI. Some cards (SanDisk) has non-standard SPI mode and might cause troubles, which was taken into account during construction. Most of the card will be working fine

7. Why game XXX is working correctly on emulator, but at this cartridge does not work at all/has garbage graphics/has no graphics at all?
Generally, emulators:
i. is trying to idealize the surrounding environment, for example: they fills the whole RAM at startup with zeros,
ii. they block unallowed game operations, like for example blocking game's writes to CHR memory when game declares it uses CHR-ROM memory as graphics,
iii. they try to fix invalid NES headers, like when NES header declares that game uses 128 kB CHR-ROM and game is trying to use graphics past 128 kB bank, it will be wrapped modulo 128.

First case is mainly about unlincensed (homebrew amateur) games, whose creators were not testing them on real hardware. If that happens, please contact game developer for issuing game fixing.
Second case is about games like Doki Doki Amusement Park, Krusty's Fun House - those games might ovevwrite some tiles used in title screens as they try to write to CHR memory despite using CHR-ROM.
Some homebrew games (especially those from Shiru - Alter Ego, Zooming Secretary) have invalid initializing memory function which fills whole CHR memory with zeros. Those games use CHR-ROM, but on real hardware where CHR-RAM is used in place of CHR-ROM, all game graphics will be destroyed and changed to black colour. There are fixes to those games already available at nesdev.com

8. Why there is no progress bar during loading game, just the blinking screen?
Console processor, during programming PRG/CHR memory is changing memory banks extensivelly, so trying to display something would lead to the need of reloading tiles to next bank, which would cause slowing programming process. Also when programming CHR, Picture Processing Unit in console cannot display anything.

9. Is that all legal?
According to law, game ROMS are copyrighted as other computer programs. It is lawful to have ROM only of those games that you have original cartridges (backup). Micro SD cart, included with this cartridge is blank - the owner is liable for putting only those games on it that he is able according to law. However, except official Nintendo's copyrighted games, there are hundreds of free home-brew games made by fans and enthusiasts of NES.

Looks cool! One minor nitpick I have is that the loading screen looks glitchy because of that white line that shows up whenever the color changes, which I'm guessing is there because the palette is changed mid-frame. Would it be possible to code that part so that the color change happens during vblank?

Anyway, is this gonna be a product available to the general public? If so, how much will it cost?

Why 8K?

My eyes opened wide when I saw that this was probably the first CF or SD based flash cart that can run 1 MB PRG ROM games. Action 53 volume 3 is 1 MB and on a mapper comparable in complexity to MMC1 (which currently is supported) that is a superset of UNROM (supported), CNROM (supported), and ANROM (supported). I imagined it could be the first flash cart to run Action 53 volume 3, as the competition can't because their PRG ROM capacity is only half that.

But then I saw it has only 8K CHR RAM, and I felt a sinking feeling. One of the games on this volume is a CNROM with 16K of CHR data, and it can't go into the CHR ROM because the menu engine is designed for CHR RAM. It also means no chance to eventually run Videomation (CPROM, 32K PRG ROM, 16K CHR RAM) or The Curse of Possum Hollow (MMC3, 512K PRG ROM, 32K CHR RAM).

The WRAM is also 8K. This means no Koei sims (MMC1, 8K VRAM, 16K WRAM) and no PR8 by Neil Baldwin (MMC1, 8K VRAM, 32K WRAM).

Very nice.

To be honest, the PRG-ROM capacity is 4MB, all address lines are wired up to FPGA so it can implement really big games (on current supported mapper set, the biggest game is 168-in-1 Contra Function with 1 MB PRG)

The CHR-RAM capacity is 512 KB, however MMC3/MCM1 support only 256 KB CHR-ROM or 8 kB.

WRAM capacity is 32 KB, but also MMC1/MMC3 games dont need more than 8kB (except modified MMC1 games which uses high CHR address lines for PRG-RAM bankswitching, but there is trouble with detecting them so i simply ommited them)

So, the cart is physically prepared for supporting all possible kind of game (except MMC5 with external SRAM). Just matter of implementing proper mapper in VHDL.

For the sake of homebrewing, I think hardware makers should unlock any features that don't break existing software. Artificially locking the hardware to the scope of what commercial games are known to need makes it seem like your product is meant for piracy rather than encouraging innovation in homebrewing, which is a shame. In short, please don't design your products around the "no games make use of this" mentality.

There's nothing preventing the MMC3 from accessing up to 256KB of CHR-RAM, since that's how much CHR-ROM it supports. It just so happens that no commercial games ever used more than 8. Just think about the cool dynamic graphics and animations new programs could have if they had access to the full 32KB! Things like 3D graphics, FMV video, extra smooth character animations... But no, let's limit the hardware to what SMB3 and Kirby need.

Thanks for clarifying.


The MMC1 or MMC3 only outputs address values. It doesn't care whether the address is going to a ROM or a RAM. So if someone were to rewire a TGROM board to use a 62256 (32Kx8 SRAM) and run wires from CHR A13-A14 out of the MMC3 to A13-A14 on the memory, all 32K would be usable, and it could run The Curse of Possum Hollow. Games using large CHR RAM can be detected with NES 2.0 headers.


Games using large WRAM can be detected with NES 2.0 headers. This doesn't include anything using MMC3 because it can't switch WRAM. But it includes Koei's SOROM games, SXROM games by Squaresoft and Neil Baldwin because of the repurposed CHR address lines. It also includes a forthcoming Z-machine interpreter that uses FME-7 because FME-7 can switch RAM at $6000 the same way it switches ROM at $6000.

If you do plan to mass-produce this, do you plan on having both 60- and 72-pin versions?


Perhaps the argument is that existing games unaware of large RAM may rely on being able to, say, write to one bank and read the same data out of other banks. But existing games that depend on this won't have NES 2.0 headers, in which case the mapper can assume an appropriate default RAM size. Homebrew will have an NES 2.0 header that specifies how many high address lines on the RAM to use.

Looks cool. Since my powerpak stopped working and I never got any news when sending it for repair I guess I'll eventually have to aquire something else - this looks like a solid replacement for it. It being in famicom format is nice, too. (I have adapters for both ways so I don't really care).

That's a really cool project. I like how it's home made. What do you think it cost for you in parts and materials for each cartridge?

That's great!!

And that's how it is implemented right now - if NES header says it is CHR-ROM, i am just filling CHR-RAM with the tiles. The game later can still switch bank or even try to write to modify tiles.

Unfortunatelly that is no good because I found out that some games (Krusty's Fun House, Trolls In Crazyland), which use CHR-ROM, still writes to to the $0000-$1fff, which makes title screen in them garbled a little bit (tiles are overwritten)

Other games I know of that attempt to overwrite CHR ROM include B-Wings, Concentration Room, early games by Shiru (LAN Master, Lawn Mower, Zooming Secretary), and MineShaft by Nioreh (which uses the same runtime library version as Zooming Secretary). I've started a list of them on NESdev Wiki; can you think of others?

Can't you just prevent writes from going through if the header indicates the use of CHR-ROM? I'm pretty sure that the PowerPak and the EverDrive do that.

That's a start. But some mappers need more sophisticated write enable logic. Pinbot and High Speed are on TQROM, which has both CHR ROM and CHR RAM. (Banks 0-63 are ROM, and 64-71 are RAM.) So do a bunch of games from China.

True.

Yup, that is right - the color is changed without respect to the VBLANK. I was quite curious why this happened, I am not master at CPU-PPU interaction in NES. But i did not want to wait for VLANK because that could slighty prolonged the programming time.
I was also considering adding some kind of progress bar - that could be possible when programing PRG-ROM, but impossible when writing CHR-RAM (unless i would program it only in VBLANK which would take 100 times longer).
[/quote]


Yea, the product is available for sale - the price, including delievery in Poland is 330 PLN (around 85 USD). The price includes the cartridge PCB, cartridge shell, 4 GB Micro SD card and USB-MicroSD reader for putting roms into card.

The price will probably be the same for the whole Europe, but overseas delievery might be quite more expensive. Also, which I did not mention, the cartridge has possibility of firmware update - just puttin newer version on SD card and chosing it in console like ordinary rom file.

More mapper support is not planned, as I was intendent to concentrate only on most popular mappers. Also, the choosen FPGA chip is 95% used.

Feel free to write: krzysiocart(at)gmail.com for ordering or other private inquiries

You don't need to stop everything and wait for vblank, but instead of changing the palette whenever, you could buffer the new color value in a variable, and in the NMI handler use that variable for the actual palette update. This way the code can signal that it wants a new color to be displayed at any time, but the actual change will only happen during vblank.


If you could keep track of time somehow (cycle-based mapper IRQs?) you could have the screen fill with color from the bottom up. If you don't have the means to time raster effects, you could increase the speed of the color animation according to the progress. To avoid epilepsy issues you probably shouldn't flash different colors rapidly though, but maybe have different colors fading in and out, slowly in the beginning and faster towards the end.


Being cheaper than the PowerPak and the N8 is definitely an advantage.


Oh, too bad. Can users experiment with making their own mappers, for homebrewing purposes?


Are all the mappers loaded at all times?

The code that programs and erases all memories is copied to internal console's RAM and then executed from it, because ROM cannot be read (fetching opcodes) and programmed at the same time. So NMI have to be disabled. I could potentially stay with PRG programming routine in RAM and move CHR-RAM writing to be excecuted in ROM and the NMI trick could work. But the way it is done is simpler, but thanks for pointing that - I will consider it in next firmware release.


Yea, the time programming PRG and writing CHR takes can be estimated easily, I even did it, so I might display time game takes to load before choosing it.


Yea, all the mappers + mapper for showing menu (which also contains code for accessing SD-card) are preprogrammed in FPGA. I cannot distribute the code and let others modify it, as it would lead to appear this cartridge at aliexpress soon quickly.

Why would code in RAM prevent NMI? You can easily point NMI to RAM.

NMI vector is sitting at $fffa-fffb. This area is always mapped to ROM,

Yes, but what it points to can be in RAM. Many NES games do that.

The CPU still needs to fetch the vector. If the menu ROM isn't mapped at $FFFA-$FFFB, from where will it fetch the vector?

Is it fetched each time? I thought it was grabbed once at bootup.

No, it is not stored anywhere, it is fetched every time. You can have different NMI vectors in different banks. (Same goes for IRQ and Reset.)

If you've got to execute PPU updates entirely from RAM you probably need NMI off and just do it by polling? The polling will add some waste time (and occasionally an extra frame), but you wouldn't have to run it every frame, only as often as you want to update the status bar.

I think the issue you're missing is that you CANNOT read valid data from a flash chip while it's being programmed. While waiting for the flash chip to complete the write, reading from it will invert some bits, and toggle others of true data. When that stops happening, it's the flash chip's way of saying when the byte(s) programming is completed.

So you can't read from flash while programming, which means you can't execute from it. And since you never know when NMI is coming, you can't be sure your not in the middle of a byte programming operation which means the CPU can't fetch the NMI vector from flash. Well it can try, but it will get a corrupted vector.

The only way around this would be if the menu/SDcard mapper was able to place PRG-RAM in the last bank during programming operations and fetch valid vectors from PRG-RAM.

I updated the first post with more detailed description.

This cart, due to its huge PRG-ROM size of 4MB, would have the potential to play games that the EverDrive N8 and NES PowerPak, with their 512KB PRG-ROM limits, cannot. Of course you would need to reporgram the CPLD to support different mappers. I understand that it cannot fit more mappers because the macrocells and logic elements are almost completely used up, but can it be reprogrammed by software running on the SD card to support different mappers? Action 52 (Mapper 228), Final Fantasy VII and Pokemon Yellow (Mapper 163) and Action 53 and Streemerz (Mapper 28) all would be possible. An advantage for sure (sales!) for some who want to play larger games on real hardware.

Wait, N8's page says it supports iNES Mapper 015, and that page says it's only 512K, which fits in either…and it's such a simple mapper…

Oh. 100-in-1 Contra Fn. 16 and 168-in-1 are indeed 1MB. *fixes wiki…ed: insofar as ROM size is concerned*

I'm guessing mapper 15 might have also been used for some other smaller game.

Mapper 15 is the board name for Contra-100 in-1 for NES. The way I implemented it is exactly how it is described in nesdev's wiki.

Contra-168-in-1 (which is famiclone multiset) was for some reason also assigned mapper 15, but this game does not use the all mapper 15 banking modes. Also, this game in some banking modes protects its CHR-RAM from writing (which was not mentioned in nesdev's wiki). If this is not implemented, Urban Champion will have garbled letters on title screen.

Bio Hazard is also assigned mapper 15, but it hangs just after gameplay starts. There is bug-free version which is assigned mapper 227.

Some other chinese games from the same company as BioHazard has also assigned mapper 15.

Is there a demo code(verilog or vhdl) to read/write SD cart.