Comparison of 4th generation ("8/16-bit") system hardware

[Kamahl]

Which part did you have trouble with? I also didn't describe the precalc'd hue/luma thing fully. A line of every tilemap would only point to row 0 of every tile associated on that tilemap line. So when you go to do you Hint routine, you basically set the Y position of the tilemap every 8 pixels to get the alignment right. But what I was mentioning was, is that you could use the lower 3 bits of the Y offset to select which row of pixels every tile on that whole scanline is referencing. Thus you could make gradients going in both directions. You could also assign different subpalettes for horiztonal effects via color changes but the resolution in steps would be little bit coarse (equiv to 2 pixels in 128 double wide mode).

Trying to understand what you were trying to do . Still don't quite get it.

I could write it and find out, but I'd feel more comfortable picking the brain of coders that tweak these kind of routines in their sleep (rotation, 3D, on limited systems, specifically 65x would help, etc) Yeah, just doing the scaling perspective isn't much of a problem, but where's the fun in that? I've already done it via Hint Y scale routine demos before. Doing a X scale on top of that wouldn't be hard.

Speaking of scaling: http://www.pcedev.net/demos/scaling/title_scale_3.zip <- nothing is optimized (the scaling routine) and the chunky to planar converter is sloooow. But it was fun to write.

That demo is just awesome , nice to see the Lunar port coming along.

About the bitmap effect: By restricting the number of possible colors to 8 and wasting 8 palettes it's possible to use the original 4 pixel split tiles, eliminating the need for 512pixel wide mode and reducing the vram updating requirements.
Also allows for a full resolution bitmap if 512 wide mode is used. That would require SuperCD ram however to store the bitmap.

[tomaitheous]

What's so bad with that ? Or what alternative would be better (besides linked lists like MD has) ?

Not the sprite order priority (PCE is just like that). I mean priority relative to the BG layer. I'm glad it's not like the SMS. I'm glad it's on a per sprite basis.

[kool kitty89]

Their order in the sprite list.

The order they appear in the sprite table. I'm glad the PCE doesn't have the SMS mode (assuming I could only choose one mode).

Not the sprite order priority (PCE is just like that). I mean priority relative to the BG layer. I'm glad it's not like the SMS. I'm glad it's on a per sprite basis.

So the trade-off is that the SMS has per tile priority for the BG relative to the sprite plane, but the PCE has per-sprite priority relative to the BG?
Thus, the SMS could have any tile drawn in front or behind the sprite plane, but it must be in front or behind ALL sprites, while the PCE allows any sprite to be behind or in front of the entire BG plane without any per-tile priority control.

There's also the separate issue of PCE tiles not supporting flipping (but with sprites supporting horizontal flips -not sure about vertical) while the SMS has no sprite flipping, but does have tile flips (at least horizontal, I forget about vertical).

Regarding palette updates, you can do 3 updates in HBL on MD with artifacts not being on active scan. When you disable VDP in HBL you could update most of the 64 colors at cost of no sprites

That could be really useful for some CPU/ASIC(etc) rendered games using the tile planes only, or FMV for that matter. (or static images)

There is 420 pixels on a scanline in total, 390 pixels in 40H res, and 30 in 32H res(wider). HBL forms a good chunk of the active line.

I think this was addressed before, but the MD can't switch between H32 and H40 in hblank or vblank without major graphical glitches on-screen, right? (otherwise that would be pretty useful for extending DMA bandwidth for lower res games -or for cases where you'd want different resolutions on different lines)






On the issue of the PCE's hblank color updates, couldn't you fake added hblank by using a boarder of black tiles and thus hiding any fringing artifacts (since the "stuck" color would be black, the same as the rest of the boarder).

You couldn't do that with the MD since it artifacts differently.

[tomaitheous]

On the issue of the PCE's hblank color updates, couldn't you fake added hblank by using a boarder of black tiles and thus hiding any fringing artifacts (since the "stuck" color would be black, the same as the rest of the boarder).

Even easier, the PCE lets you define the actual displayable frame inside the NTSC frame. For vertical, you define the number of active scanlines (from 1 to 512) and you define the horizontal active with in units of 8 pixels ( from a minimum of 8 pixels to a maximum of near NTSC overscan). The border color is sprite color #0 (which is never seen on any sprites). That way sprites automatically get clipped too. Just set it to match BG color #0 and you're all good to go. Technically, you can define multiple frames inside a single NTSC frame too (each with their own 64 sprites). Or do weird stuff like have the dot clock high and have two 'vdc' scanlines unfold onto a single NTSC scanline. Etc. But I digress...

