Sounds like you're thinking of HXFER:

https://github.com/LivingM100SIG/Living_M100SIG/blob/main/M100SIG/Lib-10-TANDY200/HXFER.DOC

—b9

On Sun, Mar 8, 2026 at 9:35 AM John R. Hogerhuis <[email protected]> wrote:

> To make a relocatable program the most straightforward way is to use a
> assembler / relocating linker combination.
>
> The next best thing is to assemble at address zero and 1 addresses and
> detect the word sized differences to determine the offsets within the zero
> assembled file. This works for most things but I think not all.
>
> For a utility that just generated the loader I'd think you'd want to pick
> a relocatable object code format and take that as your input. I think
> standard ones exist? Probably a hex file format.
>
> -- John.
>
> On Sun, Mar 8, 2026, 8:52 AM Brian K. White <[email protected]> wrote:
>
>> It would be no problem to add a mechanism for encoding placeholders for
>> relocatable values, and for supplying those values, but the values
>> themselves would have to come from somewhere.
>>
>> I don't imagine it's good enough to just change the arguments to certain
>> opcodes. I just assume that to actually relocate something, you have to
>> know how that binary works to know what to change to get the desired end
>> result?
>>
>> There are at least a few generic relocators already out there in m100sig
>> I can look at to see what they do.
>>
>>
>>
>> But translating from one machine to another seems ambitious indeed.
>> I mean it's just a loader, the presumption is that the binary is meant
>> for the platform!
>>
>> That would be a great tool to have, but I feel like that's a separate job.
>>
>> A couple years ago I ported ca2ba.100 from 100 to kc85, and I seem to
>> recall I had to do some deducing and guessing. There was only 3 or 4
>> numbers that needed to be changed, but I think none of them were
>> directly call addresses. But I was able recognize them as being offsets
>> into some known structure like the start of the ram fs.
>> And I imagine that was a trivial example about as easy as it gets.
>>
>>
>> https://github.com/LivingM100SIG/Living_M100SIG/blob/main/M100SIG/Lib-08-TECH-PROGRAMMING/CO2BA.100
>>
>>
>> https://github.com/LivingM100SIG/Living_M100SIG/blob/main/M100SIG/Lib-08-TECH-PROGRAMMING/CO2BA.K85
>>
>>
>>
>> On 3/8/26 09:01, Stephen Adolph wrote:
>> > Two extensions that would be nice to have.  What do you think?
>> >
>> > 1.  Some way to identify and adjust addresses to enable relocatable
>> > code.  I know teeny has this feature.  Can we have another encoding
>> > element for that?
>> >
>> > 2.  Adjust ROM calls per platform.   This might require another method
>> > altogether.  Maybe there would need to be a library of calls and some
>> > code to identify the call.  More ambitious.
>> >
>> >
>> > Also have we landed on an agreed encoding?
>> >
>> >
>>
>>
>> --
>> bkw
>>
>

Reply via email to