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

[kool kitty89]

Well this turned into a Genesis PCM discussion despite my best efforts, but I've found the next theme, what's this talk about it being possible to do 2 backgrounds in mode-7?

Good call, here's the quote I mentioned in the other thread:

When bit 6 of $2133 is set, you get a related mode known as Mode 7 EXTBG. In this mode, you get a BG2 with 128 colors, which uses the same tilemap and character data as BG1 but interprets the high bit of the pixel as a priority bit. The priority map is:

Sprites with priority 3
Sprites with priority 2
BG2 pixels with priority 1
Sprites with priority 1
BG1
Sprites with priority 0
BG2 pixels with priority 0

Note that the BG1 pixels (if BG1 is enabled) will usually completely obscure the low-priority BG2 pixels.

BG2 uses the Mode 7 scrolling registers ($210d-e) rather than the 'normal' BG2 ones ($210f-10). Subscreen, pseudo-hires, math, and clip windows work as normal; keep in mind OBJ and that you can do things like enable BG1 on main and BG2 on sub if you so desire. Mosaic is somewhat weird, see the section on Mosaic below.

Note that BG1, being a 256-color BG, can do Direct Color mode (in this case, of course, there is no palette value so you're limited to 256 colors instead of 2048). BG2 does not do direct color mode, since it is only 7-bit.

http://wiki.superfamicom.org/snes/show/Backgrounds
http://www.neviksti.com/wiki/Hardware_Registers#Mode_7

The YouTube video is somewhere between 0.5 and 0.6, actually. It looks like 0.6 but sounds like 0.5 (both 0.4 and 0.5 have jittering all over the place, 0.6 doesn't).

It's hard to bet on YT displaying the jittering accurately, but the sound in the videois definitely off (distorted) compared to what I hear in fusion. (unless it's an issue with the MD being used for the video)

Honestly, I think it's trying to play PCM through a FM channel... That's why it's a bad idea to even think about doing PCM through FM =P

Oh . . . why???

That would also explain the crappy PC8801 examples, though you'd think developers would be smart enough to realize the SSG channels (a la YM2149) would work far better for sample playback (even without the 2 or 3 channel look-up output method).
Likewise, using the MD PSG for samples would have been more realistic than the FM channels. (which was basically stated a few posts back)

Too bad Yahama FM chips can't do what Atari's AMY chip could. (actually more primitive than FM in a number of ways -limited to additive synthesis via 64 sine wave oscillators, but only 8 frequency ramps -the rest being amplitude ramps, but Amy could effectively be used as a lossy digital audio decoder with extremely high compression ratio -intelligible speech at 2.4 kbps)

Edit: wait, or could FM chips be used for a sort of sub-band coded audio format by using multiple FM channels (similar to what Amy can do)?

Didn't you know? It's illegal to have a technical discussion on MD hardware unless it's about how to do sample mixing and compression on the Z80, especially once Kool Kitty is involved.

Well, there's also video compression, software rendering (various), impact of various design choices of the system (sacrificing VDP die space for the SMS logic, leaving the VDP pixel bus off the cart and expansion ports, etc), use of FM (or sound engines in general -apart from PCM), among other things. (not to mention what-could-have-happened-if type discussions -especially on the, SVP, 32x, CD, and Saturn- )

PCM has been coming up a lot recently though.

[tomaitheous]

When bit 6 of $2133 is set, you get a related mode known as Mode 7 EXTBG. In this mode, you get a BG2 with 128 colors, which uses the same tilemap and character data as BG1 but interprets the high bit of the pixel as a priority bit. The priority map is:

Sprites with priority 3
Sprites with priority 2
BG2 pixels with priority 1
Sprites with priority 1
BG1
Sprites with priority 0
BG2 pixels with priority 0

Note that the BG1 pixels (if BG1 is enabled) will usually completely obscure the low-priority BG2 pixels.

BG2 uses the Mode 7 scrolling registers ($210d-e) rather than the 'normal' BG2 ones ($210f-10). Subscreen, pseudo-hires, math, and clip windows work as normal; keep in mind OBJ and that you can do things like enable BG1 on main and BG2 on sub if you so desire. Mosaic is somewhat weird, see the section on Mosaic below.

Note that BG1, being a 256-color BG, can do Direct Color mode (in this case, of course, there is no palette value so you're limited to 256 colors instead of 2048). BG2 does not do direct color mode, since it is only 7-bit.

If the BG layer uses the same tilemap and same scroll registers, then how is it a separate layer? Seems to me, that once the PPU fetches the tile data, from the map and scroll offset and scale/rotation transform, that all it does is interpret the high bit of the tile data that was already fetched into cache/buffer. I.e. it's not real separate layer.

[Stef]

Edit:
Wait . . . I'm thinking about this wrong. I was thinking about scaling a fixed number of samples rather than scaling some variable number of samples (depending on desired pitch) to be scaled to a fixed buffer length at the output sample rate (so a lower pitch would need fewer unscaled samples while higher pitch would need more unscaled samples -but both would end up with the same number of samples for the final mixing buffer).
If you could manage to scale the sample while reading it from ROM, you could avoid the added buffer space, but you'd definitely eat up more space if you had to prebuffer the unscaled sample. (more so for larger buffer lengths)

Ah, now I see the issue of needing to switch banks at inconsistent intervals . . . unless perhaps you set it up to cater to the highest pitch you'd ever be playing and add additional waits for lower pitches. (time spent reading out more samples at high pitches would be spent idle until the point where the sample would normally be finished reading for the highest pitch -and, obviously, if you were to use a prebuffer, you'd need to reserve enough space to buffer the highest pitch sample as well)

In that case, you could arrange it such that the highest desired pitch is at the unscaled sample rate (as-is in rom), and only scale down for lower pitches. (thus avoiding the need for extra-long pre-buffering)

And so you understand now why it's that difficult to handle that.
Taking the highest pitch sample in rom will result in very bad quality for low pitched sample :-/ I think usually the base sample (for quality reason) is taken at low pitch. I already think about a method where the base sample use "medium" pitch, let's say 440 Hz. Then we limit the max high pitch to 440 Hz * 2 * 2 * 2 = 3520 Hz.
So from the standard sample, the highest pitch would need a x8 read step. So if my sample is basically aligned to 256 bytes (as its size) then i could reduce the buffering to 256 / 8 = 32 bytes loop and be sure the Z80 bank didn't changed during loop. Still there is some problems as the end sample test which need to be done at each sample :-/

Huh. I knew the SN76489 was a worse case than the AY8910/YM2149 (coarser volume steps, 16 vs 32 steps per channel, etc), but I'd thought you could at least manage better SNR than 4-bit linear PCM. (with semi-optimized conversion to the AY8910, you at least get somewhat close to 8-bit PCM level SNR -technically it's possible to achieve better SNR than true 8-bit linear PCM with highly optimized conversion, but that's not the sort of thing you'd see outside of very specialized demos -ie not the sort of thing Atari ST Mod players would be doing)
Hell, doing single channel 4-bit nonlinear PCM on the AY sounds fairly decent (as per in-game drums/speech/SFX that don't cut out music on the ST -etc- or the 3 channel sample tracker on the Speccy).

I'd have thought the SN chip would at least manage something close to 6-bit PCM in terms of SNR if using all 3 channels. (of all those 816 possible unique combinations, I'd have thought it could do better than 16 linear amplitude steps)

