Hi all! As I have mentioned a few times I am working on an MMC3 mapper implementation and a dev cart to go along with it. I am working with a local manufacturer that will do runs of 10 for me. I expect to have the prototype ready to go in Q4.
Anyhow, I need to figure out what features would be desirable to the community and what price point we are looking at.
Here are the features that I personally want:
2MB PRG-ROM
8KB CHR-RAM
8KB PRG-RAM, battery-backed
No provisions for CHR-ROM
USB interface for reading and writing all memory spaces.
I think I can do this for around $50 retail, all chips included with no soldering required.
Another option would be to include 256KB of battery-backed CHR-RAM so the cart could support CHR-ROM based development. This might add $10 or more to the cost.
Are there any other featuers you all wod like? What price would you be willing to pay?
Let me just say that I am looking to sell this product at cost. I am wanting to know what you would be willing to pay so I can get an idea of what features I can implement at the hardware level.
Thanks for your input!
One compromise between the tile animation capability of CHR ROM and the other flexibility of CHR RAM is a 32 KiB CHR RAM. Yes, this can be expressed in NES 2.0, and a 62256 shouldn't be that much more expensive than a 6264.
Do you plan to allow for both standard and TLSROM-style nametable mirroring?
Or a switchable fixed bank for multicart use?
For replication in quantity, how much would it save to leave off the USB access or use a smaller PRG flash?
tepples,
My current plan is to implement INES mapper 4 fumctionality only. I do not see how I could implement both mirroring standards while still being compatible with existing software.
One feature I am considering is adding new registers in the $5000 bank to support features like this, but that really just comes down to how many gates I have left over on the CPLD.
The USB intrface is a huge part of the cost of the cart. This will not be present on a production cart, nor would battery backed CHR-RAM.
I won't have a good estimate on the cost of the production cart untill I know how big of a CDLP I need, but I qm hoping to reduce the cost by using SMT parts.
If you're planning CHR RAM, you already give up compatibility with existing software apart from Mega Man 4, Mega Man 6, Ninja Crusaders, and a few Japanese-language RPGs.
One can ordinarily assume approximately one CPLD macrocell per bit of state. For an MMC3 clone designed for 2048 KB CHR ROM and 32 KB CHR RAM, I count 44 bits just for the bank numbers:
- CHR $0000: 4 bits
- CHR $0800: 4 bits
- CHR $1000: 5 bits
- CHR $1400: 5 bits
- CHR $1800: 5 bits
- CHR $1C00: 5 bits
- PRG $8000/$C000: 8 bits
- PRG $A000: 8 bits
Other state: 26+ bits
- Bank mode and bank register select ($8000): 5 bits
- Mirroring ($A000): 1 bit
- PRG RAM protection ($A001): 2 bits
- IRQ counter reload value ($C000): 8 bits
- IRQ counter: 8 bits
- IRQ acknowledge/enable ($E000/$E001): 2 bits
- Whatever additional bits are needed for the scanline count generation
Now we're up to 70 bits, dangerously close to 72, a size threshold that I remember from somewhere. And unfortunately, 5.0 V CPLDs appear far more expensive according to
this.
Dropping all support for CHR bankswitching saves 31 bits: 28 bank number bits, 1 CHR bank mode bit, and 2 bank register select bits. But you're still above 36, another threshold.
I have to admit I am ignorant wuen ot comes to actually implementing a CPLD design. This is my first. However I know Altera makes some pretty affordable 3.3v CPLDs that are fully compatible with 5v systems.
My HDL design is almost done, so I will know soon enough how many macrocells I will need.
You hit the nail on the head with the CHRRAM comment. Part of the reason for this thread is to see if I can get away with having no CHRROM support.
If you make a run of carts cheap and get people to use them for repros like nesreproductions and other sites, then maybe work on a version with developers on here to see what features would be liked. If you implement features nobody will use, what's the point?
I can't wait to see this done though, how much do you think a board will cost when it's done? And when you get the CPLD done, why only make in lots of 10? Don't you think the price would be way too high to use these instead of $5 donors?
(One thing I would like would be at least 32-64KB SRAM, heh.
)
Runs of 10 is for the development boards. I am fairly confident my market is right around a dozen folks, most of whom visit this board from time to time
And $5 donors do not have a convenient USB interface. Again my purpose with all of this is to reduce the barrier to entry for folks that may be attracted to the NES dev scene, and for folks wanting to produce production-ready games using MMC3.
I honestly have not looked into the repro market. That could be a great way to get some orders for the repro version of the board, but that would also involve a lot of "fitness for a particular purpose" type stuff.
Thanks for your input!
Yeah, there are only a couple dozen at most who will be developing TNROM games with the intent to sell repros.
But come repro time, a $5 donor isn't really a $5 donor if you have to desolder, rewire, remove the original label, etc. It can also increase cost if you have to keep versions for multiple regions' CICs in stock.
You can put me down for buying two of these development boards at $50 a pop (I'm willing to pay more if the price does increase), except that I'd like some clarification regarding 3 things:
1) Method of programming. There's no mention if these are EEPROM boards or what -- just a vague mention of "USB interface for reading and writing all memory space". I could interpret that as "you can use USB to flash an image to the board", or as "the USB interface acts as a real-time debugger of some sort" (how that would work is beyond me).
2) Will this thing have a proper/reliable IRQ counter per MMC3B standard?
3) Will the boards, for $50, include the necessary chips for things like battery-backed SRAM, etc.? (If not that's fine, just wanting clarification)
#2 is a deal-breaker for me with regards to purchasing the boards. No IRQ counter = no buy.
koitsu wrote:
#2 is a deal-breaker for me with regards to purchasing the boards. No IRQ counter = no buy.
Agreed. Without a scanline counter, the only advantages of TNROM over SUROM are 1. bankswitching of samples at $C000-$DFFF, and 2. slightly faster access to data spread across multiple banks.
koitsu wrote:
Will this thing have a proper/reliable IRQ counter per MMC3B standard?
Unfortunately, the MMC3 scanline counter is broken by design. All my programs are designed to fetch sprites from both pattern tables, a feature I consider one of the strongest points of the NES, because it allows games to have more diverse graphics.
tepples wrote:
koitsu wrote:
#2 is a deal-breaker for me with regards to purchasing the boards. No IRQ counter = no buy.
Agreed. Without a scanline counter, the only advantages of TNROM over SUROM are 1. bankswitching of samples at $C000-$DFFF, and 2. slightly faster access to data spread across multiple banks.
Why not just go the extra 9 yards and implement a CPU cycle counter?
So which mapper would tokumaru and Drag recommend cloning instead? Consider that this product is intended for developers, and developers will want to use a debugging emulator, so it'd be best to use a mapper that's already well supported in FCEUX and Nintendulator.
One slight problem with using a cycle counter is the authentic PAL NES, whose CPU runs at Fpx/3.2 instead of Fpx/3.
tokumaru wrote:
Unfortunately, the MMC3 scanline counter is broken by design. All my programs are designed to fetch sprites from both pattern tables, a feature I consider one of the strongest points of the NES, because it allows games to have more diverse graphics.
But shouldn't this be solved when you map the same banks of CHR data to both pattern tables (instead of switching pattern tables midscreen we may switch the banks)? Or are there any other benefits in using both tables for the same thing (either sprites or bg tiles)?
The first proposal is for a clone of a subset of TNROM, which has 8 KiB CHR RAM. It might even leave out support for bankswitching CHR entirely to save macrocells.
The advantage of 8x16 is that you have 128 different 8x16 pixel graphics for the sprites, plus all 128 pairs of background tiles. With standard MMC3 CHR ROM layout, you have only 128, not 256, distinct graphics available at once. You really only need 64 different graphics when using CHR RAM, but if you go this route, then you have to use up most of your vblank time copying in tiles.
Here are the advantages of using 8x16 sprites from both pattern tables:
1. You have more control over how you distribute your tiles. There is no way to increase the background tile count (with bankswitching you can, of course, but I'm not talking about that), but you can increase the sprite tile count at the cost of background tiles if you wish too.
2. Tiles can be used for both the background and sprites. This is useful for drawing things that move but can also be used as static background objects. Background objects can be destroyed and it's pieces can fly away, items can be available at fixed locations but they can also pop from enemies and fly around, all without having to duplicate tiles. Also, even you don't plan on moving certain objects around, you might still want to display them with sprites every once in a while just to use the sprite palettes, which could make your game look more colorful.
3. This is not specific to using sprites from both pattern tables, but with 8x16 sprites you get to display more sprite pixels per screen. O course there will be the occasional blank tile because object heights are not always multiples of 16, but since you can better distribute your tiles the blank ones are not so bad.
All 3 advantages are very important in nearly all my projects, and I find it sad the the most popular mapper ever prevents me from doing those things if I want to use the scanline counter, and without a scanline counter there's little advantage in using an MMC3.
I'm not sure what the best solution for a development mapper would be. Maybe if not many commercial games use the alternate scanline counting of the MMC3, or if the person making the carts doesn't care about the games that do (i.e. he's focused on homebrews rather than repros), an MMC3 clone with a proper scanline counter would be great.
If the scanline counter could be fixed to work consistently no matter what patter table configuration you use, that would be great, because we homebrewers wouldn't have to give up on built-in features of the console and most of the existing MMC3 games would work just fine too.
Maybe looking at how the scanline counter in the MMC5 works instead of pointlessly studying the MMC3 one could allow us to make a mapper that's essentially an MMC3 with a more consistent scanline counter. Now that's something I'd pay for!
tokumaru,
That is an very good suggestion. I will look into this! I too was sad to learn that you cannot use both pattern tables for sprite tiles with MMC3. My adventure game demo uses this.
As for making repros with this cart, I am not too worried about that side of the market. It's not something I want to pursue, and I'll leave it at that. I want to open the door to developing MMC3-based software secure in knowing you have a path to silicon already laid out for you.
Having good support for a debugging emulator is my top priority. This isn't worth anything without it. That is why I am using MMC3 as the model instead of making up my own mapper from scratch. If I did a custom mapper I'd have to write mapper plugins for Nintendulator and FCEUX at the very least to make it a viable development platform, and then there is the complication that it is much harder to release your software as a ROM image intended to be played on an emulator.
koitsu wrote:
1) Method of programming. There's no mention if these are EEPROM boards or what -- just a vague mention of "USB interface for reading and writing all memory space". I could interpret that as "you can use USB to flash an image to the board", or as "the USB interface acts as a real-time debugger of some sort" (how that would work is beyond me).
2) Will this thing have a proper/reliable IRQ counter per MMC3B standard?
3) Will the boards, for $50, include the necessary chips for things like battery-backed SRAM, etc.? (If not that's fine, just wanting clarification)
1) You will plug the cart into your computer via USB and use an application I will provide to flash a ROM image and SRAM dump onto the cartidge (while it is still in your NES, but with the power off). The same interface will also allow reading back the ROM and SRAM images. A command-line version of this software will be available for integration into a build script. The software will be DotNET-based and compatible with Linux via Mono. This will not include any debugging facility as there is not enough access to the system via the cartridge connector.
2) I will not release this cart unless the IRQ counter works correctly. Otherwise there is not much use for this cart.
3) The $50 price tag that I am hoping to hit is for a fully assembled board with surface-mount ROM and RAM chips, USB interface, mapper, battery and all other components already soldered on. This will NOT include a plastic shell as I have no way of manufacturing those. It will be a bare PCB hanging out of your dev system.
qbradq wrote:
1) You will plug the cart into your computer via USB and use an application I will provide to flash a ROM image and SRAM dump onto the cartidge (while it is still in your NES, but with the power off).
Reminds me of EFA-Linker for Game Boy Advance. Some of us might have to get a USB hub if the NES is more than 16 feet (maximum USB cable length) from the PC though.
Quote:
3) The $50 price tag that I am hoping to hit is for a fully assembled board with surface-mount ROM and RAM chips, USB interface, mapper, battery and all other components already soldered on.
Including a CIC, or will I have to cut pin 4?
Quote:
This will NOT include a plastic shell as I have no way of manufacturing those. It will be a bare PCB hanging out of your dev system.
I'd be willing to pay a bit extra for something using a RetroZone plastic shell.
If you want to make a MMC3 development cart and not have (re)production boards, I'd not be interested at all though. That defeats the entire purpose. I'd not be interested until there is a board I can easily reproduce programs on. The USB suite would be nice, but it's useless if there's no board offered to put these on without the USB developer tools. But even then, I'd not buy the developer version because I don't test every build on cart. So the development cart is useless. And plus for the $50 price tag if that is the final price, the proportionment for that single development cart and a PowerPak would make the PowerPak a better option because for $80 more, you get pretty close to every Nintendo mapper and tons of 3rd party. That's just what I see. If I'mm dropping $50 on a cart for one chip, I'd probably do the full $130 for powerpak. It's in the middle of a RetroPak and a PowerPak basically, and that's not an easy place to be.
3gengames wrote:
Developers will buy 1 "developer" board. Maybe 2-5 repro boards and put sockets in them, and will be done. Both things, you'll never get more orders from the dev since they then have the tools they need. You'll never sell that many of these to make it worth your time to help others out, truthfully.
I believe he knows this, and I find it admirable that he's focusing on software development even though that won't bring him much/any monetary compensation. We will, however, in the long run, hopefully have more interesting homebrews, because of the access to features that weren't easily available before.
Quote:
If you design these for MMC3 repro boards like the retrousb Retropak MMC1, that's what I'd probably buy.
I bet lots of people would, specially for making reproductions. We would however need this anyway, because once the games programmed with the aid of the development cartridge are ready we'll need a way to manufacture them in significant quantities.
EDIT: Man, you compltely edited your post while I was replying!
3gengames wrote:
If you want to make a MMC3 development cart and not have (re)production boards, I'd not be interested at all though. That defeats the entire purpose.
Earlier, qbradq wrote:
The USB intrface is a huge part of the cost of the cart. This will not be present on a production cart
qbradq wrote:
the repro version of the board
So consider the purpose not defeated.
3gengames wrote:
But even [with the USB port on the cartridge], I'd not buy the developer version because I don't test every build on cart. So the development cart is useless.
The nightly build goes on a cart for play testing. Builds go on a cart more often for raster timing testing, so that games don't have SMB3-style one-line glitches that annoy the [expletive] out of tokumaru.
3gengames wrote:
If I'mm dropping $50 on a cart for one chip, I'd probably do the full $130 for powerpak. It's in the middle of a RetroPak and a PowerPak basically, and that's not an easy place to be.
I already own a PowerPak, and I might buy one of these because I know that the repro version of the mapper will behave identically to the developer version. I don't want to rely on bugs in the PowerPak mapper, just like I don't want to rely on emulator bugs the way early homebrew games did.
tokumaru wrote:
I find it admirable that he's focusing on software development even though that won't bring him much/any monetary compensation.
That and the developer board can be considered the prototype of the repro board.
I thought I heard somewhere that 32k is the cheapest RAM size you can get today, so WRAM and VRAM should be bankswitched so you can use all 32k.
tepples wrote:
So which mapper would tokumaru and Drag recommend cloning instead? Consider that this product is intended for developers, and developers will want to use a debugging emulator, so it'd be best to use a mapper that's already well supported in FCEUX and Nintendulator.
I disagree with the idea what developers should restrict themselves to existing mappers. I would be happy to code for a new mapper, if that mapper made a better game possible.
Adding mapper support to emulators is not impossible. After all, at one point the existing mappers were not implemented.
If the CPLD can be programmed for a variety of mappers, then that would be great.
I'd like 8K (or even 4K) prog-rom bank switching, 32K char-ram, switchable in 256-byte blocks (yeah, I know, that would require a shit-ton of CPLD capability), in-game accessible flash storage or on-cart serial eeprom for saved games, 8K (or more) sram (skip the battery if cart has eeprom / flash)
edit: and a usable scan-line counter that can fire at least twice per frame, on user-selectable lines.
If you are making a repro, then of course you need a real MMC3. However, if that goal is to support future homebrew titles that want nifty features, then I see no need to restrict ourselves to establish mappers. If we make a game that is popular enough and want to release a rom image, the emus can be updated to support our new mappers.
clueless wrote:
I disagree with the idea what developers should restrict themselves to existing mappers. I would be happy to code for a new mapper, if that mapper made a better game possible.
Adding mapper support to emulators is not impossible. After all, at one point the existing mappers were not implemented.
...
If you are making a repro, then of course you need a real MMC3. However, if that goal is to support future homebrew titles that want nifty features, then I see no need to restrict ourselves to establish mappers. If we make a game that is popular enough and want to release a rom image, the emus can be updated to support our new mappers.
You make some good points but your vision seems somewhat boxed. Conceptually (idealistically) I fully agree that using a non-existent mapper is feasible, what I feel you may be forgetting is that many mainstream emulators *haven't* been updated recently.
Let's face it and admit it right now: on the Windows and OS X platforms, people predominantly use Nestopia, which hasn't received an official update in almost 3 years. There are already unofficial builds of Nestopia out in the wild; do you want another one thrown into the mix, making Nestopia into, effectively, MAME? (That is to say: 6 zillion versions of the same emulator, all with different tweaks/features/capabilities, forcing people to have basically 6 versions of the same emulator on their systems just to run different games)
People generally don't use Nintendulator to play games (it lacks user-friendly features that appeal to folks who, say, hook their PCs up to their home TVs, etc.), even though there's this idea running around that "Nintendulator has the most accurate PPU emulation of all emulators". That doesn't mean anything to someone who just wants to play/enjoy a game (nor should it).
Most people these days, not surprisingly (though depressingly), choose to use emulators as a full-on replacement for a NES. I'll admit happily that 90% of the time I use Nestopia instead of my actual NES (partially because the video output of the toploader is so poor[1]), and on very rare occasion use Nintendulator (I tend to use that for debugging/romhacking stuff and often wish its GUI features were less "wonky" in their behaviour).
TL;DR -- if you want to guarantee that your game gets the widest audience, you'll use a well-established mapper that works in the majority of mainstream emulators *and* is supported on PowerPak (or can be easily reproduced on a native cart). That leaves the "simple" mappers, and things like MMC1 and MMC3. People are going to go through hoops and jumps just to play your "weird game" on a "weird mapper" -- and though I'm technically skilled, even I won't go through those hoops. :-)
[1]: You know, the never-ending thread about that problem still has no concrete and well-written procedure on how to fix the problem on NTSC, where to get replacement parts (don't tell me to get them from a front-loader), what to solder to what, providing photos/diagrams, etc...
To solve that problem, I think it would be worthwhile to develop an emulator whose mappers are just simple script files.
That way, anyone could make whatever custom mapper they wanted, and you could add more mappers to the emulator without it requiring a complete rebuild. As an added bonus, make it cross-platform.
Wow, this is a great discussion folks. The options are many, and the real question at hand is what is best for the continued development of our platform.
How about using a subset of the MMC5 functionality (assuming we can wrap our heads around the IRQ behavior, I have yet to read through Drag's full post on the matter). I think if we leave out CHR-ROM support and 100% of the EXRAM features as well as the multiplier and sound it could fit on a fairly inexpensive CPLD.
tepples wrote:
One slight problem with using a cycle counter is the authentic PAL NES, whose CPU runs at Fpx/3.2 instead of Fpx/3.
I guess it's a tradeoff between flexibility and ease of use, not that big of a deal to me. Personally I'd like a CPU cycle counter more.
koitsu wrote:
TL;DR -- if you want to guarantee that your game gets the widest audience, you'll use a well-established mapper that works in the majority of mainstream emulators *and* is supported on PowerPak (or can be easily reproduced on a native cart). That leaves the "simple" mappers, and things like MMC1 and MMC3. People are going to go through hoops and jumps just to play your "weird game" on a "weird mapper" -- and though I'm technically skilled, even I won't go through those hoops.
I think many of those (us) who want to release their games on carts would actually be happy if it wasn't easy to run them on a PowerPak or emulators.
Drag wrote:
To solve that problem, I think it would be worthwhile to develop an emulator whose mappers are just simple script files.
That way, anyone could make whatever custom mapper they wanted, and you could add more mappers to the emulator without it requiring a complete rebuild. As an added bonus, make it cross-platform.
Separate emulator just for that?
Yeah it would be somewhat cool to have a scriptable mapper support in an emulator, but it doesn't really solve all of the problems because for people to be happy that should support would have to be in EVERY emulator they use.
BTW, Nintendulator already supports mapper plugin DLLs which is pretty much the same thing (not cross-platform, though).
EDIT: One more thing, just my opinion: I would prefer to see completely new homebrew mappers instead of trying to clone the existing ones.
thefox wrote:
I think many of those (us) who want to release their games on carts would actually be happy if it wasn't easy to run them on a PowerPak or emulators.
But is the improvement in copy protection worth the drop in efficiency of development from 1. having to be at home or work and next to an NES (as opposed to on your laptop), 2. having to send your binary to the NES every single time, and 3. not being able to examine RAM in real time or single-step the CPU?
Quote:
BTW, Nintendulator already supports mapper plugin DLLs which is pretty much the same thing (not cross-platform, though).
Can mapper plug-in DLLs for Nintendulator be built with free tools such as MinGW or freeware tools such as Microsoft Visual Studio Express, or does building them require the paid non-Express version of Microsoft Visual Studio?
Seems less useful to clone MMC3, there are far more people who will want it so they can build bootlegs of Final Fantasy 3 or whatnot compared to developers who could get good use out of it. That's one of the reasons I've completely stayed away from cloning mappers - they're far more useful to 'repro' builders than developers.
There's not much one can do about people that are using emulators that were written 5 or 10 years ago without a mapper SDK. Distribute a modern emu with your ROM? The game is supposed to be written for an NES, this is NESdev, after all.
Well, I guess this cart sorta competes with mine, but mine sounds a lot cheaper so far (a little different, but better than MMC3 IMHO). Supplying a dev cart at cost would be an awesome thing to do, but at $50 I'm sure you could do much, much better than that. I want to build mine in quantity, and the development version is 100% identical to the game-release version. The only difference is that with the dev version you would use an RS232/USB connector to the NES's controller port (or a CopyNES, whatever you have). But the cool thing is the port adapter is then usable with any cart.. it's not just tied to this one.
So what's the advantage of having USB on the cart instead of on the NES?
tepples wrote:
thefox wrote:
I think many of those (us) who want to release their games on carts would actually be happy if it wasn't easy to run them on a PowerPak or emulators.
But is the improvement in copy protection worth the drop in efficiency of development from 1. having to be at home or work and next to an NES (as opposed to on your laptop), 2. having to send your binary to the NES every single time, and 3. not being able to examine RAM in real time or single-step the CPU?
I was talking about the type of people who koitsu was talking about, those who don't want to "go through hoops and jumps". I'm sure a developer would have no problem using a mapper plugin or a modified version of that emulator while testing the game.
Quote:
Quote:
BTW, Nintendulator already supports mapper plugin DLLs which is pretty much the same thing (not cross-platform, though).
Can mapper plug-in DLLs for Nintendulator be built with free tools such as MinGW or freeware tools such as Microsoft Visual Studio Express, or does building them require the paid non-Express version of Microsoft Visual Studio?
I haven't done any (yet), but I'm almost 100% sure they could be built with free tools, because it's just standard Win32 API with no frills.
Memblers wrote:
The game is supposed to be written for an NES, this is NESdev, after all.
People will want to play the game before buying a copy. Now that there's no PlayChoice to demo a game on, the preferred method is to distribute an emulator-compatible version, as used by Sivak. And good luck making, testing, and distributing emulators for all major PC platforms (Windows, Mac, and Linux), unless you already own a Mac with a Windows license.
Quote:
So what's the advantage of having USB on the cart instead of on the NES?
The advantage is less brickability. You have to either A. have USB on the cart, B. have a separate bootloader ROM on the cart that loads new data from the controller port, or C. accept returns of developer cartridges whose boot sector has been overwritten by accident.
thefox wrote:
I'm sure a developer would have no problem using a mapper plugin or a modified version of that emulator while testing the game.
But who would accept the job of providing such a mapper plug-in for all major platforms that have emulators and compilers (Windows, Mac, and Linux)?
I like the idea of it in the cart, as USB CopyNES's are $70+ and to me, useless. Needless to say, I don't plan on getting one. I don't see what the advantage is over my EPROM burner and a cart for the mapper any program will be on. I'd be fine with a USB-NES Dev cart. That'd be something really nice to have which isn't done yet. But still, make reproduction boards and I will buy eventually.
And if there's a custom made mapper, if emulators don't support it, I'd probably rather have a official Nintendo ROM. Only being able to test on hardware to me is bad. The debuggers and tools we have to make development easier and faster are then pretty much gone. I don't see the point in losing those just for a mapper that may have a few extra features. I don't think we'd need to move on from the MMC1/MMC3 combo. If you need a new mapper for a game, than maybe you should be working on SNES games, or MMC5.
If I had my dream mapper, here's my specs:
1MB ROM support.
1MB CHR-ROM support with 8KB [Maybe 32K] CHR-RAM option.
Mirror selection, possibly with one-screen mirroring.
Scanline IRQ counter, despite never probably going to need one.
And lastly, 64K SRAM.
Maybe if others posted what would be liked in homebrew mapper, we could all find some good common ground in the specs.
3gen,
I agree.
Also, your desired specs fit a subset of mapper 5's functionality. Mapper 5 has a max 1M PRG-ROM, 1M CHR-ROM (assuming 4K banks are used, 512K max with 2K banks, 256K max with 1K banks), 8K CHR-RAM (NOTE: the actual MMC does not support this but most emulators do) and 64K PRG-RAM. It has a clean and easy way to use scan line IRQ and can support (without ExRAM) any mirroring combination you please except four-screen.
Best of all bank switching is single-instruction on the MMC5. This makes creating an atomic bank switching library a breeze.
There are no other features which I would require for a good mapper, and all of this can be implemented as a backward-compatible subset of MMC5. That should work on any emulator that can run CV3 (and probably several that don't
). Also, mapping that massive chunk of PRG-RAM into the ROM address space should not be a problem either. That's a huge win for folks working on RPGs and the like.
The last issue is compatibility with the PowerPak, but I'll bet TheFox can whip this up for PowerPak a lot faster than I can finish the HDL code for mine
I like the idea of a subset of the MMC5's features. The supported ROM size, bankswitching and mirroring capabilities, and the reliable scanline counter is all I could ever want from a mapper. Oh, and the extra RAM of course, but the rest is completely superfluous IMO.
Yeah, those are my only desirables and would love it. I don't even have any use for a scanline counter (yet) but when it comes to splitting the screen, it seems like it's be a life saver for when I do stuff like that. And the RAM would be great for some games that need to remember a whole map. My good example would be something like
this
Hardware multiply would be real nice too.
And why not just do the PRG-RAM (WRAM) in 8KB chunks? You know it has 8KB of space for WRAM, right?
Or maybe I'm misunderstanding you, I feel like I might be.
Yeah, the developers could use those boards, although I still think someone here should make some MMC3 carts soon....soo many donors die every week. Think of all those BFA donors! :'( Haha.
With MMC5 you can swap out the PRG-RAM in 8K chunks at $6000-$7FFF, but you can also swap that PRG-RAM into some parts of the ROM address space in 8K and 16K chunks.
Leaving out CHR-ROM support would save on a lot of things in the mapper. How do you all feel about that?
Adding the 8x8 multiplier would require adding a data bus interface.
I wouldn't mind, but others might. And AFAIK, You store the values to the MMC. Is that a problem?
tepples wrote:
Quote:
So what's the advantage of having USB on the cart instead of on the NES?
The advantage is less brickability. You have to either A. have USB on the cart, B. have a separate bootloader ROM on the cart that loads new data from the controller port, or C. accept returns of developer cartridges whose boot sector has been overwritten by accident.
Probably most of the PCs I've used were brick-able, I bet most cellphones are too, as well as anything that boots from FlashROM. But it's virtually impossible to accidentally erase flash memory, it's a very deliberate process. If the software uses the code that is supplied in the bootrom, then it it does become impossible. The only way I can see the boot bank being erased is if the PRG banking register is written to point to that specific bank before you do the command. But if you're doing stuff like that as bug, then your program is probably already crashing all over the place before it even gets to that point. And there is no way the CPU can crash and do random writes to initiate any command except a normal read.
So I'd say the brick-ability issue, IMHO is a non-issue. It wouldn't be a problem to repair those.
3gengames wrote:
I wouldn't mind, but others might. And AFAIK, You store the values to the MMC. Is that a problem?
No, that is not a problem. The only problem with driving the data bus for reads is that it requires 8 more I/O pins on the CPLD, 24 more registers and another combinational output. This means a lot more room on the CPLD is required, making it more expensive.
I think multiplications are a bit too much. Multiplications are only heavily used in novelty programs, for things like 3D and rotations, things you don't normally do in 2D games. If you really need fast multiplication you can always use a trick that uses a couple of small tables that is pretty fast, there's no need to waste mapper resources on this.
A decent scanline counter is much more important, because raster effects (split screens, status bars, etc) are much more relevant in 2D games.
Memblers wrote:
If the software uses the code that is supplied in the bootrom, then it it does become impossible.
Or if the IRQ or NMI handler or some other part of the game interferes with "the code that is supplied in the bootrom". I'd like to discuss your flash file system ideas in a new topic.
tokumaru wrote:
I think multiplications are a bit too much. Multiplications are only heavily used in novelty programs, for things like 3D and rotations
That and multiplying various speeds by 1.200 or 0.833 when in PAL mode. And multiplying the magnitude by the cosine and sine of the direction. It takes a bunch of multiplies to aim an antiballistic missile in my current project. But because those are limited to two per frame in the worst case, there isn't much of a problem even on NROM-128.
Quote:
A decent scanline counter is much more important, because raster effects (split screens, status bars, etc) are much more relevant in 2D games.
Agreed.
tokumaru wrote:
I like the idea of a subset of the MMC5's features. The supported ROM size, bankswitching and mirroring capabilities, and the reliable scanline counter is all I could ever want from a mapper. Oh, and the extra RAM of course, but the rest is completely superfluous IMO.
I too like the idea of a MMC4.99999 mapper. But I lack the relevant skills to size a CPLD for it.
Alright then, it's settled. For my hardware project I will be developing a sub-set of MMC5 aimed at compatibility with existing emulators. The design (MyHDL and Verilog code, micro-controller code, system schematics, PCB files and Gerber files) will be released under open software and open hardware licenses for the betterment of the community and the platform.
I will start a new thread to discuss the specifications of this mapper once I have them wrote up.
Thanks for all of your input!
Sounds like a great project, I look forward to the results. Good luck!
I do want to say one thing:
I like Membler's squeedo. I like qbradq's enthusiasm for creating something / anything more powerful than MMC1. I like options, and I think that it is wonderful that talented people contribute their expertise to the community.
For my next project, I might choose MMC1, Squeedo, qbardq1 or something else. I will choose a mapper because it is the best fit my the game balanced with production costs. A mapper decision is never meant to offend the creators of the un-choosen mappers.
Qbradq, I like the subset of MMC5 idea. But I might not use it, even though I endorsed it here. If I don't use your mapper, please don't take offense. Same for Membler's squeedo design.
I have a great deal of respect for people who can do things (generally intellectual) that I can't do (and I'm no dummy). Hardware design fascinates me, but I didn't study it much and choose a software path. So people who can make hardware are awesome, imho.
What I'm trying to say isn't coming out right... I sound weird when I re-read this before posting, but I wanted to put this out into the community anyway.
ps- qbradq, it should be feasible to modify a few emulators to handle your MMC5-lite mapper, just clone the existing one and disable some stuff. It would be interesting (but not the main point) to test games (like CV5 and Koei titles) on the new mapper so see if they still work. Or tweak an emu to log when each mapper feature is used, so that we can analyze what would break or not.
Now I have no plans to use the MMC5-lite mapper for repros. But I might base my next game around its feature set with the idea that I want to fabricate carts for a period of time.
Yep, like to see how this works out. Also, maybe it would be a good idea to use 32K CHR-RAM so you don't lose the advantage of CHR-ROM, so it'd be the best of both worlds.
And that sounds great, I like to see a homebrew mapper being made now. I can't wait! What mapper number will you pick?
@clueless:
I get your meaning. I won't be offended if no one uses this thing. My main focuses are to give people new to the platform an inexpensive and well-documented development process from emulator to silicon, and to create an option for current developers so they do not have to put up with sprite 0 hit-detection and 16 KB bank-swapping.
@3gengames:
I have looked into using 32K CHR-RAM. I am going to stick with zero CHR bank switching for the initial design until I get it fitted to a CPLD. Once that is complete I will see how many cells I have left over and see what can be implemented with them. Banking is very expensive on a CPLD though due to using many registers for each bank to remember what chunk of RAM / ROM needs to be loaded.
As this is a strict sub-set of MMC5 I have advised to use iNES Mapper 5 on your ROM images. A detailed implementation document will be provided. More on this in the (upcoming) planning thread.
Keep in mind another compromise, which uses only 10 register bits: allow only $0C00-$0FFF and $1C00-$1FFF to be banked and fix the rest of pattern space.
That would reduce the register count, and that is basically what SMB3 did
I will keep that in mind.
A major factor in how many cells we have to work with is the price of the chip. Depending on where the split is the price difference may not be that much. For instance, if we need more that 72 cells to implement the base functionality we go up into the $5 - $7 price range, and the difference between a 96 cell CPLD and a 144 cell CPLD is fairly small.
Also Tepples, thank you for the tip about each register bit occupying one macrocell. I had not gotten to the synthisis step yet to see this for myself and I mis-read the documentation. I thought a single register was 32-bits wide. Rather the documentation says that the integer arithmetic pipeline is 32-bits wide.