Nes2pce Possible to get more conversions?

[Dicer]

I know there are a handful of conversions out there...How hard is this? Are there tools or is it just the one dev doing the work (long since halted)

I saw mention of dragon warrior port, but no links around.

Would love to have a sizeable NES collection using the extra bit of punch of the PCE.

[NightWolve]

Pretty much only one guy has been able to do this, Malducci/Bonknuts/Tom/T-to-the-TurboXray.

https://pcedev.wordpress.com/downloads-and-links/

Yeah, he did Dragon Warrior I think, but didn't upload the patch anywhere I guess (too buggy perhaps ?). Anyway, very hard, few possess the hacking prowess to accomplish this, much less the desire...

[spenoza]

Give praise unto Bonknuts with flattery/money/poon/bananas and pray he looks upon your meager offerings with good favor.

[TurboXray]

Dragon Warrior is done, but it uses the original/old code. I wanted to update it (there was one bug in how the last boss shows on screen, but the plays fine). Audio could use the new emulation code too. Anyway, it's low priority at the moment.

 The emulation code is highly reusable, but each game does need a few couple of tweaks here and there. Not for the faint of heart. The problem is that you need to be familiar with both the NES and PCE on an advance level.

 Did you have something particular in mind, or just general conversions?

[Dicer]

I was dozing off when the thought popped into my head, I will lay down an altar and pray to the mighty Bonknuts so that we may be rained down upon with more goodNES.


I'm still dozing off...but I shall pray in my dreams...

[Dicer]

Dragon Warrior is done, but it uses the original/old code. I wanted to update it (there was one bug in how the last boss shows on screen, but the plays fine). Audio could use the new emulation code too. Anyway, it's low priority at the moment.

 The emulation code is highly reusable, but each game does need a few couple of tweaks here and there. Not for the faint of heart. The problem is that you need to be familiar with both the NES and PCE on an advance level.

 Did you have something particular in mind, or just general conversions?

Nothing really in particular...just wondering why it kind of came to a halt, so many classics that could be potentially ported over. I know nothing on the dev side, otherwise I'd be happily be porting away.

If you want to do one for shits and giggles, I'd love Tetris.

Down the line a "NES hits" superCD would be neat, but that would take work, and legality issues...that just mt personal pipe dream lol

[esteban]

Dragon Warrior is done, but it uses the original/old code. I wanted to update it (there was one bug in how the last boss shows on screen, but the plays fine). Audio could use the new emulation code too. Anyway, it's low priority at the moment.

 The emulation code is highly reusable, but each game does need a few couple of tweaks here and there. Not for the faint of heart. The problem is that you need to be familiar with both the NES and PCE on an advance level.

 Did you have something particular in mind, or just general conversions?

Nothing really in particular...just wondering why it kind of came to a halt, so many classics that could be potentially ported over. I know nothing on the dev side, otherwise I'd be happily be porting away.

If you want to do one for shits and giggles, I'd love Tetris.

Down the line a "NES hits" superCD would be neat, but that would take work, and legality issues...that just mt personal pipe dream lol

A game unique to the NES would make a lot of sense. Not sure about Tetris. I did enjoy 2-player battles in the Tengen version, though.

[spenoza]

Yume Kōjō: Doki Doki Panic would be hilarious to get running via NES2PCE. The game that ultimately became a Mario game, but still an original creation by Nintendo themselves.

[Dicer]

Yume Kōjō: Doki Doki Panic would be hilarious to get running via NES2PCE. The game that ultimately became a Mario game, but still an original creation by Nintendo themselves.

That's actually not a terrible choice either...

[Ayce]

I'd like to see Bonk's Adventure for the NES converted to the TG16... that of course may cause a tear in the time and space fabric.

[esteban]

I'd like to see Bonk's Adventure for the NES converted to the TG16... that of course may cause a tear in the time and space fabric.

Hahahahahahahahaha

[johnnymad]

