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