nesdev.com

How about all this stuff? Too many choices, huh?

I really don't know what to pick for this one. I think it has to be simple, and shouldn't deviate too much from standard NES carts, as it would be nice to have these programs running from somewhere else, not only this devcart.

But then, what's the point of having a devcart if you don't make use of the possibilities it may offer? Some of these features you can choose to use, such as a coprocessor. But the bankswitching scheme and scanline/cycle counters can make this incompatible with anything else.

If I were to dream really high (and throw any compatibility on the trash), I'd like some MMC5-like features, improving the graphical side of things, improving color resolution and all.

This question is a tough one. I'm a fan of discrete logic, but I miss scanline/cycle counters.

This is perfectly doable with discrete logic (74HC161 counter). You'll probably have to pair two 74HC161 counters in order to get a decent 8-bit counter.

Aside of that, I'd be interested buying only if the card can fit the NES (without having any socket) and if the goal is to do something like emulating common mappers (unlike squeedo). That would go for advanced discrete logic or programmable logic, but the problem is that you need a programmer to programm the logic, and then a socket, and carts with sockets cannot fit in the NES. Unless you use low-profile PLCC sockets, but then I don't know any programmer that can accept PLCC chips at all so not anyone could just programm the chips as their needs.

Programmable logic would emulate most mappers, but then I'd think you have to have a switch selecting some of the most common mappers inside the programmable logic, or just have one special register the software could write to chose the mapper, and that would have no incident on anyother card (for example a location between $5000 and $5fff). Then the programm can be ported as is to the actual mapper without having that dummy write change anything. You won't be able to simulate the MMC5 even inacurately without a powerfull DSP, wich as he stated, is expensive. I think it could be nice to have a dsPIC or something that anyone could programm to suit their own needs, but then in 99% of the cases the power of the chips would be wasted to just do some disrete logic opperations, and I'm unsure if this would cause longer delays in bankswitching as opposed to plain discrete chips.
So I'd go with either 'advanced discrete logic' or programmable logic.

_________________
Life is complex: it has both real and imaginary components.

Disclaimer: I am not that serious of a NES techno-geek, so don't yell at me for saying this.

In a perfect world, I would shoot for a handful of features from the J.Y. Company mapper (especially the special IRQ modes and the direct-from-ROM nametables). An integer multiplier would be nice, and so would some sort of hardware RNG.

Well, this isn't a perfect world, though... (The absolute minimum would probably be some form of IRQ counter, and ... I'll let the real experts debate this out.)

_________________
Warning: I am not a serious developer (yet), but CS and EE really interest me.
I was -_pentium5.1_- until I screwed up. This is why I screwed up. ^_^

Programmable logic can be programmed with a JTAG.

I went ahead and registered my vote, after waiting a bit. My favorite would be a combination of a standard MCU/DSP like PIC18 or dsPIC and a simple/cheap programmable logic setup. But I would have to weight it against 'advanced discrete logic', because the way I'd do the logic would probably be in a way that would not be easily reprogrammable by everybody (unless, maybe the MCU could handle it, getting kinda heavy on development time though..). So I'm thinking advanced discrete logic + cheap DSP is probably the winner.

Short of putting some kind of heavy CPLD/light FPGA and loading up on FlashROM, I have a hard time coming up with something I'd like more than Squeedo though.

I'm also trying my damnedest to come up with sufficiently hardcore designs that I can actually build by myself. Avoiding fine-pitched stuff, TSOP packages, is actually annoyingly limiting. Because I don't mind working for pretty cheap, but if I have to pay someone else even if they work cheap too, there's the whole paying for everything up-front deal.



Or a cheap ($1) MCU. Lots of them have a clock input for a counter (with pre-scaling too).



I think that's all doable with an MCU/DSP pretty much. Except the ROM nametables.


Bad thing with that though is that it's more cost, more cables to buy/build. Sure, someone could just get a proconfigured one, but if other people started developing stuff with custom logic, it'd make the non-JTAG one look kinda crippled..

All that means is that someone needs to whip up a couple dozen cables based on the Cheaptag plans. They can't be that expensive to build (couple of dollars for parts and a few minutes of labor).

_________________
Pin Eight | Twitter | GitHub | Patreon

To clarify: My vote was for the last option. I would also like to mention that my (n00bish) conception of an "ideal" mapper would have enough RAM for four-screen mirroring but also a programmatically controllable option to do some real mirroring with those nametable pages.

I generally agree with the direction that Squeedo is going.

