Discretes for a Multicart w/menu

I'm working on putting together a multicart with a menu for selecting the game. It'll be Lorom only, no hi/lo switching.

I'm trying to do this with discrete logic instead of a CPLD or the like. Each game will be around 8mbit in size, a max of 4 games per cart. I assume I'll need some kind of latch or counter IC, but I'm not sure what kind I'd need to do this. Or how to get the IC to select the right bits after you select the game from the menu.

What i'd like to know is what you guys recommend for accomplishing this? Is it possible using discretes?

I'm not certain this will work correctly, but I think you might be able to do something like the NES's BNROM board, where you add a single latch that will respond to writes.

If /ROMSEL and /RD are both connected to the ROM, then connecting /ROMSEL and /WR to a 74'161 should let you write to the same address as the ROM occupies to switch banks.

So how would I get it to write to the correct banks to do the switch? Is that something I'd have to set up in the ROM or just how it gets wired?

I've written an NES multicart builder designed for BNROM. It was used for a homebrew multicart sold by infiniteneslives.com, and a second multicart with different games is in development. Let me explain:

You'll probably have to patch each game to write a bank number to your cart's register at reset time. This makes your menu program visible to the CPU. Once the user has chosen a game, write the game's bank number to the register and jump to that game's reset vector.

How big (in bytes, megabits, etc.) are these games? It's simplest when all games are the same size.

As it stands all games will be 8mbit. To a max of 32mbit on a cart.

I think I know how the ROM's address pins would be wired. Am I missing something?
ROM A21-A20 = 74HC161 outputs
ROM A19-A15 = CPU A20-A16
ROM A14-A0 = CPU A14-A0
ROM A1-A0 = 74HC161 inputs (using address instead of data avoids bus conflicts)
74HC161 reset = CPU /RESET
74HC161 load and clock = CPU /ROMSEL and /WR (or vice versa?)

You'll need to find several kilobytes in the first ROM for a menu.

Thanks! I can try wiring it up like that and see how it responds. Also sending you a PM tepples

I was assuming that you'd be starting from 4 separate ROM images and engineering a new multicart from scratch. But if you have an existing multicart ROM image, it is unlikely to behave as I described. If the author of that image is unwilling to describe the mapper behavior that it expects, you'll have to find someone more experienced in reverse engineering Super NES code than I am.

There shouldn't be any bus conflicts, if the ROM is enabled using /ROMSEL and /RD, and the 161 is written to using /ROMSEL and /WR.

I think that won't work, because in LoROM mode, /ROMSEL = '0' and /WR = '0' when accessing SRAM to save a game, so this would corrupt the counter.

My proposal is that you use a 74LS139 to decode SRAM/ROM and a 4-bit latch:




The 4bit latch input would be A0-A1 (or A0-A3, whatever you prefer), so whenever you write (or read) from $A0:0000, you set to boot the first game, $A0:0001, the second one, $A0:0002 the third, and so on.

I hadn't considered whether any games in the multicart had battery save. Even if one or more did, the games would have to have the same size of SRAM chip to pass the board self-test that a lot of games perform.

You could just apply cracks to those games if you were using them.

Thanks for the suggestions guys!

As it stands right now the games don't need saving, but i guess if i implement it now then it leaves the door open for later.

So if I wired it with a '139 and a '161, i'd still require the rom image adjusted so that after you select a game from the menu it would execute the appropriate instruction and read the right address, correct?