Re: [M100] Fwd: Reporting Breakthrough for "Run In Place" Operation -- Was Re: Remem : relocatable ML codes.

[John Gardner]

If a BASIC pgm with code embedded in a DATA statement loads

OK,  maybe embed a return instruction,  call the routine,  & see

what happens?

On 6/1/18, John R. Hogerhuis  wrote:
> Awesome. Thanks Steve, and Ken.
>

Re: [M100] Fwd: Reporting Breakthrough for "Run In Place" Operation -- Was Re: Remem : relocatable ML codes.

[John R. Hogerhuis]

Awesome. Thanks Steve, and Ken.

Re: [M100] Fwd: Reporting Breakthrough for "Run In Place" Operation -- Was Re: Remem : relocatable ML codes.

[John R. Hogerhuis]

" Instead of forcing the calling routine to restore HL, I would instead
code it using XTHL/RET vs. PCHL:"

Yeah that is cleaner.

-- John.

Re: [M100] Fwd: Reporting Breakthrough for "Run In Place" Operation -- Was Re: Remem : relocatable ML codes.

[Ken Pettit]

It also get's LISTed funky.

Ken

On 6/1/18 11:45 AM, Stephen Adolph wrote:

0-31 survives loading.  Agree with Ken that the file can't be edited...

On Fri, Jun 1, 2018 at 2:41 PM, Stephen Adolph > wrote:


edit: i did not test the entire codespace from 0 to 31.  let me do
that

On Fri, Jun 1, 2018 at 2:40 PM, Stephen Adolph
mailto:twospru...@gmail.com>> wrote:

seems that low codes survive being loaded into basic.
they don't survive being translated from a .DO.


On Fri, Jun 1, 2018 at 2:35 PM, Stephen Adolph
mailto:twospru...@gmail.com>> wrote:

good question.  what I do now is transfer the DO file, and
read into a .BA in the M100.
A separate thing would be to transfer a .BA, and just look
at the memory contents before it is loaded/run, and after.

I don't know what will happen


On Fri, Jun 1, 2018 at 2:30 PM, John R. Hogerhuis
mailto:jho...@pobox.com>> wrote:



On Fri, Jun 1, 2018 at 11:24 AM, Stephen Adolph
mailto:twospru...@gmail.com>>
wrote:

basic programs can't have binary codes <32decimal.
I think most or all of those codes have special
meanings.
all of these options would be nice to capture in a
document.



What I was wondering is, is that an issue of
untokenized BASIC, or is it also a limitation of a
tokenized BASIC program.

So if you have bytes < 32 in a static string or DATA
statement in a tokenized BASIC program, will it still
load without corrupting the memory files area in
general, and be runnable?

-- John.

Re: [M100] Fwd: Reporting Breakthrough for "Run In Place" Operation -- Was Re: Remem : relocatable ML codes.

[Stephen Adolph]

0-31 survives loading.  Agree with Ken that the file can't be edited...

On Fri, Jun 1, 2018 at 2:41 PM, Stephen Adolph  wrote:

> edit: i did not test the entire codespace from 0 to 31.  let me do that
>
> On Fri, Jun 1, 2018 at 2:40 PM, Stephen Adolph 
> wrote:
>
>> seems that low codes survive being loaded into basic.
>> they don't survive being translated from a .DO.
>>
>>
>> On Fri, Jun 1, 2018 at 2:35 PM, Stephen Adolph 
>> wrote:
>>
>>> good question.  what I do now is transfer the DO file, and read into a
>>> .BA in the M100.
>>> A separate thing would be to transfer a .BA, and just look at the memory
>>> contents before it is loaded/run, and after.
>>>
>>> I don't know what will happen
>>>
>>>
>>> On Fri, Jun 1, 2018 at 2:30 PM, John R. Hogerhuis 
>>> wrote:
>>>


 On Fri, Jun 1, 2018 at 11:24 AM, Stephen Adolph 
 wrote:

> basic programs can't have binary codes <32decimal.  I think most or
> all of those codes have special meanings.
> all of these options would be nice to capture in a document.
>


 What I was wondering is, is that an issue of untokenized BASIC, or is
 it also a limitation of a tokenized BASIC program.

 So if you have bytes < 32 in a static string or DATA  statement in a
 tokenized BASIC program, will it still load without corrupting the memory
 files area in general, and be runnable?

 -- John.

>>>
>>>
>>
>

Re: [M100] Fwd: Reporting Breakthrough for "Run In Place" Operation -- Was Re: Remem : relocatable ML codes.

[Ken Pettit]

Hey John,

After I sent the original email, I realized this also.  Instead of 
forcing the calling routine to restore HL, I would instead code it using 
XTHL/RET vs. PCHL:


LXI   D, branch_offset   ; Calculated relative to the DAD D opcode below
CALL  WHEREAMI   ; 31E9H or 3F3DH.  HL now contains address of 
DAD D opcode on next line

DAD   D  ; Perform relative address calculation
  XTHL ; Restore HL, push jump address to stack
RET  ; Jump to new relative location

But this still uses codes that are not allowed in a BASIC program.

Ken


On 6/1/18 11:06 AM, John R. Hogerhuis wrote:

