MMC5 ExGrafix Hello World

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

puzzud
Posts: 8
Joined: Tue Jul 05, 2011 8:19 pm
Location: United States
Contact:

MMC5 ExGrafix Hello World

Post by puzzud »

Greetings all.

I am in the process of developing a 6502 game library that can target the C64 and the NES (although still requiring different graphics source files). Eventually, I'd like it to target the Apple II, Atari 800, and the Atari 2600.

As you can imagine, handling each system's differences in a uniform way (where the application code is mostly platform agnostic) is the most difficult part of my goal.

I finally have a firm grasp of the most basic memory configuration for an NES ROM (including the way CHR-ROM's are appended to the end of the binaries).

My biggest concern is having to tailor the library to the 16x16 palette attribute table limitation. I stumbled upon some information regarding MMC5 and the ExGrafix mode. To be able to color background graphics per 8x8 character tiles would be ideal for matching the capabilities of the C64.

It seems as though most people who talk about MMC5 on these forums are not interested in the expanded attribute functionality but more of the other things the MMC5 can provide.

I was wondering if anyone can point me to any sample code showing the use of this particular aspect of MMC5. I'm not really interested in the banking properties which may be why my current attempts have been unsuccessful. I wouldn't mind just using my 32KB PRG and 8KB CHR setup.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

I think that the lack of interest on the MMC5 is due to the impossibility of producing new carts. The MMC5 is by far the most complex (NES) mapper there is, and so far nobody has successfully replicated it in hardware, which means that in order to make a cartridge of a homebrew that uses ExGrafix you have to destroy an original MMC5 cart.

I don't think anybody wants to make software that can't be easily put into real carts, so that's why the MMC5 is largely ignored. Personally, I don't see much appeal in running NES software exclusively in emulators.
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames »

^ That. Poeple program the system to get the games on it. If you wanted a game just for emulator, you pull out C and SDL/Allegro and get working on that. And does the C64 have a bitmapped screen at all? If so, that alone would make cross compatibility insane, since I think the NES works largely different than the NES. Especially with RAM constraints without more hardware.
Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

Post by Shiru »

C64 have a bitmap mode, although it is not very useful for action games. There is a text mode that used similar to NES as well.

I'd better worry about other differences than the attributes size. For example, scrolling and number/sizes of sprites. NES is much superior in these features, and universal solutuion like a cross platform library should aim for lowest specs of all the supported platforms. 8 large sprites that C64 provide, being recreated on NES with its 8x8 sprites, would be pretty useless, at least because of the 8 sprites per line limitation. You would prefer to use native NES sprite features, but you can't recreate them on C64.
puzzud
Posts: 8
Joined: Tue Jul 05, 2011 8:19 pm
Location: United States
Contact:

Post by puzzud »

Thank you all for the quick responses. Yea, when I considered how none of the current homebrew cart kits support MMC5, I realized I wasn't likely going to run my code on a real NES. I was bummed just a little but not much as my real goal is to develop a game that is ported to all the major 8-bit systems.

@Shiru You're right, there is plenty of other limitations that I have to contend with. The two system's sprite manage is so dissimilar that I've had to accept that my sprites will likely need 16x16 (as a single sprite on the C64 can't go any bigger). I was really just hoping to eliminate the need to compromise on the character graphics. The small resolution and 16x16 color limitation on the NES is what hurt so many ports (ie LodeRunner)--requiring scrolling when it wasn't necessary on its predecessors. I don't even want to think about cross platform scrolling at this point! :)

I disassembled Gemfire with little luck of grasping any kind of greater knowledge of MMC5 ExGrafix. If you guys know of any sample MMC5 code (demos, etc) out there that uses the attribute table extension, that'd really speed up my search.

Even if you guys could iron out the basics/steps of transitioning my current ROM configuration to a MMC5 one, that'd be awesome. Currently, my code uses no mapper, has 32KB of PRG-ROM and 8KB of CHR-ROM.

I'll probably not be sharing my application code but I plan on throwing my cross-platform library up on Google Code at one point.
User avatar
cpow
NESICIDE developer
Posts: 1097
Joined: Mon Oct 13, 2008 7:55 pm
Location: Minneapolis, MN
Contact:

Post by cpow »

