Anyone Interested in a Combined NES + Gameboy Cart?

Now that the HDMI project is in the bag and mostly thru production, I was wondering about a next project and had the idea for a really nifty flash cartridge.

Yes, there's two on the market right now (Power Pak and the Everdrive) but I was thinking of making my own to address the shortcomings of both, and to make it do just that little bit more.

So the bullet points would be:

* Full mapper support - including MMC5, mapper 90, etc
* Full expansion audio support like the HDMI adapter
* 1/8" stereo jack on the end of the cartridge that allows you access to line out stereo audio - no system mod required
* Audio would also exit in mono form on the usual pin for those that want an audio mod
* Digital audio is possible, since it will use a DAC so spdif and similar would be a theoretical option
* Gameboy support - ability to play GB ROMs natively on the cart with the NES outputting audio/video for the game
* SD card running in 4 bit mode for instant game loads
* Save states on select mappers (i.e. MMC1, MMC3, etc)
* Game Genie support of course
* USB to download code to test instantly
* High resolution menus using a 5 pixel high variable width font
* Low resolution menus using a 7 pixel high variable width font
* NSF playing with visualizer
* GB link port - you would have to transplant an existing GB link connector though
* CopyNES lite

There's probably a lot more dodads and geegaws I could add that I can't think of at the moment.

I figured since the existing flash carts on the market don't really do everything I want them to do and the odds of them being able to do so is slim to none, a new flash cart might be in order.

I have all the mappers done already on the FPGA NES so the mapper thing isn't a problem, and the FPGA gameboy is done also, so getting it to play GB games is not a problem either. For the variable width fonts and 5 pixel high text mode, I was going to have a CPU on the FPGA handle most of the menu stuff, with the NES merely acting as the output device. This frees me from all the vagaries of the NES graphics restrictions like waiting for vblank, and even the notion of tiles is completely made irrelevant. I can easily produce a full bit mapped NES display on the FPGA with it handling all the dirty pixel -> character translation, and I can even do 8 attribute changes per character.

So, what do people think about this type of thing? I am not sure if there is a market with the existing carts out there, but the complete(ish) mapper support and gameboy playing might push it over the edge. Cost would be in the $120-150 range probably.

Sounds cool! The Game Boy part is really interesting, and together with support for mappers that have been overlooked will surely guarantee a decent number of sales. I know I'm interested, and I already own the 2 existing flash carts.

It's a shame the NES can't do Game Boy Color graphics, because I'd really like to play that on the TV, and there's no way I'd buy a Game Cube + GB Player (shitty optical drive with moving parts that's bound to fail) just for that.

Yeah my GB core does do GBC right now. You'd only be able to play in 4 level greyscale unfortunately so that's why I wouldn't include it.

You could try running SMS and GBC games in "slivervision". It's not perfect, but it's at least better than "GBC ONLY" error messages.

• Set a constant palette 0F001020 0F172720 0F112120 plus a fourth possibly used for the UI.
• Output GBC games' graphics in 4-level grayscale, possibly with some sort of Bayer dithering.
• For each 8x1 pixel sliver, calculate the sliver's average chroma, test whether it's closer to gray, orange, or teal, and output that as the attribute. You can do this by calculating I from YIQ or Co from YCgCo. Co in particular is just R - B.

Put in slivervision for SMS and GBC, and I just might buy one.

FDS support?

Ability to customize menu?

Ability to add or customize mappers?

I am definitely interested despite already having an EDN8. I'd love to have a cart that actually supports MMC5 and the VRC's properly, and the GB feature sounds fantastic.

Would it be possible to make a famicom version? I'd buy a NES one, but it'd be nice to have it not triple the height of my famicom. :p

Please do include it! I'd love to be able to play GBC on the NES, even if it's in grayscale! If you think people will think less of your device because the GBC games don't look good, you can maybe leave this feature disabled by default, and display a warning about the color limitations when it's enabled.


Now you got me all excited about this. Man, playing SMS games on the NES would be awesome! Every FPGA console you can fit in there will make this cartridge even more awesome. It's really cool how having the VRAM bus available to the cartridge makes it simple to stream video at full speed, even if the colors are far from perfect. Can you imagine being able to play PC Engine/TG-16 games on the NES? That would be insanely cool, specially considering that not many people played it back in the day, and it's not a console that's easy/cheap to come by (except in Japan).


Definitely... the more consoles you include, the more I'll want to buy one.

I'm not so sure about the orange/teal suggestion, though... tepples, would you mind mocking up a screen with the algorithm you described? Scrolling would greatly affect the results, because the attributes would appear to "jump" in 8-pixel increments, which could be really distracting. This sort of color clash was extremely unpleasant on the Spectrum, and I'm afraid it would be in this case too.

I would definitly buy one in an heartbeat. If It can support bigger ROM than PP and EDN8 that's all the convincing I need but I got to admit the rest of the festure soubd pretty awesome even If I doubt I would use most of them.

Exactly one week ago I was musing over at the NintendoAge forum about the Ultimate NES/Famicom Flashcart, which pretty much boiled down to complaints about what is wrong with each of the existing carts.

I would hope it could support 2MB of PRG-ROM for FFVII or Action 52. (Neither are my cup of tea, but if you want some advertising features...) If you will be supporting all non-Color exclusive Game Boy games, including the hybrids, you will need to support 2MB and 4MB games.

How exactly would CopyNES lite work? Would you have to remove the flash cart and insert the cart you wanted to copy?

