On Mon, Aug 15, 2022 at 4:52 AM Stephen Adolph <[email protected]> wrote:

> I encode the data to avoid these values  If the byte matches the above
> criteria, I use "/" to denote "encoded" and then I follow with the value of
> the byte +128.
>

Good idea, but I can't as I am going to be indexing into the file given a
fixed record size.

On Mon, Aug 15, 2022 at 12:09 PM John R. Hogerhuis <[email protected]>
wrote:

> There is no limitation on the characters a binary file contains. But,
> binary files are harder to use, since you cannot open them directly, you
> can only load them back into RAM at their reserved load location... which
> itself creates a second copy of the data doubling RAM requirements.
> Alternatively if you have a CO in the RAM file system you could access the
> directory entry and peek the contents directly. This skips a decode
> operation.
>

I was planning on accessing the file directly without loading it. I need
less than 1% of the file, but which 1% changes every day. I already have
the code for that working, albeit for .DO files.

Is there a manual where the .CO file format is defined? I presume there's a
header I'll have to skip to get to my data, but what is its format? Also,
how can I render a .CO file harmless if a user accidentally tries to load
it. For example, can I set the reserved load location to be 0000 so it'll
write to ROM?


> If you want to create a binary file, you need to create a CO file by
> saving a range of memory to a CO file. To create the initial contents you
> would POKE your bytes into a reserved region of memory.
>

That would be the simplest way, but I'm trying to avoid duplicating the
file in memory. Has anybody ever tried first creating a .DO file of the
correct size in BASIC and then twiddling the RAM Directory's attribute byte
so that it is a binary file? Once I have the file's address, I could just
poke directly into it and save the copy. Right? Or am I missing something?
(For example, after creating a file, does the Ram Directory get updated? I
already noticed that I need to use CLEAR at the start of my program since
the file pointers are stale after doing an EDIT in BASIC.)


> Another topic is embedding binary data into a tokenized BASIC program, for
> example in strings, in REM statement and in high-numbered unlistable lines
> of tokenized BASIC. That's also tricky but can result in machine code that
> can be run directly. You actually have to specially craft your ML code to
> do this.
>
> -- John.
>

You always amaze me with ideas that are so far over my head that I can only
aspire to someday make use of them. Having the data embedded in the BASIC
program would be fun, but a requirement of this program is that it will run
on Model 100/102, Tandy 200, and NEC PC-8201/A/8300. (I might add Olivetti
M10 and Kyotronic KC-85, but I can't find the technical reference manuals
that have the address for the RAM Directory.)

  —b9

Reply via email to