[Coco] Programming help needed

[William Astle]

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.