On Thu, Feb 12, 2026 at 10:41 PM B 9 <[email protected]> wrote: > On Thu, Feb 12, 2026 at 6:48 PM John R. Hogerhuis [email protected] > <https://mailto:[email protected]> wrote: > > On Thu, Feb 12, 2026 at 10:43 AM B 9 <[email protected]> wrote: >> >>> >>> 1. >>> >>> A single .CO program can run on the Kyocera Kyotronic 85 and its >>> sister computers: TRS-80 Model 100, Tandy 200, Tandy 102, Olivetti M10, >>> NEC >>> PC-8201A, and NEC PC-8300. >>> >>> >> Not really. The ROMs entry points are different so you'd have to patch >> calls as you load. I think the CO header structure is the same for all, but >> not sure. >> > Yeah, I’m avoiding the ROM calls as much as possible and just using RST 4 > to print to the screen. At least on Virtual-T, that seems to work cross > platform. As you said, the CO header does seem to be the same, again, > presuming Virtual-T is accurate. Since some of the architectures don’t have > “LOADM”, I’ll probably tell people to select the .CO file from MENU which > seems to work everywhere. > > >>> 1. >>> >>> 2. >>> >>> All the Kyotronic kin must store a .CO file *twice* in memory: Once >>> in the filesystem and a second copy in high memory when it is loaded >>> through LOADM, RUNM, or by selecting it from the MENU. [Side question: >>> Does >>> distribution on cassette get around this limitation? Do all machines have >>> the same audio encoding format?] >>> >>> >> Not exactly? Yes if you want to keep it reloadable, you need both the >> file and the loaded image. >> But it is common to clear space, load the file into its execution area >> once, and then delete the CO file and it lives in the cleared space. Maybe >> create a trigger file so you don't need to remember the CALL entry point. >> But you don't need to keep two copies. >> > I see. That’s not what I need right now as the program would still be > limited to half the free memory size. > > If you have TS-DOS with DOS-ON you can clear then LOADM the file directly >> to its execution area and bypass the file system. And you can do the same >> trick with a cassette file. CLEAR first, then CLOADM. >> > Thanks, that’s what I wanted to know. I’m not sure if I should pursue it, > but it seems like it’d double the available space for the program. If I’m > understanding you correctly, on an 8K M100 I could do something like this: > > MAXFILES=0CLEAR 0, 57777 > CLOADM > > and that would give me 3,327 bytes, which should be plenty. (It would be > 5183 bytes if I could use the M100’s MAXRAM, but I want the same binary to > run on the T200 as well, and its MAXRAM is 1856 bytes lower). > > and you can have multiple programs there if they mind their manners. >> Not many on an 8K machine :-) >> > Not many at all! So, for “minding manners”, does that mean checking the > current HIMEM and relocating the code as it gets POKEd into memory? Are > there standard programs for doing that? And actually, in general, what is > considered the best way to convert a Machine Language program to a BASIC > loader? >
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. Maybe only support .DO formatted BASIC. Or generate tokenized basic versions for incompatible variants. 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. -- John.
