Powerglove

Hi, I am currently thinking about porting the C64 game "Powerglove" to the NES.

-
NES mockups (left), c64 screenshots (right)

more infos: http://www.lazycow.de/powerglove

It has been created with cc65 and as65, so I "only" would have to remake the low level functions.

But I have some questions:
- The map is scrolling and there are 2 splits on the screen for the status display on top and the map display on the bottom. Would this be possible on the NES?
I only know about the sprite-0 split, but what about the 2nd split? If there's a way, is there example source somewhere?

- The game uses about 3k ram for building the map and storing the blocks for one room. As I do not want to change the game core itself, would it be possible to use CHR-ram to store that map data?

- Would someone be interested in building Powerglove cartridges, or is the game too simple?

The simplest answer, and most familiar from a C64 point of view, would be something like MMC3's scanline IRQ. (I think this differs from the C64, where I think one programs the scanline on which the IRQ should fire; on the MMC3 one sets how many scanlines should pass before it fires)

The scanline IRQ was reinvented in the NES at least three different ways, but from a software point of view they're pretty similar.
I suspect it would be easier to instead specify that your game uses an extra 2 or 8 KiB of RAM that's provided on the cartridge (mapped from $6000-$7fff)... but anyway, the only problem with CHR RAM is that you can only read or write it while the PPU isn't drawing. If that's not a problem, and you don't need all 8 KiB of CHR RAM for patterns, then yes, you could store the extra data in CHR RAM.
If you're looking to get your own, INL sells all-new-hardware flashable cartridges compatible with the MMC3. Larger production runs would probably better start off by contacting him.

You could also repurpose an existing boards. Generally we like to dissuade that, though. Or you might be able to find a source of second-source MMC3 clones (such as the ax5202p)

And how would this game use hand input?

"It's so bad."

But seriously, it's more traditional on the NES to display the map and the status in the same bar, as is done in, for example, The Legend of Zelda. If you insist on splitting the status bar, there is another scanline IRQ inside the NES, but you can't use it while playing DMC samples.

How big is the C64 game in bytes? The size of the game might inform whether the expense of an MMC3 CPLD is worth it compared to a cheap discrete board.

Yes, "it's so bad" ... Still don't know that movie. (Shame on me)

Thanks for the infos! On the c64, it is a 16k rom cartridge, but it is decompressed into 40k ram at startup, using prepack6502 and exomizer and some additional crazy tricks... On the NES, this is not possible, because of the lack of ram, so I would probably want to use a standard UxROM with 64k PRG rom. (8k CHR ram?)

This audio IRQ split is clever, then no special mapper would be required.

The bigger problem is that I didn't know that I can only access CHR ram in vblank. Meh, have to think about it. The cartridge should be as cheap as possible, so PRG ram is not a good option.

This might be a good time to point out NROM-368... at least, if you don't have much self-modifying code.

If you're specifically looking towards production costs: a new 5V ROM or RAM is about $1, a random 74xx series IC is about 10-20¢. A CPLD is somewhere around $1.5. The PCB will cost somewhere around 2-4$. A new case will cost somewhere around $4-6. The cheapest possible board is a design that uses part of the NES's screen memory for character data, but it won't work on every famiclone (Not all famiclones pay attention to one of the signals on the cartridge connector. This breaks a small handful of games, including Gauntlet). It is also rather restrictive. That said, the canonical example of it is compatible with a subset of AxROM, so "incompatible with famiclones" just means "sometimes you have to install an extra RAM on the cartridge"

After that, next is NROM (or NROM with CHRRAM), which is the standard minimal NES game, and just two ROM+RAMs. Then NROM-368, AxROM, BNROM, GNROM, and Color Dreams, all of which add a single logic IC. UxROM adds one more IC. Honestly, all of these are comparable enough in cost you should just pick one that's convenient.

There's the set of otherwise-unheard of cheap hybrids between CHRless and the various discrete logic boards above, but I'm hard pressed to think of a situation in which they'd be useful.

