[Solved]Split scrolling fine on Nintendulator but wack on...

[tepples]

qbradq: I'm not going to convert it to MMC3 because I would like to do a cart release using RetroUSB's printed boards

INL-ROM supports MMC3.

and they don't support it.

I think what was intended was a compile-time switch to build as UNROM or TGROM. It'd look like this (untested):

Code: Select all

.proc switch_to_bank_a
  .ifdef ::USE_MMC3
    asl a
    ldy #6
    sty $8000
    sta $8001
    ora #$01
    iny
    sty $8000
    sta $8001
  .else
    tay
    sta identity,y
  .endif
  rts
.endproc

Anyway, I have it running, and I see a still top status bar and a smoothly scrolling playfield below that. It works the same way on NES + PowerPak, FCEUX 2.1.5 SDL (old and new PPU), FCEUX 2.2.0 Wine (old and new PPU). What weirdness are you seeing?

[mrmmaclean]

Alright, I was running it on FCEUX 2.2.1 and getting the weird glitch. I decided to check for a new version and there's now v2.2.2 and it works correctly!!

Sorry for all the trouble. I'm sure anyone who tried the ROM and is not a fool probably didn't know what I was talking about. Note to self: check for the newest version of emulators to test...

[mrmmaclean]

Thanks for testing, tepples! There must be something about the 2.2.1 release that had something weird to it, as I can see you're testing with older versions.

As for not supporting MMC3, I'm talking about their reproPak boards (http://www.retrousb.com/product_info.ph ... c14e71dc37), which only support mappers 0, 2, 3, and 7. I can't buy MMC3 chips from a retailer so I don't want to use them. Unless I'm missing something.


Edit: the glitch was the whole scrolling section also scrolling vertically, which made no sense at all and I simply could not pinpoint the issue.

Edit: I just checked version 2.2.0 and it works fine. I redownloaded v2.2.1 to have a clean folder and tested, and the glitch is there. The problem is definitely that specific version!

[tepples]

Thanks for testing, tepples! There must be something about the 2.2.1 release that had something weird to it, as I can see you're testing with older versions.

Yeah, I skipped 2.2.1 because it broke support for mapper 28, which STREEMERZ: Action 53 Function 16 Volume One uses.

As for not supporting MMC3, I'm talking about their reproPak boards, which only support mappers 0, 2, 3, and 7.

And 34, as bunnyboy clarified in #nesdev. Use the mirroring instructions for 0, 2, and 3, and the banking instructions for 7. (The Action 53 menu engine was originally designed for #34.)

I can't buy MMC3 chips from a retailer so I don't want to use them. Unless I'm missing something.

What you're missing is MMC3-compatible INL-ROM boards from a different retailer.

[mrmmaclean]

And 34, as bunnyboy clarified in #nesdev.

Interesting. Though, while it doesn't effect my own project, it's kind of annoying that the website is not updated to account for that. Not all of us are lurking in irc channels.

What you're missing is MMC3-compatible INL-ROM boards from a different retailer.

You officially blew my mind! Thanks for the link.

However, a nearly $10 production cost increase per cart is not exactly a small matter, especially considering the negligible cost of discrete parts. Though the ease of use of those boards (pre-built, more compatibility, etc) could be worth it in the end.

[mrmmaclean]

Actually, scratch that. With CIC chips already in there and an option to make them flashable, these boards become a definite option! Thanks again!

[qbradq]

I only mentioned MMC3 because that's the only dev cart I have available

Also, while we're on the subject, you might want to check out forum member Infinite NES Lives' product page. He offers a CPLD-based development cart that supports a wide range of mappers (basically every mapper used in a licensed US cart) and a USB-based in-cart flasher to go with it!

Full disclosure: INF doesn't pay me, but I'd have his babies if I could

Edit: Woops, missed the whole second page

[mrmmaclean]

As a matter of fact, I must thank you for mentioning the MMC3 and both yours and tepples' links! I ordered his flasher and a couple of upgraded boards already!

