kevtris wrote:
Mappers would not be user-updateable; I'd have to compile them into the main FPGA code.
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.
Quote:
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.
Not for players, but you'll definitely be taking something away from from people who are creating new stuff.
Quote:
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.
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.
Quote:
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.
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.
Quote:
As for ROM size, I was going to use at least a 16Mbyte SDRAM or DDR2 part so storage space is not a problem.
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.
Quote:
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.
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:
Attachment:
File comment: Master System
sms-gray.png [ 42.14 KiB | Viewed 1615 times ]
Attachment:
File comment: Game Gear
gg-gray.png [ 38.81 KiB | Viewed 1615 times ]
Attachment:
File comment: Game Boy Color
gbc-gray.png [ 41.64 KiB | Viewed 1615 times ]
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.