_________________
Warning: I am not a serious developer (yet), but CS and EE really interest me.
I was -_pentium5.1_- until I screwed up. This is why I screwed up. ^_^

Yes, avoiding SODIP and PLCC packages is more and more a pain. If you found any way to programm those, go for it. I don't mind SODIP and PLCC packages, as long as I can programm them. You'd probably have to do the programming in-circuit, with the software doing that on a PC using an USB port or something. I hope it's doable, because that would be the perfect solution :
- PLCC packages are cheap, more common nowdays (while rare in the NES days) and can fit in a NES cart even with sockets (as far I know), unless DIP pakages
- Programmable logic/DSP allow great features as well as basic ones, and anyone could programm it's own logic/code to emulate any actual mapper (exept the DSP would really have to be powerfull and fast to sumulate the MMC5)
- I hope this wouldn't be too expensive, but even if it is, it's worth it as opposed to a cart with cheap bankswitching.

You could even release both : A cart with UNROM/CNROM/GNROM like features for people exepting a cheap way to test their programm on the NES even with limitated, and a complete customisable and progammable cart that can emulate any mappers.

_________________
Life is complex: it has both real and imaginary components.

Cheaptag didn't work for me. I had to build a slightly more advanced version, with a hc125 to buffer the lines. Though it might just have been the error of having a far too long cable...

For single-game production carts, I'd go for programmable logic, and especially using it to emulate dual-port RAM thru a regular 32kB SRAM. Letting all the data and adress lines pass through the cpld would allow for other neat graphics extensions as well. It would require a cpld with lots of I/O pins though.

Or, if your goal is not to sell physical game cartridges, go for a cart with advanced programmable logic and an usb mcu + flash memory, which functions as a mass storage device and lets you choose your game on startup, loading both the game into memory and the mapper functions into the fpga. Sort of like Kevin's fpga console, but having the NES functionality external to the cart.

What I'd look for in a devcart is configurable expansion. For example, the ability to switch between one-screen, horizontal, vertical, and four-screen mirroring. I'd also go for an MMC5-style graphics expansion if it wouldn't jack the price up too much. For Famicom devcarts, some form of sound expansion would be spiffy.

The most general way to handle mirroring is to do an expansion on what TLSROM does: Put in a 12-bank CHR switch (one register for each 1 KiB bank in PPU $0000-$2FFF).


Up to MMC3 will fit on a CPLD. Anything bigger and you need FPGA ($$$ and 3.3 V/5.0 V issues).


Would an RCA passthrough be a bad idea even for NES carts?

And what exactly is "advanced discrete logic" anyway? MMC1-level?

_________________
Pin Eight | Twitter | GitHub | Patreon

I figured it as roughly 6 or more logic chips, or logic using 4 times the amount of PCB area used by the memory chips, whichever comes first. Just something with a lot of chips, regardless of what it implements.

Simple discrete logic would be 1 or 2 chips.

Depends on what features of the expansion you need. Re-directing palette attribute reads to another section of PPU memory shouldn't be a problem to fit in a CPLD. But if you want to expand the number of BG tiles on screen, you'd need an FPGA with on-chip RAM. (or alternatively yet another akward external memory to be accessed by the CPLD) I can't see much good use for the more BG tiles option though, especially since it makes tiles more akward to animate. Extended sprites would've been a much nicer option for the MMC5 to implement IMO.

A nice graphics extension to put in a CPLD/FPGA would be to have a second BG layer that can be scrolled to any Y-coordinate, but where the lowest 3 bits of the X-coordinate would follow the main BG layer. (for obvious reasons) Then, for each 8x1 character rendered, the CPLD/FPGA would have a priority bitmap that specifies which layer is visible, reading the nametable index from the second BG layer where the second BG has priority. (and using the second BG's scroll coordinate of course)

In an FPGA implementation, on-chip memory could be used for this bitmap. For a CPLD implementation, having a 16-bit or 32-bit latch (for 16x16 or 8x8 attributes) that needs to be rewritten by software at appropriate scanlines would be a nice compromise.

A second layer would be awesome to have on the NES! But having both layers tile-aligned horizontally would kill most of the fun! I understand why this would be needed, though.

Would having access to more tiles (MMC5 style) be that hard? If you can redirect pallete reads, why can't you redirect pattern reads (since the mapper has access to the whole CHR chip)?

Anyway, do you guys think this thing should deviate from standard NES stuff that much? I mean, it sure would be cool to have these nice features avaliable, but is it fair? And wouldn't something as complicated as that take Memblers ages to develop?