Archive for April, 2010

Custom XM player WIP

Posted in Uncategorized on April 17, 2010 by pcedev

Yeah, she’s a coming along nicely. Still needs quite a few things (like a new period LUT, the current one is missing finetune for low octaves – which this song uses). Some FX still need implementing, etc. I  sorted out a few bugs in the FX I do have working, and added long sample playback support, so I figured I throw up a WIP vid/example.

What is it? It’s an XM player for the PCE. I have a converter that converts XM and MOD files into more PCE friendly format (a reformat), but all the FXs and such are still there. What is XM format? Go look up MilkyTracker

🙂

Oh and btw – the song is: HuC6280 on Fire! by Louis Gorenfeld. Thanks to Louis for providing a PCE legal MOD. <o.

Advertisements

A new sprite and tile mode for the PCE

Posted in Uncategorized on April 16, 2010 by pcedev

Yup. I’ve mentioned this to Charles in IRC a couple of times in passing, but in context of a different use. This requires no hsync interrupt correction logic and such, either.

The standard method:  Normally the PCE build sprites from 16×16 cells. It also builds BGs from 8×8 cells. Now, the 16×16 cell is nice – but sometimes it’s too much in certain situations and even causes un-necessary flicker and… even waste a little bit of vram memory. 16×16 can be too much when all you need is 16×8 or 8×8. The rest of the invisible data in the sprite, is still contributing to sprite overflow (normal shown as either flicker or just “blank out”).

The premise: Get the PCE to display sprites in cells of 16×8 instead of 16×16. As a side result, tiles will now also be 8×4 instead of 8×8. For BGs, this increase isn’t as important as sprite cells but there are some advantages:

  • More color definition in an 8×8 area. Since you have 8×4 tilemap entries, you have up to 31(30) colors per 8×8 area instead of the normal 16(15). For the very obvious reason that the tile right below the above 8×4 tile can have a different subpalette attached to it.
  • Smaller tiles means you can exploit “patterns” easier and save tile space. This isn’t a huge benefit as 8×8 is pretty capable of doing what you need most of the time, but this added effect is practical in the right hands or situations. Especially when you have repeated part of patterns, that you necessarily don’t want to appear as reused – but as unique. Late generation 16bit titles tried to expand on this idea (not the 8×4 thing, but reusing tiles in ways that don’t appear to be strictly patten limited).

For sprites, I think this would be self evident for anyone that’s worked with them – relative to sprite scanline limit. So I’ll not bother really listing the benefits of a 16×8 cell over a 16×16.

The method: Now comes the gory details. Yeah, you’ll love them. Actually, it’s not that complex but we need a little understanding about how the VDC and VCE work together. The VDC is the heart of the graphics for the PCE. It pretty much does everything; subpalette association, building the BG, building the sprites, etc. The VCE doesn’t do as much. It holds the external color ram (the RGB values for the VDC output putted pixels), it builds the NTSC frame works – timings and such, and also sets the resolution of the display (outputs the clock source that the VDC runs on).

Now, the VDC is perfectly capable of doing ALL of this on its own. And it does… on the PCE arcade boards (like Bloody Wolf). So it’s capable of driving its own display frame (even wildy non standard NTSC stuff), But the VDC is also capable of running in subordinate mode. That is to say, it takes queue from something external instead of generating it itself. This means the VDC could work in conjunction of a series of graphics chips (including other VDCs). This is called input mode.

The VDC has this weird behavior in that, when in input mode – it can still define its “own” frame. Well maybe not weird, but it can set the number of scanlines from 242 all the way down to 1, in steps of 1 scanline. It can also define the horizontal resolution by “clipping”. But this is in steps of 8 pixels. I believe you can have a horizontal width of just 8 pixels (and you can center this too). It’s nice. You could definite a 232 or 224 wide screen and not have to worry about clipping the sprites or background yourself. This also has a nice effect that sprites take up relative more “space”. And this is perceived as just that. ‘Cause you know, any “frame” filled with sprites… is a frame filled with sprites. Regardless of it’s width. I’m surprised developers didn’t take advantage of this psychological perception. Oh well, back on topic.

