1

Topic: FAT32 file system corruption when DMA is enabled

Setup:
1. ZX Spectrum Next (personality mode - ZX Spectrum 128)
2. FlashAIR SDXC 64GB (FAT32)
3. esxDOS 0.8.8 with DMA support enabled
4. new browser with LFN support (https://spectrumcomputing.co.uk/forums/ … LX4#p37349)

Symptoms:
When DMA support for esxDOS is enabled in ESXDOS.CFG the file system gets corrupted when saving data to SD card. Reading is unaffected.

Example:
The new browser with LFN support saves memory dump to TMP/BROWSE.NMI file on SD card during start. In DMA enabled mode instead of BROWSE.NMI file there is bunch of files created with sizes of 1GB each and corrupted file names:

https://i.imgur.com/7cb5emi.png

Workaround:
Disable DMA support in ESXDOS.CFG

2

Re: FAT32 file system corruption when DMA is enabled

Hi,

Actually I was under the impression that esxDOS' DMA driver didn't work at all on the Next, so that's news to me. Please see https://www.specnext.com/forum/viewtopi … amp;t=1713 for more information.

PS. Moved to the Next section.

3

Re: FAT32 file system corruption when DMA is enabled

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.