Seems like it should work. Though you could consider putting the 128 byte table and maybe all the relocator in the launcher.
Then use the common launcher could be used for any CR. -- John. On Mon, Jun 4, 2018 at 8:11 AM, Ken Pettit <[email protected]> wrote: > Steve, > > Well, for the .CR file, I am thinking of a small routine (assisted by > BASIC) that would "relocate" the binary in the .CR file, similarly the way > Ron Wiesen was investigating. Ron was looking into a linked-list of > addresses that needed to be updated. This linked list will grow as the .CR > file grows. I haven't identified that this is 100% bullet-proof, but what > I was thinking is a way that would have a fixed size relocation program. > What I'm thinking is: > > 1. Place all variables and strings at the end of the code (i.e. all code > is in a contiguous block). > 2. Put a 128 byte table in the .CR holding the number of bytes for each > opcode that isn't "MOV A,C, MOV D,B, etc.". Those 128 are all 1 byte. > 3. Put a routine in the .CR to identify if the opcode in A uses an > address. This is a simple CPI value / RZ routine with no branching. > 4. Write a routine (probably in ALTLCD) to test if "HL < .CR start" and > HL > .CR end". In other words, is the opcode addressing the .CR space. > 5. Scan through the code, one opcode at a time. > 6. Call the routine to test if the opcode uses an address. If it does, > call the routine to test if the address is within the .CR file > 7. Calculate new address for any opcode that needs it and poke it back to > the .CR. > 8. Use the opcode length table and test for MOV opcode to calculate the > offset to the next opcode (i.e. skipping over operands). > 9. Stop when you see a MOV B,B opcode (who ever uses that anyway?). > > Calculations for "old .CR location", "new .CR location" and address > adjustment distance could be performed by the .BA loader and poked into the > relocation routine withing the .CR prior to calling it. > > Ken > > > > On 6/4/18 7:52 AM, Stephen Adolph 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. >>>>> >>>> >>>> >>> >> >> > >
