nesdev.com

Redirecting memory is easy; it's not easy to keep track of rendering though (if that's necessary)

Just to be nitpicker: I assume you meant attribute reads. Palette reads cannot be redirected. No way, no how.

And the reason an extended tile index a la MMC5 would be harder is because the extra bits for the tile index need to come from somewhere. If you just want to redirect attribute reads, there is a one-to-one correspondence between the read instructions coming from the PPU and the read instructions going to the mapped memory. You just change some of the address bits. Whereas if you want more bits for the tile index, you have to throw in an extra memory read to latch the uppermost bits of this extended tile index from this memory. So if you want to use your on-cart memory for this, you would need to perform two reads for every nametable index being fetched.

But it's nowhere impossible, just a whole lot more work, pins, logic and latches than redirecting the attribute reads. And personally, I'd rather spend the extra cost and effort needed on a shared memory system instead. (eliminating the vblank limit altogether)



Depends on what you mean by "standard NES stuff". The NES sort of deviates from itself already, as it was only meant to run NROM games when it was released. In my opinion, the mapper jungle is both the coolest and the ugliest aspect of NES development, and NES development is as much about hardware as software engineering. There is no standard to follow, so you're free to invent anything you like that will run on the hardware, as long as you have good reasons for doing so. (i.e., if your supercool game idea needs it)

Yours is a valid point though. Most of the MMC5 games sucked badly, while the best NES games there ever were used the most primitive discrete-logic mappers. (Battletoads come to mind) So the hardware is always secondary to well-made software.

But if you're satisfied with the existing cart types, then I don't really see the benefit of cloning them rather than sacrificing existing games. There are a lot of crappy games to put on the altar for almost every common cart type. And re-cycling circuit boards is a lot nicer to the environment than manufacturing new ones. And last but not least, all game collectors out there will be even happier than before, since it raises the value of their cart collection. ;)

Yes, I meant attributes. Nitpick all you want... =)


I assumed this wouldn't be a problem because for extra attributes you also need extre bits.


Now, since I am not really sure of how all the fetching during rendering works, I can only guess that the reason why these reads have a one-to-one correspondence is that in spite of just one pair of attribute bits being used for a 2x2 tile area, that same pair is read once for each tile?


You know, I'm a noob at this. But in my head, if you had the extra bits (defining from which bank to fetch each tile from) inside on-cart memory it would be just a matter of putting those bits in the higher address lines of the CHR chip at the correct times (assuming that the mapper has a way to tell the correct times - which it must have, since it would be able to redirect the attribute reads at the correct times). The NES wouldn't even know that'd be going on. Then again, noob's point of view.


But even if there is no vblank limit, you'd still have to time your writes in order to not get any "tearing" and things like that. Unless you are updating a part of a nametable that's hidden, in which case no limit would be great!


Yeah, "standard" is a tricky word here. But I meant things that are taken as "NES-like", because of the large number of games using UNROM, MMC1, MMC3 and such. Making a "super mapper" now will make the games less "NES-like", and few people will be able to run those games unless the mapper was properly implemented on most emulators and the carts were easily obtainable. You know, if you release a MMC3 game, anyone can get a MMC3 cart and put your game on it.


I agree.


It would be cool as hell to have 2 scrolling planes, extended attributes, extend sprites, extended everything. But the fact is that the NES scene is a bit slow, and we haven't made extensive good use of even the standard features yet. So, even if a devcart had all these cool features, I don't see them being used all that much. There is plenty to explore with the "standard" hardware as it is. I don't think this is just the time yet.


I know... I bought a lot of crappy games the other day (like, some 12 carts) and I picked the cheapest ones which had the mappers I wanted.

But you know, even if a devcart does not have these super cool runtime features, it can still stand out for it's development features. Like being able to program chips in place, eliminating the need of an EPROM programmer. That's something I really miss. I have made NROM, UNROM and am about to make a couple MMC3 devcarts, but I find it very annoying having to take the chips in and out, from the cart to the programmer and vice-versa. A self contained, all-in-one devcart would be the coolest thing to have, even if it does not include any revolutionary mapper features.

I think a nice "advanced" discrete board could be made for CHR-RAM dev with little more than two 74670 register files for 8k banks capable of addressing 2MB PRG ROM, SRAM and mirroring. I'd only be interested in something which can address 1MB (I'm not one for optimizing) which I think is novel enough and cheap enough :)

Yeah, that's how it works. For every nametable index that the PPU reads on each scanline, it also reads the corresponding attribute byte. So what the MMC5 does for each scanline is to keep track of odd/even nametable reads and fake them with reads from its internal 1kB memory. My point is that this doubling of the attribute table resolution could be done in a much simpler way, by just changing a bit in the address on odd reads, so you'd have one attribute table area to store attributes for odd nametable entries and one for the even ones. (ignoring vertical attribute table resolution at the moment, just to simplify)

