2017 NESDev Compo - Rules/Guidelines
Moderator: Moderators
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.
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.
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?
Interesting idea, providing I'm not misunderstanding it, did any actual NES games use that method back in the day?
Re: 2017 NESDev Compo - Rules/Guidelines
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:The cart's mapper "emulation" of CNROM games needs the banked CHR to be copied to CHR-RAM
There is.na_th_an wrote:Unless there is 32K of bankable CHR-RAM which I believe there is not.
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?
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?
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.
So, yes.
"32KB PRG-ROM plus up to 4 banks of 8KB CHR-ROM"
Yes. This is exactly what I'm doing.
nesdoug.com -- blog/tutorial on programming for the NES
- FrankenGraphics
- Formerly WheelInventor
- Posts: 2064
- Joined: Thu Apr 14, 2016 2:55 am
- Location: Gothenburg, Sweden
- Contact:
Re: 2017 NESDev Compo - Rules/Guidelines
We're going to see a lot of CNROM this time around
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
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.
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.
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: Select all
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.
Last edited by infiniteneslives on Mon Nov 13, 2017 3:12 pm, edited 1 time in total.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
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.
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.
Re: 2017 NESDev Compo - Rules/Guidelines
Yup.FrankenGraphics wrote:We're going to see a lot of CNROM this time around
My games: http://www.bitethechili.com
- NESHomebrew
- Formerly WhatULive4
- Posts: 418
- Joined: Fri Oct 30, 2009 4:43 am
- Contact:
Re: 2017 NESDev Compo - Rules/Guidelines
I agree!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.
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.
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.
It's nice, but you can only use it while rendering is off, obviously.
Re: 2017 NESDev Compo - Rules/Guidelines
It works for map data in flick screen games, for example
Re: 2017 NESDev Compo - Rules/Guidelines
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).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.
EDIT: I've moved my proposal to another topic.
Re: 2017 NESDev Compo - Rules/Guidelines
What do these mappers allow that the other supported configurations don't?