What about Pro Action Replay code support? I don't think anyone has ever attempted that.

Could the Game Boy core emulate the sound effects and the palettes of the Super Game Boy? I know that the borders are not possible due to the NES color limitations, but the rest should be possible, maybe.

I assume that this will be completely compatible with the HiDefNES mod and can think of no reason why it shouldn't be compatible with NESRGB. But with native video, the PowerPak adds noticeable jailbars and even the Everdrive is not immune from enhancing the jailbars a bit compared to licensed cartridges. Can your cart do at least as well as the Everdrive?

There is definitely interest.

How feasible is it to implement debugging features on a flash cart (or is that what you mean by CopyNES light?)?. For example -- bank watching, stepping debugger, read/write/exec breakpoints, instruction trace logging, RAM listings -- all on real hardware, using a gdb-like textual control interface over USB. I think these kinds of things are possible with CopyNES, but it would be amazing to get them from a cart instead.

I'd be very interested! Let me know however I can help

I'm interested.

Those are the colors that are perceptually farthest apart. The human visual system has a lot easier time telling small areas of teal from orange than telling green from purple.


That could take a while, possibly a few pages of this discussion before I get to it.


Not if he aligns the tile grid by feeding fine scroll values from the cart through $2005. He's already planning to feed audio through $4011 every hblank, and he said in #nesdev that he could feed fine scroll at the same time. Edges of sprites would be most affected.


Unpleasant is still better than "This game works only on Game Boy Color".

100% would buy. I was looking into the EDN8, but after seeing your (at least I think it was you) comments in another thread about how their mappers are all coded asynchronous and all the issues people are dealing with as a result, I would love to see a cart with the mappers implemented properly, and the GB support would just be that much more of a nice touch. Would you consider FDS support as well?

These are all nice features. The ones I'd be most interested in personally are 1MB PRG ROM (and 4k banking that doesn't half the PRG size), and I guess VRC7 support. Both of these are somewhat minor to me, though.


My main complaint with the PowerPak is a complete lack of ongoing official mapper support. The mappers haven't been updated since 2010. Loopy made some important unofficial additions, and TheFox more recently made some of his own, at least, but there's no real acknowledgement from RetroUSB.

The Everdrive at least has ongoing support, and it actually has forums and relatively good customer response. Its main drawback is that it its software isn't as far along as PowerPak is, and the hardware seems to be no better (and in some cases it may be inferior).

What I'd really like to see (for any/all of these) is open source mappers, and a support forum. To make a minor change to an existing mapper now, we have to write the whole mapper again from scratch. It would be great if users could review the mapper code, suggest/try and share changes, and have them officially adopted if viable.

Whether you, as the developer would be interested in open source mappers is your own decision of course. There are plenty of reasons to remain closed. I'm just saying that from my viewpoint it's a huge asset to the product.

some clarifications:

Mappers would not be user-updateable; I'd have to compile them into the main FPGA code. Be that as it may, I have support for pretty much every mapper under the sun, so I don't see this as a major problem. The other method I was thinking of to handle mappers was a very fast (200MHz or so) micro-CPU that could run code to emulate them. THAT would be user-updateable if I go that way.

Though, honestly, as was mentioned by rainwarror, hardly anyone makes their own mappers so I don't know if it's such a big deal to not allow user-updating of the mappers.


As for ROM size, I was going to use at least a 16Mbyte SDRAM or DDR2 part so storage space is not a problem. I will be supporting full 1Mbyte NSFs for example, and all those multicarts should run just fine, so long as they are under 16Mbyte total minus some small amount for WRAM and similar.

Debugging facilities will probably be limited mainly to dumping RAM and being able to modify RAM/ROM on the cart itself. Single stepping wouldn't be possible since I don't have control per se over the NES' CPU.

I can't put more than gameboy/gbc into the FPGA due to size limits. As others have said, I could possibly put other systems on there like SMS and similar, but the whole colour problem is the issue so I doubt I will do that. GB seems a good fit. Supervision would work as well but no one would want to play that. hehehe.

Tepples and I were talking about how to represent more than 4 level grey on the screen and I do like the orange/teal thing, the results are pretty nice but attribute clashing I think would kill the utility. think of a sprite moving across the screen, and the attribute only changing every 8 pixels. it'd look pretty bad unfortunately.

Orange and teal... attribute clash potential... why am I reminded of this album cover?

Makes sense. I guess you could sort of fake it since a cartridge can see and manipulate what goes on the CPU's/PPU's address and data buses, e.g., put the CPU into a temporary jmp loop to "pause" it; or, more extreme, interleave your own book-keeping instruction-sequences, which of course have to finish with all state the way they found it, in between "real" instructions... but I suppose this is bound to break some things.

I'd buy one. Full mapper support and expansion sound would be excellent. The Gameboy feature would also be pretty cool. The USB link for quick code uploads would be very handy for the homebrew programmer. I do think you'd have plenty of buyers that would be looking for something that can do more than their PowerPAK or EverDrive carts.

I don't think the user updating or making mapper files would be important as long as the mapper support is basically complete and without problems. For the PowerPAK it was great since it allowed for some growth but if it's all there from the beginning then it isn't really a problem.

I'd buy this in a heart beat, even though I already own an Everdrive and a PowerPak. Having the extra mappers, and the line out support would be fantastic

I'd definitely like this, as I'm making a homebrew game using mmc5 and plan to use the extra sound channels.