I'd like to see Bonk's Adventure for the NES converted to the TG16... that of course may cause a tear in the time and space fabric.

A port of a port. Isn't that like inception?

[PukeSter]

Yume Kōjō: Doki Doki Panic would be hilarious to get running via NES2PCE. The game that ultimately became a Mario game, but still an original creation by Nintendo themselves.

Good idea, but two problems.

1. It's a disk system game.
2. There is no run button in Doki Doki Panic, and you must beat the game with all 4 characters.

[Joe Redifer]

I'd like to see NES Bonk via NES2PCE.

[BigusSchmuck]

Blaster Master? Or how about the Ultima games?

[NightWolve]

Blaster Master?

+1

Thinking of playing that, and now Metroid on a TurboExpress with the 3.5" LCD mod some day. ;)

[TurboXray]

The NES games that switch tilemap mirroring randomly, are a current problem for my nes2pce video code. I have an idea of how to handle this without hacking the game engine, but it's a major piece of work. Megaman 2 has this issue, when the screen scrolls for the end game stage map and the intro (unsupported mirror mode switching). Also, you might have noticed that in some games the sprites are offset by 1 pixel when moving with the BG.

 Normally this isn't a concern, as even some PCE games do this, but I do want to fix it - or attempt to reduce this. This is a PCE thing, because the PCE updates the sprite locations/attributes on a fixed schedule (at the start of vblank), where as the NES can do it anywhere in vblank. It doesn't just effect sprites, but moves vblank into the active screen area of the game - giving the PCE more time to translate NES PPU/APU data into PCE data on the fly (better syncing at the start of the next frame, etc). Since in game logic is running 4x the speed, there shouldn't be a problem with this (and in game logic tends to run in active screen for nes game, meaning they aren't touching the video display; i.e. it's running fast). As it is, the PCE is sitting idle for quite a bit of the time during active display. I want to put that idle time to good use. This idea is also complex like the mirroring situation.

 These two upgrades would open up a lot more NES games to be...hackemulated.  Hacmulated? Hamulated? Whatever. Something between HLE and emulation.

[Dicer]

The NES games that switch tilemap mirroring randomly, are a current problem for my nes2pce video code. I have an idea of how to handle this without hacking the game engine, but it's a major piece of work. Megaman 2 has this issue, when the screen scrolls for the end game stage map and the intro (unsupported mirror mode switching). Also, you might have noticed that in some games the sprites are offset by 1 pixel when moving with the BG.

 Normally this isn't a concern, as even some PCE games do this, but I do want to fix it - or attempt to reduce this. This is a PCE thing, because the PCE updates the sprite locations/attributes on a fixed schedule (at the start of vblank), where as the NES can do it anywhere in vblank. It doesn't just effect sprites, but moves vblank into the active screen area of the game - giving the PCE more time to translate NES PPU/APU data into PCE data on the fly (better syncing at the start of the next frame, etc). Since in game logic is running 4x the speed, there shouldn't be a problem with this (and in game logic tends to run in active screen for nes game, meaning they aren't touching the video display; i.e. it's running fast). As it is, the PCE is sitting idle for quite a bit of the time during active display. I want to put that idle time to good use. This idea is also complex like the mirroring situation.

 These two upgrades would open up a lot more NES games to be...hackemulated.  Hacmulated? Hamulated? Whatever. Something between HLE and emulation.

Hopefully these hurdles get leaped over at some point, because more is better

[seieienbu]

These two upgrades would open up a lot more NES games to be...hackemulated.  Hacmulated? Hamulated? Whatever. Something between HLE and emulation.

I like the term Hacmulated.  Megaman 2 is one of my favorite games; it'd be cool to have a Turbo version of it.  Good luck with your hacking!

[Dicer]

These two upgrades would open up a lot more NES games to be...hackemulated.  Hacmulated? Hamulated? Whatever. Something between HLE and emulation.