Very nice.

Seems like this destroys DE and HL.

You have to sacrifice some register as the relative offset, I guess.

As a small improvement, since the code at WHEREAMI is

XTHL
PCHL

it is actually preserving the original HL on the stack before it 
"returns".


So, you could remove the POP D and instead have a POP H at the jump 
target, so the jump target executes with the original HL value.


Then you can keep HL intact for program logic.

LXI   D, branch_offset   ; Calculated relative to the DAD D opcode below
CALL  WHEREAMI   ; 31E9H or 3F3DH.  HL now contains address of 
DAD D opcode on next line

DAD   D  ; Perform relative address calculation
  PCHL ; Jump to new relative location


TARGET:
POP   H  ; Pop old HL value from Stack
  ; ...

-- John.


On Fri, Jun 1, 2018 at 12:15 AM, Ken Pettit > wrote:


Hi John,

So based on Ron's research, the WHEREAMI function in ROM can be
used as another way to perform a relative branch without the need
for a fixed location in RAM:

LXI   D, branch_offset   ; Calculated relative to the DAD D
opcode below
CALL  WHEREAMI   ; 31E9H or 3F3DH. HL now contains
address of DAD D opcode on next line
DAD   D  ; Perform relative address calculation
POP   D  ; Pop old HL value from Stack
PCHL ; Jump to new relative location

And if you need a conditional relative jump, you can do:

LXI  D, branch_offset; Calculated relative to the DAD D
opcode below
CALL WHEREAMI; 31E9H or 3F3DH.  HL now contains
address of DAD D opcode on next line
DAD  D   ; Perform relative address calculation
POP  D   ; Pop old HL value from Stack
JZ (or JNZ, etc.) 0ED7H  ; Conditional jump to a PCHL opcode

; Fall though if condition not met


Ken

Re: [M100] Fwd: Reporting Breakthrough for "Run In Place" Operation -- Was Re: Remem : relocatable ML codes.

[Ken Pettit]

Hey John,

The values < 32 are not BASIC tokens, those are all > 127.  I actually 
did some tests with VirtualT and poking values < 32d into a BASIC 
program.  It will run.  I don't know if it will load correctly.  The 
problem is that if you EDIT the BASIC program, TEXT will not work 
correctly.  When hit F8 to save the edited file, TEXT will strip any 
characters < 32d from your program.  Something like "DATA a^bcdefg" 
(notice the CTRL-B 02h value) will be stripped to "DATA acdefg".


Ken

On 6/1/18 11:30 AM, John R. Hogerhuis wrote:



On Fri, Jun 1, 2018 at 11:24 AM, Stephen Adolph > wrote:


basic programs can't have binary codes <32decimal.  I think most
or all of those codes have special meanings.
all of these options would be nice to capture in a document.



What I was wondering is, is that an issue of untokenized BASIC, or is 
it also a limitation of a tokenized BASIC program.


So if you have bytes < 32 in a static string or DATA statement in a 
tokenized BASIC program, will it still load without corrupting the 
memory files area in general, and be runnable?


-- John.

Re: [M100] Fwd: Reporting Breakthrough for "Run In Place" Operation -- Was Re: Remem : relocatable ML codes.

[Stephen Adolph]

edit: i did not test the entire codespace from 0 to 31.  let me do that

On Fri, Jun 1, 2018 at 2:40 PM, Stephen Adolph  wrote:

> seems that low codes survive being loaded into basic.
> they don't survive being translated from a .DO.
>
>
> On Fri, Jun 1, 2018 at 2:35 PM, Stephen Adolph 
> wrote:
>
>> good question.  what I do now is transfer the DO file, and read into a
>> .BA in the M100.
>> A separate thing would be to transfer a .BA, and just look at the memory
>> contents before it is loaded/run, and after.
>>
>> I don't know what will happen
>>
>>
>> On Fri, Jun 1, 2018 at 2:30 PM, John R. Hogerhuis 
>> wrote:
>>
>>>
>>>
>>> On Fri, Jun 1, 2018 at 11:24 AM, Stephen Adolph 
>>> wrote:
>>>
 basic programs can't have binary codes <32decimal.  I think most or all
 of those codes have special meanings.
 all of these options would be nice to capture in a document.

>>>
>>>
>>> What I was wondering is, is that an issue of untokenized BASIC, or is it
>>> also a limitation of a tokenized BASIC program.
>>>
>>> So if you have bytes < 32 in a static string or DATA  statement in a
>>> tokenized BASIC program, will it still load without corrupting the memory
>>> files area in general, and be runnable?
>>>
>>> -- John.
>>>
>>
>>
>

Re: [M100] Fwd: Reporting Breakthrough for "Run In Place" Operation -- Was Re: Remem : relocatable ML codes.

[Stephen Adolph]

seems that low codes survive being loaded into basic.
they don't survive being translated from a .DO.


On Fri, Jun 1, 2018 at 2:35 PM, Stephen Adolph  wrote:

