nesdev.com

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.

_________________
/* this is a comment */

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.

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog

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.