nesdev.com
https://forums.nesdev.com/

2017 NESDev Compo - Rules/Guidelines
https://forums.nesdev.com/viewtopic.php?f=33&t=16019
Page 5 of 6

Author:  na_th_an [ Mon Nov 13, 2017 1:13 pm ]
Post subject:  Re: 2017 NESDev Compo - Rules/Guidelines

Hello. I might enter this year, but my current development is based upon an experiment to use CNROM's extra CHR banks for data. (I'm using 2 banks for patterns and 2 banks for map data).

The cart's mapper "emulation" of CNROM games needs the banked CHR to be copied to CHR-RAM, and this is not going to work with my game. Am I right? Unless there is 32K of bankable CHR-RAM which I believe there is not.

I can make an UNROM port if I have the time, of course.

I was planning a full-fledged UNROM64 game as well but time is tight this year. Let's see.

Author:  Sumez [ Mon Nov 13, 2017 1:23 pm ]
Post subject:  Re: 2017 NESDev Compo - Rules/Guidelines

I didn't even realise the mapper requirements allowed any kind of banking. So you're technically bank-switching between CHR-RAM windows, and have to write to each of those manually?
Interesting idea, providing I'm not misunderstanding it, did any actual NES games use that method back in the day?

Author:  tepples [ Mon Nov 13, 2017 2:12 pm ]
Post subject:  Re: 2017 NESDev Compo - Rules/Guidelines

na_th_an wrote:
The cart's mapper "emulation" of CNROM games needs the banked CHR to be copied to CHR-RAM

Which the menu does before your program starts. I added this feature to the Action 53 menu back in February to support Sinking Feeling.

na_th_an wrote:
Unless there is 32K of bankable CHR-RAM which I believe there is not.

There is.

Author:  Sumez [ Mon Nov 13, 2017 2:20 pm ]
Post subject:  Re: 2017 NESDev Compo - Rules/Guidelines

Ok, so it's just plain CNROM then :)
So if I'm not misunderstanding, entrants potentially get a maximum of 32KB PRG-ROM plus up to 4 banks of 8KB CHR-ROM with a CNROM configuration?

Author:  dougeff [ Mon Nov 13, 2017 2:27 pm ]
Post subject:  Re: 2017 NESDev Compo - Rules/Guidelines

"up to 64KB"

So, yes.

"32KB PRG-ROM plus up to 4 banks of 8KB CHR-ROM"

Yes. This is exactly what I'm doing.

Author:  FrankenGraphics [ Mon Nov 13, 2017 2:36 pm ]
Post subject:  Re: 2017 NESDev Compo - Rules/Guidelines

We're going to see a lot of CNROM this time around

Author:  infiniteneslives [ Mon Nov 13, 2017 2:53 pm ]
Post subject:  Re: 2017 NESDev Compo - Rules/Guidelines

You actually get a maximum of 64KB of total rom, and there is 32KB of CHR-RAM. Although there are no suggested mappers that bank both PRG and CHR simultaneously. The real requirement is that it's compatible with https://wiki.nesdev.com/w/index.php/Action_53_mapper

I suspect the most sensible way to utilize the 32KB of banked CHR-RAM is to simply develop your game to utilize mapper 28 directly. Tepples will have to back me up on this. To submit the entry, you will have to initialize all the supervisor registers to get the desired banking effect. But that initialization will need to get stripped in the final version as the menu will take care of the supervisor register settings, and the game code can control PRG-ROM and CHR-RAM banking via the user registers.

If there's significant interest to utilize the banked CHR-RAM outside of abusing a CNROM config with it's underlying CHR-RAM, it might be worthwhile to settle on a simple homebrew "discrete" mapper design to simplify the rules and mapper specification for future compos.

Code:
7654 3210
MBCC PPPP
|||| ++++- PRG-ROM bank (LSB ignored in 32KB bank mode)
||++------ CHR-RAM bank
|+-------- PRG-ROM bank mode (0-16KB UNROM style, 1-32KB BNROM style)
+--------- Mirror select (0-Horiz 1-Vert)

Register can be assumed to start-up with all bits cleared.  So stubs aren't needed in each bank.
Edit: additionally this definition would not be subject to bus conflicts.


With a limit of 64KB PRG-ROM bank bits would only utilize the lower two bits. Dedicating two extra bits would allow room for expansion if rules provided more rom, or rules were broken for exceptional entries. A simpler definition like this that also gained emu support would greatly simplify the definition of mapper 28 to something more tangible for development.

Author:  na_th_an [ Mon Nov 13, 2017 3:02 pm ]
Post subject:  Re: 2017 NESDev Compo - Rules/Guidelines

As I said, I can always port it to UNROM with ease. All I'm storing in CHR-ROM is map data which is only accessed screen by screen and unpacked to a one screen metatile buffer in RAM. It was an experiment and I was just wondering if it could go on the cart untouched.

But again, porting it to UNROM would be a piece of cake, really.

About your mapper specification, I think it's a great idea. It can be easily configured to act as anything the compo allows for and I guess less fiddling with the games should be necessary afterwards when building the multicart.

Author:  gauauu [ Mon Nov 13, 2017 3:23 pm ]
Post subject:  Re: 2017 NESDev Compo - Rules/Guidelines

FrankenGraphics wrote:
We're going to see a lot of CNROM this time around


Yup.

Author:  NESHomebrew [ Mon Nov 13, 2017 3:27 pm ]
Post subject:  Re: 2017 NESDev Compo - Rules/Guidelines

na_th_an wrote:
About your mapper specification, I think it's a great idea. It can be easily configured to act as anything the compo allows for and I guess less fiddling with the games should be necessary afterwards when building the multicart.

I agree!

Author:  calima [ Tue Nov 14, 2017 1:32 am ]
Post subject:  Re: 2017 NESDev Compo - Rules/Guidelines

"data in CNROM CHR pages" is something I've done several times, it's much nicer than PRG banking, if your data fits the model.

Author:  Sumez [ Tue Nov 14, 2017 2:00 am ]
Post subject:  Re: 2017 NESDev Compo - Rules/Guidelines

You mean similarly to how SMB hides the structure of the logo screen in the last few background tiles of the CHR-ROM? :)

It's nice, but you can only use it while rendering is off, obviously.

Author:  na_th_an [ Tue Nov 14, 2017 2:25 am ]
Post subject:  Re: 2017 NESDev Compo - Rules/Guidelines

It works for map data in flick screen games, for example :-)

Author:  tepples [ Wed Nov 15, 2017 9:44 am ]
Post subject:  Re: 2017 NESDev Compo - Rules/Guidelines

infiniteneslives wrote:
it might be worthwhile to settle on a simple homebrew "discrete" mapper design to simplify the rules and mapper specification for future compos.

Another idea would be a third user mode that resembles three existing discrete mappers: Uchuusen (78.1), Holy Diver (78.3), and Color Dreams (11).

EDIT: I've moved my proposal to another topic.

Author:  Sumez [ Wed Nov 15, 2017 3:52 pm ]
Post subject:  Re: 2017 NESDev Compo - Rules/Guidelines

What do these mappers allow that the other supported configurations don't?

Page 5 of 6 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/