Yeah, hidey holes the biggest being altlcd. And can always alloc big chunks dynamically on stack and stores pointers at fixed locations.
Another possibility would be for the program to lower HIMEM itself to allocate a fixed variable space. That doesn’t work if the user is already keeping stuff in HIMEM. — John. On Mon, Jun 4, 2018 at 7:52 AM Stephen Adolph <[email protected]> wrote: > the .CR file --- could it ignore the start end exe prefix? I think so. > so, just raw ORG at 0000 assembly. > > BTW variables need a solution-- probably best to use absolute addresses > and put those in hidey holes. > > On Mon, Jun 4, 2018 at 10:34 AM, Ken Pettit <[email protected]> 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]> >> 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]> 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. >>>>> >>>> >>>> >>> >> >> >