I like the term Hacmulated.  Megaman 2 is one of my favorite games; it'd be cool to have a Turbo version of it.  Good luck with your hacking!

Then you'll like this... http://pcedev.wordpress.com/downloads-and-links/

[seieienbu]

...looks like tomorrow evening is booked.

[Keith Courage]

I second Metroid. It is one amazing game.

Especially if there could be a save feature.

[ToyMachine78]

What language do these systems use? Are they the same or different? Are they proprietary code sets or something more mainstream like basic or C or something?

[TurboXray]

What language do these systems use? Are they the same or different? Are they proprietary code sets or something more mainstream like basic or C or something?

These games were originally coded assembly, but that doesn't matter since there are no public source code; all these games are in native machine language (compiled/assembled/whatever). The PCE processor is backwards compatible, so it can run the NES code natively. But that's about it - the rest has to emulated, or rather converted on the fly in realtime (mappers, bank switching, sprites, tiles, maps, audio, etc). My code is a bit voodoo, and not a lot of comments (that's an understatement), so it's so easy for others to jump in and use (from what I've been told, but one person did get it working on their own). From my own perspective, the code doesn't really need comments. It's kinda obvious what's going on for a port write/read emulation call. It just takes extensive system knowledge of both systems to be applicable, because the code isn't 100% out of the box reusable for every game. Small tweaks needs to be made here and there for each game (hence the extensive knowledge on both systems mentioned). The tweaks are usually centered around timing and related quirks.

 Anyway, the backend code on the PCE side is Assembly code. The NES roms themselves are still in native binary format; nothing is disassembled. So that's all on the coder to handle whatever. Usually nothing needed to be disassembled, but the port read/writes need to be tracked down and replaced with emulation hooks to the backend code. Personally, I put it at advance level stuff (hacking and programming) - but that really depends on the game itself. At minimum, it's intermediate level skill/knowledge.

 I don't make the source available to the public directly anymore, but to individuals who request it (whole project folder, etc).

[NightWolve]

Have you worked on your incomplete sound emulation code BTW, Tom ? After testing my TurboEverdrive on my Express, I tried your hackulation ROMs like Contra, Castlevania, etc. and I couldn't stand playing them under the condition they're in with terribly distorted background music/sound consisting of bleeps, blips, etc... Renders the game unplayable to me.

[Lochlan]

^From the downloads and links page of pcedev.wordpress.com:

NES2PCE projects:

- Castlevania 1 ver 0.44 (early beta)
- Contra ver 0.35 (early beta)
- Ducktales 2 ver 0.31 (early beta)
- Robowarrior ver 0.27 (early beta)
- SMB 1 ver 0.21 (early beta)

Note: The above nes2pce stuff have older audio emulation, and will sound off. They haven't been updated with the newer AUP core yet. Once I get sweep emulation working, I'll update all of the above roms.

...which I assume is what you're referring to.

[NightWolve]

Ah, good to see! So that has been fixed.

[ToyMachine78]

What language do these systems use? Are they the same or different? Are they proprietary code sets or something more mainstream like basic or C or something?

These games were originally coded assembly, but that doesn't matter since there are no public source code; all these games are in native machine language (compiled/assembled/whatever). The PCE processor is backwards compatible, so it can run the NES code natively. But that's about it - the rest has to emulated, or rather converted on the fly in realtime (mappers, bank switching, sprites, tiles, maps, audio, etc). My code is a bit voodoo, and not a lot of comments (that's an understatement), so it's so easy for others to jump in and use (from what I've been told, but one person did get it working on their own). From my own perspective, the code doesn't really need comments. It's kinda obvious what's going on for a port write/read emulation call. It just takes extensive system knowledge of both systems to be applicable, because the code isn't 100% out of the box reusable for every game. Small tweaks needs to be made here and there for each game (hence the extensive knowledge on both systems mentioned). The tweaks are usually centered around timing and related quirks.

 Anyway, the backend code on the PCE side is Assembly code. The NES roms themselves are still in native binary format; nothing is disassembled. So that's all on the coder to handle whatever. Usually nothing needed to be disassembled, but the port read/writes need to be tracked down and replaced with emulation hooks to the backend code. Personally, I put it at advance level stuff (hacking and programming) - but that really depends on the game itself. At minimum, it's intermediate level skill/knowledge.

 I don't make the source available to the public directly anymore, but to individuals who request it (whole project folder, etc).

Thanks for the explanation. I would agree that it would require advanced skill. I have worked with Assembler some at work. Some of our 3M vendor applications are written in assembler, and our older 3270 mapsets for our green screens.

Its definitely not very user friendly or intuitive. I always thought it would be fun to dabble in this on the side. I haven't coded since 2006 though, and I'm rusty. This would prob require more time than I have to commit at the time.

[TurboXray]

Thanks for the explanation. I would agree that it would require advanced skill. I have worked with Assembler some at work. Some of our 3M vendor applications are written in assembler, and our older 3270 mapsets for our green screens.

Its definitely not very user friendly or intuitive. I always thought it would be fun to dabble in this on the side. I haven't coded since 2006 though, and I'm rusty. This would prob require more time than I have to commit at the time. 

To be honest, it's not really the assembly syntax/language that poses the more complex issues - it's the hardware. Beside a few calculation look-up tables that I use for video addressing, almost all the code is for the emulation backend is nothing fancy. It's everything around the processor. NES video isn't clean in design/interface, and games rely on these weird quirks (you get dumby/pre-buffered data on the first read from vram port, etc). NES programmers turn off the display while in vblank, and this causes a problem for the PCE which doesn't need this. On the PCE if BG/Sprites aren't enabled by the time active display starts on the PCE, it's disabled for the whole screen - you can't turn it back on mid screen. A serious pain in the ass when NES code runs into active display area of the PCE. I had to cache/buffer this for a whole frame on the PCE side, so I could tell the difference between normal vblank code or if the game is really turning off the screen on the NES. I had to test for this case. Stuff like that. While that's working now, everything is still timing sensitive, since the NES code isn't perfectly synced (running) as with a real NES. I mean, it gets re-synced every frame due to v-blank interrupt. Usually not a big deal, but it can cause problems to where you need to tweak or replace some NES specific code (like sprite 0 trick on NES to make fixed status bars). Or some stuff isn't straight up emulated yet because games I worked with hadn't used that feature yet.

 I actually have three main PPU emulation cores that I tweak depending on the game. One is for games that use 8x16 sprites, one is for certain tilemap mirroring, one is for vrom vs vram, etc. I don't emulate everything straight out because the overhead of case checking makes the code slower and more complex. For instances, if I wanted to get Blaster Master up and running, I'd have to make a new PPU core than can handle both 8x16 and 8x8 sprites, because this game switches between these modes (overhead mode VS tank mode). Most NES games don't do this. 8x16 sprites on the NES aren't just large sprites; it also allows sprite cells (access to them) to cross into the BG only cell bank (which otherwise isn't capable of doing in 8x8 mode). It's common for 8x16 sprite cells and BG cells to be in same BG bank, so I have to double write to vram on the PCE to compensate for this; I write/convert the data into two locations in PCE vram (since PCE sprites DO NOT use the same cell format as PCE tiles, like it does on the NES). I could write code to switch between with core to use by testing a PPU reg status bit, but if the game updates vram/vrom BEFORE changing the PPU to this bit - then I won't be able to tell. This is crucial. The game would have to be hacked to fix this timing issue, if this were the case.

 Stuff like that. So the core(s) I wrote are reusable across different games, but they still need to be tailored/tweaked per game. Thus the requirement for both in depth/advance knowledge of NES and PCE. The commenting of my code is the least of the problem ;)

 The negative stuff out of the way, I do have a positive side; upgrades. Since I'm emulating the PPU in realtime, I've actually gone in and expanded the NES PPU capabilities. I took the unused bits in the sprite tables for the PPU, and gave it larger sprites with larger subpalettes. This basically gives a hacker a level of translation for PCE capabilities, but without learning PCE side of the system. So an experienced NES hacker could upgrade something like Megaman 1 or 2 with better graphics, without having to learn the PCE's much different hardware side. And they could write code as if it was on the NES system (6502, typical mapper, etc). But I have yet to get any interested hackers out there though, sadly.

 NightWolve: Yeah, I haven't made public the released the updated audio core for those games. Although they sound better, the lack of sweep emulation still makes them sound broken at parts. Once I get that working, I'll update it. Those games were more of just a proof of concept and practice (those games only took about a day to get up and running). Megaman 1, 2, and Dragon Warrior (unreleased) were tweaked to run as perfect as I could - because I cared more about those games.

[VenomMacbeth]

Soooo how about Recca?

[Dicer]

Soooo how about Recca?

Ew, we have the FAR superior shmup machine....there are much better titles to hack over.

[VenomMacbeth]

Soooo how about Recca?

Ew, we have the FAR superior shmup machine....there are much better titles to hack over.

And you don't think Recca could benefit from that superiority?  :/

But I will at least agree that something other than a shmup would be preferably... like a good action platformer, something the PCE sorely lacks. 

GIMMICK!

[Dicer]

Soooo how about Recca?

Ew, we have the FAR superior shmup machine....there are much better titles to hack over.

And you don't think Recca could benefit from that superiority?  :/

But I will at least agree that something other than a shmup would be preferably... like a good action platformer, something the PCE sorely lacks. 

GIMMICK!

Recca would be fine, but we just already have a fine selection.

Doesn't Gimmick use an extra chip? I imagine that would be a huge hindrance.

Metroid would be awesome. Or Zelda

[technozombie]

The Legend of Zelda ported to PCE then upgraded with the sprites/graphics from the BS Zelda Remake would be pretty sweet just on principal alone.

[TurboXray]

The Legend of Zelda ported to PCE then upgraded with the sprites/graphics from the BS Zelda Remake would be pretty sweet just on principal alone.

Very, very doable. But Zelda has extra ram (8k cart +2k sys =10k total), so making it a hucard project means using Tailchain's hucard (which mendafen supports) - or make a custom card (ram/rom card). Or make it as CD only project.

[ParanoiaDragon]

Nod had already started on a Zelda remake, I think Frag did the gfx IIRC.  I think though the engine was based on the Neutopia 3 engine rather then the NES game itself.

[Dicer]

Nod had already started on a Zelda remake, I think Frag did the gfx IIRC.  I think though the engine was based on the Neutopia 3 engine rather then the NES game itself.

Neutopia 3 existed at some point?!?!!

Such a tease seeing the ending of 2 only to never get the sequel...

[ParanoiaDragon]

Nod had already started on a Zelda remake, I think Frag did the gfx IIRC.  I think though the engine was based on the Neutopia 3 engine rather then the NES game itself.

Neutopia 3 existed at some point?!?!!

Such a tease seeing the ending of 2 only to never get the sequel...

We were working on our own homebrew version of N3 years ago, but abandoned it due to copyright stuff.

[HailingTheThings]

Nod had already started on a Zelda remake, I think Frag did the gfx IIRC.  I think though the engine was based on the Neutopia 3 engine rather then the NES game itself.

Neutopia 3 existed at some point?!?!!

Such a tease seeing the ending of 2 only to never get the sequel...

We were working on our own homebrew version of N3 years ago, but abandoned it due to copyright stuff.

Just release it under the name "N3wtopia" and change everyone's skin color to blue. There. Done. :3

[clackattack]

^^^ Love this idea, problem solved!

[DeshDildo]

I'm sooooo late to this party but since I recently got an ED I've been checking these out.  Huge praise to Bonknuts on this work.  NES and Turbo/PCE are my favorite consoles so this is like a wet dream to me.

 I would love to see more run and guns as it is my personal favorite genre.  It's awesome to see Contra (what about using the Japanese version with English hack for the extra animation).  Of course, Super C would be killer.  I wonder if Contra Force could benefit by running on NEC hardware?

The game I think would be most bad ass would be Journey to Silius.

Of course, having the NES version of Batman and ports of Turtles 2 and 3 would be amazing as well.  I wish I was more smarter and could do some of this software stuff myself.

[ParanoiaDragon]

In regards to Journey to Silius, I think most or all Sunsoft games used special chips for the sound, but don't quote me on that.  Atleast some did, which would probably add to the headache in hacking.

[SamIAm]

In regards to Journey to Silius, I think most or all Sunsoft games used special chips for the sound, but don't quote me on that.  Atleast some did, which would probably add to the headache in hacking.

Sunsoft had their own custom mapper called the FME-7, but Gimmick was the only one of their games that used a special version of it (called the Sunsoft 5B) for sound AFAIK.

If you can get the FME-7 to work in emulation on the PCE, then you can at least get Gimmick to work without any of the extra sound channels. That's how it runs on an Everdrive, which currently doesn't have the 5B channels supported at all.

[DeshDildo]

In regards to Journey to Silius, I think most or all Sunsoft games used special chips for the sound, but don't quote me on that.  Atleast some did, which would probably add to the headache in hacking.

There is nothing special about Silius.  It's SLROM which was used by many, many other games on Nintendo's 8 - bit hardware.  The actual chip is MMC1B1 or MMC1B2 (I can't remember exactly which and I don't think there's a difference anyways).  This is far from being one of the more advanced PCB's.

[BigusSchmuck]

Had another thought to add to the bucket list: Guardian Legend. Remixed music and upgraded graphics, that would be sweeto.

[Dicer]

Had another thought to add to the bucket list: Guardian Legend. Remixed music and upgraded graphics, that would be sweeto.

That's not quite what these are, the most you could hope for is lack of slowdown/flicker at most I would imagine...

[ParanoiaDragon]

Had another thought to add to the bucket list: Guardian Legend. Remixed music and upgraded graphics, that would be sweeto.

That's not quite what these are, the most you could hope for is lack of slowdown/flicker at most I would imagine...

Not necessarily.  Putting in new sprites & tiles that don't change hitboxes n' such, IIRC, are very doable.

[spenoza]

Had another thought to add to the bucket list: Guardian Legend. Remixed music and upgraded graphics, that would be sweeto.

That's not quite what these are, the most you could hope for is lack of slowdown/flicker at most I would imagine...

 

Not necessarily.  Putting in new sprites & tiles that don't change hitboxes n' such, IIRC, are very doable.

It has come up before, however, that because the NES can use smaller sprites, this can be a challenge.

I think Shadow of the Ninja would be a great candidate. It has tons of flicker and slowdown later in the game that might be resolved, and the PCE needs more awesome ninja games.

[TurboXray]

 Simply updating the color/pixels for the sprites is doable, but changing the size of the sprites so that they don't produce flicker (on the PCE), is a much harder task. This is what I was doing with Megaman. It's not just simply putting in a new size, but most NES 'sprites' are made up of smaller 8x8 sprites. If you substitute, say a 32x32 sprite (to remove flicker), for as a group of 8x8 sprites (a metasprite) - you now have to adjust for the 'offset' of that metasprite. That means building a new table and such to translate this all in realtime.

 It's not processor intensive at all (quite the opposite since the processor is prepping less '8x8' sprites), but it's very tedious work creating these table values and testing them in game. Then there's the issue of clipping; NES only has 8bit screen coords and removes 8x8 cells from a sprite as they disappear on the edges (sometimes not so great either. You see popping on the edges of the screen, or wrapping). The game logic doesn't now how to deal with X and Y coords that are larger than 8bit (on the PCE they are 10bit), so you have replace this part of the original game's routine with your own. Otherwise whole parts of a sprite will disappear at the edge of the screen. Every game is different, so it's not like you can simply reused this replacement code as is for any NES2PCE game. It's game specific. All of this is.

 So upgrading colors, music, and sound FX is pretty doable. Slowdown itself is usually automatically eliminated. But fixing flicker, by upgrading the sprite sizes, is no easy task.

 The time it takes to get NES games, mentioned here in the past few pages, to run on the PCE wouldn't be much time in comparison to the time it takes to actually hack these games for upgrades. Upgrades means figuring out how a game works, nes2pce process to get the original rom running on the PCE does not require this; I only address how the NES hardware is supposed to respond to the game code - nothing else. And that usually means adjusting some timing or such (the large percentage of the emulation code is reusable across games).

 But do you guys really want to play unmodified NES games on your PCE, though? I mean besides the cool novelty factor, which wears off quickly, what's the appeal if they aren't upgraded?

 At some point, Megaman upgrade will get finished. My god, I've hacked that game more than I've ever hacked/replaced code in any retro console game. But I still have a ways to go. I still have Dragon Warrior to be released. And I still want to do a quick upgrade version of that as well (that game is actually partially hacked already for graphics). But please, don't hold your breathe on any of these. If you really want a specific NES game on PCE, I highly encourage you to get other hackers involved. I just don't have the free time to do this. But I do have the time to help explain things and even probably look into some problems.
 
 To be honest, these are the plans that I had for nes2pce: Upgrade Arkista's Ring for 2-4 player TAP mode with enhanced graphics and music, upgrade Jackal with enhanced graphics, music, and 2 player mode, and upgrade Dragon Warrior with enhanced graphics and music. And upgrade Megaman 1 with graphics, music, and gameplay changes (6 button support, slide, etc). And possibly SMB with upgraded graphics and music. When any of these will be done, is directly related to the amount of free time I have. Man, I've wasted soo much of it over the years, too..

 PS: Hey, did you guys know that "MottZilla" actually got NES Contra up and running with an old version of my nes2pce lib before I attempted it myself? He's an emulation author, but IIRC he dabbles in homebrew and hacking as well. Maybe someone should contact him and see if he's interested in a particular game for nes2pce? He's got the skills.

Edit: Also, if you want to know which NES games would probably be easiest to getting running on the current lib - look for NES games that use chr-ram (not chr-rom). There's a document out there called "nesmapper.txt" which lists a lot of NES game, and which ones use chr-ram (it's listed as "0k CHR"). CHR-ROM is doable, but I only had simple mapper support for it. And it's not refined. So the ones that list "0k CHR" are the best candidates. Of course, "8k CHR" games also work as well (no mapper for vrom).

[ParanoiaDragon]

On that note, I'm still moving ahead on the music for Mega Man 1, can't stop, won't stop!  Elec Man has taken me much longer then any of the other songs, but I finally found a solution & am on the fast track to finishing it.  After that I just have Ice, Guts, Bomb, & Dr. Wily Stage 1.  I will go ahead & do a Title screen as well, & I need to do some touch up's  on Dr. Wily Stage 2 & the regular Boss theme(I feel like my version isn't quite up to par with the rest of the songs I've finished). 

I plan on getting back to Dragon Warrior, & am totally down for doing Jackal(one of my fav's from BITD), I'm unfamiliar with Arkista's Ring, I'll have to look into that.  Ofcoarse, I'd love to do Trojan, take the arcade gfx & use em' on the NES game.  And like others here, I'd love to see Contra, though, I still have my personal doubts about me doing the soundtrack for it.  Another I'd love to do is Karnov, but.....it's the same damn song thruout the whole game!  I guess that would make my life easier, though, I'd probably still want to find a way to put some extra variety into the soundtrack.