PowerPak mapper 30 implementation

[rainwarrior]

Yes, Bananmos' mapper is backwards from the standard that was eventually assumed. This is what to use:
http://wiki.nesdev.com/w/index.php/UNRO ... figuration

Code: Select all

* %....0..0 - Vertical arrangement
* %....0..1 - Horizontal arrangement
* %....1..0 - 1-Screen, switchable
* %....1..1 - 4-Screen, cartridge VRAM

This wasn't clearly or "officially" stated anywhere until recently, since there weren't any public ROMs that needed either until Black Box and Twin Dragons released.

This standard was provisionally implemented in FCEUX a while ago, which propagated to FCEUmm (and from there to Retroarch, OpenEMU, etc.). I'm not sure if Mesen supports using these bits, IIRC there was some different logic for it that was not compatible.

Otherwise I don't really know any other emulators that support it yet. When Bananmos wrote that mapper it was still a TBD on the Wiki.

[Broke Studio]

Thanks a lot guys for helping people getting Twin Dragons to work on their PowerPak, I really appreciate it!

I now need to update the ROM "package" with instructions for the PowerPak.

[Bananmos]

Hi, sorry for missing out on this conversation. Been quite busy since starting a new contract.

I've updated my Powerpak and Everdrive implementations with a trivial change to flip the H/V bits.
New Powerpak version
New Everdrive version

Unfortunately my NES and flash carts are packed down at the moment and I'm still a bit short on time and haven't been able to actaully test these builds on a cart yet. So if anyone could volunteer with testing these implementations with the various combinations (H, V, 1-screen and 4-screen) it would be greatly appreciated.
And obviously don't advertise these links too widely before we know they even work at all...

[rainwarrior]

Neither seems to be ready for release:

1. PowerPak version just goes to a black screen.
2. Everdrive version works perfectly for all 3 test cases I have, but you replaced mapper 2 (UNROM).

With the everdrive, you seem to have redirected mapper 2 to 1E (30), and then placed your new mapper as 002.RBF. 030.RBF does not exist, but also 002.RBF was already in use for mapper 2. (This is based on the latest OS version 16.) So... it breaks Mega Man. ;>

No idea what's up with the PowerPak version..

The three test cases I have are:

• Black Box Challenge (4 screen)
• Twin Dragons final version dump (1 screen)
• Larry and the Long Look... dump (relies on horizontal arrangement)
• Tower of Turmoil (NES maker game, no scrolling)

I don't know of any vertical scrolling mapper 30 games, so I don't have anything at hand to test it. NESMaker doesn't have scrolling yet either, right?

[Bananmos]

Code: Select all

With the everdrive, you seem to have redirected mapper 2 to 1E (30), and then placed your new mapper as 002.RBF. 030.RBF does not exist, but also 002.RBF was already in use for mapper 2. (This is based on the latest OS version 16.) So... it breaks Mega Man. ;>

Gosh, I obviously managed to upload a really hacky version here. It was actually supposed to redirect both mapper2 and mapper30 to the changed 002.RBF, as the .RBF also contained the original mapper2 implementation. (and mapper11 and NROM too, incidentally)

In hindsight, I guess a proper "patch" should be less intrusive, so I've indeed renamed the 002.RBF to 030.RBF and updated MAPROUT.BIN accordingly, to leave the original mapper2 untouched on the SD card.

Everdrive version

