I was directed here thanks to NA. I am looking for someone to put together a one off personal use multi cart. If this is something anyone can do here please let me know. Turn around time would be before Christmas.
If I am barking up the wrong tree please let me know too so I can figure out another solution.
Thanks in advance!
You need the software, the hardware (cart), or both?
What games are they? Are they games from the launch era, 24-40 KiB in size (easy), or are they newer games?
Not sure what you mean about software, but the games are licensed MM games I own. I would want a complete cart with a launcher for all 6 of the games.
According to just a quick search on a rom site the smallest one is 78k and the largest is 255k. I'm guessing that will be a problem.
tl;dr: Not easy.
Zipped size doesn't count; unzipped size counts. The games you name are 128 KiB to 512 KiB in size. Because the NES can't directly use this much memory, the games contain mapper circuitry to "turn the page", so to speak. A
mapper translates addresses between the CPU and PPU on one side and the ROM chips on the other. The six Mega Man games have essentially four different mappers:
- UNROM (Mega Man)
- MMC1 with CHR RAM (Mega Man 2)
- MMC3 with CHR ROM (Mega Man 3 and 5)
- MMC3 with CHR RAM (Mega Man 4 and 6)
Making a multicart of these would require the circuitry for UNROM, MMC1, MMC3, and additional circuitry to switch among the games. Or it would require reprogramming all the games to use MMC3 instead of what they currently use, and it would still need additional circuitry to switch from one game to the next.
What "thefox" meant by "software" is the program that takes several ROMs, adds a launcher, and outputs a multicart ROM. For example, if you were trying to make a multicart of The Legend of Zelda plus three early-NES-era games, you'd use
Forbidden Four. But if you
really want to make a multicart of these, make it for Game Boy Advance using
PocketNES, an NES emulator for GBA. Such a multicart will play on GBA, GBA SP, GameCube, Game Boy micro, DS, and DS Lite.
I'm afraid it's going to be quite hard. Megaman 1 is UNROM, Megaman 2 is MMC1, and the rest of the games are MMC3. Some of them use CHR-RAM, some use CHR-ROM. The combined size of the ROMs is over 2MB.
I think I gathered about half what you guys said. I have not looked into it much at all so a majority went over my head but the consensus is it wont work.
In my thread on NA this auction was mentioned...
http://cgi.ebay.com/ws/eBayISAPI.dll?Vi ... hqrbo%253D
Are the Japanese roms any different?
And this multicart needs to be for NES, unless the other solution you mentioned for GBA would somehow work on the NES.
Outinthedark wrote:
In my thread on NA this auction was mentioned...
[eBay listing for "Rockman 6-in-1"]
Are the Japanese roms any different?
Not really; Capcom used Nintendo's mappers, unlike some other Famicom game developers that used their own. But Chinese pirates have the time to mapper-hack UNROM and MMC1 games to work on MMC3 (which is straightforward yet time-consuming), and they have the resources to produce the circuitry (called the "submapper") that switches between games.
After mapper-hacking Mega Man 1 and 2 to work with the MMC3 (tedious, but definitely possible), wouldn't it be possible to use something simple like a 74161 for selecting the games?
Here are the ROM sizes for each game:
Mega Man 1: 128KB PRG, 0KB CHR;
Mega Man 2: 256KB PRG, 0KB CHR;
Mega Man 3: 256KB PRG, 128KB CHR;
Mega Man 4: 512KB PRG, 0KB CHR;
Mega Man 5: 256KB PRG, 256KB CHR;
Mega Man 6: 512KB PRG, 0KB CHR;
You could use 2 1MB EPROMs for the PRGs, one for Mega Man 4 and 6, and the other for 1 (shares the 256KB with the menu), 2, 3 and 5. The 4 bits that a 74161 can store are enough to select between the two chips (1 bit), a bank within that chip (2 bits) and between the CHR-ROM and CHR-RAM chips. Maybe the selection between CHR-ROM and CHR-RAM won't even need a dedicated bit if the games ordered in a certain way, so there will still be 1 free bit.
A 512KB EPROM could be used for CHR-ROM, and since only 2 games use it and each one is in a different PRG EPROM, the bit that selects between those can be used to select this too.
The problem would be booting up to a known state (so that the menu is the first thing to run) and preventing the games from overwriting the 74161 settings once they start making mapper writes. I figured that since there are revisions of the MMC3 that boot up to known states, and since none of the Mega Man games have extra RAM, the PRG-RAM protect bits of the MMC3 could be used to force the initial state of the 74161 and to prevent future writes to it.
I know that there are a lot of details missing, but this might actually be doable, don't you think?
tokumaru wrote:
I know that there are a lot of details missing, but this might actually be doable, don't you think?
Yeah, quite a substantial amount of work for a one-off item though.
I have a solution that is easier, but you're looking at $145+ in parts costs alone. Take a PowerPak, hack the boot ROM so it doesn't look as ugly, put it in a new case with the label you want. Done.
I've been kinda wanting to make a better PowerPak system ROM, but my time for hobbies is all used up by my own stuff. I'd do it professionally maybe, but it might not be all that cheap.
Memblers wrote:
tokumaru wrote:
I know that there are a lot of details missing, but this might actually be doable, don't you think?
Yeah, quite a substantial amount of work for a one-off item though.
I have a solution that is easier, but you're looking at $145+ in parts costs alone. Take a PowerPak, hack the boot ROM so it doesn't look as ugly, put it in a new case with the label you want. Done.
I've been kinda wanting to make a better PowerPak system ROM, but my time for hobbies is all used up by my own stuff. I'd do it professionally maybe, but it might not be all that cheap.
Yeah, you wouldn't even need to flash the bootrom really, since most of the magic happens in the 1K modules that are loaded from CF. Unfortunately it would show a POWERPAK text very briefly because that's included in the default bootrom (at least 1.0).
As for replacing the system ROM, if you mean replacing the menu system etc, yeah that would be cool. Like I said it's also possible to do it with just new files on the CF. I have most of that stuff reverse engineered, although I'm not sure if bunnyboy would want me to release it.
thefox wrote:
I have most of that stuff reverse engineered, although I'm not sure if bunnyboy would want me to release it.
Bunnyboy has benefited from work other people have done for the PowerPak, like mappers that were even included in the official package. I don't think he has anything to lose if a better menu is made.
tokumaru wrote:
thefox wrote:
I have most of that stuff reverse engineered, although I'm not sure if bunnyboy would want me to release it.
Bunnyboy has benefited from work other people have done for the PowerPak, like mappers that were even included in the official package. I don't think he has anything to lose if a better menu is made.
I guess for me, one issue I see is that essentially would be a hack, and I like to write code I can reuse. With no sources, no developer docs, no clear software license, sorta implies it's proprietary. I don't know if software can be retroactively licensed, but if so then I guess that could affect how I'm able to reuse my own code later.
thefox: One thing that I was curious to look into was to get actual file creation/saving to work. Probably not worth my time though since I don't particularly want to use CompactFlash in my own stuff, using SD instead where the NES doesn't even access it directly. On the easier side of things, it definitely could use a lot of menu improvements.
Memblers wrote:
thefox: One thing that I was curious to look into was to get actual file creation/saving to work. Probably not worth my time though since I don't particularly want to use CompactFlash in my own stuff, using SD instead where the NES doesn't even access it directly. On the easier side of things, it definitely could use a lot of menu improvements.
The FAT32 part is quite messy, I can tell you that much.
If I was to add file creation I would probably write it from scratch... would probably take less time than reverse engineering the existing code AND adding those features in it. I actually tried to use some C FAT32 library with PowerPak just for the heck of it, but couldn't get it to work and stopped trying after a while since debugging was a pain.
FAT32 sounds like a huge kludge in general. I thought of a hack of my own to get around it (what I planned to resort to if I have trouble with FAT in my design) - custom file system. Portable software used with a transfer cable would be able to translate it to whatever filesystem is native, (relatively) effortlessly during normal transfer operations.
And I think the same theory of operation should work with the PowerPak - however you would want to make a blank file to use a disk image, rather than using the whole memory card in the custom format. If that would work OK. I kinda wondered myself once I found out that PowerPak can't create save files, why there isn't just a large "saves.bin" file or something that it would use for that purpose. It wouldn't be too hard then to have a C program to run on PC, to extract/add files/format/resize the disk image.
Memblers wrote:
FAT32 sounds like a huge kludge in general. I thought of a hack of my own to get around it (what I planned to resort to if I have trouble with FAT in my design) - custom file system. Portable software used with a transfer cable would be able to translate it to whatever filesystem is native, (relatively) effortlessly during normal transfer operations.
Would this transfer cable connect to the NES (like Flash2Advance) or to the cartridge (like EFA-Linker)? If the cartridge, then you'd have to remove the cart from the NES every time, as opposed to just removing the CF from the PowerPak. If the NES, you'd need a failsafe boot ROM because the NES doesn't have a built-in "multiboot" client like the GBA does.
In addition, device drivers under 64-bit Windows generally have to be digitally signed. If you turn on the option to accept a self-signed certificate instead of a $200/year one, you'll get annoying always-on-top "Test Mode" warnings in all four corners of the screen. And no, running Linux or 32-bit Windows in a virtual machine doesn't count because the virtual machine's USB forwarder itself needs a signed driver.
tepples wrote:
And no, running Linux or 32-bit Windows in a virtual machine doesn't count because the virtual machine's USB forwarder itself needs a signed driver.
Are you sure about that?
At work I have a Windows 7-64 bit desktop pc. On that PC I run VMWare Workstation 6.5 and Virtual Box 3.something. In both I have VMs that run unsigned 32-bit drivers on Windows XP and Windows 2000. I can also run a full USB stack on Gentoo Linux inside a VM. VMWare and VirtualBox ship with signed usb-shim drivers for the host OS.
I'm pretty confident that generic USB devices plugged into a host, and tunneled to the guest, can be accessed on the guest using libusb or other non-device specific communications code. I do this with several developmental image scanners.
clueless wrote:
VMWare and VirtualBox ship with signed usb-shim drivers for the host OS.
Then I guess I must have got the wrong impression from all the tutorials for the "Test Mode" workaround, which implied that the VMs' USB forwarding drivers weren't properly signed yet. But even then, not everybody is willing to start Linux in a VM every time they want to copy a file to Memblers's card.
Quote:
I'm pretty confident that generic USB devices plugged into a host, and tunneled to the guest, can be accessed on the guest using libusb or other non-device specific communications code.
But the libusb driver itself needs to be signed to run on 64-bit Windows (except in a VM whose USB forwarder is signed), and as of today, it isn't because it has no corporate sponsor.
I would love to see a more visually pleasing file screen for the PowerPak Bunny's is effective but very basic in appearance.
That would require a bit more technical info about how the current PowerPak menu works, which in turn would involve contacting bunnyboy. Who has had meaningful, positive discussions with him in the past? I'm just worried about asking him on IRC myself because I appeared whiny once before when discussing options for saving.
tepples wrote:
Would this transfer cable connect to the NES (like Flash2Advance) or to the cartridge (like EFA-Linker)? If the cartridge, then you'd have to remove the cart from the NES every time, as opposed to just removing the CF from the PowerPak.
I would say it connects to the cartridge, and by extension, to the NES. Nothing would be more boring than a communication channel on an NES cart, that the NES couldn't talk to, heheh. So it would need to be in the NES (it's powered by it, and can be controlled by it), the only thing in the way is the cart door on a front-loader, and of course there's no problem with leaving that open during use. The cable would emerge from the finger-grip area of the cart shell, just like it does on MidiNES.
For a failsafe boot ROM (admittedly this was a problem with all of my older designs, because I really didn't want to write-protect the boot sector - I guess it would have helped if I had finished ROM code
) I've got a solution that will be 100% un-brick-able
and effortless to update, at least for my future Squeedo rev3 (which I've been pushing back further while developing other stuff, but I've been learning a lot throughout the process).
I guess I hadn't considered 64-bit operating systems, but that's not surprising because I've never heard of anyone who hasn't had a problem with them. Though my own PC's CPU is 64-bit, and with more RAM than I can use, I haven't seriously considered upgrading to 64-bit (at least, not while I can expect to run into problems with it). At any rate I'm definitely not gonna be writing an OS drivers for it, if it's needed I'll leave that to Microchip or whatever vendor made the chip I end up using (tho I'm pretty sure PIC32 will remain in the design).
Reviving, you guys were talking way over my head but it was inevitable it wouldnt work with roms or anything.
I tracked down a seller and managed to buy a copy of the pirate cart seen above.
Anyone know if this cart can be cloned or not?
Should be doable if someone reverse engineers the mapper...it would stil probably require an fpga to recreate though (so might as well go with powerpak)
- The front label shows the GameBoy versions of Rockman World, but I suppose they're the NES versions... obviously... eh?
Yes all are NES ..er.. Famicom versions. There is some hacking involved if I remember right, Rockman 3 had 30 lives added, and Rockman 4 (or 5?) had Capcom logo replaced by a oddly-colored robot-master-select-screen (just shows up for a split second, like the capcom logo did).
Also the picture of Rockman 6 on the cartridge is the artwork of Rockman 7 (SFC).
Outinthedark wrote:
Reviving, you guys were talking way over my head but it was inevitable it wouldnt work with roms or anything.
I tracked down a seller and managed to buy a copy of the pirate cart seen above.
Anyone know if this cart can be cloned or not?
Rather than clone it you could probably take a MMC3 board and heavily modify it to make your own Mega Man 6-in-1 cartridge. You just need to construct a master mapper to control whether the Menu or one of the 6 games is selected. It probably wouldn't be that hard. You'd just select approprate CHR-ROM chips for MM3 & 5 and CHR-RAM for the rest. Then also the appropriate PRG-ROM chips for each other. MM1 & 2 would need to be hacked to run on MMC3 but that shouldn't be a huge deal. Since 7 is an odd number ( Menu + 6 games) you could probably throw in that Rockman Board game to round it out. That or just latch the free slot (assuming you have eight) to also be the menu I guess.
MottZilla wrote:
Outinthedark wrote:
Reviving, you guys were talking way over my head but it was inevitable it wouldnt work with roms or anything.
I tracked down a seller and managed to buy a copy of the pirate cart seen above.
Anyone know if this cart can be cloned or not?
Rather than clone it you could probably take a MMC3 board and heavily modify it to make your own Mega Man 6-in-1 cartridge. You just need to construct a master mapper to control whether the Menu or one of the 6 games is selected. It probably wouldn't be that hard. You'd just select approprate CHR-ROM chips for MM3 & 5 and CHR-RAM for the rest. Then also the appropriate PRG-ROM chips for each other. MM1 & 2 would need to be hacked to run on MMC3 but that shouldn't be a huge deal. Since 7 is an odd number ( Menu + 6 games) you could probably throw in that Rockman Board game to round it out. That or just latch the free slot (assuming you have eight) to also be the menu I guess.
If anyone can pull it off you could.
The following information is about designing a new 6-in-1:
MM1: 128 KiB UNROM
MM2: 256 KiB SGROM (MMC1)
MM3: 256+128 KiB TLROM (MMC3)
MM4: 512 KiB TGROM (MMC3)
MM5: 256+256 KiB TLROM (MMC3)
MM6: 512 KiB TGROM (MMC3)
Total PRG ROM: 1920 KiB, just shy of a 16 Mbit flash. I'd put the menu in MM1's segment.
Total CHR ROM: 384 KiB; use a 4 Mbit flash.
UNROM-to-MMC3 appears doable in all cases. But how does MM2 configure the MMC1's banks? Does it use any modes other than switchable $8000/fixed $C000?
It'd probably take one CPLD or a few 7400 series chips to implement the following behavior:
Code:
7654 3210 $6000-$7FFF: Bank select
|||
|||
+++- Switch 256 KiB bank
Banks 0-1: MM4
Banks 2-3: MM6
Bank 4: MM1 and menu
Bank 5: MM2
Bank 6: MM3
Bank 7: MM5
In banks 0-3 (MM4 and MM6), the A18 output from the MMC3 is used and bit 0 is ignored.
In banks 4-7 (MM1, MM2, MM3, MM5), the A18 output from the MMC3 is ignored and bit 0 runs to PRG ROM A18.
In banks 0-5 (MM4, MM6, MM1, MM2), the CHR RAM is enabled and the CHR ROM is disabled.
In banks 6-7 (MM3 and MM5), the CHR ROM is enabled and the CHR RAM is disabled. The low bit of the bank number controls CHR ROM A18.
How would you go about constructing this master mapper? I thought of using a register to control the higher addresses and enabling/disabling chips. You'd write to this register by writing to $8000-$FFFF, but one of the MMC3 lines used to control WRAM (not used in any Mega Man game) would instead allow or disallow these writes. An address that doesn't interfere with the MMC3 much would have to be used for these writes, such as $A000 (if the menu is in the first name table, the mirroring can be changed at will).
What I'm not sure is how to boot to the menu. The register of the master mapper has to somehow be configured to map the menu in on power up. There's still one WRAM control bit free, so it might be possible to use its power up state to force the register to the value that selects the menu banks (for simplicity, this value could be all 1s or all 0s).
Sounds to me like the master mapper can be built with 2 or 3 chips (the register and some AND/OR gates).
EDIT: Mapping the register to $6000-$7FFF is a very good idea! But still, how are you going to boot to the menu?
Both multicarts with Nintendo World Cup (the US one with Super Spike V'Ball and the PAL one with SMB1 and Tetris) likewise put the mapper register in $6000.
tokumaru wrote:
What I'm not sure is how to boot to the menu.
Google power-on reset, and make sure the menu's bank number gets loaded.
I think we can do this with a 74HC161, a couple quad NANDs (74HC00), and some sort of POR circuit to generate a pulse on the 161's CLEAR input. I'd recommend against the sort of POR in the NES-EVENT board, which depends on a signal not present in toploaders.
tepples wrote:
a couple quad NANDs (74HC00)
Couldn't you avoid (at least some of) the NANDs by using a register with more bits than the 74HC161? For example, instead of using one bit to select between CHR-ROM or CHR-RAM you could could use 2 bits and control each chip directly. You'd just have to be careful to not enable both chips at the same time, something the menu would obviously never do.
I read a little about the POR circuit, but since I don't know much about this stuff I'm still wondering if it wouldn't be easier to use an output pin of the MMC3 with a known power up state (like the WRAM control bits) and AND/OR that with the outputs of the bank selection register to force all bits to 0 or 1. If the WRAM bits can really be used that way, you'd just switch them to the opposite value right before jumping to the address pointed by the reset vector of the game.
EDIT: You only have to force the PRG bits to a known state, the menu itself could do the CHR configuration. Does anyone know if the power up state of the WRAM control lines of the MMC3 is consistent? If it is, this mapper can probably be made with only 2 chips (8-bit register + AND/OR), although you'd have to use two PRG-ROM chips, because only the larger games will use A18 from the MMC3.
You need to enable the WRAM in order to enable mapper writes. You see, in the Nintendo World Cup multis, the MMC3 thinks the mapper is a 6264 SRAM.
tepples wrote:
You need to enable the WRAM in order to enable mapper writes. You see, in the Nintendo World Cup multis, the MMC3 thinks the mapper is a 6264 SRAM.
OK, but I don't think that matters, the WRAM lines can still be used to force the menu bank if their power up state is consistent. Once the game boots to the correct bank, no matter if mapper writes are enabled or not, you can copy the bankswitching code to RAM and jump to it. Then you can enable/disble WRAM at will (because RAM is always mapped, so it doesn't matter what happens to the ROM area) in order to stop forcing the menu bank, and finally properly select the boot bank and jump back to it.
EDIT: I'm just trying to propose the simplest solution possible, but if you guys, who know much more about hardware than I do, say that what I'm suggesting is not possible, I'll believe you. I would just like to know why, of course.
I love how when you guys all put your heads together you come up with some amazing stuff. Now if you could make this a reality and provide an IPS or some sort of loader to put this all together like Mottzilla did with his 11 in 1. Then the less educated like myself could enjoy such a thing.
marvelus10 wrote:
provide an IPS or some sort of loader to put this all together
IMO, the software is the easiest part... Hacking MM1 and MM2 should be fairly easy, the hardware part is the tough one!
Maybe I have got it all wrong, but once all the mapper ports were done and a menu screen created wouldn't it be as simple as finding e proms large enough and rewiring the selected PCB accordingly.
Tokumaru, if you did it your way with register bits being enables for various PRG or CHR chips, how would you wire that? Would you or rather could you, use the 74161 to control the power supply to each chip? Or would you use another signal? Just curious what your idea is for that.
I wouldn't trust me on this, since I'm not much of a hardware guy... But yeah, my idea was to use the 74161 (or something with more bits if 4 aren't enough) to enable and disable the various chips, as well as controlling the higher address lines to select the different games. I believe that the games can be ordered in a way that minimizes the number of control lines needed.
