here is an example - RAMTST - 64704 to 64936, so 232 bytes this was the intel hex
:18FCC000CD3142F33E01D3E02E0926FECD8EFD21000036802E0926BE62 :18FCD800CD8EFD21000036402E0926FECD8EFD2100007E32A8FDAFD37A :18FCF000E0FB3E0232A7FD3AA8FD4F3AA7FDB9C83C3C32A7FD2101010D :18FD0800CD7C423AA7FD6F2600CDD439F33E01D3E02E093AA7FDF6809B :18FD200067CD8EFD2100003AA7FD77237CFE80C227FD2E0A3AA7FDF687 :18FD38008067CD8EFD2100803AA7FDBEC279FD237CFEC0C240FD2E0A6B :18FD50003AA7FD3CF68067CD8EFD2100803AA7FDBEC279FD237CFEC07A :18FD6800C25DFD2E0A2682CD8EFDAFD3E0FBC3F7FC2E0A2682CD8EFDE4 :18FD8000AFD3E0FBCD2942CD2942CD2942C93AC03A3AB8F03AF2F03A31 :11FD980034F03AB0F03A31F03ABFF037377EC9000063 :00000001FF This was the encoded result - 445 bytes including all the overheads. Here the Intel HEX file defined the length of the data field -24 bytes. longer data fields would improve efficiency a bit. "escape" character is / so whatever follows / must be reduced by 128 to represent the original code. /ÿ = end of file 14000 DATA 64704 14001 DATA "Í1Bó>/ Óà./‰&þÍŽý!/€/€6€./‰&¾" 14002 DATA "ÍŽý!/€/€6@./‰&þÍŽý!/€/€~2¨ý¯Ó" 14003 DATA "àû>/‚2§ý:¨ýO:§ý¹È<<2§ý!/ / " 14004 DATA "Í|B:§ýo&/€ÍÔ9ó>/ Óà./‰:§ýö€" 14005 DATA "gÍŽý!/€/€:§ýw#|þ€Â'ý./Š:§ýö" 14006 DATA "€gÍŽý!/€€:§ý¾Âyý#|þÀÂ@ý./Š" 14007 DATA ":§ý<ö€gÍŽý!/€€:§ý¾Âyý#|þÀ" 14008 DATA "Â]ý./Š&‚ÍŽý¯ÓàûÃ÷ü./Š&‚ÍŽý" 14009 DATA "¯ÓàûÍ)BÍ)BÍ)BÉ:À::¸ð:òð:" 14010 DATA "4ð:°ð:1ð:¿ð77~É/€/€" 14011 DATA "/ÿ" for completeness, here is the program to decode and poke into RAM: 13000 CLS:PRINT"loading ML code...";:READQ 13030 READP$:e=0:FORX=1TOLEN(P$):a$=MID$(P$,X,1) 13040 if a$="/" then e=1:goto 13070 13050 if asc(a$)= 255 then return 13060 print@20,q:POKEQ,asc(a$)+128*(e=1):Q=Q+1:e=0 13070 NEXTx:GOTO13030 On Thu, May 31, 2018 at 7:49 AM, Stephen Adolph <twospru...@gmail.com> 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. >> > >> > >