Thus, the SMS could have any tile drawn in front or behind the sprite plane, but it must be in front or behind ALL sprites, while the PCE allows any sprite to be behind or in front of the entire BG plane without any per-tile priority control.

And for the SMS vs the NES, it's a pretty good feature. I mean, relative to these 8bit systems, it's not uncommon to have large areas of no detail (just solid color). But relative to the PCE, since there is no second BG layer - sprites are quite often used to push BG detail on a single pixel level/basis above other sprites. In the SMS method, you can't do that. And with the PCE's sprite bandwidth relative to the NES/SMS, it makes sense in that context. If I had to chose between the NES and the SMS system, and the priority level relative to BG layer... I'd probably go with the SMS. It makes more practical sense in that situation. The limited scanline sprite bandwidth makes is almost impractical as an option.

There's also the separate issue of PCE tiles not supporting flipping (but with sprites supporting horizontal flips -not sure about vertical) while the SMS has no sprite flipping, but does have tile flips (at least horizontal, I forget about vertical).

The PCE has more vram to work with (64k vs 16k), so it's not a big deal comparatively speaking (SMS small vram is much more limiting). And the more unique detail you have, the less tile flipping comes into play. I could think of more important features I would add to the tilemap 16bits for each entry other than tile flipping. Like a single bit that would cause the upper 8 colors in that specific a tile reference to be higher priority than high priority sprites. And some other features I forget now :P

[kool kitty89]

The PCE has more vram to work with (64k vs 16k), so it's not a big deal comparatively speaking (SMS small vram is much more limiting). And the more unique detail you have, the less tile flipping comes into play. I could think of more important features I would add to the tilemap 16bits for each entry other than tile flipping. Like a single bit that would cause the upper 8 colors in that specific a tile reference to be higher priority than high priority sprites. And some other features I forget now :P

The SMS can't flip sprites though, and (as has been mentioned in a previous thread) that's a much bigger issue than non-flipping tiles. (many, many sprites need to face both directions regardless of art design -save for the odd case of wanting an asymmetrical object . . . Segat would apply there except SFII -at least the 16-bit gen home ports- do just flip the sprites so his eye patch changes sides )


On another note, if the PCE had actually supported a true 2bpp mode (not just realtime unpacking by the VDP), be it 1 or 2 BG layers, you'd use half the VRAM anyway at the expense of 4 colors per tile. (if they HAD implemented a dual layer 2bpp BG mode, it probably would have made the most sense to use 4 separate subpalettes per layer rather than 4 shared ones -since you've already got the CRAM for 64 4 color palettes; for that matter, for a 2bpp sprite mode, they could have segmented the sprite CRAM into 4 separate banks of subpalettes which different groups of the 64 sprites would be able to use)

[tomaitheous]

On another note, if the PCE had actually supported a true 2bpp mode (not just realtime unpacking by the VDP), be it 1 or 2 BG layers, you'd use half the VRAM anyway at the expense of 4 colors per tile. (if they HAD implemented a dual layer 2bpp BG mode, it probably would have made the most sense to use 4 separate subpalettes per layer rather than 4 shared ones -since you've already got the CRAM for 64 4 color palettes; for that matter, for a 2bpp sprite mode, they could have segmented the sprite CRAM into 4 separate banks of subpalettes which different groups of the 64 sprites would be able to use)

But it does have real 2bpp modes. Separate bits to enable it for sprites or BG tiles. And on a scanline basis. For sprites, the bit 0 of the address register that's normally ignored is used to select which 2bpp sets to use in a 4bpp set. And for BG tiles, you have to use an Hint routine to change the 'bank' CG bit for which 2bpp to use for the BG output. I had plans to hack the Space Harrier port for PCE to enable the BG floor, just past the far scrolling layer, to be set to 2bpp mode and make the floor like the Genesis and arcade version. Since there's enough free vram for a 2bpp floor in the game.

[kool kitty89]

But it does have real 2bpp modes. Separate bits to enable it for sprites or BG tiles. And on a scanline basis. For sprites, the bit 0 of the address register that's normally ignored is used to select which 2bpp sets to use in a 4bpp set. And for BG tiles, you have to use an Hint routine to change the 'bank' CG bit for which 2bpp to use for the BG output. I had plans to hack the Space Harrier port for PCE to enable the BG floor, just past the far scrolling layer, to be set to 2bpp mode and make the floor like the Genesis and arcade version. Since there's enough free vram for a 2bpp floor in the game.

