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 want something that can be used immediately by pretty much anyone and I’d guess more people have serial cables than those funny audio cassette cords. Perhaps I should have mentioned my use case: Inspired by our Norwegian friend with his TRS-80 Televerkert Modell 100, I created a program which can run on any Model T and tell you if the system ROM installed is recognized or if it is one that is missing from our repository of known ROMs. It worked and didn’t take too much space, even when I added a 256 byte table to speed up the CRC-16 calculation. I imagine that if somebody finds a weird Model T in their great aunt’s attic, they might be willing to run a program, if it is not too difficult, to check if it contains a ROM we haven’t archived yet. However, I was having too much fun, and wanted it to not only say “Recognized”, but also print out the Make, Model, and ROM Variant. For example, “Olivetti M10, North America, Y2K patched”. We’ve got maybe 25 different ROMs (including split, merged, and patched versions) which adds another 512 bytes or so of text. Just adding those made the program too large and caused crashes on 8K machines (in Virtual-T). [Side question: Why do our computers blithely overwrite MAXRAM and beyond with LOADM? I would have expected at least a warning given the grave consequences. I added a little sanity check to my Makefile that looks at the first two bytes of the .CO to get the HIMEM address and then checks if the filesize would exceed MAXRAM. That solves the problem for me, but it seems like a strange oversight to not have such a simple check builtin to LOADM.] Since the model names were redundant across variants, I was able to compress the program significantly, but it just barely fits. If we find more ROMs, which I hope we do, my program, as is, wouldn’t be able to fit them. I had hoped somebody would tell me I’m wrong about how little RAM is available, but if no one does, I’ll have to compress the strings more or give up on the idea. 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. Again, any suggestions are appreciated! —b9 P.S. Is there any better source of system ROMs than http://tandy.wiki/Model_T_System_ROMs?
