The state of PowerPak mappers

Is anyone here up-to-date on the current "state" of PowerPak mappers? The Wiki page on the subject is pretty good about referencing all the forks and variances, but assisting with a project recently that uses MMC3/mapper 4 caused me to have to deal with variance in behaviours and left (again) a bitter taste in my mouth. I'm just sort of ranting and will get to the point eventually -- but I don't even know where to start...

It doesn't seem like any of the individuals who have worked on these mappers collaborate, so we have literally 3 forks of the base/stock mapper sets, with each fork having fixes/tweaks/whatever (they're rarely well-documented) and behave differently, in addition to more one-offs from other users/developers. Some, like PowerMappers, implement whole new features (save states); others, like loopy's, are just a nebulous .zip file with no versioning so you have no way of knowing if you have the "latest version" or not.

End-users have absolutely no idea which of those mapper sets should be used, how they should be used (I've been extracting the stock set, then extracting loopy's on top of that + overwriting, then extracting PowerMappers on top of that + overwriting, then adding in whatever other mappers are found/discussed/whatever).

Furthermore, some sets (ex. loopy) are basically complete re-release of the stock set with miscellaneous files changed. Has anyone looked into the stock set .zip file? There's all sorts of (IMO) crap in there -- .txt files (some of these look very important, and are in binary (!!), others look just like readmes, others are empty but probably important?), .pdf files, a .jpg showing a resistor mod but without any text or pin descriptions or even if the console was a top-loader or front-loader, an .smc ROM (yes, for the SNES!), and even a .nes ROM. You can't even tell what goes where, you're just told "put all this in your POWERPAK directory on the CF". There's no way for anyone to know how to clean this up without knowing all about it.

I know nothing of VHDL, and very little of FPGAs or CPLD devices, so I really can't help here. I'm looking at it purely from the perspective of an end-user with a flash cartridge used for development/testing.

Is there some way to consolidate all of these? Is that even the right process? Furthermore, where is the source code for PowerMappers v23, and most of the other one-off mappers? Why isn't this stuff consolidated and stored in, say, GitHub with release builds made for everything, with everyone working together -- even if all just working off the master branch? Does anyone maintain their own "merge" of all of these somewhere, with proper versioning of releases, so users know what they've got? If not, why has none of this stuff been handed back to Bunnyboy for review/consolidation?

Like I said: this is kind of a rant, but the above really is the state of all of this. The EverDrive N8 isn't much different in this regard either, from what our Wiki page says.

Why does it matter? Well, when it comes to testing software like I am, it absolutely matters. For example, I definitely need to know if quirks/issues I'm seeing when testing a NES game with a particular mapper are due to a specific mapper pack -- and whose (and what version/release of that pack) -- so that I can report it back to the NES game developer so they can include in their readme/docs something like "PowerPak users should avoid blah blah pack v4.66 else the game will crash, please use v4.67 instead" etc..

This has been the "standard" for a long time, and it's actually what Bunnyboy would tell you to do when asked:

1. Take the last official mapper set.
2. Put loopy's set on top of this, overwriting any files with the same name.

If you want savestate support, TheFox's mapper set is another overlay step:

3. Put TheFox's set on top of that. (Then do some extra setup for savestates, it's in the readme.)


All of the the other mappers are miscellaneous things that don't overlap with those three.


There's some difference between how TheFox implemented MMC3 and how Loopy did, but I don't know what the difference is. I think it's mainly to do with the scanline IRQ.


Loopy released source of some of his mappers, but not all. TheFox didn't want to release any source of his. Bunnyboy released a few example sources. This is all linked at the bottom of the wiki page.

The complaints you're making are things I (and I think others) have asked of these people multiple times in the past. Nothing was done about them. Eventually I started collecting mapper information on the Wiki page so I could have something to refer to.


There were other versions released of all 3 of the major sets, I think, but only the most recent versions can really be found anywhere at this point. The old versions were more or less universally worse than the last version of each of them. All three of them have been several years since the last change, so there's not really much instability there. TheFox's are 3 years old, the other two are much older.

