The shape of the text cursor

[nvingo]

David's recollection is correct: using ; passes a 4-byte number, using , passes a 2-byte number, which is why it is curious that in this instance the command appears - I stress "appears" - to accept either.

Over to the experts ...

Simple, the intended 1-byte value of zero - eg.VDU 23,0,2,0,0,0,0,0,0,0 is being replaced with an equal number of 4-byte zeros - the VDU23 command uses how many it needs for data, then the rest are output and it just happens that (each extra) VDU0 has no obvious effect.
Now if the command had been VDU 23,0,2,123,234,12,23,32,17,65,99 but was typed as VDU 23,0,2,123;234;12;23;32;17;65;99
several non-zero values would be passed after VDU23 had taken enough data to work with, not only would there have been extra codes sent with their own undesirable effects but the data passed to the VDU23 command would have been corrupt: instead of 123,234 it would have received 0,0,0,123,0,0,0,234 etc.

[Hated Moron]

Simple, the intended 1-byte value of zero - eg.VDU 23,0,2,0,0,0,0,0,0,0 is being replaced with an equal number of 4-byte zeros

I'm not too sure why this thread has been resurrected after more than a year, but since it has I would want to point out that VDU never passes 4-byte values, only ever one-byte values - which is the default - or two-byte values when followed by a semicolon.

[nvingo]

...I would want to point out that VDU never passes 4-byte values, only ever one-byte values - which is the default - or two-byte values when followed by a semicolon.

I'm sure you're quite correct as that was my recollection from Acorn machine days, and I didn't believe Richard would change something so fundamental but:

I strongly encourage people NOT to mess with the commas/semicolons in these commands: as I recall, it determines whether BB4W passes the underlying system call 4 or 2 byte numbers

David's recollection is correct: using ; passes a 4-byte number, using , passes a 2-byte number, which is why it is curious that in this instance the command appears - I stress "appears" - to accept either.

[Hated Moron]

David's recollection is correct: using ; passes a 4-byte number

It's not difficult to test it:

Code: Select all

      *spool test.tmp
      VDU 30000;
      *spool
      F% = OPENIN("test.tmp")
      PRINT EXT#F%

Here that prints 2, not 4.

[nvingo]

I guess the two previous posters were confusing bytes and hexadecimal digits, as it was often the case in program listings that they would be presented as VDU ... &FFEE; instead of &FF,&EE (and again, my long absence from coding, I can't remember if it's Bigendian or Littlendian, ie. = &FF,&EE or &EE,&FF)
Edit:
As you say, easy to test. This snippet proves 2-byte ';' deliminated values are passed low-byte before high-byte

Code: Select all

      PRINT ~65,~66,~67,~68 REM get hex values for ABCD
      VDU &41,&42,&43,&44 REM display ABCD in byte order
      PRINT
      VDU &4142;&4344;  REM display ABCD with bigendian order
      PRINT
      VDU &4241;&4443; REM display ABCD with littlendian order

Again the fundamental conclusion is that in this instance comma-deliminated or semi-colon-deliminated parameters present no issue to the VDU parser in the OP instance only because all values are zero.

[Hated Moron]

I guess the two previous posters were confusing bytes and hexadecimal digits

I suppose that's possible, but it would be rather worrying (one of those posters is the forum's administrator and the other is his deputy!). The documentation is quite explicit:

"The VDU statement takes a list of numeric arguments (constants or variables) and sends their least significant bytes as characters to the currently selected output stream. A 16 bit value (word) can be sent if the value is followed by a semi-colon. It is sent as a pair of characters, the least significant byte first."

[nvingo]

I suppose that's possible, but it would be rather worrying (one of those posters is the forum's administrator and the other is his deputy!).

I agree posting unchecked misinformation (it was incorrect, whether it was hex digits or 32-bit words and 16-bit words they intended to impart), from a position of authority

The documentation is quite explicit:

"The VDU statement takes a list of numeric arguments (constants or variables) and sends their least significant bytes as characters to the currently selected output stream. A 16 bit value (word) can be sent if the value is followed by a semi-colon. It is sent as a pair of characters, the least significant byte first."

Thanks for checking.