2014 NESDev Compo - Guidelines/Rules

May 2/14

The website has been updated with all the entries. Thanks to everyone for making this another success. The judging is also done, but will be posted when I've awoken (night shifts... zzzz)http://nesdevcompo.nintendoage.com/contest14



This year there are three categories.

Category 1:

• Mapper 28 compatible entry up to 64KB with NO PRG-RAM
• Prizes as follows:
  1st Place - $500
  2nd Place - $250
  3rd Place - $100
• Dev. Edition Numbered multicarts (#1 for 1st place, #2 for 2nd, etc) for all meritorious entries (at judges discretion).
• Judging criteria and full submission requirements to be posted shortly
• By submitting an entry into this contest, you are giving full consent to use the entry on the multicart. Submissions must meet multicart standards to be inlcuded (at judges discretion).
• See General Guidelines below.

Category 2:

• App entry - Mapper 28 compatible entry up to 8KB
• Prizes as follows:
  1st Place - $50 + SNES mouse with converter cable
  2nd Place - $25 + SNES mouse with converter cable
  3rd Place - SNES mouse with converter cable
  Above cash prize inclusions subject to at least 5 entries in this category (<5 entries, you just get the SNES mouse)
• Dev. Edition NON-Numbered multicarts for all meritorious entries (at judges discretion).
• Judging decided by the public on the Nintendoage and NESDev forums (This could be interesting....)
• By submitting an entry into this contest, you are giving full consent to use the entry on the multicart. Submissions must meet multicart standards to be inlcuded (at judges discretion).
• See General Guidelines below.

General Guidelines (cat. 1 & 2)

• Contest runs from January 1, 2014 until April 1, 2014.
• Registration and submission will begin January 1st.
• Entries must be submitted by midnight April 1st.
• Entries cannot be submitted if they have already been released prior to the contest. The exception would be if there are significant changes making the original release something completely different.
• Multiple entries are allowed and encouraged.
• Only one cash/cartridge/mouse prize will be awarded per entrant across all categories. If multiple submissions place in top three, the greatest prize will be awarded, and the runner up will receive the prize. You can only win one cash prize. You can only win one cartridge. You can only win one mouse.
• Entries must be original. Plagiarism and copyright infringement will result in disqualification.
• Use of existing tools/libraries/code qualify as long as permission has been granted by the author.
• Collaborations are allowed, prize distribution will be decided by those who collaborated on the project.
• Explicit content is not prohibited from the competition, but will most likely not be considered for multicart inclusion.

Category 3 (the non-contest):

• Anything Goes - old unreleased stuff, modified existing stuff, whatever. If it runs on the NES/FC feel free to submit it.
• There will be no cash prizes awarded for this category.
• Dev. Edition NON-Numbered multicarts for all entries included on the multicart (at judges discretion)
• Depending on the configuration of the entry, it may not be possible to include it on the multicart, however, at the judges discretion NON-Numbered multicarts will be awarded. For exceptional submissions, extra effort may be done to adapt the game/cartridge hardware to support being included in the multicart.
• Entrants are not required to consent to multicart inclusion upon submission.
• Since this category will not be ranked or judged, it will also not be under the strict submission dates and times. If it is submitted before the multicart is released, then it is fair game. Keep in mind, the sooner it is submitted the better chance it will have at making it onto the multicart.
• Entries in this category will also not be under the restriction of the General Guidelines below, but material you do not have rights to will not be considered for the multicart.

Judging criteria, registration details, and submission guidelines are still pending. This will be updated (along with the website) once the details are worked out. Please reply on this thread, PM me, or email NESHomebrew@gmail.com with any questions or clarification. Thanks and GOOD LUCK to all entrants!

Looks pretty good to me, glad we've got things ironed out relatively on time too!

Minor comments, the time zone is not provided. I assume EST? Also I would try to make it a little more explicit that the general guidelines don't apply to category 3. I know you mentioned it, but perhaps move the guidelines above category 3 and name them "Category 1&2 General Guidelines"? Reading through it the way it's structured confused me for a min.

Explaining the intent of category 3 might help people understand why it exists. The main benefit of category 3 I see is that it's a means for people to include their work on the multicart which would otherwise be disqualified due to timing, prior compo entries that were submitted previously as WIP, etc. Even if not able to be placed on the cart, it also allows people to get some publicity, aknowledgement, and praise for their work. This will gain a little more attention from the retro community as a whole compared to making a single post here/NA about your game.

I did this on purpose to allow for a bit of flexibility, I've had my fair share of last minute coding sessions and would have killed for a bit of flexibility.



Quoted.

Fair enough. In that case, maybe just say the entries are due on April 1st 2014 instead of specifying an ambiguous time.

YAY!!! Great work! I've already started on art and freaking out about what to do for sound

So it appears that the structure of this will be a bunch of actual mapper 28 images. That can work so long as no game writes an incorrect outer bank number. So should I try my hand at making an automated tool to mapper-hack individual NROM and CNROM images to mapper 28 so that entries won't exhibit failure modes like Concentration Room, LAN Master, Lawn Mower, Zooming Secretary, and MineShaft did when they mistakenly overwrote CHR ROM?

I guess it should say mapper 28 compatible entry for the first one. Does that really make a difference? I don't know the particulars about the problems related to putting them on the multicart, are there particular guidelines that should be posted to avoid having to mapper hack the games once they are submitted?

The big guidelines I can think of are:

• Don't overwrite the pattern table (PPU $0000-$1FFF) when you don't mean to. This can happen with overzealous VRAM clearing (as in games using older versions of Shiru's library) or with accidental +32-mode writes to the palette (as in Concentration Room).
• In a mapper 28 entry using a fixed bank, write to register $81 only once, at the beginning of the program, so that the builder can NOP it out.
• In a mapper 28 entry, make sure the value written to register $80 matches the size of the game. For example, always use $0x for a 32K entry or $1x for a 64K entry.
• An 8K entry needs to leave a few bytes of RAM open for NMI redirection, and if it's included, we may ask you to relocate it to $C000 or $E000.
• Leave $FFD0-$FFF9 unused for reset redirection.

I think that having a bunch of actual mapper 28 images is kinda pointless, since the games will have to bother initializing details they won't really have to when put in the multicart, since the menu will take care of that. IMO it would be much better to just have the entries be NROM/CNROM/BNROM/UNROM/AOROM images.

I agree for the large part, but some people will want switchable mirroring.

Well, if people want to use switchable mirroring with mappers that don't originally support it, then yeah, they'll have to use a new mapper that does (mapper 28 being the obvious choice, since it will be used to make the multicart).

I also agree, so should we specify NROM/CNROM/BNROM/UNROM/AOROM or Mapper 28 with the stipulations posted above?

I guess so.

My thought was the only REQUIREMENT be that the config/mapper be supported by mapper 28. Not that submissions be mapper 28 roms necessarily. We need to be able to get it on the multicart. We should suggest different standard configs NROM/CNROM/BNROM/UNROM/AOROM etc and accept entries as those configs to help make things clear to people who don't care to have knowledge of mapper 28. We will have to make sure they play freindly with the mapper 28 hardware in the end. Specifically listing out Tepples' guidelines is a good idea, but I don't think we should go as far as disqualifing an entry for messing that up.

I just don't want to limit people from being able to use the available hardware on the cart. Not only is the selectable mirroring useful, but having bankswitchable CHR-RAM is a nice zero-cost feature.

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

• 8K entries: Use $E000-$FFC9, and leave a few bytes of RAM open for NMI redirection. If your game is accepted, we may ask you to relocate it.
• 8K entries and NROM-128: Be careful not to write to $8000-$FFFF. Test with a breakpoint on writes to ROM.
• NROM, CNROM: Be careful not to overwrite CHR ROM. Test with a breakpoint on writes to PPU $0000-$1FFF.
• NROM, CNROM, ANROM, BNROM: $FFD0-$FFF9 of each 32K PRG ROM bank must be unused.
• UNROM (2): $FFD0-$FFF9 must be unused.
• UNROM (180): $BFD0-$BFF9 must be unused.
• A53: Write to register $81 only once, at the beginning of the program, and match the values written to $80 to the size of the entry: $00-$0F for 32K entries and $10-$1F for 64K entries. Specify whether $FFD0-$FFF9 or $BFD0-$BFF9 is unused.

EDIT: Added NROM-128 caution

I think that sounds good.

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

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?

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


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.

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

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.

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.

You should let people donate prize money.

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?

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?

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.

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.

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!

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

SNES versions? Where did this nonsense come from?

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:

I would like to see a homebrew made with similar specs...

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.

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.

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?

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.

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

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


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.


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.


It does not. The mapper 28 test tests this.

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

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.

Yes, this is what I thought and what would be good idea.

Thank you; that is what I thought, but wasn't quite sure.

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.


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

I thought I wouldn't need it but my graphics are exceeding 4kb already... so, please send the compressor to me

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?

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

Yes.

The iNES header format doesn't support files smaller than 16KiB PRG. You could use UNIF instead, but for your purposes there's no real advantage to doing so over padding.

FYI, the website has been updated. Everything is a go, good luck. If something doesn't make sense, let me know.

Looks great! Good job getting everything together and fully announced.

A few minor comments, do with them as you please.

Registration: I'd recommend explaining that it's non-obligatory, and can be done at any point. There is no deadline to register afaik, just a good idea to do it sooner vice later if you're thinking about making a submission so you can stay in the loop.

What about open source, openly shared code? So long as licensing requirements are upheld, would it not be okay to use especially things like generic libraries and such? Or if someone took a hello world example, or nerdy nights tutorial do we want to discourage things like that?

If your library is under a free software license, then the license itself is proof that "permission has been granted by the author". For example, anything copied out of Zap Ruder, such as controller and Zapper reading code, is under the GNU Permissive License.

(Not sure if this is the best place to mention this..)
I would like to, but I don't think I will have time in the coming months to be able to finish/submit my own project. But I would like to offer to help with anyone else's project. Anyone that feels they could use some help with programming please let me know/PM me. I'd be happy to be part of a team.

I would hope not, but an answer to this question would be swell. Many of us, I assume, are coming straight off of the NN and have a majority of our code adaptations invested in it. Thanks for any clarification

I just realized that this might be a perfect place to slip in a serial bootloader. PL2303-based USB-TTL-serial adapters are $2 shipped on eBay and can be wired directly to the controller port. Even if there's no cart RAM, small programs can be developed. If this sounds good, I'll update the spec using my current version and we can figure out the details. It'd be a nifty easter egg feature tucked away into 65 bytes of ROM. And if the contest organizers aren't interested, then maybe it can be slipped into one of the entries

What you could do is enter an 8K app containing the bootloader and instructions for using it.

I'm not much into gambling/artificial zero-sum situations, and it's less useful if you have to navigate a menu every time to use it. My thought was hold a particular button on the controller while powering up/resetting to invoke it. If code size is an issue I can probably provide a version under 40 bytes, including controller checking code.

You have a point. Given the whole desktop PC GUI-style theme of the planned menu, I could have this serial bootloader stand in for PXE. Code size is not the issue as much as my own ability to test a transfer. I have an NTSC NES with PowerPak, a Windows 7 PC, and a Linux PC, but no soldering skills.

I think this would be an excellent addition. I'm glad Blargg thought of this. It would be nice to have some more useful purposes for the GUI other than just look pretty. For example, it would be cool to have it run some hardware tests on the as the "OS" boots up. You brought up detecting peripherals, this would be a cool place to show "Port 2: Zapper Detected", "NTSC Mode", etc.

Which bits of which port? I suggest bit3 and/or bit4 of the second port; this way it is compatible with both NES and Famicom. The bootloader program could also include a BIOS of functions (and an ASCII character set loaded by default in CHR RAM) also used by the main menu; then loaded programs can optionally use this feature.

Yes, and perhaps display "Push SELECT for serial bootloader", or "Push gun trigger for serial bootloader" if the Zapper is connected to the first port.

Another question about NESDev Compo in general: If individual programs are extracted for standalone, is the reset vector restored? Is a program allowed to check if the reset vector has been tampered with, and display a "QUIT" option on its menu if so? Would it work?

Yes. The current builder (designed for NROM games) saves the original reset vector in a table in the ROM and restores it when extracting the ROMs. I plan to make the next generation builder (designed for multiple mappers) at least as careful.


It should work. Great idea.

I had it using $4017 bits 4, 2, 1, 0. If I remember correctly (I cannot access all my notes at the moment), bit 0 so you can use a normal NES controller cable, bit 1 if you replace Famicom controller input (or maybe they put input in either), bit 2 is either so you can wire serial to NES internal bus (memblers was going to do this) and possibly on Famicom, and bit 4 is for having two controllers connected and using a modified extension cable for the second port, and maybe also for Famicom. The main danger from more than the minim necessary bits is other hardware that drives them them low when idle.

The bootloader is very minimal, receiving a 256-byte user program to zero-page and checksumming it. Everything else can be done by uploading the appropriate program.

As for invocation, it should be something simple to do with minimal effort. Holding a button on the controller while powering up/resetting is about as minimal as it gets for manual invocation. It should check the controller shortly after reset to avoid having to hold the buttons for more than a moment. It should also check that only the decided-on buttons are held, and no others, to avoid possibility of false triggering if no controller, other controller type, whatever.

Here's what I've got for the bootloader spec and serial cable at the moment, but I haven't looked over it in a while so it may contain minor errors:

Bootloader

Serial cable

I've been using the specified bootloader for a few years, and an earlier variant for many years before that, and it's performed quite well.

OK, yes I believe that can work.

A good substitute would be designating one 4KB sector of flash rom for storage. Future app compos could be developed/tested on this years carts with the 4KB limit in mind. We could always wait until we had all multicart entries to determine if we could/desired to leave room for this. It's possible we may end up with a few sectors to spare.

I like it! Just a bootloader is a nice feature, and extra flash is all the more nicer. I've worked on a nice "romless" format, packaged as a normal NES ROM and usable on normal emulators/normal flash carts, that can be uploaded to something like this. I'll be providing a tool that takes this file format and generates a binary file to be sent to the NES over serial to upload and run the program. This way you develop it fairly normally, and let the tool handle getting it all into RAM/flash. In specific, the format lets you specify initial CHR RAM and nametable contents, allowing some reduction of the limited code space, though you wouldn't want to use this if you did have some flash available and wanted it to run without a PC to upload it.


I've generally tried to keep things not depending on the ROM of the cartridge with the bootloader, to avoid unncessary dependence on it, but it could be useful if the cart had no RAM, leaving you with just 2K of internal RAM. One thing that would be very useful is to have forwarding of NMI and IRQ to somewhere from $200-$7ff in RAM ($7fa-$7ff is preferred), so that "romless" programs can have interrupt handlers.

Well I don't know what to say. I'd like to enter the contest but I don't know what to do, considering the pile of abandoned projects and "maybe" projects.
Of course since multiple entries are allowed I could go for all of the options but the time is limited. So I'd like to know what people would like to see the most ^^

Also I don't care about winning, so anything that doesn't go to cathegory 1/2 would go to cathegory 3 instead, I'd be very happy to see one of my games completed and released on a multicart, and I'd rather see that than getting any amount of cash or hardware !!

Basically I have the following projects going on :

1) A small single player action RPG consisting of 6 levels (it's in fact more "action" than "RPG", don't worry tokumaru ), on which development started on 2005. The game engine is complete and several levels are complete, but I never went on further. I already releasded screenshots and some infos but I never released anything else (such as a demo ROM nor a video) so pehaps it could still quality in category 1/2 ? Not that I care anyways.

2) A relatively simple puzzle game with relatively simple rules that promises to be very fun in 2 players mode. I started development on this one in 2011. I only developed a very small part of it and never released any single info about it (exept maybe clues) so this would definitely quality for 1/2. The game itself might not be as epic as the 1st one, but definitely it'd be fun.

