It is currently Fri Nov 24, 2017 11:44 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 41 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Wed Nov 11, 2015 12:38 pm 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10118
Location: Rio de Janeiro - Brazil
raydempsey wrote:
I'm not worried about putting it on a cart later because I can't profit off of my game because of the NFL trademarks.

So if you can't sell the game and the existing Flash carts don't have good support for the MMC5, are people stuck with running it on emulators unless they decide to build a cart themselves from an MMC5 donor?

Quote:
The instructions says that for CHR MODE 3, I will need to write to $5130 for the upper bank bits and between $5120-$5127 for the lower bank bits. So to switch $0000-$03FF bank 12C, would I have to write #$01 to $5130 first then #$2C to $5120?

Yes, that seems correct. There's no "master banking" like I thought there was, so you can freely mix and match tiles from all 1024 banks.

Quote:
If I have 1024K CHR ROM, which 16384 tiles do I have access to?

Well, then $5130 starts to act as a master bank selection register. It selects which group of 16384 tiles will be used, and you can't mix tiles from different groups. I'm not sure how that affects sprites, though...


Top
 Profile  
 
PostPosted: Wed Nov 11, 2015 1:07 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5838
Location: Canada
tokumaru wrote:
raydempsey wrote:
I am looking more closely at mapper 005 MMC5.

One of the problems with the MMC5 (the NES super mapper, yay!) is that it's not currently available for making new carts. AFAIK, the only way is still to use donor cartridges. The other problem is the lack of full support for it in Flash carts.

INL offers a partial MMC5 mapper, currently. I'm not sure which parts that includes. If you talked to him you might be able to work out whether the subset you need can be supported by it.

Though, to tell you the truth, the more somebody asks about MMC5, the less likely I think they are ever going to finish an NES game. :wink:


Top
 Profile  
 
PostPosted: Wed Nov 11, 2015 1:37 pm 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10118
Location: Rio de Janeiro - Brazil
rainwarrior wrote:
Though, to tell you the truth, the more somebody asks about MMC5, the less likely I think they are ever going to finish an NES game. :wink:

I think almost everyone that gets started on NES development becomes fascinated with the MMC5. We have tons of topics where people ask "Is this, this and that possible?" with answers like "Yes, if you use the MMC5", so this is only natural. I know I really wanted to use the MMC5 at one point.

My opinions about mappers changed a lot as time passed. Being obsessed about complexity didn't get me anywhere, and the more I'm able to simplify things, the closer I think I am to reaching my goals. Aiming for simplicity doesn't necessarily mean dumbing things down or giving up features though, it's more about asking yourself questions like "do I really need this?" or "is this the best way to do this task?". Sometimes we assume that one particular path is the way to go, and the stubbornness to remain on that path prevents us from making as much real progress as we'd like.

I started making a game for the MMC3, which is what a lot of iconic NES games use, but now I'm fairly happy with the incredibly simple BNROM mapper. In retrospective, the only significant thing I had to give up was the scanline counter, which was only really necessary for a couple of non-essential visual effects, which weren't really worth the complications of using a more advanced mapper. I can still have some of these effects, using sprite 0 hits, sprite overflows and timed code, so I got over that pretty quickly. Everything else from the previous design is intact, even if implemented a little differently.

I simplified things a lot on the engine side too... Previously I believed that I'd only be able to max out the VRAM update capabilities of the NES if I used dedicated NMI handlers and update routines, but recently I was able to come up with a very optimized general VRAM update method, which can be used for the entire game. I literally replaced 20 subroutines with a single one, which is slightly more complex than the average subroutine it replaced, but still, it does the job of 20!

It frustrates me a bit that I was never able to accomplish anything significant in the field of NES development, so hopefully this new line of thinking will get me somewhere sooner. I am making progress faster than I used to, and what I'm creating does feel more robust and stable, so those are good signs.


Top
 Profile  
 
PostPosted: Wed Nov 11, 2015 2:03 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19256
Location: NE Indiana, USA (NTSC)
There are four sets of tiles:
  1. Left end zone
  2. Right end zone
  3. Midfield logo
  4. Field graphics that are not left end zone, right end zone, or midfield logo, such as lines and yard numbering
Sets a-c fill 4K, leaving no room for d unless a, b, and c are swapped in on demand.


Top
 Profile  
 
