Time to go beta. I created 4 versions of the driver; maybe the preprocessor will allow to make 1 file and #ifdef will do the rest, but now they are 8,16 and 32 channels + fast 8 channels.
I was going to give this latest 32 channel version a try with PSRAM and DOPE.MOD, but I then read this below from Ahle2. Will need to wait for a XM player it seems.
Btw, that "dope.mod" is not a .mod at all, it's actually a .xm module and is not compatible with the protracker format at all. (I'm already looking into a .xm and .dbm tracker player that would will work fine with the 64 available channels in reSound. Stay tuned)
I have to try my PSRAMs as I soldered 10 pieces of them to breakout boards - 2x 4 and 2x 1. The plan is to connect them to a P2 Edge breakout board with as short connections as I can do. That's why I asked for 1-chip driver: hardware errors, bad connections, etc problems will be easier to find with 6 wires than 18.
The xm module's basics are not very different than mod: samples and patterns. There are more channels and more effects available: this has to be implemented in the player. The difference that can generate problems is wider frequency range. The dope.mod uses 6th octave. Amiga normally cannot do it as it cannot get samples that fast, my driver can, but of course it costs time. 28 channel+6th octave+PSRAM may be hard to run, but this is the Propeller so anything should be possible. In the worst case we can always use more cogs
In the retromachine environment, as I plan it, where all things are pixel-clock synchronized - the samples can be retrieved - as in Amiga - in hblanks, using the video driver.
This 8-channel version can use PSRAM for samples (if started with mailbox address >=$200) or HUB (if started with 0)
It can switch between PSRAM and HUB at the run time using a command (if started with the real mailbox address, if started with 0, it will always use HUB)
It can also change the sample rate on the fly - in reality, what is passed via the command is a divider for DACs which is then written by wxpin. The real minimum is somewhere about 60, the hangup value is about 50
If the new divider set is n*256, the driver will switch to PWM DACs instead of noise mode. This, along with setting the proper CPU speed via HUBSET, allows to play wav files with the best possible quality.
This version supports exporting samples (at 1/128 sample rate) to the HUB at (now hardcoded, but will be settable) $72238 - the buffer length is 640 longs and is constantly overwritten. It is good enough to have an oscilloscope effect in the player.
This version uses 256-byte cache (which fills in about 1200 cycles) instead of reading (300 cycles) every sample individually. I have now to clean this up and remove hardcoded addresses for a hub buffer (8*256 bytes) and a scope buffer. They should be passed using API calls.
The change opens a possibility to have both video and audio in PSRAM - this have to be checked. The video "sprite" driver preloads the line to a buffer 2 lines earlier, so the realtime PSRAM priority can be removed from it and a burst size reduced to avoid too long waiting for audio cache loading.
The driver is now cleaned and gets parameter in start - mailbox (0=no psram) , scope -oscilloscope buffer address (0=don't use oscilloscope) , cache - cache address (set to 0 if no PSRAM)
The "skip" parameter is now 8.8 fixed point instead of 16.0 integer. This allows for fine tuning, which is needed for application such as "mind machines" where you have to generate 2 sine waves at slightly different frequencies. Paula period table is much too coarse for this. This will also allow wavetable type synthesis using one period wave tables+ADSR. The wave definition can be then long (eg. 1024 samples or more) , then the period and skip values can be set to fine tune the frequency
Non-integer skip introduces aliases and additional noise. The samples are not interpolated. It has to be used with caution, but for integer values (set in the register as n*256) the driver works exactly as before, and for the described purposes, where the wave definition is long enough, it should be sufficient. I have now to move these changes also to 16 and 32 channel version, which will enable to write a wavetable midi synth using the driver.
Also (which was introduced in 0.92) the first 2 channels can be synchronized for playing a stereo wave file without phase errors. To do this, the bit #29 in the wave start pointer has to be set.
0.93b
If the bit #28 in the sample pointer is set, it shl the pointer by #2. This enables using fractional skip parameter also for stereo interleaved samples (=wav file)
Bit 27 of the sample pointer switches the driver to a noise generator mode
Envelope generator added. Envelopes are also sample based and can have up to 1024 points. The envelopes are updated at every generated sample, with linearinterpolation between two defined points.
A channel's mailbox is now 16 longs, to fit the envelope generator parameters,
Comments
Time to go beta. I created 4 versions of the driver; maybe the preprocessor will allow to make 1 file and #ifdef will do the rest, but now they are 8,16 and 32 channels + fast 8 channels.
https://github.com/pik33/P2-retromachine/tree/main/Propeller/Audiodriver
I was going to give this latest 32 channel version a try with PSRAM and DOPE.MOD, but I then read this below from Ahle2. Will need to wait for a XM player it seems.
I have to try my PSRAMs as I soldered 10 pieces of them to breakout boards - 2x 4 and 2x 1. The plan is to connect them to a P2 Edge breakout board with as short connections as I can do. That's why I asked for 1-chip driver: hardware errors, bad connections, etc problems will be easier to find with 6 wires than 18.
The xm module's basics are not very different than mod: samples and patterns. There are more channels and more effects available: this has to be implemented in the player. The difference that can generate problems is wider frequency range. The dope.mod uses 6th octave. Amiga normally cannot do it as it cannot get samples that fast, my driver can, but of course it costs time. 28 channel+6th octave+PSRAM may be hard to run, but this is the Propeller so anything should be possible. In the worst case we can always use more cogs
In the retromachine environment, as I plan it, where all things are pixel-clock synchronized - the samples can be retrieved - as in Amiga - in hblanks, using the video driver.
The player code was cleaned up before starting to make a real player program.
I put a 0.91 version into https://github.com/pik33/P2-retromachine/tree/main/Propeller/Audiodriver
This 8-channel version can use PSRAM for samples (if started with mailbox address >=$200) or HUB (if started with 0)
It can switch between PSRAM and HUB at the run time using a command (if started with the real mailbox address, if started with 0, it will always use HUB)
It can also change the sample rate on the fly - in reality, what is passed via the command is a divider for DACs which is then written by wxpin. The real minimum is somewhere about 60, the hangup value is about 50
If the new divider set is n*256, the driver will switch to PWM DACs instead of noise mode. This, along with setting the proper CPU speed via HUBSET, allows to play wav files with the best possible quality.
This version supports exporting samples (at 1/128 sample rate) to the HUB at (now hardcoded, but will be settable) $72238 - the buffer length is 640 longs and is constantly overwritten. It is good enough to have an oscilloscope effect in the player.
Switching hub/psram works now at the channel level
This version uses 256-byte cache (which fills in about 1200 cycles) instead of reading (300 cycles) every sample individually. I have now to clean this up and remove hardcoded addresses for a hub buffer (8*256 bytes) and a scope buffer. They should be passed using API calls.
The change opens a possibility to have both video and audio in PSRAM - this have to be checked. The video "sprite" driver preloads the line to a buffer 2 lines earlier, so the realtime PSRAM priority can be removed from it and a burst size reduced to avoid too long waiting for audio cache loading.
Yeah bursting to/from PSRAM will help allow audio share the PSRAM with video instead of doing individual transfers.
The driver is now cleaned and gets parameter in start - mailbox (0=no psram) , scope -oscilloscope buffer address (0=don't use oscilloscope) , cache - cache address (set to 0 if no PSRAM)
0.93.
The "skip" parameter is now 8.8 fixed point instead of 16.0 integer. This allows for fine tuning, which is needed for application such as "mind machines" where you have to generate 2 sine waves at slightly different frequencies. Paula period table is much too coarse for this. This will also allow wavetable type synthesis using one period wave tables+ADSR. The wave definition can be then long (eg. 1024 samples or more) , then the period and skip values can be set to fine tune the frequency
Non-integer skip introduces aliases and additional noise. The samples are not interpolated. It has to be used with caution, but for integer values (set in the register as n*256) the driver works exactly as before, and for the described purposes, where the wave definition is long enough, it should be sufficient. I have now to move these changes also to 16 and 32 channel version, which will enable to write a wavetable midi synth using the driver.
Also (which was introduced in 0.92) the first 2 channels can be synchronized for playing a stereo wave file without phase errors. To do this, the bit #29 in the wave start pointer has to be set.
What I did for 0.93 worked only for 8-bit samples. For 16-bit, when the fractional part was not 0, it switches endians....
So I had to correct it, SHLing the pointer inside the driver. The skip parameter is now samples, not bytes, but 16-bit samples can now be fine tuned.
0.93b
If the bit #28 in the sample pointer is set, it shl the pointer by #2. This enables using fractional skip parameter also for stereo interleaved samples (=wav file)
0.95
Bit 27 of the sample pointer switches the driver to a noise generator mode
Envelope generator added. Envelopes are also sample based and can have up to 1024 points. The envelopes are updated at every generated sample, with linearinterpolation between two defined points.
A channel's mailbox is now 16 longs, to fit the envelope generator parameters,