If you would consider making a 60-pin version of this flashcart I would buy this in a heartbeat despite already having an Everdrive. I especially like the full mapper, expansion sound and NSF support, the extra ROM memory and the debugging features. The other new features are delicious bonuses for me.

The current flashcarts aren't very satisfying when it comes to FDS support. It's not just that the expansion audio isn't supported, but the fact that you can't control disk side switching makes it pretty bad for anything but one sided games that doesn't use FDS audio. If you support FDS it might at least need a button on the cart for side switching. I think Loopy's FDSStick will fulfil all my FDS needs though.

Full mapper support includes all official mappers and lots of unlicensed ones? That would certainly make it appealing for people from Famiclone countries and those who collect mostly unlicensed games.

If you only need HuCards it's not hard to find a Core Grafx (but you are missing out on more than half of the PC Engine library without CD).

This is kind of a let down. One of the good things about the other flash carts is that everyone can put their own mapper files in there, making the carts not only useful for playing stolen commercial games or playing/testing homebrew, but also for prototyping new mappers, which some hardware enthusiasts like to do.


Not for players, but you'll definitely be taking something away from from people who are creating new stuff.


My knowledge of hardware is limited, so I'm not sure about the implications of that, but as long as you're not taking features away... I mean, you said that one of the points in making a new flash cart is addressing the shortcomings of the existing ones, and not supporting something they do would be the exact opposite of that.


I think it might be the chicken vs. egg thing going on here. I for example don't know much about FPGAs and advanced hardware stuff, but I know enough to understand how the discrete mappers work. I would like to learn more about how to create my own mappers, but the lack of resources (e.g. no sources available for studying and playing around with) kinda make that hard.


That's really cool. The 512KB limit of the other flash carts always bothered me. I know that the vast majority of flash cart owners just want to play commercial games, hacks and maybe a handful of homebrews, but these carts are supposed to be development tools also. We should be able to experiment with things that were never done before, like 8Mbyte games with FMV, sampled songs, and other ridiculously oversized content.

Also regarding ROM sizes, the ability to create mappers becomes important if we want to experiment with larger ROMs, because most existing mappers can't address that much memory.


Really? Oh well, I got really excited about GBC and SMS. I honestly don't see the color problem as such a big issue. Here are a few quick conversions I made in Photoshop:





All I did was keeping only the luminosity ("luminosity" blending mode over white layer), posterizing to 4 levels and finally converting to the 4-color grayscale NES palette. I only adjusted the brightness in the Shantae and Pokemon screenshots, which might mean that configurable brightness might be a good addition for some games, but in general, games look mostly like regular Game Boy games, and perfectly playable. I guess most 8-bit games use very high contrast graphics already, due to the small palettes.

I tried the teal/orange thing but the results weren't very good. I also tried detecting the 4 most common hues across the whole picture, but that's not really a great idea since the palette could change abruptly as different colored objects entered or left the screen. Anyway, things were particularly bad around sprites, for obvious reasons. If only sprites could be rendered with hardware NES sprites, things wouldn't be so bad. That could be done for the Master System and Game Gear, which have the exact same sprite count (total and per scanline) as the NES (sprites would have to be clipped beforehand though, because of the way background priority works on the SMS), bot not for the GBC, which can show 10 sprites per scanline.

Anyway, playing different consoles on the NES would be cool even if it was just for the wow factor. If you have the cores already implemented, and it wouldn't be a lot of work to include them, I don't see why not. Anyone who is bothered by the lack of color can simply choose not to use this feature, but by deliberately removing the feature you're taking something away from the people who are not bothered by playing in grayscale. When I was a kid, sometimes I had to play video games on tiny portable B/W CRT TVs with hacked in RF wires... Grayscale on a properly connected NES is definitely a step up, believe me. Plus, the sound will be perfect, which adds to the experience.

It's not exactly a rare console, but it's definitely more expensive and less available than Nintendo and Sega stuff. This means that accessories are pretty hard to come by, like controllers. Here in Brazil it's definitely much rarer than in the US or Japan, and having to import it makes it that much more expensive, due to shipping and import taxes. Usually, I only import loose consoles, to save on shipping and taxes, but when controllers, cables, etc. are not widely available that's not a good option. I do have a lot of interest in the PC-Engine, it looks like a really cool console, but for the reasons listed above I don't think I'll ever get one.

BTW, here's a teal and orange test using Sonic Chaos (background uses 8x1 attributes, sprites use 8x16):


I think I prefer playing in grayscale. BTW, Photoshop is the one that decided that the tree trunks were more gray than orange, probably because of the large chunks of sky on both sides.

Case in point: I created mapper 28 as a document and an exhaustive test ROM, then kevtris and thefox collaborated on an implementation for the PowerPak, and INL wrote a separate Verilog implementation for the INL-ROM.


Like Espozo's oversized run-and-gun bosses.


Ouch.

The only new mapper I've been involved with is mapper 31, but implementing it for PowerPak or Everdrive was a non-issue due to the lack of a controllable address line for 4k banking, or enough cart RAM to hold the ROMs.

However, I have very frequently wanted to revise existing PowerPak mappers (especially the NSF mapper) either for personal experimentation or just to improve emulation, but the barrier to entry for this is too high. It just never felt worthwhile, for many reasons:

