nesdev.org

Good news! Another mapper 'knocked-out'. Hearing Mike Tyson on the Bob & Tom show this week gave me a little extra motivation

So MMC2 is up and running, still need to actually test MMC4 too. It's as good as done though too with it's subtle differences between MMC2.

Wanted to verify this one before ordering the next batch. I've already converted most of this wire mess needed to run MMC2/4 into PCB traces for rev2.



I was actually kinda surprised how much logic the thing sucked up. It's only got 27 state bits but it's taking up around 38 MCells with all the other logic going on so it doesn't fit in the smaller CPLD's but oh well. Still fits in a single 72Mcell CPLD and the MMC4 should as well. I used a 74HC30 (8 i/p NAND gate) to sense CA3,6-11 high to reduce the number of I/O. So the second rev will have a SMT footprint for that guy.

MMC1 is still kicking my butt for some reason. It's practically working but for some reason CHR A11 keeps going high durring sprite fetches. It's the darnedest thing too because I was trying out SNROM and tried having the NES drive CHR A11 directly and the mapper doesn't even touch the signal. So I still gotta figure what's up there. One other weird thing is that there are 3 levels of 'severity' almost as if it's somehow related to CPU/PPU alignment. I put the oscope on the trace and I can see the line getting tugged high and everything. I'm going to try and debug using an original MMC1 to figure out where the bug's at exactly...

Anyways I should be ordering another batch next week after the Chinese new year. I figure I'll debug mmc1 while they're in production/shipping over here. Pretty sure whatever's going on with the mmc1 isn't PCB related so I should be safe.

That's great to hear that MMC2/4 is near done. And even better that on the next board revision it won't require all those wires! =) I'm sure you'll sort out MMC1, it might be one of those things where you feel silly for making a minor mistake. But who knows, it might be something more clever.

I received my boards just today and will get to try them out later today.

Awesome progress since the last time I checked! Maybe it would be cool to add another 8 pin IC footprint overlapping the Ciclone location for AVRCICZZ. It would be trivial to just run wires to the correct pin or cut the trace and rewire them but I figure it would take 2 min to add and it would be very nice to have the possibily to just drop the attiny13 on the board without extra wire/modification.

SkinnyV wrote:Maybe it would be cool to add another 8 pin IC footprint overlapping the Ciclone location for AVRCICZZ.

Yeah I actually already had the first rev set up for the t13 using Jim's Cool CIC 'tennis' for the SOIC footprint and the DIP was for the CIClone. The AVRCICZZ only has a couple signals swapped compared to the tennis. You could actually make them identical if you recompiled it. I'm actually dropping CIClone support on rev2 and replacing it with t13 DIP footprint so it'll support the tennis in both SOIC and DIP. So it in essence already supports AVRCICZZ if you rebuild it with matching pinout.

This is all looking great

Good news. Finally got out the second revision to be assembled. Pretty sure I can't fit much more on this thing... Should have the next batch available in about a month. Many thanks to all the people who tried our the first batch and provided great feedback for the next rev.

Aside from a few errors, there wasn't really anything that changed compared to the eariler rev. I really only ADDED things.

Additions:
1) Support for SOIC-44 PRG-ROM Flash up to 1MBytes. I made some connections via EXP0 that should allow this memory to be programmed via the kazzo or similar (cart edge alone) This would allow for a somewhat simple flash cart assuming CHR-RAM was used.

2) MMC2 & MMC4 support, no wire jumpers or anything. Just drop in your ROMs.

3) MMC1 all configs SXROM, SUROM, SOROM, SNROM, SLROM etc with a single CPLD and no wire jumpers. Still have to get the MMC1 debugged though. I wired up an original MMC1 and still had the same bug, grrr... Hoping to fix this before they show up in a couple weeks.

4) AY-3-8910 synth for Sunsoft-5A support. No wire jumpering. Just drop in the synth. The mixing circuitry is included in surface mount form. I'm actually planning on stocking up on synths soon, so people don't have to hassle with overseas ebay suppliers.

5) EXP connections. Connected up JTAG for the CPLDs and /RESET for the AVR used for the CIC. Doesn't really mean much, just makes assembly easier for me.

6) All discrete components are surface mount on the top side. Makes assembly easier, still have the through hole capacitor support for people interested in bare PCBs.

7) Discrete mappers are also supported by using surface mount '161/'32. The through-hole '377 and '32 are still there.

8) Slightly smaller board outline, since they were tight in original NES cases.

9) New design on the solder jumpers (see below). Basically this was the number one source of errors I had making games. There are over a dozen jumpers that need to be closed, but most of them are closed in the same position for nearly every configuration. It's pretty easy to miss one... So the board is 'pre-configured' for normal operations. If unique configs are used, then the little trace making the default connection can be easily nicked with an exacto knife. It can be easily re-made by solder jumpering again if desired. This also saves time on assembly. And since it's easier to ignore most of the solder jumpers I made a few more for things that became more common like PRG A12 mapper input, WRAM /WE -> PRG R/W, PRG-ROM A19 jumper, a few others for MMC2/4.