So here comes the weird part. The VCE drives the sync signals. Those would be hsync and vsync. These sync signals are monitored or triggered on the VDC side… because it’s input mode. Normally, you would define the display frame parameters to match that of the VCE resolution mode. But an interesting thing happens when you don’t. Say you define a horizontal width that’s larger than the VCE frame. Guess what? The frame gets terminated because the VCE generated hsync and the VDC “obeyed”. Now, what happens if you define a frame horizontal width that’s smaller than the VCE timings for a scanline width? The VDC will generate an interrupt when this internal frame ends, start processing the next scanline. But… the VCE is still outputting the same scanline! Bingo. Somethings got to happen. And that something is the VCE eventually generating hsync and the VDC obeying. So you have the VDC stopping in the middle of this scanline that it started generating, so it starts the next scanline.

Ok, but how does this help us? For starters, that means a whole scanline of sprites and BG data will now be skipped instead of being display. Actually, that’s wrong. If the VDC scanline ends early enough and there’s room on the VCE scanline, you’ll see the “next” scanline being drawn on the same scanline. Ever tried out those funny cheat passcodes in Coryoon? The one that displays 4 frames on screen? That’s what it’s doing.

For our purposes, we don’t want to display this “next” scanline. BUT, we do want the VDC to engage and give the internal mechanisms enough time to increment the logic for looking at the next scanline for tile and sprites. So we created a frame defined that just starts to do this, then bam – the VCE forces it to start the scanline mechanism again.

This results in every other scanline being skipped. This is literally scaling the whole display down by 2. But don’t think of it as such. You need to think of the display now in terms of being “interleaved”. Still 240p 60fps mind you. This isn’t interlaced stuff. But interleaved. What does that mean? Well, since the display is skipping ever other scanline – it will display either an odd or even interleaved version of this display allllll depending on the very last bit of the vertical position of the map Y position register and the SATB’s sprite Y position register. If you kept it at zero, you would only display one interleaved frame now matter where the sprites were put and how the BG scrolled. The VDC will need a new frame vertical length number now. Luckily the VDC can hold up to a value of 512 (and actually build a 512 scanline display, but that’s another topic). So this will need to be set accordingly, or you’ll get two vertical frames in a single window (split screen). We’re not after that effect in this instance, so we won’t be needing that. So if the VDC was set to 224 displayable lines before, it will need to be set to 448. Etc.

If you’ve followed along fairly closely, you might be asking yourself – won’t that waste vram? Because it’s only showing every other row of pixels. The short answer is: no. Not at all. But the long answer requires you to now think of vram layout as much more complex. Now everything in vram is interleaved as well (well almost everything). Tile data is now interleaved. Sprite data is now interleaved. Hell, even the tilemap is now interleaved. And since only corresponding interleaved data will be display, you can use the opposite interleaved data to store your other tiles/sprites.

Some more details..

You’ll have to make the tile map taller to compensate the 4 pixel tall rows.  A height of 64 would do nicely. That interleaves to two 32 height maps. And 32 is enough to handle any vertical scrolling needs. The complex part comes when you have a screen that’s multiple of 32 tiles wide. Say 64 or 128. I mean, those are already interleaved to begin with and now you’ve just added this whole new interleaved format ontop of that. Needless to say, you’ll have to write ALL new map updating routines :O

Oh come on, it’s not that hard 😉

The sprite table on the other hand, is less complex. A simple treating the bit #0 of the Y register as the “bank select” of which interleaved sprite data to show. And that’s on a per sprite table entry level. You can mix and match sprites from different interleaved areas of vram, in a single screen instance. To avoid artifacts, you’ll have to scroll the sprites on the Y direct in multiples of 2, not 1. But that’s not difficult and sprites have a 512 value system for Y.

How convenient for us 🙂

