Archive for October, 2015

PCM player

Posted in Audio on October 31, 2015 by pcedev

That old PCM player that’s in the download in links section? No good. I was looking over it and realized that not only is it convoluted and complex, but the interface really doesn’t show how to use the damn thing. It’s a poor example.

So I revisited it. I’m going to attempt to modularize it into an easy library of sorts. I’ll include macros and routines for basic functions for controlling each channel. I also made it a little more friendly to memory page layouts compared to the fix bank requirement from before. This bumped the cpu resource up by 2.7%. In addition, I added dynamically controlled fixed frequency sample streaming for the last two channels. So 4 XM channels and 2 PCM streaming channels.

I refer to them as XM channels, because they use a linear frequency approach compared to period base system of MODs. It’s a phase accumulator. The nice thing about this, is that I don’t need a huge table to translate notes to frequencies. I actually only need a table of 12 notes at C3 (octave 3). Everything else can be derived by shifting that left or right. The phase accumulator is 19bits long with the top three bits being the whole number and the lower 16bits being the float part (fractional value). So I have a finetune table of 16 points between notes (plus or minus direction) for finetuning the wave form without the need of an external program. And lastly, I have 32 frequency steps in between notes. I could have more… waaayyy more given the 16bit fractional part of the frequency divider, but honestly from my experience 16 usually cuts the cake anyway, so 32 should be enough. The steps are for frequency sliding (or vibrato).

I’ll include a small command line utility that prep a wave file to the format needed for the player. The player supports loop points, so those would need to be included into the waveform directly for that support. I also don’t track the waveform by its length, but rather have an end of marker value in the stream itself. So those need to be included as well.

So the numbers I have for 4 XM channels is 29% cpu resource from the call to the RTI at 117 times per frame (1/60) – for all channels playing.  The frequency division is all handled inside the timer routine, so you would just need to provide the note to play.  For the 4 XM and 2 PCM, that number jumps to 36.6% if all six channels are playing. Still not bad at all. The timer interrupt is actually 6.991khz and not 7khz, but I reset the timer counter ever vblank to keep it in sync, and do an mid-between call to the timer routine – so it ends up being 117 calls per frame or 7.02khz. Honestly, if I skipped it and did 116 I doubt there would be an audible difference.

 

On the topic of audio, have you guys ever heard the PCE stream 55khz 5bit PCM using the channel’s waveform memory as a buffer? Check it out: http://pcedev.net/6280a/sgx_dump.wav   That was recorded from my SuperGrafx. Basically it’s a 1.7khz timer interrupt, which means an interrupt called 29 times per frame. Each interrupt call, just refill the buffer. On the SGX, you only need one channel to do this (or any of the core grafx consoles with the 6280a processor). The regular 6280’s need two channels to do this. Sounds pretty good for 5bit audio. Because of how audio tends to get filtered/blended at that higher range, you can actually interleave channel streams and have them mix together. You could do a ~64khz output setup, but have four streams feeding it in interleave format for a 4 channel PCM stream at 16khz each. Not bad at all, especially considering how light the cpu resource is compared to something like 7khz single channel output the old fashion way. But here’s the crazy thing, as if that wasn’t crazy enough, you can do this with two channels on the SGX and stream 10bit audio in the same fashion. Just let that sink in for a minute…

Email and server is back up..

Posted in Uncategorized on October 30, 2015 by pcedev

I’m currently reconciling all the stuff between my laptop and new desktop setup. I don’t think my laptop is going to survive much longer.

SamIam and I talked about the possibility of a dub for Spriggan Mark 2. That’s all I’ll mention at the moment on that.

I finished my final for one my classes, so things I’ve got more free time, which is one of the reasons why I’m setting up my desktop system; pce dev stuffs. In an attempt to get more organized, I’m going through and trying to make a list of all the wonderful things and possibilities of PCE stuffs that I want to do. I have a terrible time trying to keep track of all these things, so I need to organize them into a system. I tend to forget about things. It’s not that I lose interest, but I forget and pick up other interesting stuffs.

Anyway, just an update. Also, if you come across anything that appears damaged (file wise) for my links, let me know.

Email and file server is down

Posted in hacks, homebrew, NES2PCE, retro on October 17, 2015 by pcedev

My server account got suspended cause I didn’t pay the bill. Hopefully I can get it back online in the next few days.

I’ve been messing with PCE hardware this weekend. Also looking over what projects are due, what needs attention, and what is going to be put on the back burner (for time resource reasons).

That and just some gaming on the SGX+SCD. I was playing SMB (nes2pce) and realized I could optimized some of the nes2pce PPU emulation code. Anytime the cpu writes to vram, the internal emulation code has to do all these checks to make sure it’s transferring data to the right area (and how to interpret that data). I needed this because I found games could just load PPU tile, sprite, and tilemap stuffs all in one shot.

Of course this slows things down having to do all these checks. Sometimes it puts what would normally be the cpu in vblank time, into the start of active display. I figured one way to speed this up, is to have dedicated $2007 write functions. NES games tend to setup strings of data into a buffer to be updated during vblank (because game logic is processed during active display). This means it’s very rare that a string of data will cross a tile bank into a nametable area, etc. So for those areas of code, I could potentially use the faster and specific $2007 write functions.

Nes2pce code was never meant as general emulation for NES games to run on the PCE. It was to get the game up and running close as possible, to help the transition of replacing the original NES sprite and map routines into native PCE stuffs. Though none of the nes2pce stuffs I’ve released have these changes.

Ideally, the sprite and map routines should be hacked for direct PCE writes, by passing some of the PPU emulation. So the optimization I listed it kind of counter intuitive to the goal of nes2pce. But I just don’t have the time to alter each game for these kinds of changes. I used to have that kind of time, but I squandered it :/ Eventually, I will have that kind of time again – but will people really care about nes stuffs on PCE by then? One example is Dragon Warrior. It’s the first RPG I’ve ever played, so I have nostalgia for it. I’ve already hacked the map routines somewhat. The game is simple enough to keep modifying. But should I really put my time into it? This is the dilemma I’m faced with nes2pce.

Anyway, just thinking out loud.