Thanks! Stephen's encoding scheme <https://www.mail-archive.com/[email protected]/msg06926.html> from 2018 seems like it might be efficient enough to work. Just to keep the record straight: I was confused about NULL being a problem, it is ASCII 26 (^Z) which cannot exist in DO files. EDIT has cursor positioning trouble with embedded ASCII 127 (DELETE), but doesn't remove it. BASIC programs, when tokenized, cannot contain DELETE or any characters less than 32 (space) — other than 9 (TAB).
—b9 On Sat, Feb 14, 2026 at 10:33 AM John R. Hogerhuis <[email protected]> wrote: > You can look up discussions on the list for "alternative relative branch" > and execute in place and position independent code for ideas. > > -- John. > > On Fri, Feb 13, 2026, 11:14 PM B 9 <[email protected]> wrote: > >> On Thu, Feb 12, 2026 at 11:26 PM John R. Hogerhuis <[email protected]> >> wrote: >> >> I mean that programs only access memory they are documented to use. There >>> is no API for this. One way would be shipping your program with a >>> relocating loader which communicates to the user the memory range it will >>> occupy for running and for data. >>> >>>> I’m beginning to think a CO file is maybe too difficult for my target >>>> audience, so I ought to look into how to make a BASIC loader that takes as >>>> little space as possible. >>>> >>> I think that's a good idea, though interestingly BASIC variants >>> particularly at a tokenized BASIC level might be a bigger fork in the road >>> than CO files. >>> >> Did someone here once tell me that any character, except for a NULL, >> could be stored in a BASIC string? What about DATA statements? >> >> >>> Maybe only support .DO formatted BASIC. Or generate tokenized basic >>> versions for incompatible variants. >>> >> A single .DO file sounds like a good idea as I would like there to be one >> set of instructions so people don’t have to think and figure things out. A >> program that is supposed to identify the machine type should definitely not >> require people to know what kind of machine they have. >> >> If Brian’s co2ba script is typical, BASIC’s filesize expansion is going >> to be killer at about 250%. Double that in order to actually run it. (It is >> mostly data, not tokenizable BASIC). For example, >> File Bytes >> CRCPSH.CO 1054 >> CRCPSH.DO 2691 >> CRCPSH.BA 2588 >> >> (Brian: you may want to call it co2do. From the name, I had presumed it >> output only tokenized BASIC. Reading it into Virtual-T as a .BA file caused >> a segmentation fault. Minor typo: The co2ba script worked once I removed >> the extraneous quotation mark being added near the end of line 3. Feature >> request: it’d be swell if it did a quick check against MAXRAM and refused >> to crash the machine if the program length was too long.) >> >> And I like the idea of embedding ML directly in BASIC REMs or strings, >>> either with special position independent code or self-relocating. It can be >>> very compact and require minimal "load time" overhead. >>> >> That sounds intriguing. Do you have any examples you can share? How do >> you handle NULLs in the data? How do you handle programs that are too long >> to fit in a single line or string? >> >> —-b9 >> >