I see in a video that the screen scrolls vertically as well as horizontally. Combining 4-way/8-way scrolling with status bars isn't such a trivial thing on the NES, depending on the type of name table mirroring you use. The easiest way would be to use single screen mirroring (as provided by AxROM, for example), because you can dedicate one name table to the gameplay and the other to the status bar(s), keeping them completely separated. With other mirroring types the gameplay would eventually overwrite the status bar and you'd have to dynamically relocate it or skip over it with more splits.

The main drawback of scrolling with single screen mirroring is that since a name table is the same width as the screen (256 pixels), you're left without offscreen areas for horizontal tile updates (vertically this isn't a problem because the status bar buys you the space you need for offscreen updates). The PPU does offer the option to mask the leftmost 8 pixels of the screen, but since palettes on the NES are applied to 16x16-pixel areas, you'll still end up with color glitches like the ones in SMB3 or Kirby's Adventures near the edges of the screen.

Completely clean 8-way scrolling with status bars IS possible, but you'll either need a few tricks or extra hardware. The simplest trick would be to mask the rightmost 8 pixels with sprites (Alfred Chicken and Felix the Cat do this), but this means sacrificing a number of sprites and effectively reducing your sprites-per-scanline limit to 7.

As for the splits, the first one can be done with timed code only (you can count cycles from the end of VBlank), so you can save the sprite 0 hit for the second split. If you're not sure the time between the 2 splits is enough for all your frame calculations, you can have a DMC IRQ fire near the sprite 0 hit, so you're sure you won't miss it.

The other option is of course using an MMC3, which would make the carts more complicated/expensive to manufacture.


If you really don't want to change your map encoding, I see no way other than including extra RAM on the cart.

@lidnariq: Oh, NROM-368 is very interesting!

But currently, I am thinking about AxROM/UxROM:
- it is common and it has CHR-ram
- Powerglove is not a very complex game, so it will probably not be interesting enough to build lots of cartridges. Maybe it will find a way into a multi-game-cartridge. PRG-ram or NROM-368 might not be a good idea then, right?
- The game is the small brother of my current project, Pharaohs Return, which needs much more than 48k rom and then I would need bank-switching code anyway.

@tokumaru: Hm yes, on the NES I would need 4way scrolling because the screen is only 256 pixel wide. The size of one room is 320x384, 640x192 or 320x192 pixel.

I like the idea with the static status display and sprite-0 at the bottom. Maybe I should try to start with the split.

I would not recommend using CHR-RAM as a substitute for PRG-RAM. The narrow timing window for access requires a very advanced NES programming technique to use effectively.

8k of PRG-RAM at $6000 is supported by a lot of common mappers, and fairly simple to build as a discrete mapper, if you're concerned about building the carts. In a case like this where it will make it much easier for you to port, I think it is a good option to consider. (PRG-RAM could be added to AxROM or UxROM, though I am unsure which emulators would currently support it.)

A different question might be why you need it. For 4-way scrolling on an NES, having random access to the whole room does simplify things a lot. However, is your room static or dynamic? If they're static, are you using RAM because the rooms are compressed? If they were uncompressed, could you get away with read-only access? A mapper like UxROM might give you the space you need to page in uncompressed rooms.


There are a couple of methods to do 2 splits without a mapper IRQ. Here's two options (one of which was already mentioned):
1. Design your NMI carefully with timed code to do the status bar split at the top, and then use your sprite 0 hit to do a second split at the bottom.
2. If you do not need DPCM sounds, you can use a sprite-0 hit for the status bar, and a blank DPCM sound to trigger a timed IRQ for the second split.


As far as 4-way scrolling implementations go, you might take a look at how Super Mario 3 does it (check out its nametables in a debugging emulator like FCEUX). Since your maps are less than 2 screens high, you can get away with a static vertical position in the nametable and just stream in new vertical strips at the horizontal scroll point. As stated, there is a hard to avoid attribute glitch on the right hand side, but this was considered acceptable for SMB3, at least.

Shrinking your rooms to 256 pixels wide might also be a consideration, but that might be a more invasive change than you would like. If all your rooms were <= 512 x 480 you could fit them statically onto 4 nametables with a mapper that has extra nametable RAM (e.g. Gauntlet), which would make 4-way scrolling almost trivial to implement. (Actually you would only need to shrink the 640 wide rooms for this method.)

