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.
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.
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.
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.)
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.)
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.
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).
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..
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.
Quote:
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).
Quote:
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.
Quote:
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..
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).
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.
I generally agree with the direction that Squeedo is going.
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.
- 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.
Quote:
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.
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.
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).
Quote:
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).
Quote:
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?
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.
Quote:
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.
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?
Redirecting memory is easy; it's not easy to keep track of rendering though (if that's necessary)
Quote:
Would having access to more tiles (MMC5 style) be that hard? If you can redirect palette reads, why can't you redirect pattern reads (since the mapper has access to the whole CHR chip)?
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)
Quote:
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?
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. ;)
Bananmos wrote:
Just to be nitpicker: I assume you meant attribute reads. Palette reads cannot be redirected. No way, no how.
Yes, I meant attributes. Nitpick all you want... =)
Quote:
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.
I assumed this wouldn't be a problem because for extra attributes you also need extre bits.
Quote:
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.
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?
Quote:
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.
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.
Quote:
And personally, I'd rather spend the extra cost and effort needed on a shared memory system instead. (eliminating the vblank limit altogether)
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!
Quote:
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.
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.
Quote:
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)
I agree.
Quote:
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.
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.
Quote:
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. 
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 :)
Quote:
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?
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.
Quote:
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 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? :)
Bananmos wrote:
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.
Bananmos wrote:
tokumaru wrote:
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.
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.
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.
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.
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
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
Bregalad wrote:
And I've trouble to know how you could transport your cart and lend it to friend with an EPROM emulator attached to them
You'd need to lend your NES with a cut CIC pin 4 anyway, unless you know that your friend has a toploader.
Quote:
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.
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 :)
Quote:
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.
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.
Quote:
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.
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.
Quote:
And for mass-producting carts, I'm definitively against destroying commercial games ! It's good for developement purposes, but not for mass-producting games.
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...
Quote:
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.
Quote:
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.
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.
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?
Quote:
who would buy a game they can just download, and in total legality above all ?
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.
Quote:
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.
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.
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.
Quote:
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.
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.
Quote:
Also, who would buy a game they can just download, and in total legality above all ?
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.
Quote:
And for mass-producting carts, I'm definitively against destroying commercial games ! It's good for developement purposes, but not for mass-producting games.
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.
I think Squeedo is really neat, and it proves my whole point: why re-invent the wheel when wheels are plentiful, and you can invent something new and totally different instead? While personally, I prefer programmable logic just because extending the hardware possibilities is a lot more fun than just adding raw processing power, I still think Squeedo is the coolest NES cart to have been designed. And I'd still like to have one. :)
I still haven't heard any good reasons for why cloning of UNROM, MMC1 and MMC3 boards is desirable. The only situation I can think of is when you've already finished a game and would like 100 PCBs to plug in your lot of 100 random crappy NES carts that you just bought cheap on eBay.
But if anyone wants to pursue that goal, be my guest. I'm just saying that I personally would have null interest in boards whose functionality is identical to cheap carts, minus the CIC and plastic case.
Yeah, that's what I've been doing as well. I wonder if 32-pin DIP-to-IDC adapters even exist. I think chopping a 40-pin one works pretty well though. And if you'd like to have it permanently soldered to a dev-cart, it won't even look ugly from the outside. ;)
I still haven't heard any good reasons for why cloning of UNROM, MMC1 and MMC3 boards is desirable. The only situation I can think of is when you've already finished a game and would like 100 PCBs to plug in your lot of 100 random crappy NES carts that you just bought cheap on eBay.
But if anyone wants to pursue that goal, be my guest. I'm just saying that I personally would have null interest in boards whose functionality is identical to cheap carts, minus the CIC and plastic case.
Quote:
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.
Yeah, that's what I've been doing as well. I wonder if 32-pin DIP-to-IDC adapters even exist. I think chopping a 40-pin one works pretty well though. And if you'd like to have it permanently soldered to a dev-cart, it won't even look ugly from the outside. ;)
Quote:
Putting those to new use is better than seeing them thrown away eventually.
I sure agree, but keep in mind there is no unlimited source of existing NES carts. In europe, it is serioulsy rare to find used NES games to sale as opposed to GameBoy, Gameboy color and SNES games wich you can found pretty much easily. I don't know in america, but I just think it's better to keep carts for collectors (and by all means NOT to throw them away !!). I'm not totally against recycling carts, I just don't think it's a very good idea to goal to do any mass production with used carts. Anyway, due to the low quantity and quality of homebrewn games available right now, I don't think it's a question to solve immediately, because nothing will be mass producted right now.
Quote:
But if anyone wants to pursue that goal, be my guest. I'm just saying that I personally would have null interest in boards whose functionality is identical to cheap carts, minus the CIC and plastic case.
With the exact same funcitonality, I agree. But imagine a card you could just erase and re-write and switch from mapper to mapper as you like. Squeedo is just another complex mapper, and it cannot run games not designed for it. That's not bad at all, just a whole different thing.
A such cart would really be cool, I think. I think it is worth developping *one* prototype that could help developement and allow people to play commercial game they doesn't have. (don't bother me with legal issues here please, because you just cannot found every game arround at least not for a decent price).
About the package, I have strictly no idea how hard it is to make any. Wisdom Tree and Codemasters didn't seem to have any trouble doing it, but again maybe they just did have more money and knowledge than us. I partialy agree with Bananmos, I found somewhat ridiculous to place a brand new board in an old plastic package and let the old board away, unless that card in question has amazing features of course.
My vote would be for the following ideal (all in ONE cart) :
- Connectable to a computer via any kind of common parallel or serial port (USB comes in mind, but I don't think if it's doable).
- A PC software would come with and would just be able to control the cart from your computer
- A programmable logic (CPLD) could handle most common mappers (not ALL mappers of course) in hardware, and could be rewritable trough the computer with a plugin system.
- You can manually force the CPLD to some state emulating a mapper
- You can 'burn' internal PRGROMs and CHRROMs (done with any system such as backuped SRAMs, Flashroms, EEPROMs, etc...) with raw ".bin" files
- You can burn a iNES and maybe UNIF ROM on your card that will automatically detect PRG/CHR sizes and the CPLD plugin corresponding and write stuff on the card.
- You can manually force an internal battery backed WRAM with any ".sav" file on your PC
- You can dump the on-board battery backed WRAM and save it on a ".sav" file on your PC
- The cart could hold PRGROM up to 512kb, CHROM up to 512kb and 8kb of CHRRAM (typically only one of them will be connected trough the CPLD).
- The WRAM in the cart can be disabled trough the CPLD to run games without SRAM, it could also have various size in funciton of the mapper/submapper implemented (typically 8kb, 16kb and 32kb). Of couse the actual size will always be 32kb, but not the whole thing will be acessible in most cases.
- On board CIC defeater, so that most people will be able to play it without any modifictions. Of couse it won't be very acurate, but in the case it isn't, you just can cut pin 4... Personally I've both a modified and unmodified NES.
- It would be a pain to inser the PC connector (USB or whathever) inside an existing NES plastic package
Inconvenient :
- Somewhat expensive, but it's a one-time investisment
- Needs a lot of tought to put in developpement, but many people here have knowledge
- Needs a donor card only for the package (?). However, most of us already have a board/cart you've destroyed by error, or a game you hate so much you don't even want to recycle the board
- Need CIC defeater, and not all of them are accurate, unless the CIC gets completely reverse-engineered
- Need to be tricky to fit a NES package both horizontally and vertically
- Not all mappers will be supported
- Ridiculously high cost for mass-producting
- You have to rewrite the cart each time you want to make changes to your code or change game you're playing.
- This process will eventually damage the Flashroms/EEPROMs on the board above a few thousands of times.
Advantages :
- Easy to use
- You can test your code on the real hardware very easily without having any f**** soldering and rewiring to do, without talking about the EPROM programming issues and the fact that you cannot erase them without a UV light machine, and most people don't have one (at least I don't)
- You can play both homebrew and commercial games
- You can backup your saves on both homebrew games, as well as importing exploits you made with an emulator onto the real hardware !
- If it can hold NOROM, C*ROM, U*ROM, A*ROM, S*ROM, P*ROM, T*ROM and F*ROM, it can definitely hold 97% of the NES games library, and that is most likely to be possible on a CPLD. For the other 3% you can just go with the traditionnal donator cart issues.
- All chips can be SMD (PLCC and SO packaged) chips as well as DIP chips, because you just have to solder them once and all programming and so will be on board.
- Don't need any modification to the hardware nor any knowledge in electonics for the used (and modify an existing card definitely needs knowledge in electronics).
- Different plugins will be needed for each submappers, and for each small configuration available (such as mirroring).
Of couse this is only suggetions, but I think a such thing could be pretty idea. I can help in the developement of a such cart in questions, because I've some knowledge in electronics. If anyone does have ideas opposite to mine I won't be angry, but I just exposed my point of view. I just think developping a NES cart in hardware sounds so COOL !
This very idea was attempted a long time ago by www.vgwiz.com, and it failed horribly (to the point that the site, forums included, pretty much went completely silent nearly a year ago). Part of the problem is that they used a CPLD, which was barely big enough to even hold an MMC1, let alone something like an MMC3.
One thing you should be aware of is that CPLDs have a very significantly limited logic storage space - a "large" CPLD is generally only big enough to hold one single mapper, and the complexity is pretty much limited to that of the MMC3. If you want to keep more than one mapper on the cartridge and be able to select between them, you pretty much need to use an FPGA (most of which tend to be SRAM-based, meaning they need to be reprogrammed every time you power on the system or have an attached battery that will likely be drained fairly rapidly). Kevin Horton's FPGA-console actually started out as an all-in-one cartridge idea until he realized that the massive amounts of level translation needed would make it simpler to just cram the entire system inside the FPGA.
One thing you should be aware of is that CPLDs have a very significantly limited logic storage space - a "large" CPLD is generally only big enough to hold one single mapper, and the complexity is pretty much limited to that of the MMC3. If you want to keep more than one mapper on the cartridge and be able to select between them, you pretty much need to use an FPGA (most of which tend to be SRAM-based, meaning they need to be reprogrammed every time you power on the system or have an attached battery that will likely be drained fairly rapidly). Kevin Horton's FPGA-console actually started out as an all-in-one cartridge idea until he realized that the massive amounts of level translation needed would make it simpler to just cram the entire system inside the FPGA.
That's interesting.
Are CPLD reprogrammable ? I think so, abd I just think about using a large CPLD that would hold *one* mapper at the same time. Then, if you want to change it, you just have to reprogramm your CPLD trough the PC software that would come with the cart.
Of course you can just emulate discrete logic mappers, and some MMCs (let alone MMC5), but I think it's already a great thing.
Anything involving more complex mapper would need a FPGA, and if you have to reprogramm it on each powerup, that means there is at lease a microcontroller on the cart that would programm the FPGA *OR* have your PC cable inserted when you turn the NES on and having both systems syncronize to eachother. I think both are a real pain in the ass.
So if the simple CPLD isn't valuable for some reason, a DSPIC-like DSP microcontroller could do the whole work of the mapper. I don't think if it's worth it, but it could be really fun to code mapper emulation for such kind of chips, trough I've never done anything like that before myself. I don't know about Memblers. It's up to everyone to bring ideas and contributions.
Are CPLD reprogrammable ? I think so, abd I just think about using a large CPLD that would hold *one* mapper at the same time. Then, if you want to change it, you just have to reprogramm your CPLD trough the PC software that would come with the cart.
Of course you can just emulate discrete logic mappers, and some MMCs (let alone MMC5), but I think it's already a great thing.
Anything involving more complex mapper would need a FPGA, and if you have to reprogramm it on each powerup, that means there is at lease a microcontroller on the cart that would programm the FPGA *OR* have your PC cable inserted when you turn the NES on and having both systems syncronize to eachother. I think both are a real pain in the ass.
So if the simple CPLD isn't valuable for some reason, a DSPIC-like DSP microcontroller could do the whole work of the mapper. I don't think if it's worth it, but it could be really fun to code mapper emulation for such kind of chips, trough I've never done anything like that before myself. I don't know about Memblers. It's up to everyone to bring ideas and contributions.
FPGA are usually configured through serial EEPROM in static designs, they don't need a microcontroller because it is built into the EEPROM. There are however antifuse and flash FPGA which are nonvolatile. Any way you look at it though, FPGA is no good for +5V devices.
Yes, CPLD are reprogrammable with a simple device called a JTAG cable, if a user has the pin constraints file (pinout) it is possible for people to design their own mappers.
If anyone else goes the CPLD route, remember you will need:
-24(or 18 if last bank static) macrocells to address 512k PRG ROM in 8k banks
-64 macrocells to address 256k CHR ROM in 1k banks
-16 macrocells + flags to make a Phi2 counter
-8 macrocells + flags to make a scanline counter
~10 macrocells for large multiplexing overhead (ie the 1k CHR bankswitching)
I've almost got a MMC3 into 108 macrocells (112), I think I can fit it by manually routing (It fits easily without the scanline counter) Artoh's MMC3 uses ~120 macrocells.
Yes, CPLD are reprogrammable with a simple device called a JTAG cable, if a user has the pin constraints file (pinout) it is possible for people to design their own mappers.
If anyone else goes the CPLD route, remember you will need:
-24(or 18 if last bank static) macrocells to address 512k PRG ROM in 8k banks
-64 macrocells to address 256k CHR ROM in 1k banks
-16 macrocells + flags to make a Phi2 counter
-8 macrocells + flags to make a scanline counter
~10 macrocells for large multiplexing overhead (ie the 1k CHR bankswitching)
I've almost got a MMC3 into 108 macrocells (112), I think I can fit it by manually routing (It fits easily without the scanline counter) Artoh's MMC3 uses ~120 macrocells.
Sounds like the cart you want, Bregalad, is Arto's FunkyFlash. And yeah, it is crazily expensive to have produced and alternatively, not too easy to build by hand (time and potentially money consuming when mistakes are made). I still have mine, it's still only partially-built though since I messed up when soldering the USB chip and I haven't tried removing/repairing it.
I think he said it was actually pretty slow for reprogramming, I can't remember if that was a hardware or software limitation but I remember being aware that it would be much faster for me to socket the FlashROMs and use my programmer on them (and just use the USB or JTAG for CPLD reprogramming). IIRC, the USB/JTAG controlled the CLPD pins to program the flash, compared to my designs I always send code to the NES and write with the CPU. It's a very well-done design though, it exists and it works.
The VGWiz cart, I remember them saying on the forum there was some legal concerns with it. I don't know the details of that, I know they had at least some NROM test programs that I sent working on it. They do have a couple successful Atari flashcart designs too. Ronen there is a cool guy, he's helped me out a lot with info, a few chips, and inspiration to really get started on my big Squeedo adventure.
I wish they were fast enough, but I don't think there are any DSPs approaching the needed speed in 5V. dsPIC is only 30 MIPS, there are affordable low-voltage DSPs that are much faster but their cost is pretty comparable with a decent CPLD. Parallax's Propeller chip seemed strangely compelling though. Writing code with various (at the same time!) timing requirements down to the nanosecond sounds pretty difficult too. On Squeedo I just measure it by NES CPU cycles (the 20 MIPS PIC18 is running about 5 full instructions per NES cycle, not too bad huh?). Programmable logic between a DSP and the NES, is what I find most interesting though.
I think he said it was actually pretty slow for reprogramming, I can't remember if that was a hardware or software limitation but I remember being aware that it would be much faster for me to socket the FlashROMs and use my programmer on them (and just use the USB or JTAG for CPLD reprogramming). IIRC, the USB/JTAG controlled the CLPD pins to program the flash, compared to my designs I always send code to the NES and write with the CPU. It's a very well-done design though, it exists and it works.
The VGWiz cart, I remember them saying on the forum there was some legal concerns with it. I don't know the details of that, I know they had at least some NROM test programs that I sent working on it. They do have a couple successful Atari flashcart designs too. Ronen there is a cool guy, he's helped me out a lot with info, a few chips, and inspiration to really get started on my big Squeedo adventure.
Quote:
So if the simple CPLD isn't valuable for some reason, a DSPIC-like DSP microcontroller could do the whole work of the mapper.
I wish they were fast enough, but I don't think there are any DSPs approaching the needed speed in 5V. dsPIC is only 30 MIPS, there are affordable low-voltage DSPs that are much faster but their cost is pretty comparable with a decent CPLD. Parallax's Propeller chip seemed strangely compelling though. Writing code with various (at the same time!) timing requirements down to the nanosecond sounds pretty difficult too. On Squeedo I just measure it by NES CPU cycles (the 20 MIPS PIC18 is running about 5 full instructions per NES cycle, not too bad huh?). Programmable logic between a DSP and the NES, is what I find most interesting though.
Well, I have trouble understanding that CPLD and FPGA stuff. I have no experience with them. It seems that the general opinion is against the FPGA for some reason, and that the CPLD is somewhat limited. On the other side, Wikipedia states that larger CPLD can have about the equivalent of 10 thousands logic gaes, wich is much larger than what the MMC3 needs for it's several adress decoding, flip-flop latches, and counters.
I'd just think how many inputs and outputs a discrete logic system would need (regardless of the technology used) :
OUTPUTS :
PRGROM : A13..A17 (assuming 512kb and 8kb banks) : 5 pins
CHRROM : A10..A17 (assuming 512kb and 1kb banks) : 8 pins
/OE and /CE of PRGROM, CHROM, CHRAM and WRAM : 8 pins (?)
R/W pin for CHRRAM and WRAM : 2 pins
/IRQ : 1 pin
CIRAM A10& CIRAM /CE : 2 pins (?)
Secutiy pins (if lockout defeat integred in main chip) : ? pins
INPUTS :
PRGROM : A13..A14 : 2 pins
CHRROM : A10..A12 : 4 pins
CHR A13, CHR /A13 (Mirroring ?) : 2 pins
PRG /CE, PRG R/W, CHR /CE, CHR R/W : 4 pins
M2, CLK : 2 pins
Security pins (if lockout) : ? pins
Communication with external computer : ~3 pins if serial port
Total : ~43 pins
This will probably need a package such as 64-pin TQF, regardless of the technology used. Unless some simplification of the above suff is done and a 40-pin DIP could be used, but it doesn't really hurt if it's not a DIP package as long as the goal is to have it on-ciruit programmable.
About Artroh's cart, I did never hear of it to be 100% completed and available. I wish it would be the case, tough. Well, I also wish I could play programm mappers in hardware. It sound like fun. However, I've zero experiance with programmable logic, only with microcontrollers.
EDIT : As far I know, PIC18xxxx can go up to 40MHz, but that means they execute their instructions at 10MHz because of internal RISC configuration, and so it makes them 10MIPS, and about twice as fast as NES' PPU. This is effectivly a bit too slow if you wish to upload the CHR lines each eight PPU clock cycles. Unless a serious combination of DSP and FPGA/CPLD is done, MMC5 will never be emulated. Anyway, I don't think this is too much needed -> for the several applications where a MMC5 chip is desirable, just use one of those dumb Koei games to place your game on !
I'd just think how many inputs and outputs a discrete logic system would need (regardless of the technology used) :
OUTPUTS :
PRGROM : A13..A17 (assuming 512kb and 8kb banks) : 5 pins
CHRROM : A10..A17 (assuming 512kb and 1kb banks) : 8 pins
/OE and /CE of PRGROM, CHROM, CHRAM and WRAM : 8 pins (?)
R/W pin for CHRRAM and WRAM : 2 pins
/IRQ : 1 pin
CIRAM A10& CIRAM /CE : 2 pins (?)
Secutiy pins (if lockout defeat integred in main chip) : ? pins
INPUTS :
PRGROM : A13..A14 : 2 pins
CHRROM : A10..A12 : 4 pins
CHR A13, CHR /A13 (Mirroring ?) : 2 pins
PRG /CE, PRG R/W, CHR /CE, CHR R/W : 4 pins
M2, CLK : 2 pins
Security pins (if lockout) : ? pins
Communication with external computer : ~3 pins if serial port
Total : ~43 pins
This will probably need a package such as 64-pin TQF, regardless of the technology used. Unless some simplification of the above suff is done and a 40-pin DIP could be used, but it doesn't really hurt if it's not a DIP package as long as the goal is to have it on-ciruit programmable.
About Artroh's cart, I did never hear of it to be 100% completed and available. I wish it would be the case, tough. Well, I also wish I could play programm mappers in hardware. It sound like fun. However, I've zero experiance with programmable logic, only with microcontrollers.
EDIT : As far I know, PIC18xxxx can go up to 40MHz, but that means they execute their instructions at 10MHz because of internal RISC configuration, and so it makes them 10MIPS, and about twice as fast as NES' PPU. This is effectivly a bit too slow if you wish to upload the CHR lines each eight PPU clock cycles. Unless a serious combination of DSP and FPGA/CPLD is done, MMC5 will never be emulated. Anyway, I don't think this is too much needed -> for the several applications where a MMC5 chip is desirable, just use one of those dumb Koei games to place your game on !
kyuusaku wrote:
Any way you look at it though, FPGA is no good for +5V devices.
And why is that? There do exist 5V FPGAs, they're just not as common anymore.
Quote:
My vote would be for the following ideal (all in ONE cart) [...]
I've actually proposed this idea for many years, and have planned on building it for almost as many. When Kevin Horton started a project like this, I was hoping that'd someone better skilled would do this project for me. Unfortunately, he changed his goal into making a NES clone instead of a universal NES cart, and lost all of my interest along the way. (even if I find do his FPGA console cool in its own way and hope it'll earn him money for his effort)
My ideal universal cart would be centered around a modest FPGA, a CompactFlash/SD memory and a USB microncontroller that would make the cart act like a regular mass storage device when plugged into the PC. You could then use a flash memory of desired size, and on power-on you'd just select the appropriate .NES-file to run. The appropriate bitfile to emulate the mapper would then be loaded to the FPGA before the game starts.
The biggest problem (and the number one reason why I've still only theorized about this project) is deciding on which FPGA to choose. A disturbing fact is that once a cart like this is developed, then all the implemented mappers will be more-or-less taylor-made for the FPGA you've chosen. And if it goes out of production, your universal cart will as well. There are some decent 5V tolerant FPGA series, but at least the one I have personal experience with (namely Xilinx's Spartan2 series) is no longer being produced, so there might be a problem of obtaining those parts in a few years. And like always, not wanting to take a bad decision makes you end up with taking no decision at all...
Besides that, somewhere along the way I realized that a project like this is a bit too big to do at once and it'd be better to do an easier project to begin with. So I have started making an USB CompactFlash cart for the Sega Mega Drive instead. That way, I won't have to lose sleep over the FPGA dilemma, and I'll have half of the functionality needed to do a similar product for the NES.
I started working a little on the prototype during this summer, but haven't touched it since early September. I got the USB mass storage device working nicely on a PIC4550 MCU, and implemented a mapper chip on an XC95108 CPLD that acts as either a Sega Master System mapper or a simple "Megadrive mapper" (that just passes the adress lines through the chip) depending on the setting of an input pin.
I had SMS games running on it with my EPROM emulator, and Sonic The Hedgehog running off two 8-bit flash-ROMs. The last thing I did with it was trying to replace the programmable ROMs with SRAM so the PIC could run programs from the Compact Flash card. I never finished this because of weird bugs that made the SRAM look like random trash when read from the megadrive console.
At this point, I had to return the In-circuit debugger for the PIC, which I had only borrowed for a limited time. I plan to buy a cheap clone of it on eBay to continue my work, but now that I'm trying to finish the last of my physics courses to get my masters degree in physics and engineering, there's just no spare time for spare time projects.
I hope to get a working product within a year though. If it does well at a price tag of $50-$100, then I'm certain that a NES equivalent will do better, even at twice the price.
Sound interesting.
I know it's hard to chose a component when you have too much choise. Often lists are so big you can't even have a clue on wich componant to use.
A good thing is take a chip wich has a more or less standard pinout. For example, most PICs are pin-to-pin compatible, even if there is hundred of variants of each PIC, wich is very confusing.
So yeah, a small project you said. It's better to have a small project that work fine than a big that doesn't. However, Memblers has done pretty well already. After a bit of trough I really seem to like more and more the FPGA idea. If an EEPROM has to be attached to it to maintain the configuration, that would mean the mapper logic has to be in an EEPROM and not in some complex chip, so it make things sound even easier. Exept when it comes to programm the FPGA.
Another idea would be to just have a 74xx series MMC1 like Flash reprogrammable board. It is possible and not too expensive to build a pseudo-MMC1 with about six or seven 74xx chips. You basically need one shift register, two couple of gates for adress decoding, 4 5-bit flip-flops and output logic. You could even customise it to reduce the number of chips to reduce the number of features (typically a CHRAM only board would need much less flip-flops, as would a board with fixed bankswitching mode). So that we could end up with a board with MMC1 like mapper, but limited functionality and cost. Also the code running on it would be 100% compatible with an actual MMC1 chip, wich is good.
I know it's hard to chose a component when you have too much choise. Often lists are so big you can't even have a clue on wich componant to use.
A good thing is take a chip wich has a more or less standard pinout. For example, most PICs are pin-to-pin compatible, even if there is hundred of variants of each PIC, wich is very confusing.
So yeah, a small project you said. It's better to have a small project that work fine than a big that doesn't. However, Memblers has done pretty well already. After a bit of trough I really seem to like more and more the FPGA idea. If an EEPROM has to be attached to it to maintain the configuration, that would mean the mapper logic has to be in an EEPROM and not in some complex chip, so it make things sound even easier. Exept when it comes to programm the FPGA.
Another idea would be to just have a 74xx series MMC1 like Flash reprogrammable board. It is possible and not too expensive to build a pseudo-MMC1 with about six or seven 74xx chips. You basically need one shift register, two couple of gates for adress decoding, 4 5-bit flip-flops and output logic. You could even customise it to reduce the number of chips to reduce the number of features (typically a CHRAM only board would need much less flip-flops, as would a board with fixed bankswitching mode). So that we could end up with a board with MMC1 like mapper, but limited functionality and cost. Also the code running on it would be 100% compatible with an actual MMC1 chip, wich is good.
Quietust wrote:
There do exist 5V FPGAs, they're just not as common anymore.
Not common often means not affordable.
Bananmos wrote:
My ideal universal cart would be centered around a modest FPGA, a CompactFlash/SD memory and a USB microncontroller that would make the cart act like a regular mass storage device when plugged into the PC. You could then use a flash memory of desired size, and on power-on you'd just select the appropriate .NES-file to run. The appropriate bitfile to emulate the mapper would then be loaded to the FPGA before the game starts.
Replace the flash memory with RAM and you have pretty much described how SuperCard for GBA works.
Quote:
Besides that, somewhere along the way I realized that a project like this is a bit too big to do at once and it'd be better to do an easier project to begin with. So I have started making an USB CompactFlash cart for the Sega Mega Drive instead. [...] implemented a mapper chip on an XC95108 CPLD that acts as either a Sega Master System mapper or a simple "Megadrive mapper"
Once you do that, you can make the ultimate UOROM card, right? Isn't the Sega Master System mapper a lot like what UNROM would be with an additional 16 KiB bank at $4018-$7FFF?
That said, I've sketched out an idea for a decent 4-chip 7400 mapper, and I'm about to post it in NES Hardware.
tepples wrote:
Quietust wrote:
There do exist 5V FPGAs, they're just not as common anymore.
Not common often means not affordable.
Digikey has Altera FLEX 6000 FPGAs for around $30 apiece. A little bit expensive, but not what I would call "not affordable".
Quietust wrote:
There do exist 5V FPGAs, they're just not as common anymore.
I meant a FPGA from within the last 10 years.
Quietust wrote:
Digikey has Altera FLEX 6000 FPGAs for around $30 apiece. A little bit expensive, but not what I would call "not affordable".
I would call that unreasonable since +5V CPLD, still available, which can easily hold MMC3 and even more register heavy Konami/Sunsoft mappers, cost under $10. 140 macrocells should be able to emulate any current mapper which doesn't touch the CHR data bus or have expansion sound.
tepples wrote:
Replace the flash memory with RAM and you have pretty much described how SuperCard for GBA works.
Add a FPGA to that and you have something developed for FC in 1990 ;)
Yes, 16 years ago there was a device which conveniently loaded a JEDEC along with the game.
I think the best method would be to use FlashROM, SRAM and a CPLD. The implementation would be very similar to FunkyFlash but instead of flashing through boundary scan, flashing should be done with a base unit like a GB linker (which could also dump.) Configuration of the CPLD would be done through the cartridge data bus (D0-2). All that would be needed is a 74244 to open the connection when not configuring the device. Another much smaller CPLD could be used as well to handle configuration and free up some macrocells from the big CPLD for small tasks such as WRAM decoding or a manual switch could be used for programming.
Quote:
Replace the flash memory with RAM and you have pretty much described how SuperCard for GBA works.
I'm not sure what you mean by "replace the flash memory with RAM". Both the RAM *and* a CF/SD memory are needed of course, though the later is of arbitrary size and provided by the user. One of my problems will be to decide what type of RAM to use to have 8 megabytes of it. I've considered SRAM (which is expensive and only comes in smaller sizes), SDRAM (which would require adding a refresh circuit to the CPLD core) and PSRAM. (which only come in BGA packaging and are only sold in quantaties of thousands)
I looked at the SuperCard, but I'm still not sure how it works. It doesn't seem to use a USB cable, and thus doesn't act like a mass storage device at all? Seems to use need its own software and additional patching of the ROMs? (correct me if I'm wrong here) That doesn't seem very user-friendly...
Quote:
Once you do that, you can make the ultimate UOROM card, right? Isn't the Sega Master System mapper a lot like what UNROM would be with an additional 16 KiB bank at $4018-$7FFF?
More or less. It also controls SRAM mapping though. (currently unimplemented since I only have 2 sets of 512kB SRAMs on the prototype board anyway, and only the lower chip is used in SMS mode.
Quote:
Digikey has Altera FLEX 6000 FPGAs for around $30 apiece. A little bit expensive, but not what I would call "not affordable".
That's pretty much expensive, but keep in mind it would be a all-in-one investisment and that cart could then play hundreds to thousands of games.
For storage, I think Flash or EEPROM is better than SRAM, just because disable the SRAM on proper time can be a pain. Actually it could work easily for PRG-ROM, and I don't know how common 512kb SRAM chips are. You could just keep it battery backed, and be sure to disable the chip when anything is written on $8000-$ffff, wich is needed for any type of ROM anyway. However, to simulate CHRROM with a SRAM would be a lot harder, to disable the chip on proper time if the program ever tries to write to the CHROM, wich is normally totally illegal. The advantage would be that the same chip could handle CHROM and CHRAM, and only the way it's used and adressed would make difference (typically for CHRAM the chip could be writable by software and only the first 8kb would ever be adressed, while in CHRROM mode the whole chip would be write-protected and battery backed.
I think Flashroms would be better write-protected and safe at power down than battery backed SRAMs.
About the CPLD/FPGA debate, I think a CPLD may hold a simplistic MMC5 with only PRG and CHR bankswitching and IRQ capabilities (letting alone sound, EXRAM and all it's uses, special graphic modes and SRAM bankswitching), so that it can proprely run at least Castlevania III and Laser Invasion. Only the boring Koei games, Just Breed and that Majong game couldn't ever be played on a CPLD cart. Also, VRC6 and VRC7 may be a little too much complicated for the CPLD letting alone the japansese Castlevania III and Laser Invasion (but the US/PAL version could be played anyway), Lagrange Point, and a couple of RPGs by Konami. Almost every other game could be played. So I don't think FPGA is needed, but maybe it is.
Actually Akumajou Densetsu/VRC6 can easily fit onto a CPLD, it requires about 120 macrocells. VRC7 can probably too, I haven't tried. All games with similar bankswitching schemes have similar requirements.
Also both protection against writing PRG and CHR ROM is very simple, all it requires is two register bits and two OR gates to lock the /WR pins on the RAM.
Also both protection against writing PRG and CHR ROM is very simple, all it requires is two register bits and two OR gates to lock the /WR pins on the RAM.
kyuusaku wrote:
Actually Akumajou Densetsu/VRC6 can easily fit onto a CPLD, it requires about 120 macrocells. VRC7 can probably too, I haven't tried.
VRC7 bankswitching could fit easily enough, but forget about trying to fit the sound in such a small chip (because Lagrange Point is effectively nothing without its magnificent music).
There's always Tiny Toons 2 J and homebrew potential which deserve an implementation.
Bananmos wrote:
I'm not sure what you mean by "replace the flash memory with RAM". Both the RAM *and* a CF/SD memory are needed of course, though the later is of arbitrary size and provided by the user. One of my problems will be to decide what type of RAM to use to have 8 megabytes of it.
8 MiB? No NES or Famicom game is larger than 1 MiB, apart from multicarts.
Quote:
PSRAM. (which only come in BGA packaging and are only sold in quantaties of thousands)
Are you sure about these drawbacks of PSRAM? Can you cite sources?
Quote:
I looked at the SuperCard, but I'm still not sure how it works. It doesn't seem to use a USB cable, and thus doesn't act like a mass storage device at all?
SuperCard has a 32 MiB RAM (to hold the running program, believed to be some form of PSRAM), a 64 KiB RAM (for saving), and an ATA interface (for reading the CF card).
Quote:
Seems to use need its own software and additional patching of the ROMs?
SuperCard patches GBA games for three reasons, mostly related to saving:
- There are three GBA mappers, distinguished by how they save. Patches mapper-hack games that use the serial EEPROM mapper or the 8-bit flash mapper to use the 8-bit SRAM mapper instead.
- SuperCard save memory is not battery backed. Patches make the game occasionally write the SRAM to the CF card.
- "Exit hack" allows the game to go back to the menu.
Bregalad wrote:
That's pretty much expensive, but keep in mind it would be a all-in-one investisment and that cart could then play hundreds to thousands of games.
We have to decide: Are we trying to make carts solely for development and piracy, or should we consider how to make carts for replication once we get some sort of lockout defeater working?
Quote:
8 MiB? No NES or Famicom game is larger than 1 MiB, apart from multicarts.
Nope, but I was only babbling on about my current project, which is a USB MSD cart for the Sega Mega Drive. For a NES equivalent, the RAM size wouldn't be a problem since the price of 1MB-2MB of SRAM is still reasonable for the cart's functionality. But there, the choice of a suitable FPGA is a bigger dilemma.
Quote:
Are you sure about these drawbacks of PSRAM? Can you cite sources?
No, I'm not certain. Only thing I know is that I've spent countless hours googling "PSRAM" along with other keywords, and have never managed to find any evidence for PSRAMS in non-BGA packages. And all sites I found had no pricing information. I only tried to ask for pricing information on one of Samsung distributors here in Sweden, and they informed me that they don't have it in stock and that the minimum order quantity from Samsung is 3,600 pieces. But if you find evidence to counter my somewhat premature claims, no one would be happier than I.
Hey, just to go a total different way....
As long as Artos' Flash Cart can run 95% of existing NES games (commercial and homebrew) duplicate it isn't very much necesary.
So if the option would be to build a cart with super-powerfull mapper instead, I think that would be cool too.
I have a nice idea : A PIC or similar microcontroller could write data into an external RAM during the frame, and a programmable logic circuit would read it for the previous frame in order to replace normal attribute and maybe pattern table data by graphics that would be buffered in the external RAM (there exists chips that have a different bus for reading and writing for this kind of purposes...) Also, the NES CPU would just tell instructions to the PIC processor trough a communication bus and registers, and the PIC would handle parametring and comunicating with the programmable logic circuit, but during rendering all the fast operations would just be read by the logic circuit trough the RAM buffer. The programmable logic circuit could also hold some PRG bankswitching and IRQ counters.
This is just a basic sheme of how a very modern and powerfull NES mapper would be. Then, color resolution can go up to 8 pixel horizontally, and 1 pixel vertically, but unfortunately you're stick with 4 BG palettes, wich make things pretty limited. However, quite nice effects could go, including :
- Show raw 13-color bitmaps wich are just stored in a special format with this horizontal limitation. Videos could even be displayed, but that would waste a lot of memory !! Also, only a small portion of the screen could use such graphics for example just a face picture in a RPG that would be more detailed.
- Do transparency effects (no flickering). It's common use to have NES palettes composed of the same color, but with different light intensity (i.e. $0f, $07, $17, $27; $0f, $01, $11, $21, etc..) because it allow luminosity effects and make games look a lot nicer (at least to my personal experience).
So the chip could manually add '1' or '2' to given pixels regardless of scrolling, and by overlapping the color addition to the nomral color, this would create AWESOME light&transparency effects on the NES !
- Very fast moving BG data : Typically, the NES programm could tell the pic to render very different images in the buffer from one frame to another and trus do a lot more than what normal NES BG can do without any particlary complicated algorithm in the PIC : Typically move a fighter totally in BG in a fighting game to trick the 8-sprite limitation.
Of course, multi-layered background, polygon rendering of 3D images and mode-7 comes in mind, but that would work only in 4-color mode and would look very bad I think. I personally would prefer the effects I listed above to those classic things everyone has in mind. I hope this will give everyone some ideas. I'm not hoping something particular to be made, just imaginating pushing the NES cartridge connector to it's limits !!
As long as Artos' Flash Cart can run 95% of existing NES games (commercial and homebrew) duplicate it isn't very much necesary.
So if the option would be to build a cart with super-powerfull mapper instead, I think that would be cool too.
I have a nice idea : A PIC or similar microcontroller could write data into an external RAM during the frame, and a programmable logic circuit would read it for the previous frame in order to replace normal attribute and maybe pattern table data by graphics that would be buffered in the external RAM (there exists chips that have a different bus for reading and writing for this kind of purposes...) Also, the NES CPU would just tell instructions to the PIC processor trough a communication bus and registers, and the PIC would handle parametring and comunicating with the programmable logic circuit, but during rendering all the fast operations would just be read by the logic circuit trough the RAM buffer. The programmable logic circuit could also hold some PRG bankswitching and IRQ counters.
This is just a basic sheme of how a very modern and powerfull NES mapper would be. Then, color resolution can go up to 8 pixel horizontally, and 1 pixel vertically, but unfortunately you're stick with 4 BG palettes, wich make things pretty limited. However, quite nice effects could go, including :
- Show raw 13-color bitmaps wich are just stored in a special format with this horizontal limitation. Videos could even be displayed, but that would waste a lot of memory !! Also, only a small portion of the screen could use such graphics for example just a face picture in a RPG that would be more detailed.
- Do transparency effects (no flickering). It's common use to have NES palettes composed of the same color, but with different light intensity (i.e. $0f, $07, $17, $27; $0f, $01, $11, $21, etc..) because it allow luminosity effects and make games look a lot nicer (at least to my personal experience).
So the chip could manually add '1' or '2' to given pixels regardless of scrolling, and by overlapping the color addition to the nomral color, this would create AWESOME light&transparency effects on the NES !
- Very fast moving BG data : Typically, the NES programm could tell the pic to render very different images in the buffer from one frame to another and trus do a lot more than what normal NES BG can do without any particlary complicated algorithm in the PIC : Typically move a fighter totally in BG in a fighting game to trick the 8-sprite limitation.
Of course, multi-layered background, polygon rendering of 3D images and mode-7 comes in mind, but that would work only in 4-color mode and would look very bad I think. I personally would prefer the effects I listed above to those classic things everyone has in mind. I hope this will give everyone some ideas. I'm not hoping something particular to be made, just imaginating pushing the NES cartridge connector to it's limits !!
Bregalad wrote:
Hey, just to go a total different way....
As long as Artos' Flash Cart can run 95% of existing NES games (commercial and homebrew) duplicate it isn't very much necesary.
As long as Artos' Flash Cart can run 95% of existing NES games (commercial and homebrew) duplicate it isn't very much necesary.
So without selling copies, how does a developer eat?
Quote:
So without selling copies, how does a developer eat?
Well, anyone hoping to put food on his table thru NES game development should be prepared to loot the local garbage cans for lunch.
I didn't mean "day job". I meant "something that makes the whole effort not a complete waste of time".
I'm not much interested in money, and I hope noone in this board is. What I'm interested in is to programm for the NES system. Pushing the hardware in it's limits is something interesting.
Bregalad wrote:
I have a nice idea : A PIC or similar microcontroller could write data into an external RAM during the frame, and a programmable logic circuit would read it for the previous frame in order to replace normal attribute and maybe pattern table data by graphics that would be buffered in the external RAM
I like the idea, I remember thinking of something similar a while back too. I also drew part of a schematic for allowing the NES CPU to write to VRAM at any time. Using discrete parts though there were 6 octal bus drivers, amongst other stuff. It requires a lot of I/O pins any way it's done. I also never figured out exactly how to generate a write cycle without doing some real dirty tricks or using expensive/rare parts.
Quote:
(there exists chips that have a different bus for reading and writing for this kind of purposes...)
AFAIK they're expensive, very small, and you still actually can't write and read them at the same time. Seems to only move the pin count over to the RAM chip. I think it'd be better to use a standard RAM through some wild custom interface like Bananmos mentioned earlier in the thread.
Actually right now I'm looking at different chips that I could upgrade my Squeedo PIC to. Would be really great to switch to dsPIC, but Squeedo uses the PIC's parallel port to great advantage, and no version of the dsPIC has that. Haven't found a decent way to replace it..
Actually one solution that comes in mind would be to use TWO chips of RAM, to crate a double-buffered frame buffer.
You'll need a PIC with a lot of I/O pins. Also, there exits SRAM chips with IIC interface, but I think they're rare and much slower than parallel 62xxx SRAM chips. The PIC would just open it's bus on one chip, and deal with the other chip, while the discrete logic componant can read the first chip. On next frame, the bus that was open by the PIC become used, and vice-versa. Not sure how hard it would be to do and how well it would work.
Another idea would be to have the PIC only dealing with it's internal memory during the frame, and during VBlank, the programmable componant would trigger a kind of DMA trough the PIC from it's internal RAM to external SRAM/DRAM, and then during the frame the PIC could do it's rendering work again while the programmable componant would adress and read the frame buffer SRAM/DRAM and deal with the PPU bus. That solution sound almost idea, but I don't know if such a DMA is possible on PICs. Maybe on dsPICs.
I'm unsure of what parallel port you're talking about. You mean the PSP module, or just normal ports you can freely write to and read from ?
You'll need a PIC with a lot of I/O pins. Also, there exits SRAM chips with IIC interface, but I think they're rare and much slower than parallel 62xxx SRAM chips. The PIC would just open it's bus on one chip, and deal with the other chip, while the discrete logic componant can read the first chip. On next frame, the bus that was open by the PIC become used, and vice-versa. Not sure how hard it would be to do and how well it would work.
Another idea would be to have the PIC only dealing with it's internal memory during the frame, and during VBlank, the programmable componant would trigger a kind of DMA trough the PIC from it's internal RAM to external SRAM/DRAM, and then during the frame the PIC could do it's rendering work again while the programmable componant would adress and read the frame buffer SRAM/DRAM and deal with the PPU bus. That solution sound almost idea, but I don't know if such a DMA is possible on PICs. Maybe on dsPICs.
I'm unsure of what parallel port you're talking about. You mean the PSP module, or just normal ports you can freely write to and read from ?
Bregalad wrote:
I'm unsure of what parallel port you're talking about. You mean the PSP module, or just normal ports you can freely write to and read from ?
Yes, the PSP. I did some reading up the other day on Microchip's site, and actually the PIC24 sounds very nice. Some of them have a PMP (Parallel Master Port) for writing memory, and a DMA too (I'm not sure if that extends to the PMP peripheral, it very well might). It's a 3V chip with some 5V tolerant inputs, I was getting tempted to design it into Squeedo until I noticed the flash can only be written 1000 times..
That's quite a few times, but very reachable for someone doing PIC experimenting.
Sadly (or not, it's a pretty damn fun chip), I'll probably just stick with my current PIC18F family. Maybe upgrade to the newer one with a bit more flashrom (which would be the 4th PIC upgrade for Squeedo, wow, all with the same pinout too).
PMP peripheral is coming to some PIC18 chips too, but they all seem to be "future products". Probably not a DIP-40 one though. DIP-40 sure takes up some PCB space, but it looks oldschool as hell and sure beats soldering .5mm pitch pins!
The double-buffering thing sounds like a fine idea too. Damn, all this PPU hackery would be a bit easier if we had an equivalent of the M2 line for the PPU. Really I don't even know if it's been established that the PPU bus ever goes tri-state. I know it's multiplexed, because it has that address latch internally. Damn, I should've kept notes when I was working on my crazy mapper a while back, heh.
Isn't the M2 line the main 22.??? MHz clock ? If so that'd be fabulous, because you could just made it the external oscillator input for your PIC. However, the lenght of the connector contacts could significantly bring high noise to that fast clock. I don't know if that's what you have been doing, since nobody had any shemtics, and all pictures are down now.
1000 times is a lot, but if you manage to programm it on board, it will be actually not quite a lot. The main issues with PICs is that there is so many different version of them with so slight differences !!
It's a very fun thing, at work I'm working with PIC 18F252 and 18F2525 wich are the 28-pins counterparts of those you used on your squeedo, 18F452 and 18F4525. That's pretty much a micracle, considering how many different 18xxx there is on the market (above the hundred).
PIC24s looks good, but I don't know what you would gain from a 18xxx exept speed, if you use an external oscillator independant to the NES' wich I definitely wouldn't do for evident syncronisaiton issues.
Yeah, I agree DIP-40 looks oldscool as hell Actually even DIP-28s looks somewhat oldscool, while DIP-28 large looks just normal. A chip looks oldscool when it's much longer than wide, definitely. However, regardless of looking, a great advantage of DIP chips is that you can just programm them without any expensive adapter. This of course is no longer significant when you get on-board chip programming. An advantage of PLCC package would be that you can use very-low profile sockets to fit a cartridge plastic case.
If you need any help, don't hesitate to ask. Many people are very top-knownledged on detailed PPU operations I have trouble to undestand (especially Blargg and Quiestus), and I think I have some experience with hardware stuff such as shematic design and microcontroller programming, so don't hesitate to ask for ideas ! Squeedo sounds great, and improving it sounds even better !
1000 times is a lot, but if you manage to programm it on board, it will be actually not quite a lot. The main issues with PICs is that there is so many different version of them with so slight differences !!
It's a very fun thing, at work I'm working with PIC 18F252 and 18F2525 wich are the 28-pins counterparts of those you used on your squeedo, 18F452 and 18F4525. That's pretty much a micracle, considering how many different 18xxx there is on the market (above the hundred).
PIC24s looks good, but I don't know what you would gain from a 18xxx exept speed, if you use an external oscillator independant to the NES' wich I definitely wouldn't do for evident syncronisaiton issues.
Yeah, I agree DIP-40 looks oldscool as hell
Actually even DIP-28s looks somewhat oldscool, while DIP-28 large looks just normal. A chip looks oldscool when it's much longer than wide, definitely. However, regardless of looking, a great advantage of DIP chips is that you can just programm them without any expensive adapter. This of course is no longer significant when you get on-board chip programming. An advantage of PLCC package would be that you can use very-low profile sockets to fit a cartridge plastic case.
If you need any help, don't hesitate to ask. Many people are very top-knownledged on detailed PPU operations I have trouble to undestand (especially Blargg and Quiestus), and I think I have some experience with hardware stuff such as shematic design and microcontroller programming, so don't hesitate to ask for ideas ! Squeedo sounds great, and improving it sounds even better !
Maybe you oughta wait with redesigning Squeedo for just a moment... it seems the lockout chip is about to be 0wn3d finally, and if the CIC functionality could be easily emulated by an MCU and some buffering logic, that mission alone justifies making a custom board with an MCU in it. :)
Perhaps writing during rendering could be as simple as a 2006/7 clone which empties the buffer on the rising edge of /rd && /wr (or during a read cycle of PPU A13 = hi)
I like the idea of using fast SRAM for DMA as well. Too bad PRG ROM (and internal VRAM) is so slow..
I like the idea of using fast SRAM for DMA as well. Too bad PRG ROM (and internal VRAM) is so slow..
Seems right now it's worth the wait to have both the actual reverse enginer of the CIC and the latest PIC18 devices with PMP port !
Using stupid tricks to overload the CIC with -5V and make it overheight are a bit fun, but a bit stupid I found.
Using stupid tricks to overload the CIC with -5V and make it overheight are a bit fun, but a bit stupid I found.
I'm excited about the CIC being RE'd too, but once we know how it works it's like they said on GI Joe, "knowing is only half the battle". The Tengen CIC was for North America only, and there's plenty of other NES regions to figure out.
And personally I'd rather use a 2nd MCU for the lockout chip, like PIC10F family or something else really small. It seems wasteful to have a really good MCU farting around with CIC stuff, heh. If I'm really smooth I could fit it in the normal CIC pinout, but I'm not at home so I can't check if that's possible at the moment.
And personally I'd rather use a 2nd MCU for the lockout chip, like PIC10F family or something else really small. It seems wasteful to have a really good MCU farting around with CIC stuff, heh. If I'm really smooth I could fit it in the normal CIC pinout, but I'm not at home so I can't check if that's possible at the moment.
And also, if we want the PMP on the PIC, we'd be better off just getting it now from the 24F series. It looks like the 18F ones being made with the PMP are also standard Flash (rather than the enhanced Flash like the 18F4525). But with them all being fine-pitched parts, as much as I'd like having more I/O pins, I'm not too excited about soldering a bunch of those.
Quote:
I'm excited about the CIC being RE'd too, but once we know how it works it's like they said on GI Joe, "knowing is only half the battle". The Tengen CIC was for North America only, and there's plenty of other NES regions to figure out.
The microprocessor is most certainly the same, only the code will differ.
Then, you could include a code that tries all regions, and switch to another if the NES CIC doesn't seem to answer correctly to a given region. This will do an universal CIC that will work with all NES ever made, including those with modern "secured CICs" and with no CICs at all.
Quote:
And personally I'd rather use a 2nd MCU for the lockout chip, like PIC10F family or something else really small. It seems wasteful to have a really good MCU farting around with CIC stuff, heh. If I'm really smooth I could fit it in the normal CIC pinout, but I'm not at home so I can't check if that's possible at the moment.
I just figured it would be a pain to get something possible both with the pinout of the CIC and the pinout of anyother MCU out there. Pins 1, 2 and 3 must definitely be input ports, pin 4 could be VSS (since it's grounded anyway for CICs on the cart) and then any MCU coming in a DIP8 package with ground pin on pin 4 and VCC pin on pin 8 could do. Clock input and reset could be ported to pins 5-7 that are not connected to the CIC (or grounded).
The problem is that the DIP8 pics available have a totally different and annoying pinout, I haven't figured if there were any other MCU in DIP8 package.
EDIT : Here you are the final version of a universal cart with a real CIC and CIC defeater PIC10F DIP8 based MCU.
Notice : PIC10F must be placed in the other polarity than the CIC, and one slot backwards. I know it's not too good looking, but the best I've found.
Code:
___________
1 : DATA_OUT |____\/____| 16 VCC
2 : DATA_IN | | 15 : DATA_OUT*
3 : N/C ? | PIC10Fxx | 14 : 4MHz CLK*
4 : GND | | 13 : VCC*
5 : /RESET IN* |____/\____| 12 : N/C ?
6 : 4MHz CLK | | 11 : N/C
7 : RESET IN | CIC | 10 : N/C (output)
8 : GND | | 9 : N/C (ouput)
+----------+
* : Was origially no connect on CIC, but is served here as PIC10F input/output. Normally shouldn't cause any significant issues.
N/C ? : Is no connected on both the CIC and the PIC10F. Maybe it's better to ground it ?
DATA_IN is PIC10F's GP0 I/O.
DATA_OUT is PIC10F's GP1 I/O.
1 : DATA_OUT |____\/____| 16 VCC
2 : DATA_IN | | 15 : DATA_OUT*
3 : N/C ? | PIC10Fxx | 14 : 4MHz CLK*
4 : GND | | 13 : VCC*
5 : /RESET IN* |____/\____| 12 : N/C ?
6 : 4MHz CLK | | 11 : N/C
7 : RESET IN | CIC | 10 : N/C (output)
8 : GND | | 9 : N/C (ouput)
+----------+
* : Was origially no connect on CIC, but is served here as PIC10F input/output. Normally shouldn't cause any significant issues.
N/C ? : Is no connected on both the CIC and the PIC10F. Maybe it's better to ground it ?
DATA_IN is PIC10F's GP0 I/O.
DATA_OUT is PIC10F's GP1 I/O.
Also is the CIC reset active high or low ? If it's active high an inverter should be added before pin 5, because PIC's reset is active low. This could be done with a 74HC04, 74HC14 or a comparator easily.
jit dukescript style high-level programmable.
possibly rpn.
(yes i am insane.)
possibly rpn.
(yes i am insane.)
RPN? Let me guess: You're putting in something like FALSE. There exists a compiler for FALSE whose MC68000 object code size is 1024 bytes. Now you're talking sense.
tepples wrote:
RPN? Let me guess: You're putting in something like FALSE. There exists a compiler for FALSE whose MC68000 object code size is 1024 bytes. Now you're talking sense.
Something like that might do, but probably not exactly FALSE, just similar, modified in a way that is best for this kind of things. I also like Reverse Polish Notation.
However, I think just a simple very small coprocessor (simple PIC maybe?) where you can put a small code in there that emulates the mapper you want (such that it can emulate most of the common mappers used in homebrew). In this case, a new iNES mapper number should be added for this, and then any variation of the mapper you make up for this can also be emulated in NES emulators on computer loaded from a .NES file (and that a (Free) program can be written to transfer a .NES file to the cartridge and vice versa)
A Really inexpensive Mapper, About $5-$10 for one or the likes, It can be:
- Part-compatible= Mixed Sunsoft's FME7 and MMC3
- Fits as well as being compatible with Retrozone's Retrokit MMC1
- Mapper that has support for a 8-16 bit IRQ select reg
- 16 bit IRQ compatible with Sunsoft IRQs
- 8 bit MMC3 compatible IRQ
- Mirroring Modes from FME7 (or MMC5-like custom mirroring)
- 00-1f = ROM and CHRROM banks
- 8k RAM Bank(s) at:
6000 if REG $6000 = $80
8000 if REG $8000 = $80
A000 if REG $A000 = $80
C000 if REG $C000 = $80
E000 = Fixed, no RAM
That's it
- Part-compatible= Mixed Sunsoft's FME7 and MMC3
- Fits as well as being compatible with Retrozone's Retrokit MMC1
- Mapper that has support for a 8-16 bit IRQ select reg
- 16 bit IRQ compatible with Sunsoft IRQs
- 8 bit MMC3 compatible IRQ
- Mirroring Modes from FME7 (or MMC5-like custom mirroring)
- 00-1f = ROM and CHRROM banks
- 8k RAM Bank(s) at:
6000 if REG $6000 = $80
8000 if REG $8000 = $80
A000 if REG $A000 = $80
C000 if REG $C000 = $80
E000 = Fixed, no RAM
That's it