I'm presently working on the Bidirectional Packet Protocol (BDPP) for the Console8 (and any other Agon platform), which affects both the MOS and VDP for it. When BDPP is activated, this changes how communication is done between the EZ80 and ESP32, enabling bidirectional data packet flow. For example, a BASIC app can request information from the ESP32, and get data back, in a buffer, outside of the existing "system variables".
Sending packets implies that when driver-owned (as opposed to app-owned) packets are used (e.g., by PRINT, PLOT, VDU, RST &10, and RST &18, in BASIC), if the driver-owned packets are not completely filled (32 bytes), they must be flushed manually (by RST &20), or they are not queued for output to the ESP32. BDPP supports having multiple packets queued for both TX and RX. (It uses interrupts for all I/O on both CPUs.)
When BDPP is active, we still want the "user experience" to be similar to the existing mechanics (any BASIC statement that affects VDP does so almost immediately, because serial data bytes are sent out right away).
Since BDPP buffers data, that can affect the "user experience".
To reduce that effect, the BDPP edition of MOS has some strategic calls to its "flush packet" function for BDPP. Wherever MOS makes a VDU call, such as to obtain the cursor location, it also does a flush call, to force the command to go to VDP, because typical VDU commands don't fill a packet. MOS also has flush calls in its "edit line" function, so that typed characters are made visible immediately.
In BASIC (especially the 24 bit edition), it may make sense to place flush calls at certain points in the code, so that BASIC statements that send output to VDP will not leave data hanging (in a packet buffer). For example, in the BASIC "exec" loop, whenever a new statement (program line) or a colon separator is reached, it may make sense to flush there. Of course, any program that uses BDPP can perform its own flush operations as needed, via RST &20.
If BDPP is disabled, communication works as before (direct transmissions, without any packet enclosures).
It is only necessary to flush between (or after certain) BASIC statements if (1) a statement affects VDP, and (2) BDPP is enabled.
I am willing to discuss the best approach for any necessary modifications to BASIC, and/or to make the necessary changes in a branch, for review. Again, any program (in BASIC, C, assembler, or whatever) will always have the option to perform its own flush operation, if desired, and there are certainly cases (scenarios) where that becomes necessary, for the "user experience".
I'm presently working on the Bidirectional Packet Protocol (BDPP) for the Console8 (and any other Agon platform), which affects both the MOS and VDP for it. When BDPP is activated, this changes how communication is done between the EZ80 and ESP32, enabling bidirectional data packet flow. For example, a BASIC app can request information from the ESP32, and get data back, in a buffer, outside of the existing "system variables".
Sending packets implies that when driver-owned (as opposed to app-owned) packets are used (e.g., by PRINT, PLOT, VDU, RST &10, and RST &18, in BASIC), if the driver-owned packets are not completely filled (32 bytes), they must be flushed manually (by RST &20), or they are not queued for output to the ESP32. BDPP supports having multiple packets queued for both TX and RX. (It uses interrupts for all I/O on both CPUs.)
When BDPP is active, we still want the "user experience" to be similar to the existing mechanics (any BASIC statement that affects VDP does so almost immediately, because serial data bytes are sent out right away).
Since BDPP buffers data, that can affect the "user experience".
To reduce that effect, the BDPP edition of MOS has some strategic calls to its "flush packet" function for BDPP. Wherever MOS makes a VDU call, such as to obtain the cursor location, it also does a flush call, to force the command to go to VDP, because typical VDU commands don't fill a packet. MOS also has flush calls in its "edit line" function, so that typed characters are made visible immediately.
In BASIC (especially the 24 bit edition), it may make sense to place flush calls at certain points in the code, so that BASIC statements that send output to VDP will not leave data hanging (in a packet buffer). For example, in the BASIC "exec" loop, whenever a new statement (program line) or a colon separator is reached, it may make sense to flush there. Of course, any program that uses BDPP can perform its own flush operations as needed, via RST &20.
If BDPP is disabled, communication works as before (direct transmissions, without any packet enclosures).
It is only necessary to flush between (or after certain) BASIC statements if (1) a statement affects VDP, and (2) BDPP is enabled.
I am willing to discuss the best approach for any necessary modifications to BASIC, and/or to make the necessary changes in a branch, for review. Again, any program (in BASIC, C, assembler, or whatever) will always have the option to perform its own flush operation, if desired, and there are certainly cases (scenarios) where that becomes necessary, for the "user experience".
Thanks.