Hmm, for some reason I remember you describing the 2bpp modes in the PCE as padding 2bpp planar data to 4bpp as it was put into VRAM. (not sure why I remember that, maybe I'm mixing something up)

There's no sprite/tile bandwidth advantages to using 2bpp mode, right? (would have been neat if it doubled sprites per line or something )

On that note, a 2bpp mode could have been even more useful for the SMS given the limited VRAM, or even 1bpp support could have been useful. (after all, the original TMS9918 VDP was designed around 1bpp sprites and playfield, but still had 16 kB of DRAM for video -some 6 years before the Mk.III was introduced)

[TmEE]

I think this was addressed before, but the MD can't switch between H32 and H40 in hblank or vblank without major graphical glitches on-screen, right? (otherwise that would be pretty useful for extending DMA bandwidth for lower res games -or for cases where you'd want different resolutions on different lines)

No, I meant the line consist of both H40 and H32 wide pixels, pixel clock is not constant on the line, it changes at one point. It is constant in H32 mode, but not in H40

[Stef]

Why would you need to change banks at any time rather than regular intervals? Couldn't you maintain a constant sample (and data) rate for every sample in ROM, but then scale the samples (and vary loop times for looping samples) after they've been buffered into Z80 RAM?

I don't see how you can efficiently buffer sample to Z80 ram. Also the Z80 ram is quite limited, how much bytes you want to pre buffer ? If we have 4 samples to mix together, we can barely buffer 1Kb for each sample which isn't much. Also how can you update these buffers quickly enough ? if we're playing at very high rate (thinking about 8 times the base frequency) then you need to buffer 8 times the size actually played...
I think we have to read with direct scaling from ROM with Z80 but then the Z80 bank update becomes a complex stuff to handle without having large data alignment (and so we still can keep buffering).

If you did want to mix samples that actually used different data rates, but didn't care about note quality pitch control, perhaps limiting sample/data rates of samples to regular steps (like 4, 8, 16, kHz, etc) and interleaving the samples and using simple integer scaling to match the output rate.

Get the idea but i think you can not use that to play / compose music. It's more important to get a good pitch control, the playback rate is maybe less important here...

