nesdev.org

I'll mostly use it for gaming. That's what it's made for, and it will be strinkingly good at it from what I can tell, its only drawback to an emulator being the load time and the lack of external sound.

For development, it leaves a lot to be desired. Copying stuff to a CF card is just marginally less work than programming chips. I suppose a serial joypad cable would improve things, but this will be even slower than loading stuff from the CF card. And as there is no support for it in the boot ROM, the NES program you write would need to do the actual loading.

And while testing stuff on the PowerPak is hundreds of times more reliable than testing it on an emulator, I still advise people to test it with an actual AOROM/MMC3/whatever board if the program is intended to run on that. Otherwise, we might get a lot of lookalike-mappers to add to the iNES 2.0 format just to support homebrews.

In short, this is a gamer's device, not a developer's. That doesn't mean it's not in a developer's interest, as most of us usually love to play pirated games as well. And for the stuff you do release, people who use it on the real deal will most likely do it with a PowerPak, so it's in your interest to see your stuff run on it. :)

And while testing stuff on the PowerPak is hundreds of times more reliable than testing it on an emulator, I still advise people to test it with an actual AOROM/MMC3/whatever board if the program is intended to run on that.

For MMC3 (and any other non-discrete logic mapper) I couldn't agree more.
For AOROM (and any other discrete logic mapper) since the only thing there is to emulate in hardware is a simple latch, I doubt the PowerPak could be any innacurate as long as the mapper itself is implemented right, but I'd still test on a real cart for principe.

I still advise people to test it with an actual AOROM/MMC3/whatever board [...]. Otherwise, we might get a lot of lookalike-mappers to add to the iNES 2.0 format just to support homebrews.

This is my biggest fear, but face it: this will happen unless PowerPak's mappers are spot-on or they are tweaked so often that developers won't make things that only work on one revision of a PowerPak mapper. Or maybe PowerPak in its full power should be the target hardware, and the programs that run on it include a copy of the mapper code it runs with.

Why are you guys so scared of synthesized mappers? It's not as if MMC1 or MMC3 have any incomprehensible logic to mimic. Besides someone can always make test ROMs!

True, but it's not a replicable cartridge.

Why are you guys so scared of synthesized mappers?

It's synthesized mismappers that I'm scared of. Such things already exist in (almost?) every NES emulator, which is why testing with only an emulator is frowned upon.

If all commercial MMC1/MMC3 games work, chances are the logic is sound enough for homebrew, no?

kyuusaku wrote:If all commercial MMC1/MMC3 games work, chances are the logic is sound enough for homebrew, no?

Not necessarily, as there may be some special case that never appears in a commercial game but can appear in a homebrew project. It's much harder to prove that someething is 100% accurate than it is to prove that something is not 100% accurate.

Sure some undocumented and unused feature may be missing but at least we know that the known features work when a commercial game runs well. Homebrew authors are likely to use only features documented anyways unless the purpose of the homebrew is to reverse engineer hardware, but in that situation you would only want to use the original.

kyuusaku wrote:Homebrew authors are likely to use only features documented

They may intend on only using well-known features, but end up using obscure features too. There's no substitute for testing on an MMC3 if your program claims to work with it. On the other hand, an emulator author could create an emulator specifically to assist writing NES programs (games) that don't rely on obscure features. It would have many options for each mapper and main chips to warn if certain features are used. The main benefit would be many bugs caught automatically. Smart emulator authors already have something like this for debugging the emulator itself, where warnings are printed when weird things are done by the emulated code.

Using documented features doesn't always work, because it's possible for the documents to be flat-out wrong. I know I was really annoyed when my (really simple) MMC1 program followed all the docs, worked on every emulator (and probably still does), but gave me random results every time the NES was turned on (I didn't have a burner then, so I was stuck with the ROM as it was).

I think most of these out-of-production ASIC mappers should just be left to do what they were made for.. running the old games.

Then what mapper should new games target? And I'd rather not be stuck with A*ROM/B*ROM, which Squeedo is closest to, because of DPCM limitations.

That all depends... what features do you require, and how do you intend do distribute your creations? It all comes down to whether you want to make and sell your own carts, or are satisfied with your stuff running on people's PowerPaks.

tepples wrote:Then what mapper should new games target? And I'd rather not be stuck with A*ROM/B*ROM, which Squeedo is closest to, because of DPCM limitations.

UNROM is pretty decent (and Squeedo can simulate it, except it has 4-screen mirroring). It's also easy to reverse the banks with the same PCB, when having $C000-$FFFF switchable is desirable (I'm gonna use that setup for my upcoming 'Chipography' music release).

And I actually really enjoy doing new NES board designs. I'm pretty sure I could even come up with a fairly cheap way to do a scanline or CPU cycle timer interrupt. If it's really needed, I may be able to source some 74LS670s so both banks could be independently switched (but I might face a minimum order, so I'd have to be confident the game can use it with good success).

I'm still willing to offer my new board design service for free (well, at my cost.. $100). That should be easy to make back with a good game release.

tepples wrote:Then what mapper should new games target? And I'd rather not be stuck with A*ROM/B*ROM, which Squeedo is closest to, because of DPCM limitations.

Why not design a very powerful mapper that is inexpensive to produce, easy to emulate in both software and FPGA, and then use that? I mean, why write games for old mappers that aren't even manufactured any more?