Not sure what Chris Walsh means, I don't see any errors in the first routine.

Good point about RAM contention from Simon N Goodwin though. I'll add a little note on that. IO contention is mentioned in Part 5, I don't think readers need to be overly concerned about it before that point.

Anyway, thanks for passing on the feedback.

Before sharing the document here, I have shared in on FB in https://www.facebook.com/groups/z80asm/, where I got suggestions to actually contact you via this forum.

In the meantime, I have received following feedback, that might be interesting for you:

* Chris Walsh
Hiya, just looking at the very first routine, and something isn't right about the A ("state") register and the OUT commands. For example, you're setting A to 0 (XOR A) on the first line before the channel 1 loop but then setting it to 10h after the look and just after the OUT. The same issue occurs in the channel 2 routine. Are you missing two more OUTs after setting the A register? Thanks for the docs BTW.

* from Simon N Goodwin:
Thanks for sharing.
In the context of the Spectrum (the focus of this group) it would be wise to remind readers that RAM as well as I/O is contended so loops like this should be in ROM (the only option for a 16K Spectrum) or the top 32K of 48K Spectrum RAM, or the right 64K half (which varies by model) of RAM on a Spectrum 128. If you haven’t altered the default paging, RAM addresses from 32768 to 49151 are always uncontended.
As regards source readability, the comments need rewrapping - they run off the edge of the PDF pages.

I have also included the .org file that I have originally used to copy paste from the forum and then used Emacs export to LaTeX functionality (only body export using following mouthful chord:  C c C e C b l l). I think at this point you can update only .tex files, and discard tutoria.org file.

            ld h,0
            ld l,0
soundloop   dec b
            ld a,h                  ; I moved this above JR NZ
            jr nz,skip1
            xor #10
            ld h,a
            ld b,c
skip1       out (#fe),a
            dec d
            ld a,l                  ; I moved this above JR NZ
            jr nz,skip2
            xor #10
            ld l,a
            ld d,e
skip2       out (#fe),a
            dec ix
            ld a,ixh                ; These destroy A register which is holding the speaker state in...
            or ixl                  ; ...case of both JR NZ jumps are taken which is most of the time
            jr nz,soundloop

How exactly did you mean to move LD A, IXH/L to save 8 T-states?

I'm inclined to leave the part on Pulse Interleaving as is. You are of course correct in that moving the ld a,ixh/l up would save 8t here, but I'm concerned that it might make it harder to see the connection with the pseudo-code on the left. In the end a proper player should not be written like this anyway, because you'd still end up with an all-too-large, 10t timing difference between the skip-taken and skip-not-taken paths.

While I was reading I noticed a few things that might or might not have to be corrected. In Pulse Interleaving routine most of the time the loop would jump through both JR NZ,SKIPx jumps and at the end the A register would be changed to IXH OR IXL and then output to port 254. That could be avoided by moving LD A,H and LD A,L above JR NZ,SKIPx instructions.

In Variable Pulse Width routine I think the state would be changed when couter wraps from #7FFF to #8000 and not when it wraps from #8000 to #8001 because carry is 1 when H goes from #00 to #7F and when H becomes #80 then carry becomes zero. The other reason why the state can't be changed when counter wraps from #8000 to #8001 is because we are checking only high byte so the state can't be changed when the change is in only low byte.

In Achieving Simple PCM with Wavetable Synthesis there are multiple RCLA instructions where there should be RLCA

Part 10 is actually a bit outdated, in part 12 you will find a better synthesis method that can also be adapted to PCM playback. In a sense, the same caveat about consecutive 1s applies to that, though, e.g. having two 3-bit outputs will be cleaner than having one 4-bit output, but having one 4-bit output saves 24 cycles...

In any case there are some interesting effects that can be observed in this regard. This is because the expansion of a speaker diaphragm isn't linear, so at volumes >50% it will react differently than <50%. So far nobody has been able to really make use of that, though.

I.e., rather than:

C-1 ...
... ...
... ...
... ...
... C-2
... ...
C-1 E-2

have:

C-1 ... > run sound loop for four rows without parsing anything
... C-2 > run sound loop for two rows
C-1 E-2