Hey guys,
Looking at this a bit, it seems because of the restrictions imposed by
BASIC with regard to binary values less than 32 decimal, the only real
viable way to do execute in-place ML code would be to imbed it in a .DO
file. Then the only restriction is that you can't have 26 decimal (the
End Of File character). This is much less restrictive, though it would
require distributing the BASIC program with a .DO file as a dependency.
For execute in place, you could even implement a relative branch
mechanism so you don't have to recalculate jump addresses when the .DO
moves.
Ken
On 5/31/18 4:49 AM, Stephen Adolph wrote:
John I think a scheme like that could work, however you'd need to
eliminate all codes under 32decimal. To run in place, you lose the
ability to encode/decode the problematic characters.
finding the DATA statements in RAM can be done but it is a bit of
work. I think you'd have to start from the directory table and trace
out the line by line starting addresses from there.
On Wed, May 30, 2018 at 3:15 PM, John Gardner <gof...@gmail.com
<mailto:gof...@gmail.com>> wrote:
Or, for really evil results, you can execute your embedded code
in place - I think. I have'nt tried this on a MT, but it works a
treat
on TI CC-40's & TI-74's, 8-bitters of a similar vintage. Of course
you have to keep track of where your code is in memory...
I actually wrote a tool once (in QB) that would take a .lst file and
turn the opcodes into DATA statements, with offsets & jumps in
the right places; a TI-BASIC DATA statement length is 80 Bytes
max, not 255, so more than one is sometimes needed, & there's
some overhead in the jumps, but an EXEC statement is pretty fast...
Too much fun... "8)
...
On 5/30/18, Stephen Adolph <twospru...@gmail.com
<mailto:twospru...@gmail.com>> wrote:
> I often want to embed ML into basic programs. There are 2 ways
that I use
> 1) make a string of binary and assign it to a basic string
variable. (use
> VARPTR)
> 2) include data statements that contain the ML binary, with
some encoding,
> and use a routine to poke into memory
>
> regarding (2)
> I've seen 2 methods
> 1) encode data as decimal numbers
> ex. Data 125, 34, 56 etc
>
> 2) encode data as hex characters
> ex. Data C9F501 etc
>
> Neither of these are really optimal because they expand the size
of the
> code by 2 -3 x
>
> I've come up with an alternative to this which I'm now using.
The raw
> binary, with some code changes, can be directly embedded in data
> statements, in quotes.
>
> ex. Data "$%#(Lop" etc
>
> gotchas:
> 1) all binary codes <=32 must be mapped to special sequences to
avoid
> problems with BASIC
> 2) the " character has to be mapped to a different sequence
otherwise you
> confuse BASIC
>
> I use the "/" as a special symbol to mean "special sequence" and
I map all
> characters <=32, + " + / by adding 64d to each character.
>
> Ex. if the code 0Dh is encountered in the binary, it would get
transformed
> to "/" + chr$(13+64).
>
> Decoding is straightforward - look for / and subtract 64 from
the next
> character.
>
> Anyhow the net result is very compact with a minimal poke
routine. I
> compile my machine code into Intel HEX format, run a simple
program to
> encode the data into sets of DATA statements, and copy the
resulting text
> into a .DO file.
>