• No source code for almost all mappers means that I'd have to re-implement them from scratch to be able to make any change at all to the mapper.
• The example PowerPak mapper source was a confusing jumble of project files and templates. So far I haven't found any clear information about how to build them into a PowerPak MAP file, what tools are needed, what this file format is, etc.
• Loopy released source for a few of his mappers (not the NSF mapper), but they were just verilog source files, again with no instruction on how to build them.
• The lack of community support for any of this. Even finding the example sources is a bit of an ordeal. They're buried pages deep into tenuously related threads here on this forum. These files aren't publicly linked at the author's webpage or anything like that. Everdrive is much better in this respect, offering a dedicated discussion forum and an example mapper source right on the website.

I'm sure if I applied myself I could figure out how to build a PowerPak mapper, and then tediously recreate the mappers I want to change from scratch, but it's just too much effort for too little gain. I would have done it a lot by now if it weren't such an ordeal to just get started with it.

The reason I haven't tinkered with Everdrive mappers is because it doesn't work in my NES due to incompatibility with my CopyNES. As such, I only really use it for very occasional compatibility testing.


What I'm saying is that if the authors had a different attitude/approach to letting other people develop mappers for the PowerPak, we'd probably see a lot more people doing interesting things with it.


I understand you probably want to protect yourself against knockoff products ganking your hard work, so I do have some compassion for the lack of open-source here, but for myself as a consumer, having a device I can easily reprogram is far superior (and a more attractive product) than one I can't.

Hi all, long time listener but first time caller.


As someone who uses a NES+Powerpak to play NSF backing tracks at live shows these features excite me. I'd imagine only a handful of people would be interested in niche features like per-channel audio outputs, but if you could incorporate channel volume / panning adjustment which impacts your proposed built-in audio jack, that'd be godly. I'm drooling at the thought of a setup where I could use the APU TRI/NOISE/DPCM pin in conjunction with the stereo, panned pulse output from your cart.

Ouch indeed. Well, there's always rgb121:


Although I have no idea how the flickering would work, since the original material runs at 60 frames per second. Even without the flicker it still looks way better than the teal+orange thing, just a little stripy and dark.


Maybe an option to switch between grayscale and this?

EDIT: Here are all the Master System screens again, this time converted to rgb121:

I would suggest strictly limiting the Game Boy core to the non-Color Game Boy games and using the logic savings for something else. The NES's color palette limitations would cripple many Game Boy Color games graphically and even the Super Game Boy features are somewhat beyond the NES's capabilities. The features should be close to Nintendo's Wide Boy or retroUSB's RetroVision, which allowed for some ability to adjust the colors of the monochrome palette and background for bunnyboy's device.

Also I would second a request for a Famicom version, my Famicom AV often felt neglected when I only had a PowerPak, but its native Nintendo composite video quality is the best there is.

When it comes to the Everdrive, the mappers have a ways to go, but Krikzz is focused on products for eight systems and whatever new systems he wants to support. It is hard to maintain focus on one console when you need it and the other seven to pay the bills.

As I understand it, FPGAs are reconfigurable, so you'll not be wasting resources with these extra cores. If you're not using them, they're not loaded, period. Those who are bothered by the color limitations can simply choose not use them, but I don't understand advocating against a feature that costs almost nothing to implement (the cores are already done) and there are other people interested in.

That looks a lot better, actually.

It's not perfect, but at least everything retains its basic colors. It should look much better when flickering at the proper speed on the actual console. I'm not sure how the flickering should be approached when the source material runs at 60Hz... Drop every other frame? Alternate green and red/blue even though the source frame is different? Get rid of the flickering altogether and don't alternate green and red/blue?

Here's an animation test (no flickering: even scanlines always red/blue, odd scanlines always green):


