BANK COPY TO disrupts DMA from any z80 RAM addresses
On nextZXOS 2.09 RC11, just one of the dozen BANK commands interrupts and corrupts DMA output using the prescalar, e.g. background audio replay. This is expected for DMA from addresses above 49151 of course, because Sinclair 128 and Next routines momentarily swap the 16K normally mapped to BANK 0 with other banks in order to access them, but if the DMA source is below that address, everything else I’ve tried - including 11 other BANK commands, the BASIC editor and browser - works without affecting the DMA.
I understood from my meeting with Garry in Wolverhampton that NextZXOS policy is to leave DMA hardware free for applications. This one exception is problematic for games and anything else that wishes DMA to continue unmangled as a program runs, while making use of BANK COPY TO. The current DMA block is replaced with what sounds like junk, though it recovers at the next looping or block (the listener may take longer to do so).
I have confirmed that BANK CLEAR/ERASE/NEW/LIST/FORMAT/GO/POKE/PEEK$, LAYER BANK and TILE BANK do not disrupt DMA - BANK COPY TO is the only statement I have found that does (but if there are others, please fix those too).
If this is because of an optimisation which means NextZXOS now presumes it can take over DMA, please fix it to use the CPU if it detects DMA is already running (e.g. with OUT 107,191 then IN 107 to read the status register, with interrupts off for atomicity!)
Assigning to Garry for analysis, but I guess Allen might also be implicated