It is currently Mon Nov 20, 2017 6:56 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 31 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Thu Apr 06, 2017 11:00 am 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 245
Location: Poland
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]

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


Top
 Profile  
 
PostPosted: Thu Apr 06, 2017 11:32 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10114
Location: Rio de Janeiro - Brazil
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.

Quote:
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.

Quote:
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.

Quote:
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?

Quote:
Also, the choosen FPGA chip is 95% used.

Are all the mappers loaded at all times?


Top
 Profile  
 
PostPosted: Thu Apr 06, 2017 12:01 pm 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 245
Location: Poland
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.

Quote:
Quote:
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.

Quote:
Quote:
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.


Top
 Profile  
 
PostPosted: Fri Apr 07, 2017 2:21 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 581
Why would code in RAM prevent NMI? You can easily point NMI to RAM.


Top
 Profile  
 
PostPosted: Fri Apr 07, 2017 3:05 am 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 245
Location: Poland
NMI vector is sitting at $fffa-fffb. This area is always mapped to ROM,


Top
 Profile  
 
PostPosted: Fri Apr 07, 2017 10:36 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 581
Yes, but what it points to can be in RAM. Many NES games do that.


Top
 Profile  
 
PostPosted: Fri Apr 07, 2017 10:39 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19234
Location: NE Indiana, USA (NTSC)
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?


Top
 Profile  
 
PostPosted: Fri Apr 07, 2017 10:41 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 581
Is it fetched each time? I thought it was grabbed once at bootup.


Top
 Profile  
 
PostPosted: Fri Apr 07, 2017 10:47 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5822
Location: Canada
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.


Top
 Profile  
 
PostPosted: Fri Apr 07, 2017 10:51 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1924
Location: WhereverIparkIt, USA
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


Top
 Profile  
 
PostPosted: Mon Apr 10, 2017 5:54 pm 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 245
Location: Poland
I updated the first post with more detailed description.


Top
 Profile  
 
PostPosted: Thu Jul 27, 2017 11:23 pm 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 620
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.

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog


Top
 Profile  
 
PostPosted: Fri Jul 28, 2017 5:36 am 
Offline
User avatar

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

Top
 Profile  
 
PostPosted: Fri Jul 28, 2017 5:44 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19234
Location: NE Indiana, USA (NTSC)
I'm guessing mapper 15 might have also been used for some other smaller game.


Top
 Profile  
 
PostPosted: Fri Jul 28, 2017 3:24 pm 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 245
Location: Poland
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 31 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group