I have converted my code over to MMC3, and while it was an interesting learning experience to write and test a generic scanline counter for splits, having a built in counter that doesn't waste my cycles is already a boon. And with battery backed RAM in addition to double the ROM size, everything I require for sweet NESsing is on the INL board! Pretty pumped.

[qbradq]

That's great to hear! For a long time there was a thought within the community that there would be no MMC3 development cart until someone made an MMC3 homebrew worth publishing. I'm glad to see that the presence of an easily accessible MMC3-based development board is promoting it as a target

[darkhog]

Well, it is catch 22/chicken'n'egg problem with things like that. Linux for example wasn't considered platform for gaming because no one made games for it and no one made games for it because no one was gaming on Linux. Until recently.

It'll take some time until major players except Valve goes to Linux as target, but I'm digressing.

I guess what I'm trying to say is that lack of ability to do something often inhibits any tries to do so. And often it's the other way around than you might think. Like with Linux gaming.

[tepples]

Well, it is catch 22/chicken'n'egg problem with things like that.

One way I've found to break chicken-and-egg in the NES scene is to make a test ROM. It at least helps get support into emulators, as I showed with my test for the Action 53 mapper.

But the problem with making something that uses MMC3 is that a game big enough to need MMC3 is usually big enough to need more art, and programmers have had trouble finding artists.

[qbradq]

The attitude that you don't need MMC3 if you don't have gobs of CHR data, or that you don't need anything more than UxROM unless you absolutely have to have WRAM, and that you don't need WRAM and can do everything in system RAM unless you want to provide battery-backed saves, and that you don't need saves because you can use a password system, is unproductive. If that attitude were the norm we'd still be using stone hand axes to strip raw meat from the carcasses of sickly bison.

The simple fact is we now have a reliable source of pre-assembled MMC3 development carts. Unless you're targeting NROM there's no reason not to target MMC3 (or MMC1 or FME7 for that matter).

/rant

[rainwarrior]

You could argue that the attitude that you should make your game for NES instead of PC is unproductive by exactly the same logic.

And yes, there's a zillion valid reasons not to target MMC3, but I'll just state the most obvious one here:

You intentionally chose to work with this platform because of its limitations. Don't denigrate others for choosing a slightly different set of limitations than you did. This is silly.

[tepples]

The simple fact is we now have a reliable source of pre-assembled MMC3 development carts. Unless you're targeting NROM there's no reason not to target MMC3 (or MMC1 or FME7 for that matter).

That depends on whether INL can produce UNROM boards (74161+7432) or UNROM + WRAM (74161+7432+7420) cheaper than MMC3 boards (one or two CPLDs depending on the functionality subset). True, having MMC3 boards available is a good thing, but big games still need more effort, and beyond a certain point, artists want to be compensated in some manner. That and there's a fixed overhead of making each cart, and small games on discrete mappers make it easier to take advantage of bundling efficiencies in much the same way as the sections of a newspaper by building a multicart.

[mrmmaclean]

Cost is definitely a huge thing, if not the biggest thing when it comes to the actual product and production. I am a jack-of-all-trades who needs a lot of graphics for this project, so something like the MMC3 is ideal, and I don't have to pay an artist because I'll be doing it myself. But discrete parts are super cheap (like 20 cents per chip) and if all you need is 8 kb of CHR ROM or something then using MMC3 "just because" is just throwing your money away. Not only that, but when I was working with the UNROM format, I learned a lot while trying to tackle the various issues I was having with its limits, which of course is invaluable.

The main reason I am developing a new game for the NES is BECAUSE of the limitations. I find they force me to think in ways that I otherwise would never have given the virtually unlimited freedom of, say, PC development or Flash/Air. The constraints are what drive me to push the limits of the console as well as my own limits of creativity and problem solving.

Either way, at the end of the day, Super Mario Bros is NROM. Enough said.