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.
Quote:
2: I'd like a DMA Mode for CHR-RAM, much like Gameboy, SNES and One-bus.
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.
Quote:
Quote:
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.
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.
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.
Quote:
Interesting to see a new dev board. I guess it won't get a famicom treatment since the crowd is too small for it.
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.