Thanks, Tom. Given that I don't have any blank tapes, probably any I pick
up at the thrift store will probably come pre-installed with "80's Rock"
that I can listen to before I record computer bleeps and bloops over!
Trouble is, I'm not sure if I have a cassette cord. Is it the same as the
one for the Color Computer?

On Thu, Feb 12, 2026 at 3:26 PM Tom Cronin <[email protected]>
wrote:

> You might consider loading it over the cassette port if you have at least
> the audio cables.
>
> 1) Load the .CO file into a machine with larger memory
> 2) save the CO to the cassette (or computer audio pretending to be a
> cassette - play 80s rock in the background for verisimilitude)
> 3) Load the audio onto the 8kb machine via the cassette mechanism (CLOADM).
> 4) LOADM to get into the correct memory location
>
> You'd still have two copies of the CO file but wound't need any BASIC
> program or Teensy memory resident at least.
>
> On Thu, Feb 12, 2026 at 10:44 AM B 9 <[email protected]> wrote:
>
>> I created a single machine language .CO file
>> <https://github.com/hackerb9/crc16-modelt/blob/idtest/CRC16.CO> which
>> should run on any of the Model T variants (at least it does in emulation),
>> but now I’m trying to figure out how it would be loaded onto them. As a
>> binary it is not easy to transmit.
>>
>> Ideally, I’d have a BASIC loader that would POKE the program into memory,
>> but the problem with that is that my .CO file is already 1.5 kilobytes
>> long, so it barely fits into memory on an 8K machine. (Which, in itself
>> wonders me. Please see my calculation below and correct me if I’m
>> mistaken.) I believe a BASIC loader would expand the file size and simply
>> not fit.
>>
>> So my first question is: Is there something like TEENY for all Model
>> T’s,even for the less common variants like the Olivetti M10, that can
>> receive binary files over the serial port?
>>
>> My second question is: Am I confused about the 1.5K limit on
>> cross-platform .CO files? I’m fairly new to assembly language on these
>> devices and have made some guesses based on what I’ve been observing in the
>> Virtual-T memory viewer. Let me state my presumptions explicitly, so you
>> all can help me figure out where, or if, I’m going wrong.
>>
>>    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.
>>    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?]
>>    3.
>>
>>    The area in high memory which the .CO file is copied to before it
>>    runs must be reserved using the command CLEAR 256, *x*, where 256 is
>>    the space reserved for strings, *x* is the lowest memory address the
>>    .CO file can occupy, and the builtin variable *MAXRAM*-1 is the
>>    highest.
>>    4.
>>
>>    I’m defining *MINRAM* as the lowest address which can be reserved
>>    using CLEAR. The value of MINRAM is higher on machines with less memory.
>>    5.
>>
>>    To run cross-platform, we’d need to know the largest MINRAM and
>>    smallest MAXRAM across all the Kyocera kin. The Tandy 200 has a MAXRAM of
>>    61104. The 8K Model 100 has a MINRAM of 58044 (with no files and setting
>>    string space to 0).
>>    6.
>>
>>    Thus, the largest cross-platform machine language file would be:
>>
>>        [image: \frac{(61104-58044)}{2} = 1530 \text{bytes}]
>>
>>    and the space from 59574 to 61103 should be reserved for the .CO file
>>    using the command
>>
>>     CLEAR 0, 59574
>>
>>
>> What is the right way to load a larger file? Or is it not possible and I
>> need to solve my problem in a different way? (I’ve already had to compress
>> the data strings to get it to fit at all. I could do more, but the code
>> would be uglier and harder to extend in the future.)
>>
>> Thanks all for any help or suggestions,
>>
>> —b9
>>
>

Reply via email to