NESDEV1 Community Development Board, Initial Planning

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderators: B00daW, Moderators

Post Reply
User avatar
qbradq
Posts: 952
Joined: Wed Oct 15, 2008 11:50 am

NESDEV1 Community Development Board, Initial Planning

Post by qbradq » Fri Apr 15, 2011 9:32 am

All,

This is the result of our previous discussion about building an easy-to-use dev board, together with the further discussion in this thread. The end result of this discussion was to create a replica of the Sunsoft FME-7 mapper using programmable logic that would be backward-compatible with existing emulators and development tools.

All related specifications, code (including Verilog files), schematics, PCB layouts and Gerber Files will be provided under open source and open hardware licenses. This will ensure that all who contribute (and have contributed) have a stake in the design, and that our community can freely use the design for the betterment of the platform.

Google Code Project
NESDEV1 on Google Code
Please email qbradq@gmail.com to request commit access.

Artifact Download Links
FME-7 Test ROM for Memory Mapping and Name Table Mirroring

Related Wiki Pages
NESDEV1 Development Cart
Sunsoft FME-7 ASIC Mapper

Implementation Task and Status
1. Specify the functional requirements of the mapper Complete
2. Specify the behavioral model of the mapper Complete
3. Create a test ROM for existing emulators to validate the behavioral model is compatible, and test in a variatey of emulators Working
4. Implement the mapper in MyHDL and Verilog in a synthesize-able form Working
5. Fit the mapper to a programmable logic device pending
6. Implement on-board programming code for micro-controller and workstation pending
7. Create a schematic for the development board pending
8. Create PCB designs and Gerber files for the development board pending
9. Construct prototype development board for testing and approval pending
10. Create schematic for the production board pending
11. Construct prototype production board for testing and approval pending
Last edited by qbradq on Sun Apr 17, 2011 3:59 pm, edited 5 times in total.

User avatar
clueless
Posts: 498
Joined: Sun Sep 07, 2008 7:27 am
Location: Seatlle, WA, USA

Post by clueless » Fri Apr 15, 2011 10:10 am

qbradq, based on my reading of your excellent MMC5_NESDEV1 wiki page, it seems that one would be able to reprogram the IRQ counter multiple times per frame, thereby being able to implement a top + bottom status bar, for example.

Can you confirm that your mapper will permit this?

Does the original MMC5 do this, and if so, do any existing games make use of reprogramming the IRQ timer within a frame after it has already fired?

I do with that you could support banking CHAR-RAM though. Games that have background tile animation generally make use of banking the char address space (char-rom usually) (like Crystalis). This is an effect that I really want to put into a game. I know that one can re-write char-ram during vblank, but that consumes lots of precious CPU cycles that are better used for updating name tables.

I understand that there is a limit to what a given CPLD can do, and a cost / feature trade-off. But maybe you can keep this in the back of your mind and tinker with it later?

User avatar
qbradq
Posts: 952
Joined: Wed Oct 15, 2008 11:50 am

Post by qbradq » Fri Apr 15, 2011 10:32 am

clueless wrote:qbradq, based on my reading of your excellent MMC5_NESDEV1 wiki page, it seems that one would be able to reprogram the IRQ counter multiple times per frame, thereby being able to implement a top + bottom status bar, for example.

Can you confirm that your mapper will permit this?
Yes, it will.
clueless wrote:Does the original MMC5 do this, and if so, do any existing games make use of reprogramming the IRQ timer within a frame after it has already fired?
According to documentation it does. I do not know of any commercial games that used this however. It seems like the commercial games that did use the MMC5 generally did not utilize it to its full extent.
clueless wrote:I do with that you could support banking CHAR-RAM though. Games that have background tile animation generally make use of banking the char address space (char-rom usually) (like Crystalis). This is an effect that I really want to put into a game. I know that one can re-write char-ram during vblank, but that consumes lots of precious CPU cycles that are better used for updating name tables.

I understand that there is a limit to what a given CPLD can do, and a cost / feature trade-off. But maybe you can keep this in the back of your mind and tinker with it later?
I know, this is a major limitation of this proposed mapper. What I plan on doing is implementing what I have documented, then fitting it for a CPLD. Once I know how many macro cells and I/O pins the base design requires we can see how much more it would cost to add CHR-ROM or CHR-RAM banking.

The ultimate plan is to develop an NESDEV2 that supports more features, and an NESDEV3 that supports much larger memory spaces (on the order of 4 MB ROMs and 1MB PRG-RAM). These two designs will be even more expensive to create both in terms of logic requirements and board space. For those reasons I want to limit the initial design to basically a (very) enhanced UNROM board.