For the Powerpak version, it appears I somehow managed to get my COPY /B command backwards (or that's what I assumed happened as a power outage removed my command-line), ending up with the 1kB header being at the end instead.

Not sure how I managed two big bloopers in one evening. But should be all fixed now as well.

Powerpak version

[Bananmos]

I don't know of any vertical scrolling mapper 30 games, so I don't have anything at hand to test it. NESMaker doesn't have scrolling yet either, right?

NESMaker actually has some limited scrolling now, though I have yet to try this version out myself. Haven't had enough time for my own NESdev project lately, let alone learning somebody else's tools just for the prospect of future game jams... but one of these weekends

[krzysiobal]

Can someone explain if the ROMS produced by NESMAKER utilize the direct writes to Flash (self-programing as additional RAM)?
Because allowing mapper writing to PRG is not great idea (if some flash cart stores firmware & rom code in the same chip, then game making `chip erase` command might brick the cartridge)
And if we totally forbid writing to PRG and game will try data-poling for testing if write suceded, then it might end in infinite loop.

[Bananmos]

Can someone explain if the ROMS produced by NESMAKER utilize the direct writes to Flash (self-programing as additional RAM)?

AFAIK, this has not been implemented yet and there is no ETA for this either. When it comes, it will be an interesting challenge to emulate with the FPGA - especially given you cannot control all address pins.

Because allowing mapper writing to PRG is not great idea (if some flash cart stores firmware & rom code in the same chip, then game making `chip erase` command might brick the cartridge)
And if we totally forbid writing to PRG and game will try data-poling for testing if write suceded, then it might end in infinite loop.

This should not be a problem for the Powerpak nor the Everdrive. They both have a 512kB reserved for the PRG-ROM alone AFAIK. Trying to fit a boot room in a bigger circuit sounds like a very careless cost-cutting experiment to me. Better to just have a separate chip for the 6502 boot ROM - or use an MCU-only solution that can fake a minimal boot loop at reset until PRG has been initialised.

[rainwarrior]

The new uploads look good to me. Both of them pass the same tests I mentioned earlier, and mapper 2 is now unaffected on Everdrive.

One thing this makes me realize is that I think NESMaker games have the battery backed bit set in the header by default. I notice because the PowerPak offers to save it after long-reset. (Not really a problem... but it's probably just saving garbage from $6000. I think the real fix for this is really NESMaker shouldn't set that bit unless games actually use a save.)

I'd suggest submitting the RBF to Krikzz, by the way. Whenever he does another Everdrive OS update I'm sure he'd want to include it.

[NovaSquirrel]

When it comes, it will be an interesting challenge to emulate with the FPGA - especially given you cannot control all address pins.

I've thought about this before, and the nuclear option if nothing else works is that you do have complete control over the data pins when doing reads in cartridge-controlled addresses, and perhaps you can force the next few reads out of PRG ROM after a flash operation to come out as "JSR $5000" where some mapper-included BIOS code can take care of it (with the 6502-provided full access to the address pins) and correct the return address to be the replaced instruction.

[Bananmos]

I'd suggest submitting the RBF to Krikzz, by the way. Whenever he does another Everdrive OS update I'm sure he'd want to include it.

Yeah, I've actually been in touch with Krikzz since early January about this mapper30 implementation, as I can't really figure out why it won't even run on the AVS. I don't have an AVS myself and no plans to get one either, but I'd like this implementation to work for AVS owners too.

The original 002.RBF from the mapper example I used had the same problem of not working at all, so it appears that the mainline release has had accidental fixes done to it after that example was released, that somehow made it work on AVS, and which not even Krikzz himself can recall anymore, as he hasn't even observed that issue on the AVS himself.

Unfortunately he's also been too busy to provide a newer cleaned-up mapper example source from the current mainline. And I can't really try much out myself when I can only toss wild ideas into the build, and ask an AVS user in a different time zone to re-test it only to see a gray screen again...

But hmm, just realised now though that the MMC5 example released later has a slightly newer timestamp, and also has some extra code related to the reset signal. So maybe this could be the missing link... I'll try to look into this in the weekend.

[Bananmos]

When it comes, it will be an interesting challenge to emulate with the FPGA - especially given you cannot control all address pins.

I've thought about this before, and the nuclear option if nothing else works is that you do have complete control over the data pins when doing reads in cartridge-controlled addresses, and perhaps you can force the next few reads out of PRG ROM after a flash operation to come out as "JSR $5000" where some mapper-included BIOS code can take care of it (with the 6502-provided full access to the address pins) and correct the return address to be the replaced instruction.

Yeah, there's various ways it could be made to work. Block RAM to store per-page erase state would be another way to get around the limitations. But I can't say I'm too keen, as it's pretty overkill for what needs to be done. The standard vanilla approach for saving to PRG flash data should be to write to every single memory location after clearing a page anyway, and if that's what flash carts need then I can't see a great reason for why ROMs wouldn't do it that way. Unless they specifically want to break the system for copy protection reasons or whatever, in which case I wouldn't even want to bother fixing it.

Anyway, PRG is not something I'm likely to spend any time on before NESMaker supports it, or there it at least a PD ROM that uses it, so I'll know for sure what sort of code people will use for implementing flash writes.

[tepples]

The standard vanilla approach for saving to PRG flash data should be to write to every single memory location after clearing a page anyway

Are you familiar with how a log-structured file system works? A log-structured file system treats the underlying storage as a circular buffer. Once a page is erased to $FF, individual objects with a (file ID, version, size) header are written one by one to the page. Whenever the flash code is told to load a particular file into work RAM, it searches all pages for the last version of any particular file ID and loads that version. Once all but one page is full, those files from the the oldest page that haven't been superseded by a newer version of the same file get copied into the empty sector, and once that finishes, the oldest page gets erased. This pattern is intended to minimize wear on the flash chip.

PRG is not something I'm likely to spend any time on before NESMaker supports it, or there it at least a PD ROM that uses it, so I'll know for sure what sort of code people will use for implementing flash writes.

Let's say I want to write a proof-of-concept implementation of a log-structured file system on NES. Should it spend time deliberately writing $FF over every byte of the oldest page after erasing it?

[rainwarrior]

Anyway, PRG is not something I'm likely to spend any time on before NESMaker supports it, or there it at least a PD ROM that uses it, so I'll know for sure what sort of code people will use for implementing flash writes.

Black Box Challenge is free (download here) and it uses flash saves. It's also a long enough game that it really does need the save.

[rainwarrior]

This pattern is intended to minimize wear on the flash chip.

Wear levelling seems like it might be out of scope for an NES game's save data. Your ability to do this depends on how many pages you can spare for the save.

NES. Should it spend time deliberately writing $FF over every byte of the oldest page after erasing it?

I'd say you should write every byte you intend to read back, and nothing more.

Also, nothing less, since not having to rely on $FF simplifies things.

The third thing I'd recommend for any NES flash save is that the game should be able to run with garbage data in the save page and/or no ability to save (i.e. have a timeout when waiting for erase confirmation). Eventually the flash will fail, and it'd be nice if the parts of a game that don't really need a save don't have to have it.


Though I would say that it is a reasonable requirement for a PowerPak mapper to just say a game can only rely on XYZ. Most likely even existing games could be patched to meet a reasonable subset of capabilities, without having to duplicate everything that flash chips do, if they aren't already using only a suitable subset.