To make up for there being no multicart for the 2011 NESdev compo, I'm working on rewriting the menu system so that we can include the NROM entries from both last year's and this year's, as soon as I can drag myself away from Cracked.

Last edited by tepples on Fri Jan 13, 2012 6:06 am, edited 1 time in total.

That's something I wanted to add too. Making carts shouldn't take long at all, I mean Tepples engine probably isn't too bad to add games too, I don't see why it didn't get put together last year. At the least make it work on something like MMC1 and commission a repro maker to make the games.

I believe it could start in any bank. But another consideration, is that we can't know what bank it will be in the when the user hits reset - you'll always want some kind of reset vector available.

Because it uses the '161 which has a /clear input, I suppose it would have been possible to put an RC circuit (resistor-capacitor) on that, charged by Phi2 (M2). Kinda sucks I didn't consider that when I did the board layout, but oh well, it's only slightly annoying to add a bunch of 8-byte segments into LD65's configuration (8 bytes should be enough for mapper reset and JMP).

I imagine you'll have to replace every game's reset vector by the address of this 8-byte sequence as well. Could this possibly be a problem? I don't think many games use their reset vectors for strange purposes.

With some of these smaller games you certainly will want to fit more than one game per bank. The games true reset vector would be wherever it's convenient for the menu program (such as in a table that includes the NMI and RESET vectors of every game). In this case I normally set the ROM's NMI to point to $0170 or someplace odd that wouldn't be touched normally, the menu program can just put a JMP there. The "fake reset" triggered by the menu would be similar, but include a bankswitch write before the JMP.

With some of these smaller games you certainly will want to fit more than one game per bank. The games true reset vector would be wherever it's convenient for the menu program (such as in a table that includes the NMI and RESET vectors of every game). In this case I normally set the ROM's NMI to point to $0170 or someplace odd that wouldn't be touched normally, the menu program can just put a JMP there. The "fake reset" triggered by the menu would be similar, but include a bankswitch write before the JMP.

The reset vector doesn't even have to be the same in all banks, as long as you are willing to make the reset code larger than 8 bytes (so that it can bankswitch from RAM). This is a good idea if by any chance it's impossible to find a ROM location that's free in all games. Something like this should work if the menu is in bank 0 (finding 19 free bytes is harder than finding 8, but finding 8 free bytes in the same location in all games might be harder than finding 19 bytes anywhere):

Code:

Reset: ldx #$06- lda Bankswitch-1, x sta $ff, x dex bne - jmp $0000

Bankswitch: stx Bankswitch-1 jmp InitializeMenu

In banks that only have one game, the NMI vectors don't have to be changed. Some games have very timing-sensitive NMI routines, so this is a good thing. Hopefully this will not be the case for the smaller games.

Does BNROM guarantee that the first page will be swapped in at reset, or does every page need reset code?

Tokumaru guessed most of the design that I plan to use. NROM-128 automatically gets patched at $BFF0 if the reset vector is in $C000-$FFFF or at $FFF0 if the reset vector is in $8000-$BFFF. With NROM-256 or CNROM, the user must specify in a config file (the same one with the instruction blurbs) whether to patch 10 bytes at $FFF0 (more or less the Barbie stub) or 21 bytes anywhere (more or less the stub tokumaru listed). I also plan on storing the data that the patch replaces in the ROM's directory so that extraction of individual ROMs from the multicart is still lossless.

Memblers: Multiple titles can share a PRG ROM bank if the config file gives each game's entry point. These can even use CNROM if the game doesn't bankswitch after starting.

By loading the CHR bank assigned to the title before handing control over to the game. It's for things like Donkey Kong Classics, which combine two originally NROM-128 games into one CNROM. Games that switch banks after the game begins obviously wouldn't work. For example, the config records for four of the games might look like this:

Who is online

Users browsing this forum: No registered users and 4 guests

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