Is there anything that could alter an MMC1 reg3 write?

[MottZilla]

CHR ROM on SFROM/SJROM/SKROM/SLROM needs to be swapped 4 KiB at a time, which in my mind defeats the advantage of CHR ROM over CHR RAM. With CHR ROM on MMC1, you have to repeat the hero's sprite cels in each set of enemy sprite cels.

One use is in Ninja Gaiden the background is swapped between the status bar and the playfield so that you have more graphical tiles available for the backgrounds. With CHR-RAM you cannot do this. Though I suppose if you made your own MMC1 with 32kb of CHR-RAM then there would be no point in CHR-ROM over it with its large CHR chunk size.

But that just reinforces the point that it would be nice for homebrew to have a mapper that is smoother and more capable. You can always re-purpose a MMC3 but if you plan to produce your game on any scale you'll be stuck using donors rather than being able to have new parts. Although I think I mentioned before I would assume if you published your game through RetroZone that MMC3 wouldn't be an issue.

[bigjt_2]

One could argue that dealing with this problem is a part of the learning process...

Yep!

... but there are cases when fixing this is very frustrating because it requires great changes in the game's architecture.

And yep again.

Fixed it! I was reluctant to disable my NMI because I'm doing sprite 0 hit for my status bar. So whenever I disable my NMI interrupt during gameplay, everything goes to hell.

Let me describe real quick what I did. A lot of this will be real basic to a lot of you, but just in case it might help some other people with a similar issue in the future.

I took advantage of a variable already in my NMI handler. This variable (called sleeping) gets set to 0 at the end of the NMI handler just before the registers are restored. In the gameloop, it doesn't proceed past the continuous loop into the rest of the engine unless this "sleeping" is 0 (meaning NMI has fired). This particular process I learned from Metalslime, but of course it's a variant of what a lot of you do in your gameloops.

I basically applied the same thing to the PRG bank switching subroutine. At the end of the sub, it now checks if the variable is 0. If not, it branches to RTS. If it is, then it resets the MMC1 latch by writing $80 to $8000 (just to be safe) and then jumps back to the beginning of the sub to re-write to REG3. Also, I've now added a couple of lines pushing my current PRG bank # to the stack (where the registers get pushed) at the beginning on NMI and pulling at the end. Yeah, I think this describes all of what I did.

Regardless, I set a breakpoint on the new part of bankswitching sub and it's working exactly like I needed it to. Also tested it on the NES and there wasn't any noticeable slowdown. Then again, I should hope not, as it's only dropping one of 60 frames about 3% of the time. (This bug frame overflow was really random, another thing that made it so damn hard to find.)

It's still going to be my policy to keep things within the frame as much as possible, but it's nice to have this safegaurd here in case that doesn't happen.

Thanks for the help folks!

[frantik]

I took advantage of a variable already in my NMI handler. ... At the end of the sub, it now checks if the variable is 0. If not, it branches to RTS. If it is, then it resets the MMC1 latch by writing $80 to $8000 (just to be safe) and then jumps back to the beginning of the sub

heh, that's exactly what i suggested like 30 minutes ago

[tepples]

CHR ROM on SFROM/SJROM/SKROM/SLROM needs to be swapped 4 KiB at a time, which in my mind defeats the advantage of CHR ROM over CHR RAM.

One use is in Ninja Gaiden the background is swapped between the status bar and the playfield so that you have more graphical tiles available for the backgrounds. With CHR-RAM you cannot do this.

I understand what you mean. I've never played Ninja Gaiden, but from screenshots, its status bar could also use a lot of slimming down: "SCORE STAGE TIMER NINJA ENEMY" Does it use one set of enemies for all levels? Or how many times does it repeat Ryu's sprite cels?

If I use only three-fourths of the sprite half of the pattern table (and I can prove that with double buffering this can be feasible), that frees up 64 tiles out of which to build a status bar.

[bigjt_2]

heh, that's exactly what i suggested like 30 minutes ago

Yes, the only difference was I really didn't need to add something, per se, as there was already something there to use (the sleeping variable). Nonetheless it was a helpful suggestion, along with the others. Danke!

[tokumaru]

One use is in Ninja Gaiden the background is swapped between the status bar and the playfield so that you have more graphical tiles available for the backgrounds.

Touché! This is indeed an advantage of CHR-ROM over CHR-RAM, even if the mapper can only switch large chunks of tiles.

But that just reinforces the point that it would be nice for homebrew to have a mapper that is smoother and more capable.

I would really like that, one without the oversights present in the Nintendo mappers, but just like with iNES replacements, talks about a homebrew mapper come and go every once in a while but nothing ever changes.

Although I think I mentioned before I would assume if you published your game through RetroZone that MMC3 wouldn't be an issue.

I don't know, they can't seem to get the MMC3 right on the PowerPak... Unless something changed since the last time I checked.

[frantik]

heh, that's exactly what i suggested like 30 minutes ago

Yes, the only difference was I really didn't need to add something, per se, as there was already something there to use (the sleeping variable). Nonetheless it was a helpful suggestion, along with the others. Danke!

well if it helped at all thats cool

[Bregalad]

Oh I'm sorry to have stated my solution will solve all problems, because whoever corrected me is right, it's a bad idea to say that !

In this case it happened to solve the problem, but he's right that it might have been something else as well.