> good question.  what I do now is transfer the DO file, and read into a .BA
> in the M100.
> A separate thing would be to transfer a .BA, and just look at the memory
> contents before it is loaded/run, and after.
>
> I don't know what will happen
>
>
> On Fri, Jun 1, 2018 at 2:30 PM, John R. Hogerhuis 
> wrote:
>
>>
>>
>> On Fri, Jun 1, 2018 at 11:24 AM, Stephen Adolph 
>> wrote:
>>
>>> basic programs can't have binary codes <32decimal.  I think most or all
>>> of those codes have special meanings.
>>> all of these options would be nice to capture in a document.
>>>
>>
>>
>> What I was wondering is, is that an issue of untokenized BASIC, or is it
>> also a limitation of a tokenized BASIC program.
>>
>> So if you have bytes < 32 in a static string or DATA  statement in a
>> tokenized BASIC program, will it still load without corrupting the memory
>> files area in general, and be runnable?
>>
>> -- John.
>>
>
>

Re: [M100] Fwd: Reporting Breakthrough for "Run In Place" Operation -- Was Re: Remem : relocatable ML codes.

[Stephen Adolph]

good question.  what I do now is transfer the DO file, and read into a .BA
in the M100.
A separate thing would be to transfer a .BA, and just look at the memory
contents before it is loaded/run, and after.

I don't know what will happen


On Fri, Jun 1, 2018 at 2:30 PM, John R. Hogerhuis  wrote:

>
>
> On Fri, Jun 1, 2018 at 11:24 AM, Stephen Adolph 
> wrote:
>
>> basic programs can't have binary codes <32decimal.  I think most or all
>> of those codes have special meanings.
>> all of these options would be nice to capture in a document.
>>
>
>
> What I was wondering is, is that an issue of untokenized BASIC, or is it
> also a limitation of a tokenized BASIC program.
>
> So if you have bytes < 32 in a static string or DATA  statement in a
> tokenized BASIC program, will it still load without corrupting the memory
> files area in general, and be runnable?
>
> -- John.
>

Re: [M100] Fwd: Reporting Breakthrough for "Run In Place" Operation -- Was Re: Remem : relocatable ML codes.

[John R. Hogerhuis]

On Fri, Jun 1, 2018 at 11:24 AM, Stephen Adolph 
wrote:

> basic programs can't have binary codes <32decimal.  I think most or all of
> those codes have special meanings.
> all of these options would be nice to capture in a document.
>


What I was wondering is, is that an issue of untokenized BASIC, or is it
also a limitation of a tokenized BASIC program.

So if you have bytes < 32 in a static string or DATA  statement in a
tokenized BASIC program, will it still load without corrupting the memory
files area in general, and be runnable?

-- John.

Re: [M100] Fwd: Reporting Breakthrough for "Run In Place" Operation -- Was Re: Remem : relocatable ML codes.

[Stephen Adolph]

basic programs can't have binary codes <32decimal.  I think most or all of
those codes have special meanings.
all of these options would be nice to capture in a document.

On Fri, Jun 1, 2018 at 2:18 PM, John R. Hogerhuis  wrote:

>
>
> On Fri, Jun 1, 2018 at 11:05 AM, Ken Pettit  wrote:
>
>>  I believe those are all opcodes < 32 decimal.
>>
>
> Yeah. But what is this requirement?
>
> can you not have any data bytes < 32 in BASIC program string when it is a
> memory file?
>
> Or is that a limitation of parseable .DO content?
>
>
> Also, FWIW Ron was thinking about run-in-place .Cx files. Through a
> combination of a relocator that had bits that could truly XIP but which
> modifies .Cx content through an array of jump offsets. His innovation there
> was to not code a list of 16-bit offsets, but instead to encode the
> distance between each offset location in 8 bit values.
>
> So yet another way to do it...
>
> -- John.
>

Re: [M100] Fwd: Reporting Breakthrough for "Run In Place" Operation -- Was Re: Remem : relocatable ML codes.

[John R. Hogerhuis]

Very nice.

Seems like this destroys DE and HL.

You have to sacrifice some register as the relative offset, I guess.

As a small improvement, since the code at WHEREAMI is

XTHL
PCHL

it is actually preserving the original HL on the stack before it "returns".

So, you could remove the POP D and instead have a POP H at the jump target,
so the jump target executes with the original HL value.

Then you can keep HL intact for program logic.

LXI   D, branch_offset   ; Calculated relative to the DAD D opcode below
CALL  WHEREAMI   ; 31E9H or 3F3DH.  HL now contains address of
DAD D opcode on next line
DAD   D  ; Perform relative address calculation
PCHL ; Jump to new relative location


TARGET:
POP   H  ; Pop old HL value from Stack
; ...


-- John.


On Fri, Jun 1, 2018 at 12:15 AM, Ken Pettit  wrote:

> Hi John,
>
> So based on Ron's research, the WHEREAMI function in ROM can be used as
> another way to perform a relative branch without the need for a fixed
> location in RAM:
>
> LXI   D, branch_offset   ; Calculated relative to the DAD D opcode
> below
> CALL  WHEREAMI   ; 31E9H or 3F3DH.  HL now contains address of
> DAD D opcode on next line
> DAD   D  ; Perform relative address calculation
> POP   D  ; Pop old HL value from Stack
> PCHL ; Jump to new relative location
>
> And if you need a conditional relative jump, you can do:
>
> LXI  D, branch_offset; Calculated relative to the DAD D opcode
> below
> CALL WHEREAMI; 31E9H or 3F3DH.  HL now contains address of
> DAD D opcode on next line
> DAD  D   ; Perform relative address calculation
> POP  D   ; Pop old HL value from Stack
> JZ (or JNZ, etc.) 0ED7H  ; Conditional jump to a PCHL opcode
>
> ; Fall though if condition not met
>
>
> Ken
>
>

