A port 0x0b mapping of the dma was added specifically for compatibility with the mb02, datagear, mb03. When it is enabled, the internal dma gets used instead of the external one.Using port 0x0b places the dma in z80 compatibility mode so dma transfers should work fine using this port. However there are a couple of issues:
1) The East German z80 dma clone that was used in the datagear and possibly others is not 100% compatible with the z80 dma. In particular, a Czech magazine published a how-to on programming the z80 dma that contained a bug and this got spread around. The bug causes the dma transfer to start before it is initialized but on the E German dma, the command is ignored. The Next is following the z80 dma currently and I think the mb03 may be following the E German clone on this issue. As long as the dma is properly programmed there shouldn't be an issue with dma transfers.
2) There are some edge cases in timing that are different in comparison to the z80 dma. These show up in some demos where copies to screen may be shifted out of position. This shouldn't affect dma transfers which are not timing sensitive at all. In the mb03 these timing differences were fixed but in the zx next we're waiting to make the fixes until the dma sees an upgrade.
So I am wondering if bug #1 might be the issue with dma transfers? The offending dma command is:
$C0 WR3, enable=1
which starts a dma operation on z80 dma chips. It can be removed without any consequences.
]]>
