We're making excellent progress on the Munchausen Flash Cartridge. arfink posted a video demonstrating the menu and loading from the PC:
Munchausen NES Menu Demo
I wonder how this compares to the PowerPak?
* Goal is to be able to run a good portion of homebrew stuff for low cost (current target: $40). Not for advanced homebrew using other mappers.
* Runs NROM (32K PRG, 8K CHR ROM/RAM) and MMC1 (256K PRG, 8K CHR RAM). Current prototype can hold two NROMs and one MMC1 at once. Future software upgrades will probably also allow 6 NROMs, without any MMC1s. With more juggling, it would be possible to fit 4 NROMs + 1 MMC1 or 10 NROMs.
* Programs can be loaded without removing cart from NES. NROM takes about 10 seconds to load, MMC1 about 55 seconds. Future software upgrades might improve this.
* Software upgrades allow other interesting features that I'm exploring.
* Included USB-NES cable can be used for interesting things besides just loading things on the cart.
* Made from SNROM board with fairly minor modifications, and plans will be posted for people to make one themselves. The minimal modification version on a board with a NEC MMC1 takes only 5 jumpers I believe, and of course replacing the ROM with an Am29F040B Flash chip.
So there's 8K of WRAM (battery backed) and 8K of CHR-RAM. Any way to expand the CHR-RAM?
blargg wrote:
* Made from SNROM board with fairly minor modifications, and plans will be posted for people to make one themselves. The minimal modification version on a board with a NEC MMC1 takes only 5 jumpers I believe, and of course replacing the ROM with an Am29F040B Flash chip.
What features does the Flash chip need to have to work with this thing? I have some spare W29C020C chips so wondering if I can use them. Of course they're only 256KB but that's not really a problem for me. Here's the data sheet:
http://www.gaw.ru/pdf/Winbond/w29c020c.pdf
Other Flash chips could be accommodated, though it'd require some changes to the driver code. Once I rewrite the driver to be more modular, it shouldn't be too difficult (right now it runs at 5.76 KB/sec using some crazy code that receives a byte as it calculates the CRC-16 of the previous and programs and verifies a byte into Flash). As long as you can get the bootloader programmed into Flash, it's relatively easy to get programming code working. The development setup allows running small programs in low memory or WRAM, so you don't have to be reprogramming the Flash chip in a programmer when getting the basic driver working. The chip you mentioned uses a different sector layout, so I wouldn't be able to write the driver myself unless I had one of the chips. I was thinking that we could just provide the preprogrammed Flash chip, that way they're all the same part.
Quote:
So there's 8K of WRAM (battery backed) and 8K of CHR-RAM. Any way to expand the CHR-RAM?
It shouldn't be too hard to put a 32K CHR RAM in, as it's also a 28-pin chip.
Compared to PowerPak, this is far more useful for developers. Can't say I'm particularly a fan of the MMC1, but whatever floats your boat, as they say.
This is pretty much how the loading was to work on the original Squeedo design. But this is a simpler mapper, and is cheaper with less firmware to work on.
Whenever I make that CPLD cart board I was talking about (in the battery-backed SRAM alternatives thread), the serial adapter for this would work well with it. It will have 32kB of CHR and WRAM, and a less annoying register setup (IMHO) than MMC1. I think it would be cool for example to release a game on it, and still allow the user to load their own program onto it if they wanted (either using unused part of the ROM, or backing up the full game and reloading it whenever they want).
For now it's only MMC1 and you can build it yourself out of an existing cartridge. What I would like to know is if it would be possible to put it on other type of cartridge like an MMC3? What would be required to be updated to be able to use this setup?
I wouldn't mind to have an MMC1 too for other type of testing but an MMC3 would be more useful for my current project . Or I could even go as far to say that I would built up to one per mapper that I want to play with.
Banshaku wrote:
For now it's only MMC1 and you can build it yourself out of an existing cartridge. What I would like to know is if it would be possible to put it on other type of cartridge like an MMC3? What would be required to be updated to be able to use this setup?
With the MMC3 (if you want CHR-RAM) the main concern is what happens you try to program the bytes behind the PRG bank select register.
You need some logic to select whether $8000+ writes go to mapper, or to ROM. You need a decoded address for the register, a latched data bit to hold the state selection. Or you can relocate the mapper registers, if you don't want to run commercial games without hacking them.
MMC1 is multicart friendly: it has a mode that kinda-sorta emulates NROM-128 ("Crazy Climber mode") and a 32 KiB mode that emulates NROM-256. It also has a well-defined way to switch between two independent MMC1 binaries (the SUROM trick).
MMC3, on the other hand, isn't very multicart friendly. It needs additional hardware to switch between games, as seen in
NES-QJ or
Mario 7 in 1 or
1,000,000 in 1. They could have done like TLSROM and abused the CHR bank lines to select a game as in SUROM, but 1. that doesn't allow selecting individual NROMs within a bank, and 2. all MMC3 NES games but
three use CHR ROM anyway.
Memblers wrote:
With the MMC3 (if you want CHR-RAM) the main concern is what happens you try to program the bytes behind the PRG bank select register. You need some logic to select whether $8000+ writes go to mapper, or to ROM.
It doesn't seem you would. Map the 8KB Flash bank you're currently programming to $C000, then do the $C555, $C2AA, $C555 program sequence and the only MMC3 registers you'll disturb are the IRQ reload and acknowledge, which you won't be using during programming anyway.
The possible problem is that the last bank is fixed. You need a bootloader to run when you power on. Maybe you could use one of the CHR bank bits as on the MMC1, assuming they power up with predictable values and that value is different than what an MMC3 CHR RAM program would normally write to them.
So yeah, an MMC3 version should work fine. Besides the bank select rewiring to the Flash chip, you'd just hook /CS to /CART on the NES bus, /OE to the /ROM CS output of the MMC3, and /WR to /WR on the NES bus, just as on the MMC1 version.
The cart's menu looks and sounds well designed. I also like the use of the controller port. Would it be possible to network two NES systems together?
Yeah, you could connect to NES units together and do asynchronous serial, though it wouldn't have any relation to the Munchausen, which simply includes a NES-to-USB cable (which is internally just a USB-to-RS232 adaptor connected to a controller cable). For NES-to-NES links, you'd connect two controller cables together, with Strobe and D0 cross-connected).
The USB-serial cable that will be included will of course allow some interesting things in NES programs. One thing I plan on releasing is an NSF player that runs on the PC but plays audio on the 2A03 (DMC wouldn't be supported, as that needs RAM at $C000-$FFFF). Could also do a silly audio player that streams sound at 22 kHz uLaw...
Ah, yeah that sounds right, I'm used to thinking of how CopyNES handled it (using the expansion pin). That made it simple to program Flash with every type of board. For MMC3 if you had to live with a permanent fixed boot bank, that's not too bad either (just point NMI and IRQ vectors into RAM and take the 3-cycle JMP penalty).
Jagasian: Networking would be much better done over USB. If one did it with the controller port, it would be easy for them to get out of sync (if doing other processing). Maybe a better setup would be to take a cue from the VS Dualsystem and use a USB host app to emulate/arbitrate a shared RAM area. Then would use an address/data port type setup to read/write a small number of bytes every frame (auto-incremented, or using address lists if needed).
Later on I want to get networking stuff going on the Squeedo revision, and I'll definitely try to make the NES code compatible with whatever hardware the Munchausen uses.
Good to hear that it could work with an mmc3. That get me interested.
I have another question. Sorry for my ignorance but I missed how you connect the cart for uploading the data into it in this current version. From the video (which I looked at it very fast) I didn't saw it. I think it's through the game port? If that's the case, how can you do it with an older famicom, not av one?
It would need to plug into the 15-pin expansion connector, that should work fine (with minor software changes, at worst).
I've been curious about writing to FlashROM through the PPU address/data (for CHR-ROM). I don't think I'll use CHR-ROM, but someone should try that out.
I'm also thinking one could use the NES Satellite (a 4-player adapter with infrared I/O) to make a wireless data connection to their PC. Pointless, but funny.
Memblers wrote:
It would need to plug into the 15-pin expansion connector, that should work fine (with minor software changes, at worst).
I've been curious about writing to FlashROM through the PPU address/data (for CHR-ROM). I don't think I'll use CHR-ROM, but someone should try that out.
I'm also thinking one could use the NES Satellite (a 4-player adapter with infrared I/O) to make a wireless data connection to their PC. Pointless, but funny.
Having recently been gifted a NES Satellite I might just try that out with the Munchausen prototype, just for kicks. I have no idea if it'll work.
What is the current status of this project? This sounds perfect for my budget and my development needs.
Can I get the schematics for the cart and USB->NES cable and code? More importantly, can anyone flash the boot loader for me?
Why not using SD/MMC cards with a custom format (file count + file offsets + files in iNES format, for example), so you don't have to implement a USB port, and also because SD's SPI protocol is far easier than the USB
What socram8888 suggested is called the PowerPak. And it uses CF because SD's SPI is far slower than CF's parallel ATA without some hardware assistance. Besides, to make something a PowerPak, even if it's just for one mapper, you still need a boot ROM and an SRAM the size of PRG ROM. Munchausen is supposed to be cheap.
Quote:
And it uses CF because SD's SPI is far slower than CF's parallel ATA without some hardware assistance.
SD SPI mode is really slow because you need to do a write for every read. In native mode you don't need to do that, with the drawback that you can read only 4 bits at a time. I haven't tried reading SD cards on the NES - but I have on the SNES, and I can read files at upwards of 200 kB/s with good cards and some minimal hardware assistance (no DMA or anything, just a kind-of latch that combines two 4-bit data reads into a byte that gets placed on the bus at the next write). I'm not familiar enough with the ATA protocol to say which is faster or easier to implement.
It might also have something to do that SD Card Association hadn't published the
non-confidential simplified specs to read SD cards when the PowerPak was first designed. Sure, it could have been designed with the FPGA doing most of the grunt work in collecting both nibbles or even clocking SPI eight times. But I guess at the time,
parallel ATA was better documented, being a subset of ISA.
Just thought I'd weigh in here, since it's been a while. The first round of hardware will likely ship to its owners soon, after which I am happy to release instructions and code for building these. They are quite cheap parts-wise, and pretty simple to build. Given the cost (less than $30 in parts to build if you're thrifty, even less if you're building a bunch of them or already have parts) I think the capability is pretty good. MMC1 with CHR RAM and WRAM, and also two NROMs on the cart at the same time, and a simple USB interface.
Release details and whatnot are coming. Thanks!
EDIT: Oh, and one other thing, I do intend to offer pre-programmed Flash chips for people, as well as making completed cartridges. This stuff will be licensed under some kind of non-commercial license, but I won't really care if you have your buddy make you a chip and even pay him for it.
Not like I can do anything, but it's nice to ask politely.
Any kind of time frame on this? I would really like to know before I drop $100 on an EEPROM programmer and an MMC1 dev board.
Thanks for all of your hard work!
Heh, unfortunately no. Hopefully before the month is out though, if I can muster enough hours to work on this.