Provide API over serial to control basic functions

[z0m8ied0g]

Create a binary API to perform basic functions via serial.

The initial API function required are...

• Mount a disk image by number. Also might be useful to have another API command to do it by filename.

• Check if a valid USB stick is present. Simple check if the USB stick has been inserted and is readable.

• Fetch names of disk images in the currently selected directory on the USB stick. Return the filenames of disk images in currently selected directory. May be useful to have pagination to return a set no of filenames per request.

• Change directory on USB. Select the current directory.

• Create empty disk image. Create an empty disk image. Will have to select the disk type when creating (DD / HD etc) and filename to use.

• Display message on screen. Would be useful to be able to display a custom message on the OLED screen and disable the normal ones.

See facebook discussion for more details...

https://www.facebook.com/groups/flashfloppy/1049673525192880/?comment_id=1051745661652333&reply_comment_id=1059585644201668&notif_id=1541335194232414&notif_t=group_comment_reply

[z0m8ied0g]

Can we make it use some kind of generalised packet mechanism such as...

<STX><COMMAND ID><DATA LENGTH><DATA><CHECKSUM><ETX>

Return command from FlashFloppy...

<STX><COMMAND ID><STATUS><DATA LENGTH><DATA><CHECKSUM><ETX>

So status could be an error code or 0 if ok. Data is only returned if required. Checksum is XOR of each of the bytes between <STX> and <ETX>.

Also when returning lists of items can we possibly add the length of filenames etc before as it makes it much easier as you don't need to worry about escaping any characters that might be interpreted as a string delimiter and you can pre-allocate any buffer space required.

So to select an disk image index 500 in the example above...

<STX><COMMAND = 1><LENGTH = 2><NO = 500><CHECKSUM = 246><ETX>
0x02 0x01 0x02 0x01 0xF4 0xF6 0x03

Would return...

<STX><COMMAND = 1><STATUS = OK><LENGTH = 0><CHECKSUM = 1><ETX>
0x02 0x01 0x00 0x00 0x01 0x03 - Good selection

<STX><COMMAND = 1><STATUS = OK><LENGTH = 1><EXTENDED DATA = 255><CHECKSUM = 254><ETX>
0x02 0x01 0x01 0x01 0xFF 0xFE 0x03 - Bad selection error (0x01 with extended info (0xFF).

And to get a list of files...

<STX><COMMAND = 3><LENGTH = 0><CHECKSUM = 3><ETX>
0x02 0x03 0x00 0x03 0x03 

Would return...

<STX><COMMAND = 3><STATUS = OK><LENGTH = 10><NUMBER OF FILES = 2><FILE 1 SIZE = 4><FILE NAME 1 = "TEST"><FILE 2 SIZE = 3><FILE NAME 2 = "BOB"><CHECKSUM = 85><ETX>
0x02 0x03 0x00 0x0A 0x02 0x04 0x54 0x45 0x53 0x54 0x03 0x42 0x4F 0x42 0x55 0x03

[penfold42]

Is anyone actively working on this ?

I have a need for an API to control this so will likely do something over the next few weeks

[penfold42]

Has anyone been working on this ?

I have mostly finished the controlling side and need to start working on the FF side.

At a minimum I’ll start implementing button/rotary controls over serial and firmware and api version commands.

[keirf]

Probably best make a start and point us at a branch to take a look at. Which uart will this connect to? One possible issue is the main uart dma channels are already used elsewhere.

[keirf]

Another question: does serial interface respond only while in navigation mode, or respond always but dump into navigation mode if not there already, or is some subset expected always to respond even during drive emulation mode?

[z0m8ied0g]

What happens currently when you press a key on the front. I take it it waits for the drive emulation to get to some point before navigating on the menu or ejecting the disk?

[z0m8ied0g]

You could probably get away with only allowing commands while a disk image isn't loaded then having an eject command (or just send anything) that ejects the current image and drops back to navigation mode. Then you'd only have to service the drive emulation to set the disk change flag while responding to serial commands.

[keirf]

It would be nice to be able to resync to the command stream if bytes are lost or corrupted. Eg. send bytes x=0x00-0x7f direct, send x=0x80-0xff as { 0x80, x-0x80 }. Then we have 0x81-0xff for out-of-band signalling (eg. command/response start/end) allowing easier error recovery. Just putting this down while I think about it.

[JanHolbo]

RE #225 How hard/easy would it be to port the FlashFloppy code to an ESP32? Pros could be control by BT or WiFi, update storage by WiFi, enabling the FlashFloppy hardware to be buried deep internally in the retro machine as access to storage and control buttons no longer is needed.

[keirf]

Interesting question. I suppose the most obvious thing that seems to be missing is STM32's super nice timer peripherals with very flexible I/O. They are very critical in FlashFloppy for reading/writing floppy data.

[peter-mount]

Has there been any progress on this?

One thing I do with my GoTek's is to attach a Raspberry PI 0W to it in Gadget mode instead of a flash drive. This is useful for me as I can then copy new images (usually during software development) to the PI over WiFi and it's then available without having to unplug anything avoiding wear & tear on multiple usb sockets etc as well as making development a lot faster.

That said one thing I have been thinking was if there was a way of controlling the GoTek from the attached PI, so I could do the disk selection/changing from the command line as well as possibly list the available disks (as seen by the gotek) from there - disk images are already visible as they are in a FAT partition on the PI.

As the PI has a uart available to it so it makes sense that if a uart connection was available then this would be pretty simple to implement on the PI.

I'm commenting on this now as I've been following #445 but from what I'm reading right now that seems to be duplicating what's in this issue.

[keirf]

@peter-mount Sidestepping the serial API non-progress slightly, one option for changing disk would be:

1. Eject
2. Rewrite IMAGE_A.CFG on the FAT partition (or INIT_A.CFG, if image-on-startup=init in FF.CFG on the FAT partition)
3. Mount

Not as quick as a serial API perhaps, but pretty easy to knock up in Pi-land, and can then see if it's fast enough for your needs?