Re: [M100] interesting VARPTR bug

ah, so making the assignment to the scalar variable is the difference, vs an array variable. they are in different memory areas. thanks I think that is a clear answer. On Tue, May 29, 2018 at 7:08 PM, Ken Pettit wrote: > Hi Steve, > > The line: > > 20 F=VARPTR(A$(0)):*K*=256*PEEK(F+2)+PEEK(F+1

Re: [M100] interesting VARPTR bug

Hi Steve, Or rather "... fails becuase *F* is pointing to the old location for A$(0)". Ken On 5/29/18 4:08 PM, Ken Pettit wrote: Hi Steve, The line: 20 F=VARPTR(A$(0)):*K*=256*PEEK(F+2)+PEEK(F+1) Doesn't work because you take the value of VARPTR(A$(0)) and assign it to F. But then you

Re: [M100] interesting VARPTR bug

Hi Steve, The line: 20 F=VARPTR(A$(0)):*K*=256*PEEK(F+2)+PEEK(F+1) Doesn't work because you take the value of VARPTR(A$(0)) and assign it to F. But then you assign the value of K. This creates a new scalar variable, causing A$(0) to be moved. So then the "256*PEEK(F+2)+PEEK(F+1)" fails be

Re: [M100] interesting VARPTR bug

Ken, when I first read your code I said "That wont work and k(0) will be wrong." however it seems to work. I cannot explain why your code works and my original code did not. I never modify the string content. - your line: 20 FOR X=0TO3:F=VARPTR(A$(X)):K(X)=25

Re: [M100] interesting VARPTR bug

Steve, Are you are trying to pre-calculate the addresses of the strings to save time or something? One thing to note is that the address of the A$() or D$() array variable will move around in RAM. However, as long as you don't modify the strings *in* the array after they are first assigned,

Re: [M100] interesting VARPTR bug

I read something last night that gave me the impression the moving array thing applies to BASIC generally, not just the M100. On Tue, May 29, 2018 at 11:56 AM, John R. Hogerhuis wrote: > > On Tue, May 29, 2018 at 9:25 AM Stephen Adolph > wrote: > >> John, I wasn't able to declare variables in a

Re: [M100] interesting VARPTR bug

On Tue, May 29, 2018 at 9:25 AM Stephen Adolph wrote: > John, I wasn't able to declare variables in any meaningful way to solve > this problem. Only assignment seemed to work. Do you know a trick for that? > steve > No I think you’re probably right, storage attaches and variables move when you

Re: [M100] interesting VARPTR bug

John, I wasn't able to declare variables in any meaningful way to solve this problem. Only assignment seemed to work. Do you know a trick for that? steve On Tue, May 29, 2018 at 12:21 PM, John R. Hogerhuis wrote: > > On Tue, May 29, 2018 at 5:13 AM Jeffrey Birt > wrote: > >> >>> Anytime a new

Re: [M100] interesting VARPTR bug

On Tue, May 29, 2018 at 5:13 AM Jeffrey Birt wrote: > >>> Anytime a new scalar (i.e. non-array) variable is created, the > addresses of the array variables must all change to make room for the new > scalar variable. > > > > So BASIC copies all the arrays to a new memory address? That does not see

Re: [M100] interesting VARPTR bug

On 5/29/18 5:13 AM, Jeffrey Birt wrote: >>> Anytime a new scalar (i.e. non-array) variable is created, the addresses of the array variables must all change to make room for the new scalar variable. So BASIC copies all the arrays to a new memory address? That does not seem very efficient.

Re: [M100] interesting VARPTR bug

Jeff From: M100 On Behalf Of Ken Pettit Sent: Monday, May 28, 2018 10:24 PM To: m...@bitchin100.com Subject: Re: [M100] interesting VARPTR bug Steve, John is correct. Array variables are stored at a higher memory address than scalar variables. Anytime a new scalar (i.e. non-array

Re: [M100] interesting VARPTR bug

The manual mentions something to this effect. What is tricky is understanding when it works and when it breaks. As a rule, if every variable used in a program is assigned once before using VARPTR then you are for sure safe. I guess using VARPTR with array variables complicates things. On Tue, M

Re: [M100] interesting VARPTR bug

One other interesting thing about BASIC variables. A, A%, A%, A(1), A$(1) and A%(1) are all different variables and can exist at the same time with different values. Ken On 5/28/18 4:55 PM, John R. Hogerhuis wrote: On Mon, May 28, 2018 at 4:43 PM, Stephen Adolph

Re: [M100] interesting VARPTR bug

Steve, John is correct. Array variables are stored at a higher memory address than scalar variables. Anytime a new scalar (i.e. non-array) variable is created, the addresses of the array variables must all change to make room for the new scalar variable. So the return value from VARPTR for

Re: [M100] interesting VARPTR bug

On Mon, May 28, 2018 at 4:43 PM, Stephen Adolph wrote: > I think you must be right John, > because this line works > > 20 PRINT A$(S):F=256*PEEK( VARPTR(D$(S)) +2)+PEEK( VARPTR(D$(S)) +1) > > Yeah, the theory being that F as a left-hand-side of a (implied) LET allocates F before the (two) VARPTR

Re: [M100] interesting VARPTR bug

sounds plausible. for reference here is the code. I have 4 embedded ML programs that I want to select to run. 2 REM good command sequence 3 A$(0)="using good sequence":D$(0)="ó:@ð:@ð:¸ð:òð:4ð:°ð:1ð:¿ð77~2ÀüûÉ" 4 REM bad command sequence add 7 after 4@ 5 A$(1)="using bad sequence1":D$(1)="ó:@ð:@ð

Re: [M100] interesting VARPTR bug

I think you must be right John, because this line works 20 PRINT A$(S):F=256*PEEK( VARPTR(D$(S)) +2)+PEEK( VARPTR(D$(S)) +1) On Mon, May 28, 2018 at 7:37 PM, Stephen Adolph wrote: > sounds plausible. > > for reference here is the code. I have 4 embedded ML programs that I want > to select to

Re: [M100] interesting VARPTR bug

On Mon, May 28, 2018 at 4:29 PM Stephen Adolph wrote: > yes, I do have a dim but ..not sure it matters though. I think I tried > with and without. > Hmm. Not sure how the basic variable allocator works. But if putting F=0 makes it work or not work I suspect that assigning F for the first time cr

Re: [M100] interesting VARPTR bug

yes, I do have a dim but ..not sure it matters though. I think I tried with and without. On Mon, May 28, 2018 at 6:54 PM, John R. Hogerhuis wrote: > I assume you DIM A$ somewhere else? > > — John. >

Re: [M100] interesting VARPTR bug

I assume you DIM A$ somewhere else? — John.

[M100] interesting VARPTR bug

I found something odd about VARPTR. I have a matrix of strings A$(x) where x is 0 to 2 for example. If I use the statement: K=VARPTR(A$(S)):F=256*PEEK(K+2)+PEEK(K+1) to derive the location for the data in memory, I get incorrect results. If however I do this: F=0:K=VARPTR(A$(S)):F=256*PEEK(K+2)