Coolest mapper feature for a devcart

The Membler Industries, Strangulation Games, and Strangulation Records forum.

Moderator: Moderators

Of the mapper features listed, if you was gonna buy one to use what would you prefer?

None. Keep it simple. (no cost)
3
10%
Simple discrete logic (negligable cost)
2
7%
Advanced discrete logic (moderate cost)
6
21%
Programmable logic (moderate to high cost)
2
7%
Advanced Programmable logic (very high cost)
1
3%
Standard Coprocessor/DSP (nice performance, fair cost)
2
7%
6502 Coprocessor (familiar, limited memory, slightly above fair cost)
1
3%
Fast, bleeding-edge Coprocessor/DSP (moderate to high cost)
4
14%
Memory card. Just lots of memory/disk space. (moderate to high cost)
1
3%
Nintendo standard MMC3 (fair to moderate cost)
2
7%
Some combination of above features. I'll post and explain.
5
17%
 
Total votes: 29

User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Coolest mapper feature for a devcart

Post by Memblers »

How about all this stuff? Too many choices, huh?
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

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.
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

tokumaru wrote: 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.
Useless, lumbering half-wits don't scare us.
User avatar
85cocoa
Posts: 96
Joined: Sat Jul 22, 2006 12:06 pm
Location: USA

Post by 85cocoa »

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. ^_^
User avatar
kyuusaku
Posts: 1665
Joined: Mon Sep 27, 2004 2:13 pm

Post by kyuusaku »

Programmable logic can be programmed with a JTAG.
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Post by Memblers »

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.
tokumaru wrote: 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.
Or a cheap ($1) MCU. Lots of them have a clock input for a counter (with pre-scaling too).
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.
I think that's all doable with an MCU/DSP pretty much. Except the ROM nametables.
Programmable logic can be programmed with a JTAG.
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..
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

Memblers wrote: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).
User avatar
85cocoa
Posts: 96
Joined: Sat Jul 22, 2006 12:06 pm
Location: USA

Post by 85cocoa »

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. ^_^
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

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.
Useless, lumbering half-wits don't scare us.
Bananmos
Posts: 552
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Post by Bananmos »

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).
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.
User avatar
commodorejohn
Posts: 193
Joined: Mon Sep 11, 2006 6:48 pm
Location: Moose Lake, Minnesota

Post by commodorejohn »

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.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

commodorejohn wrote: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.
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).
I'd also go for an MMC5-style graphics expansion if it wouldn't jack the price up too much.
Up to MMC3 will fit on a CPLD. Anything bigger and you need FPGA ($$$ and 3.3 V/5.0 V issues).
For Famicom devcarts, some form of sound expansion would be spiffy.
Would an RCA passthrough be a bad idea even for NES carts?

And what exactly is "advanced discrete logic" anyway? MMC1-level?
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Post by Memblers »

tepples wrote: And what exactly is "advanced discrete logic" anyway? MMC1-level?
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.
Bananmos
Posts: 552
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Post by Bananmos »

I'd also go for an MMC5-style graphics expansion if it wouldn't jack the price up too much.
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.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

Bananmos wrote: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.
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?
Post Reply