How to use Tables (via labels & CODEPTR) with ASM?

[Paul Dixon]

Clay,
<<Thanks, once again.>>

The bill is in the post.

Paul.

------------------

[Clay Clear]

Thanks, Paul! Funny thing is, I just printed out the docs for
LEA from the PDF file, but wasn't sure how to use the opcode.

Thanks, once again. Now I think I have enough information to be able
to do some final test coding to "learn the ropes," then finally
get into the production coding that this whole overnight has been
geared for.

Thanks.


------------------
mailto:[email protected][email protected]</A>

[Paul Dixon]

Clay,
for indexing through tables the following may help.

Paul.

rem access indexed table using asm
ans1?=0:ans2?=0:ans3?=0

!lea di,lab   	;get the code segment offset of the table into di

!mov al,cs:[di] ;get the byte pointed to by di in the code segment into al
!mov ans1?,al   ;save it

!inc di         ;point to next byte
!mov al,cs:[di] ;get next byte
!mov ans2?,al   ;save it


!inc di         ;point to next byte
!mov al,cs:[di] ;get next byte
!mov ans3?,al   ;save it


'etc.

print hex$(ans1?)
print hex$(ans2?)
print hex$(ans3?)

end
lab:
!db &h12
!db &h23
!db &h34
!db &h45

------------------

[Clay Clear]

OK, got the answer to my second question - PUSHA/PUSHAD do NOT
store the segment registers. That is why the windows errors, I think,
because PB/DOS uses the DS (at LEAST that one), so my code was changing
the values in it without restoring them upon exiting the ASM code.

However, I could not figure out an answer to my first question.


------------------
mailto:[email protected][email protected]</A>

[Clay Clear]

Paul,

I have had success with your ASM version. However, I have a couple
of questions.

(1) How would I step through (increment) the table, to copy to
AL the next highest byte in sequence?

(2) Do you have any idea why:

! db &H66
! db &H60

or:

! db &H60

would cause those Windows errors when my code was run? I replaced them
with the standard ! push/! pop mnemonics, and the Windows errors
disappeared. However, using them does not cause errors when they are
used within a FUNCTION. Any ideas?

Wait, before you answer these questions, let me read up on ! mov
and ! pusha / ! popa in the PDF I downloaded from the URL you
provided in that other thread. Sorry, forgot I had the docs.



------------------
mailto:[email protected][email protected]</A>

[Clay Clear]

Lance,

I did initially try using STRPTR32(). Even though my test code
did not generate a Windows error, the destination string was always
empty (i.e., PRINT S2$ did not print anything). When I changed it
to VARPTR32(), the destination string then displayed the copied
char when using PRINT S2$. However, your wisdom is much higher
than mine, so right now when I go to try Paul's method, I'll try STRPTR32()
again.

Oh, and Lance,

GREAT success in these overnight hours! Remember a LONG time ago
when I could not get the COMMUNIT.BAS "DSR" (or whatever it's called)
function to correctly return the DSR status between modem turned
on and modem turned off? I got it working! AND, I used totally my
own code to do it (just to prevent any copyright problems, since it is
used in a couple of of my public release BBS doors )! Also,
my own version of the "Carrier" function works correctly, as does my
own version of a "Ring Detect" funciton. So, I *am* learning!

Anyway, sorry about the long spiel - mainly wanted to let you know
that it IS possible, at least under Platform 1 OS's, for a DOS
program to retrieve the status of a serial port (I.E., DSR line).


------------------
mailto:[email protected][email protected]</A>

[Lance Edmonds]

VARPTR32 references a dynamic string handle, not the string data... use STRPTR32() to obtain a 32-bit pointer to the string data itself.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Paul Dixon]

Clay,
try the following.

Paul.

rem access table using BASIC
dim pnt as byte pointer
pnt = codeptr32(lab)
print hex$(@pnt)
'
rem access table using asm
ans?=0
'
!mov al,lab
!mov ans?,al
'
print hex$(ans?)
'
end
lab:
!db &h12
!db &h23

------------------

[Clay Clear]

OK, I am beginning to sense that, unlike the 32-bit PB compilers,
the PB/DOS 3.5 compiler only uses CODEPTR to point to live code,
not data? Lance, Tom, can you confirm/negate this? If you reply
negatively, can you give me an example/idea/etc. of how to use
CODEPTR to reference a table of bytes in ASM for PB/DOS 3.5 (I already
know how to do it in the 32-bit compilers)?

Thank you very much for any replies.


------------------
mailto:[email protected][email protected]</A>

[This message has been edited by Clay Clear (edited February 05, 2003).]

[Clay Clear]

Is there any way in PB/DOS 3.5 to reference a Table of bytes with
a label via CODEPTR32? The following code illustrates one of the
attempts that I made. *ALL* efforts resulted in a Windows
"...has performed an illegal function..." error. I finally gave up and
decided to ask for help as I am tired of having to reboot my 'puter.

One of the test codes follows:

DEFSTR S
DEFDWD D
 
S = " "
 
DPtr1 = CODEPTR32(Table1)
DPtr2 = VARPTR32(S)
 
! db &H66
! db &H60
 
! lds si, DPtr1
! les di, DPtr2
 
! movsb
 
! db &H66
! db &H61
 
PRINT S
 
WHILE NOT INSTAT : WEND
 
END(0)
 
Table1:
! db &H54

Any ideas, insights, etc. gratefully received.


------------------
mailto:[email protected][email protected]</A>

[This message has been edited by Clay Clear (edited February 04, 2003).]