nesdev.com

You can call it "eight tee" or "infinite turkeys", something like that.

Not for sale yet.. this is just the prototype and I'm about to put it through a lot of tests.

I got the boards this week and have soldered this one, built the JTAG cable for writing the CPLD (verified), currently I'm writing a full test program so I can verify if it works. Once that is settled, if I don't need to redo the board, next step will be releasing a PowerPak mapper file. Once there are enough demos/test ROMs, then emulator support should be possible.


For larger images, see here:
http://membler-industries.com/memblers/pics/IMG_2089.jpg
http://membler-industries.com/memblers/pics/IMG_2091.jpg
http://membler-industries.com/memblers/pics/IMG_2092.jpg

There is a CPLD, but this is not a universal type of board. It's not a clone of any mapper, but I'd say it is most similar to MMC2 and MMC4 because there are PPU 'interrupt' tiles that can be used to automate CHR banking at nametable grid (BG) or scanline (sprite) precision.

Basic mapper specs:

• 512kB PRG-ROM - 16kB PRG page size (either can fixed, or both paged, 32kB mode also possible). Flash memory - 4kB sectors.
• 32kB CHR-RAM - 1kB CHR page (smaller CPLD can use 2 * 2kB paged, 2 * 2kb fixed)
• 32kB WRAM - 8kB page size
• 8 control registers at $5000 - $5038 - 4 bits wide
• NES Expansion port enable - creates 4 8-bit ports, NES can read or write to an expansion port device at $5038,$5039,$503A,$503B - for use with future synthesizer, network adapter, ?? (this requires front-loader NES though). Unfortunately, enabling this feature requires changing jumpers on the board and different firmware.
• Automated CHR bankswitching, also a CPU IRQ function (that comes with some side-effects, though)
• H/V/single0/single1 mirroring control register

Stuff that remains to be implemented, but should be do-able (not all at once though):

• 8 * 1kB CHR banking
• CPU cycle timer
• 4-screen mirroring, nametable bankswitching (either one requires changing jumper on the board)

To accompany this cartridge, I'm working on some communications software that will provide various functions, most importantly loading ROMs. I talked with blargg about his bootloader and I think we both came up with some pretty cool ideas.

Because of that, the USB adapter I'll build may have any (hopefully all) these features (I'll make another thread for this later):

• NES controller port to USB
• hardware flow control mode
• software flow control mode
• external reset - it needs NMI and/or IRQ/BRK activity, will fail if NES CPU is locked up - reduces need to manually reset NES during testing
• plus various software-based features (supported in Windows, should be portable to OSX and Linux) - so far only the serial communication is platform dependent.

So yeah, the PLCC socket is just for testing, pretty soon I'll try to make a kazzo script so I can solder a blank chip on, then write a bootloader onto it.

What can I say, very very cool stuff! Can't wait to get my hands on this. Hopefully this thread will not go unnoticed under this rarely used sub-forum.

Interesting to see a new dev board. I guess it won't get a famicom treatment since the crowd is too small for it.

Time to get back someday a toaster nes! I miss my square controllers.

Sounds like a cool mapper, I'm very interested!


Not great, because this has to be used for both PRG and CHR, since the board uses CHR-RAM. This means that some of the last commercial NES games are bigger than what this board can do, so theoretically we can't surpass a few titles made back in the 90's in some aspects, which is a bit of a let down.


Wait, there's only 1 switchable 1KB slot? That doesn't make much sense, but based on the list of "stuff that remains to be implemented" (where you say "8 * 1kB CHR banking") it does sound like it. In this case I'd much rather have 2 2KB fixed + 2 2KB switchable.


Automated CHR switching is nice and all, but not very useful. I can't think of any other use for this other than drawing title screens, cutscenes or status bars. An IRQ function on the other hand, can be used to switch tiles as well as for many other useful effects (scroll splits, color emphasis changes, etc). So, if the automatic switch is just a way for lazy programmers to avoid manually doing the bankswitching, I'd rather give up that feature and improve some other aspect of the mapper (possibly the IRQ function).

