[Coco] Programming help needed

[Arthur Flexser]

I think you may be mistaken about a string terminating with a zero.  The
string's length is conveyed by its descriptor byte in the variable table,
so there'd be no need for a special termination character.

Art

On Sun, Dec 2, 2018 at 6:24 AM tim franklinlabs.com <tim at franklinlabs.com>
wrote:

>    A string terminates with a zero. If there's a chr$(0) somewhere in the
>    midpoint of the string, BASIC would see that as an "End of String" and
>    stop processing. Only part of the string data would be saved. I haven't
>    verified this but that's what I would expect.
>
>      On December 2, 2018 at 1:19 AM William Astle <[1]lost at l-w.ca> wrote:
>      On 2018-12-01 5:59 p.m., Paul Shoemaker wrote:
>
>      Need some advice. I am trying to store to a disk file a 48x40
>      section from a PMODE 4 screen.
>      The method I am attempting to use is to peek the byte values using a
>      nested loop and save them as a string. For example, A$ = A$ + CHR$
>      (PEEK(&HE00+X+(Y*32))). Note I am storing the byte value as a CHR$
>      because doing so makes the completed string length only 240 bytes
>      long. Creating the string is working fine; I have validated that.
>      Saving the string to a disk file is not working, however. When I
>      execute a WRITE #1,A$ followed by a PUT #1,<record #>, Disk BASIC is
>      not saving entire contents of A$. I believe it is parsing the string
>      as it goes or something, as it seems to be ignoring or even stopping
>      on some "special" CHR$ codes.. like CHR$(0).
>      Is there a way around this?
>      Thanks!
>      -Paul
>
>      WRITE should be exactly equivalent to PRINT except that it will
>      surround
>      string data with quotes (and numeric data won't have quotes). I
>      assume
>      you're using READ or INPUT after a "GET" as a way to get the result
>      back. That *will* stop reading at a NUL byte since NULs terminate
>      parsing strings in the interpreter.
>      Basically, your problem is that you are using random files wrong.
>      What
>      you're doing is okay for text formatted records. However, it's not
>      binary safe. What you should be doing is:
>     1. Open the file with in random/direct mode with a specified record
>        length.
>
>     2. Use FIELD to set up variables for the record:
>
>      FIELD #1,<record size> AS F$
>     3. Put your data into F$ using LSET (or RSET if you want it right
>
>      justified). DO NOT simply assign to F$. In fact, don't assign to F$
>      at
>      all since it will disassociate it from the file record. For example:
>      LSET F$ = A$
>     4. Now use "PUT #1, <record #>"
>
>      Reading works the same but use "GET #1, <record number>" and then
>      access
>      the string variable specified in the FIELD command. Again, don't
>      assign
>      to that variable since that will break its association with the file
>      record.
>      The above *is* binary safe.
>      Obviously, it can be more complicated than that by having multiple
>      fields for a particular file. You can even have multiple record
>      structures using different variable names for the same file.
>      --
>      Coco mailing list
>      [2]Coco at maltedmedia.com
>      [3]https://pairlist5.pair.net/mailman/listinfo/coco
>
> References
>
>    1. mailto:lost at l-w.ca
>    2. mailto:Coco at maltedmedia.com
>    3. https://pairlist5.pair.net/mailman/listinfo/coco
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>