Honestly i didn't intensively tested the PCM playback on PSG, my goal was initially to get easy 3 channels playback, so i stay with standard 4 bits PSG env level to simulate 4 bits PCM but it sounded really crappy and i didn't gone farther... maybe you can achieve descent PCM playback by combining the 3 available PSG channels but then you will waste some Z80 time only to get 1 single PCM channel. Anyway it could be interesting to test just to see if we can get better output quality than using DAC.

So you use the same set of delta values too, or different? (SMPS uses 0, 1, 2, 4, 8, 16, 32, 64, -1, -2, -4, -8, -16, -32, -64, -128) I'd imagine it would make more sense to use finer steps between deltas (with lower max deltas) to cater to the higher sample rate and 8-bit range limitation.

Exactly my delta are somewhat adjusted :
-34, -21, -13, -8, -5, -3, -2, -1, 0, 1, 2, 3, 5, 8, 13, 21
As you can see i have better low resolution in low delta and less for high ones... This give good results for general music with beats but less good for multi voices samples.

Tiido uses 7-bit samples for his 2 channel 22 kHz driver . . . but he preprocesses everything to boost volume and optimize for low res PCM in general. (to the point of modest -viarually inaudible- clipping in some areas of unmixed samples)
Such optimization, if done at full 8-bits could result in significantly audible clipping in the final output (since you've already boosted the signal to tend towards the upper limits of the 8-bit range), unlike unoptimized (directly scaled) 8-bit PCM where there's a lot that stays well below the 7-bit boundary, let alone threatening to hit the 8-bit boundary.

I'm also modify my sample so even with pure 8 bits samples i normalize them to -0.3 db... giving good dynamic and even with that i obtain limited clipping. Of course you get more if you're playing 4 loud samples at same time but really i think it's quite reasonable.

[kool kitty89]

If the BG layer uses the same tilemap and same scroll registers, then how is it a separate layer? Seems to me, that once the PPU fetches the tile data, from the map and scroll offset and scale/rotation transform, that all it does is interpret the high bit of the tile data that was already fetched into cache/buffer. I.e. it's not real separate layer.

What good is that then?
If it could be scrolled (and rotated) independently, even with a shared tilemap, you could at least have cases where 2 effectively separate objects could be displayed. (by placing them at opposite corners of the tilemap grid and displaying each such that only 1 object is ever visible on-screen for each plane) But with both sharing scroll offsets, that makes it pretty useless.

I suppose it could be useful for allowing per-pixel priority to allow parts of the BG to go in front of sprites and other parts behind (and on a pixel basis, not tile).

[Stef]

I did a quick test with my 22 Khz 4 bits (A)DPCM driver :

BadApple!!

Quality is really not good for voices, i think i should change to real ADPCM to have better handling of high frequency with high amplitude...
Also playback can be a bit fast on emulator, it's better on real hardware where it's almost match 22 Khz.

[Chilly Willy]

I did a quick test with my 22 Khz 4 bits (A)DPCM driver :

BadApple!!

Quality is really not good for voices, i think i should change to real ADPCM to have better handling of high frequency with high amplitude...
Also playback can be a bit fast on emulator, it's better on real hardware where it's almost match 22 Khz.

Not bad. 4-bit sounds much better than 2-bit. It's to be expected that singing will result in more noise as it's trying to replicate a more complex waveform. You hear the same thing in my CVSD example - the music sounds pretty good alone, but the moment the singing starts, the noise level increases noticeably.

[kool kitty89]

Honestly i didn't intensively tested the PCM playback on PSG, my goal was initially to get easy 3 channels playback, so i stay with standard 4 bits PSG env level to simulate 4 bits PCM but it sounded really crappy and i didn't gone farther... maybe you can achieve descent PCM playback by combining the 3 available PSG channels but then you will waste some Z80 time only to get 1 single PCM channel. Anyway it could be interesting to test just to see if we can get better output quality than using DAC.

I wouldn't expect good results from plain 4-bit volume modulated PCM channels using the PSG . . . (unsigned) nonlinear amplitude will leave that being considerably worse than 4-bit linear PCM (too bad Sega didn't use a PSG with 4-bit linear volume like Atari's POKEY or the NES -or the lynx's 4 PSG channels with 8-bit linear volume ).
The SN76489 is a good bit worse off for that over the AY8910 as well due to the coarser volume steps (though AY is still worse than 4-bit linear PCM).