Re: [M100] Fwd: Reporting Breakthrough for "Run In Place" Operation -- Was Re: Remem : relocatable ML codes.

[Ken Pettit]

Hey Steve,

Unfortunately it uses LXI D and DAD D (or LXI B and DAD B).  I believe 
those are all opcodes < 32 decimal. :(  Plus your relative jump would 
have values < 32 decimal for any jump distance that is less than 2020H.  
So maybe not so useful after all.


It is still doable in a BASIC string, but it becomes costly in terms of 
size and execution time due to the coding limitations:


PUSH  PSW ; Only needed if relatvie branch 
required (save condition flags)

XRA   A   ; Zero A
MOV   D,A ; Zero D.  For backward jumps, insert 
a DCR A prior to MOV D,A
MVI   A,forward_branch_dist   ; Jump 32 to 255 forward (or 
backwared if DCR A inserted).
MOV   E,A ; Load jump into E (We can't use MVI 
E because it is < 32d)
CALL  WHEREAMI; 31E9H or 3F3DH.  HL now contains 
address of CALL opcode on next line

CALL  21ACh ; Location in ROM with a DAD D followed by RET
XTHL  ; Put return val on stack, restore 
original HL
POP   PSW ; Only needed for conditional return 
below
RZ / RNZ / RET; Return or conditional RETurn for 
conditional branch
POP   D   ; Only for conditional.  If RZ / RNZ 
didn't jump,
we must pop the unused RET address 
from stack


; A Whopping 16 bytes for a conditonal branch!  Or 17 for backward 
branch.  Don't use to many of them!


If a lot of conditional branches are needed in BASIC strings / DATA 
statements, it might be better to poke a routine similar to this into 
the hidey hole I mentioned yesterday (at F6EBH) and call it.  For 
conditional, write that routine so it returns either to the next opcode 
or the new relative branch location.  To load the relative jump, easily 
you could do:


XCHG
LXI   H, branch_distance  ; USE LXI H since it can be used in 
BASIC string

CALL  hidey_hole

Then the hidey_hole would perform the XCHG / XTHL/ PCHL / RZ magic. 
There may be other ROM call magic to be found also.


Ken

On 6/1/18 5:01 AM, Stephen Adolph wrote:
this is quite useful; it applies specifically to (a) running code that 
is buried in BASIC string variables and (b) running code that is 
buried in DATA structures, because in those cases you really don't 
know where the code is (easily), and the code can't adapt to being 
moved around (easily).  Now it can.  Very useful!


Regarding .DO files - the contents of the .DO file survives being 
loaded into M100 memory intact.  One has to avoid EOF and 0A.   One 
does not need quotes either.  So this is quite dense, and



On Fri, Jun 1, 2018 at 3:15 AM, Ken Pettit > wrote:


Hi John,

So based on Ron's research, the WHEREAMI function in ROM can be
used as another way to perform a relative branch without the need
for a fixed location in RAM:

LXI   D, branch_offset   ; Calculated relative to the DAD D
opcode below
CALL  WHEREAMI   ; 31E9H or 3F3DH. HL now contains
address of DAD D opcode on next line
DAD   D  ; Perform relative address calculation
POP   D  ; Pop old HL value from Stack
PCHL ; Jump to new relative location

And if you need a conditional relative jump, you can do:

LXI  D, branch_offset; Calculated relative to the DAD D
opcode below
CALL WHEREAMI; 31E9H or 3F3DH. HL now contains
address of DAD D opcode on next line
DAD  D   ; Perform relative address calculation
POP  D   ; Pop old HL value from Stack
JZ (or JNZ, etc.) 0ED7H  ; Conditional jump to a PCHL opcode

; Fall though if condition not met


Ken


On 5/31/18 12:49 PM, John R. Hogerhuis wrote:

Self-locating code.

Ron Wiesen did some research a long time ago to figure out code
in the ROM that could tell you where you are calling from.

This is a critical part of code that can efficiently relocate
itself to run-in-place or at a specific location.

-- John.

-- Forwarded message --
From: *Ron Wiesen* mailto:r...@sunnyfla.net>>
Date: Thu, Nov 9, 2006 at 2:25 AM
Subject: Reporting Breakthrough for "Run In Place" Operation --
Was Re: Remem : relocatable ML codes.
To: Model 100 Listserve mailto:m...@list.30below.com>>


Previously I wrote:
> But your "relocatable ML codes" message has reminded me of some
progress I
> recently made on a mission that was placed on the "back burner"
a long
time
> ago.  So I'll review my mission notes and report my progress to
this list.
>
> The mission was to develop the means for software, operating in
a M10x or
> M200 laptop, to discovered the memory address of "Where I am
Now".  I've
> found four 

Re: [M100] compact embedded ML coding

[John Gardner]

...pop B...   6809?

Hi Willard -

70C20,  actually.   I'm not smart enough for 808X."8)

On 6/1/18, Stephen Adolph  wrote:
> Sure no problem.  Let me know what you need
>
> On Friday, June 1, 2018, Willard Goosey  wrote:
>
>> On Wed, 30 May 2018 14:48:11 -0400
>> Stephen Adolph  wrote:
>>
>> > I often want to embed ML into basic programs.  There are 2 ways that
>> > I use 1)  make a string of binary and assign it to a basic string
>> > variable.  (use VARPTR)
>> > 2)  include data statements that contain the ML binary, with some
>> > encoding, and use a routine to poke into memory
>> >
>> [...awesomeness deleted...]
>>
>> > Anyhow the net result is very compact with a minimal poke routine.  I
>> > compile my machine code into Intel HEX format, run a simple program to
>> > encode the data into sets of DATA statements, and copy the resulting
>> > text into a .DO file.
>>
>> Any chance I could include this with the M100SmallCLib? It might remove
>> one of the roadblocks to people actually using it (smallclib) for
>> something. ;-)
>>
>> Willard
>> --
>> Willard Goosey  goo...@sdc.org
>> Socorro, New Mexico, USA
>> I search my heart and find Cimmeria, land of Darkness and the Night.
>>   -- R.E. Howard
>>
>

