PCM player using SCC

صفحة 11/33
4 | 5 | 6 | 7 | 8 | 9 | 10 | | 12 | 13 | 14 | 15 | 16

بواسطة nikodr

Paladin (748)

صورة nikodr

22-10-2007, 20:06

Could this decoding of samples be used for games?Example is an adventure game,that could be installed on hard disk to have samples there...Would it work?In that way games could have speech or other cool effects...

بواسطة dvik

Prophet (2200)

صورة dvik

22-10-2007, 20:10

nikodr, Yes it can. NYYRIKKI gave some preliminary numbers that show that with sample frequencies around 3kHz its possible to use line interrupts to play the samples and there will be quite a lot of cycles left for actual game.

I was thinking of it yesterday and it would be possible to do a simple re-player that can play sampled music on one channel and sfx on another. More advanced replayers, like mod players is also possible but then I don't think it will be as much cpu left for the actual game.

بواسطة nikodr

Paladin (748)

صورة nikodr

22-10-2007, 20:13

For a turbo-r would those numbers be different?

بواسطة dvik

Prophet (2200)

صورة dvik

22-10-2007, 20:21

probably not. when you want to use an interrupt driven player, the main limitation is the region in VBLANK when you can't issue line interrupts.
When it comes to more advanced replayers, such as mod players, a TR would of course be beneficial.

بواسطة ARTRAG

Enlighted (6923)

صورة ARTRAG

22-10-2007, 20:25

Well, this current technique is good for MSX2 with 4-5 line interrupts per frame, quite a lot even if it allows
up to 3 wav file to be played at the same time.

The other possibility (for MSX1 e.g.) is to develop the game in the main wait loop.
In this case all the branches MUST have as max duration 32/Fs. (for 8KHz this is 447*32=14318 Tcycles)
Doable, much more doable than using pcmenc, but limiting.

BTW

I would explore the poliphase approach also (the one using 4 channels for one sample).
With that, you can have sampled voice at 7680Hz and one normal Vblank interrupt per frame.
It can work in any MSX1 with NTSC (!!).
Well, with PAL you would have 6400Hz as Fs, but who cares ?

If the current technique is cool for the "self timing" feature based on HW, the other would be even cooler
for the lower CPU usage and the use to ANY MSX1.

Cool

PS
Dvick, do you want some Matlab files about it Wink

بواسطة dvik

Prophet (2200)

صورة dvik

22-10-2007, 21:14

I think doing the poliphase implementation may be a lot trickier than the current implementation. The problem is getting the phase correct but maybe its just a matter of timing the setting of period very controlled.

Actually using line interrupts will be tricky too, because you have a small drift between the SCC replay frequency and the frame rate. This could potentially be compensated for by for example syncing everything to VBLANK, then busy wait and count the cycles until the rotation wraps so you get the scanline where it wraps. Then schedule HINTs offsetted from the current scanline (which will be different each frame). This way you can also get a higher sampling frequency, by doing two or three updates in VBLANK using busy wait techniques. Something like:

On VINT:
    0. Disable HINT.
    1. busy wait for rotation to wrap
    2. Update samples
    3. Busy wait for another rotation
    4. Update samples
    5. Goto 3 one or more times depending on sample frequency.
    7. calculate current scanline.
    8. Schedule HINT some scanlines later (based on sample frequency)
    9. Start doing background stuff

OnHint:
    1. busy wait for rotation to wrap
    2. Update samples
    3. Schedule HINT some scanlines later (based on sample frequency) 

This can be made to work both in PAL and NTSC. just do enough busy waits.

بواسطة ARTRAG

Enlighted (6923)

صورة ARTRAG

22-10-2007, 21:34

Well, using the 4th channel as pointer to the value currently played
allows you also to decide if update less or more samples according to
the counter value.
My proposal is to have some HINTS in fixed location that copy the table up
to the current "used" position.
At each frame HINTS are at the same fixed position.

Everything works is #HINT*32/frame*50 (or 60Hz for PAL) > Fsample

OnHint:
1) read the current position of the player
2) update only "used" samples
4) set next HINT

OnVblanck:
1) read the current position of the player
2) update only "used" samples
3) reset the HINT line to the beginning of the frame 

Each time HINT copy less than 32 bytes, but any frequency jitter should be
absorbed by the fact that you have more #HINT than strictly required

or not?
Tongue

بواسطة dvik

Prophet (2200)

صورة dvik

22-10-2007, 22:25

.

بواسطة dvik

Prophet (2200)

صورة dvik

22-10-2007, 22:34

Well it may be possible to do a more dynamic update knowing where to start doing the updating. I suppose if you update samples up til but exluding the currently played sample in each interrupt. Then just save the location where you should resume the update on the next int.

بواسطة ARTRAG

Enlighted (6923)

صورة ARTRAG

22-10-2007, 23:05

If you assume more hints than strictly required this will allow you to have HINTs at fix position.
Let me explain, assume 60Hz and Fs = 7680Hz : in this condition 4 HINT would be sufficient.

The screen if 262 lines. Strictly speaking, you should have an HINT each 65,5 lines and write 32 bytes each time. As you cannot have HINTS in the middle of a line, you need more than 4 HINTs

If you allow 5 HINTS, and you update only the used one, some hints you'll copy 25 bytes, some others 26, but in average you'll copy 128 bytes per frame i.e. 7680 per sec

[EDIT]
IMHO
The samples to be updated are those "used" i.e. all those from 0 to the current used position (excluded).

صفحة 11/33
4 | 5 | 6 | 7 | 8 | 9 | 10 | | 12 | 13 | 14 | 15 | 16