actually even better idea... If we have values 32 to 0 in ch4 we know exactly how many bytes we can update... This way we don't need to wait... we just need to make sure that update routine is called at least 4 times in screen update...

You mean using one channel as a time counter? Apart from wasting one channel it sounds like a very easy way of doing synchronization.

Yes, thats the idea...

Line interrupt adjusted on fly is the sole source for interrupt at 240 Hz.
(only for msx2 naturally )
Using the deformation register in the way you say is a good way to "correct"
interrupt latency and jitters.
I only wonder if the Hsync and the Fsample are/can be multiple both in PAL and NTSC.
If yes latecy and jitter could be not bad even using only a custom interrupt routine
witout using the channel as counter.
If not, you need to resort to the counter or the audio will have glitches.
Actually in this case, you will need 5 interrupts for frame.

Is it possible to do line interrupt on all scanlines? In PAL there are 313 scanlines and the register is only 8 bit...

NYYRIIKIs idea makes it very easy to reprogram the samples at any given time. It could be worth the waste of one channel, especially in a game because the only thing you need to think about is to refill at least once within the period of the scc and you always know how much to refill.

Interrupts at 240Hz will leave you 8500 T-states after BIOS IRQ handling.
Not bad ... That is roughly 1000 operations.

Some more detail about the # of ints per frame.

The HSYNC rate of TV is 15625 Hz (for PAL and SECAM standards) or 15750 Hz (for NTSC standard).
The VSYNC rate is 50 Hz (for PAL and SECAM) or 60 Hz (for NTSC).

Anyway Portar claims that hsync on msx does not depend on PAL/NTSC settings and is always 15716.99 Hz
Now the base frequency in the scc should be the z80 main clock, i.e. 3.579545MHz.

this leads the scanline time to 227,75 cycles

from portar we have also:

Vertical Timings, 50Hz Mode

Frame Height : 313 scanlines
Frame Time : 71285.75 cycles
Exact Frame Rate : 50.214 Hz
Possible HBL IRQs: Line 00-FF (either 192/212 pix mode)


Vertical Timings, 60Hz Mode

Frame Height : 262 scanlines
Frame Time : 59670.5 cycles
Exact Frame Rate : 59.9885 Hz
Possible HBL IRQs: Line 00-EA (192 pix mode), 00-F4 (212 pix mode)

thus,
at 50Hz, 5 interrupts should fall each 62.6 lines, i.e. 14257,15 cycles of spare time
at 60Hz, 5 interrupts should fall each 52.4 lines, i.e. 11934,1 cycles of spare time

I say 5 interrupts becouse with 4 of them you need to be cycle accurate in the
timing at wich the interrupts occur.
But if we know where the player is in the buffer, we can always have more interrupts
than stricly required in order to compensate the jitters.


now all we need is to see how scc actually works when deformation bits 6&7 are set

I'm not really understanding what you're saying ARTRAG. The line interrupt falls every scanline, i.e. every 228 cpu cycle regardless of PAL/NTSC. One scanline is the same in both PAL and NTSC.

The problem is that in PAL you can only get a HINT on 256 of the 313 scanlines (unless there is some offset that can be used) or am I totally wrong?

Well I suppose you could use R23 to set the display offset and then R19 to set the scanline. That should cover all scanlines, right?

you're totally right, according to Portar Hsync does not change

This is why
at 50Hz, the 5 interrupts should fall each 62.6 lines apart, leaving 14257,15 cycles of spare time
at 60Hz, the 5 interrupts should fall each 52.4 lines apart, leaving 11934,1 cycles of spare time

About your point, we do not need r23, indeed
with Vertical Timings @50Hz
the Possible HBL IRQs can be at Lines 00-FF (either 192/212 pix mode)

with Vertical Timings @ 60Hz
the Possible HBL IRQs can be at Lines 00-EA (192 pix mode), 00-F4 (212 pix mode)

this means that the idea can work, as the last interrupt,
at 50Hz, should fall at line 250 (we can set it till 255),
at 60Hz, should fall at line 209 (we can set it 234 or more)

With 5 ints/frame you can play up to 8KHz when at 50Hz
and up to 9,6KHz when at 60Hz. Moreover using the last channel counter,
you can reach any frequency lower than those two

I think that Metalion's calculations don't work well because although BIOS interrupt routine may take huge amount of time while handling screen refresh interrupt (keyboard scan etc.) in lineinterrupt I find it unlikely that the interrupt routine would take >1000 t-states.

@Artrag I understand very well that you are interested about geting this work without sync from SCC. If this could be done you would get hardware volume controll in use that would make MOD-player much more easy to implement. I think that by adjusting the playback rate you can find some good combination for PAL & NTSC. How ever I'm starting to think that it will not work reliably all the time...

I also think that if you need, you may be able to trick more HBL IRQs by using overscan. How ever I'm pretty sure the numbering of lines will be weird. This might be worth of checking out as 8kHz mixing rate is not actually very good.

