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.



PS
Dvick, do you want some Matlab files about it

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.

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?

.

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.

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).

Quote:

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.

According to what I understand, you need to store the position of the last sample updated and start the next update from that position on (cyclically in the buffer).

Moreover you should also reset the ch4 by writing its frequency having set bit 5 in the deformation register.
In this way, next time you read ch4, you get again the number to fample to be written fro that position you stored.

I would avoid resetting ch4. when you do you may loose some fractions of a sample and you'll get out of sync. I think its doable to do without resets. I'm working on it right now. I'll keep you posted.

Yes, you do not need to reset ch4: in this case you simply need to update from the last sample you wrote last time up to the current sample in ch4 (mode 32).

offtopic
I'm examining the output of your previous player, but I cannot see why is needed the +4 offset.
Waveforms seems correct even without +4
more precisely, comparing the plot of the output with the original, they drift of few samples per sec due to the rounding in Fs, that's all.

Thats one of the things I mentioned I wasn't sure about. I think that the offset may be needed if you do a quicker update (ldir) instead of the one in the example. Anyways I soon have a dynamic version ready.

At http://www.bluemsx.com/demos/sccplay.zip you can find a dynamically updating version of the replayer. The ReplayerUpdate method can be placed in an line interrupt handler and it will update as many samples as needed.

I need to test this on a real cart though to see that the offset ARTRAG mentioned earlier is set correct (if it is at all needed).

If placing the replayer in a line interrupt it will use about 25% of the cpu time which means plenty of room for game logic or other stuff

You'r the master !!
As you say all you need is to call the player once each 32/Fs secs
This should be achieved by having max one extra hint than strictly needed

Would be nice if someone could try and give feedback on these two roms.

First my favorite: http://www.bluemsx.com/demos/leila.rom
Then, myself 15 years ago: http://www.bluemsx.com/demos/bengan.rom

These are both replayed at 22kHz so quality should be better than previous Handel but I haven't had a chance to try on real MSX yet.

I will receive by mail my SCC megaflash by Manuel in few days (I hope, hi Manuel, nothing received jet here!!)
I eager to test your files and much more

BTW, it is nice to point out that this technique leaves two SCC channels free for any use !!

One possibility could be to use all the 3 channels for PCM,

The drawback is that all the 3 channels share the same frequency and must be synchronized,
due to the fact that the same counter must be used for all the 3 wave tables (tricky but always
possible).

This implies eg PCM music and two PCM FX at the same time !!!



The other possibility, not to disregard, is to use the 2 spare channel -and the PSG-
for SCC music in the standard traditional way we know.

This to reduce the size of the required room in ROM for samples...

I'm dreaming, but this is real !!