I tend to like these simple mappers because they're easy to work with and to build physical copies of. I like UxROM, but sometimes a fixed 16KB of PRG-ROM is too little or too much, and AxROM/BxROM start to look like better choices.


Yeah, NROM-368 isn't anything like the common multi-carts.


Oh, I had seen that before, looks really cool!


The maximum height of 384 pixels will make things easier for you, since 2 name tables stacked vertically will give you 480 pixels, which should be enough for the map and both status bars. The color problems related to scrolling horizontally will still be there though.


You can detect the end of VBlank by waiting for the sprite 0 flag (which got set during the previous frame) to be cleared, because this always happens at the same time every frame, near the end of VBlank. Then you can do some constant-timed tasks or simply wait for the time to change the scroll.

The sprite 0 hit further down will be trickier because of the 4-way scrolling. Since sprite 0 hits only happen when solid sprite pixels overlap solid background pixels, you can't simply draw a solid background line to make sure the hit will happen (like would be possible if you scrolled in a single axis). You might have to manually put a solid background tile where the hit is supposed to happen.

Another important thing to consider is that during rendering, only the horizontal scroll can be changed though the normal means (register $2005). In order to change the vertical scroll as well you need a little trick that involves writing to more registers.

There's no need to time the entire NMI handler... I worked with timed NMIs before, and they were quite a pain. You can handle the PPU updates normally and wait for the sprite 0 hit flag to be cleared in order to sync with the PPU.