Aside from that I'm going to be working on a few other mappers while waiting on the boards. Starting to target some rarer famicom only mappers, and some multicarts. Going to test out Motzilla's NROM multicart, and thinking I'll give Farid's megaman multi a try. One easy addition should be mapper 78 (holy diver) in a single small CPLD. Thinking I'll give the RAMBO-1 a try at some point also. I'd like to start on the VRC's and Namco's and such as well, although I don't have the board set up for lower address bit inputs common on the VRC's and similar. I had a thought about giving the VRC-7 a shot at some point using an external Yamaha YM2413 OPLL. Yes it wouldn't be a true VRC-7 since there are some differences, but it'd be better than nothing at all. The VRC-7 is pretty hefty though, I might have a hard time fitting all the logic in 144 Mcells... We'll see how far I get on that list in the next month

MMC1 up and running Details here for those curious about what was racking my brain for the past month... Going to start testing out the various MMC1 PCB versions. So far only SNROM tested and verified.

Boards are being manufactured as we speak. Should have em in about a week along with a slew of parts to populate em.

Wow, this is looking fantastic Great to hear MMC1 is all fixed up, as well as the progress on the other mappers. Good stuff

Well the new batch showed up last week finally

They turned out kinda orange this time vice yellow like last time, but oh well. It's not the 'norm' so I'm still happy.

I've tested out most mappers that were working on the original boards. The 8910 synth's drop directly in now and everything seems to be working there. Had a small bug on MMC2 that showed up on the new boards and not the proto. I guess the new boards are a little faster than that wire mess I had previously because CHR A12 started becoming invalid. Turns out latching the addresses on the positive edge of CHR /RD is not a good idea. I found I had to put a pull-up resistor on CHR A12 to keep it valid long enough. Switched over to latching on the negative edge of CHR /RD and all is good (no pull up needed).

Still need to play around with the new PRG-ROM Flash and everything. Started investigating VRC's and realized they aren't actually that difficult to implement with my current setup. I've coded up VRC I & II so far, need to test them out still.

So far so good, no major errors and I'm liking the changes thus far. I have started taking orders on these. But I'm trying to get caught up with a few things and make up a good supply of them in advance before I list them up on my site.

As a kind of dirty hack, I was idly wondering how feasible it would be to use the AY-3-8910 to badly emulate the VRC6's audio. Obviously it's not trivial: the '8910 lacks duty cycle control, the sawtootth wave uses a ÷14 instead of ÷16 divider, and the AY-3-8910 expects indirect addressing while the VRC6 registers expect direct.

It's probably a terrible idea, but at least you can still buy NOS AY synthesizers.

lidnariq wrote:As a kind of dirty hack, I was idly wondering how feasible it would be to use the AY-3-8910 to badly emulate the VRC6's audio. Obviously it's not trivial: the '8910 lacks duty cycle control, the sawtootth wave uses a ÷14 instead of ÷16 divider, and the AY-3-8910 expects indirect addressing while the VRC6 registers expect direct.

It's probably a terrible idea, but at least you can still buy NOS AY synthesizers.

Yeah it'd probably be difficult to do without some level of rom hacking to go along with it but it is a interesting idea. I was actually considering trying out emulating VRC6 sound on a microcontroller and DAC. Of all the extra sound chips to emulate with a mcu I think the VRC6 would be a good place to start.

With the VRC7 I was thinking about trying to use the Yamaha YM2413 OPLL since they're still available to some degree. Yes it wouldn't be identical to the true VRC7 due to their minor differences, but for new music composition it might even be seen as an improvement. With only the one game that used VRC7 sound you're really better off to buy the original cart if you want 100% authenticity anyways.

That picture my friend is the closest thing we might get to NES porn I'll be keeping an eye on this project as I will probably buy one of the next board revision. Only thing I wish it could have is a port to program it without external hardware but I doubt this would be possible.

SkinnyV wrote: Only thing I wish it could have is a port to program it without external hardware but I doubt this would be possible.

Oh it's certainly possible the trick is to do it as simply as possible to keep the cost from being prohibitive. I'm working on it right now. My preliminary plan is here.

Pretty cool to see a board that mostly fills up the whole cart case. And the amount of option jumpers almost rivals Nintendo's Playchoice game boards, heheh.

Are you still using the XC9500XL family parts? I was curious what you're doing to reset yours. I've tried initializing the registers in the build options, and in the verilog (e.g., reg [3:0] PRG_PAGE_0 = 4'b1111;), but doesn't seem like it ever starts in the bank that I want. Did I miss something, or do I just need a dedicated reset pin? I hate to lose an input pin, but I need to move forward on a board revision.

I'm still using XC9500XL family for these boards. I love the lattice Mach XO2 family, but it's cost inhibitive for this project. Xilinx claims there is some way to designate startup of individual registers. I tried it once and wasn't successful.

In the processes window, right click 'fit' and then select 'process properties'. There is an -init flag that allows you to choose high or low startup value of all regs. FPGA equivalent is also a choice, perhaps that's what you have to select to designate start up in your verilog. I've had sucess with both startup high and start up low in practice. If you need different regs' to start up hi/lo I just use inverse logic so they can all start low or high together.

Couple other advanced notes. Under 'Design goals and strategies' there is also a means to select start up value. Don't trust it, it lies. You can verify the settings if you view the 'detailed reports' 'CPLD fitter report (text)' at the bottom it will tell you your selected settings. It wasn't until I saw this that I realized my CPLD wasn't really in low power mode like I told the design goals and strategies to do. It saved me ~30% power consumption when actually set properly. Additionally in the -optimize flag a few below the -init flag, I've found that 'speed' actually synthesizes to a macrocell or two smaller than 'density' most times. Messed up, but true in all my experiences...