PostPosted: Wed Nov 11, 2015 2:13 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6454
Location: UK (temporarily)
tepples wrote:
raydempsey wrote:
They do. They're worth it. Makes the game more NFL.
EA WILL SUE
Actually, the NFL will.

They're astoundingly aggressive about protecting their trademarks, which includes all the team names as well as all the logos.

They might not care in the case of a single non-reproduced homebrew, but if you ever want to sell it that won't go well.


Top
 Profile  
 
PostPosted: Wed Nov 11, 2015 2:30 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5838
Location: Canada
I think it's pretty clear that OP is unconcerned with the NFL trademark issue.

They've already been doing it for years at: http://tecmobowl.org/


Top
 Profile  
 
PostPosted: Wed Nov 11, 2015 2:32 pm 
Offline
User avatar

Joined: Sat May 31, 2014 4:12 pm
Posts: 139
tepples wrote:
There are four sets of tiles:
  1. Left end zone
  2. Right end zone
  3. Midfield logo
  4. Field graphics that are not left end zone, right end zone, or midfield logo, such as lines and yard numbering
Sets a-c fill 4K, leaving no room for d unless a, b, and c are swapped in on demand.


You are correct but I am going to see how MMC5 treats me and I think that makes my task simpler. I understand that there is an art to simplicity but the point of me making this football game is to have no expense spared on making it the best NFL game playable on an NES. It will likely take years to develop so I'm not in a rush to put in on a cart.

I am converting my MMC3 to MMC5 and I figured out bank switching but not sure how I write one of the 16384 tiles to the nametable. After that is figured out, I think I'm off to the races.


Top
 Profile  
 
PostPosted: Wed Nov 11, 2015 7:08 pm 
Offline
User avatar

Joined: Sat May 31, 2014 4:12 pm
Posts: 139
rainwarrior wrote:
I think it's pretty clear that OP is unconcerned with the NFL trademark issue.

They've already been doing it for years at: http://tecmobowl.org/


I always wondered how the Tecmo fans could legally sell Tecmo Super Bowl carts with updated rosters. They've been doing it for years.

I have been experimenting and I still can't figure out how to write to a nametable using MMC5. I successfully bank switched tiles and got my palettes in order with writes to PPU $3F00 but I don't know how to write to a nametable. Since MMC5 allows me to pick any tile from a 256K super bank, then I must have to make an additional write somewhere because writing a single value to $2007 won't be enough. What do I do?

I attached my program so you can see what I have so far. Maybe that will help.


Attachments:
NFL.chr [256 KiB]
Downloaded 40 times
NFL.asm [11.68 KiB]
Downloaded 43 times


Last edited by raydempsey on Wed Nov 11, 2015 7:16 pm, edited 1 time in total.
Top
 Profile  
 
PostPosted: Wed Nov 11, 2015 7:09 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5838
Location: Canada
raydempsey wrote:
I always wondered how the Tecmo fans could legally sell Tecmo Super Bowl carts with updated rosters. They've been doing it for years.

The answer is simple: they haven't. They have, however, been selling them illegally, which is often very easy to do.


Top
 Profile  
 
PostPosted: Wed Nov 11, 2015 7:12 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19256
Location: NE Indiana, USA (NTSC)
Because nobody has notified Tecmo Koei, NFL, and NFL's present exclusive licensee EA.

Yet.


Top
 Profile  
 
PostPosted: Wed Nov 11, 2015 8:22 pm 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10118
Location: Rio de Janeiro - Brazil
raydempsey wrote:
Since MMC5 allows me to pick any tile from a 256K super bank, then I must have to make an additional write somewhere because writing a single value to $2007 won't be enough. What do I do?

The MMC5 has 1KB of RAM mapped at $5C00-$5FFF, which is where the extended attributes go. The lower 8 bits go to the name table as usual ($2006/$2007 writes), but the expansion RAM can be addressed by the CPU directly. You also have to select the proper extended RAM mode (mode 1) through register $5104. Note that in this mode, according to the wiki, the extended RAM can only be written to during rendering, which is the opposite of regular VRAM, which can only be written to during vblank. Go figure.

Anyway, each byte there will provide 6 more tile index bits (for a total of 14 bits, allowing access to 16384 tiles) and 2 palette bits, allowing each tile to be colored individually.

Another important point is that since there are only 1024 bytes of expansion RAM, and each name table is 32 x 30 = 960 bytes long, the MMC5 doesn't have enough memory to extend the attributes of both name tables individually, so the same extended attributes are used for both name tables. You have to take this into account when scrolling.


