http://club100.org/memfiles/index.php?direction===Steve%20Adolph/creating_embeddedML_basic_programs;
repaired. let me know if you see any errors. thx
On Thu, Sep 19, 2019 at 1:52 PM Dan Higdon wrote:
> Cool, thanks. I thought I had a handle on how BASIC was storing strings,
> but I was
Cool, thanks. I thought I had a handle on how BASIC was storing strings,
but I was starting to have doubts. :)
It's nice that constant strings seem to be referenced out of the actual
source code though, and not copied into the string table. Maybe Bill knew
what he was doing after all. :)
On Thu,
ok the root of the issue is my posted file. I'll fix that tonight.
On Thu, Sep 19, 2019 at 1:40 PM Stephen Adolph wrote:
> yep like that.
>
> On Thu, Sep 19, 2019 at 1:38 PM Dan Higdon wrote:
>
>> It was earlier in this thread.
>> I would have thought that the proper code would look more
yep like that.
On Thu, Sep 19, 2019 at 1:38 PM Dan Higdon wrote:
> It was earlier in this thread.
> I would have thought that the proper code would look more like:
>
> 10 a$="your machine code here"
> 20 a%=varptr(a$): call (peek(a%+1)+256*peek(a%+2))
>
> On Thu, Sep 19, 2019 at 12:33 PM
It was earlier in this thread.
I would have thought that the proper code would look more like:
10 a$="your machine code here"
20 a%=varptr(a$): call (peek(a%+1)+256*peek(a%+2))
On Thu, Sep 19, 2019 at 12:33 PM Stephen Adolph
wrote:
> yah thats not up to date. where did you get that?
> I can
If you got this from my personal directory, I will post a correction later
today.
On Thu, Sep 19, 2019 at 1:33 PM Stephen Adolph wrote:
> yah thats not up to date. where did you get that?
> I can post a correction.
>
> On Thu, Sep 19, 2019 at 1:31 PM Dan Higdon wrote:
>
>> I'm still
yah thats not up to date. where did you get that?
I can post a correction.
On Thu, Sep 19, 2019 at 1:31 PM Dan Higdon wrote:
> I'm still struggling to understand how this works:
>
> 10 a$="Code in ASCII"
> 20 call varptr(a$)
>
> Doesn't varptr(a$) return the address of the string descriptor,
I'm still struggling to understand how this works:
10 a$="Code in ASCII"
20 call varptr(a$)
Doesn't varptr(a$) return the address of the string descriptor, which is
[len,lo,hi]? Wouldn't you have to synthesize the call address from
lo+hi*256?
Or is there something magical about how constant
Nice! My PROM burner stands ready :)
On Fri, Sep 13, 2019 at 12:48 PM Kurt McCullum wrote:
>
> Success! I had to abandon all the poking, initialization, and string work and
> finally go back to the ROM initialization routine.
>
> 10 POKE 63911,10:EXEC 62394:EXEC 64448 Will load the LINE code.
Success! I had to abandon all the poking, initialization, and string work and
finally go back to the ROM initialization routine.
10 POKE 63911,10:EXEC 62394:EXEC 64448 Will load the LINE code. Adding this
line to a program that requires LINE makes the process automatic.
10 POKE 63911,11:EXEC
It would appear that Steve already came up with a simple solution to my
problem. I just had to find the file "embedding short ML routines in BASIC.txt"
10 a$="Code in ASCII" Zeros not valid but I can work with that.
20 call varptr(a$)
Simple solution Steve. My thanks to you for putting that
On 9/12/19 5:05 PM, Peter Noeth wrote:
But wouldn't the 52 byte buffer mentioned below be wiped out if you
typed"Edit" while in BASIC, to invoke TEXT to edit your basic program?
Yep. It is useful only when RUNNING a BASIC program.
Ken
hese files/buffers.
Regards,
Peter
--
Message: 5
Date: Thu, 12 Sep 2019 10:16:41 -0700
From: "Kurt McCullum"
To: m100@lists.bitchin100.com
Subject: Re: [M100] compact embedded ML coding
Message-ID:
Content-Type: text/plain; charset="us-ascii"
It's a BASIC Token, but it only works when the line code is loaded. Unlike the
100 ad 200 which have LINE built in.
Kurt
On Thu, Sep 12, 2019, at 3:15 PM, John R. Hogerhuis wrote:
> So LINE is a BASIC token? Or you have to do a CALL?
>
> -- John.
>
> On Thu, Sep 12, 2019 at 2:37 PM Kurt
So LINE is a BASIC token? Or you have to do a CALL?
-- John.
On Thu, Sep 12, 2019 at 2:37 PM Kurt McCullum wrote:
> In the Option Rom, I push all the code from the ROM to the ALTLCD, then I
> populate 65215 & 65216 with the memory location 64448 which is the first
> byte of the ALTLCD. That
In the Option Rom, I push all the code from the ROM to the ALTLCD, then I
populate 65215 & 65216 with the memory location 64448 which is the first byte
of the ALTLCD. That turns the LINE feature in the NEC Basic on. So whenever the
Line function is called, it jumps to the code that is in
On Thu, Sep 12, 2019 at 1:46 PM Kurt McCullum wrote:
> 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
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
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
;
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 wrote:
>> Oh,
>>
>> And speaking of hidey holes,
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 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
On Fri, 1 Jun 2018 07:36:32 -0500
John Gardner wrote:
> ...pop B... 6809?
>
> Hi Willard -
>
> 70C20, actually. I'm not smart enough for 808X."8)
Assembly in 808x isn't about smart, it's about having the patience to
look up every other instruction in a book. ;-)
The classic example:
On Fri, 1 Jun 2018 07:20:52 -0400
Stephen Adolph wrote:
> Sure no problem. Let me know what you need
>
Whatever program you use to convert the hex file into the data
statements.
hex2co is all well and good but without a pdd client CO files are
definitely harder to move to M100...
Thanks!
...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:
>>
>>
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
On Thu, 31 May 2018 12:22:43 -0700
"John R. Hogerhuis" wrote:
> Here is the classic 8085 relative jump for those interested.
>
> It requires some code at a fixed location :-)
Classic cleverness!
Willard
--
Willard Goosey goo...@sdc.org
Socorro, New Mexico, USA
I search my heart and find
On Thu, 31 May 2018 14:15:19 -0500
John Gardner 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...
>
Umm, on a point of order...
I see what you're
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
>
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
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 wrote:
Hi John -
I'm thinking about Ken's idea of having code embedded in BASIC
jumping to
...Reljmp.pdf...
Nice. Thanks.
On 5/31/18, John Gardner 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,
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 wrote:
> On Thu, May 31, 2018 at 12:15 PM, John Gardner
Here is the classic 8085 relative jump for those interested.
It requires some code at a fixed location :-)
RelJMP.pdf
Description: Adobe PDF document
On Thu, May 31, 2018 at 12:15 PM, John Gardner 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
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...
...
On Thu, May 31, 2018 at 11:51 AM, Stephen Adolph
wrote:
> Ken,
> so you are suggesting the .BA file calls into the .DO file? interesting.
>
> When I embed programs as strings, I write the program to avoid codes <32
> d.
> ex.
> mvi a,00
> is bad
> xra a
> is good.
>
>
Maybe the best of both
Hey Steve,
Yes, then you aren't as restricted on the opcodes plus you don't need
any encoding. You just need to ensure 1Ah doesn't appear anywhere. I
suppose if your ML code snippets don't need to perform any jumps to
address that require a byte <32, it works out. Also, I guess if you need
Ken,
so you are suggesting the .BA file calls into the .DO file? interesting.
When I embed programs as strings, I write the program to avoid codes <32
d.
ex.
mvi a,00
is bad
xra a
is good.
On Thu, May 31, 2018 at 2:34 PM, Ken Pettit wrote:
> Hey guys,
>
> Looking at this a bit, it seems
The relative branch technique I’ve seen requires a few bytes of code at a
fixed location.
— John.
Hey guys,
Looking at this a bit, it seems because of the restrictions imposed by
BASIC with regard to binary values less than 32 decimal, the only real
viable way to do execute in-place ML code would be to imbed it in a .DO
file. Then the only restriction is that you can't have 26 decimal
Hi Steve -
My original scheme (for TI-74) was to make the 1st pgm line
the DATA statement, in the form: 100 DATA ### ... ###
The "#" character are simply placeholders, up to 80 chars,
the max length of a DATA statement in TI-74 BASIC.
A TI-74 "main" pgm always starts at HIRAM;
Hi Steve,
Search through BASIC lines? Nah, don't do that! Put a dummy DATA
statement and then your ML code:
10 DATA "a", "encoded ML"
Then do a READ D$. The BASIC ROM will perform the search and update
address FBB8H (on M100/T102) with the address where READ will start it's
search next.
John I think a scheme like that could work, however you'd need to eliminate
all codes under 32decimal. To run in place, you lose the ability to
encode/decode the problematic characters.
finding the DATA statements in RAM can be done but it is a bit of work. I
think you'd have to start from the
What Mike said. IIRC from 30+ years ago, the TRS-80 Model III could read
and write both FM and MFM. The issue with drives was the difference between
40 track and 80 track formatting. Because an 80 track head writes a
narrower track, using it to update a disk written by a 40 track drive was
likely
Or, for really evil results, you can execute your embedded code
in place - I think. I have'nt tried this on a MT, but it works a treat
on TI CC-40's & TI-74's, 8-bitters of a similar vintage. Of course
you have to keep track of where your code is in memory...
I actually wrote a tool once
Hi Steve,
Very clever. I had used ASCII85 encoding before, but your approach
produces smaller data statements and the decoding is also smaller.
Ken
On 5/30/18 11:48 AM, Stephen Adolph wrote:
I often want to embed ML into basic programs. There are 2 ways that I use
1) make a string of
46 matches
Mail list logo
