2014 NESDev Compo - Guidelines/Rules

[infiniteneslives]

Then it might be better to frame it as mapper-specific advice:

I think that sounds good.

[qbradq]

I like the mapper-specific guidelines. That helps a heck of a lot!

[Punch]

I'm definitely in. Just for clarification, is it ok if I build my game as a regular NROM? If I understood it correctly, I just need to leave FFD0 to FFF9 free and the soft reset, nmi and irq handles will get replaced when building the compilation cart?

Also, is source code required to be gived? Is there any problem to release work in progress ROM images to the public during the course of the competition?

[tepples]

I'm definitely in. Just for clarification, is it ok if I build my game as a regular NROM?

Yes. The menu will take care of initializing the mapper for you.

If I understood it correctly, I just need to leave FFD0 to FFF9 free and the soft reset, nmi and irq handles will get replaced when building the compilation cart?

NMI and IRQ will get left alone (except in 8K entries). Reset will get changed.

Source code is not required, just helpful to get it onto the cartridge, especially if it's an 8K game that will be paired with another 8K game in a 16K bank. In that case, source code would help me make the NMI dispatcher. And any entry that has source code can be used as an example for helping others learn to code.

The policy on official leaking of WIP ROMs is out of my hands. But I'll probably be using at least one leak detection measure on copies of my own entry given to testers to make sure they don't compromise confidentiality.

[infiniteneslives]

Is there any problem to release work in progress ROM images to the public during the course of the competition?

I don't see any issue with sharing progress while the competition is going.

[NESHomebrew]

I'm all for a more open development/progress report type of contest. Not everyone has friends that can test things out and give feedback. Plus, you can get good ideas from testers that you may not have thought of.

[Punch]

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?

[tepples]

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.

[Zelex]

You should let people donate prize money.

[tokumaru]

Why exactly does $FFD0-$FFF9 have to be left unused in all games, since according to the documentation of mapper 28 the last 16 KB of ROM is consistently mapped into $C000-$FFFF on power up?

[tepples]

So that switching games doesn't need a power cycle.

[tokumaru]

So that switching games doesn't need a power cycle.

I see... if you don't reset the mapper the RESET button will reset the current game as opposed to going back to the menu, is that it?

[Drag]

Makes sense to me. The menu can trampoline to the game's reset code when you select it, leaving the actual reset vector to point to a bootstrap that can initialize the mapper to start the menu after a reset.

In addition, you'd be able to exit to the multicart menu by indirectly jumping through the reset vector. There you go, an "exit game" option at your title screen.

[NESHomebrew]

You should let people donate prize money.

That is what we did with the first contest, but it isn't really necessary since we have money sitting in a bank account to go towards future contests and cart production. Besides, I've looked at quite a few contests where they rely on community to donate funds and I didn't see any that came close to what we are offering for this contest.

[Hamtaro126]

Tepples has a good change, But time to spice things up for a challenge, even if I don't join in...

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

* You need at least a NES version of the program to enter the contest!

* Speed coding is allowed, As long as everything is working OK as far stability

Then again, The author chooses the rules... So it's optional to review

Edit: Added one!