Page 2 of 10

Re: 2016 NESDev Compo - Guidelines/Rules

Posted: Thu Oct 06, 2016 8:52 pm
by tepples
We are, as Free Software Fanatics might say, distributing copies of the games on the multicart for a fee. That's commercial.

Re: 2016 NESDev Compo - Guidelines/Rules

Posted: Fri Oct 07, 2016 6:41 am
by gauauu
Good enough for me, thanks

Re: 2016 NESDev Compo - Guidelines/Rules

Posted: Mon Oct 10, 2016 11:25 am
by VEG
Is it possible to add this one to the Category 2 (the non-contest category)? =) It was heavily updated when this contest just started.

UPD. I've found a bug with speed when not FCEUX is used. So, it will be updated soon =)

Re: 2016 NESDev Compo - Guidelines/Rules

Posted: Wed Oct 12, 2016 9:15 am
by VEG
New version of my demo "Unchained Nostalgia" is released. Now it works fine on real hardware.
Topic on this board is here: viewtopic.php?f=22&t=10672

Re: 2016 NESDev Compo - Guidelines/Rules

Posted: Thu Dec 01, 2016 3:20 pm
by Punch
Is there any battery-backed like save capabilities on the A53 compo cart? I recall vaguely that this was being discussed in the last competition.

Re: 2016 NESDev Compo - Guidelines/Rules

Posted: Thu Dec 01, 2016 4:44 pm
by tepples
The mapper supports WRAM in the same way as the iNES version of discrete mappers, equivalent to a 7420 decoding $6000-$7FFF. But it doesn't offer any way to isolate one game's WRAM from another. There are a few ways that could be addressed:
  1. Run two outer bank bits to A14-A13 of the WRAM. Allow only three games to save, and have all other games use WRAM bank 0.
  2. Run two outer bank bits to A14-A13 of the WRAM. Run all games in WRAM banks 1-3, and add a library that copies data (smaller than 8K) in and out of WRAM bank 0.
  3. Add 8K of non-bankable WRAM and make the first few sectors of the ROM self-flashable, with a library that copies files in and out of a log-structured file system.
  4. If possible, fit your campaign's state into 32 bits or less, which is small enough to make a practical password system.
What all state do you want to save in your game?

Re: 2016 NESDev Compo - Guidelines/Rules

Posted: Thu Dec 01, 2016 9:04 pm
by Punch
tepples wrote:The mapper supports WRAM in the same way as the iNES version of discrete mappers, equivalent to a 7420 decoding $6000-$7FFF. But it doesn't offer any way to isolate one game's WRAM from another. There are a few ways that could be addressed:
  1. Run two outer bank bits to A14-A13 of the WRAM. Allow only three games to save, and have all other games use WRAM bank 0.
  2. Run two outer bank bits to A14-A13 of the WRAM. Run all games in WRAM banks 1-3, and add a library that copies data (smaller than 8K) in and out of WRAM bank 0.
  3. Add 8K of non-bankable WRAM and make the first few sectors of the ROM self-flashable, with a library that copies files in and out of a log-structured file system.
  4. If possible, fit your campaign's state into 32 bits or less, which is small enough to make a practical password system.
What all state do you want to save in your game?
I want to save a scoreboard. I want 3 characters for a name + 6 digit score (20 bits ~ 3 bytes). If I use 32 characters for the name entries, I'll have 15 bits ~ 2 bytes per name, or 3 bytes for more characters. 6 bytes per entry, 30 for a table with 5 entries.

Not having saved WRAM is no big deal for me since almost every arcade style game doesn't have a battery backed WRAM to save scores anyway. For me it's more of a luxury than a necessity.

Re: 2016 NESDev Compo - Guidelines/Rules

Posted: Fri Dec 02, 2016 2:48 am
by na_th_an
Wouldn't the easiest way to achieve this be that entrants who wish to use save ram ask for an amount and are given a reserved fixed address range they should adhere to?

Re: 2016 NESDev Compo - Guidelines/Rules

Posted: Fri Dec 02, 2016 3:48 am
by rainwarrior
Isn't it going to be on flash ROM anyway? You could use flash to save stuff without needing a battery.

Re: 2016 NESDev Compo - Guidelines/Rules

Posted: Fri Dec 02, 2016 10:02 am
by tepples
That's what I meant by "make the first few sectors of the ROM self-flashable, with a library that copies files in and out of a log-structured file system." But if we go that route, the library would have to be extra careful not to brick the game, or we'd need logic in the mapper CPLD to allow write enables to go through to the flash chip only in low-numbered outer banks. (Anyone remember bridging SL1 when installing FlashMe custom firmware on a DS?)

Re: 2016 NESDev Compo - Guidelines/Rules

Posted: Fri Jan 06, 2017 7:27 pm
by Jedi QuestMaster
This may sound like a dumb question, but...

Where do we submit our entries? :? I was hoping the website would have more details:

http://nesdevcompo.nintendoage.com/

Re: 2016 NESDev Compo - Guidelines/Rules

Posted: Sat Jan 07, 2017 7:39 am
by dougeff
Please reply on this thread, PM me, or email NESHomebrew@gmail.com with any questions or clarification. Thanks and GOOD LUCK to all entrants!
I'm not an official, so I'm speculating...

It seems to me that NESHomebrew and tepples are 'running the show', so I would think emailing either/both of them would be considered an official entry. Or posting a ROM in a compo thread should suffice...or do what the Mojon Twins did, and post it on a website, I suppose would work.

Re: 2016 NESDev Compo - Guidelines/Rules

Posted: Sat Jan 07, 2017 7:51 am
by tepples
I'm not accepting entries through email. The appropriate method will be revealed in a few days.

Re: 2016 NESDev Compo - Guidelines/Rules

Posted: Sun Jan 15, 2017 3:57 am
by NESHomebrew
tepples wrote:I'm not accepting entries through email. The appropriate method will be revealed in a few days.
I'm not sure if anyone has noticed, but the website has slowly been updated over the last week. If you see anything that looks strange, or have any questions/comments let me know.

Re: 2016 NESDev Compo - Guidelines/Rules

Posted: Tue Jan 24, 2017 3:19 pm
by Myask
I'm surprised this isn't stickied, now that 2016 compo is its own subforum.