Rework socket DMA for disks and cartridge files

[p2mate]

Rather than downloading the whole image into a 200KB buffer and then
writing the buffer to a ramdisk file, use a 646KB buffer and append
the data to the ramdisk file as it is received. This allows for images
larger than 200KB (eg easyflash CRT images or D81 images). With some more
work this can also be used for flashing the update and the esp32 images
using socket DMA.

Signed-off-by: Peter De Schrijver [email protected]

[Grrrolf]

This will likely also fix the (not yet reported) issue when sending a d81 disk image with a mount-image command to the TCP port 64 command interface hanging/crashing the Ultimate application?

[GideonZ]

It would be a band-aid on a gaping wound.

I think it is better to replace the socket dma test code with a properly defined and documented API, e.g. through http.

…

[p2mate]

It would be a band-aid on a gaping wound.
I think it is better to replace the socket dma test code with a properly defined and documented API, e.g. through http.
…

I don't know much about web APIs though so I will leave defining such an API to someone else. It might make sense meanwhile to use FTP to upload the file and then use the socket DMA API to pass the filename of the file to use. This would ofcourse be a breaking change unless new command codes are used.

[p2mate]

I wonder if HTTP would be the right way to go. It would require a web server and a lot of parsing code because web APIs tend to be UTF-8 based. I think COAP (https://en.wikipedia.org/wiki/Constrained_Application_Protocol) would be a better idea. Opinions?

[Gee-64]

Is the reason for this PR not solved now that the HTTP API exists? It happily accepts a megabyte large CRT files and runs it. Can this be closed? @p2mate @GideonZ

[GideonZ]

Yeah, the PR doesn't need to be fixed. The whole port 64 thingie can be removed in the next firmware release, as everything that could be done through that raw tcp port can now be done through the API in a proper way.