It is currently Wed May 24, 2017 1:02 am

All times are UTC - 7 hours





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

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 135
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 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 9643
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: 135
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: 411
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: 135
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: 411
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: 18338
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: 411
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: 5177
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: 1779
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: 135
Location: Poland
I updated the first post with more detailed description.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Yahoo [Bot] 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:  
Powered by phpBB® Forum Software © phpBB Group