Of course sprite cell organization will be effect by this. As if it wasn’t already complex for some sprite sizes, this will make your head hurt even more. Yay! Sprite size NN x 64 never really had a good use. I mean, the sprite table even with 64 entries, was enough to handle most engines that did 32×16 and 32×32 size. But since we’ve now halved our base sprite cell vertically, that NNx64 mode is looking more useful. But (always a but), ever deal with setting up sprites in that format? Talk about alignment issues. Very strict on where the start (offsets) of that type of pattern is in vram. And now we’ve just added interleav..ation on top of that. Another YAY! 😀

What? Were you expecting of getting something for nothing? All good FX come at a price. I think, given what you gain, the negatives are just complexities of layouts and not something more severe. Maybe I should list the plus sides? Well, one of them is that you don’t need an hsync interrupt system to change -blah-blah parameters every scanline. It’s done for you. And it’s already compatible with hsync scrolling/fx. Secondly, if you really, really, really disliked having 8×4 tiles, interleaved at that, and additional interleaved layout on the tilemap – you could just do an hsync interrupt to correct this.. on EVERY scanline! Yeah, I wouldn’t want that overhead. Imagine 224 interrupts. No thanks.

But, you can turn “interleaved mode” on and off during the active display. Say, if you had a status window at the top or bottom of the screen. Like you would normally do, you turn sprites off or on for clipping in that area, use a reserved part of the tilemap for that window, sew any seams for vertical scrolling like a good boy in the non window area (like most games like that do on the PCE). You just make sure to have an interrupt right before the needed change from interleaved to normal, or vice versa, and change the horizontal regs. Don’t worry, they’ll love you for it 🙂

I’m not sure if I’m forgetting anything. Did I mention sprite cells of 16×8!? Much better optimization for flicker. Man, gotta love that. Not just specific to any game type either. That’s universal appeal. :3 You don’t even know how many times have 8 tall sprite cells have helped Genesis games. It’s just that much big of a difference for optimization.

Of course, this is an advanced skill level effect. So I don’t expect everybody to replicate this. Hell maybe even no one. I dunno. I mean, to design a game around this type of setup. But you demo boys, up to the challenge?

Now, take this effect and apply it to the SGX ._. You could do it “per” VDC. You’re not limited to doing it to both.

TG16 or Turbo Duo dev kit?

Posted in Uncategorized on April 14, 2010 by pcedev

Marshallh passed on this bit of news to me, that was posted on a non gaming forum…

“I have been trying to get my cousin to let go of his NEC turbographx dev kit, which is the only one I know of in existence, he worked atNEC/turbotechnologie s back in the late 80s early 90s, I think that would bring in some serious bucks as well as a ton of unfinished projects that are in it as well as floppy”

Interesting. I wonder who will snatch this up and if they’ll release any info about it. “Guy’s” cousin worked for NEC/TTi BITD, eh? I wouldn’t mind finding out who his cousin is and if he’d like to share any stories and/or experiences from there.

PCE audio research..

Posted in Audio on April 13, 2010 by pcedev

Doing a little researching into PCE audio engines of games today (again). Found some interesting things.

First, Devil’s Crush. Looks like some of the instruments on a channel are receiving small channel buffer updates. Very small, but enough to slightly change the timbre of the sound. Channel 6 of track 2 of the HES, you can hear it if you listen long enough. The timbre scales with the note in some parts, instead of a flat timbre to note scale. Another odd thing with Devil’s Crush, is the whole note system is detuned from the standard table. The WHOLE thing. Appears to be detuned by about -27 cents. Although this doesn’t scale too well (it’s about -20 cents just 2.25 octaves higher). I think there was another instance where a few high notes use a slightly different waveform. Gives it a nice but subtle effect (a nice peak to a build up).

Second, Afterburner. Uses sharper or duller versions of the same instrument to scale the timbre up and down selectively. At the beginning of one track, the intro part is very quick changing waveforms (as fast as every 3-4 frames).

I’ve already RE’d Bonk’s sound engine (the first game in the series). Pretty simple engine, yet it sounds soo great IMO. Love those trumpets, even though they are nothing special technical wise. I have enough info to reproduce a player and rip some songs.  Anyway, it’s a simple vblank tick engine. No TIMER resolution. Only a few effects.  Channel 1 is used for sample playback, but the sample rate is only 3.5khz. Strange they’d use such a low frequency. Oh well, they sound pretty good for what they are.