3) Any of the other games I always wanted to do but never really started. More specifically I have a 2 players beat'em up game in mind where most characters are ready as well as some level ideas, but I haven't started any kind of design on this one. If I do this one it'll be a real entry in the contest, as I haven't started anything prior to now. However I was aiming at something that probably can't be done in 2 months so I'd only release like a single level demo of the game or something in the like.

Unfortunately I won't have any free time before January 31st, and by then I'll have plenty of it, but that still gives me only 2 months instead of 3 So just tell me which game you guys would rather make it to the multicart.

IMO They both sound like great candidates for the multicart assuming they're complete. Although it sounds like the RPG might not actually have an 'ending' right now? If you're able to ensure there was one and have it more complete I'd suggest focusing on that one. If the second one doesn't take as much effort to complete and you could fit it into category 2 then perhaps it's best to focus on that one first depending on how much time you have. Better to submit one complete entry vice two/no partials.

The problem is that I'm not sure what fits in category 1 and 2.

Even the puzzle game isn't going to fit in 8k (unless I seriously strip down the planning of the project, but what's the point), so it won't fit category 2. It would fit category 1 if I am allowed to submit something that I already started to do several years ago (2011), if I'm not then it'll fit category 3.

Same goes for the action-RPG : It would fit category 1 if I am allowed to submit something that I started in 2005 and already published informations and screenshots about. If I'm not then it's category 3.