I'm honestly surprised that Afterburner sounds as good as it does just using single PSG channels (better than some of the poorer PCM using the DAC even). They certainly did a good job optimizing the conversion to such a limited output method.

I also doubt you'd ever manage better quality than true 8-bit PCM using multi-channel PSG playback. The more capable AY chip only managed that in combination with very intensive preprocessed optimized conversion using Viterbi search. The traditional method (and the one used by most Atari ST mod players) uses a simple look-up table conversion method: there's two possible routes for this, 1. conversion of true linear PCM to PSG on the fly (the only practical option if you're using the PSG as a DAC to mix multiple channels -though you could opt to mix to a higher res than 8-bits, with correspondingly larger LUT), or 2. you could take a high resolution sample and optimally convert it to a custom format for the PSG that avoids additional rounding errors or redundant values (an 8-bit sample maps to 256 unique amplitude values, though not perfectly linear), or you could potentially map to values beyond an 8-bit linear range in general. (like having an 8-bit ulaw like format customized for the PSG) The more capable examples would use the full 5-bit logarithmic volume range per channel, but I believe some limited it to just 4-bits. (still better than the SN due to smaller steps between each volume level)
Such look-up methods also impart noise to the samples since the 3 channels are updated in series, not simultaneously. (more complicated look-up tables were sometimes implemented to minimize that noise by selecing the optimal order to update the 3 channels in based on the current volume settings and the one it's to be changed to -but those are large tables which wouldn't be practical for the MD Z80 to use in any case, and I don't think they're very common on the ST even)

The SN PSG could use the same methods, but definitely limited to 4-bits and with generally lower peak quality. It's unlikely that you'd truly manage much (if any) better SNR than plain 8-bit linear PCM even with the most optimal conversion. Still, it should be possible to do far better than a single channel and perhaps reasonablyclose to 8-bit PCM quality. (more so if you used it as a single channel without mixing -thus allowing an optimized custom format to be used rather than approximated linear PCM)
That would also be the only option for doing multi-channel PCM without scaling (though you'd have the overhead of look-up and writing to 3 channels).
If used at all, it might be preferable to use the PSG as the variable playback rate channel (for notes) with the DAC used for mixing additional fixed rate samples.

You've probably heard similar examples before, but here's some stuff to consider as far as the AY8910 is concerned (again, a better case than the SN, but still somewhat useful for comparison)
http://ym-digital.i-demo.pl/music.html (all done on stock Atari STs)
And obvious various demos in games and such, like Turrican II (probably one of the best examples used in games)
http://www.youtube.com/watch?v=g4Uy69Jjk9M

And perhaps more interesting is the independent channel 4-bit nonlinear playback using the AY in the Spectrum's 3 channel sample tracker. (actually, I'm not positive it's just simple 4-bit PSG samples -ignoring one of the 5 volume bits- but might instead use look-up to map 4-bits to the most useful 16 values of the full 5-bit range -they're definitely stored as 4-bits per sample in memory, that much I know)

One thing interesting about these is that they're all on Speccy 48ks, so the same amount of memory (and similar CPU resource) as you'd have with the MD Z80 using a single 32k bank of ROM.
http://www.youtube.com/watch?v=j4aEHXpRaUg

http://www.youtube.com/watch?v=rLqHVv7V1DY

http://www.youtube.com/watch?v=2yuTusrb1Xc

http://www.youtube.com/watch?v=JWbIv_bMyBQ

Exactly my delta are somewhat adjusted :
-34, -21, -13, -8, -5, -3, -2, -1, 0, 1, 2, 3, 5, 8, 13, 21
As you can see i have better low resolution in low delta and less for high ones... This give good results for general music with beats but less good for multi voices samples.

Perhaps something between that and SMPS's delta range. (SMPS uses some pretty large deltas for something aiming at decompressing to 8-bits)
Heh, if you just averaged SMPS and your current table, you'd get (with some rounding) -81, -42, -22, -12, -7, -4, -2, -1, 0, 1, 2, 4, 7, 12, 42.

I did a quick test with my 22 Khz 4 bits (A)DPCM driver :

BadApple!!

Quality is really not good for voices, i think i should change to real ADPCM to have better handling of high frequency with high amplitude...
Also playback can be a bit fast on emulator, it's better on real hardware where it's almost match 22 Khz.

Hmm, would you still be able to manage 2 22 kHz channels if doing true ADPCM?

As for emulators, there's also the issue of GENS only going up to 16 kHz for the DAC, and Fusion 19.4 kHz iirc. (the missed samples aren't too bad in Fusion, but really noticeable in GENS -more so for Tiido's 26 kHz demo )

Do you compress samples from preprocessed/optimized 8-bit PCM sample streams? (I know chilly willy's formats encode from 16-bit PCM, but those also decode to 16-bits and output only the upper 8-bits, so that's a different case in general)

Not bad. 4-bit sounds much better than 2-bit. It's to be expected that singing will result in more noise as it's trying to replicate a more complex waveform. You hear the same thing in my CVSD example - the music sounds pretty good alone, but the moment the singing starts, the noise level increases noticeably.

You still don't have an optimized example of the 2-bit format to compare, do you? (so it should be closer than the current examples)

Also, which of your demos have singing in them? (do you mean the limited choral parts in the sonic tracks?)

[Sik]

As for emulators, there's also the issue of GENS only going up to 16 kHz for the DAC, and Fusion 19.4 kHz iirc. (the missed samples aren't too bad in Fusion, but really noticeable in GENS -more so for Tiido's 26 kHz demo )

An even worse issue with Gens is the YM2612 timers, which happens to have a huge impact in Echo. See, the issue is that Gens only updates the status of the timers every scanline. Echo uses timer A for timing of PCM samples. It needs a timer tick every ~1.5 scanlines. Thereby, in Gens it'll end up getting a tick every 2 scanlines. You can imagine where it's going...

No idea if Stef is using the timers but it's something to take into account.

[Stef]

Not bad. 4-bit sounds much better than 2-bit. It's to be expected that singing will result in more noise as it's trying to replicate a more complex waveform. You hear the same thing in my CVSD example - the music sounds pretty good alone, but the moment the singing starts, the noise level increases noticeably.

Yeah as soon waveform becomes complex the DPCM compression kills the thing but i think i can improve easily that point by using severals delta tables. The draw back will certainly be a lower playback rate (i can't maintain 22 Khz for 2 channels with variables deltas).

I wouldn't expect good results from plain 4-bit volume modulated PCM channels using the PSG . . . (unsigned) nonlinear amplitude will leave that being considerably worse than 4-bit linear PCM (too bad Sega didn't use a PSG with 4-bit linear volume like Atari's POKEY or the NES -or the lynx's 4 PSG channels with 8-bit linear volume ).
The SN76489 is a good bit worse off for that over the AY8910 as well due to the coarser volume steps (though AY is still worse than 4-bit linear PCM).
...
That would also be the only option for doing multi-channel PCM without scaling (though you'd have the overhead of look-up and writing to 3 channels).
If used at all, it might be preferable to use the PSG as the variable playback rate channel (for notes) with the DAC used for mixing additional fixed rate samples.

Ok so we agree the PSG won't sound any good compared to the DAC even by doing the best conversion on 3 PSG channels...
So it offers an extra PCM but it has a price, let's see the good point and the bad point :
+ no need of Z80 software mixing for 2 channels PCM playback :
+ more Z80 time
+ less memory used (no more buffering) for a second sample play.
- quality probably not as good than using software mixing with DAC.
- require some lookup table and Z80 processing to achieve (maybe not as much than mixing though).
- can't use anymore PSG for anything else.

Conclusion : not sure it deserves it compared to a classic software mixing...

Perhaps something between that and SMPS's delta range. (SMPS uses some pretty large deltas for something aiming at decompressing to 8-bits)
Heh, if you just averaged SMPS and your current table, you'd get (with some rounding) -81, -42, -22, -12, -7, -4, -2, -1, 0, 1, 2, 4, 7, 12, 42.

Yeah, i should do some tests on a good set of samples to see which table is preferable

Hmm, would you still be able to manage 2 22 kHz channels if doing true ADPCM?

As i said previously i don't think so, i already have very limited free time and i'm not sure i can still keep the 22Khz rate. Anyway maybe 22Khz is a bit up, requiring 88 Kbits/s... but it's a standard output rate... 16 Khz offers nice quality and will lower bitrate to 64 Kbits/s and the variable delta rate will avoid important compression degradations.

As for emulators, there's also the issue of GENS only going up to 16 kHz for the DAC, and Fusion 19.4 kHz iirc. (the missed samples aren't too bad in Fusion, but really noticeable in GENS -more so for Tiido's 26 kHz demo )

Yeah i know, for Gens this is related to simple way of updating DAC (every scanline), not sure about Fusion though...
Anyway the main problem is also playback rate which isn't the same between emulator and real hardware, this is mainly due to the delay when you access ROM from Z80. On real hardware the Z80 share BUS time with 68k and so each access can be delayed to some cycles. In my driver i assume a 2 cycles penalty for each ROM access, also giving my cycles count to 22 Khz, i always round to the pessimist case... generally it gives good result on real hardware but too high pitched on emulators.

Do you compress samples from preprocessed/optimized 8-bit PCM sample streams? (I know chilly willy's formats encode from 16-bit PCM, but those also decode to 16-bits and output only the upper 8-bits, so that's a different case in general)

The only optimization i do before compression is a normalization to -0.3 db..

An even worse issue with Gens is the YM2612 timers, which happens to have a huge impact in Echo. See, the issue is that Gens only updates the status of the timers every scanline. Echo uses timer A for timing of PCM samples. It needs a timer tick every ~1.5 scanlines. Thereby, in Gens it'll end up getting a tick every 2 scanlines. You can imagine where it's going...

No idea if Stef is using the timers but it's something to take into account.

No, i don't use timers for PCM playback
Testing for timer is just some cycles lost and the granularity isn't good enough for PCM playback at a given rate.
I'm just counting Z80 cycles, that not a perfect solution but needed to gain some cycles

[Sik]

Yeah, but I need to use the timer because Echo is a Z80-only sound engine and thereby the Z80 is busy doing lots of other stuff (parsing stream data to control FM, PSG, etc.), and as you can imagine all those tasks take an unpredictable amount of time (not to mention that some are longer than a sample so Echo has to test for new samples while it's already doing other stuff).

[Chilly Willy]

You still don't have an optimized example of the 2-bit format to compare, do you? (so it should be closer than the current examples)

Also, which of your demos have singing in them? (do you mean the limited choral parts in the sonic tracks?)

I only did one 2-bit example. I did optimize the 1-bit example to do better encoding, but never got around to improving the 2-bit.

musicdemo used songs with vocals and was 1 bit / smp
musicdemo2 used Sonic CD tracks and was 2 bits / smp
musicdemo3 used Sonic CD tracks + one song with vocals and was my improved 1 bit encoder
musicdemo4 used Sonic CD tracks and was my version of Tiido's TADPCM format (3 bits per sample)
musicdemo5 (not sure I ever released this one) was an attempt to apply TADPCM principles to my 2 bit format, but wasn't noticeably better than TADPCM
musicdemo6 used Sonic CD tracks + one song with vocals and was an even more improved 1 bit encoder

[Stef]

Yeah, but I need to use the timer because Echo is a Z80-only sound engine and thereby the Z80 is busy doing lots of other stuff (parsing stream data to control FM, PSG, etc.), and as you can imagine all those tasks take an unpredictable amount of time (not to mention that some are longer than a sample so Echo has to test for new samples while it's already doing other stuff).

Of course, it's more natural doing this way. And i would do it too if i could, to make the code simpler (no more need to do nop or nasty operation to waste cycles and get good sample synchronization). Also how you handle the case when a task take too many time and you missed the timer latch ? i mean, can you detect about how late you are and then bypass some samples ?

[Sik]

Also how you handle the case when a task take too many time and you missed the timer latch ? i mean, can you detect about how late you are and then bypass some samples ?

When this happens you're screwed, period =P This is why I say that the YM2612 timers lacking a looping mode adds to inaccuracy, there's no way to avoid it with the hardware available. There's a good reason why Echo samples are declared to be 10250 Hz even though timer A is set to run at 10650 Hz.

The other option is to interrupt all PCM playback during stream processing and then have PCM done with a busy loop. This is what both SMPS/Z80 and TMSE do (and why SMPS/Z80 runs off the vblank IRQ). In order for this to work though you need to be really fast processing stream data or the cutting will be very noticeable.

Ironically, out of all sound engines, the one that takes the same approach as Echo is... GEMS.

[Kamahl]

GEMS has pretty good PCM.

[Sik]

But very shitty timing. The reason being that it needs to load a full FM instrument every time a note plays, and that's an awfully expensive operation. Needless to say, that results in massive slow down, which is why so many people hate it.

Channel allocation may have seen like a good idea to take the technical burden off musicians but it did more damage than good. I'm pretty sure composers would have easily understood that they're limited to a given amount of channels =/