Though it just occurred to me that you could do MMC5-style extended attributes without external memory after all. Since only 2 bits from the read attribute byte are used, you have exactly the 6 extra bits needed for a 14-bit index. The downside is that you'd need to pipe the CHR databus through the mapper chip so it can re-arrange and replicate the attribute bits properly, as well as use more address lines. And then, the complexity is almost at the point where it pays off to do shared memory and other graphics extensions. I still think extended tile indices are of minor importance, and are only useful if you still allow one of the 256-tile pages to be controlled by bank-switching registers.



I think what you really need is an EPROM-emulator. That way you can easily use any of the "standard" devcarts you've socketed, instead of trying to fit your ideas into a homebrewn clone cart. And no chip removal or long programming times at that. Maybe we need a new poll, on how many people would like to have an EPROM emulator manufactured by MI? :)

Yeah, an EPROM emulator would be nice. The bad part is that if you want to emulate two chips (PRG and CHR) you need 2 emulators. Plus, the ones that I saw for sale emulated small chips (128KB only) and were quite expensive compared to EPROM programmers. Of course I got the programmer.

I don't really know what Memblers' plans are with this new devcart. I'd like to know what HE thinks. If this is more about a powerful mapper or versatility during development, for example.

As tokumaru points out, EPROM emulators are expensive, especially if you need two of them. Can we get a homebrewn clone cart with a built-in EPROM emulator? This seems to be the strategy used by SuperCard and M3 products for Game Boy Advance and Nintendo DS.

And I've trouble to know how you could transport your cart and lend it to friend with an EPROM emulator attached to them, nor how you could just plug it in an unoppened NES.

Nah, what you need is really on-board programmable EEPROMs/Flashroms.
About the super-cool features, well, that would really be super cool. But then, you have to make a good use of them.
A nice feature would be tiles that could merge tiles from many palettes (10-bit pixels), but I don't think that is possible, at least not horizontally.

As Banamnos pointed, many Koei games just wasted the MMC5's power, but that's a good thing for devcards. I hate destroying existing NES games, unless they're really bad and common. Those Koei games are incredibly boring and not too much common, but I say to myself some people could just love those games and that destroying them isn't good at all even if I found they're very bad.
And for mass-producting carts, I'm definitively against destroying commercial games ! It's good for developement purposes, but not for mass-producting games.

And my opinion is that it is better to stuck with existing mappers, at least for now. So if you want any MMC5-like features, I'd code for the MMC5 on something I know that could fit an existing commercial cart. Then, we could create an MMC7 or anything even better to push the system out of its limits, but I really don't think it's time yet.

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

I voted for the advanced discrete logic (for accessing larger amounts of memory).
But thats probably because I'm still pretty new to coding on the NES and I haven't tried any advanced things yet. I'm still mainly just concerned with memory.

Al

You'd need to lend your NES with a cut CIC pin 4 anyway, unless you know that your friend has a toploader.

Yeah, most EPROM emulators that I've seen on eBay are both crappy and somewhat expensive. But the parts you need for a homebrewn one shouldn't cost you more than < $50. (for a memory size of 512kB - 1 MB)

How much are you willing to pay for one btw? If you don't build it yourself, I'd say $100 is quite fair for a one-time investment...

