Archive for emulation

MM1 / MM2

Posted in Megaman, NES2PCE with tags , , , , on November 9, 2012 by pcedev

Been pretty busy the last week and will be for a bit. But I’m slowly chugging away at stuffs. I got this weekend coming up, so I need to prioritize what pce related stuffs I should do. I’ve got a lot (DX still needs ending credits, Spriggan Mark 2 need ADPCM offsets to tracks to go to BL for english dub prep, Motteke Tamago needs the new title screen inserted, etc).

Megaman 2 is getting an overhaul to the audio emulation code, so that is holding back the public release. Thanks to Drakon for testing out Megaman CDDA version. I fixed a few bugs. I also added an easy mode to MM1 (people seem to think this game is hard 😛 ). I need to fix the CDDA track loading screen (it looks like crap when the tracks load). So these two games will be getting public releases soon.

Also, Megaman 2 with CDDA tracks. Or hell, just a version that’s on CD as-is. It’s gonna be difficult. The game is 256k as is. But CDRAM for SuperCD is 256k (plus 8k for system ram). At minimum I need an extra 8k free bank to put my emulation code in and for CDDA track code, I need another 8k free bank. I thought about removing some graphic data from the game, and load that in when it’s needed (like at the start of a level), but none of the graphic segments start exactly on an 8k page boundary. I.e. there are no clean breaks where I can do this. It’s definitely going to be tricky to say the least.

And finally, not MM related, Dragon Warrior. I never publicly released this game. It’s on CD. I’m gonna redo some the emulation code because this game was the very first NES2PCE project that I ever did, then release it publicly. I’ll have to figure out BRAM syscard lib and make a save option too.

MM: sprite work extended

Posted in Megaman with tags , , , , , on March 18, 2012 by pcedev

Pwwwhooo.. You run into problems when you give NES extended sprite sizes ;>_>

NES doesn’t have negative left coords for hiding or moving sprites to the left off screen. They do for the right side though, but it’s only 8 pixels wide. The X position is 8bit: 0 to $ff. $F8-$FF don’t get shown onscreen and so they don’t wrap around. And since the largest width for a sprite on the NES *is* 8 pixels, it works. The problem occurs on the original NES is when you want that effect left side. Megaman handles this by hiding the sprites in 8pixel wide columns of the whole meta-sprite. So you get this sort of jarring/popping on the edge. Not a huge deal on the real system, especially back in the day when the edge of the 256 pixel wide screen was almost always partially in overscan area (TVs were rather poorly calibrated back then and the tolerance allowed for overscan was rather sloppy for consumer grade equipment).

So in comes my problem. I replaced all MM main character meta sprite with a single entry: 32×32. The game logic tries to remove the right edge on MM when he’s right at the edge of the left side, thus he disappears. Big problem? Not really. I can fix that logic. But that got me thinking. If I don’t find a solution to this problem, it could definitely be a problem for any other NES game one might want to upgrade as such. There aren’t enough bits left in the sprite attribute byte to fix this either (the problem is not to break compatibility).

So after mulling this over for a few days, I’ve come up with a solution. It’s pretty damn rare that games use “OAM data” ($2004). They all seem to use the sprite dma controller ($4014). The nice thing about the sprite dma is that it copies all 64 OAM entries to PPU OAM ram while halting the cpu. The dma controller takes an address based on $x00 from ram. And the NES only has 2k of ram ($000-$7ff). This is perfect for the solution. I have a shadow 64 entry in higher/invalid ram area of the NES range. This provides four additional bytes to the original four bytes for an OAM entry. For X and Y, the shadow equivalent bytes are a signed offset (2’s compliment). Perfect for offsetting the sprite with it ‘wrapping’ onscreen. And here comes the tricky part. For compatibility, the sprite dma function backend code clears each byte after it reads it. So the game engine itself doesn’t need to clear the shadow list. And if it isn’t used, values of $00 do nothing to effect the original. This also allows to me to use all 16 subpalettes for sprites and also allows me to use other sprite ‘banks’ in PCE vram.