Malban – Vide diary – 14th of October 2016

Funny, when I have the least time it seems that I am most productive, I didn’t expect to do anything vide related this week, but it seems that I did something after all.

It also seems that I constantly say “I won’t do…” and than “oops I actually did…”.

YM-again

I implemented the “bitstream” encoding and decoding I wrote about that I wouldn’t do. This is another way, that Vide can encode YM-data. It uses more (quite a bit more) memory than the old YM-Sound data, but unpacking is faster and nearly without peaks. If you have enough memory, have quite short ym-files and do not have many cycles to spare – this might just be the right format.

I implemented it having “Frogger” in my mind (again) – since I would like to have in game music – there are not many cycles to spare. The complete “old” binary is “only” 16KB long, so having a few kB of ym-data (of nearly original quality) won’t hurt (see last blog entry).

Playing the Frogger main theme averages at about 1300 cycles with peaks up to 2400 cycles. That might be just about manageable to run in the background.

Here a short explanation:

The ym data is bit encodeded in a stream of “bits”. At first the ym-data is analyzed, the analysis 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:

1. leaving out data is “packing” of some sort, the resulting data is shorter than the original
2. 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 2 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, 
        otherwise clear noise
   read bit, if bit is 1 
        than set tone, 
        otherwise 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 read bit 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.

Vecci again

In the past I said, the vector editing panels can’t be resized and the “viewport” to the vectorlist can’t be translocated.

Well since I said that wouldn’t change soon – I took up the challenge and changed exactly that.

There are mainly two enhancements:

a) in the main view there is a button”pad” with which you can now “scroll” the viewport in all directions (scrollstep width is the width of the current used grid) [double click the center -> centers the viewport]

b) a new button below the mentioned button “pad” which opens a large (resizable) editor window (the window is completely synchronized with vecci)

BTW.:
If you enlarge the editing area, be sure to enlargen the grid width, otherwise the grid drawing really takes computational power and will slow things down drastically (I might look into that some day…)!

Because of popular demand I also added two additional configuration options to vectorlist generation.

• data as hex or decimal
• using DB or fcb statements

Settings within vecci are now persistent (scale, gridwidth, above mentioned db/hex…).

Christmas time

“Chris” asked me about the XMas LED emulation.

(Now, have a guess, which one of those:
– Chris Salomon
– Chris Parson
– Chris Romero
– Chris Malcom
– Chris Tumber
– Kris Tuts)
There is a special supported “cartridge hardware” now for that LED. Only cartridge that I know of, that uses it, is the Christmas 2015 cartridge of Binarystar. To actually see the emulation, you need a ROM dump of the card, the “free” version does not contain the corresponding code sections.

Regards

Malban

PS
I am uploading Vide V1.05 right now…