2014 NESDev Compo - Guidelines/Rules

Moderator: Moderators

Drag
Posts: 1286
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Re: 2014 NESDev Compo - Guidelines/Rules

Post by Drag » Sun Dec 15, 2013 12:27 am

I think dual pal/ntsc compatibility is more than sufficient for the purposes of this compo.

User avatar
tokumaru
Posts: 11465
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: 2014 NESDev Compo - Guidelines/Rules

Post by tokumaru » Sun Dec 15, 2013 8:08 am

SNES versions? Where did this nonsense come from?

User avatar
Punch
Posts: 346
Joined: Sat Feb 16, 2013 11:52 am

Re: 2014 NESDev Compo - Guidelines/Rules

Post by Punch » Sun Dec 15, 2013 2:13 pm

Hamtaro126 wrote:The better way is to change the NESDEV 2014 contest specs to use $FFB0-$FFDF for complete optional SNES or/and FDS header compatibility, and allow a certain range for extra vectors per system:

* $FFFA-FFFF for NES/FDS versions, (using one NMI only for FDS version, nulling $FFF6-$FFF9, SNES-specific vectors can be disabled or nulled)

* $FFE0-FFFF for SNES versions

* Can use replacements for SNES instructions as long as you do trickery such as the provided bankswitch rules as well as make your own macros for them, etc...

Edit: Added one!
What's with you and your crazy unattainable goals?
This is a block of text that can be added to posts you make. There is a 255 character limit.

User avatar
Hamtaro126
Posts: 763
Joined: Thu Jan 19, 2006 5:08 pm

Re: 2014 NESDev Compo - Guidelines/Rules

Post by Hamtaro126 » Sun Dec 15, 2013 5:45 pm

Punch wrote: What's with you and your crazy unattainable goals?
Read the lower parts of the opinion again, or to make it easier, and I quote:
Hamtaro126 wrote: Then again, The author chooses the rules... So it's optional to review
AKA SmilyMZX/AtariHacker.

User avatar
Punch
Posts: 346
Joined: Sat Feb 16, 2013 11:52 am

Re: 2014 NESDev Compo - Guidelines/Rules

Post by Punch » Sun Dec 15, 2013 6:19 pm

I would like to see a homebrew made with similar specs...
This is a block of text that can be added to posts you make. There is a 255 character limit.

User avatar
infiniteneslives
Posts: 2097
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: 2014 NESDev Compo - Guidelines/Rules

Post by infiniteneslives » Sun Dec 15, 2013 8:46 pm

Do whatever craziness you'd like with your own entry as allowed by the rules of the categories. The specifics Tepples provided were in regards to the multicart the games will be going on, not just for fun. Even I don't know what you're talking about... We can move that discussion to a different thread if you'd like to discuss it for future compos or something as those requests are outside the scope of what we've already determined for this years'. I'm not trying to be a jerk, just trying to stay on topic please.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

User avatar
Hamtaro126
Posts: 763
Joined: Thu Jan 19, 2006 5:08 pm

Re: 2014 NESDev Compo - Guidelines/Rules

Post by Hamtaro126 » Sun Dec 15, 2013 10:00 pm

I apologise deeply, I was also very SLEEPY at the time because it was overnight... This is one of the common problems anyone has.

But yeah, I'll go On Topic if I need to be in here.
AKA SmilyMZX/AtariHacker.

User avatar
infiniteneslives
Posts: 2097
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: 2014 NESDev Compo - Guidelines/Rules

Post by infiniteneslives » Mon Dec 23, 2013 11:31 am

I understand the holidays are upon us, but just checking to see if there's anything left to be resolved in order to kick things off next week?
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

User avatar
NESHomebrew
Formerly WhatULive4
Posts: 393
Joined: Fri Oct 30, 2009 4:43 am
Contact:

Re: 2014 NESDev Compo - Guidelines/Rules

Post by NESHomebrew » Mon Dec 23, 2013 9:34 pm

Yep, there are a few loose ends I've been meaning to post up here. Judging criteria/format, submission method, and registration. These will be posted before the new year. Most everything is ready to go, I just need to contact a few people before the information is all posted.

zzo38
Posts: 1050
Joined: Mon Feb 07, 2011 12:46 pm

Re: 2014 NESDev Compo - Guidelines/Rules

Post by zzo38 » Tue Dec 24, 2013 1:19 am

If it is a mapper 28 image, should the value written to its $81 register be done in the $FFD0-$FFF9 block, and writing that followed by jumping to the actual reset vector, being the only things done in that block?

I suppose that, if you are writing to the $80 register, the outer bank size should not be changed to larger than the allocated amount, and in such a case (or if the PRG bank mode is being changed), it will be necessary to provide the low bit of the outer bank number with your submission (only for 64K entries; it is unnecessary for 32K).

