What was the PIC implementation used for, just a stand-alone thingy? Do you still have sources for it?

Zilog wrote:

Is it really more efficient than mine?

Not at all, yours is certainly more efficient! The idea was more to smoothen row transitions by speeding up the data loading. I think that worked out reasonably well, though as you can probably tell from the code it's not optimized at all yet.

8bit mixing with postscaling? Sounds intriguing, but to be honest I don't quite understand how that would work. Could you explain a bit more about this idea? In any case, I'd love to see a new engine from you, given the unique approach you took in Squeeker

Well, the key idea is, why do all the people use 8bit counters (DEC counter8; JR NZ 10T_padding; LD counter,divider; LD channel,spike) - this means the higher tone, the less accurate its frequency (divider has just few valid bits). this takes 26T/channel AFAIK.

But, there's different approach - phase accumulator instead of divider, there's no need for conditional jumps, you just add to 8bit "accumulator", ala
LD A,frequency; ADD A,L; LD L,A (no need to reload counters, carry is immediately available, you even can use ADD HL,DE to accomplish this, when the frequency of two channels is very different - bass carry-contributions from L to H could be neglected then etc.).

Carry then feeds (SBC A,A; AND scaling_val; ADD A,scaler8) another register, "scaler", where's accumulated scaling value, typically some power-of-two, repeatedly added and we can control octave this wat, ensuring that the frequency would be in perfect align with other octaves, because we add 128, 64, 32 or similar "nice" numbers. And, when the numbers are even a little bit biased, let's say by 7, 5 or so, then, PWM control degrades for very low widhts to "intermittent" pins, giving nice fades. You could even produce harmonics with "masking" of that scaler, in one channel.

You can think of it like a <#80-#FF>-range phase accumulator as "top-octave" generator, with secondary 8bit scaler fed by its pins, doing the "downscaling" stuff - volumes, timbre, intermittent PWM stuff.

I have this idea for more than 10 years, but still no time to implement it properly (some proof-of-concept has been made on PIC12F628 :-), where it takes 7 mcycles (7us for 4MHz xtal) per channel...

regards,
Zilogat0r

Is it really more efficient than mine?

Not at all, yours is certainly more efficient! The idea was more to smoothen row transitions by speeding up the data loading. I think that worked out reasonably well, though as you can probably tell from the code it's not optimized at all yet.

8bit mixing with postscaling? Sounds intriguing, but to be honest I don't quite understand how that would work. Could you explain a bit more about this idea? In any case, I'd love to see a new engine from you, given the unique approach you took in Squeeker

Got a first beta of the XM converter ready. It's functional but highly unoptimized, so I'll probably make more changes to it later. Anyway, it's using the original core of the 2012 version of Squeeker. Per-row speed control has been added. Data format and loader have been changed completely.
The converter is standalone, no Perl required.

download (win/*nix binaries and source included)

Btw. interesting row-oriented partial-change format. Is it really more efficient than mine? (channel-oriented, pattern is always made up of four particular channels)? mine was designed for LZ-based compression (pattern definitions were similar enough, and some tracks, such as bass or accompanion were quite reusable)... nice anyway. looking forward to hearing something new with my engine inside.

Btw., nowadays I wouldn't use 16bit phase-accumulator technique. Instead, I'll use 8bit mixing with postscaling , congruential "lower bits" of the scale-divider, and pwm-threshold for pwm-based volumes. The same 8bit "top-octave" frequency source would ensure proper tuning with sufdficiently enough values (128..255), and the postscaler allows to "modulate" the sound in different ways, producing one carry in the end as well...

Z.

- why is the loop djnzed, not unrolled, etc? it's because there's no need for extra speed, slow iteration means longer spike (more audible pin-based channels), and it was originally written with code-size in my mind, for Hellboj^HPRG (who loved Hubbard's JSW so much that i decided he deserves this gift:). summer 2000...

- channel counter preset - it helps to fight stuck-one in the bass channel (resting pin channel would never produce this), but more importantnly, it helps fight the aliasing - imagine playing two tones simultaneously, just one octave apart. pre-setting channels with different starting values (0,1,2 or maybe 0, 2, 4?) will produce desired harmonics, otherwise spikes of the higher tone would cover up the spikes of the lower tone completely. it's audible in the JSW song in one pattern - data are correctly there, but the original routine (without preset AFAIK) plays like there's no progression in one of the channels - all the spikes for that particular tone were just aliased out.

Now, i'll play with your converter, Utz!

Z.

I'm on Windows 8, 64bit

Just tried the xmtosqueeker.exe and downloaded a .dll it asked for but it still won't start up.
libgcc_s_sjlj-1.dll

Net research also advised to copy this .dll to \windows\SysWOW64
libgcc_s_dw2-1.dll

download (win/*nix binaries and source included)