Thank you for your input! If I have learned anything throughout the past several weeks it is that what I create hardware-wise is very much a product of the community. I could not even begin to do any of this without the contributions you all have made long before I got here, and those you continue to make.

User avatar
Bregalad
Posts: 8018
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Fri Apr 15, 2011 10:55 am

Sounds like an interesting project. However the flamed debate will come when it will discussed which features will be cut off and which ones won't....

Isn't there a way to "synthesize cheaply" the whole MMC5 chip ? :roll:
I mean this chip is over 20 years old and technology has advanced....
Useless, lumbering half-wits don't scare us.

tepples
Posts: 22331
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Fri Apr 15, 2011 11:16 am

Bregalad wrote:Isn't there a way to "synthesize cheaply" the whole MMC5 chip ? :roll:
I mean this chip is over 20 years old and technology has advanced....
CPLDs are cheap, but the ones designed to work in a 5.0 V environment are either much smaller (e.g. 36 to 72 macrocells) or far more expensive. FPGAs generally need a CPLD to load them at power-on. This takes time, and the CPU needs to have the reset vector yesterday. ASICs are dirt cheap in quantity, but the first unit is cost prohibitive for a hobbyist to make.

User avatar
tokumaru
Posts: 12042
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Fri Apr 15, 2011 11:30 am

clueless wrote:Does the original MMC5 do this, and if so, do any existing games make use of reprogramming the IRQ timer within a frame after it has already fired?
There are so few MMC5 games that it might be hard to find good examples of its features, but using several scanline interrupts per frame is nothing new, several MMC3 games did this. IIRC, MMC3 interrupts can be as close as 2 scanlines apart. So you can have up to 120 or so in the same frame. What happens in those interrupts is up to the programmer, but I don't why you couldn't have status bars at the top and at the bottom.
I do with that you could support banking CHAR-RAM though.
I second this request. Even though you can do a lot with 8KB of CHR-RAM, you really need CHR bankswitching to achieve that "16-bit" look, with large characters and lots of background animations.
I know that one can re-write char-ram during vblank, but that consumes lots of precious CPU cycles that are better used for updating name tables.
Even if you use all of VBlank for updating tiles, you can only update about 17 of them every frame with the fastest code possible. The "definitive homebrew mapper" should really allow more than 8KB of CHR memory.

User avatar
clueless
Posts: 498
Joined: Sun Sep 07, 2008 7:27 am
Location: Seatlle, WA, USA

Post by clueless » Fri Apr 15, 2011 11:54 am

qbradq's approach is very reasonable. Just get the MMC5_NESDEV1 working and see where the project is at. Personally, I won't be ready to start on a new game for a few more months anyway, and I will make do with MMC1 + 8K SRAM until I need more memory and more granular banking.

User avatar
qbradq
Posts: 952
Joined: Wed Oct 15, 2008 11:50 am

Post by qbradq » Fri Apr 15, 2011 12:14 pm

I am already needing more granular banking :D

The cheapest 5V FPGA with enough I/O pins I can find is $30 in single quantities. I am not too familiar with how FPGA's work, so I do not know what resources would be required to implement the 1KB ExRAM.

Let's just get this first draft of the HDL done and then see what we can do about CHR banking. One step at a time :D

User avatar
qbradq
Posts: 952
Joined: Wed Oct 15, 2008 11:50 am

Post by qbradq » Fri Apr 15, 2011 12:38 pm

Bummer, Nintendulator's MMC5 implementation does not seem to support CHR-RAM. FCEUX does.

tepples
Posts: 22331
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Fri Apr 15, 2011 12:42 pm

Programs must not turn off PPU rendering? Ouch. This will cause heavy loading times, as it'll take 51 frames to fill CHR RAM 10 tiles at a time. And how do you plan on handling presses of the reset button, which can occur on any scanline? Better would be to reset the scanline counter on $FFFA (NMI vector) reads.

User avatar
tokumaru
Posts: 12042
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Fri Apr 15, 2011 12:55 pm

qbradq wrote:Bummer, Nintendulator's MMC5 implementation does not seem to support CHR-RAM.
What the hell? Why would it do that?! Even if there aren't any MMC5 games with CHR-RAM, that's no reason for rejecting this combination...

User avatar
Dwedit
Posts: 4423
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit » Fri Apr 15, 2011 12:56 pm

This is similar to blocking NROM games from using CHR-RAM, or forcing CNROM games to have a 32k CHR cap.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

User avatar
qbradq
Posts: 952
Joined: Wed Oct 15, 2008 11:50 am

Post by qbradq » Fri Apr 15, 2011 1:02 pm