Maybe a wiki article about MMC1 writing techniques should be made ? I should include :
1) The normal way to do it (disable interrupts)
2) The tricky workarround (if you rely on tight NMI timing or if you sync with NMIs like Battletoads)
3) Some other workarround that works with 32kb or high 16kb PRGROM switching

[MottZilla]

CHR ROM on SFROM/SJROM/SKROM/SLROM needs to be swapped 4 KiB at a time, which in my mind defeats the advantage of CHR ROM over CHR RAM.

One use is in Ninja Gaiden the background is swapped between the status bar and the playfield so that you have more graphical tiles available for the backgrounds. With CHR-RAM you cannot do this.

I understand what you mean. I've never played Ninja Gaiden, but from screenshots, its status bar could also use a lot of slimming down: "SCORE STAGE TIMER NINJA ENEMY" Does it use one set of enemies for all levels? Or how many times does it repeat Ryu's sprite cels?

If I use only three-fourths of the sprite half of the pattern table (and I can prove that with double buffering this can be feasible), that frees up 64 tiles out of which to build a status bar.

As the game is, no you can't free up any space. It is all used. There are no significant free BG or Sprite tiles in banks. Another issue is the game also needs CHR-ROM for bankswitching between Cinema Scene graphics and the font. Though I suppose it might be possible to use the other 4K of pattern tables and switch between them although now we are just talking about it being possible to perhaps achieve something similar, but the point is that NG does need CHR-ROM as it was built. If it did not, it would have used CHR-RAM as CHR-ROM repeats Ryu's sprites since the enemy graphics change depending on the level or boss.

Another issue is the cinema scenes would require substantial pauses to load graphics between each picture where as with CHR-ROM it is instant.

[tokumaru]

As the game is, no you can't free up any space.

I don't think anyone is considering converting the actual game to CHR-RAM, tepples was probably just thinking of ways to hypothetically "remake" the game with CHR-RAM instead of CHR-ROM, as an exercise.

It is all used.

If I understand correctly, his idea was to dynamically load a single frame of animation worth of player tiles to a small section of VRAM as demanded by the game engine, so that there was no need keep all of them mapped at all times. This would free up a great deal of tiles, maybe enough for the status bar tiles.

I seem to remember that there was an item or something that created a ghost of the player, and in this case each copy would need to display different animation frames. This kinda gets in the way of freeing up those tiles.

Another issue is the cinema scenes would require substantial pauses to load graphics between each picture where as with CHR-ROM it is instant.

I don't think a couple of black frames would make such a difference (apparently the screen already flashes black between some scenes).

[thefox]

Maybe a wiki article about MMC1 writing techniques should be made ? I should include :
1) The normal way to do it (disable interrupts)
2) The tricky workarround (if you rely on tight NMI timing or if you sync with NMIs like Battletoads)
3) Some other workarround that works with 32kb or high 16kb PRGROM switching

Article about this and interrupt awareness in general would be good. There are other problematic things like updating music pointers (i.e. calling music init routines) from the "main thread" that can cause troubles if the programmer isn't careful.

but the point is that NG does need CHR-ROM as it was built. If it did not, it would have used CHR-RAM as CHR-ROM repeats Ryu's sprites since the enemy graphics change depending on the level or boss.

Another issue is the cinema scenes would require substantial pauses to load graphics between each picture where as with CHR-ROM it is instant.

If I had to choose a config for a new game, I would go with bankswitchable CHR-RAM. Maybe like 32K.

[MottZilla]

I don't think anyone is considering converting the actual game to CHR-RAM, tepples was probably just thinking of ways to hypothetically "remake" the game with CHR-RAM instead of CHR-ROM, as an exercise.

It is all used.

If I understand correctly, his idea was to dynamically load a single frame of animation worth of player tiles to a small section of VRAM as demanded by the game engine, so that there was no need keep all of them mapped at all times. This would free up a great deal of tiles, maybe enough for the status bar tiles.

I seem to remember that there was an item or something that created a ghost of the player, and in this case each copy would need to display different animation frames. This kinda gets in the way of freeing up those tiles.

Another issue is the cinema scenes would require substantial pauses to load graphics between each picture where as with CHR-ROM it is instant.

I don't think a couple of black frames would make such a difference (apparently the screen already flashes black between some scenes).

Actually given my extensive workings with Ninja Gaiden, tonight for fun I converted it to UNROM. I cut out the Cinema Scenes but the rest of the game is there and works. It fits into 128K (though without much to spare) even though it was 256KB before. The Cinema stuff takes up about half of the CHR and probably half of the used PRG.

There is no room in BG graphics for a status bar. For sprites, I wouldn't really know how to go about trying to dynamically load the current animation frame. There are no clones (Phantom Doubles is their actual name) in NG1, only NG2. So the idea does work assuming you actually have enough time to transfer all the tiles needed each frame.

An idea that might also work for a slimmed down Status bar would be to redraw the Item Pickup boxes to reuse and reduce the total tiles used to try to have enough for a status bar. Something like 20 - 24 or maybe more tiles are used by items the player can pickup. So if you cut these down you could probably get to still display the life bars, Score, Chi (special weapon ammo), current level, and time.

Not planning on releasing anything about it on UNROM since the ROM is far too different for any IPS patches or anything like that to not contain huge amounts of copyrighted material. But it could have been done though for the Cinema's I think UOROM would have been needed for the capacity. But I guess that just again proves you don't need a fancy mapper to make a good game.