Can you at least get better quality than 4-bit PCM? (or if the added step sizes facilitated it, it might be more efficient -in terms of bitrate and SNR- to use a rudimentary 4-bit ulaw like scheme to map 4-bit samples into the 3xPSG channel amplitude range, or just a 4-bit per sample format mapped to PSG values as close to linear as possible -but then you'd definitely get no better than 4-bit PCM quality)

Given what Tiido mentioned about the YM2612 volume modulation route, PSG is probably a better option if anything.

Unfortunately no, you get get anything better from PSG than a simple 4 bit PCM... and i expected the YM2612 FM channels doesn't bring much here :-/
I think we have to stay with the DAC to get correct quality and so, have to do software mixing whatever we do.

The idea would be several channels (ie 2 or 3) with fixed pitch playback (for SFX, percussion, etc) and 1 channel for playing notes with a sampled instrument. (obviously something that can't be produced with 4-op FM adequately)

Yeah, if we can't handle severals modulated pitch channels so maybe one is already not that bad (if we can handle FM, PSG and maybe 1 or 2 fixed pitch channels aside it).

Ah, so it's a bit like the format used in SMPS (but presumably with a different delta table more optimized for the high sample rate on top of the 8-bit range limit -or possibly limited to 7-bit output to better optimize for adding 2 channels to 8-bits).

Yeah i guess it's something similar to SMPS, except i allow 2 channels to be played simultaneously and at 22 Khz (i think it's less with SMPS).
Unfortunately that eats all Z80 time (a lot is wasted in synchronization though).
In all my drivers i use real 8 bits samples, i think it's very important to not loss quality as we have something really poor to start with.

[Sik]

If we have 4 samples to mix together, we can barely buffer 1Kb for each sample which isn't much.

It isn't much? Echo's sample rate is 10250 Hz, and 1Kb would hold over 1/10th of a second (over 6 NTSC frames). Are you sure that isn't much?

1KB isn't a good size anyways. If you want to keep performance, you probably shouldn't go over 256 bytes, so you don't need to update the high byte of the address (which will eat up some extra cycles).

EDIT: remember that buffering is done to speed up the code, not to avoid ROM access like crazy. Eventually it'll reach a point that you've buffered so much it doesn't provide any serious speed gain to be worth the effort.

In all my drivers i use real 8 bits samples, i think it's very important to not loss quality as we have something really poor to start with.

As soon as you start mixing you're screwed anyways. Either you mix two 8-bit samples and get a 9-bit output (and doing that as-is will require you to use slow 16-bit operations) or you downsample the values before hand so you get two 7-bit samples adding up to 8-bit (which is faster to process).

It really depends anyways. A smaller sample range will make you lose some control over volume, but in practice the shape of the waveform is much more important, so you could do e.g. 6-bit and still get something that sounds decent. In practice the sample rate matters more.

[Stef]

It isn't much? Echo's sample rate is 10250 Hz, and 1Kb would hold over 1/10th of a second (over 6 NTSC frames). Are you sure that isn't much?

1KB isn't a good size anyways. If you want to keep performance, you probably shouldn't go over 256 bytes, so you don't need to update the high byte of the address (which will eat up some extra cycles).

EDIT: remember that buffering is done to speed up the code, not to avoid ROM access like crazy. Eventually it'll reach a point that you've buffered so much it doesn't provide any serious speed gain to be worth the effort.

Of course i myself use 256 bytes buffer for mixing and is more than enough but in case you want variable pitch playback then 1 KB isn't that much (i was speaking about pre buffer, not just mixing buffer) : if the base sample frequency is 440 Hz and you want to play a 3520 Hz note (3 octaves up) then you eat your 1 Kb buffer faster than fixed 256 bytes one...

As soon as you start mixing you're screwed anyways. Either you mix two 8-bit samples and get a 9-bit output (and doing that as-is will require you to use slow 16-bit operations) or you downsample the values before hand so you get two 7-bit samples adding up to 8-bit (which is faster to process).

It really depends anyways. A smaller sample range will make you lose some control over volume, but in practice the shape of the waveform is much more important, so you could do e.g. 6-bit and still get something that sounds decent. In practice the sample rate matters more.

If you use 8 bits samples you actually lose quality *only* when overflow occurs and even with 4 channels, this doesn't happen often.
And you can use 8 bits instruction, you need to directly test overflow flag and use a simple trick to limit sample :

            LD      A, (BC)        ; source sample       
            ADD     (HL)           ; mix                  
            JP      PO, .ok         ; check overflow  

            LD      A, $7F          ; limit
            ADC     $0              ; A = $7F/$80 (depend if negative or positive)

.ok
            LD      (HL), A        ; write sample in buffer
            INC     L                ; next

I do need to use signed samples here which i unsign right before sample output.
Of course this slow down quite a bit the mix process (you can improve speed by caching constants values in registers) but i don't mind, i really don't like use 6 bits samples which sound really quiet.

[Kamahl]

Since I don't understand the slightest thing about audio, I'll just post this:

[Sik]

Of course i myself use 256 bytes buffer for mixing and is more than enough but in case you want variable pitch playback then 1 KB isn't that much (i was speaking about pre buffer, not just mixing buffer) : if the base sample frequency is 440 Hz and you want to play a 3520 Hz note (3 octaves up) then you eat your 1 Kb buffer faster than fixed 256 bytes one...

The problem here probably is that you want to buffer to avoid bank switching, but you seem to forget that mixing in itself is going to eat up a lot of processing resources. If you just pre-buffer samples into memory and then mix on-the-fly, you're screwed because you need to change the full pointer four times every time you mix a single sample.

A better idea would be to buffer the mixing itself. Take one of the channels, then "play" it into a buffer, then take the next channel, and "play" it mixing it with what's buffered, then do the same with the other two channels. The end result is that you mixed several samples, only doing full pointer changes four times (since when reading several samples in a row from a waveform you only need to increment the current pointer, which is faster than loading a whole new pointer).

If you use 8 bits samples you actually lose quality *only* when overflow occurs and even with 4 channels, this doesn't happen often.

But it happens, and you won't know when it happens, and if it happens and you don't clamp the result, the outcome will be a complete disaster since the waveform will be transformed into something else entirely (not to mention all the sudden noise!).

Of course this slow down quite a bit the mix process (you can improve speed by caching constants values in registers) but i don't mind, i really don't like use 6 bits samples which sound really quiet.

The idea is to do the mixing with 6-bit samples and only then amplify the result so it's at the right volume, d'oh (you can even get a look-up table for this, which as a nice extra can be used to avoid sudden clamping, as shown in this image)

And I'll beat Kamahi with this:


Seems impressive at first until you learn how it actually works...

EDIT: ugh, fixed YouTube tag x_x And OK, by impressive I was talking about the video, the audio part is still probably impressive (I think it's compressed audio). A newer version takes a completely different approach to audio rendering, but it completely screws it up...

[Stef]

Yeah i already saw this video, quite impressive still we easily see the resolution is quite low with fast movement then it becomes almost native (i mean 320x224) when element doesn't move anymore... i understand the logic, still it's really nicely done =)

[slobu]

I can hardly hear the stereo sound when playing Shove-It so all this talk about killerhurtz and YMCA compression confuses and angers me.

THAT last video Kamahl posted though nearly gave me a 42-ounce vodka buzz. Slobu approves!