Does category 2 have PRG-RAM? I would think not, since category 1 doesn't have, presumably because it is using the cartridge which doesn't have PRG-RAM.

You say that for programs with a fixed lower bank, you should make $BFD0-$BFF9 to be unused. But, since it is possible to map the same bank to both 16K areas, might it sometimes be necessary, if such a thing is done, that $BFFC-$BFFD will also be unused (so that the RESET button will work)? If it is mapper 180 then probably it should contain the copy of the reset vector anyways (which will then be overridden, so your game shouldn't read it as data); if it is mapper 28 then it would be explicitly needed to mark this area unused (if you are switching banks in this way), since otherwise it is possible to store miscellaneous data in $BFFC-$BFFD due to the power on state of the game.

If the PRG bank mode is being changed at runtime, then it might be necessary for the areas $BFD0-$BFF9, $BFFC-$BFFD, $FFD0-$FFF9, all being marked as unused.

Is there any guidelines relating to input devices? I suppose it should normally be using the standard controllers, although you also said that since some games might use mouse connected to both NES ports, that the menu would have to deal with that too, so I suppose it is possible that some games might use that. I suppose it might be the good idea that category 1 and 2 programs should normally be made to support standard controller, and other device (zapper, mouse, keyboard) can be optional use (especially in case of a level-editor, keyboard/tape may be helpful); however, I don't know what your intention is specifically, so perhaps it would be good idea to clarify it, please.

The other thing I did not see mentioned, is whether or not mapper 28 has bus conflicts (but it is possible to write the program working either way, if necessary).

Just so you know, I do not have any intention to entry at this time (but clearly, it is possible to change my mind).
[url=gopher://zzo38computer.org/].[/url]

tepples
Posts: 21750
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 2014 NESDev Compo - Guidelines/Rules

Post by tepples » Tue Dec 24, 2013 7:06 am

If it is a mapper 28 image, should the value written to its $81 register be done in the $FFD0-$FFF9 block, and writing that followed by jumping to the actual reset vector, being the only things done in that block?
Mostly I'm concerned with being able to extract a working standalone ROM from the compilation. That'd probably be done by restoring the original reset vector and blanking $FFD0-$FFF9. It's only a few bytes, and you don't have to bean-count nearly as much on the NES as you would on, say, the Atari 2600.
I suppose that, if you are writing to the $80 register, the outer bank size should not be changed to larger than the allocated amount, and in such a case (or if the PRG bank mode is being changed), it will be necessary to provide the low bit of the outer bank number with your submission (only for 64K entries; it is unnecessary for 32K).
I see no reason to change the outer bank number while the game is running. You can swap 32K banks, or you can swap $8000-$BFFF, or you can swap $C000-$FFFF, with ordinary writes to reg $01. Back when Action 53 was using mapper 34, I was considering a standard method of passing a bank number translation table to games because that would have been needed for larger than 32K games. But now that games for popular discrete mappers (2, 3, 7, 34) run unmodified, I saw it as less necessary.
You say that for programs with a fixed lower bank, you should make $BFD0-$BFF9 to be unused. But, since it is possible to map the same bank to both 16K areas, might it sometimes be necessary, if such a thing is done, that $BFFC-$BFFD will also be unused (so that the RESET button will work)?
Technically this is true, but I see no real reason to "store miscellaneous data in $BFFC-$BFFD". You see even more exceptions than I do.
Is there any guidelines relating to input devices? I suppose it should normally be using the standard controllers
All entries, at least in judged categories, MUST be playable with standard controllers. And as far as I can tell, judging will be done on 72-pin consoles, which means 7-pin controllers, not 15-pin controllers. If you make a mouse or Zapper game, have it fall back to the controller, as I did in Thwaite and Zap Ruder, and as the developers of Baby Boomer, Operation Wolf, On the Ball, and Jurassic Park did. If you make a text adventure, you'll need to make it play smoothly with input menus like on the TI-83 or TI-89, because I don't think any judges will own a Famicom with keyboard. Consider something like Maniac Mansion, Deja Vu, or Princess Tomato.
The other thing I did not see mentioned, is whether or not mapper 28 has bus conflicts
It does not. The mapper 28 test tests this.

zzo38
Posts: 1050
Joined: Mon Feb 07, 2011 12:46 pm

Re: 2014 NESDev Compo - Guidelines/Rules

Post by zzo38 » Tue Dec 24, 2013 11:53 am

tepples wrote:Mostly I'm concerned with being able to extract a working standalone ROM from the compilation. That'd probably be done by restoring the original reset vector and blanking $FFD0-$FFF9. It's only a few bytes, and you don't have to bean-count nearly as much on the NES as you would on, say, the Atari 2600.
Ah, that is understood; in that case, you still need to provide the outer bank size so that it can be extracted (and, of course, the mapper numbers of each individual game).
I see no reason to change the outer bank number while the game is running. You can swap 32K banks, or you can swap $8000-$BFFF, or you can swap $C000-$FFFF, with ordinary writes to reg $01.
I understand that (and like you said it should never be changed); I am talking about the outer bank size (not outer bank number), though, if it is a 64K entry and you are changing it between 32K and 64K at runtime (probably not so useful, but it might be), or to change the bank mode (probably more useful than changing the bank size, but also might not be so useful); in addition, you might want the fixed lower bank to be bank 2 rather than bank 0 for some reason (maybe it makes the coding more efficient for your game, somehow). You could figure out with a debugger, what the low bit of the outer bank number will be, in such case (such a way would also override the outer bank number when making the compilation); once the standalone is extracted it will continue to work. Or the address of the outer bank number in the ROM could be provided if being writing as an immediate number not used for anything else.
You say that for programs with a fixed lower bank, you should make $BFD0-$BFF9 to be unused. But, since it is possible to map the same bank to both 16K areas, might it sometimes be necessary, if such a thing is done, that $BFFC-$BFFD will also be unused (so that the RESET button will work)?
Technically this is true, but I see no real reason to "store miscellaneous data in $BFFC-$BFFD". You see even more exceptions than I do.
I also see no reason to store data there, although maybe someone does, so that is the purpose why I would specify such a thing.
All entries, at least in judged categories, MUST be playable with standard controllers. And as far as I can tell, judging will be done on 72-pin consoles, which means 7-pin controllers, not 15-pin controllers. If you make a mouse or Zapper game, have it fall back to the controller, as I did in Thwaite and Zap Ruder...
Yes, this is what I thought and what would be good idea.
The other thing I did not see mentioned, is whether or not mapper 28 has bus conflicts
It does not. The mapper 28 test tests this.
Thank you; that is what I thought, but wasn't quite sure.
[url=gopher://zzo38computer.org/].[/url]

tepples
Posts: 21750
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 2014 NESDev Compo - Guidelines/Rules

Post by tepples » Tue Dec 24, 2013 1:06 pm

I am talking about the outer bank size (not outer bank number), though, if it is a 64K entry and you are changing it between 32K and 64K at runtime (probably not so useful, but it might be), or to change the bank mode (probably more useful than changing the bank size, but also might not be so useful); in addition, you might want the fixed lower bank to be bank 2 rather than bank 0 for some reason (maybe it makes the coding more efficient for your game, somehow).
If you use both fixed lower and fixed upper, then yes, there will be problems. You'll need fixed lower 2 and fixed upper 3, or fixed lower 0 and fixed upper 1. I just don't want to pass an argument that developers will assume gives them carte blanche to step all over every other game on the cart.
You could figure out with a debugger, what the low bit of the outer bank number will be
Yeah, the debugger route is what I'd probably do. I had to use a debugger anyway to find unused sections of the ROM for the first multicart, so that I could fit the reset stub and possibly other games' CHR ROM data into unused areas of each game's CHR ROM. For each entry, I'd store the reset vector, $80 and $81 settings, and the ROM address of compressed CHR ROM data (if any).

User avatar
Punch
Posts: 346
Joined: Sat Feb 16, 2013 11:52 am

Re: 2014 NESDev Compo - Guidelines/Rules

Post by Punch » Sat Dec 28, 2013 5:07 pm

tepples wrote:
Punch wrote:Sorry if it is a dumb question, but for the 8kb games does that include the graphics? Will I be able to use a 8kb NROM project with plus 8kb character rom, or is a one bank UNROM project more apropriate?
It's the sum of PRG + CHR. So yes, it'd be to your advantage to do a small UNROM because then you can compress the graphics. If you want help with compressing your CHR data, I can let you use my Python compressor and 6502 decompressor.
I thought I wouldn't need it but my graphics are exceeding 4kb already... so, please send the compressor to me :oops:

By the way, bunnyboy's NESASM acts weird if I use "bank 0" instead of "bank 0 bank 1" in my UNROM project, I guess that's because iNES header has a 16kb minimum bank. So I'll just leave it blank, I wanted to crop it with a hex editor but I'm not sure if that messes with emulator's behavior because of the iNES header.

Another thing, I noticed that the emulator mirrors my 16kb bank at the $8000~$BFFF range, that's normal, right?
Last edited by Punch on Sat Dec 28, 2013 5:13 pm, edited 1 time in total.
This is a block of text that can be added to posts you make. There is a 255 character limit.

tepples
Posts: 21750
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 2014 NESDev Compo - Guidelines/Rules

Post by tepples » Sat Dec 28, 2013 5:12 pm

Action 53 menu
Download "Menu source code" and look for files related to "pb53"

Post Reply