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

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderator: Moderators

User avatar
krzysiobal
Posts: 1037
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: KrzysioCart - Home made cartridge that support>80% NES g

Post by krzysiobal »

tokumaru wrote: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?
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]
Anyway, is this gonna be a product available to the general public? If so, how much will it cost?
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
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: KrzysioCart - Home made cartridge that support>80% NES g

Post by tokumaru »

krzysiobal wrote: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.
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.
I was also considering adding some kind of progress bar
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.
Yea, the product is available for sale - the price, including delievery in Poland is 330 PLN (around 85 USD).
Being cheaper than the PowerPak and the N8 is definitely an advantage.
More mapper support is not planned, as I was intendent to concentrate only on most popular mappers.
Oh, too bad. Can users experiment with making their own mappers, for homebrewing purposes?
Also, the choosen FPGA chip is 95% used.
Are all the mappers loaded at all times?
User avatar
krzysiobal
Posts: 1037
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: KrzysioCart - Home made cartridge that support>80% NES g

Post by krzysiobal »

tokumaru wrote: 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.
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.
I was also considering adding some kind of progress bar
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.
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.
More mapper support is not planned, as I was intendent to concentrate only on most popular mappers.
Oh, too bad. Can users experiment with making their own mappers, for homebrewing purposes?

Are all the mappers loaded at all times?
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.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: KrzysioCart - Home made cartridge that support>80% NES g

Post by calima »

Why would code in RAM prevent NMI? You can easily point NMI to RAM.
User avatar
krzysiobal
Posts: 1037
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: KrzysioCart - Home made cartridge that support>80% NES g

Post by krzysiobal »

NMI vector is sitting at $fffa-fffb. This area is always mapped to ROM,
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: KrzysioCart - Home made cartridge that support>80% NES g

Post by calima »

Yes, but what it points to can be in RAM. Many NES games do that.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: KrzysioCart - Home made cartridge that support>80% NES g

Post by tepples »

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?
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: KrzysioCart - Home made cartridge that support>80% NES g

Post by calima »

Is it fetched each time? I thought it was grabbed once at bootup.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: KrzysioCart - Home made cartridge that support>80% NES g

Post by rainwarrior »

calima wrote: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.
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: KrzysioCart - Home made cartridge that support>80% NES g

Post by infiniteneslives »

calima wrote:Yes, but what it points to can be in RAM. Many NES games do that.
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.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
User avatar
krzysiobal
Posts: 1037
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: KrzysioCart - Home made cartridge that support>80% NES g

Post by krzysiobal »

I updated the first post with more detailed description.
Great Hierophant
Posts: 780
Joined: Tue Nov 23, 2004 9:35 pm

Re: KrzysioCart - Home made cartridge that support>80% NES g

Post by Great Hierophant »

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.
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

Re: KrzysioCart - Home made cartridge that support>80% NES g

Post by Myask »

krzysiobal wrote: first and only cart that supports famous Famiclone multicart: Contra Function 168-in-1,
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…
krzysiobal wrote:
biggest game is 168-in-1 Contra Function with 1 MB PRG)
Oh. 100-in-1 Contra Fn. 16 and 168-in-1 are indeed 1MB. *fixes wiki…ed: insofar as ROM size is concerned*
Last edited by Myask on Fri Jul 28, 2017 5:53 am, edited 1 time in total.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: KrzysioCart - Home made cartridge that support>80% NES g

Post by tepples »

I'm guessing mapper 15 might have also been used for some other smaller game.
User avatar
krzysiobal
Posts: 1037
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: KrzysioCart - Home made cartridge that support>80% NES g

Post by krzysiobal »

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.
Post Reply