Re: [M100] Fwd: Reporting Breakthrough for "Run In Place" Operation -- Was Re: Remem : relocatable ML codes.

[John Gardner]

Good stuff!

HP-LX docs call Run-In-Place code "XIP",  for Execute-In-Place.

Although RIP seems appropriate enough for my code...

On 6/1/18, Stephen Adolph  wrote:
> this is quite useful; it applies specifically to (a) running code that is
> buried in BASIC string variables and (b) running code that is buried in
> DATA structures, because in those cases you really don't know where the
> code is (easily), and the code can't adapt to being moved around (easily).
> Now it can.  Very useful!
>
> Regarding .DO files - the contents of the .DO file survives being loaded
> into M100 memory intact.  One has to avoid EOF and 0A.   One does not need
> quotes either.  So this is quite dense, and
>
>
> On Fri, Jun 1, 2018 at 3:15 AM, Ken Pettit  wrote:
>
>> Hi John,
>>
>> So based on Ron's research, the WHEREAMI function in ROM can be used as
>> another way to perform a relative branch without the need for a fixed
>> location in RAM:
>>
>> LXI   D, branch_offset   ; Calculated relative to the DAD D opcode
>> below
>> CALL  WHEREAMI   ; 31E9H or 3F3DH.  HL now contains address
>> of
>> DAD D opcode on next line
>> DAD   D  ; Perform relative address calculation
>> POP   D  ; Pop old HL value from Stack
>> PCHL ; Jump to new relative location
>>
>> And if you need a conditional relative jump, you can do:
>>
>> LXI  D, branch_offset; Calculated relative to the DAD D opcode
>> below
>> CALL WHEREAMI; 31E9H or 3F3DH.  HL now contains address
>> of
>> DAD D opcode on next line
>> DAD  D   ; Perform relative address calculation
>> POP  D   ; Pop old HL value from Stack
>> JZ (or JNZ, etc.) 0ED7H  ; Conditional jump to a PCHL opcode
>>
>> ; Fall though if condition not met
>>
>>
>> Ken
>>
>>
>> On 5/31/18 12:49 PM, John R. Hogerhuis wrote:
>>
>> Self-locating code.
>>
>> Ron Wiesen did some research a long time ago to figure out code in the
>> ROM
>> that could tell you where you are calling from.
>>
>> This is a critical part of code that can efficiently relocate itself to
>> run-in-place or at a specific location.
>>
>> -- John.
>>
>> -- Forwarded message --
>> From: Ron Wiesen 
>> Date: Thu, Nov 9, 2006 at 2:25 AM
>> Subject: Reporting Breakthrough for "Run In Place" Operation -- Was Re:
>> Remem : relocatable ML codes.
>> To: Model 100 Listserve 
>>
>>
>> Previously I wrote:
>> > But your "relocatable ML codes" message has reminded me of some
>> > progress
>> I
>> > recently made on a mission that was placed on the "back burner" a long
>> time
>> > ago.  So I'll review my mission notes and report my progress to this
>> list.
>> >
>> > The mission was to develop the means for software, operating in a M10x
>> > or
>> > M200 laptop, to discovered the memory address of "Where I am Now".
>> > I've
>> > found four methods to do it, tested all four of them, and believe I've
>> > determined which is the "best" method of the four.  Having the means to
>> > ascertain "Where I am Now" is a long sought after breakthrough.  It's
>> > something that's essential in obtaining a substantial improvement in
>> > the
>> > "Run In Place" operation of binary objects; the improvement eliminates
>> need
>> > for the separate utility that launches said binary objects.  "Run In
>> Place"
>> > operation of binary objects avoids need for a HIMEM area and avoids the
>> > double-consumption penalty that ordinary invocation of binary objects.
>>
>> The "Self-Locate" snippet shown below is my report, which details the
>> "best"
>> method of the four methods that I found and tested.  Details are given
>> for
>> both the Model 10x laptop (CALL 31E9H and JMP 14EDH) and for the Model
>> 200
>> laptop (CALL 3F3DH and JMP 1604H).
>>
>> = Self-Locate -- major milestone for run-in-place laptop executables
>> =
>> WHEREAMI:   EQU  $
>> CALL 31E9H   ;XTHL PCHL stacks HL, HL=rtn. Model 10x.
>> ;   CALL 3F3DH   ;XTHL PCHL stacks HL, HL=rtn. Model 200.
>> IAMHERE:EQU $;I am HERE at this discovered return address
>>  ;which now is in HL
>> PUSH D
>> PUSH B
>> PUSH PSW
>> ;All reg content stacked. JMP 14EDH is a handy unstack exit.
>> JMP 14EDH;Pops PSW,B,D,H and then RET exit. Model
>> 10x.
>> ;   JMP 1604H;Pops PSW,B,D,H and then RET exit. Model
>> 200.
>>
>> Once it's discovered "Where I am Now" then inspection of "Where I was
>> Before" is done.  The difference is the needed adjustment of wordAdrs.
>> Note, if difference is 0, adjustment isn't needed and time is saved --
>> often the case for code held within BASIC program files.
>>
>> Via link-lists, locales of wordAdrs are found.  Each is adjusted
>> according to the adjustment difference.  If there are locales for
>> byteAdrs (unlikely), they have their own link-lists and also 