Another PPU feature you can use is the sprite overflow flag. You can line up 9 sprites (yeah, it's a bit of a waste) near the end of the top status bar for the first split, and use the sprite 0 hit for the second split. Using the overflow flag after the gameplay window isn't recommended, because game objects can accidentally trip the overflow sooner.

I noticed that the game is more like Metroid's "only two way at any given time", which ... might help? At least, given a mapper that allows you to switch H/V during runtime (such as m28).

Maybe the layout for status bars could be laid out like this? :

The video only shows horizontal or video scrolling, but the screens are 40 tiles wide, not 32 (though only 24 tiles high). The OP said there are some rooms that are double-wide double-high as well, so I presume even on the C64 version 4-way scrolling is needed somewhere.

Yes, currently the game generates the rooms procedurally. Ok, if I would change the map format to use 16x16 pixel tiles instead of 8x8 pixel tiles, then I wouldn't need any extra-ram at all and a simple 64k+8k NROM would do the job. Or I use lots of rom to store all the rooms in decompressed form. Neat ideas, cool!

But first I want to do the double-split. Ok, it's better to do Sprite-0 on top, DPCM on bottom. Wasn't aware of that.

One question: On the C64 I changed the border-color mid-frame several times for debugging. Is this possible on the NES?

The color emphasis, left column mask, and monochrome bits can be changed at any time. The overscan isn't normally visible on the NES, and you can't change the palette midscreen without disabling rendering (and reenabling, and breaking sprites).

Yeah, most NES games used 16px metatiles. If your rooms are 320x384 pixels (20x24 metatiles) or 640x192 pixels (40x12 metatiles), then each room will fit in 480 bytes, which is just under 1/4 of internal RAM. That's just slightly larger than the 32x13-metatile sliding window that Super Mario Bros. uses to cache the collision map for the area around the player.


During rendering, the NTSC NES PPU draws the side borders using the backdrop color (last value written to PPU $3Fx0). This border is hard to see on a traditional CRT, but any LCD TV will show it clearly. But you can't change the palette cleanly without disabling rendering. So I second lidnariq's recommendation to use the monochrome and tint bits, or possibly to just disable background rendering (leaving sprite rendering enabled) for parts that you want to be particularly visible during profiling. Another technique that resembles printf debugging is to temporarily have the status bar display something other than the score, such as the "C0DE" at bottom center in debug builds of my games Thwaite and RHDE that displays four hexadecimal nibbles.

Yeah, the main advantage of using DPCM for the second split is that it fires an interrupt, so even if your logic happens to take more time than expected you'll still be able to do the split without glitches.

DPCM IRQs aren't as simple as they sound though... the sound hardware isn't aligned to the video hardware, so even if you ask for a sample to start playing at the exact same pixel every frame, the IRQ will fire with a variation of up to several scanlines (depending on the frequency of the sample). This means that the DPCM IRQ alone isn't enough for a clean split. Most commercial games that used it for raster effects had the IRQ fire right before a sprite 0 hit, which allowed for proper synchronization with the PPU.

tepples linked to a discovery of his that greatly increases the control you have over when the DMC IRQ fires, but I found the whole thing too complex... to this day I still don't understand it completely. I believe it involves setting up a preliminary IRQ so you can count how long it takes to fire (a time that you waste every frame) and use that count later on to compensate for the misalignment. I was never able to replicate the idea perfectly on my end, and even when the thing was mostly stable I would occasionally (every few seconds or so) get a big timing variation.

Correct. You end up wasting up to 432 cycles, the period of one byte at speed 15. It should be fairly straightforward to get it at least as clean as SMB3's (admittedly glitchy) split, so long as you have a way to test on hardware.

New mockups! This time, the monsters are build out of 4 8x16 sprites (to get 6 color monsters). The program code has to take care that there are not 2 monsters on the same level when the player comes along. Otherwise it would flicker...

Seems like I won't have enough time to finish the NES version this year. But it is available now for C64, Windows, Mac and Linux. Get it here: http://rgcddev.itch.io/powerglove

I tried the Windows version quickly. The presentation is very solid all-around. The game is simplistic, but fun to play. I like the fact that there are separate builds for modern operating systems, and the 3 MB download size.

What's the "shader mode" in the Windows version? It doesn't work on my computer (I have 8800 GTS, so I expected it to work).

@thefox: Nice to hear that you like it. I think it would be a nice NES cartridge. Several C64 players mentioned that it gives some kind of "NES feeling" when playing it

The shader mode bends the display a bit. (like on a curved CRT monitor) Unfortunately, it does not work with every GFX chip and it's hard to debug if it works on your computer. That's why it is disabled by default. (does not look better than the default mode, anyway)

How does that degrade with the red single-eyed guys? They jump off edges, I thought I remembered getting a pit full of them when playing the C64 build.

@lidnariq: Hm... Yes, you are right. There are some rooms which would be problematic and the monster placement would have to be changed a bit. But the red one-eyed "Tap Tap" robo only falls into areas without other robos. (if I remember correctly)

As the 3 additional colors are used in the eyes only, another possibility would be: One robo just closes his eyes if there are too many sprites in a row! (Ha, I like this one)

Wait a minute... if a robo only has 1 eye, then it only needs 3 sprites in one row. Two one-eye robots and a player does not flicker. It is complicated...

There's also the room with the two two-eyed red hopping robots, but the idea that they would wink is amusing.

Lazycow you've been peddling this on all boards how about you wait until you have a nes build to show instead of including links on every board to your c64,win builds.

... you bothered to make an account just to post that?

This is the nesdev forum, not the nesreleases forum...

No lidnariq I've made an account because I enjoy 6502 and nes dev and the topics discussed in the forum interest me immensely as there some very profound programmers that reside here.

Not to mention this being appropriately on-topic to this forum.

Yeah the whole point of the Homebrew Projects subforum is for people to show off their work. The fact that a NES version is under development is enough to warrant a thread here.

Fair enough thefox,as I'm beat on he's never going to port this to nes and Atari 2600 but you guys seem to agree he will, and since I'm a new member unlike you i'll give the programmer(lidnariq an thefox the benefit of the doubt) i'll give in
I apologize LazyCow and hope you do convert the game to nes,2600 best of luck to you
We await your port LazyCow.

Oops, didn't want to annoy anyone, I thought you woudn't mind.


Wink test...

Left robo: the hilighting-pixels vanish, too. (but it might not be noticed)
right robo: removed the hilighting pixels. (so the body has 3 colors and the eyes have 3 colors)

In case of a "sprite overflow", only the eyes would have to vanish... (thanks for the inspiration, lidnariq)

Finally, I've got some time to continue with Powerglove. Cartridge init seems to work now, but I had to write my own PNG converter, because the chars seem to be numbered differently than on the C64 and my plan is use as much original code as possible.


pgtest1.nes
It's just a test image, but just in case you want to have some evidence that I am really working on this, here's the cartridge image...

Next up: colors (PNG converter only works b/w for now)

Which black do you usually use? ...and wasn't there a color you should not use?

$0D is the color to avoid (in practice, it's almost never a problem though. Codemasters games always used it). $0F is usually used for black.

Use colors $xE, $xF, or $1D for black. Don't use $0D, that's darker-than-black and some TVs will incorrectly parse it as hsync.

pgtest2.nes

Ok, the png converter handles colors now. (Using $1d for black) - Still only a boring test picture.

I also changed the map generation to use 16x16 pixel tiles, but it does not fit into the 32k rom. Can you recommend a simple code example for ca65/cc65 bank switching? (i have found some code here at nesdev, but phew...)

edit: wait, it's a 16k +8k rom... can't I use a 32k +8k rom without bankswitching?!

Yes, NROM ("mapper 0") supports that. Just make sure you pad things correctly with your assembler and/or linker so that your vectors/etc. end up in the last 16KByte portion of the 32KBytes (I'm sure you know why).

Hi, I am currently working on a sprite-0 split for scrolling.
A busy-loop checking for bit 6 in $2002 seems to work, but... how can I trigger an interrupt?

By using a mapper (such as MMC3) that provides such IRQs.

Sprite 0 hit can't generate an interrupt (unfortunately).

For a split at the top, I could busy-wait in the NMI-code for the sprite-0 hit. That might work.
Let's say I don't want to use a special chip like MMC3 (and no audio-IRQ), how do games usually handle a split at the bottom of the screen?

They busy-wait (examples offhand: Addams Family, Ghostbusters II, Gradius). Of course this has obvious problems if the frame handling can take longer than a frame.

The other way is to use DPCM Split technique, which (ab)uses the DMC as a crude interval timer. See the DPCM Letterbox demo.

Yes, I know the (amazing) DPCM demo. Maybe I will try, but there's another problem with the IRQ.

This little test is called at the beginning when I startup the NES. (screen turns green and I see some garbage)
here's the init code, did I disable IRQ correctly on startup?

Any hints?

Seems fine for disabling the APU frame IRQ. Have you tried in debugging emulators?

After the SEI, no IRQs will ever fire, even if you fail to disable the IRQ sources. It's good practice to disable them anyway, though.

Ok, I have found the bug, NMI and IRQ used parts of the same code segment. (oops)

Some progress: In the NMI, I wait for the sprite-0 hit (red part), then I setup the DPCM IRQ.
The IRQ-handler is called 3 times (green part), it increases a counter and wastes some time
and then at the 3rd call it disables the IRQ (lda #0 sta $4015). (end of green part)

But there's a problem: The start of the green part is moving with each frame.
I know, this should happen, BUT at the end of the movement, before it jumps back, it seems like one IRQ is missing for one frame. This is a bug, right? What's wrong? How do I avoid this?

It might be easiest to use FCEUX or Nintendulator and set a breakpoint on the NMI so that you can see what's happening on a frame-by-frame basis.

If you are missing an IRQ, it's hard to speculate on why it's being disabled too early; it'd help to see a little more of the IRQ handler source.

Here's the...

Oh, I see, you just copied the code from dpcmletterbox.

Did you set the DPCM to loop? It looks like tepples's dpcmletterbox doesn't, and restarts it inside the IRQ instead.

Hm... I am not sure if I can read the letterbox code correctly. Does the IRQ handler restart the IRQ every time? Even if the screen has been split? Huh? That would be different to my approach.

Yeah, tepples's code always manually restarts the IRQ. Hence your comment about "why does writing to 4015 have no effect?"—if DPCM loop is on, it won't have an effect because the $10s bit in $4015 is still on, so writing to $4015 with that bit on won't do anything. It only restarts sample playback if the previous sample is finishing, indicated by that bit being clear.

I really don't have any more useful advice at this point beyond recommending loading your thing in nintendulator's debugger—you can set a breakpoint on the IRQ and it'll give you the corresponding screen coordinate.