hey all the 2006 minigame comp is now running at
http://minigamecomp.org.uk
this years code sizes are 1k, 4k and 8k with different end times
I'm interested in joining the compo, but I would like to know how exactly the size limitations should be handled on the NES, since you can't just make a 1kb ROM, for example. I'm guessing you can only use the ammount of data you choose to use and clear the rest and forget it even exists.
And I'd like to know what exactly is included in this size limit. It's only the ROM (code, graphics and other data) right? RAM use is free, isn't it?
Yeah, RAM use is free. Any of you NESASM users better check also that your zeropage RAM is being used with zeropage addressing (NESASM seems to be kinda odd like that), to conserve ROM space.
Technically you can make a 1kB ROM, just push it all up into the $Fxxx address and higher. Just that iNES format doesn't like that, has to be padded, no big deal.
I experimented with all kinds of crazy crap when I was working on my minigames. Like uncompressing the whole program into RAM (wasn't too effective with RLE, worked great for some data though). And my favorite (and probably the most useful) was using zeropage RAM as the sprite RAM.
I doubt I'll have one ready for this year, but who knows.
tokumaru wrote:
I'm interested in joining the compo, but I would like to know how exactly the size limitations should be handled on the NES, since you can't just make a 1kb ROM, for example. I'm guessing you can only use the ammount of data you choose to use and clear the rest and forget it even exists.
Correct. One suggested format is UNROM (iNES #002) with only one 16 KB PRG bank and everything zeroed except $FC00-$FFFF.
Quote:
And I'd like to know what exactly is included in this size limit. It's only the ROM (code, graphics and other data) right?
Correct.
Memblers wrote:
And my favorite (and probably the most useful) was using zeropage RAM as the sprite RAM.
Doing such will force you to put everyother variables out of zero page RAM, so you'll most probably have it wasting space.
Also, it makes lda [$xx],Y totally forbidden, unless you reserve some zero page for pointers that correspond to sprite ram tile number and palette, and make sure that the vertical position byte previous to it is always $f0.
This is fool, however. Such small size limitation are not fair to make good games. Being able to spare size is usefull in the life, tough.
Bregalad wrote:
Also, it makes lda [$xx],Y totally forbidden, unless you reserve some zero page for pointers that correspond to sprite ram tile number and palette
You lose only 25% theoretical RAM efficiency doing it this way, as you can steal the tile, attribute, and X value of each sprite. Heck, as anything from $F0 to $FF works, you could use one hidden sprite's X value and the next hidden sprite's Y value to make an indirect ROM address in $F000 on up.
Well, I'll probably be shooting for the 4kb or 8kb limit, I'm not so hardcore as to go with 1kb. But all space is still precious, even with the higher limits.
tepples, why did you suggest UNROM? Couldn't I just use 16kb with plain NROM? Or doesn't it allow CHR-RAM?
EDIT: Oh, one more thing: the header does not account for the total size, does it? I'd guess not, since it wouldn't be there on a cart and is only used for emulation purposes.
tokumaru wrote:
tepples, why did you suggest UNROM? Couldn't I just use 16kb with plain NROM? Or doesn't it allow CHR-RAM?
NES-NROM-128 does not allow CHR RAM. The closest boards to NROM that allow CHR RAM are UNROM and BNROM.
Quote:
EDIT: Oh, one more thing: the header does not account for the total size, does it? I'd guess not, since it wouldn't be there on a cart and is only used for emulation purposes.
The rules state that headers used only by an emulator do not count.
CPROM is the closest to NROM to allow CHRAM, isn't it ? It has no PRG bankswitching, and only CHRAM bankswitching.
Bregalad wrote:
CPROM is the closest to NROM to allow CHRAM, isn't it ?
It's also rare. Do you think that both you and the judges will 1. have and 2. want to destroy a
Videomation cart?
the judges are anybody wishing to vote (obviously highly suspicious votes have to be disqualified, but they are rare)
Could someone please tell me what boards/mappers would allow for 16kb of PRG-ROM and no CHR-ROM? Even if they are very different from NROM.
But since we're already not using a huge chunk of the avaliable ROM space would it really matter if the total size were 32kb instead of 16kb? I don't think so.
nope 16k or 32k, does't matter to me, actually you could use chrrom if you wanted, you just lose being able to compress it, just make sure the tiles are together, straight after the code
You mean have the tiles uncompressed, using only part of the avaliable 8kb, leaving the rest free, just as with PRG-ROM? Could be.
But I don't think I'll want to give up on compression. Just didn't think of the best compression scheme for 2-bit bitmaps yet. It will come to me.
Good to know a 32kb ROM won't be a problem. I guess 16kb would just be cleaner, so I still want to know what mappers/boards would work with that and CHR-RAM.
tokumaru wrote:
Could someone please tell me what boards/mappers would allow for 16kb of PRG-ROM and no CHR-ROM? Even if they are very different from NROM.
If you want to wire up a board with CHR RAM to take a 16 KB PRG EPROM, then UNROM or Camerica with A14-A16 not connected is by far the most common one. SNROM and SUROM would work too. I'd imagine that BNROM would work too, as the lower bank would just get mirrored.
I consider the "fill unused bytes with zero" quite retarded. All real less-than-32kB carts repeat it's PRG throughout the whole PRG space, so why should the submitted entries behave differently?
Additionally, it rids you of the "you must not use the padding bytes as data!" remarks, and allows for some tricks with accessing the same memory at different locations. (not that it'd be extremely useful, but still)
True. Repeating the data over and over until the whole space is filled is a good idea. Maybe the rules to these compos should include that.
If you actually had a, say, 1kb ROM on the board, only the lower bits would have any significance in the address of the actual data, isn't it? Theoretically, could you actually place a 1kb, 4kb or 8kb ROM on the board and expect it to work? If so, NES ROM files should not have a minimun size of 16kb. Is that an ines bug?
tokumaru wrote:
Theoretically, could you actually place a 1kb, 4kb or 8kb ROM on the board and expect it to work?
Yes.
Quote:
If so, NES ROM files should not have a minimun size of 16kb. Is that an ines bug?
It's a bug. Galaxian and Game Genie were not dumped when Marat designed the iNES format.
tepples wrote:
tokumaru wrote:
Theoretically, could you actually place a 1kb, 4kb or 8kb ROM on the board and expect it to work?
Yes.
And the code would be mirrored through the whole PRG space?
Quote:
It's a bug. Galaxian and Game Genie were not dumped when Marat designed the iNES format.
I see. So, will emulators crash or something if I the iNES header says there is 1 16kb bank but it is actually 8kb? Or are current emulator authors doing some sort of check for this?
tokumaru wrote:
Will emulators crash or something if I the iNES header says there is 1 16kb bank but it is actually 8kb?
Yes. That, or they'll throw an error message saying the ROM image is corrupted. In any event, it definitely would not run, since the interrupt vectors wouldn't be filled in.
If you want to support less than 16KB of PRG ROM, you need to either mirror it or zero-pad it, and this competition generally requires you to use the zero-pad method with NES stuff.
If you used UNIF, however, you could theoretically make it as small as you wanted, though a fair number of emulators would probably have problems if you made it smaller than 4KB or so...
Bananmos wrote:
I consider the "fill unused bytes with zero" quite retarded. All real less-than-32kB carts repeat it's PRG throughout the whole PRG space, so why should the submitted entries behave differently?
Additionally, it rids you of the "you must not use the padding bytes as data!" remarks, and allows for some tricks with accessing the same memory at different locations. (not that it'd be extremely useful, but still)
and how are you suggesting to tell that the author is't cheating?
besides the rules cover *any* platform
RoboNes wrote:
and how are you suggesting to tell that the author is't cheating?
besides the rules cover *any* platform
Maybe the author should submit the files separtelly: the 1k/4k/8k ROM, the header, and a .bat file that will join things and make a working ROM image, repeating the PRG ROM as many times as necessary to fill the requirements of emulators.
This way the judges will easily know the actual size of the program, and will just have to click the .bat file before running the game on an emulator.
Of course, this would work for Windows PC's, don't have a clue about the rest.