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> 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> 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> 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. >> > >> > > >
