Hi Tinyfpga
Tinyfpga wrote: Thu Feb 13, 2025 7:20 pm
from "Read the docs"
BGET [#ch\position,] [item *[,item]*..]
Does -
"Each item to be fetched must therefore be either an integer or a floating point variable."
Mean -
Each item fetched must be either and integer or a floating point variable depending on whether the item is
stored as va% or va.
The result looks same except that the variable va% is stored internally as an
integer and the variable va is stored as a floating point number both in the range 0..255.
Correct, it is trying to convey that:
a) A single byte will be read from the channel for each named variable, thus a cardinal value, in the range 0-255.
b) If more than one variable is provided, more than one byte will be read.
c) The byte value will be 'coerced' in to its target variable type, % or FP.
Compare that to the definition of the later version of BGET under SMSQe, which will also accept a 'sub-string of a string array' as the destination variable (i.e. with an implicit or explicit range), such that multiple bytes - up to the length of the substring - will be collated into that substring.
Whether or not the earlier 'pre SMSQe' TK2 BGET supported substring slices, I cant say.
Note that, if you're using Marcel's v2.32 or later update to TK2 (i.e. long after that TK2 Manual was written), you may well be using the SMSQe variant anyway, so the SMSQe manual definition is relevant.
Tinyfpga wrote: Thu Feb 13, 2025 7:20 pm
I assume floating point numbers take up more space in memory and are slower to manipulate.
Yes, your assumption is (mostly) correct, but as mentioned below, % variables in interpreted SuperBASIC under QDOS often prove as slow to process as FP. To get the full benefit of % variables, you need to either compile or run Minerva or SMSQe...