Yes, since core 3.1.5 (Next OS "distro" 1.3.2) the port $0B is only ZilogDMA mode, port $6B is only zxnDMA mode. The previously used config bit in NextReg 06 is now used for beeper configuration, not related to DMA any more.
The SW from Velesoft page should NOT work well with $6B (zxnDMA), there's not much point to even try that, the $0B port has better chance.
But there is one more issue with SW from Velesoft page. There's lot of CZ/SK community production, done with the UA880d DMA chip (East Germany clone of Zilog DMA chip), which does *NOT* react to the "WR3.enable" bit.
And by some unfortunate coincidence, lot of the early DMA SW does set this bit to "1" half-way into the init, there was even article in Czech paper magazine describing how to program DMA on ZX, which did contain the same bug writing to WR3.enable early.
But the original Zilog DMA and some other clones (*and* the FPGA implementation in ZX Next) do react to the WR3.enable, and will start the transfer (as if DMA_ENABLE $87 command was sent to WR6).
This issue was identified and known by the cz/sk community few years later after the first versions, and later versions of MB-02 disk system BIOS were patched to work correctly even with original Zilog chips, also some demos were patched, but I'm not sure if somebody did review all the SW on Velesoft page and mark which contain the WR3 bug and which is compatible with Zilog chip.
If you have SW which does work with original Zilog chip, and does use port $0B, and you did select the correct video timing of your Next (of course you need VGA mode, not HDMI) to simulate zx48/128/+3 machine, then I would expect most of the old demos to work correctly, the 48/128/+3 timings of Next are quite accurate AFAIK (demos doing multicolors like Shock work usually pixel perfect, there were few pieces like muco1k from Busy which were not completely correct on Next the last time I have seen it (back in early 2018), but it was not completely clear if muco1k is correct on real HW, as Busy did use emulator to tune the timing ... I'm not sure if somebody managed to do proper test of it, real HW vs Next HW and after all the timing fixes were applied to Next)
Actually, looking at (incomplete) changelog of Next core ( https://gitlab.com/SpectrumNext/ZX_S...t/changelog.md ) there was small fix to timing even in core3.1.0, so I guess nobody did run side by side HW vs Next for these demos which are so critical on the timing accuracy.
So any precise input from people who can do the tests is welcome, but make sure you fully understand the complexity of Next setup and that you are testing in the correct mode and correct thing (with the extra bonus of some intros like muco1k containing machine-detection code, so it's better to avoid that and load the correct version explicitly, as the detection code may fail to pick the correct model too.
In ideal world it should be on Next (running with VGA mode at 50Hz) as easy as to select your video timing (48 / 128,+2 / +2A,+2B,+3 / Pentagon) and ROMs (this is what the TAP and SNA loader does, with TAP loader displaying menu to select the machine configuration by user, SNA reads snapshot type and modifies the HW config automatically based on the type), and just run the SW and all should work.
If it does not work correctly, and you can identify what is failing, please report it to the Next team, it's important piece of information. But it's also very tricky to find the true reason where is the problem, as there are many details contributing to the final result, as you can see from this post (it was supposed to be short 2-3 sentence post, and it's whole page instead, argh).
- - - Updated - - -
So, I downloaded the dma-demo-level_1.zip from velesoft page, added debug printf into ZESERUse (fork of ZEsarUX) to print every byte going to DMA port and this is the init sequence:
($0B) = $C3 RESET
($0B) = $C7 RESET port A
($0B) = $CB RESET port B
($0B) = $7D WR0 + port A adr + length, A->B, transfer
($0B) = $21 A.adr = 0x4021
($0B) = $40
($0B) = $BE length = 0x07BE
($0B) = $07
($0B) = $14 WR1, A++, memoryA
($0B) = $10 WR2, B++, memoryB
($0B) = $C0 WR3, enable=1
DMA Transfer with mode 0 (single byte) requested - ignored
($0B) = $AD
($0B) = $20
($0B) = $40
($0B) = $82
($0B) = $CF
($0B) = $B3
($0B) = $87
....
I added comments from beginning to the WR3 write, which wrongly enables the transfer (prematurely, before the DMA_LOAD command). So the demo works only on the UA880d cloned chip, which ignores this WR3 write.
If you are bored, you can try to disassemble the demo and find the init sequences and turn $C0 into $80 in each of them (writes all-zeroes to WR3, which is actually important on real Zilog DMA, because it somehow affects timing without the write to WR3 - it's still a bit mystery why/how, as the other bits are related to interrupts/etc which is not used on MB-02 + Zilog DMA, but by testing with real HW we did find that writing explicit zero to WR3 somehow makes the machine timings more stable).
But at this moment, Next with it's Zilog DMA emulation, can't run the SW which has the WR3.enable bug correctly, there's no such option on Next.