Edit: Heh, while just recently browsing wiki for something else, I came across a little bit of  info I didn’t know about. Apparently “heavy metal” bands would down tune from concert pitch. I don’t think this is a coincidence on Devil’s Crush side as the music is interpreted as just that…. but PCE-fied.

Blargg

Posted in Audio on April 13, 2010 by pcedev

I messed around with Blarggs emu audio code/player today. Got it to compile under dev-c++.  It’s nice in that he’s done a full band limited step synthesis system. Anyway, after a bit of fiddling I got it compiled and it plays HES files (as well as other formats). Gonna see if I can use the audio code for the custom PC tracker. I don’t particular care for c++ and I don’t like dev-c++’s debugger. So, gonna try to convert over the parts I need to C99 and use lcc-win32 instead.

XM volume tables…

Posted in Audio on April 12, 2010 by pcedev

Here’s  that chart I mentioned previously. Hope it explains it clearly.

Trackers…

Posted in Uncategorized on April 12, 2010 by pcedev

The only known tracker for PCE is by DamageX and is very limited (no audio output either until you compile it). I started working on a MOD to PCE converter. Why? Because the MOD structure fits perfectly for PCE. The Amiga period system is the exact same, both use PCM to playback tones, etc. PCE of course, uses tiny PCM samples in comparison. So I took on the task of writing a MOD to PCE converter and player (ROM). 6 channels with 1 channel for static sample playback (fixed at 7khz). After about a week, the player was up to speed and half the FX were working.

But I wasn’t happy. There are a few draw backs to the MOD format. One of them is the total number of PCM waveforms/samples is limited to 31. The second part was the FX column. And third, was that it had no volume envelopes.

In comes the XM format. After doing a lot of research, I found out that XM supports the Amiga period based system (a little flag in the file) and supports up to 128 samples. It also supports separate FX column for volume manipulation and addition FX. And finally, it supports volume envelopes. Not just ADSR, but anything you have define with 12 points. There’s sustain, and even “looping” with the option of fade out. Fade out is nice in that you can fade out at any point of the envelope phase, including “attack” (if you set it up as such) – on key release.

The other thing I like about MOD/XM is fine tune. This is a real time scale system. Sometimes, a pcm sample has different harmonics than what you would normally map it to on the note frequency scale. Fine tune allows you to adjust the note between 1/16 of a note (1/8 up from base note or 1/8 down from base note). With MOD/XM, this scales with the note frequency and octave range. This means a note will stay in tune as it goes up and down the scale. For normal long sample stuff on MOD/XM, you could just slightly resample the wave at a high or lower frequency to get it in tune. But for PCE waveforms, they are stuck at 32bytes. On no-finetune engines, your only option is restrict yourself to simplistic waveforms that “fit” or deal with the fact that it’s out of tune (which can sound horrible). I’ve traced through a few PCE sound engines and have yet to see any with scaling finetune. Detune, sure, but detune is used to set a channel slightly out of phase and it doesn’t “scale”. PCE, being a sample based synth system – finetune is an expected function. This might explain why most PCE games really limit themselves to simplistic waveforms (lots of square, triangle, saw, sine). Waveforms that have evenly divided frequencies and harmonics relative to known note frequencies.

XM isn’t the perfect match for PCE, but it does provide an instant audio experience in real time. A real PCE tracker with FX that more accommodate the PCE’s limited sample size, where as such effects might not be really necessary for sample based synth songs that already have long samples with pre-rendered audio effects.

A list of things that would benefit the PCE on the tracker side:

1) Sample phasing. You replace the channel’s waveform buffer with a new 32byte sample every 1/60 or slower as the note plays out. You’d have to pre-render a series of stages between on 32byte waveform, to another 32byte waveform. The effect can simulate a few types of sound, but one of them is “filter” bending. This concept isn’t new. Bloody Wolf does this to get a better “trumpet” sound out of the PCE, among other things. But it’s the only game that I know of that does this and on a very small scale. There’s a side effect of doing this. Turning the DAC on/off causes a spike in the out on that channel. Usually not noticeable, but you start do updating the channel waveform at a fast enough rate, you’ll get this “clicking” noise. Sad too, because if not for that – you could do 32khz sample play back on a simple 1khz TIMER setting. Fun fact: The SGX fixed this bug (or rather, the spike is tiny), so you can do this. But the PCE before *and* after the SGX still have this bug. The bug happens regardless of *any* volume levels, or channel setting.

2) Frequency envelopes.  Specifically with key on/off system. This not vibrato, but works in conjunction with vibrato. Given enough points, it’s like a programmable portamento. Much more powerful than a simple pitch slide mechanism. Could also be used in conjunction with “porta to note”.

3) Vibrato modulation. A modulator that effects the speed and/or depth of a current vibrato effect.

4) Tremolo envelopes. Control the depth and speed via a series of  “points”.

5) Key on off trigger for both vibrato and tremolo.

6) Waveform update with offset. Normally, you reset the channel’s waveform pointer with #$40, then #$00 to $806 – but one could reset it, write a series of bytes to offset the pointer, then update the full waveform. The channel buffer pointer wraps at 32bytes,  so whatever you wrote in to offset the waveform starting point will be erased. This has the side effect of playing to channels with one waveform slightly out of phase along with detune. You could even scale the offset with the note frequency, if you’re using two channels as a single instrument channel – your instrument sound changes as you go up or down the note scale.

And other effects like this. Reasonable effects. Stuff that doesn’t take up too much cpu resource. If you didn’t care about cpu resource, there are a lot of other effects you could do.

But for now, XM will have to do unless I finish my WIP tracker or someone else makes one. BTW – here’s a XM that I converted into 100% PCE legal specs (5bit waveforms and all)-> Satellite One PCE version (right click and “save as”). If you play this (*highly* recommend milkytracker as other standalone plays get it wrong) please turn off *ALL* filtering in the config and if applicable (in case the player ignores the flag in the file), set the frequency to Amiga period system or else the notes and slides will sound off/weird. PCE has no such filtering, so any MOD/XM will sound very soft or just different because of the filtering.

If you want to start using milkytracker to make PCE music, you’ll need to follow these rules:

1) Reserve 1 channel for “long” samples. Doesn’t matter what channel, as long as it’s the same channel through out the song. You can play short samples on it too, if you wish. But only play “long” samples on this channel. Set relative note to C-4, no finetune, and play all samples at A-3. If they sound too slow/fast, you’ll have to resample them in a wave editor.

2) *ALL* samples, long or short, must be 5bit resolution but padded to 8bit. CoolEdit 2000 will do this under “edit” -> “convert sample type”. Make sure you set “adjust sample rate” under “edit” to the correct frequency. That will be the frequency to down sample from. Cool Edit was bought out by Adobe IIRC, so it has a different name. But try to track down the older 2000 version. It’s perfect and has a nice range of useful PCE related features.

3) all other channels must have waves that are 32bytes in length (20 hex) and *only* use  forward repeating. You can finetune on short samples like these, but use steps of  “16”.You can also use relative note offsetting under instrument edit.

4) Go into config and set frequency to Amiga period (not Linear), and change “resampling” to “no interpolation”. Your very high notes might sound a tiny bit crunchy, but the rest will sound relatively appropriate.

5) You can use any of the envelope and FX parameters (including stereo pan adjust). For envelopes, you might want to stay withing steps of whole lines (see the grid in the envelope window, there are 8 lines plus the bottom. Use those as volume points for now until I get a chart up online).

8 ) You can use whatever speed or BPM setting, but be reasonable. Most people stick with speed of 6 and use BPM to change the speed of the song. The reason why you don’t want to mess with speed, is that it effects how all of the FXs work. It’s best to keep it as default unless you understand the inner workings of the system.

7) And finally, create a module that uses 6 channels. Even if you don’t use all of the channels. 🙂

Meantime, I’ll be working changing the MOD converter I almost finished, over to XM.