I wouldn't mind being able to choose between that or grayscale if it was possible to do something as cool as playing SMS or GBC on my NES. It's a little stripy (don't people love scanlines? ) and dark, but come on, something's gotta give.

Different source materials probably look good with different dither patterns: temporal or fixed, checkerboard or linear.

I have avoided dithering completely in the color reduction steps of these tests, because I think it ends up looking like details or textures that weren't supposed to be there.

For completeness' sake, here's the same animation in undithered grayscale:


Except for the tree tops, which blend with the sky, I think it looks quite acceptable.

I'll probably stop with the images now. I think I've already expressed too well how much I'd like to play GBC/SMS/GG on my NES, and how I'd love this new flash cart to include these features, and I also showed how I think the games could be rendered by the limited NES PPU. Now it's up to kevtris to decide whether to make this a reality.

Classic Game Boy is cool and all, but the Super Game Boy already takes care of that. GBC games on the other hand can only be properly played on the big screen if you own a Game Cube, which people who don't care about newer consoles don't. Master System and Game Gear would be awesome to have mainly because they're SEGA's, but the more games, the better.

I'm sure this will be a good flash cart no matter what, but here's hoping it will be as cool (for doing fun things) and versatile (as a development tool) as possible, so that it does indeed become the "ultimate NES flash cart", as opposed to just "yet another one".

When I said "dither" I meant the attribute zones, whether it's
or the same patterns without the temporal dithering

Since the SMS is just RGB222, there's only a tiny bit of finesse about how to best convert it to RGB121 anyway.


In a tangentially related note ... how much of a stretch would ColecoVision or any other 2nd/3rd generation console emulation be?

Wow lots of interest in how to get it to play other systems on the NES. haha. I really do like that rgb121 thing, it is the damnest thing, curious about how that'd look on a bigger screen. I might give it a try on the systems I have to see what it'd look like.

I did try benham colour once and it was... interesting. This is something I read about in a 1960's electronics magazine. The idea was to be able to transmit full colour video using just a black and white TV. It exploits the human vision system, but it flickers really bad. I did get it to work but the colours were fairly pale to me... but there.

The trick is a 6 frame cycle; the monochrome output is on for 1, 2, or 3 frames then there's 3 black frames from what I recall. If anyone's interested I can look it up. The NES could natively generate this type of thing for testing purposes.

Apparently some TV ads were made in this format and broadcast but it didn't last very long.

To clear up a few things...

There would only be a single FPGA on the cartridge, due to cost concerns, which makes it a lot harder to reconfigure it on the fly. I was expecting a single configuration. This is why I can't easily let people make their own mappers; the mappers are just a smallish portion of the FPGA code. There's going to be some kind of DRAM controller, SD controller, memory controllers, another CPU, audio hardware, video control hardware, and then the mappers.

When the FPGA is being reconfigured, the NES cannot access any memory on the cartridge (or hardware things like timers, etc) which means there has to be some kind of hardware on the cartridge besides the FPGA so the CPU doesn't crash during the loading. The powerpak uses some TTL logic on the cart to keep the NES happy while it boots, and the everdrive uses a CPLD.

I kind of wanted the SD card connected up to the FPGA so it could load RAM that way; it'd be so much faster and simpler if it didn't have to pass through the CPU; especially for 4Mbyte and bigger ROMs. If I have to pull configurations off the SD card it will need something to do that- either the NES CPU or another thing on the cartridge (read: costs money). The configuration file is around 800-900Kbytes, which if the NES CPU loaded would take a Long Time(tm). At least 5-10 seconds or more.

It'd be possible to build a microcontroller on the board to do some of the work but this would cost money. I wanted to keep the costs of the cartridge down to make it more affordable. Adding a micro would make it better but add to the cost. I have not totally given up on a micro but I have to check out how much it'd cost. It'd also slow the SD card stuff down a little but I think it might be acceptable speed wise. 2-3 seconds to load a typical MMC3 game like SMB, probably.

Didn't think microcontrollers costed that much but I guess you need an expensive one. I'd prefer to keep down the cost though since the price is already quite steep compared to the Everdrive, and especially if we are counting shipping from USA.

So any plans for a 60-pin version for us Famicom/Famiclone users?

I imagine that buying this with the Game Link connector option would be cheaper than buying an EverDrive GB, a Super Game Boy 2 (only the rare SGB 2 has Game Link), and an EverDrive N8.

I'd be interested in this, even with just Classic GB support.

The color reduction experiments are interesting, but I would be unlikely to use them for much.

Please do share the results!


Sounds kinda crazy... and not practical at all!


I see... that's not what I was expecting, considering how most flash carts work. Would it really be possible to fit everything you originally wanted, at the same time? Lots of mappers (including full MMC5) + GB(C) + FDS + NSF Player... sounds like a lot!

Anyway, please keep us updated on the design decisions, and how they could affect the final price.

Some of us are already set

I don't think I would play GB ROMs on an NES much, but it would be a good excuse to use up a little extra wasted space on these huge 1gig+ SD cards.

A new flash cart would be nice though, especially if it supported all of the mappers that EDN8 doesn't. Proper FDS expansion audio would be great too, though it has yet to be confirmed.

I'd definitely buy one! Especially if it were easy to update.

been sitting on the fence about which cart to get for a while now, but I'd wait for this.

If GameBoy is included it would be neat to support the MegaDuck clone as well since it does use a GBZ80 as well. I believe the only difference between MegaDuck and GameBoy games is memory mapping.

I would be very interested in it even if it is just for running Little Sound DJ on another device than the Super Game Boy. For that reason emulating plenty of SRAM is important too.

I am assuming the refresh rate of the Game Boy would be locked to the updating of the CHR data the NES is displaying so there isn't tearing / lag.

When I was programming the Game Boy Advance, the number 280896 cycles per frame was drilled into me, and the best guess for its crystal was 2^24 Hz = 16.7772 MHz. The Game Boy runs at one-fourth the clock speed (4.1943 MHz) but has one-fourth the cycles per frame: 70224. This means the frame rate is 4194304/70224 = 59.7275 Hz for both systems.

The NTSC NES and Super NES run slightly faster, based on a 945/44 = 21.4773 MHz master clock. (This is six times 315/88 = 3.57955 MHz, the NTSC color burst frequency.) The frame is 1364*262-2 = 357366 master clocks long for a 60.0988 Hz frame rate.

Super Game Boy clocks the Game Boy hardware at 1/5 of the Super NES master clock rate, or 189/44 = 4.29545 MHz, which is 2.42% faster than the standard Game Boy clock. The video circuit ends up producing 61.1679 frames per second, causing the SGB to skip frames. This is also why the original Super Game Boy lacks a a link port, as the speed difference from a standard Game Boy is enough to cause games to desync. The rare SGB 2, released to support Pocket Monsters, has its own crystal to produce a more accurate clock signal.

The only external clock signal on the Famicom cart edge is M2, which is master divided by 12. The NES additionally provides master, but 72 to 60 pin adapters don't. It's possible to use a PLL to multiply M2 by some factor to produce a clock signal for the FPGA. But then we run into a problem: do we want correct game speed, audio pitch, and link cable speed, or do we want to align NES vblank to Game Boy vblank without skipping or repeating frames? The speed factor differs for the two approaches.

EDIT: correction to Game Boy mono calculation

I believe you mean one-fourth the cycles per frame here.



The ideal approach for me would be as follows:
Using a PLL on M2 as you've mentioned, run the FPGA-GB at a speed that has the GB Vsync and the NES Vsync in lockstep - genlock them. The game might be *slightly* too fast or too slow, but people did not get upset with this in the Super Game Boy. Frameskips and tearing are very interruptive to the already limited graphical experience, and since the appeal here is looking at a Game Boy on the television, the graphical presentation is a high priority. We can do better than the SGB by having optional sound pitch correction, since this gives us control over the audio generation hardware. For those who are concerned with the link port speed matching other devices, an option to de-sync the systems might be an okay idea.

I would be interested. And will follow this thread

Unfortunately, the PLL ratio needed there is the fairly obnoxious 140448 ÷ 59561, or approximately 2.358

(Showing my work: 3 (pixels/M2 cycle) ÷ (178683÷2 pixels/source frame) × 70224 (pixels/target frame))

Hm, that's pretty bad. Perhaps a clock on the cart can target the solved speed, and can either correct itself to match, or just have to skip the occasional frame. I would prefer a consistent occasional frameskip over tearing, though.

It's also something that a PLL multiplier followed by a DDA clock divider can probably handle.

I would buy this cart. Would a game manuals viewer in the menu be possible?

A game manual viewer might not even be needed if enough people bribe me to make an e-book reader for NES, as then you'd just have e.g. "Dr. Mario.nes" and "Dr. Mario manual.nes".

What about a Playchoice-10 instructions viewer program? Wouldn't cover all the games, but it should be sufficient for the 52 that did find their way to a PCB.

re: how to get systems to run at the proper speed, I have the PLLs on the FPGA and my own oscillator. If I wish to frame-lock I can also do a more complex method with a phase accumulator to generate the system clock and dial in any clock speed desired.

I will not use the NES' clock to time anything.

Even though I have a N8, I would definitely get one of your carts. GB support and better compability would be awesome.

That's a feature I would want in a devcart.

I will buy one for sure.

What about the pirate mappers for the pokemon games and the ff7 demake? Will those be supported as well?

I'd definitely order one, and a Famicom version as well if you were to make one.

My PowerPak's CF card pins have started lifting, so using it has become a slight hassle. Would be super interested in a complete-support flash cart with possible monochrome CGB Wideboy mode.

I'll buy one for sure. Hopefully native support for NSF, NSF2, GBS, and NES2 are included.

Perhaps some logic hacks to allow NSF/NSF2 access to GB sound hardware; as well as GB to gain access to Famicom expansion audio "hardware" within GB/GBS mode as well?

Yes, I would definitely be interested! The gameboy feature is killer!!

That'd be incredible. The chipmusic community would go wild!

As long as we're talking about audio expansion, it would be really neat to throw in a Namco 163 option that uses straight channel mixing instead of TDM.

Throw a YM2612 in there too, let's get Genesis music playing on here!

What if we assume that both the flashcart and HDMI mod are being used at the same time, could the flash cart not communicate directly to the HDMI board by simply sending data directly to the "PPU" (in this case replaced by the HDMI board)? My understanding is that every PPU clock, the PPU will read a bit from four different shift registers, meaning we can send up to 4 bits per clock of information. Since the HDMI board is sitting in front of the PPU, it could read this data and use it in a manner that the PPU wouldn't support. Each NES scanline is 341 PPU clock cycles long, meaning we get 1,364 bits of information per NES scanline.

For the GBC, a scanline consists of 20 background tiles and 10 sprites. Each background tile has 8 x 2-bit pixels, and it can select from one of 8 different palettes. That's 8*2+4 = 20 bits per background tile, and 20 * 20 = 400 bits for background tiles.

Each sprite has 8 x 2-bit pixels, and it can select from 8 palettes, plus needs a 0-160 offset. That gives us 8*2+4+8 = 28 bits per sprite, and 28 * 10 = 280 bits.

That means that we're at a total of 680 bits per scanline for the actual image. In terms of palette information, the sprite palettes have only 3 colours to define (one is always transparent), and it's 15-bit palettes, so you need (8*4*15)+(8*3*15) = 480 + 360 = 840 bits to send the palettes.

That's 680 + 840, which is 1520 bits... That's more bits than we have on each scanline. However, my understanding is all games, with only a handful of exceptions, only update the palettes once per frame. A handful update it more than once per frame. So we can get away with only changing each palette every other scanline, because that will work correctly with like 99% of games, and the 1% that remain will still work nearly correctly, since they're unlikely to be changing both the background and sprite palettes every single scanline.

That means that even scanlines need 680+480 = 1,160 bits, and odd scanlines need 1,040 bits. Both of which are within our capabilities.

If you want to try to better support games that change their palettes, instead of alternating even/odd, just add one bit to specify which set of palettes are being updated in that scanline: background or sprites. That way, if a game changes the background palettes every scanline, but doesn't change the sprite palettes every scanline (or vice versa), you could actually be completely correct.


Alternately, if the HDMI board doesn't have the ability to store palettes, or draw a scanline that includes sprites like I described, you can just say, 1,364 bits, 160 pixels, you get 8 bits per pixel, like in a RGB233 config or something. That's not going to look as good as what a real GBC would do, but it'd be better than the RGB121 trick.


I may have completely misunderstood the degree to which the PPU can pull data from the cartridge, or the capabilities of the HDMI board, but it was fun to try to think of what could be done within my admittedly probably faulty understanding of the limitations.

I would definitely be a buyer of such a flash cart, especially if it stayed in that price range.

I'm currently a PowerPak owner. My main complaints are the menus and how game saves are handled.

The PowerPak menus are pretty drab. I don't like how there aren't any button prompts on screen. If I haven't used the cart in a while, I tend to forget what start, A and B do, so usually end up fumbling about until I remember. Once I browse to a folder full of games, it's hard to read. It's not that the font is bad, but I find it hard to see what game the cursor is next to in a long list of games. It would be nice to have file names highlighted with the cursor next to them. Also, the allowed length of file names can get annoying, especially when you have multiple versions of the same game. I usually tend to lean toward functionality over aesthetics, so I don't need flashy menus with theme support, etc. But the PowerPak menus are so poor that it becomes about functionality, in my opinion. I also really don't like that they can't auto sort - that would be a nice feature to have.

The way SRAM is handled is a major complaint of many. Although most people find it annoying, I can deal with having to manual add save files to the CF card. But what really annoys me is the way they're written back to the CF card (having to hold reset for 5 seconds then select the backup option). This creates the possibility of losing your save file before you had a chance to back it up (forgetting/human error, electricity going out, etc) aside from being an inconvenience.

It would be nice if Game Genie codes could be loaded from text files. Specifically, I like when individual codes can be loaded one at a time (from individual text files) instead of being forced to load all or none.

I think this encompasses many of the complaints regarding the PowerPak, which don't get me wrong is still a very fine piece of hardware.

Menu suggestions :

Start : Begin last game
A : Select
B : Back
Select : Menu

The current file should be highlighted like SD2SNES and have pages like N8 ED instead of scrolling. I would also prefer the ED method of sacrificing lines for a text box giving rows of characters for the file name.

The ED N8 automatically handles creating SRAM files and has a battery backup for the SRAM. If you turn off the game it will save. Obviously I would expect nothing less from a competing device.

Ditto regarding Game Genie from text files. PAR code support for RAM modification would be nice too, but I understand that is much more complicated.

The PowerPak had difficulty with MMC3, there was only one mapper (thefox's Save State Mapper 1.6) I could use that would give appropriate scanline split-screen behavior in every game. iNES 2.0 support would be nice.

Finally, the PowerPak added quite a bit of noise to the native video signal. I assume this is not a problem with the HiDef NES Mod or the NESRGB, but on a real NES the jailbars are rather unsightly. The ED N8 is better, but real Nintendo-made carts are best. I hope this could be improved.

Interesting, never realized this was an issue (don't own either myself), guessing it's due to the excessive loading on the stock power supply circuitry? Curious if anyone has tried beefing up NES's supply to resolve this or done other debug here.

I don't see any picture quality difference at all on my machines with a real NES cart, PowerPak, or Everdrive N8. The output is identical, as far as I can tell. (I have a front loading NES, and a famicom, and two different powerpaks.) I'm kind of surprised that you have this issue, I've never heard anyone mention it before. (I believe you, I'm just saying that I wouldn't expect this to be a common experience.)

I don't notice any picture quality differences between my real carts and the same games on my Everdrive either (I have an HVC-CPU-07). I haven't tried to compare them though and my power supply is a bit beefier than the stock adapter.

I agree with Great Hierophant about the menu control. I don't have a Powerpak but judging from the manual it doesn't look as good as the Everdrive (all buttons except the d-pad can be used to select? What about canceling?). And all that hassle with save files, you should definitively aim to make it more like the Everdrive.

The only problem with the Everdrive's menu is that controls are backwards by default (A is cancel), but that can be mended by setting an option for swapping A and B in the options menu.
However, I noticed to my horror that my newly acquired PC Engine Everdrive also has these backwards controls and it has no option to swap them! It doesn't make any sense to me why Krikzz keeps doing this nonsense.

I have a front loading NES with PowerPAK and see no difference in picture quality between using the PowerPAK and an original cartridge. Although I guess it is worth noting that there are a couple revisions of the PowerPAK aren't there?

Wonder if the regulator/caps on Great Hierophant's NES have deteriorated/aged to the point where the rails are abnormally noisy with the extra loading. Or perhaps some other reason his video signal is more sensitive to rail noise.

I made a followup post here so as to not to derail the OP's topic :

viewtopic.php?f=9&t=13219

I totally want one of these, but sadly I have a SIDE-loading NES system (equipped with a Blinking Light Win), and no TV capable of accepting HDMI signals.

It sounds fantastic, though!

Could this flashcart's expansion audio volume be made to sound the right level regardless of whether a 47k ohm resistor or 2 were done to the nes? I only added one, but 2 was said to be accurate.

I would very much be interested in such a flash cart, and I sincerely hope you can find the time and resources to make it happen. I started following your stuff a few months ago when hearing about the Hidef NES, and since then I've watched all the video updates and related postings by Game-tech. You have a highly detailed grasp of the NES architecture and it seems you're more capable than most others of releasing a device that would be compatible with a maximal number of mappers.

Anyways, I'm new to this whole nesdev site, but I just wanted to voice my support. Plus, all of the recent attention I've paid to NES modding has inspired me to spend more of my free time on electronics and hopefully be able to learn some Verilog and maybe build a buggy FPGA NES myself.

Is there any limitation(Everdrive has 512/512, so R4MI is out) on ROM size?

kevtris was talking about using 16Mbytes of DRAM, so that would be the limit.

In related news, I don't think it has been mentioned on the NESdev forum at all, but there has been a renewed (or first time?) appeal from the community for kevtris to produce his FPGA console in some form.
http://atariage.com/forums/topic/242970 ... me-system/

In my opinion, this would be far more interesting than a new Flash cart. It would have the same mapper support, a bigger FPGA (maybe more possibilities), very solid NES core, emulates many other systems besides NES, HDMI and analogue output.. I've been seeing him work on the thing in person over the years, and it's really awesome. It would cost more than a stripped-down NES Flashcart, but considering what else you get for it, I think it could be a really good deal. I think buying the Flashcart and HDMI kit together might cost about as much as buying the console. For people who like carts, he's working on an add-on system where you could add cart ports to the console, too. Not just to dump and run games like the Retron5, but actually running the cartridge directly.

I agree, specially if we get GB/GBC. Isn't bunnyboy close to releasing his own FPGA console, though?

He's releasing a NES.

Yeah, the AVS, I've barely followed news on it, but I was able to try it at the Midwest Gaming Classic convention earlier this year. It was out of the case, so I had a chance to get a look at the board, from what I recall it didn't look like it had a memory card connector or additional RAM you'd expect to be needed to emulate any cartridges, and I believe it only takes NES/Famicom controllers, so my assumption is that it's just made to take NES and Famicom carts. It seems to do it well, using a PowerPak I threw some 'tough' games at it like Micro Machines and I didn't notice anything inaccurate. The case designed for it looks pretty good. I'd say it's in competition with kevtris' HDMI mod kit more than his console.

I see... So bunnyboy is taking a more purist approach.

I agree, this would be certainly more interesting. Although I'm sure people will want to see more system cores like Sega Genesis, SNES, NeoGeo, etc.

Yeah, those are all systems that kevtris has mentioned on AtariAge as being goals, as well as C64 and other computers. Not easy ones if it's to be accurate, but if anyone can do it, I'm sure he can. And these systems pretty much set the specs for his latest hardware, the memory bus should be fast enough to support TG16/PCE, and wide enough to support NeoGeo. For a while already he's had SNES audio working, playing SPC files.

I think there would be a lot of interest in such a system being able to support all those platforms and not via software emulation. It certainly does seem like it would be quite a lot of work to get the 16-bit systems working accurately.

Interesting, but not more so than a new flashcart IMHO.

Really? If my understanding is correct, his console eliminates the need for a Flash cart, given that it also simulates mappers and probably loads games from files. I think that's more interesting than a 3rd Flash cart.

Well if it's accurate, it's certainly interesting for the future (who knows how long my old Famicom is gonna hold). But my Famicom is working fine at the moment.

As far as NES/Famicom goes, it's very likely to be accurate as we have so much technical information including chip die photos and study. I'm not sure about more complex systems like PC-Engine, SNES, NeoGeo.

I'd guess byuu's contributions for SNES helps a lot, but Neo Geo... It's expensive just to buy one.

How much accuracy do you loose with programmable logic anyway? I understand it's much faster than emulating hardware in software for a CPU.

In theory? None. In practice? It all depends on how closely the Verilog approximates the behavior of the original hardware. A Verilog NES clone converted from the Visual 2A03/2C02 netlists should be very, very accurate, except for a few signal timing quirks such as the 33 ns(?) /PRGSEL delay. Then it becomes a matter of finding time in the Visual 6502 volunteers' busy schedules to actually decap, delayer, and photograph the chips so they can be traced out.

Makes sense, thanks for the explanation!

Just a little question: How hard would be to implement an Atari 2600 on this cart?
Don't the NES and the 2600 use the same processor?

Each Atari 2600 pixel is 1.5 NES pixels wide. How would you handle that?

I don't really see a way to do that; the video format of the 2600 is so different from the NES's ... additionally the NES CPU both 1- runs at 150% the speed and 2- doesn't have the 2600's RDY pin

The difficulty would be stretching the horizontal resolution from 160 to 256 pixels in a way that doesn't look weird, and implementing all the mid-screen palette changes that the 2600 allows. The 2600 also has a bigger master palette than the NES, with 128 colors.


Both are versions of the 6502, so they share the same instruction set, but the NES CPU doesn't have decimal mode and the 2600 CPU is missing some address lines, so they aren't exactly the same. Even if they were exactly the same that wouldn't help at all, because you can't simply run unmodified code directly in the host system, since the memory map, registers, etc. are all different. The CPU would have to be fully simulated in the cart, just like the Z80 of the Master System would.

Any updates on this project?

The best way to stay updated on kevtris' projects might be to subscribe to his youtube channel:
https://www.youtube.com/user/kevtris

But no, no recent updates on this or his other FPGA projects.

It is quite possible that kevtris has lost interest in this project given the overwhelmingly positive response to his Zimba 3000 console on AtariAge.

Zimba 3000 was taking priority last time I talked to him but the NES cart is still an active project, even if it's been put to the back burner. I told Kevin I want to use the multicart on the Z-3k

Ya. I'm subscribed to his channel and enjoy watching and learning about his projects. I only subscribed after hearing about the HiDef NES, and it looked like updates for that were sporadic and not necessarily coinciding with the progress of the project.

Either way I'm excited to hear about the progress even if it takes a while. Thanks for the info/feedback.

I think I'm going to hold off on buying an Everdrive N8 if this is indeed getting made. Nothing recently on his YouTube channel about this, though, or any confirmation that it will be made at all.

Seriously i would buy this sight unseen. Just let me know where to send my money.

Any news this thread is quite old?