Everdrive N8 is in a less fragmented state. Krikzz kept updating it for a while, stopped about 2 years ago I guess, but he may resume at any time. He provided example source and documentation which was IMO much better than what we had for PowerPak, and at least while he was updating it he would incorporate mappers contributed by others. (Also the Everdrive's USB upload interface is much better for testing mappers.)

So the scanline IRQ could behave differently based on the mapper version used... That is "the" important information I needed to confirm for my current project. Thanks for confirming that part, it could be the cause of my current issue

I may have to test is with my real devcart after all to make sure it's not the mapper IRQ implementation that could be causing the issue. What you just mentioned is now invaluable for my raster tests since it could put doubt that the test on the powerpak may be the cause after all.

Thanks again!

Thanks for the info.

Sad.

If you specifically want to know about MMC3, that's one of the ones Loopy did release source for:
http://forums.nesdev.com/viewtopic.php?p=173302#p173302

The PowerMappers do not have source, but there is a description in its readme about its method:
https://fo.aspekt.fi/

Presumably it refers to:
https://wiki.nesdev.com/w/index.php/RAMBO-1#IRQ_counter_operation

How close either of these is to the real MMC3 is an open question. I'm not much of an expert on the fine details of MMC3 interrupts, and it's been the subject of much confusion in general over the years. I think there may be different variants that are mostly compatible, except for a few games which depend on very specific timing. If you're doing development of a new game all I'd really recommend is test with many emulators and try to leave yourself as much margin for error as you can. I think in most cases it's very possible to write robust interrupt handlers that don't really care about these minute differences.

Thanks rainwarrior. Some context as to why this came up -- and apologies for the length:

I've been privately testing some stuff for Banshaku. The behaviour I see varies between each set (stock vs. loopy vs. PowerMappers). I did the testing myself and made videos for him (sorry, again they're private), including testing between NES vs. AVS. Sadly I don't have an actual MMC3B devcart (I do have an EPROM/EEPROM writer) so I can't test on an actual MMC3B cart, but I think InfiniteNesLives apparently tested it on hardware and found that there's a slight difference there too (it would really help if I could just test this all myself, haha). I'm being vague here when I keep saying "behaviour" and "difference" so I'll try to explain:

This particular code uses the MMC3 IRQ counter, triggered multiple times in a frame (more on that in a second). There is some nop timing involved to try and get certain things to happen at certain times. An important piece of the puzzle is that this isn't using the fire-the-IRQ-every-scanline technique by writing $00 to $C000. It's actually firing at a certain scanline/point, being acknowledged, doing some nop timing, followed by a CHR-ROM bank switch, followed by setting up the scanline counter to run again within the same frame several scanlines later, rinse lather repeat. To complicate matters, there are several different IRQ handler routines (i.e. the IRQ vector points to RAM, and the game changes it in real-time -- including some of the IRQ routines changing it themselves for the next subsequent firing). Sprites are not tweaked/involved during this operation.

I'll also add that some of these anomalies -- but not all -- actually show up in some emulators like Nestopia and NintendulatorDX 0.975, but not Nintendulator on Linux or OS X (I forget which), and not in emulators like Mesen. Everything varies massively!

The anomalies seen are graphical, and usually manifest as a partial scanline (maybe 16 pixels worth) showing an abnormal colour/line, often varying (horizontally) in size every frame. I might be able to make an animated GIF of this, or maybe a small cropped video of what they look like. Each powerpak set seems to vary slightly in where it happens, etc..

What's interesting is that "where" the anomalies happen (on some of the powerpak sets) correlate on-screen with events found using Mesen's Event Viewer. The "length" of the aberration, visually, also correlated with the number of PPU cycles (about 12, which is about 4 CPU cycles). My gut feeling was "this is PPU register tweaking causing the problem" (e.g. the whole $2000/2002/2005/2006 thing), but nope, it doesn't seem to be.