So finally the rules are not clear about those points : How much of the project was allowed to be already done before january 1st 2014 for category 1. The action-RPG has a complete game engine, a complete level and several planned levels and enemies. The puzzle game has just the basics graphics and some early programming.

The later is currently much less complete, however it would be a smaller project overall.

I can't plan if I'll be able to finish any of those 2 by April 1st, but I can at least try and getting external pressure is a good way to see those progress.

Technically my understanding of the rules is that submitting anything that wasn't officially released prior to the compo is okay.



I wouldn't qualify screenshots as officially released. We're trying to encourage submissions, but had to draw the line somewhere. Doesn't sound like you released any of those titles officially, so you're good. To play it safe I would encourage you to spruce up and add some detail/content to them. If you did that you'd certainly be okay to submit them into category 1.

Category 2 is kind of an experiment, sounds like they wouldn't fit there, so if you ensure the mapper is compatible with category 1 then it sounds like that's where they belong.

The problem is that I don't how fair is it to enter the competition with something that was started more than 8 years ago. Of course I didn't work continuously on it, but that's still a huge advantage against someone who just started his entry recently.

With the puzzle game it'd be more fair since I'm not very far in the development. But I still started it more than 2 years ago technically.

Well it's not me to decide. Either way I'll try to come up with one of these, and I'll let someone else decide if they enter category 1 or 3. Just tell me if you'd rather see the action RPG or puzzle game on the multicast, I'll handle the rest.