Is it so bad to require 2 x SCC to play back MOD-files This way you could have own sync channel for each sound channel. You could stop thinking about volume control, sample mixing etc. If you didn't know SCC frequency registers are also compatible with MOD format internal frequency format (!!!) Practically in this case all time consuming thing left is to keep all the sample buffers filled.

Actually I think that playing MOD-files with 2 x SCC could be even easyer than with MoonSound...

Do you want another idea for multiple channel play ?

Theoretically this idea can work allowing 4 channels
with independent frequencies from 1,92KHz up to 27,946KHz

let's fix to 60Hz, (at 50Hz the frequency range change a lot and it is too low, so let's skip it)

the last interrupt can be sent at line 244, so the number of lines you have to the end of the frame is 262-244=18
if we partition the screen in slices of 18 lines by sending 262/18=14.555 interrupts we could send to one channel
14.555*60*32bytes/sec = 27946,666 Hz

This is the max freq, as we cannot send ints in the last 18 lines of the borders.
now the implementation problems:
You cannot send a fractional number of ints in ONE frame (eg. 14.5 interrupts)
Solution:
We can work on multiple frames. e.g. we set 29 interrupts in two frames, this gives 14.5 ints per frame
and can be implemented by starting with an offset the interrupts on the odd frames.
(the offset should be the reminder of the division N_ints_sent_up_to_now*int_period_in_lines/262,
that can be implemented as : current_line_int + int_period_in_lines - 262)


In short: the replayer sets the number of ints per frame accordingly to the Fsample,
having care to spread across the frames the fractions of period that exceeded in the
past frames. At each call the routine decide at witch line to call itself next time.

Assume now you want 2 channels at different frequencies.

Each one could be implemented independently in the way above,
Each channel has an independent routine and is able to
compute at which line it should be called next.

The problem in setting the interrupt line is that the code of
each channel should

1) book the int at line at which it should be called next
2) set the int at next line in the booking list that has been booked by other channels
3) redirect the next interrupt at the code of that channel

I see many "sub" problems that could compromise the result, but the idea is nice
some problems are:

a) the CPU takes a non zero time to execute the player code of one channel, if the
Fsample of two channels are almost equal or multiple, some ints will overlap and the result
will be that one of the two channel will loose data....

b) if the Fsample of the channels are generic, some ints can fall in the 18 line area
where, without tricks (I do not know if overscan can give more ints), we cannot
generate ints. In this case you have data loss

b) usual problems of jitters and latency and loss of accuracy in sample timing due
to the fact that interrupts are not synchronized to the SCC frequency



Problems B) and C) arise also in the single channel version

Quote:

I think that Metalion's calculations don't work well because although BIOS interrupt routine may take huge amount of time while handling screen refresh interrupt (keyboard scan etc.) in lineinterrupt I find it unlikely that the interrupt routine would take >1000 t-states

Those are not my calculations, I am just quoting them ...
I also think that 6500 T-states is huge ... And wait until you find about Turbo-R's IRQ handling : 9900 T-states !

www.msx.org/forumtopic7855.html

What kind of technique is used for the samples in Manbow2?
I believe that the explosion when getting hit is a sample (at least sounds like it). But the enemies and scroll continues...

Is this an SCC sample?

@NYYRIKKI
I was thinking about the deformation register used as timer.
WIKI says that all the locations from 98E0h to 98FFh aim to the same register.

If all channels share the same register, what is the period P used for computing the rotation frequency ?
or better, assuming each channel is deformed with its own period,
can I deform only one channel and not the others?


Beside this, if we look carefully we see that in the time the channel outputs one sample,
the deformed channel will rotate 32 times.

This implies that I cannot use rotation and last bit as a timer of the channel where data are
hoping to move to the channel 32 bytes chunks

I did this error in my proposal "Posted: October 12 2007, 18:35"

I can set just ONE sample at time.
so change the lines in this

Quote:

All the samples have to be prepared having the last bit reset except for those multiple of 32, where the bit is set. the algorithm is this: Prepare the channel as before 0) do you staff here in less than 125us (if at 8KHz) 1) test bit 0 in byte #1 of the channel used for replay 2) if it is reset goto 1 3) put the next sample in the wavetable 4) goto 0

In this case your proposal of using the deformed channel to know how many bytes must be updated cannot work
unless you do not guarantee that the deformed channel has period 32 times longer than the actual channel

only if the frequency of the deformed channel and that one of the play channel can be set
independently and you can divide by 32 the one in the deformed channel
you can can use the deformed channel as counter

and this leads to my initial question

what is the period P in the deformed channel??
can I deform only one channel, using the others normally?

Can someone use Five channels on the cartridges of Snatcher and SD Snatcher !?

Indeed, Channeling four different samples on SCC should be very nice.