nesdev.org

Moving right along...

I've got the programming interface completed (some IO extending within the CPLD). No more jumpers to swap around during programing. I've also got the valuable part of the .nes header stored inside the CPLD to implement the proper mapper, rom size, and mirroring etc. I've officially got NROM and UxROM support now with everything working cleanly. I'll be adding the rest of the discrete mappers after the boards show up and everything gets ported over next week.

At that point the project is pretty much complete as far as school is concerned. But I'll be keeping it going and start implementing come complex mappers and features. I'll test out qbradq's FME-7 and see if he actually has it working (where is he nowadays anyways?) Assuming there are bugs I'll work on getting MMC1/3 working then dig back into FME-7.

The other day someone mentioned that you'd be crazy to try to develop a game by testing on hardware alone. With this thing being so quick and easy to program it's not really much more cumbersome than loading up an emulator. Yeah I won't have all the tools of a emulator but I think I'm going to take that as a personal challenge to build my first game using hardware testing only, no emulator...

infiniteneslives wrote:The other day someone mentioned that you'd be crazy to try to develop a game by testing on hardware alone. With this thing being so quick and easy to program it's not really much more cumbersome than loading up an emulator. Yeah I won't have all the tools of a emulator but I think I'm going to take that as a personal challenge to build my first game using hardware testing only, no emulator...

I did that with Glider, it was definitely a fun challenge Didn't use anything but the screen for debugging, so there was lots of printing hex numbers, or using the grayscale bit as a notifier that something happened. I don't think it made me code any more carefully tho. Maybe if it took the 2 minutes to program and swap eproms it would have.

Got some progress and eye candy to share. The CPLD was a bit of a pain to solder. We had a stencil made up that helped out but we still had some shorts. Luckily we had some scopes available to get in there and see what we were doing to remove them. Everything else was cake to solder on. After we learned some lessons with the CPLD.

Got the board together yesterday and slowly moving though and testing all the hardware and connections before we start trying to do a full test with it playing games. I've got it recongized by USB now and should be playing games by the end of the week assuming nothing blows up

Last week with the breakout board set up I got all the discrete mappers working I've got about 6-7 mappers now and I started working on MMC1. Right now the bare bones programming interface and NROM mapper take up about 40-50 Mcells (~7% of available) and after adding most discrete mappers: UxROM, AxROM, BNROM, CNROM, M/GxROM, and colordreams all on the same configuration I'm using up about 110Mcells (~17%). By my calculations I shouldn't have much issue fitting MMC1, MMC3, and FME-7 on the same configuration as well with plenty of room to spare.

The more and more I play around with this Lattice CPLD I'm really happy with my decision to build with it. I like the IDE alot better than Xilinx and haven't had any issues with the whole set up really. Oh and I also was excited to see Lattice's larger MachXO2 cplds are available now. We've got the 1200 with 640 Mcells but the 7000 has >3400Mcells as one of the biggest 3.3V cplds on the market for cheap. Ours is $7.35 @ individual quantities and dirt cheap IMO at $6.40 for quantities of 25. The 7000 is only $15 with several intermediate steps between. They are pin compatible as well, so I know where I'm going if I fill this thing up. I'll have to ask Loopy how much logic his MMC5 is taking up at the moment.

[EDIT: images re-attached]

Ôh wow, this looks so fantastic

That's awesome! So are the EXP port pins connected (via buffers) to the CPLD?

How does this board differ from the PowerPak? I'm not asking about parts, technologies and such (although that information could be used figure out how the price will differ), but actual use in development/playing.

I'm mainly interested in development obviously, since I don't see much that can be improved about playing when compared to the PowerPak. The PowerPak lacks a lot as a development tool though, even though it's marketed as such.

Is it possible to integrate all the addon-chips on the japanese games?
FME-7 and MMC5 was one of them, but what is with the rest of them?

MMC5 will need 8192 microcells just for the 1024 bytes of ExRAM unless you put the ExRAM in a separate chip. Or do they make CPLDs with a block of RAM?

tokumaru wrote:How does this board differ from the PowerPak? I'm not asking about parts, technologies and such (although that information could be used figure out how the price will differ), but actual use in development/playing.

Would hope that the on board processor+USB will load games faster than the 5KB/s through controller port or 25KB/s through USB CopyNES. Maybe the USB can be used as a serial debug port too?

Would also be nice if it runs on clones

