Enhanced comms with VDP

[stevesims]

As noted in AgonPlatform/agon-vdp#8 and AgonPlatform/agon-vdp#9 it would be good to support an enhanced communications protocol between MOS and the VDP.

This would allow for multiplexed commands to be executed - for example allowing a lengthy upload of a bitmap or sound sample to the VDP whilst simultaneously updating the screen to indicate progress of that activity.

[stevesims]

the solution implemented inside the VDP in AgonPlatform/agon-vdp#30 is to work with the existing protocol, adding in a command VDU 23, 0, &A0, bufferId, command, <args> to allow buffered commands.

arguably from the MOS side, no additional support is really needed, however there may be value in adding some API calls to wrap up buffers to send, call buffers, and dispose of them. those would be simple wrappers around the VDU 23, 0, &A0 commands, helping to ensure that correct numbers are sent, etc.

[stevesims]

one further note here - it would be useful to support some improved options for sending data from the VDP to MOS.

this is likely to be commands to send parts of a buffer back to MOS

[stevesims]

one potential option here is #41

having separate channels for communications with the VDP would have distinct advantages. I had two stumbling blocks with adopting the BDPP approach tho - firstly it required an active opt-in for programs to use it, and secondly I never managed to fully understand the code. something like BDPP would be very cool to have tho

for many functions however it is not truly needed.

as noted before, "buffered commands" gives a partial solution - it allows for a form of packet-based comms with the VDP. the major missing piece however is sending data back to MOS

one problem with the current protocol is that comms is not properly flow controlled, as noted against #57 however this is being addressed via #109 and AgonPlatform/agon-vdp#262

an additional problem with the VDP protocol at the MOS end only has a 16-byte buffer for received command packets. this is defined via VDPP_BUFFERLEN. obviously this can be increased, if that will help

our current VDP protocol has a byte of flags stored inside MOS to indicating whether a particular type of packet has been received. one bit of that byte that is currently unused - it's earmarked in the MOS source for VDPP_FLAG_BUFFERED. the protocol doesn't directly tie particular messages to particular bits in the protocol status byte tho. instead there is just a simple table of sequentially numbered packet types that are handled - we're using 9 so far - each handler may set a status bit as desired, but does not have to.

we can add whatever new packet types we like. if a VDP tries to send a packet that MOS doesn't understand it will just be ignored. the current handler however is crude - if an unrecognised command byte is seen the incoming data bytes for that unrecognised command is not "consumed". it would make sense therefore to improve the current handler to properly consume bytes from unrecognised commands