If the competition is what gives you the extra push to finish it, then I would say that the compo has successfully done it's job.

Is there a mapper supported by Mapper 28 that has 16kb bank switching at 0x8000 and single-screen mirroring?

Yes. You can mix and match bank switching features, in this case AOROM-style 1-screen mirroring with UNROM-style fixed $C000 PRG banks. The setup code looks like this:


Fixed banks in the A53 mapper actually work by temporarily forcing the bank mode to 32K NROM. So it's possible to set up a 64K UNROM-style banking mode (fixed $C000, switchable $8000) with either 1 or 3 being the outer bank. Normally for compatibility with UNROM link scripts, you want it to be 3, so you have to write a value with bit 0 turned on to the outer bank. Normally the menu will do this for you, but when you use mapper 28 directly to mix and match bank modes, you have to do this yourself.

After the code above executes, to switch PRG and nametable banks, write to $8000 with the nametable page in bit 4 and the PRG bank in bits 1-0. (Or perhaps 3-0 if your entry is oversize and in the freestyle category.)

Thank you very much for taking the time to write out the settings. I'm looking forward to moving my MMC3 code to Mapper 28. One more question: do most emulators support mapper 28, or are there specific emulators that I should be testing with?

Only a few: viewtopic.php?f=22&t=9393&start=15#p102960

