Hey Steve,
Actually, the relative jump might be +6 if you use a DATA statment (you
have to skip the DATA token) or +8/+9 for a string (skip B=" or B1="),
assuming you had a DEFSTRB somwhere an don't need the '$' for string names.
Ken
On 6/4/18 7:34 AM, Ken Pettit wrote:
Hey Steve,
First, the T array was just an attempt to avoid hidey-holes. Also for
a 12-byte program it was smaller than a DATA statement with a FOR /
READ / POKE loop..
For prorams larger than 255 bytes, just put the follow-on code at the
next BASIC line. Then just do a relative jump over the BASIC EOL
marker and next line number. Counting the XTHL and RET, I think this
would be a relative jump +5. To get this without encoding a byte <
32d, encode it as:
PUSH PSW
MVI A,80h
ADE A,85h + OFF_ADJUST
But I still like the idea of .BA + .CR (Command Resoruce) file. I
shortened my .CR address lookup to only 1 line of BASIC code about 130
bytes long.
Ken
On 6/4/18 5:49 AM, Stephen Adolph wrote:
Ken,
a comment.
DADTHUNK code could expand from 14 bytes to 24 bytes, as you point
out, to shorten the calls in the program ML.
--> at this point, maybe a DATA approach for T(i) would be more dense
than assigning each T(i), with a read loop.
How do we embed programs larger than 255 bytes? If I understand
this, we have single programs contained in single strings.
It seems like it would be hard to have a large program segmented into
multiple strings.
any thoughts?
Steve
On Mon, Jun 4, 2018 at 7:27 AM, Stephen Adolph <[email protected]
<mailto:[email protected]>> wrote:
Ken,
Regarding T, interesting way to make a machine code routine in ram.
This is quite compact for a short routine, but I think this part
is equivalent to encoding the 14 bytes and poking into ALTLCD.
Is there something I missed in that?
IE you don't care how those 14 bytes show up, nor where they are.
Steve
On Sun, Jun 3, 2018 at 12:17 PM, Ken Pettit <[email protected]
<mailto:[email protected]>> wrote:
Hey Guys,
Okay, BASIC XIP code, as promised. This code was written
taking a "purest' approach where no hidey holes were used,
only BASIC allocated RAM. If hidey holes were to be used, I
believe the resulting assembly could be made smaller. A
short relative jump could be made to occupy only 5 bytes (MVI
A,offset + CALL helper_in_hidey_hole). This method does not
preserve A, it uses it as the relative jump distance. To
preserve A, it would need to be PUSH/POPed using the stack.
Also, looking at the number of instructions that have to be
executed to make this happen, I'm not sure the resulting ASM
code will be faster than BASIC, but it was a fun experiment. ;)
I developed / assembled the ASM code using the VIrutalT
assembler and then manually copied bytes into the BASIC
program. There are quite a few comments in the ASM code.
Again, the concept:
1. INT array T(0-6) is initialized using BASIC assign
statements with an ASM THUNK to perform DAD D operation.
2. VARPTR(T(0)) is passed to the ML program in H$ string.
3. The T() array address is store off so the ROM JUMPTHUNK
code will jump there (fixed CALL to jump to variable address).
4. The Accumulator holds a short jump distance.
5. Relative branching is done by:
MVI A, offset
CALL LOCATEME
CALL JUMPTHUNK
XTHL
RET
If a large ML program is needed in BASIC, one could
expand/modify the code above a bit and poke it into a hidey
hole. Then each relative jump would become:
MVI A,offset
CALL hidey_hole
Ken
On 6/2/18 2:56 PM, John R. Hogerhuis wrote:
Very nice. Code? :-)
— John.
