With the supplied ym utility you can generate different YM data files (and players). Following is a list of these formats.
The data is written in without any compressing to data statements - this is very easy understandable. (for comparisson, playing speed ~ 1700 cycles)
This output is 100% compatible to the tool I released about 15 years ago. The structure of the generated ym file is explained in YM-Conversion I.
This is still in basic the same as YMSound, but with a few ehancements. The data between these two are NOT compatible.
The generated data uses a little bit more space (10% more ~ about). The average unpacking speed is about the same amount faster (a little bit more than 10%), but the main aspect is, that the "peaks" are reduced.
With my given example file, peaks by playing using the old routines were up to nearly 20000 cycles (average 3200 cycles). The new routines have a maximum peak of less thean 7500 cycles (in the whole song only 3 times) - and an average of about 2400 cycles.
Changes to YMSound historic:
single bytes are not shannon encoded (since searching for the shannon code takes longer the more codes are generated, and the savings for single bytes using shannon was only a small benefit)
RLE encoding changed from LSB first to MSB first, this made decoding the RLE length more performat
the phrase length is not held befor the phrase structure but directly in the phrase mapping, I can calculate the phrase offset now while searching the phrase
the RAM structure is 1 byte longer per register, the current phrase length is also kept in the data structure now
only the used bits per register are encoded (e.g. amplitude registers only 4 bits...) this made up quite some of the lost space due to the shannon/byte changes
some internal changes to optimzed "little" stuff
all "subroutines" were macro'ed
I advise to change the subroutine, to output to shadow registers, rather than to PSG registeres directly, that way you can "overwrite" values with sound effects!
(streamed does not support envelope data as yet)
The ym data is bit encodeded in a stream of "bits". At first the data is analyzed, the analyses results in following "knowledge":
is channel X used at all or not
does channel X use tone or not
does channel X use noise or not
is noise used at all in the ym data
does register 7 change at all in the data
According to the above knowlegde only used registers are encoded.
The idea behind streamed encoding is to only supply information for changes and leave out all data that is unchanged.
There are two good reasons for that:
leaving out data is "packing" of some sort, the resulting data is shorter than the original
we know while processing inherently what data has changed and what not, so while unpacking on the vectrex we also know what registers changed and we do not have to poke to the psg registers that did not change. Poking to psg takes quite a few cycles.
Following decoding is used (for each ym-line, a complete set of data for one refresh cycle - encoding is the opposite way):
read bit, if bit is 0 than nothing at all changed -> goto done
for channel 0 to 1 do
read bit, if bit is 0 than channel did not change at all -> do next channel
read bit, if bit is not 0
read 4 bits of amplitude
read bit, if bit is 1 than set noise, outherwise clear noise
read bit, if bit is 1 than set tone, outherwise clear tone
read bit, if bit is not 0
read 8 bits of frequency low
read bit, if bit is not 0
read 4 bits of frequency high
end for
read bit, if bit is not 0
read 5 bits of noise frequency
done:
Vectrex unpacking is done like described above. The unpacker is a bit "longish" since readbit is realized as a macro and often used :-).
The mentioned analysis is also respected by the vectrex sources. Code parts that are not needed are omitted (using "if then else").
The resulting player is usually quite a lot faster than the other packing - but the data used is by far not reduced as much. It depends on how "tight" (cycles) the circumstances are what strategy of packing is more useful to you.