All you absolutely need are the hardware and one debugging emulator, and I have PowerPak and FCEUX 2.2.0 for Windows.

I was able to get the bank switching routine working. Thanks Tepples.

I thought I'd ask - Is there any way we could get 8 bytes of save data? This would be very useful for high scores - or, for an rpg or metroid style game, for remembering items gathered or state flags set.

Possibly just 8 bytes? I wouldn't say no to 16 though!

For such a small amount of data, couldn't you make do with passwords?

Of course - although 8 bytes (12-16 char password) is really the longest password I'd consider. Just asking. Don't know if it's even possible with the hardware - but possibly some spare flash?

It's possible with the hardware on the cart. The main thing is software support. Part of the trouble is sector size of 4KB. You can't erase anything smaller than 4KB, although you can program one byte at a time. I don't think we want to give each entry their own 4KB to use solely for saves. If we were interested in this, the best way to handle that would be to setup something through a OS style interface with the multicart software. That would be up to what Tepples thinks about setting up something like that.

Another less versatile, but easier route would be to designate a bank for free range for all entries. If you toggled between games that also used that space they'd stomp on eachother. But if the player stuck with only the one game then perhaps that'd be a shortcut to entering the password each time. I would still have a password in that case though to allow for recovery post-stomping. We had discussed designating a bank or few to the bootloader, so perhaps just opening that to anyone would work.