Re: [M100] Fwd: Reporting Breakthrough for "Run In Place" Operation -- Was Re: Remem : relocatable ML codes.

[Stephen Adolph]

this is quite useful; it applies specifically to (a) running code that is
buried in BASIC string variables and (b) running code that is buried in
DATA structures, because in those cases you really don't know where the
code is (easily), and the code can't adapt to being moved around (easily).
Now it can.  Very useful!

Regarding .DO files - the contents of the .DO file survives being loaded
into M100 memory intact.  One has to avoid EOF and 0A.   One does not need
quotes either.  So this is quite dense, and


On Fri, Jun 1, 2018 at 3:15 AM, Ken Pettit  wrote:

> Hi John,
>
> So based on Ron's research, the WHEREAMI function in ROM can be used as
> another way to perform a relative branch without the need for a fixed
> location in RAM:
>
> LXI   D, branch_offset   ; Calculated relative to the DAD D opcode
> below
> CALL  WHEREAMI   ; 31E9H or 3F3DH.  HL now contains address of
> DAD D opcode on next line
> DAD   D  ; Perform relative address calculation
> POP   D  ; Pop old HL value from Stack
> PCHL ; Jump to new relative location
>
> And if you need a conditional relative jump, you can do:
>
> LXI  D, branch_offset; Calculated relative to the DAD D opcode
> below
> CALL WHEREAMI; 31E9H or 3F3DH.  HL now contains address of
> DAD D opcode on next line
> DAD  D   ; Perform relative address calculation
> POP  D   ; Pop old HL value from Stack
> JZ (or JNZ, etc.) 0ED7H  ; Conditional jump to a PCHL opcode
>
> ; Fall though if condition not met
>
>
> Ken
>
>
> On 5/31/18 12:49 PM, John R. Hogerhuis wrote:
>
> Self-locating code.
>
> Ron Wiesen did some research a long time ago to figure out code in the ROM
> that could tell you where you are calling from.
>
> This is a critical part of code that can efficiently relocate itself to
> run-in-place or at a specific location.
>
> -- John.
>
> -- Forwarded message --
> From: Ron Wiesen 
> Date: Thu, Nov 9, 2006 at 2:25 AM
> Subject: Reporting Breakthrough for "Run In Place" Operation -- Was Re:
> Remem : relocatable ML codes.
> To: Model 100 Listserve 
>
>
> Previously I wrote:
> > But your "relocatable ML codes" message has reminded me of some progress
> I
> > recently made on a mission that was placed on the "back burner" a long
> time
> > ago.  So I'll review my mission notes and report my progress to this
> list.
> >
> > The mission was to develop the means for software, operating in a M10x or
> > M200 laptop, to discovered the memory address of "Where I am Now".  I've
> > found four methods to do it, tested all four of them, and believe I've
> > determined which is the "best" method of the four.  Having the means to
> > ascertain "Where I am Now" is a long sought after breakthrough.  It's
> > something that's essential in obtaining a substantial improvement in the
> > "Run In Place" operation of binary objects; the improvement eliminates
> need
> > for the separate utility that launches said binary objects.  "Run In
> Place"
> > operation of binary objects avoids need for a HIMEM area and avoids the
> > double-consumption penalty that ordinary invocation of binary objects.
>
> The "Self-Locate" snippet shown below is my report, which details the
> "best"
> method of the four methods that I found and tested.  Details are given for
> both the Model 10x laptop (CALL 31E9H and JMP 14EDH) and for the Model 200
> laptop (CALL 3F3DH and JMP 1604H).
>
> = Self-Locate -- major milestone for run-in-place laptop executables
> =
> WHEREAMI:   EQU  $
> CALL 31E9H   ;XTHL PCHL stacks HL, HL=rtn. Model 10x.
> ;   CALL 3F3DH   ;XTHL PCHL stacks HL, HL=rtn. Model 200.
> IAMHERE:EQU $;I am HERE at this discovered return address
>  ;which now is in HL
> PUSH D
> PUSH B
> PUSH PSW
> ;All reg content stacked. JMP 14EDH is a handy unstack exit.
> JMP 14EDH;Pops PSW,B,D,H and then RET exit. Model 10x.
> ;   JMP 1604H;Pops PSW,B,D,H and then RET exit. Model 200.
>
> Once it's discovered "Where I am Now" then inspection of "Where I was
> Before" is done.  The difference is the needed adjustment of wordAdrs.
> Note, if difference is 0, adjustment isn't needed and time is saved --
> often the case for code held within BASIC program files.
>
> Via link-lists, locales of wordAdrs are found.  Each is adjusted
> according to the adjustment difference.  If there are locales for
> byteAdrs (unlikely), they have their own link-lists and also are
> adjusted.  Two link-list structures are considered: ByteAdvance and
> BitsOfNext.  In some cases a mix of both may minimize overhead cost.
>
> ByteAdvance was done before in type .CE development and for ERL
> development.  It presumes all locales are adjacent in series by no more
> than 256-spans.  Worst case is two 

