In some applications it is useful to have a transmit and/or receive buffer for Com1 that is larger than the default. On native mode devices, it is necessary to define a new queue, initialize it, close Com1 and then open Com1 using the new queue(s). While this achieves the objective, it requires run-time code and wastes the RAM dedicated to the default queues.
For native mode devices, you can specify the default size of the Com1 transmit queue or the receive queue or both using new directives as shown below. The presence of these directives changes the size of the respective Com1 queues before the back-end compiler produces the native code. Consequently, no run time code is produced to effect the change no RAM is wasted.
Don_Kirby wrote:Could this same method be implemented for VM devices as well? It would be good to remain as consistent/compatible as possible between the two.
I think the answer to this question is no. Don indicates that it is for native mode devices only and here is why.
These constants define the size of the buffers that are used for compiling the code. In the case of VM mode, the ZBasic Virtual Machine has already been compiled with these sizes and is installed inside your ZX device. When the ZVM starts up, it automatically opens the com port for your application.
When you use the ZBasic code to create new buffers and attach them to the com port, this is taking up additional RAM - the old buffers as compiled into the ZVM still exist in RAM but are simply not used.
Don_Kirby wrote:Could this same method be implemented for VM devices as well?
Mike's analyis is correct with regard to the queue sizes. It would be possible to implement setting the default speed.
Don_Kirby wrote:It would be good to remain as consistent/compatible as possible between the two.
That is our goal and we are working to realize it. For example, the methods of setting the heap limit were first implemented in native mode and then were ported to the VM devices (not yet released).
Thanks for the explanation. I was under the assumption that the VM devices created the queue on-the-fly. I hadn't realized that the existing queue space simply goes to waste in that case.
Don Kinzer wrote:It would be possible to implement setting the default speed.
From a usability standpoint, it seems like it would be best to make as much as possible compatible from VM to Native. However, the option remains to leave related groups of functions as 'Native Only' (or 'VM Only' for that matter). My thinking on the latter is that it would most likely be easier for newcomers to the platform without some of the more esoteric commands. Need more capability? Step up to the native mode devices.
I'm quite off topic, but it's something to think about when back-porting to the VM devices. This is a good example of the 'just because you can...' mentality. Of course it's up to Don to decide how much work he should put into bringing native mode features to the VM side of the coin. We all certainly agree that more features is a good thing, but where does the line get drawn?