And you don't really need to emulate two memory chips. Just put another SRAM chip on a ribbon cable that plugs into the CHR-ROM socket on your socketed cart, and pre-load the EPROM-emulator with chr-data and a small program that copies the chr data to the CHR-RAM. My EPROM emulators uploading program does all this automatically in one step, and the loading program copied to the NES even autodetects if it's running on a MMC1 or MMC3, and then uses the appropriate bankswitching routines. Works pretty nice for gaming as well. (which is mainly what I've used my EPROM emulator for during the last inactive years :)



Stop comparing apples to oranges. For the GBA or DS, memory size is the only issue to consider for a rewritable cart. Here, every discussion of this kind always ends with people not being able to agree on which specs are desirable for a cart.



That's because you're (deliberatly?) confusing development tools with distribution media. Tokumaru's main objection to using existing boards was that the development process was tedious when using programmable memory chips. I therefore explained that this is not an issue of the cart, but of lacking the proper tool for fast development. Now, you reply by critcizing that tool because it doesn't easily let you show off your work at your friend's place, or even lend it to him? That just doesn't make sense.



Then I wish you luck with saving up the money needed to make cart cases. Please visit us again when you have, and we might just be interested in buying some from you...

I'd never do that on my own, you know. I'll release my games available for emulation and with instructions on how to modify a cart to play it for electronicians, but I don't plan to ever mass produce any of my games for the actual hardware. The problem isn't just the money, but the knowledge too. Also, who would buy a game they can just download, and in total legality above all ?

However, Memblers is in a different case and was hoping to do that someday, as I understand things.


I don't think it doesn't make sense. It's practical to use a real cart because you can lend it to friends. What I say is that a cart such as the one Memblers describes, it could make the thing work just as well for that, exept the CIC problem you just pointed. Memblers could try a CIC defeater I think. But if you do something that needs serious modification to hardware in order to fit in the NES this isn't abordable for that situation. So for games just using a standard mapper you could just use your re-writable cart for developpement, and then use one or a few modified Nintendo cards to give/lend them to your friends. But if you use a new mapper with a million features, the only way the game could be played is trough an emulator wich support the homebrew mapper in question, wich will obviously be rare unless you're a very popular developper, and noone is up to now, or trough your rewritable card, and not all your friends would want to modify their NES and to test your game on your rewritable card.

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

You're still not making any sense, Bregalad.



Are you being ironic? If not, then check out eBay's video game section to have your question answered. (minus the legality issue, which no one really cares about anyway) Packaging is often as important as the product itself.

Granted, a homebrew can't really compete with the popularity of classic NES games. But even with that, I estimate that a homebrewn game above average quality (i.e., one that matches the most popular titles in gameplay, graphics and sound) priced at $50 could easily sell 100 copies. So it's nothing to earn money from of course, but that's probably not anyone's goal here. We have yet to see my prediction proven right or wrong though.



Jeez, I can't make ANY sense out of this lengthy paragraph. One of your main issues seems to be that people won't want to modify their NES units to play a homebrewn game without a CIC? But you're the one who just rejected the idea of using a "standard" carts in favor of a homebrewn one, which would definitely need a donor cart to work on a non-modified NES unit. And no matter how primitive or advanced a homebrewn mapper would be, you still need a donor cart for the cart case.

You also seem to argue from a point of view where a NES developer can only own either an EPROM emulator or a single pair of programmable memory chips. There's no law preventing you to use the first one for development and the second one for lending your cart to friends.

What's your point, really?

I should start a new topic: What can we do with five 74 chips?

I do have a lot of ideas about what other kind of carts I could make, every option on there is one that I've seriously considered. Squeedo would be a combination of the higher-end (considering it's amount of integrated memory) standard DSP and simple logic. The logic is almost too simple, but if you look at the rev1 board you can see I pretty much ran out of room with all those dumb DIP packages (I know better now).

Really, besides my UNROM board which is more of a production design and CopyNES accessory, all my designs are geared towards being easy to work with (for non-hardware hacker people, I figure it shouldn't even require a screwdriver nor lockout modd) and being self-contained as far as reprogramming and stuff.

But what's interesting for me with these polls, is to see how much people are willing to invest into a devkit. Besides potentially paying a lot extra up-front, there's really no harm in using a super-powerful devcart to develop an NROM or UNROM game. In fact, it's even worth encouraging if you want to release your game on cart. If it's cheaper to produce, more people can afford it. But there's still the possibility of making your own "Hellraiser", or just have some fun and write some crazy demos for yourself and other devcart owners.

Plus you can write a game, and only use some features of the cart. If you want it produced, then I could design a special board for it. There's more NES gamers and collectors than that are developers, so making more board designs isn't as much of a problem if a good amount of each could be used.

So these polls are really just to satisfy my curiousity, because I'm interested in making a 2nd devkit design or (even better) enhancing Squeedo to fill whatever needs everyone has, if it can stay within a reasonable cost.

And yeah, I have put a lot of serious thought into making my own EPROM emulator also. The big annoyance with that is that there are no 32-pin DIP-to-IDC adapters available anywhere (if someone sees some, let me know). Just 28 and 40-pin ones. The adapter I'm using for my emu now is a 40-pin with the end chopped off and epoxied together. I'd like the connectors to be cheap enough to where it'd be practical to solder it directly to an NES board so it'll fit in the case.



The SRAM in the emulator could be battery-backed, but it's still gonna be a box attached to the cart.

ROM emulator and programmer are both something I consider essential tools for development. But I'm trying to make them obsolete, as far as NES developing goes. Who needs a programmer when you could rewrite your cartridge in a CopyNES? And not many people will need an EPROM emulator when they have a flashcart (Squeedo rev1 supports both though). ROM emulators can be faster than flash, but many of them seem designed for far below their potential speed.



A collector or anyone who prefers using the actual system. I have a lot of carts myself, honestly I'm not too worried about the legality of - personal use of - ROM images of 80s and early-90s games (many of which are pretty obscure) and there are quite a few times I've bought a cart because I played a game on an emu and liked it.

I really like the idea of having my games just downloadable, that's how my stuff will be too. I was planning on releasing the Garage Cart 1 ROM at the same time as GC#2. I just don't release very much normally because I want everything to be pretty much finished.



Maybe it's different over there, but there's plenty of people that have copies of the same games. Not too long ago walking into used game stores they'd regularly have dozens of copies of stuff like TMNT, Top Gun, Super Glove Ball, SMB/DH. Putting those to new use is better than seeing them thrown away eventually.

I don't know if 100 carts counts as mass production, but I think that'd be a successful amount.