Megaman PCE thread

[TheOldMan]

...hucard version of the CD PSG player...

Just pointing out that it -should- take roughly the same amount of memory/cpu time as the bios player. I'd guess somewhere around 20% cpu, btw.
The assembler version is sorta commented; I did my best, but some of it still makes me scratch my head...Feel free to modify it, if needed. Maybe we can get a smaller footprint for the Hucard version, and some neat extra operations as well

[Arkhan]

If you want to do samples, you can always cheat and turn the samples into custom waveforms and play them back in succession while flipping through them.   Someone was doing that for voicesamples, but I can't remember who.

Either way, the player for MML doesn't really dent the CPU much, all things considered.   The entirety of MegaMan's soundtrack, converted properly into MML wouldn't take much space at all.  MegaMan 1 doesn't exactly have complicated soundtracks.   

[fragmare]

A little something I did for fun. 

[ParanoiaDragon]

Nice!  I guess I'll mention that I too am working on something special, mainly for fun, but, just incase Bonknuts ends up wanting it for this project.  I'm a Mega Man fan, so, it's hard for me to resist!

[Bonknuts]

From what you guys've tested, is the hucard version 100% compatible with the CD version?

[Arkhan]

From what you guys've tested, is the hucard version 100% compatible with the CD version?

As far as we know, especially since the BIOS was mimicked for the HuCard one, and it's all pretty basic byte-code stuff to feed into it either way.. 

All tunes I've made sound the same either way.    There's even that video on YouTube of all my tunes that USED to be CD, that were playing off of a flashcard instead.    Sounds the same.

[TheOldMan]

From what you guys've tested, is the hucard version 100% compatible with the CD version?

As far as we know, especially since the BIOS was mimicked for the HuCard one

Is that what he meant. I thought he was asking if the HuCard and CD versions of megaman were compatible. My Bad.

I'd say 99.5% compatible. IIRC, most of the changes were actually on the interface code, to run the player in a manner compatible with how BIOS does it. The byte-code stuff I'm sure is the same; the 6 or 7 routines to set up the player might be slightly different. And the code to turn the player on/off is different from the stock HuC code.

FWIW, when I was talking about duplicated code earlier, the player has two copies of the routines - one for background music, and one for sound effects. IIRC, the background code is executed first, and sound effects 'overlay' the bg music; ie, the bg music keeps stepping along, but the sound effects code, being executed last, is what you actually hear on a given channel.
I'm sure those could be merged by a talented programmer who actually knows 65xx assembler. (Unlike me. I still have to look a -lot- of things up.)

[Bonknuts]

Yeah, I was referring to the music/sound player. It's the hucard version that I'll want to use, even for the CD project (CD version will have that option; cdda or chiptunes).

[Arkhan]

Yeah, I was referring to the music/sound player. It's the hucard version that I'll want to use, even for the CD project (CD version will have that option; cdda or chiptunes).

If you're using a CD project, you're better off using the BIOS because there's less code you need to include and deal with to get it to work.

[Bonknuts]

The problem is switching back and forth between the game engine and the CD setup. I'm using a different bank of ram for the game, as well as a different stack pointer, and the sys card rom bank needs to be mapped back to MPR7 - which means different vectors as well. It's slow to switch back and forth between the two. For CD play and CD read, it's fine. But realtime music engine while the game is playing - I rather not introduce anymore processor overhead than I need to. The game is now running a lot faster than the original, but I'll also be adding in H-int scanline effects and other cpu resource additions to the game. That also complicates it. I need the music/sound engine to be local.

[TheOldMan]

Let's see if I have this straight....
To run megaman, you have to use a custom memory mapping (not the standard layout) to mimic the memory on the nes. Because of this, you have to save/restore several system settings when you switch between modes for the game (ie, to use bios you essentially have to re-map the system, and put it back when you are done).  Not only that, but (iirc) the basic ram stuff is different; the stack is in a different place, so if you use the pce irq vectors, it will push/pull from a different area in memory, essentially corrupting the NES variables....

kk. From what I remember (and it's been a while, so you would have to double-check the source code), the player itself is page agnostic - it doesn't care where it runs from, so long as it always runs in the same address range. I believe you could re-assemble the player in a different page/bank and it would still work.
You would, however, also have to move the variables it uses. I believe the player code actually accesses them by name, so you would just have to make sure they get assembled somewhere 'out of the way' of the NES variables. There is quite a chunk used, so it might be a bit difficult to set that up...
The other problem I see is getting the player actually called. The pce irqs map the player in and out, so you would have to make sure your modified version got called correctly. I don't think that would be a big problem, if the irq handler does it correctly.

It's going to be interesting to see how easy/hard this turns out to be, assuming you decide to try it.

[TheOldMan]

edit: sorry, double post.

[Arkhan]

I am pretty sure it is indeed page agnostic, because I recall moving it around with Atlantean a few times.


That might have just been the song data though.    It's been a while. 


I'm curious how bad the overhead really is for constantly switching back and forth.

[Bonknuts]

Hmm..

 If I setup an h-int interrupt at a certain point during active display, to swap into sys bios mode and manually call the PSG routine, then that might work. I would have to duplicate the h-int routine, for the screen fx, on the sys card side - but that's doable. Active display after a certain point has minimal timing issues (vblank is out of the question; nes NMI is always running - timing is sensitive, etc). Since game logic is 4x faster on the PCE, there should be alot of free time during active display; the game gets to the point of waiting for vblank much faster on the PCE than the NES. 

[TheOldMan]

the game gets to the point of waiting for vblank much faster on the PCE than the NES

If it's spending more time waiting on a vsync, then you should be able to map things in and direct call it. The pce irq system goes through some hurdles to make sure things needed are mapped in when needed, and there is a flag indicating if the psg irq is being serviced; so you would know if it was already running or not.

If you look at the modified startup.asm, (around line 900: search for psg_irqflag) you can see how it's called from a vsync().  Basically, it checks a buch of flags to make sure it needs to run the driver,   then ends up at psg_driver, which handles mapping things in/out and then runs the main/fx drivers.
If your irq routines are duplicated at the correct places in the psg_bank, it shouldn't be a problem
And keep in mind, you should be able to insert your irq routines between functions in the player, if needed. Just re-assemble that part of the code.

The other odd thought I had was to use the timer irq: do a timer setup to de-sync by 1/2 frame, then use the normal psg timer routine. Should stay off by 1/2 frame. That might cause other problems, though.