Also, I'm interested in what the "side-effects" of the IRQ function are.

Half a meg is as big as Mega Man 5 and 6 and Super Mario World. Kirby's Adventure is the only licensed NES game bigger than this. But perhaps you can extend it a bit with the Codemasters-derived codec that you RE'd.


I chatted with Memblers about this at MGC back in March. It's sort of a compromise between ability to rewrite a few CHR tiles every frame during downtime (Battletoads style) and ability to rotate CHR (SMB2/SMB3 style). Choose one method for sprites and the other for background. More switchable slots means more state bits on the CPLD, and state bits get expensive on 5.0 V CPLDs.


That or text in an RPG, if it's anything like MMC2/MMC4. Dedicate one bank to a 128x32 pixel pseudo frame buffer, as in Faxanadu or Super Bat Puncher, and you can use it draw dialogue with mid-scanline bank switching.

Sounds pretty good to me, almost everything I personally wanted. 2KB eatra nametable RAM and you'd totally please me if I were to pick a custom developer board for sure. Sweet stuff memblers, I hope this satisfies most people's needs.

I too like chr-rom, but I guess it would be easier for me to make my chr-rom game chr-ram than it would be for anyone else to do vice versa. I take it the WRAM can't be battery backed?

Four screen mirroring could, at least in theory, use some of the available 32K CHR-RAM for nametables.


If I remember correctly, the plan was to use the Flash PRG-ROM for game saves. Some of these chips make it possible to write protect certain sectors, which makes it practically impossible to accidentally overwrite actual PRG-ROM data.

Well I mean, it has 4x banks of 8KB of CHR-RAM, so you lose no benefits of CHR-ROM and still have the advantages of CHR-RAM just as long as you write what you need. It'd take a while to write 32KB, even 16KB, but if you really hate the waiting inbetween screens or whatever, you can always only used 16KB and during the game running and upload the next 16KB if you'll need it and can tell you're about to switch character sets.

Opinions for your Mapper:

1: If needing an IRQ: Something that is seperate from CHR, and it has to be Easy and Simple

2: I'd like a DMA Mode for CHR-RAM, much like Gameboy, SNES and One-bus.

