It is currently Wed Jul 24, 2019 12:15 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 116 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 8  Next
Author Message
PostPosted: Sun Dec 15, 2013 12:27 am 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1258
I think dual pal/ntsc compatibility is more than sufficient for the purposes of this compo.


Top
 Profile  
 
PostPosted: Sun Dec 15, 2013 8:08 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11376
Location: Rio de Janeiro - Brazil
SNES versions? Where did this nonsense come from?


Top
 Profile  
 
PostPosted: Sun Dec 15, 2013 2:13 pm 
Offline
User avatar

Joined: Sat Feb 16, 2013 11:52 am
Posts: 330
Hamtaro126 wrote:
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...

Edit: Added one!


What's with you and your crazy unattainable goals?

_________________
This is a block of text that can be added to posts you make. There is a 255 character limit.


Top
 Profile  
 
PostPosted: Sun Dec 15, 2013 5:45 pm 
Offline
User avatar

Joined: Thu Jan 19, 2006 5:08 pm
Posts: 760
Punch wrote:
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:

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

_________________
AKA SmilyMZX/AtariHacker.


Top
 Profile  
 
PostPosted: Sun Dec 15, 2013 6:19 pm 
Offline
User avatar

Joined: Sat Feb 16, 2013 11:52 am
Posts: 330
I would like to see a homebrew made with similar specs...

_________________
This is a block of text that can be added to posts you make. There is a 255 character limit.


Top
 Profile  
 
PostPosted: Sun Dec 15, 2013 8:46 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 2097
Location: WhereverIparkIt, USA
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.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Sun Dec 15, 2013 10:00 pm 
Offline
User avatar

Joined: Thu Jan 19, 2006 5:08 pm
Posts: 760
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.

_________________
AKA SmilyMZX/AtariHacker.


Top
 Profile  
 
PostPosted: Mon Dec 23, 2013 11:31 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 2097
Location: WhereverIparkIt, USA
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?

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Mon Dec 23, 2013 9:34 pm 
Offline
Formerly WhatULive4
User avatar

Joined: Fri Oct 30, 2009 4:43 am
Posts: 392
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.


Top
 Profile  
 
PostPosted: Tue Dec 24, 2013 1:19 am 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 1041
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).

_________________
.


Top
 Profile  
 
PostPosted: Tue Dec 24, 2013 7:06 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21511
Location: NE Indiana, USA (NTSC)
Quote:
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?

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.

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

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.

Quote:
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)?

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.

Quote:
Is there any guidelines relating to input devices? I suppose it should normally be using the standard controllers

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.

Quote:
The other thing I did not see mentioned, is whether or not mapper 28 has bus conflicts

It does not. The mapper 28 test tests this.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Tue Dec 24, 2013 11:53 am 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 1041
tepples wrote:
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.
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).

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

Quote:
Quote:
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)?

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

Quote:
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...
Yes, this is what I thought and what would be good idea.

Quote:
Quote:
The other thing I did not see mentioned, is whether or not mapper 28 has bus conflicts

It does not. The mapper 28 test tests this.
Thank you; that is what I thought, but wasn't quite sure.

_________________
.


Top
 Profile  
 
PostPosted: Tue Dec 24, 2013 1:06 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21511
Location: NE Indiana, USA (NTSC)
Quote:
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).

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.

Quote:
You could figure out with a debugger, what the low bit of the outer bank number will be

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

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Sat Dec 28, 2013 5:07 pm 
Offline
User avatar

Joined: Sat Feb 16, 2013 11:52 am
Posts: 330
tepples wrote:
Punch wrote:
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.


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

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?

_________________
This is a block of text that can be added to posts you make. There is a 255 character limit.


Last edited by Punch on Sat Dec 28, 2013 5:13 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat Dec 28, 2013 5:12 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21511
Location: NE Indiana, USA (NTSC)
Action 53 menu
Download "Menu source code" and look for files related to "pb53"

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 116 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 8  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group