(note: this is meant as a response to https://eev.ee/blog/2018/09/06/cheezball-rising-resounding-failure/, but since comments there are disabled but i might have not seen the comments... also don't have a disqus account and this would be too long to be a proper comment anyways so an issue it is)

so, after reading your post (blame nicole.express for linking to it), i have a few notes to say

first, about why the pulse wave isn't centered, it's because a proper 1/8 pulse has a dc offset that the high-pass filter blocks, this comes from the fact that every 8 samples, 1 is in one direction and the other 7 are in the opposite direction, not canceling out.

now about the wavetable sample problem

the problem appears to be that, when the wavetable channel is not playing, the mixer outputs its default value of 8, instead of the wavetable average of 0.

to visualize this better, imagine an output of 8 to be "0", an output of 0 to be "8", and so on. this should give identical results to the original hardware when not using global volume, just at an inverted phase.

then the default value is indeed 0, and the wavetable can go from 0 to 16, usually averaging around 8.

thus, when not playing the wavetable, play a very high frequency square wave instead, creating a dc offset of 8. do that quickly enough and the pop could be too minor to notice.

this also presents an opportunity if the wavetable has sufficient low-frequency content such that each 32-sample window has a different dc offset.

if that's the case, the offset can be changed to anywhere from 8 to 12 (possible with 3/4 pulse) when not playing a sample, and lowered from 0 to 4 when playing a sample (or higher if you know the sample levels will go back down by the end of the window, potentially allowing the signal to be mixed louder and thus, reduce clipping.

additionally, if you know you are using mono audio (such as the internal speaker), you can also adjust the "coarseness" of the wavetable steps by panning them. unfortunately the volume slider won't work for this since it only shifts the existing values instead of shrinking them properly.

potential bonus idea: changing the channel frequency to do slight data compression and align the samples better so the previous idea works better.

Currently you define eight BUTTON_* constants, but hardware.inc already has these (PADB_* for bitwise instructions, PADF_* for masks). To switch to using them you'd need to change the swap a in read_input (here) to swap b, since you have the nybbles in the opposite order to its expectations.