Wizzcat Protracker Replay Routine Improvements

[mlynn1974]

One thing that has always stumped me is the the use of the work space in Wizzcat's Protracker Replay Routine.
For simplicity I am looking at the STE routine in assembly language not calling it from STOS.

Problems:
1. It cannot be called multiple times e.g. start/stop, start/stop.
This causes an illegal instruction because the workspace stack is overflowed.

2. Why is the workspace necessary?
It shuffles the samples in an then out again overwriting original memory.

The sample start addresses are calculated and added to an array:
samplestarts DS.L $1F

To mitigate this a bit I have an example where the header of the module is copied to a 2k buffer and restored when the music is stopped. This corrects it for the next play. I also clear the play attributes: speed, counter, song position, break value and pattern position. The samples are still slightly corrupted by some process I don't understand though.

The workspace is a real annoyance because there isn't a program to help you calculate it. Some tunes need 16k, some need more.
This is a great play routine but this mystery needs to be solved.

I have attached some work I have done on this:
STE.S - original STE play routine by Wizzcat,
STE2.S - modified play routine,
PROTRACK.S - test routine to examine memory when preparing the workspace.

I included the classic amegas.mod as it's one of the earliest mods.
It had to be converted to ProTracker format from the original Soundtracker version.

A couple of years ago I asked this question and it would be good to have a better replay routine for STOS:
https://atari-forum.com/viewtopic.php?t=36806

[mlynn1974]

I have found that the number of words stored per sample is converted to bytes, and the repeat length word is often converted from 0x140 (320) to 1. It doesn't store them in a separate bit of memory and refer to them there.

I've written a program to calculate and display the correct length for all the samples combined. For amegas.mod it is 50800 bytes (25400 words). With a 16k workspace it would bomb immediately, with 32k it overwrites the module corrupting it. With 51000 bytes of workspace (more than it needs) when the samples are written back from the work space it also corrupts memory. I don't understand why it has to do this. If the programmer wanted to have indexes to the start of each sample in number of bytes (not words) I think it should be in a separate location. Or simply do a shift left every time it needs it. Surely that wouldn't take too much CPU time? I thought the workspace would be per sample, that would make sense at 16k, but it seems to copy ALL the samples in there.

It doesn't seem to be processing the samples in any way in the work space. Allocating a 51k buffer is like having the whole module in memory twice. It shouldn't' overwrite the original modules memory space at all in my opinion.

[metalages]

I have made an optimized version of Wizzcat routine here : https://github.com/jhubrt/demOS/tree/ma ... RN/WIZZCAT
Simple player using the routine here : https://github.com/jhubrt/demOS/tree/master/WIZPLAY

Of course, it is not as fast as Lance replay but uses less than 45% CPU time
Samples are mixed at 25khz interleaved with DMA running at 50khz (I like this trick as it keeps 8 bits dynamic)

The transpose ratio are computed on a fourth of the length and automodified into the mixing routine which is reused 4 times.

[metalages]

I have found that the number of words stored per sample is converted to bytes, and the repeat length word is often converted from 0x140 (320) to 1. It doesn't store them in a separate bit of memory and refer to them there.

I've written a program to calculate and display the correct length for all the samples combined. For amegas.mod it is 50800 bytes (25400 words). With a 16k workspace it would bomb immediately, with 32k it overwrites the module corrupting it. With 51000 bytes of workspace (more than it needs) when the samples are written back from the work space it also corrupts memory. I don't understand why it has to do this. If the programmer wanted to have indexes to the start of each sample in number of bytes (not words) I think it should be in a separate location. Or simply do a shift left every time it needs it. Surely that wouldn't take too much CPU time? I thought the workspace would be per sample, that would make sense at 16k, but it seems to copy ALL the samples in there.

It doesn't seem to be processing the samples in any way in the work space. Allocating a 51k buffer is like having the whole module in memory twice. It shouldn't' overwrite the original modules memory space at all in my opinion.

If I well remember the oversize of the samples are a way to avoid to manage sample looping into the mixing routine (in order to save cpu) so it duplicates enough data to feed one frame mixing worst case.

[mlynn1974]

The transpose ratio are computed on a fourth of the length and auto modified into the mixing routine which is reused 4 times.

That is a very nice routine.

If I well remember the oversize of the samples are a way to avoid to manage sample looping into the mixing routine (in order to save cpu) so it duplicates enough data to feed one frame mixing worst case.

Thanks! Yes that explains a lot. The problem is the amount of memory this takes. If playing a big module over 500kB then there wouldn't be enough memory on a 1Mb machine however you could edit that module in the Protracker Editor.