Re: [M100] compact embedded ML coding

[Stephen Adolph]

Sure no problem.  Let me know what you need

On Friday, June 1, 2018, Willard Goosey  wrote:

> On Wed, 30 May 2018 14:48:11 -0400
> Stephen Adolph  wrote:
>
> > I often want to embed ML into basic programs.  There are 2 ways that
> > I use 1)  make a string of binary and assign it to a basic string
> > variable.  (use VARPTR)
> > 2)  include data statements that contain the ML binary, with some
> > encoding, and use a routine to poke into memory
> >
> [...awesomeness deleted...]
>
> > Anyhow the net result is very compact with a minimal poke routine.  I
> > compile my machine code into Intel HEX format, run a simple program to
> > encode the data into sets of DATA statements, and copy the resulting
> > text into a .DO file.
>
> Any chance I could include this with the M100SmallCLib? It might remove
> one of the roadblocks to people actually using it (smallclib) for
> something. ;-)
>
> Willard
> --
> Willard Goosey  goo...@sdc.org
> Socorro, New Mexico, USA
> I search my heart and find Cimmeria, land of Darkness and the Night.
>   -- R.E. Howard
>

Re: [M100] m100smallclib : Defect Attractor! prsnam()

[Josh Malone]

Sounds quite reasonable to this novice c coder :)

On Fri, Jun 1, 2018, 2:23 AM Willard Goosey  wrote:

> OK, though I've been pretty distracted I'm still moving towards a beta
> release for the SmallC lib. I want to be able to freeze the interface
> so that there will be backwards compatibility from any further versions.
>
> ESR recently made a blog post about "Defect Attractors" -- design
> features that are easily misused or otherwise sort-of encourage bugs.
> As you can imagine, shims from one language to another (say, an assembly
> ROM API to a C lib...:) are big offenders here, if only because the
> mindset of the "hidden" language still tends to be visible in the
> interface and that's jarring.
>
> I've been thinking about this, and one function in particular keeps
> jumping to my mind. prsnam().
>
> The current prototype is prsnam(char *s, int i)
> parses a file.do filename into the FILNAM system variable as FILE  DO
> s=filename
> i=length of filename.
>
> And I see a Defect Attractor here! If a proper C function wants to know
> the length of a string it calls freaking strlen() on it. It does not
> expect the caller to do its job for it.
>
> So I propose to replace it with prsnam(char *s) that will call
> strlen() itself, making the interface a little simpler and removing a
> Defect Attractor.
>
> Any thoughts?
>
> Willard
> --
> Willard Goosey  goo...@sdc.org
> Socorro, New Mexico, USA
> I search my heart and find Cimmeria, land of Darkness and the Night.
>   -- R.E. Howard
>

Re: [M100] Fwd: Reporting Breakthrough for "Run In Place" Operation -- Was Re: Remem : relocatable ML codes.

[Ken Pettit]

Hi John,

So based on Ron's research, the WHEREAMI function in ROM can be used as 
another way to perform a relative branch without the need for a fixed 
location in RAM:


LXI   D, branch_offset   ; Calculated relative to the DAD D opcode 
below
CALL  WHEREAMI   ; 31E9H or 3F3DH.  HL now contains address 
of DAD D opcode on next line

DAD   D  ; Perform relative address calculation
POP   D  ; Pop old HL value from Stack
PCHL ; Jump to new relative location

And if you need a conditional relative jump, you can do:

LXI  D, branch_offset; Calculated relative to the DAD D opcode 
below
CALL WHEREAMI; 31E9H or 3F3DH.  HL now contains address 
of DAD D opcode on next line

DAD  D   ; Perform relative address calculation
POP  D   ; Pop old HL value from Stack
JZ (or JNZ, etc.) 0ED7H  ; Conditional jump to a PCHL opcode