puzzud wrote: Even if you guys could iron out the basics/steps of transitioning my current ROM configuration to a MMC5 one, that'd be awesome. Currently, my code uses no mapper, has 32KB of PRG-ROM and 8KB of CHR-ROM.
I thought the default state of most mappers will support having a 32KB ROM as a minimum, maybe even as little as a 16KB ROM. Most mapper docs say "the first bank is loaded at $8000 and the last bank is loaded at $C000". In your case, the first and last banks just happen to actually BE the first and last banks. You'll want to look at the MMC5 description of the registers though and make sure there aren't any that "come up with random garbage". If there are you'll want to inject code in the reset vector to intiialize them to some quiescent state. Other than that I think just changing to mapper MMC5 from "no mapper" should be simple. At least you don't have other mapper writes to worry about trapping for and replacing with a MMC5-ish equivalent.
Denine
Posts: 397
Joined: Wed Feb 17, 2010 5:42 pm

Post by Denine »

puzzud wrote:Thank you all for the quick responses. Yea, when I considered how none of the current homebrew cart kits support MMC5, I realized I wasn't likely going to run my code on a real NES. I was bummed just a little but not much as my real goal is to develop a game that is ported to all the major 8-bit systems.
SMS! Try SMS!
I disassembled Gemfire with little luck of grasping any kind of greater knowledge of MMC5 ExGrafix. If you guys know of any sample MMC5 code (demos, etc) out there that uses the attribute table extension, that'd really speed up my search.
I have code code from canceled "FAOD GFX Enchance project".
But everything is commented in Polish, not english, so.
Even if you guys could iron out the basics/steps of transitioning my current ROM configuration to a MMC5 one, that'd be awesome. Currently, my code uses no mapper, has 32KB of PRG-ROM and 8KB of CHR-ROM.
From what I can see..Just change mapper number to MMC5.
Well, have you read about MMC5 Disch's mapper docs?
There's plenty of info about it.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

Denine wrote:
puzzud wrote:I was bummed just a little but not much as my real goal is to develop a game that is ported to all the major 8-bit systems.
SMS! Try SMS!
I think puzzud was referring only to MOS 6502 and its clones, not Intel 8080 and its clones (Z80, GB CPU, etc). When two machines have different instruction sets, and the architectures aren't very suitable to compiling a higher-level language down to their respective assembly languages, it's hard to share even the game logic between the two machines unless it's turn-based.

@puzzud:
Apple II has no hardware for scrolling or sprites at all, and its audio is even more primitive than NES $4011. If you're going to include Apple II in your plans, then you're going to limit yourself to single-screen games like Missile Command, Donkey Kong, Tetris, and the like. This means you won't need to worry about the scrolling differences among NES, C64, and Atari 800.
User avatar
cpow
NESICIDE developer
Posts: 1097
Joined: Mon Oct 13, 2008 7:55 pm
Location: Minneapolis, MN
Contact:

Post by cpow »

tepples wrote: Apple II has no hardware for scrolling or sprites at all, and its audio is even more primitive than NES $4011. If you're going to include Apple II in your plans, then you're going to limit yourself to single-screen games like Missile Command, Donkey Kong, Tetris, and the like. This means you won't need to worry about the scrolling differences among NES, C64, and Atari 800.
haha pretty soon we'll limit him to vector graphics with a laminated cardboard screen overlay for "background". :lol:

My head a splode.
User avatar
MottZilla
Posts: 2837
Joined: Wed Dec 06, 2006 8:18 pm

Post by MottZilla »

Denine wrote:
Even if you guys could iron out the basics/steps of transitioning my current ROM configuration to a MMC5 one, that'd be awesome. Currently, my code uses no mapper, has 32KB of PRG-ROM and 8KB of CHR-ROM.
From what I can see..Just change mapper number to MMC5.
Well, have you read about MMC5 Disch's mapper docs?
There's plenty of info about it.
You still need to initialize the MMC5 registers. The only thing certain on power up is the last 8K of PRG ROM will be mapped to $E000-$FFFF. You can then setup a typical NROM setup if you wanted.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

