Mount d64 image via Socket

[p-a]

I've added commands FF09 and FF0A in order to run or just mount a D64 image via the socket. The new commands takes an additional byte to extend the length parameter followed by the d64 image data.

Examples:

Execute the RUN command 09FF00AB02...d64 data...

Just MOUNT a d64 0AFF00AB02...d64 data...

This is based on ref 3.1a_500+_v4

[markusC64]

Gideon also has assigned the Number FF09, so I'll have to change the numbers a little:

define SOCKET_CMD_DMAJUMP 0xFF09

and I'll need it in a different branch (Gideon has made some adjustments to the Ultimate 64. And improved FTP support. ), so I'll look at your changes and probably cherry-pick them to the latest branch.

[markusC64]

+#define SOCKET_CMD_MOUNT_IMG 0xFF0A +#define SOCKET_CMD_RUN_IMG 0xFF0B

would be ok - changing only SOCKET_CMD_RUN_IMG.

[p-a]

Great! Yes, I was counting on some minor adjustments 👍

[markusC64]

I sucessfully integrated your contribution to the temporary branch "pu" (proposed updates) relative to the newest development bramch.

Please check if everything worked.

I'll build a firmware for internal testing - and if no issues occur, the patch will be cherry-picked to the development branch.

[p-a]

Built the branch, but update.u2p is awfully lot bigger now, 2599656 bytes. Is this expected?

[markusC64]

Gideon decided to offer updating the recovery enviromnent too. So basically this updater includes two FPGAs and two Applications instead of one. That should explain the gain in size.

[p-a]

Flashed and it works like intended. 👍

Question though, I had a go at DMA-loading "*" upon CMD_RUN_IMG, but couldn't get it to work. Is there a restriction using wildcards with DMA load?

EDIT: Guess it's OK to close this PR then :)

[markusC64]

Your changes are containe in the new release 3.1d_171224+_v1. Therefore I'm closing this pull request.

Regarding your question: I do not know.

[markusC64]

1541u2.pl/.exe has been updated to support the new features provided by your patch.