Hey Steve,
Yes, then you aren't as restricted on the opcodes plus you don't need
any encoding. You just need to ensure 1Ah doesn't appear anywhere. I
suppose if your ML code snippets don't need to perform any jumps to
address that require a byte <32, it works out. Also, I guess if you need
something like LXI B, LXI D, DAD B, etc. then you can just perform the
math the long-hand way.
Ken
On 5/31/18 11:51 AM, Stephen Adolph wrote:
Ken,
so you are suggesting the .BA file calls into the .DO file? interesting.
When I embed programs as strings, I write the program to avoid codes
<32 d.
ex.
mvi a,00
is bad
xra a
is good.
On Thu, May 31, 2018 at 2:34 PM, Ken Pettit <petti...@gmail.com
<mailto:petti...@gmail.com>> wrote:
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.
>