; Fall though if condition not met


Ken

On 5/31/18 12:49 PM, John R. Hogerhuis wrote:

Self-locating code.

Ron Wiesen did some research a long time ago to figure out code in the 
ROM that could tell you where you are calling from.


This is a critical part of code that can efficiently relocate itself 
to run-in-place or at a specific location.


-- John.

-- Forwarded message --
From: *Ron Wiesen* mailto:r...@sunnyfla.net>>
Date: Thu, Nov 9, 2006 at 2:25 AM
Subject: Reporting Breakthrough for "Run In Place" Operation -- Was 
Re: Remem : relocatable ML codes.
To: Model 100 Listserve >



Previously I wrote:
> But your "relocatable ML codes" message has reminded me of some 
progress I

> recently made on a mission that was placed on the "back burner" a long
time
> ago.  So I'll review my mission notes and report my progress to this 
list.

>
> The mission was to develop the means for software, operating in a 
M10x or

> M200 laptop, to discovered the memory address of "Where I am Now".  I've
> found four methods to do it, tested all four of them, and believe I've
> determined which is the "best" method of the four. Having the means to
> ascertain "Where I am Now" is a long sought after breakthrough.  It's
> something that's essential in obtaining a substantial improvement in the
> "Run In Place" operation of binary objects; the improvement eliminates
need
> for the separate utility that launches said binary objects.  "Run In
Place"
> operation of binary objects avoids need for a HIMEM area and avoids the
> double-consumption penalty that ordinary invocation of binary objects.

The "Self-Locate" snippet shown below is my report, which details the 
"best"

method of the four methods that I found and tested. Details are given for
both the Model 10x laptop (CALL 31E9H and JMP 14EDH) and for the Model 200
laptop (CALL 3F3DH and JMP 1604H).

= Self-Locate -- major milestone for run-in-place laptop executables
=
WHEREAMI:   EQU  $
CALL 31E9H   ;XTHL PCHL stacks HL, HL=rtn. Model 10x.
;   CALL 3F3DH   ;XTHL PCHL stacks HL, HL=rtn. Model 200.
IAMHERE:EQU $;I am HERE at this discovered return address
 ;which now is in HL
PUSH D
PUSH B
PUSH PSW
;All reg content stacked. JMP 14EDH is a handy unstack exit.
JMP 14EDH;Pops PSW,B,D,H and then RET exit. Model 10x.
;   JMP 1604H;Pops PSW,B,D,H and then RET exit. Model 200.

Once it's discovered "Where I am Now" then inspection of "Where I was
Before" is done.  The difference is the needed adjustment of wordAdrs.
Note, if difference is 0, adjustment isn't needed and time is saved --
often the case for code held within BASIC program files.

Via link-lists, locales of wordAdrs are found.  Each is adjusted
according to the adjustment difference.  If there are locales for
byteAdrs (unlikely), they have their own link-lists and also are
adjusted.  Two link-list structures are considered: ByteAdvance and
BitsOfNext.  In some cases a mix of both may minimize overhead cost.

ByteAdvance was done before in type .CE development and for ERL
development.  It presumes all locales are adjacent in series by no more
than 256-spans.  Worst case is two wordAdrs locales displaced by 256.
Example: locales of ?000h and ?100h are linked by link value of FFh
(255).  Adjustment to ?000h increments beyond it to ?0001h (the
Hi-part), and relative to ?001h going further by FFh arrives at locale
?100h.  Example: locale of ?000h and ?002h are linked by link value of
01h (1).  Relative to ?001h going further by only 01h arrives at the
directly adjacent locale ?003h.  Note that link value of 00h (0) can be
used as the delimiter of a link-list, although it could be used to
increase the maximum displacement for 257-spans.  The overhead cost is
1 ByteAdvance link per wordAdrs locale.  This can be a lot for code
with much internal 

[M100] m100smallclib : Defect Attractor! prsnam()

[Willard Goosey]

OK, though I've been pretty distracted I'm still moving towards a beta
release for the SmallC lib. I want to be able to freeze the interface
so that there will be backwards compatibility from any further versions.

ESR recently made a blog post about "Defect Attractors" -- design
features that are easily misused or otherwise sort-of encourage bugs.
As you can imagine, shims from one language to another (say, an assembly
ROM API to a C lib...:) are big offenders here, if only because the
mindset of the "hidden" language still tends to be visible in the
interface and that's jarring.

I've been thinking about this, and one function in particular keeps
jumping to my mind. prsnam().

The current prototype is prsnam(char *s, int i)
parses a file.do filename into the FILNAM system variable as FILE  DO
s=filename
i=length of filename.

And I see a Defect Attractor here! If a proper C function wants to know
the length of a string it calls freaking strlen() on it. It does not
expect the caller to do its job for it.

So I propose to replace it with prsnam(char *s) that will call
strlen() itself, making the interface a little simpler and removing a
Defect Attractor.  

Any thoughts?
 
Willard
-- 
Willard Goosey  goo...@sdc.org
Socorro, New Mexico, USA
I search my heart and find Cimmeria, land of Darkness and the Night.
  -- R.E. Howard