Printable View
Not a lot per se, but definitely more than normal channel sounds. Depends on how efficient the sample playback routine is. Some are slow(unoptimized code), some use compression which takes more cpu resource. There are PCE games that use two and three channels for sample playback (thought the third channel is usually not dedicated). And some games use samples for sound FX (i.e. not voice, but in game sounds. Blazing Lazerz uses samples for a lot of sound FX).Quote:
Originally Posted by Drakon
Quote:
Originally Posted by Drakon
Depends on how well a game is programmed. Apparently Air Zonk's sound engine with merely decent samples used about 20% of 'cpu resource' (or whatever). Pretty impressive the kind of action that a PCE can push using only 80% of its strength. SFII' runs much clearer samples through two channels at once and still manages to run SFII' at full speed, so the potential is there for it to not impact a full featured game.
How much cpu/ram/etc resource does your adpcm player use?Quote:
Originally Posted by tomaitheous
Crazy that the pc engine gives you so many sound options. Anyway I played some megaman 2 beta yesterday. Obvious glitches being the graphics in the intro, the drum samples, the bar missing at the top of the screen during the stage. Less obvious issues is quieter sound effects than the real hardware. Otherwise it plays just like the real thing it's great. I only tested part of one stage I'm still busy unpacking in our new house.
I sent my results to Tom over the weekend. I played through it in one sitting and I came away impressed with his efforts. Other than the items mentioned by him directly or stated in this thread, I really didn't have a complaint. The colors were a little darker than the NES, but that's to be expected given the differing palettes used by the TG. All in all, it's a solid port that, with some tweaking, would be a welcome addition to the Turbo library.
Now if he would just port it to cd like Megaman 1... ;)
Don't worry, it will happen (someone already requested it ;) And with CDDA tracks too as an option).Quote:
Originally Posted by Lastcallhall
Thanks to all that tested this for me, whether you had beat it or not.
A little info on this (I had assumed the info on this was already common knowledge. Sometimes I get ahead of myself):
- This IS the original NES rom running on the PCE. Byte for byte, the 6280 is running the original 6502 code. I don't know if you consider this a 'port' per se because and I didn't 're-assemble' any of the game code. It just runs.
- The NES PPU (graphic chip) is nothing like the PCE's (or Genesis for that matter), other than it has tilemaps and sprites. The tile/sprite 8x8 cell format is not compatible with the PCE. The tilemap is a different format and arrangement than the PCE. The attribute table (set subpalettes to BG tiles) is completely different on many levels. The tilemap sizes are different (I have to use an hsync routine to make the 32 cell vertical map into NES 30 cell vertical map). The PPU has byte (8bit) read/write ports to the graphics chip; the PCE can ONLY read/write WORDs (16bit) to the graphic chips (this is a big pain in the ass). I could go on and on. There are just sooo many differences. Normally, one would just completely re-write ALL the graphic routines for this type of project. Instead, since the PCE's cpu runs 4x the mhz speed - there's just enough speed to emulate the NES APU (audio) and PPU (graphics) in real time. Actually, the emulation code runs slower than normal so it ends up writing to the VDC during active display - but since the PCE has no problems doing this (as opposed to quite a few other systems that can't), the job gets done. Sometimes I have to adjust timing so it doesn't show glitches and such. It's way more detailed and complicated than I can explain here.
- So, graphics and audio are emulated realtime. Mapper support is as well. I don't emulate everything because it adds to complexity and sometimes cpu resource. So I emulate just what is needed for the game to run. That said, some things MM2 requires isn't emulated yet. Most notably dynamic tilemap mirror switching (which the opening sequence uses and the wily stage map uses, so they look wrong). There's no support for reading back tilemap data from vram either, so doors to the boss show weird tiles (garbage).
- The PCE has 16x16 sprite cells and the NES uses either 8x8 or 8x16 sprite cells (one or the other, not either at the same time). MM2 uses 8x8 and while the PCE has much better sprite capability natively, it wastes a lot of sprite bandwidth. Especially for metasprites with flipped vertical settings. It kills the sprite scanline bandwidth to near NES limits, but also eats through the 64 sprite table. What am I trying to say? Basically flicker is both internal (the game code itself monitors the sprite table entry to see if it over flows, if so then it 'flickers' all sprites thus the status bar and such start blinking) and external (sprite scanline limit). The only way around this is to hack the game to use native 16x16 or large PCE sprites instead of the NES emulated sprites. I did this for MM1 and it was a lot of work (though not publicly released). It might be a while before I do this to MM2.
Hmm, I guess I didn't really need to write all of that. In sort, it's the NES rom hacked and emulated on the PCE. I did not write this from scratch. In theory, every behavior in the original should be in this version. There's no resolution differences (it runs the same res as the NES console). If anything, slow down will probably be eliminated for almost all parts.
So, thanks to the testers on this site. I'll be releasing a public version pretty soon (I'm currently re-writing the APU core).
If you make a version for systems with extra RAM (TurboDuo, Arcade Card, ...) and there's enough CPU time you could mirror VRAM writes to an 8kB buffer somewhere in extended RAM, and then use that buffer as the source for NES VRAM reads.Quote:
There's no support for reading back tilemap data from vram either, so doors to the boss show weird tiles (garbage).
Definitely. I'll have to do some moderate hacking to the game in order to get it on SuperCD format. As is, the rom is 16k over the 256k size of the original (which is more than SCD ram).Quote:
Originally Posted by mic
A public release of Megaman 2 is up on my site (download and links section. See my sig).
You know, you could use the extra ram on the SGX in the same way, while keeping the game in rom. No rom size limit + extra ram = best platform for the game. :D
http://www.youtube.com/watch?v=o5FT3IGXtAkQuote:
Originally Posted by tomaitheous
And I thought my endless soldering iron parties required insane dedication and devotion.
As for all this "you could use this and that extra ram" why doesn't someone (tiido I'm looking at you) design a ram chip you just plug into some port of the console that gives the system a massive ram upgrade. Then you could program the ultimate turbografx game that requires you to buy an 80$ ram upgrade just to play....kind of like those msu-1 homebrews / ports for the sd2snes.
*edit*
just noticed you released version 0.85 of megaman 2, that's probably way more complete than the other one I was testing.
*edit yet again*
nevermind the publically released version is what we tested.
Just the audio emulation has been updated (Woodman's stage sounds more correct now, Metalman's stage drums sound correct, music for clear and item get screen is correct now).Quote:
Originally Posted by Drakon
Quote:
Originally Posted by tomaitheous
Damn, and I was just about to ask about a Genesis port. Then again, we have an official one already. But I'd like to see the Genesis play some original sounding sounds.
The gameplay mechanics of Wily Wars is somewhat off. It feels a little weird. This was a big disappointment for me 'cause the graphic overhaul was kinda cool. It'd still be worth having a Genesis port of this game. There are tools (emulators) out there, that can map all instructions in the rom to a readable map layout - allowing you to more easily locate 65x opcodes (because they are variable length, it makes this normally a pain and you have to do a lot by hand) and auto convert them to other processor code (say, like the 68k). Hacking the game engine to load pre-converted tile/sprite cell to Genesis format is fairly easy (this would save speed on realtime converting. Actually, this is probably 100% a must do for any realtime running of the game).Quote:
Originally Posted by evildragon
Isn't that what they kind of did for the Super Mario Brothers port to the Genesis? The game engine was auto converted to 68k by means of tools, but if I remember, the PPU was emulated.
Sort of. They already had disassembled source code, so that step was done. Plus, SMB is a pretty simple game - no mappers. All the graphics for the whole game are in vram at power up, because it's vrom (chr-rom). And the vrom has no mapper, so it's a no brainer. Megaman uses vram (chr-ram) which can be written/changed via game code. So you'll have to hack all the PPU write routines that update sprite cells and tile cells to vram, to write updated genesis formatted cells instead. It's doable, just more effort is involved in getting to that point.
Oh cool, the percussion on that first one you sent us was really messed up. I tested the public one while my girlfriend was sleeping so the sound was extremely low.
Really I always felt megaman belongs in 8-bit graphics wise which is why I love these cd audio ports so much. All official ports to newer consoles came with graphic overhauls which makes me sad.
I really wish someone would disassemble the street fighter 2 champion edition arcade roms. But something tells me that would be a massive amount of work. Something like that is certainly way over my head.
I also wish fpga / bios reprogramming stuff isn't over my head (which it completely is) otherwise I'd be doing everything in my power to fpga the rgb nes ppu as well as the pc engine cd system so you could just load a iso from a sd device.
Oh well I'm atleast glad that we have people like tomaitheous, chilly willy and tiido around so atleast some of my dreams became a reality.
Quote:
Originally Posted by tomaitheous