Shiru wrote: I'd better worry about other differences than the attributes size. For example, scrolling and number/sizes of sprites. NES is much superior in these features, and universal solutuion like a cross platform library should aim for lowest specs of all the supported platforms. 8 large sprites that C64 provide, being recreated on NES with its 8x8 sprites, would be pretty useless, at least because of the 8 sprites per line limitation. You would prefer to use native NES sprite features, but you can't recreate them on C64.
Exactly. On C64 you can however multiplex sprites to simulate more than 8 esaily, although it consumes some precious CPU time. But even then the sprite size is a major issue, and the multi-color / hi-res problem on the C64 (which on the NES it's always multi-color AND hi-res), and the very different screen resolution make it a hell of a nightmare to make a dual C64/NES game, without having one very majorly different from the other. (I mean its not going to be just some graphics and sound changes).
Useless, lumbering half-wits don't scare us.
puzzud
Posts: 8
Joined: Tue Jul 05, 2011 8:19 pm
Location: United States
Contact:

Post by puzzud »

But alas, deciding to what resolution to restrict the playfield is the easy part. Making a music/sound effect engine that restricts the voices on the C64 to closely resemble the limitations of the NES sound system is not too hard.

I have a general approach so far that I haven't implemented completely that will overlay C64 sprites to appear to have the same multicolor nature of NES sprites. This application level sprite will take up two of the eight alication level sprite slots. To the C64 build, that means two of the eight hardware sprites. To the NES, that means reserve two of the eight metasprite slots but only truly use the first metasprite.

The sprite palette system on both systems are fairly different too, but again, one can be made to mimic the other; in this case, the NES interface can be made to mimic the C64 (ie modifying the palette entries and recommitting it to the GPU).

I want to match the C64/NES as closely as possible. I wouldn't let the other platform implementations lower the capabilities though. For instance, I wouldn't require all sprites be monochrome like the Atari 2600; instead, maybe I'd set up some kind of display list (HBlanking) color system that would draw the 2600 monochrome sprite in the 3 or 4 bands of color that the application sprites were set to (think of cutting out the silhouette of Mario and color him like the German flag).

Anyhow, solutions and/or compromises can be made. But what isn't happening right now is me figuring out how to setup MMC5 where FCEU doesn't show all gray when I boot my rom up. NES development is already touchy enough and adding probably the most complex mapper on top of it doesn't help. Does anyone have like a barebones example of a rom/asm that uses MMC5, particularly using the ExAttribute mode?
puzzud
Posts: 8
Joined: Tue Jul 05, 2011 8:19 pm
Location: United States
Contact:

Link to a video of the C64 progress

Post by puzzud »

Here is a link to a youtube video of my C64 progress: http://www.youtube.com/watch?v=GdLcGxVK_Po

As you can tell, I'm using blocks of 16x16 for both the sprite and the background graphics. The sprite is actually two sprites overlaid to give the appearance of an NES sprite.

The NES version runs but I have not implemented sprite animation (nor any metasprite system) or character output. I'm at a decision point where I will have to dedicate to the 16x16 approach or use MMC5 before implementing the character output code. So obviously, a video of my NES progress would be laughable by most on this forum.
puzzud
Posts: 8
Joined: Tue Jul 05, 2011 8:19 pm
Location: United States
Contact:

MottZilla takes the cake!

Post by puzzud »

MottZilla wrote: You still need to initialize the MMC5 registers. The only thing certain on power up is the last 8K of PRG ROM will be mapped to $E000-$FFFF. You can then setup a typical NROM setup if you wanted.
Thanks MottZilla. Although your post wasn't entirely clear to me at first, it was the best response received. I just figured out what you were trying to get across.

Between that and after running my ROM through FCEUSP's hex editor and poking around a bit, I noticed my problem: the initialization vectors at $FFFA were generally pointing to the beginning of $8000. This works fine, obviously, when using no mapper, a 32KB PRG-ROM, and thus, when the memory is present/loaded at boot. But, as you also implied, the ROM bank at $8000 is not set to the beginning of PRG-ROM at boot up when using the MMC5 mapper.

The solution, of course, was to move the RAM/ROM initialization code to somewhere in the tail end of the 32KB ROM block ($E000-$FFFF). Thanks again, MottZilla.
User avatar
MottZilla
Posts: 2837
Joined: Wed Dec 06, 2006 8:18 pm

Post by MottZilla »

No problem. In programming in general you always want to be sure you've initialized everything since many things have no defined power-up/start-up state. Undefined or uninitialized registers and variables being used can cause all sorts of problems.

Emulators often have behaviors that could let you pass without problems but fail on real hardware. Power-up states of mappers in emulators is one example, another is often all RAM is zeroed by emulators which is not the case on real hardware.

So just remember before relying on any registers or memory to be sure it's been initialized to the desired values.
Post Reply