The main trouble with developing saves on flash is that the only real way to test things working is on the end hardware. I can make blank mapper28 boards available to aid in development if people would like. Things can be a little tricky because the save routine needs to operate from system SRAM because flash is not readable while programming. That and a poorly written erase routine could brick the cart or a given game on the cart if the wrong sector was erased unintentionally. There are ways to prevent that, but that's why I'm thinking a OS helper routine could go a long way.

Tepples, here are my thoughts on such a helper routine I'm thinking about. Let me know what you think:

Small chunk of assembly code provided to all. This would be the same routine for every entry which choose to use save flash. Perhaps the most universal routine would be one that copied itself to SRAM. The main reason for putting it in SRAM isn't because of the flash operation, but because the OS will have to be bank-switched in which isn't universal for all entries. The programmer would have to be aware that they'll loose that block in SRAM. Perhaps they could be responsible for storing any vital info in chr-ram temporarily. This could be the same location (or same address range) which the OS will operate from while storing/loading save data. This makes it a little simpler for the game as it only needs to worry about one chunk of SRAM which will be stopped on by the OS.

The programmer would have to pass a few variables into the OS. So specifing a location in SRAM for these variables would be needed. Perhaps something like these:
game number- OS needs to know how to setup banking to return to game.
slot number- slot number in the eyes of the game. The OS would determine end location based on slot number and game number. This could allow us to give one game more than one slot if needed.
save/load- tell the OS whether you're saving or loading the data into or out of flash
current bank- for games which utilize bank switching the OS may need to know which bank to initialize the game back to, as the OS may have stomped on the current bank number.

The save size would be a specified size and location of SRAM. So the programmer has to put the save data there before calling the OS if it's not normally there. And the programmer knows that's where they'll find the save data when loading.

This would keep flash operations the sole responsibility of the OS. And the programmer would 'simply' have to follow the rules above.

I could make something like that, but nowhere near in time for this compo's deadline. Maybe for the next compo?

The obvious system for that is some kind of log-structured filesystem. Although with only 2K of RAM, some of which needs to be reserved for the flash write routine as well as everything that needs to be written back to flash after an erase, it might get kinda cramped...

Yeah it's possible, but you can't use just 8 bytes. The data is written as individual bytes, but is erased in sectors. You can only write to the blank parts (changing 1s to 0s). I'm guessing this board would be using 4kB sector sized flash. In that case, you just reserve a 4kB bank in your program. On a 4kB boundary of course, such as $8000-$8FFF. For your save data you'd make a block like 16 bytes or whatever, including a blank ($FF) byte for a flag. When you save the latest data, you clear that flag on the old block(s). So when you load, you would scan through the data to find the most recent save. When the sector is full, delete it and start over.

Wouldn't be hard at all to have multiple games share the same kind of memory space. Include an identifier in the block, the game ignores blocks that don't match it's own. Identifier could be a CRC or checksum of the program, if it needed to be automated.



I don't think it's a problem. One should isolate the the write byte and erase sector routines. Those parts are straight-forward, and are also the only parts that are specific to the memory type. IOW I'm saying that this kind of filesystem is equally useful for SRAM or Flash.



The solution for that is to use 2 sectors. Then it can copy over the blocks that aren't flagged for deletion, before erasing. This is fine with large sectors. I was just looking at one I like that has 128kB sectors.. 1024 of them, heheh.

Was there any consideration to this? Or did I miss something?

In other news, it sounds like we might be able to support a 60pin release of these cartridges as well. I'm planning on making a 60pin version of the boards used for this multicart since new shells were recently found.

I wouldn't expect a 60pin release to debut at the same date as the 72pin release. But hopefully I'll have the boards complete by summer and we can release a 60pin version of action53 v1/v2/etc by the end of the year.