I was able to track down the responsible code to an sta $8000 -- that's 4 CPU cycles -- in one of the IRQ routines, which is just selecting a CHR-ROM bank via MMC3, specifically changing what part of PPU RAM addressing maps to what CHR-ROM bank. Like I said -- the visual anomaly doesn't happen in Mesen, so I can't use it to figure out if, say, it only happens when the value written to $8000 changes -- so it's difficult to determine exactly. Hardware ICE or maybe an oscilloscope would be able to figure stuff out exactly, but that's getting into serious hardware territory where we'd need someone like Ben Boldt hooking up tons of probes to address lines on the PPU to figure out what's happening when, hahaha :-) Way outside of my skill set.

All this made me wonder: is it possible that tweaking $8000 could cause some on-screen anomaly of this fashion -- a sequence of incorrectly coloured pixels on a single scanline, varying in horizontal length? MMC3#IRQ Specifics gets into some incredibly hairy stuff. I have a feeling the answer is "in how the hardware behaves", but I start to question whether or not this is truly an effect of the NES hardware or if the PowerPak -- or rather, the Verilog code in one or more powerpak sets -- are doing something "weird" behind the scenes that might cause this.

I kind of wonder if it'd be worth trying to put all of this into a single test ROM of sorts -- not a test in the sense of validating functionality, but something that mimicked what this game/code is doing (again: private stuff, can't talk about it or share code etc.) -- just so there was something out there that could be used to test and reproduce it.

Footnote: in addition to the above, some *other* anomalies were even weirder, like bizarre single-pixel blotches being shown in areas where nothing was going on (in Mesen, anyway), or part of the screen slightly bouncing/shaking/jiggling vertically -- where a subsequent power-cycle of the NES/PowerPak and re-run of the game showed no problems. The latter inconsistency makes me wonder if some variable/thing in one of these powerpak sets is not being initialised correctly, if I have a buggy/faulty PowerPak, or what. I suspect *these* anomalies are something entirely different and not related to the above.

I always appreciate the fact that Koitsu always goes the extra mile while doing testing when the only thing I asked first was "do you see some artifacts at the split point?" I'm very grateful for all the effort he went trough for it and maybe some interesting stuff may comes out of it too!

For now, even though it still an interesting problem, until I can test and stabilize the code on either an mmc3b cart, which I have but for now started to fail and I don't know why (the logo shows up then die, lucky me!) or on one of infinitesneslives cart, which I may be able to do soon. My first guess at the issue is the timing when events occurs are not hush/hush, causing some of the artifacts but emulators just shows it without issue.

Until I stabilize the code and confirm on real mmc3b/infinitesneslives carts, we may be trying to find a solution for something that can actually be fixed by code and only me can figure it out once I have a proper environment to do so.

Thanks for the testing, really appreciate it. I can't wait to talk about it but for now, until it's completed, I have to keep it a secret. It's nerve racking

It's been ages since I've gone over the powerpak MMC3 code, but I'll dig it up if there's something that needs fixing. I have MMC3A,B,C carts I can test on if needed.

That's nice of you, I really appreciate it.

For now, before I get more people involved in this project, I really, really need to test it on real hardware on my side to make sure it's not just my code first. If it's only my code then I would feel bad to have many people working on a non issue ^^;;;

Once enough tests is done on my side, I will let you know if testing on specific cart is required. For now infiniteneslives carts shows artifcats but they are not as strong as what koitsu saw on the powerpak. I will try to rewrite my flash eeproms again if I can this week to see if it was just a failed write on my eeprom or my devcart started to just fail.

I find it strange that CHR bankswitching is causing so much trouble, since this is one of those operations that do not interfere with the PPU itself, so the worst that can happen if the switch is not stable enough is a little jitter with the wrong patterns near the switch point.

If the problem is indeed with timing CHR bankswitches, there's a simple trick you can do with the MMC3 that will buy you a lot of wiggle room for the bankswitch operations: instead of dividing the background in regions of 256 unique tiles, divide it in regions of 128 unique tiles, so that you're only ever using tiles $00-$7F OR $80-$FF, so you have the entire time during which one set is being displayed (at least 32 scanlines, which is what you can cover if each of the 128 tiles is used only once) to switch the other set, which is guaranteed not to be in use.

