I am through with it.
It might be, that more optimizations can be done, but my head is spinning and I can’t look a psg chip in the eye right now. So for now I am finished with the Arkos player.
The next version of Vide will sport a new menu entry in vedi, with which one will be able to convert Arkos Tracker “bin” files to vectrex playable bin files (inclusive source code generation).
Some technical facts:
- the player code (bin) is 1259 bytes long
- it uses 74 bytes of RAM
- playing a song averages at about
2000700-800* cycles (provided) - starting a new pattern uses more cycles – up to about 1000 cycles (using 3 tracks with “funny” instruments)
- the maximum I have seen is
31xx1762* cycles playing the demo song provided with the tracker which uses all kinds of funny stuff - digi drums are not supported
- frequency translation table adopted to vectrex PSG frequency of 1500000 Hz
- the aks “songs” are converted to DB statements as source code and are converted from little endian to big endian, the fixed memory location is “guessed” and address dependency is removed
Now I will be going back to do more “Release” stuff.
Regards
Malban
*Update:
I was to stupid to measure correctly!
I guess this means accelerated CPUs and FGPAs may need to manually account for frequency translation???
This has nothing to do with the CPU – but with the audio chip.
The PSG chip is also driven by a clock cycle pulse – in case of the vectrex – the same as the CPU 1500000 Hz.
The actual “frequency” registers 0,1; 2,3 an 4,5 are actually “wait counters”.
Internally the PSG counts the system clock down from 16 to 0, if 0, it also counts down the value in the frequency register (at each 0 I mean).
If the frequency register (counter) is 0 it does initiate another square wave pattern.
So – the higher the value in the frequency register – the lower the actual frequency – since it is a “wait counter”.
And the decrease of the wait counter is done with clock_speed/16.
So yes – the frequencies and the notes generated by the PSG chip directly relate to the clock speed.
As for your question – if the CPU or FPGA clock speed are manipulated in such a way, that it actually changes the clock speed of the PSG chip attached (haven’t looked at other soundchips) – yes – one should compensate!