Top
 Profile  
 
PostPosted: Wed Nov 11, 2015 8:34 pm 
Offline
User avatar

Joined: Sat May 31, 2014 4:12 pm
Posts: 139
tokumaru wrote:
raydempsey wrote:
Since MMC5 allows me to pick any tile from a 256K super bank, then I must have to make an additional write somewhere because writing a single value to $2007 won't be enough. What do I do?

The MMC5 has 1KB of RAM mapped at $5C00-$5FFF, which is where the extended attributes go. The lower 8 bits go to the name table as usual ($2006/$2007 writes), but the expansion RAM can be addressed by the CPU directly. You also have to select the proper extended RAM mode (mode 1) through register $5104. Note that in this mode, according to the wiki, the extended RAM can only be written to during rendering, which is the opposite of regular VRAM, which can only be written to during vblank. Go figure.

Anyway, each byte there will provide 6 more tile index bits (for a total of 14 bits, allowing access to 16384 tiles) and 2 palette bits, allowing each tile to be colored individually.

Another important point is that since there are only 1024 bytes of expansion RAM, and each name table is 32 x 30 = 960 bytes long, the MMC5 doesn't have enough memory to extend the attributes of both name tables individually, so the same extended attributes are used for both name tables. You have to take this into account when scrolling.


I'll experiment with that to see if I can get it going. From what I'm reading here...
"The MMC5 has an 8-bit incrementing IRQ counter that watches the PPU as it renders, and counts each passing scanline. When the counter reaches the desired IRQ scanline (specified by the $5203 register), it signals an IRQ. It also uses an In Frame signal which can be read from $5204.6 in conjunction with the 8-bit counter. Games can use this signal as an indication of whether or not the PPU is currently in rendering time."
Regarding $5204:
When set, the "In Frame" signal specifies that the PPU is currently rendering a scanline. It also plays a role in how IRQs are generated.
The IRQ Pending flag may be raised even if IRQs are disabled.
Any time this register is read, the IRQ Pending flag is cleared (acknowledging the IRQ).


Top
 Profile  
 
PostPosted: Wed Nov 11, 2015 9:02 pm 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10118
Location: Rio de Janeiro - Brazil
I think it's nice that the mapper provides a way for you to tell whether the PPU is rendering or not, but that's not what worries me about the extended attribute mode, since there are other ways to detect the start of rendering. It's that you're changing the data as it's being used to render the picture that bothers me. If you need to update a column of tiles that spans the whole height of the screen, there's no safe time to do it so you avoid seeing half old data and half new data on the screen. You probably need a status bar or something of the sort to divide your screen in different areas, so that when one area is being rendered, you're updating the other.


Top
 Profile  
 
PostPosted: Wed Nov 11, 2015 9:36 pm 
Offline
User avatar

Joined: Sat May 31, 2014 4:12 pm
Posts: 139
tokumaru wrote:
I think it's nice that the mapper provides a way for you to tell whether the PPU is rendering or not, but that's not what worries me about the extended attribute mode, since there are other ways to detect the start of rendering. It's that you're changing the data as it's being used to render the picture that bothers me. If you need to update a column of tiles that spans the whole height of the screen, there's no safe time to do it so you avoid seeing half old data and half new data on the screen. You probably need a status bar or something of the sort to divide your screen in different areas, so that when one area is being rendered, you're updating the other.


My program will have a status bar at the top of the screen. I still can't seem to figure out what code is needed to detect rendering. This is what I thought:

Code:
IRQLoop:
  LDA $5204
  CLC
  ADC #%01000000
  BEQ IRQLoop

After it exits the loop, then rendering has just begun. $5203 is not mentioned in my code. After the loop is exited, I begin my writes to the extended RAM. Still, my nametable is turning out to be a jarbled mess.


Attachments:
NFL-2.png
NFL-2.png [ 1.61 KiB | Viewed 1078 times ]
Top
 Profile  
 
PostPosted: Wed Nov 11, 2015 10:35 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3116
Location: Nacogdoches, Texas
You know, but speaking of row scrolling for a status bar, does anyone know of any NES games that scroll the BG every line at different speeds for a SF2-esque floor? That would look great for a football field, the field goal would have to be made out of sprites though. I assume raster splits are difficult on the NES due to the lack of HDMA or a scroll table? I always seem to hear about "sprite 0 hit".


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot], getafixx and 3 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