If you do this, then you don't have to worry about hblank or any of that precise timing bullshit, as you have a freaking huge window of at least 32 scanlines where it's safe to do the switch for the next 128-tile area. Of course, this is assuming your problems are limited to CHR bankswitching. If the MMC3 IRQ timings are causing problems elsewhere, you should definitely look into it.

The only time there was issue with bank switching midframe was when the timing in hblank was too early or too late, causing artifacts (line of a different color in the picture) since the following lines were not black. When splitting where the text is shown and switch to the bank for fonts, you have more leeway about it.

So for now, I do not think I will have to reduce the tiles to that level since I think it may just all be issue with timed code that may not be executed properly in hblank and the powerpak may be showing it more based on which mapper pak is used. I think some mapper pak may be triggering the IRQ event not exactly at the same position on the raster compared to the mmc3 or some emulator (but I'm just speculating right now).

The real test on hardware should help confirms if the powerpak does trigger the irq at a different position than the mmc3 or emulator.

Thanks for the comments!

I'm just saying you wouldn't need to worry about timing bankswitches to hblank at all if you switched more frequently (every 128 tiles instead of every 256), without having to sacrifice anything. With 2 independent 128-tile slots, you have 32 scanlines or more where the slot that's not being displayed can be changed with zero graphical glitches.

If this is not during gameplay, you could even do this using very roughly timed code (i.e. no IRQs), since the windows for doing the switches are so huge.

I will need someday to learn how to do "normal" timed code since for now, the only way I know how to do it is with the mmc3. I don't know why but for some reason, I always "kind of" figure out to some degree how to use the more complex stuff but stumble on the basics since, well, I never used them ^^;;;

Since I'm not sure what you mean by "the window to do the switches are so huge",. then it means I should learn more about it

Banshaku showed me a video and it triggered some old memories that might be relevant...

I owned two PowerPak devices over the years. The first one I damaged (and later gave away), but I think the second one behaved differently for MMC3, despite using the same mappers. I also seem to recall that thefox's PowerMappers MMC3 made it better.

The different behaviour I recall was that sometimes SMB3 or Crystalis or other MMC3 games would jitter the raster split up and down by 1 line frequently.

I also vaguely seem to recall people discussing noise on PPU A12, and maybe adding a small filtering capacitor or something to the PowerPak to help the issue? (In fact this might even have been how/why I damaged my first PowerPak.)

Thefox's PowerMappers says it does the "RAMBO-1" thing, which means it waits for 2 M2 falls before applying the IRQ. This should have the effect of filtering a noisy A12 transition, right? (Eliminate an accidental double hit?)

Like maybe the issue is more of an analog one, specific to how sensitive the FPGA in the PowerPak is to a little bit of noise/bounce on that line? (Something emulators wouldn't be affected by at all.)


Anyhow, that's just an idea. I'm not sure if my memory is correct, it's been years since I had that other PowerPak, but I really do seem to remember jitter that I can't duplicate with my current PowerPak. (Edit: after more testing, I'm noticing the jitter is still there. It's an intermittent issue with Loopy's mapper 4. I think I started using the PowerMappers around the same time I got my second PowerPak, so I was probably just misremembering this as the new PowerPak fixing it, instead of correctly remembering that thefox's mappers were the fix.)


On another note, an interesting ROM for case study might be this old Hiatus Ward demo from 2012. It seems to have timing/jitter problems on more or less any emulator but on PowerPak it's a lot worse. (Though to be fair there are probably other issues than IRQ in that ROM, and trying to isolate the effect from the others would be a challenge.)

oh, I remember reading something about that a long, long time ago. Which mean, the power pak could be acting a little bit too. Hmmm...

Well, it's good to know. I will keep that in mind once my test on read hardware are doable and confirms any possible timing issues.

You know what, this seems to vary by time of day. Maybe my electrical environment is different right now than when I was testing earlier, but right now SMB3's status bar is jittering up and down on my PowerPak with Loopy's MMC3, and it wasn't earlier today. Crystalis is even worse, since it's doing 2 splits in most frames.

So... I'm gonna take back what I said earlier about suspecting a PowerPak revision. I think it's the same as the other one I had, but the reliability of A12 probably changes from day to day depending on what the electrical situation is in my house at the moment.

Replaced Loopy's MAP04.MAP with thefox's PowerMapper one and these are rock solid (including Banshaku's test).

Regarding the "jitter/jiggle" or "bouncing scanline": I can reproduce this but only on very, very rare occasion -- it happened with Loopy's set, and thus I suspect the stock set would have the same problem. It's possible that thefox's PowerMappers fixed it, but I don't know for sure, because a simple power-cycle makes it go away. (Back to my "why is there variance?" question) I can give you links to these videos (and details about them) in a PM if Banshaku approves.

Regarding PowerPak hardware issues and a filtering capacitor: first I've heard of this. Is this something different, or perchance are you remembering this PowerPak hardware bug that required eight (8) 100ohm resistors placed between certain edge connector pins and their sips, combined with cutting traces? I opened my PowerPak and took a look -- it's a Revision E, dated 7/18/07 In fact, the photos of the edge connector and their traces look completely different than what my PowerPak has, so I suspect I have a revision where this was addressed/fixed in another way. There is, however, on the component-facing side, 8 pins which have individual resistors right after the edge connector. I can't tell from the photos if the fix was to the front or back side of the board. Looking at a cart pinout counting from the board edge + reviewing the behaviour described, I suspect they're for CPU D0-D7 (pins 42-49).

Edit: no, it seems you really are talking about PPU A12 and the PowerPak, as per this conversation in the past. That thread's from 2014, so odds are my PowerPak does not have a fix for this (if there ever was one). The thread is not very clear about how to resolve this kind of problem; I suspect most everyone just accepts it. Now you're playing with PowerPak!

Well, I think the current state of things is just that Loopy's 2011 mapper 4 has unreliable jitter problems that will vary in severity depending on your electrical environment. Maybe wherever Loopy tests he has a cleaner system than most.

thefox's RAMBO-1 approach presumably solves it by delaying the response for 2 cycles, filtering out any spurious rising edges that take less than that amount of time.

So, if this is a correct assessment, I'd say for the moment, use the PowerMappers MAP04.MAP. A 2 cycles delay is probably not a dealbreaker for almost all old games, and should be close enough for testing purposes? Probably as good as most emulators too.


I personally don't like the PowerMappers' savestate thing, and I like the game genie thing that Loopy's mappers support, so what I've done is only take the MAP04.MAP, and the POWERCFG.MAP and Z.MAP that go with it. I didn't replace O.MAP because it seems to affect the loader for other mappers in that set, but without it MMC3 games still load and save correctly, as far as I can tell.

If Loopy is willing to fix his old mapper, I'd love a replacement. That thread you dug up seems to raise some questions about the spurious rising edge, like is it a bounce during a legitimate transition, or a random spike? If it's a bounce situation it could presumably just block responses for one or two ticks of M2, rather than delaying the entire response. If it's a spike, then maybe what thefox did is already the best we're going to get from a software solution.

So what I can get from the current discussion is after I make my timing more precise, as long the glitches are not breaking the game then it should be more than enough. That's fine with me too. I think the text jumping occurs when the timed code is just at the border when you are going to enter hblank and causes such issue. I remember seeing such phenomenon on nintendulator while adjusting timing.

We can see it that way: it gives the "authentic feel" of the nes era One person that I know that is not a dev said "isn't that how all nes games look like?" after testing on a power pak so I think I'm on to something

Edit:

the good thing is, during the game, I won't need such code, except for one exception where I need to skip some scanline between maps transition so this issue should only occurs during the intro, mostly.

Well for the purposes of a scanline split I spent some time just now looking at my cartridge of SMB3 vs. thefox's mapper vs. everdrive:

During play, on the real thing I can see 1 to 3 corrupted tiles at the top of the status bar.

On thefox's PowerMapper I see 2 to 4 corrupted tiles.

On the Everdrive I see 2 to 4 corrupted tiles.

(This may adjust slightly on resets from PPU alignment I think, but this is the average behaviour I'm seeing.)

So really I think that's all we're looking at here, a very slight delay that's mostly inconsequential.


And in the case of Loopy's mapper 4, I think it's just currently unreliable, and not something you can work around, and not something you should try to work around either. Just use the PowerMappers (or at least just their mapper 4 if you otherwise prefer Loopy's set like I do).

Without adding much to the scanline conversation, I think the problem with both the Powerpak and the Everdrive is that while making a NES flash cart which runs ~90% of games can be a profitable business, the "mapper" landscape means that increasing that percentage hits diminishing returns very quickly.

The Powerpak is pretty much abandonware by now. Though it's nice that it's still possible to buy the hardware from retrousb. It's still an awesome product for what it does.

The Everdrive has seen more updates, but I think it is hitting the same issue. You also need to keep in mind that Krikzz has a ton of other flash cart products for way less quirky video game systems, all of which require a fraction of the development effort the NES needs to make more games work. Honestly, I'm impressed we're seeing any updates at all, giving how comparatively little it would boost sales at this point.

As for why third-party mapper makers haven't released (some of) their sources, I can't say for sure but it wouldn't surprise me if part of it was due to not getting much in return for pouring hours into a made-for-profit product without benefiting much from it themselves. Perhaps they even made the flash cart vendors offers that were refused? Though I'm obviously just speculating here.

I'm not a die-hard proponent of open-source solutions, as a lot of proprietary products often result in better quality to consumers IMO. But I do think open-source is the only way to eventually increase compatibility of NES flash carts when there isn't much of a business case for doing so. Open-source solutions may be slow to gain traction, but to get those remaining 10% of NES games working, I think the only long-term solution is for a lot of people who are NOT doing Verilog for a living to chip in with yet-another-simple-implementation from time to time. That model has worked with many emulators, and Verilog is not that different a beast.

Perhaps the MIST could serve as the project to contribute to, given it's ambitions of emulating a myriad of consoles? Unfortunately the current source code structure appears to have a lot of technical debt, with all of Loopy's Powerpak mappers just pasted into one big mapLoopy.v file. But with some re-structuring, it could possibly serve as a testbed for mapper implementations, and a starting point for new mappers for the Powerpak / Everdrive as well. If the signals are well-defined, then getting the MIST Verilog to work with the Powerpak and Everdrive should just be a question of making adapter modules after all.

And speaking of open-source projects, it sure would be nice to see an open-source FPGA flash cart schematic, sort of like the OSSC is in the upscaling domain. Both the Powerpak and the Everdrive have been around for many years now, and they aren't magic products at the end of the day. As mentioned above, most of the engineering effort ends up being the software support and not the hardware. But trouble with that idea is that the initial bring-up and prototyping is still a very sizeable and costly piece of work to pursue for altruistic reasons alone.

But hey, if anyone with some basic EE engineering skills is out of a job, then I'd be first in line to be a high-tier backer for a credible crowdfunded FOSS flash cart solution for the NES...

I used to think so when I got my Everdrive, but eventually went back to the Powerpak for mapper work. When you start experimenting heavily with intercepting PPU fetches for MMC5-like functionality, a logic analyzer becomes a vital debugging tool. And having those expansion pins on the Powerpak to your probe is such a blessing. It's such a shame the Everdrive's design didn't connect the EXP pins to an FPGA pins to give you some accessible debug signals. But the USB interface does blow the Powerpak out of the water for regular nesdev.

I also think the Powerpak is the more capable product as it gives you control over A0-A2 and can support the MMC5's vertical split screen. Probably doesn't matter to most people as the MMC5 vertical split screen feature went unused. But again, for making your own experimental mappers with vertical scrolling, it's a really cool feature to have and see in action. Though I suppose the Everdrive's bigger RAM units could achieve the same thing, if you can fit all your nametable and CHR space there.

But both products are well worth buying, depending on your use-case.

Oh, personally I like the PowerPak a lot better.

However, from the standpoint of making a mapper, I felt that everything Krikzz provided was a much better starting point for doing this than it is with PowerPak, IMO. It was organized and clear. For PowerPak, I had to do a lot of digging, and even the Xilinx tools were a serious pain to acquire and set up. (The Xilinx tools aren't bunnyboy's fault, but the Altera tools were a lot easier to get for me.)

Though for a long time I didn't know about nespowepak.com, which has a lot of useful info... I'm not sure if that's bunnyboy's site or what. It was just like a secret link somebody told me about one day. It's not linked from the RetroUSB website.

For actual use, though, I pretty much only use PowerPak, and I more or less just have the Everdrive N8 for compatibility testing. Everdrive seems to be more popular these days, I think because it's a little cheaper, but I would much rather use the PowerPak. My reasons might not be applicable to most people:

The main problem is just that Everdrive N8 can't work with CopyNES, so I can only use it with my Famicom through an adapter. Not an issue for most people, but I was blindsided by this fact. (Its website doesn't even mention it.)

It's missing an NSF player feature, which is important if you're into NES music. (Incidentally, Everdrive has the address line to do proper 4k banking and PowerPak does not, so it could actually handle 512k NSFs if it had a player. PowerPak has a doubled-256k workaround.)

Finally, my Everdrive N8 is unreliable. I haven't heard of other people having this problem, but generally it will hang/crash/reset around once every 10 minutes. (I don't want to sound like Krikzz has refused to provide support for this, though, as I haven't asked for any. Might be some latent problem with my Famicom or adapter that only manifests with Everdrive, and I rarely want to use it, so it just hasn't been worth my time to figure that out. )

Edit: had Altera and Xilinx transposed.

Although I like the idea of flash cart since the beginning, because I had a famicom and only the power pak (2008~10?) was available and I had no easy way to buy one, I just gave up. I'm aware of adaptors but I just never was fond of those.

Now that the everdrive is available in famicom format my interest is back but since I don't play much games these days and is doing more dev and like mentioned above, the compatibility is fine in general, I don't think I should be in rush to get one either. Maybe someday.

If it was me I would buy one flash cart for all devices I have and do some dev here and there but that would be quite an investment. It's expensive to be a nerd it seems

I might be misunderstanding something here but wouldn't it be less convoluted to just use the released mapper source than to grab it out of MIST? Or does that include stuff like their MMC5 that I don't have source for? All of my own PowerPak mappers have been based on Loopy's, usually modifying MMC3 into whatever I need it to be.



I think you might be mixing up Altera and Xilinx. PowerPak uses an Xilinx XC2S30 FPGA, which required me to somehow acquire Xilinx ISE 10.1 and that was a huge hassle because they didn't seem to be providing free licenses for such an old version anymore.

All that said I'd definitely be willing to help someone get set up with mapper development since I actually bothered to go through all the hurdles of figuring it out.

Indeed it's way easier, and maybe my rambling earlier didn't help explain my point.

Which was just to say that it'd be great if there was a centralised open-source project that's being actively developed and maintained, and the MIST attempting an implementation of NES mappers looked like a possible fit. But "actively developed" is also only half-true here anyway, seeing there's only occasional commits to the NES implementation with many being months old. And there's again the issue with the project having a bit too broad a scope, where the NES backend might not get the attention it needs. So not sure the MIST is going to help much in practice.



I personally found that no matter what FPGA solution you go for, all of it is the most terrible bloatware you can get on your computer. There's been loads of times the Xilinx have corrupted the project directory, requiring me to re-create the project from scratch. And years back at uni when I did my SNES-like videogame console in VHDL, I have "fun" memories of seeing the compiler crash after way too many hours of synthesizing.

I also had the unpleasant experience of fighting to get an older version version of Xilinx Webpack. But honestly, Altera wasn't much better here: I wasted way too many hours trying to create an account on Intel's website (without which you get no download), eventually having to email their support to figure out I had to delete cookies off my web browser to get past their buggy web forms.

I think high-end commercial FPGA tools are somewhat better. But they are really a different ball park altogether, when they're made for FPGA chips that can cost $50,000 per chip / prototype board.

Anyway, gardware development is still a fun hobby, and it's a lot more accessible than most programmers realise before they try it. But it's a shame that the software tools should always be such a frustrating struggle.

If you want an actively developed FPGA version, you probably want the MiSTer version:
https://github.com/MiSTer-devel/NES_MiSTer

Although, admittedly, "actively developed" mostly means me. Most of the changes in MiST from the past year are just copies of changes I've made to MiSTer (which is originally ported from the MiST version), as I've added probably 50+ mappers in the past several months. I've slowed down a bit recently, as I have most of the mappers I care about now (though I'll probably fix Startropics I/II this weekend).

I would imagine most of the mappers are already in the existing PowerPak mappers. There might be some changes that can be useful for PowerPak mappers (Sim City prototype works, for example), and the interface is similar enough that I could largely paste Loopy's source code in with minimal changes (This was done in one file intentionally, because I didn't want to pass off his code as mine; it was an attempt to maintain code attribution. Hence, the name of the file including Loopy. I grabbed his code from here: http://forums.nesdev.com/viewtopic.php?p=173302#p173302. Looking at this again, Loopy says he's ok with the source being available, but doesn't explicitly give permission for reuse in other projects (no license). If Loopy reads this and would prefer I remove the code, please contact me. Maybe I should just rewrite those mappers...).

Most of the other mappers I've added/fixed aren't very complicated, though. It might be easier to just write them from scratch for PowerPak. If you find anything useful in what I've written, though, feel free to use it.

I suspect that all that is really needed is for someone to start a GitHub project to hold PowerPak mapper code. I actually own a PowerPak as well, but haven't been motivated to figure out how to build mappers for it.

The EverDrive does support the MMC5 vertical split-screen functionality. That feature was used in the opening sequence of Uchuu Keibitai SDF and the ending sequence of Bandit Kings of Ancient China. I've only seen it work for the former.

Ah, so the Everdrive does implement the split screen. That's kind of cool.

However, it cannot to the best of my knowledge support "SL mode" where you have fine scrolling, as A0-A2 isn't connected to the CHR chip. Not that it matters to anyone wanting to play MMC5 games, since zero games are known to use this feature (AFAIK, Bandit Kings uses CL mode as well).
But it does mean that the Powerpak can use an MMC5 feature the Everdrive can't, which was the only point I was trying to make.

OTOH, if you're making a mapper of your own rather than using MMC5, then there's nothing stopping you from using some internal FPGA RAM for CHR instead, which the bigger FPGA in the Everdrive has more of. The bigger internal memory can also have a lot of other potential uses of course, which can be seen as more important.

Again, I am happy to own both of these products. They each have their pros and cons.

Thanks for letting me know! I wasn't quite sure of the differences between MiST/MiSTer

Hmm, you say that the reason for all Loopy-mappers being pasted into one big file is to make attribution simpler. But I really don't get that argument. The Powerpak is really only designed to have one mapper at a time loaded, due to the limitations of the FPGA. So by pasting them into one file, that's made them more awkward to use in their original intended setting - almost like a lossy conversion

Furthermore, the mmu.v seems to have a great collection of mappers you've written from scratch. But this one is also inconveniently in one big file of 4000+ lines. Again, why have such huge files rather than a subdirectory and a file for each mapper? It does make contribution and re-use of the code quite a bit more difficult.

I see you've got a Mapper30 implementation in there, but no flash saving. I added a simplified flash saving to the Everdrive yesterday evening, which was a lot more trivial than I thought. I'd be happy to help out with modding the MiSTer mapper30 to do the same. Or whatever little bit I could do, as I really dig the idea of a centralised open-source library of mappers. And I'd be keen to see if the mappers can run on the Powerpak/Everdrive too.

And yeah, it'd be great if Loopy could chip in about what he thinks of re-using the code and whether he'd be okay with either a copyleft or a permissive license, just for the record.

Now that we've managed to reproduce the ending credits for BKoAC in emulators ... it does look better in SL mode, and might have even been designed for it.

(The stars are background, the lettering is the split, the mountain itself is sprites, and the stars shimmer in an odd way due to CL mode. If emulated in SL mode, the stars stay fixed)

You're free to use the code however you like, consider it public domain.