chykn: The EXP pins are buffered so that they can be I/O of the CPLD. But I was limited on I/O so I have little solder pads that could be used to jumper the signals to the unused I/O made available on the board. The only issue is the buffers are directional and I only set the data buffers up to beable to change direction. So EXP0-3 are always into the cart and EXP 4-9 are always out of the cart.

tokumaru: I really wanted this to be more focused as a development board. My goal was to provide for a lot of capability and remove limitations where possible. The biggest thing is the fact I've got the atmega mcu on board. It allows for a lot of things the powerpak can't do. The mcu provides the USB interface for quickly programming the memories on board. But it is also interfaced with the CPLD so that one could use it as a coprocessor or something if they really wanted playing around with dual ported memory or as a synth etc.

The other notable difference is I'm using a non-5v tolerant CPLD vice the power pak's 5v tolerant FPGA. The CPLD is convinent in that it's non-volatile and doesn't need to be configured at start up like an fpga. IMO it makes it simpler for a developer. That and any cart that would get produced would most likely be on a CPLD so it made sense to me that it was also. Keep in mind the write cycle limit on the CPLD's configuration FLASH is like 100K+ cycles compared the 10K of EEPROM cplds. The fact I'm not 5v tolerant also required level shifters to be used, but they make it easier to program the cart since you don't have to power off the NES or hold reset or anything.

The biggest goal was quick and convenient programming of memories. So it's set up where you can keep the cart plugged into the NES and your PC and when you've got a new build to test you just upload the .nes ROM to the host software on the PC. Then the buffers remove the cart from the NES reguardless of state and program the memories. At that point you would have to turn the console on or press reset if you left it running. No connections to be made or broken just click program and hit reset. And it's pretty quick ~10 sec or less for most games.

Also everything is open source and I hope to have tutorials and stuff on how to modify or create mappers making it a useful tool that doesn't need to be reverse engineered to make full use of for mapper and game development.

im-pulze: FME-7 is actually planned to be implemented as one of the first mappers. Lots of the MMC5's capabilities are easily possible but I can't be sure that it would all fit in the CPLD at this point. But realistically I could support any number of mappers if one was willing to design them.

tepples: That's one of the awesome things about the mach xo2 It has 10bit of distributed SRAM that can be configured as dual port without adding much more logic. I'm not certain I can do the full 1KB with this CPLD but I shouldn't have much problem with the larger cplds in the family.

bunnyboy: It's running at around 40KBytes/sec right now. There is some room for improvement though. One should be able to do some level of debugging via USB too but I don't plan to focus on this in the near future.

Also everything is open source and I hope to have tutorials and stuff on how to modify or create mappers making it a useful tool that doesn't need to be reverse engineered to make full use of for mapper and game development.

I'll buy one of these babies as a complement to my two Powerpak gaming carts for this reason alone :)

bunnyboy wrote:Would hope that the on board processor+USB will load games faster than the 5KB/s through controller port

It's actually 10KB/s through the controller port.

bunnyboy wrote:Would also be nice if it runs on clones

I was hoping that it would be. But I'm not sure of what all would make it incompatible. Why is it exactly that the power pak doesn't work on clones? One thought I had was that the clones usually operate at 3-4Vdc and there could be issues with power supply. This should be good in that respect, the level shifters will operate at whatever voltage they get supplied with. And the regulator is low drop out so it should operate without USB power if the console provides ~3.5V. Worst case it would have to have USB power to work with clones that operate at or near 3.3V.

My other thought was that there is some issue with the power pak programming of the memories being done by clone CPUs. Not sure what the exact issue would be there, but it obviously wouldn't be a problem with this since it's all done by the mcu here.

The only clone I have is a FCmobile II. I did test my breakout board set up with it and everything worked. But that didn't include the buffers and power supply circuitry that's implemented in the final design.

Figuring out the problem is on my todo list! Could be power (clones have weak power supplies), or a wiring problem (they expect CHR /A13 and CIRAM /CE to be connected), or something in the timing differences.

Designing for USB power might be a good idea anyways. That way you could do power on tests without losing the SRAM/CPLD contents.

Hmmm, what about hooking up a bluetooth spp module to transfer data?

They can be had for about $6:
http://dx.com/wireless-bluetooth-rs232- ... dule-80711

These things are pretty easy to interface with AVRs, I've used them for a few of my projects.