3: Custom Nametable Mapping (See Opinion #4 for why)

4: If possible, use another mode flag, so if it is enabled, add layer 2 for $2800 and $2C00 (with seperate scroll regs, normal NT operation.)

_________________
AKA SmilyMZX/AtariHacker.

Yeah, I know. It's not bad, it's just not great. For most projects 512KB is enough, it's just that there isn't much room left for experimenting beyond what was already done on the NES... You know, silly stuff like FMVs and such. Anyway, I know 512KB is just fine for most uses.


I see... so it really is just 1 switchable slot. Well, If that "costs" (I don't really know how you count CPLD resources) as much as 2 switchable 2KB slots, I'd much rather have that. If the cart is capable of both, I wouldn't mind having sub-mappers for the two kinds. In fact, I imagine that all the stuff that can be customized through jumpers would result in a lot of possible combinations, which would have to be identified by different mapper numbers or sub-mappers, right?


I don't know... I feel that there are very few uses for this, and if having this feature means crippling the IRQ function, I don't think it's worth it, because you can do so much more with decent IRQ functionality.


I grew fonder of CHR-RAM over the years, and if it can be bankswitched, like in this cart, it feels almost the same as CHR-ROM.

Memblers, please don't think that I'm complaining or anything, I'm just expressing my opinions about the few weak points of the mapper. My overall impression is very positive, and I really appreciate your initiative to create something this useful for the NES homebrew community. I'm very interested in this.

DMA from PRG RAM to CHR RAM would take an MMC5-scale ASIC or FPGA to implement, and we don't have that kind of money. Why do you want to update more than ten tiles per frame?


What kind of layer 2? Do you mean parallax scrolling? That would require pretty much an entire PPU on a cart, as was done with Wide Boy for Famicom and Super Game Boy for Super NES. That too would need an ASIC or FPGA comparable to the PPU. The attributes would be taken from only one of the layers, causing Spectrum-style clashes left and right.


CPLDs are sized in macrocells. Each macrocell can hold one bit of state, and occasionally very complex logic may require macrocells to be paired up. Most large CPLDs nowadays are for voltages lower than 5.0 V, and large 5.0 V CPLDs are very expensive.

Great work on this. Thanks for the pictures and update!

What have ya got on this for a CPLD? 72 macrocell?

Thanks for the feedback and everything. I wasn't able to get it running on the first try, so it's debugging time.. Despite that, it's still really exciting to work on.

But yeah this board will be a platform for more than one mapper, it would make sense to use iNES submappers when it's emulated later, I think. I'm willing to customize it to whatever features are needed (within it's limitations of course, heheh).

The mapper I've defined currently fits into 36 macrocells and 34 I/Os. Because of demand for more features, I might standardize on the 72 macrocell part - or have them both produced eventually. It's only like $1.10 cost difference, which is nothing on a devcart, but maybe worth saving when a game is produced. It is a 3.3V CPLD, but it has 5V-tolerant inputs. Part U7 on there is a 3.3V regulator.

The CPU cycle IRQ, and 1kB CHR paging is in the unimplemented category since it's stuff that should fit now that I'll have twice the resources, I just haven't written the verilog for those parts. As soon as I get it running, those will be one of the first things to try. But just getting the basics is first.

The CPU cycle IRQ what I had in mind, was to try and use a timer with a pattern like 113,114,114 and an equivalent table for PAL. Another useful possibility is a plain CPU cycle timer, but I believe 15 bits are needed to cover an entire frame. That + compare value is 30 bits already, but I believe that would still fit in the 36 extra macrocells.



That's a feature I want for my Squeedo rev3 design (in the future), which will use an FPGA and be an epic mapper, but will definitely be more expensive. Being able to scroll nametable or CHR data on cart might be kinda cool, I hadn't thought of that.



Yeah, 512kB isn't nothing new, but having 32kB of WRAM I think makes a difference because it allows for more use of compression than previous games. And actually too, while it's maybe not useful for FMVs specifically, with the communication server I'm working on, the NES->USB adapter can become sorta like the Disk System but with gigabytes instead of kilobytes. Even with sound, I'm kinda thinking I can build the PC version of my Squeedo synth into it so it can still be used with the NES without having to own the actual synth in hardware (though it'd be very preliminary until the synth hardware is created and tested).

With the IRQ (when using CHR as IRQ source), the side-effect is that when you use the special tile, it regards the entire tile as a hit, and since the tile covers 8 scanlines, then the IRQ will trigger 8 times. The work-arounds are to either handle the repeated IRQs, or have your IRQ routine use up over 900+ cycles before acknowledging the IRQ and returning from it. It's really just a hacked-on kind of thing, since it can share the CHR banking logic easily (either mode is selectable during run-time, but can't be used simultaneously). Another thing is that I don't know how close to hblank the IRQ will be triggered - if you have to wait 100 cycles after IRQ trigger to get into hblank, that would kind of be a downer. You also have to use up a sprite for every position you'd want an IRQ, because using the background tiles for IRQ I expect could become very awkward if you scroll. So the timer type of IRQs will be more useful for sure.


Actually I have thought of doing a Famicom board, but one of the problems I'm running into is for the communication adapter, I haven't found a source for FC expansion port connectors. Closest thing I've seen, is from Tototek they have NeoGeo controller extension cables, but they seem to be out of stock. Famiclone controller cables might be easier to come by though, if they're still using the same 9-pin standard.

Good to hear about the famicom thingy. I forgot about the attached controllers so you cannot use it for debugging (except with an AV famicom) and the expansion port is different.