Powerglove

[Lazycow]

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?

[lidnariq]

- 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 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.

- 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?

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.

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

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)

[tepples]

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.

[Lazycow]

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.

[lidnariq]

but it is decompressed into 40k ram at startup

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.

[tokumaru]

- 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?

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.

- 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?

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

[Lazycow]

@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.

[rainwarrior]

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.)

[tokumaru]

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.

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.

Maybe it will find a way into a multi-game-cartridge. PRG-ram or NROM-368 might not be a good idea then, right?

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

- The game is the small brother of my current project, Pharaohs Return

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

@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.

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.

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

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.

[tokumaru]

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.

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.

[lidnariq]

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? :

Code: Select all

+----------------+----------------+
|          level imagery          |
+----------------+----------------+
|  status bar 1  |  status bar 2  |
+----------------+----------------+

+----------------+
|  status bar 1  |
+----------------+
|     level      |
|    imagery     |
|                |
+----------------+
|  status bar 2  |
+----------------+

[rainwarrior]

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.

[Lazycow]

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?

[lidnariq]

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).

[tepples]

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

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.

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

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.