tepples wrote:Programs must not turn off PPU rendering? Ouch. This will cause heavy loading times, as it'll take 51 frames to fill CHR RAM 10 tiles at a time. And how do you plan on handling presses of the reset button, which can occur on any scanline? Better would be to reset the scanline counter on $FFFA (NMI vector) reads.
Yea, when I wrote the bit about never turning off PPU rendering I knew we had to find another way. That's why I posed the question in the MMC5 thread about detecting the end of the frame.

Is the NMI vector read if NMI is disabled? I'd rather have something that does not restrict the user's program architecture, flawed though it may be :D

As for resets I am not too worried about that. If we figure out a good way of detecting the idle PPU then the IRQ counter will hiccup on the first frame after you turn rendering back on, assuming you turn it back on mid-frame. If you wait until the end of the frame (like a good lil' coder) there will be no hiccup.

You could fool the IRQ counter by reading name table data via $2006 / $2007. Once we get this nailed down I think that and not enabling rendering mid-frame will be the only restrictions on using the IRQ.

More and more I am thinking that a CPU cycle counting IRQ would be a heck of a lot easier to use and less prone to total and complete breakage at the hands of the program. Unfortunately VRC7 does not implement the super-the-cool SRAM features everyone's so hot about.

Wow, this really is a balancing act if I've ever seen one!

User avatar
qbradq
Posts: 952
Joined: Wed Oct 15, 2008 11:50 am

Post by qbradq » Fri Apr 15, 2011 1:05 pm

tokumaru wrote:
qbradq wrote:Bummer, Nintendulator's MMC5 implementation does not seem to support CHR-RAM.
What the hell? Why would it do that?! Even if there aren't any MMC5 games with CHR-RAM, that's no reason for rejecting this combination...
I know, but this is definitely a challenge we'll have to face for this setup. That's why I've started on the test ROM so early :D The good news is Nintendulator is not used for playing ROMs (for fun anyway :D), and it has a modular mapper interface. I am looking into providing both a revised MMC5 mapper that would support CHR-RAM and an NESDEV1-specific mapper that would emulate the actual hardware mapper (for compliance testing of software).

User avatar
Bregalad
Posts: 8018
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Fri Apr 15, 2011 1:47 pm

More and more I am thinking that a CPU cycle counting IRQ would be a heck of a lot easier to use and less prone to total and complete breakage at the hands of the program.
Exept that a program won't be NTSC/PAL compatible if you use such a counter. Not that it is a major problem though, it's true, since you usually need to do NTSC and PAL variations because of the sound.
CPLDs are cheap, but the ones designed to work in a 5.0 V environment are either much smaller (e.g. 36 to 72 macrocells) or far more expensive.
What about doing it like the power pak : Put a 3V (or whatever it is) regulator on the cart and use pull-up resistors on all outputs ? I'm not sure how they did it for inputs but there is certainly a way.
What the hell? Why would it do that?! Even if there aren't any MMC5 games with CHR-RAM, that's no reason for rejecting this combination...
This is similar to blocking NROM games from using CHR-RAM, or forcing CNROM games to have a 32k CHR cap.
Well I don't know. I agree blocking CHR-RAM mapper 0 roms and caping mapper 3 roms at 32k is stupid (please don't confuse the board names and mapper numbers.... arghh I think everyone habe been doing this for years anyways).

If you look carefully at MMC5's feature, you'll see that the chip was fundamentally designed to work with CHR-ROM. Half of it's features (sparate banking for sprites and BG, ex-graphics, split screen) has been made to work with CHR-ROM, so that games could easily display much more than 512 tiles. So a MMC5+8kb of CHR-RAM combination would make very little sense since this will kill most functionalities of the MMC5.

I guess you guys assumed a larger CHR-RAM, then yeah I agree it would be cool, but you'd have problems writing to it on a real MMC5 cart modified to have CHR-RAM. All the CHR chip enable lines are driven by the MMC5, so if you'd just write the write pin to CHR WR, you might not get what you're expecting, because the MMC5 drives all the enable lines and all the higher adress lines.

In short I'll be very hard to control how to write to the CHR-RAM. You'd definitely want to totally disable ExRam and split screen when doing that, but even then there is still 2 sets of swapped banks. If you make it so that both matches, then *maybe* it would be possible to normally write to the CHR-RAM chip.

That being said, I agree CHR-ROM alone is not very exciting and quite limited. On another hand the MMC5 would make the best of it, so yeah...

I guess the only mapper who can handle more than 8k of CHR-RAM is the Namco one (no I'm not counting videmation's mapper because it can't do ANYTHING else), so maybe you guys would rather duplicate this one instead ? The main problem is that it's even harder to do testing on real Namco chips are they are only released in japan and usually are epoxy blobs.
Useless, lumbering half-wits don't scare us.

Post Reply