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)
2006 minigame competition
Moderator: Moderators
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?
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?
And the code would be mirrored through the whole PRG space?tepples wrote:Yes.tokumaru wrote:Theoretically, could you actually place a 1kb, 4kb or 8kb ROM on the board and expect it to work?
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?It's a bug. Galaxian and Game Genie were not dumped when Marat designed the iNES format.
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.tokumaru wrote:Will emulators crash or something if I the iNES header says there is 1 16kb bank but it is actually 8kb?
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...
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.
and how are you suggesting to tell that the author is't cheating?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)
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.RoboNes wrote:and how are you suggesting to tell that the author is't cheating?
besides the rules cover *any* platform
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.