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
