Thanks Ken. That is definitely an option if I want to put the individual Pokes into the basic program. Which I may end up having to do. I was hoping for some bit of memory that I could count on always being there but at this point I am realizing that there may not be such a thing. I have the whole thing working if I poke the 7 bytes into ram (right now the top of ALTLCD). I can call that routine and it loads the LINE code into ALTLCD and the BASIC program is happy to use it. I put another chunk of code in the ROM for the XFER program and the same approach works to pull it from ROM into ALTLCD and then run. The only catch right now is the 7 byte load routine has to be poked into ram and then called.
Getting closer Kurt On Thu, Sep 12, 2019, at 1:28 PM, Ken Pettit wrote: > Hey Kurt, > > For the 8201a, this 52-byte hole appears to be at address F505H based on > disassembly comparisons between the M100 and 8201a: > > M100 > ==== > ; ====================================================== > ; Get address in .DO file of start of current row using Line Starts array > ; ====================================================== > 6A45H (3AH) LDA F639H ; Cursor row (1-8) > > ; ====================================================== > ; Get address in .DO file of start of row in 'A' using Line Starts array > ; ====================================================== > 6A48H (5FH) MOV E,A ; Prepare to index into Line Start Array > 6A49H (16H) MVI D,00H > 6A4BH (21H) LXI H,F6E9H ; Pointer to Line Start Addresses > 6A4EH (19H) DAD D ; Index into Line Start array > 6A4FH (19H) DAD D ; Each entry is 2 bytes > 6A50H (5EH) MOV E,M ; Get LSB of address for current row > 6A51H (23H) INX H ; Increment to MSB > 6A52H (56H) MOV D,M ; Get MSB of address for current row > 6A53H (2BH) DCX H ; Decrement back to LSB > 6A54H (C9H) RET > > > 8201a > ===== > 6AE2H (3AH) LDA F3E5H ; Cursor row (1-8) > 6AE5H (5FH) MOV E,A > 6AE6H (16H) MVI D,00H > 6AE8H (21H) LXI H,F505H > 6AEBH (19H) DAD D > 6AECH (19H) DAD D > 6AEDH (5EH) MOV E,M > 6AEEH (23H) INX H > 6AEFH (56H) MOV D,M > 6AF0H (2BH) DCX H > 6AF1H (C9H) RET > > Ken > > > On 9/12/19 10:16 AM, Kurt McCullum wrote: >> Thanks Steve! I totally forgot about that message. >> >> On Thu, Sep 12, 2019, at 9:08 AM, Stephen Adolph wrote: >>> reviving this thread. Great info on a hidey hole usable when NOT in TEXT. >>> ..Steve >>> >>> >>> On Thu, May 31, 2018 at 4:38 PM Ken Pettit <petti...@gmail.com> wrote: >>>> Oh, >>>> >>>> And speaking of hidey holes, there is a 52-byte hidey hole that exists >>>> while BASIC is running that I don't believe anyone has ever realized >>>> exists or has used before. On the M100 this address starts at F6EBH. >>>> It is a table of 26 2-byte addresses which is used only in TEXT mode. >>>> TEXT initializes and maintains this table to hold the starting address >>>> of the text within the .DO file being for each line on the LCD (or DVI >>>> ... thus 26 entries). I call it the "line starts array". TEXT uses it >>>> when updating the display to keep track of the location in the .DO file >>>> to start drawing from ... that way it doesn't have to calculate from the >>>> beginning of the file for each display update. >>>> >>>> But in BASIC mode, these 52 RAMs of ram are unused. Enjoy! >>>> >>>> Ken >>>> >>>> On 5/31/18 12:49 PM, Ken Pettit wrote: >>>> > Yeah, that's just 4 bytes of code. That could go in a hidey hole >>>> > (Suzuki, Hayashi, etc.). >>>> > >>>> > Ken >>>> > >>>> > On 5/31/18 12:45 PM, John Gardner wrote: >>>> >> ...Reljmp.pdf... >>>> >> >>>> >> Nice. Thanks. >>>> >> >>>> >> On 5/31/18, John Gardner <gof...@gmail.com> wrote: >>>> >>> Hi John - >>>> >>> >>>> >>> I'm thinking about Ken's idea of having code embedded in BASIC >>>> >>> >>>> >>> jumping to code embedded in a DO file - Sounds workable, even >>>> >>> >>>> >>> reasonable with a big routine, or a number of smaller routines. >>>> >>> >>>> >>> On 5/31/18, John R. Hogerhuis <jho...@pobox.com> wrote: >>>> >>>> On Thu, May 31, 2018 at 12:15 PM, John Gardner <gof...@gmail.com> >>>> >>>> wrote: >>>> >>>> >>>> >>>>> Your code can figure out it's execution address with something like: >>>> >>>>> >>>> >>>>> call @Boo >>>> >>>>> Boo pop B >>>> >>>>> pop A >>>> >>>>> >>>> >>>>> Boo's address is now in register pair A,B... >>>> >>>>> >>>> >>>> But you kind of already know since that code would have to be >>>> >>>> relocated >>>> >>>> to >>>> >>>> function. >>>> >>>> >>>> >>>> -- John. >>>> >>>> >>>> > >>>> >>