I thought this was sufficient so I didn't add any more comments. It's obviously going to be difficult to tell if code has been directly ripped from another source. I wouldn't go as far as requiring written consent to use code, since most if not all code out there is released for others to use. However if you took existing code, changed some sprites and backgounds, added a few features, that wouldn't be allowed. If you got help, give them credit. Most of us wouldn't be here if it wasn't for other peoples code, and most people release with some sort of free licensing like Tepples mentioned.

Fair enough, just wanted to make sure we're on the same page.

Maybe you can use CHR RAM and CIRAM as extra RAM too if needed, while rendering is turned off. Mapper 28 is supporting four CHR RAM banks, so maybe this could be used too.

That's an interesting idea. Only the saving routine itself must be at $000-$7ff, while the data to be saved could be read from VRAM. It should be trivial for a game to restore the contents of VRAM after a save. The only problem I see is the complete lack of visual feedback on the saving process. If it takes longer than a couple of seconds, players will find a blank screen weird.

I did see that problem too. Well, you can use emphasis bits to change the background color. You can also use sound effects if that helps. Couldn't the saving routine be stored in ROM, or am I missing something?

No, the flash is unreadable while it's being written, and writing takes several microseconds.
In addition, erasing takes several hundreds of microseconds to several milliseconds, so while the process as a whole should be really fast, it has to run entire from a physically separate memory.

I'm probably going to disappoint everyone (especially my own self), but since my february vacation (where I did an extremely quick advance on the game) is over, I only get a couple of hours of actual free time per week (I have a zillion other things to do each weekend, and I live far away from my workplace, which means leave home at 7 and get back past 7, so I have not many hours and even less energy on evenings to work on this). So chances that I can finish my game by April 1st are extremely slim to nonexisting.

The game's world is complete but empty right now. I basically have to :
- Write the AI of half of random enemies and all bosses (except the first one which is already done)
- Write the music for most of the stages (only several ones are done)
- Do something at the ending
- Play test and balance the game so that the difficulty curve is ok

Chances that I can do all this in mere 2 weeks, even if I do some of the work at work (sigh), are none to slim.

I hope I can release this before May though, so that I can submit it in category #3 and be on the multi-cart ?

I'll probably have to do all of this before May, because all my weekends are extremely busy in May and I have my thesis to write in June which means few to no freetime before July.

Due to various things going on in my life, various collaborators dropping out or returning work late, and other people pushing me to switch to their own pet projects, my entry will be roughly 75% complete by the compo deadline. I plan to push a big update afterward, much as I did with mouse support, practice mode, and rebalancing of late levels in Thwaite.

For the past month I had switch from programing for the main category to instead an app entry.

Just a few days ago I was about to give up, but then I saw that there's only 8 registered contestants, and it would be at least a 20% dropout rate if I were to fail. So I'm now aiming for implementing only 1 or 2 modes out of the planned 8. After the compo, I hope I can then finish the other 6 by the time the final multi-cart ROM is assembled.

Well I know everyone has it's own philosophy, but I'm reluctant to release an unfinished game. I don't want to spoil the surprise before the finished game. I could make up a demo with only a (finished) level playable, but then it'd be quite weak compared to finished games.

Suddenly I don't feel so bad for dropping a number of things (e.g. Attract Mode screens) out of my Category A entry. Not sure if I'll be able to get 4-player working in time, though. :s

Is it possible to submit the game in cat 1/2 to be judged but to give a better version later for the multicart? There are several features that I won't be able to fit in before april 1st (level editor, challenge, etc.) but I would like to include them in a separated "multicart build".

It appears yes, seeing as that's what happened with Thwaite. I submitted one version, but the multicart used a later version with mouse support, improved music, practice mode, and tweaks to late game balance. NovaSquirrel also submitted some fixes to FHBG for the multicart. My entry for this year will probably get a big post-compo update too.

Maybe 3 months wasn't long enough? This will be something to consider for upcoming competitions. The 2011 competition was extended another month because there were hardly any submissions, and it wouldn't be fair to do it this time around.

I would encourage people to submit things in any state for judging (even if you just want to submit a demo). Like Tepples said, although we can only judge you on what was submitted by the closing date, any improvements and bugfixes can and will gladly be put on the multi-cart.

