I have an idea for making an NES cart that does something I've never heard anyone doing before. Problem is, I don't have the skills to put this into action. Here's the gist of the idea.
- Make a cart that consists of an FPGA, some RAM, a small ROM and an interface to some flash memory (I was thinking a CF card would be cool).
- The FPGA works as a mapper emulator. I don't see any reason this would not be doable, since basically what it would be doing is what any PC NES emulator has been doing for years, except it doesn't need to emulate the CPU and PPU and all that. It also includes some sort of interfacing circuitry to read files and treat them as ROMs for the NES' sake.
- The ROM would work as the front-end to let the user select the file. I'm not too sure what would need to be done to read the data from the header to tell the FPGA how to work yet though. I figure it'd be possible to store some of that info in the filename too (for example, MMC3 -> mapper 4, so instead of naming the file .NES it becomes .04(something)). I know that mirroring and other stuff would need to be told to it too probably, so it's not a perfect solution, but it's on its way.
- And of course, the RAM is there for the NES to use, and perhaps for the mapper to throw the PRG and CHR space into so the NES sees it.
Any thoughts on this? Is it even feasible to make something simple that supports the MMC mappers and the like? Or even make a CF interface to an existing board to replace the ROMs?
This is my first post on these boards. Hi everyone.
I think the biggest problem with an FPGA cartridge is the lockout chip. How did you plan to get around it?
The lockout chip is rather easy to deal with. Just pull them off cheap NES games. Or use some kind of pass-through with a licensed game.
A more important issue is what kind of a FPGA will be needed to emulate the MMC chips. Would it be flexible and powerful enough to emulate the MMC5, with its ExRAM, vertical split screen mode and extra sound channels?
Don't mean to be rude but this idea has been suggested on just about every message board I've ever visited. I think if someone had the skill and desire, they'd have already thought of this and started on the project already... The problem is that the people who suggest it have no understanding of the time and knowledge it would take to put together something this substantial. Yes it's doable but I don't think anyone who can actually pull it off needs suggestions like "My idea is to use RAM to emulate ROM!"... This idea is commercial-grade, something that companies usually invest 6 figures in.
Re emulation: Emulating "mappers" in hardware is FAR different than theoretically emulating them in software. Recently I've been toying with "mapper" emulation and my biggest block (other than my lack of knowledge) is the absense of hardware related NES technical info on the net.
What I've come to realize is that emulating MMCs isn't as hard as many think. People (Chinese) have been doing it with PLD since 1989 ;)
Re FPGA type: Many *CPLD* could replicate MMC3. As a general rule, FPGAs are 10+ times better than their CPLD family members. So, if you use a Vertex+ of course you can emulate MMC5 with sound channels 'ehrm maybe (although you may need external circuitry and immense knowledge of the expansion audio's path) One thing to think about is how the unit will program the FPGA, (will it be NV or will you need the console to program it at startup) it would make sense to program it insystem so you could update the fusemap through your storage device. Probably, you'll need a CPLD & a FPGA.
I've designed a CPLD based "development cart" already and have plans to actually make a fullblown FPGA based GD clone. This will be SOMEWHAT similar to the hopefull CF unit except I'll be using archaic techniques ( trainers) to emulate MMC and some other tricks most NES users wouldn't touch let alone appreciate.
Heres my idea for a minimal part list for such a universal cartridge:
512K PRAM (Flash/SRAM/DRAM) (select page at $8,A,C,E)
512K CRAM (SRAM/DRAM) (select page at $0,0400,0800...$1C00 etc)
32K ROM/NVRAM (bootstrap)
64K WRAM (bankswitchable)
4K on CHR bus for "4 screen" games
CPLD (for flash memory memory/CF controller or DRAM refresher and most importantly the startup logic and FPGA UART)
FPGA (the FPGA will need to sit on everything, have internal RAM and have a internal multiplier if it's going to emulate MMC5.)
BTW, if someone actually tries the CF route, this page would be helpful:
http://s.guillard.free.fr/Apple2IDE/Apple2IDE.htm
Kevin Horton (aka kevtris) actually considered doing this at one time, but then he decided to do something even better - fit the entire NES inside an FPGA on a decently-featured board. He even managed to succeed.
Board (top)
Board (bottom)
The last reported count of supported mappers was 91, mostly simple ones, but including the MMC1-MMC4 and VRC1-VRC4/VRC6. He's even planning on doing other consoles as well, like the Atari 2600, Sega Master System, Colecovision, and others.
Yep, I've played games and heard NSFs on Kevin's console prototype, I can vouch for it. It's totally awesome, the sound and video is perfect.
Everyone knows a universal NES cart would not be easy to make or cheap to buy, might as well spend a little more to get a whole universal console while we're at it.
In my previous post I was going to write "Kevin Horton, your only hope" :wink:
I'm very impressed with Kevin's accomplishment.
I've seen 6502 CPU data for FPGAs, but I guess he made the PPU data, from reverse engineering it.
I see that he's getting closet to having all the major mappers. FDS support would be a bit harder, as you'd have to emulate the drive and hardware.
Still this is a crazy project...
drk421 wrote:
I've seen 6502 CPU data for FPGAs
The only one I had seen was written in VHDL, but it was NOT cycle accurate; Kev's CPU (actually, the entire system) is pretty much designed as a multi-level block schematic (which can optimize far better) and IS cycle-accurate. APU is pretty much flawless as well, though his PPU still needs some fixes (namely, it fetches sprites in the wrong order, messing up Punch-Out!!). If you browse
http://tripoint.org/kevtris/mappers/incoming you'll find a bunch of screenshots of games he's tested.
Unfortunately, he doesn't have the time or talent to make a spiffy webpage for this nifty thing - evidently, designing hardware and designing webpages require completely different skills.
Well, I'm sorry for coming up with an unoriginal idea. Actually, I am quite aware of what a pain in the ass it would be. But the main idea was that it would only need to be done once, and once it was done hopefully many would benefit. I didn't mean to insinuate that I knew better than anyone else, either, I was just openly theorizing how I would implement certain features to make sure they would work (to be honest, since I'm not too sure how CF is addressed, it might not even need RAM to buffer to). Regardless, I thought it would be a fun thing to do, but Kevin Horton has indeed beaten me to the punch (because quite honestly, the man is a genius).
I'm not sure exactly why making mapper hardware is harder than emulating it in software- from what I understand, VHDL can be coded just like a regular programming language.
BTW, I meant CPLD I think when I said FPGA. Since I'm not an electrical engineer I tend to get those sorts of terms mixed up.
Anyway, glad to hear that I wasn't completely off-base in thinking it could be done. Thanks for your feedback, all.
FDS support would not be very difficult to add, actually. It'd be hard to actually run the FDS disks themselves, but emulating that would be like emulating any other mapper, really. Everyone thinks the FDS is so special, but it's really not. IIRC, the disk is completely stored on the RAM adapter before it's run, which would make that quite easily emulated. Or at least, not really any harder than anything else.
Quote:
he doesn't have the time or talent to make a spiffy webpage for this nifty thing
If he has any interest, maybe we could volunteer to take over the "support" phase of this project. I'm assuming Kev wants to avoid the 1000 emails a day he would get from people who don't understand what this thing does. Someone else could run the site and handle those types of questions. I'd be willing to do this if it seems like a decent idea. Or we could put it on the Wiki and share the hardship of support with the whole community. I like this a lot better than having the work die (like the Copynes did) due to lack of documentation and support. Of course, it's KH's intellectual property and he can do as he pleases, just seems like a complete schematic capture of a NES-on-a-chip, and the mappers, would benefit a lot of of projects.
SgtBowhack wrote:
IIRC, the disk is completely stored on the RAM adapter before it's run
FDS disk: 64 KB per side.
RAM adapter: 32 KB EWRAM, 8 KB VRAM.
Many programs came on two disks.
But then, you could emulate the FDS by rewriting the BIOS to speak ATA PIO rather than speaking FDS low-level control signals.
One could easily emulate a FDS (before MMC5) but of course it'll require a flexible system due to the FDS's odd mapping. There are quite a few old Taiwanese FDS hardware emulators which are basically RAM adapters which play cartridges and swap sides via a pushbutton.
What do you mean by "before MMC5"? As far as I know, there was only one way to map the FDS games, right? I mean, they didn't have different versions of the RAM adapter that supported new stuff or anything (though that could've been kinda cool and extended the FDS' life maybe, provided it wasn't too expensive). Do you just mean it's simpler to do than MMC5?
Sorry about my ignorance regarding the FDS RAM adapter before. It makes some amount of sense that it'd be sort of emulating mapper 0 to the system, and I take it it just spools the data the Famicom would need then from the disk?
Were there really a lot of multi-DISK games? I know a bunch of games were dual-sided, but I've only seen a couple of games that require more than one disk. (I live in Kobe, Japan, so the FDS is still available somewhat here ^_^) I'm really learning a lot though, so I'm glad people are responding. Thanks for all of your input!
Yeah, I meant it'd be easier than emulating MMC5. And yup, only 1 FDS type. FDS is really close to NROM-256 besides the mapping and extra registers (sound/disk/IRQ.)
Quietust wrote:
Kevin Horton (aka kevtris) actually considered doing this at one time, but then he decided to do something even better - fit the entire NES inside an FPGA on a decently-featured board. He even managed to succeed.
Board (top)Board (bottom)The last reported count of supported mappers was 91, mostly simple ones, but including the MMC1-MMC4 and VRC1-VRC4/VRC6. He's even planning on doing other consoles as well, like the Atari 2600, Sega Master System, Colecovision, and others.
*fap* *fap* *fap* *fap* *fap* *fap* *fap* *fap*
For the love of god! Jesus-H-Christ! Name your price! I absolutely MUST have one! Please, for all that is sacred in this world, please tell me that Kevin Horton is going to eventually sell that!
*fap* *fap* *fap* *fap* *fap* *fap* *fap* *fap*
Cycle-perfect, pixel-perfect, soundwave perfect, etc... and can play every Famicom/NES game and use the original peripherials.
*fap* *fap* *fap* *fap* *fap* *fap* *fap* *fap*
AHHHH!!!
Anybody got an tissues? Seriously though, Kevin could make some good money, AND make many gamers very very happy if he would sell the end product, in a nice plastic chasis too
I swear to god I must be dreaming.
I forgot to ask, is it going to have a Famicom or NES cart port? I mean, if you are going to recreate everything exactly in hardware, you might as well recreate every expansion port and cartridge port... not for dumping, but just to make it a complete recreation of the original, with full support of all peripherials.
Then games could be played off of cart or flash.
The unit will NOT have a cartridge port on it - it is an emulator, albeit an incredibly low-level one. Besides, said cartridge port would only be useful for one console, and this unit is going to support multiple systems (including but not limited to Atari 2600, Sega Master System, Colecovision).
Quietust wrote:
The unit will NOT have a cartridge port on it - it is an emulator, albeit an incredibly low-level one. Besides, said cartridge port would only be useful for one console, and this unit is going to support multiple systems (including but not limited to Atari 2600, Sega Master System, Colecovision).
Is kevtris going to mass produce this retro-console?
Kevtris posted some info over at the Cherry Roms forum:
http://forums.cherryroms.com/viewtopic.php?t=3618