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
Munchausen Flash Cartridge progress
Moderators: B00daW, Moderators
* 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.
* 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.
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.pdfblargg 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.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
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.
It shouldn't be too hard to put a 32K CHR RAM in, as it's also a 28-pin chip.So there's 8K of WRAM (battery backed) and 8K of CHR-RAM. Any way to expand the CHR-RAM?
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).
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.
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.
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.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?
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.
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.
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.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.
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.
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...
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.
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.