In my opinion extending the compo for another month is reasonable, since I'm not seeing too many projects being publicized (of course some won't spoil the surprise but still), dropped projects is the worst thing that could happen to the competition.

I can only recall 2 of the previous entries that were posted before being submitted in the 2011 contest. None of the people who have registered (I believe) have created any threads either. I haven't received any submissions yet, and that does worry me a bit.

Oops, forgot to send the reg mail for my entry.
[goes to Gmail]
Done.

It's the final countdown

I need to learn to focus more on one concept. If I can make my game to category 1 it will be a miracle given the short development time of my project. Realistically I might make it into Category 3 because there really isn't much time left. If only I had the focus I'm having now at the start of the competition.

Good luck to everyone!

ok, I'm out of time.
I've submitted what I have to Category 3.

Good luck to all.

Don't forget that Category 3 doesn't have a deadline, so everyone is free to keep working on their projects.

Would it be advisable to instead post the work in progress in a thread, and then submit it when it's done?

You could do that if you'd like. I will post whatever is submitted to the website so there is a consolidated location to download the competition entries. You can submit a newer version whenever you would like and I will replace it on the website. Either that or I can add a link to your thread here instead of hosting the file on the nesdevcompo site, as long as you use the forums built in attachment feature and not link to an external website. I don't want to deal with broken links in the future.

FYI, if you have sent me an email and I have not responded please let me know via pm. I reply to every email I get, and it has been brough to my attention that someones email did not go through to the neshomebrew@gmail.com address. It didn't even show up in my spam folder. Thanks guys!

NovaSquirrel said it might have had something to do with executable blocking. If your entry includes source code, and your build process uses a batch file or shell script (as opposed to a makefile), or it includes executables that convert data or create lookup tables (as opposed to source code or a converter written in a scripting language), filters might block it as a potential malware vector.

Ok, I think I'll let you post what I submitted, with the option of replacing the compo website copy with the finished multi-cart version. I'll also make a thread to be a progress log and area for comments.


I had a blocking error when I accidentally included a compiled windows binary of asm6.

That would explain it. I hope gmails blocking doesn't cause any other problems...

Thanks again to everyone for the submissions. I believe we have 6 Entries in Category 1, and 4 Entries in category 2. As well as a few in category 3. I think everyone could have benefited from extending the contest another month, but I'm going to take this as a lesson learned. I'll have the voting ready either tonight or tomorrow so if you submitted an entry be sure to check your email. The website will also get updated with screenshots and downloads like the 2011 page. Open voting on the category 2 entries will start on the 7th and run for 3 weeks.

Any questions, let me know.

Sorry guys, delay of game. My 2yr old broke his collarbone, which ate up most of my free time today.

Man, that's rough. I hope it's not too serious and all will be fine.

It will be fine, it was just pretty traumatic for him and my wife haha.

Sorry to hear that, hope your son recovers soon.


It is just a possibility, but it is possible I'll submit a third game, in category 3.
If that happens, then there will be a total of 80kb of my games (32kb+32kb+16kb) to be included for the action 53.(If all games gets accepted)

All games uses same graphics for logo, font, same music\sprite engine etc. I think it would be possible for me to make a single 64kb ROM out of three games to save some space.

But then, how player should make a choice which game he wants to play? I can make a game select menu inside my own ROM, but it could be a bit tedious for player to have two game menus...

Maybe iI still could have 3 entries in action53, every entry would point to my ROM. I examined Action53 ROM and I see it does not clear RAM after game selection, selected game do it. I can use the game selected number from RAM before my routine clears it to determine which of my games was choosen.

How plausible this idea is?

Aaannd...how much there is (approximately) to submit a game in 3rd category?

Just give each activity its own entry point. That's how Axe, MineShaft, Zapper Calibration, and ZapPing in the first multicart work: they're all part of one CNROM image, and the menu software chooses an initial value for the program counter based on the chosen activity. Other sets of things bundled into one 32K bank include Concentration Room/NES15/Russian Roulette, Lawn Mower/Thwaite, LAN Master/Munchie Attack, and Slappin'/FHBG.

Ok, I swear I made a voting thread for category 2.... I guess I'll make another one.

Bump for website update.