Hi Steve -
My original scheme (for TI-74) was to make the 1st pgm line
the DATA statement, in the form: 100 DATA ### ... ###
The "#" character are simply placeholders, up to 80 chars,
the max length of a DATA statement in TI-74 BASIC.
A TI-74 "main" pgm always starts at HIRAM; individual elements
of the DATA statement will alway be at a fixed offset from HIRAM,
thus at a known address. One then opens the DEBUG monotor &
replaces the placeholders with the desired code. To run the code
BASIC executes CALL EXEC(the desired execution ADDR).
Once the placeholders have been replaced with code, the pgm can
be saved to PC as a text file (".b74", in TI74 parlance), or as an
executable (".pgm"), and the DATA statement willl survive in situ.
Note that READing the DATA sttement is not necessary - I wonder if
READs are a factor in having to offset non-printing chars on the MTs?
I'm about to move, & my 8201a's are already packed... Another thing;
I saw a Ron Wiesen pgm once where it seemed he'd embedded machine
code in BASIC, but that was long ago, & memory is unreliable...
On 5/31/18, Ken Pettit <[email protected]> wrote:
> Hi Steve,
>
> Search through BASIC lines? Nah, don't do that! Put a dummy DATA
> statement and then your ML code:
>
> 10 DATA "a", "encoded ML"
>
> Then do a READ D$. The BASIC ROM will perform the search and update
> address FBB8H (on M100/T102) with the address where READ will start it's
> search next. Just use that variable as your starting point. Of course
> you still have to avoid opcode and operands in the low region of the
> ASCII table.
>
> 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 <[email protected]
>> <mailto:[email protected]>> 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 <[email protected]
>> <mailto:[email protected]>> 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.
>> >
>>
>>
>
>
