ZX-Spectrum UDI format possible?

[Ldaborc]

Dear Keirf, could you please add support for the FDI & UDI disk formats for the ZX-Spectrum. That would be great.

[Ldaborc]

UDI File Format Structure https://scratchpad.fandom.com/wiki/Spectrum_emulator_file_format:_udi
FDI File Format Structure https://worldofspectrum.org/faq/reference/formats.htm

[keirf]

Possible but lack of Flash space makes it unlikely. Can these convert to HFE (using HxC tools)?

[Volutar]

UDI is low-level, HFE-like format, but without track index data. And it has CRC data which makes writing troublesome. Actually it can be used for any other, non-zxspectrum disks (it stores low level track, de-MFMed with bitmap of sync bytes).

HxC can’t convert UDI, though can FDI. But FDI is not that really usable for most of protected disks as UDI. I’ve written HFE-UDI converter myself, but due to UDI data nature (particularly using synced stream) it tends to grow garbage bytes at the start of 4E gap areas. So native UDI would help not to grow with constant UDI-HFE-UDI-HFE-... reconvertion.

How much flash space is already used?

[keirf]

I think we're at about 88 of 94kB. UDI sounds a bit like HFE really but with the clock bits removed. Perhaps offline conversion to HFE makes sense?

…

On Sun, Feb 28, 2021 at 9:00 AM Volutar ***@***.***> wrote: UDI is low-level, HFE-like format, but without track index data. And it has CRC data which makes writing troublesome. Actually it can be used for any other, non-zxspectrum disks (it stores low level track, de-MFMed with bitmap of sync bytes). HxC can’t convert UDI, though can FDI. But FDI is not that really usable for most of protected disks as UDI. How much flash space is already used? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#435 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGWZFWVARQ3WELMP6AT473TBIA3PANCNFSM4YHRDYQQ> .

[Ldaborc]

In fact, I thought for a long time what to answer to the author of the firmware. And here is actually... I came to the conclusion that there is no need to support FDI, since they can be easily converted to UDI for example. But UDI support would be just super useful for using images with copy protection(s) inside. Following from all of the above, the question remains for the author, whether he can fit the UDI support (read/write) in the remaining free memory. And I still have an idea for the author of the project: you can make a certain firmware compiler for specific needs, that is, the user selects the firmware parameters, and it in turn compiles only with what is selected.
P.S. There is nothing to convert UDI to HFE. And what there is does not give positive results.

[Volutar]

HFE is used in hardware floppy emulators like FlashFloppy for real computers.
UDI is used in emulators.
HFE isn’t supported by emulators and UDI isn’t supported by FF - that’s the problem.

Offline conversion is possible and I made python converter, but converting back and forth when moving data from emul to real and back causes gap area growth.

PS: while clock bits in UDI are removed, it still preserves MFM bits in special area, so images are as twice shorter as for HFE. Like, there is no point to store all sync bits for FM/MFM disks, only C2/A1 MFM bytes are preserved.

[Ldaborc]

After reading all the comments, maybe it still makes sense to add UDI support ?