Assembly code samples

[HOME AUTOMATION]

21 minutes ago, GDMike said:

I presume, those are spaces I see, after MIKE(xxx ). Those will place >20s after the search term, not >00s.

[HOME AUTOMATION]

35 minutes ago, GDMike said:

I'm having to convert the address in R6 to the screen location.

 

 

R4?

[HOME AUTOMATION]

1 hour ago, GDMike said:

 

Looking at KS3...

 

I assume >23A4 is the start address of the page you want to search...

R3=>FE00 *Search does this. Sooo, this becomes redundant.
R4=>23A4 *Address to start searching from.
R6=>0000 *Address at which to stop searching.
BL @SEARCH

 

This will search from >23A4 thru >FFFF+1 ...probably not what you want to do!

 

It appears you intend to copy the search term, from LBWRD(relocatable) to LIBAD7(>FFE0), after underlaying ZEROs. That should work, if done successfully.

 

But you are also searching @>FFE0, if no other match is found first!

 

Now:

 

CMP2...

 

I thought we were going to... stick to the example, somewhat. What's wrong with a simple C R4,R6?

My program doesn't manipulate R6.

 

I'm not going to try to compute that many variables ...in my head, and think of what to type, while already guessing at so much!

 

If this is your workflow ...well, I'm afraid I can't type all this ...in order to follow along.

 

 

[HOME AUTOMATION]

Old Chinese proverb...

 

 

...Grasshopper, have far to hop in program.

 

 

 

[apersson850]

Back in the days, when I was programming the TI 99/4A a lot, is did complex assembly algorithms in two steps.

First, I wrote a program doing the same thing in Pascal. Debugged and got that working properly.

Then I translated that to assembly. This was usually not too difficult, since I did of course have the conversion process already in mind, when I wrote the Pascal program. Thus I tried to use as simple structures and logic as possible, to make the translation straight-forward.

 

This apporach did of course require that there wasn't some specific thing, like messing with interrupts or CRU bits that had to be done. That can't be done in Pascal. But a sorting algorithm, or a text search algorithm, would be easy enough to do.

[apersson850]

11 hours ago, GDMike said:

Yup. If I do a BL @ search and a rt occurs, doesn't or won't that put me at SEARCH again?

No, if you do a BL @SEARCH somewhere, then inside SEARCH you do a RT (B *R11), then that will bring you back to the instruction right after the BL @SEARCH.

[GDMike]

10 hours ago, HOME AUTOMATION said:

I presume, those are spaces I see, after MIKE(xxx ). Those will place >20s after the search term, not >00s.

Yes, because I started to experiment with the search word. And I forgot to make this tighter with the quote mark. I stated to screw things up here.

[GDMike]

I'll take a different approach with this, but I'm not intending to search to >FFFF, actually not even past 840 bytes, because I have other stuff that has to happen before leaving page 1.

I'll try again.

[HOME AUTOMATION]

...try,

 

R4=>23A4

R6=>26EC

 

[+Lee Stewart]

12 hours ago, GDMike said:

Yup. If I do a BL @ search and a rt occurs, doesn't or won't that put me at SEARCH again?

 

 

1 hour ago, apersson850 said:

No, if you do a BL @SEARCH somewhere, then inside SEARCH you do a RT (B *R11), then that will bring you back to the instruction right after the BL @SEARCH.

 

Remember that, before the BL instruction takes the branch, it stores the address of the instruction that follows it into R11 in order to return to the caller (as @apersson850 said). As long as the called routine (SEARCH) does not overwrite R11 (without first preserving it) with a BL of its own, it will return to the caller just fine.

 

...lee

[GDMike]

Thx Lee. Got it. Ok yes I see a few mistakes from last night that I made, I have since corrected up until my test for true/false.

I'm rerunning my test.

[GDMike]

Here's my code, seems to me that the word, search, isn't found.

 

[GDMike]

I forgot I had the word "Search" in the title. I've removed it from the title.

 

I added a Break if r7 is past the word search, meaning it wasn't found within the first 850 bytes.

The"S" in search is at location 440 on the screen, I figured, just adding 440 to >23A4 would be my first hit. But explorer shows me that it's past that address of >255C (not pictured), but this is what I'm looking at and watching it go past that address.

Oh, and I kept confusing 840 bytes for my page length instead of 860. I've finally corrected that too.

 

Question: were doing a CB *R3,*R4+

But what if the "S" in search is at an odd address number? Is it still detected? Being that*R4+ is moving two bytes.

I'm going to move the word, search on page 1 back a position and see if it's found.

Edited July 15, 2020 by GDMike

[HOME AUTOMATION]

1 hour ago, GDMike said:

Question: were doing a CB *R3,*R4+

But what if the "S" in search is at an odd address number? Is it still detected? Being that*R4+ is moving two bytes.

I'm going to move the word, search on page 1 back a position and see if it's found.

 

CB, autoincrements by 1s.
C, autoincrements by 2s.

 

So...

 

CMPARE CB   *R3,*R4+  * compares(not moves) 1 byte at a time, w/o skipping any!

 

I was thinking along similar lines, concerning how data is moved by your KS3. Perhaps the data's bytes are being swapped or are using every other byte?

 

I see R5= >2820, suggesting that a first letter match was found at the byte before! Unless your program did this, or it was left over from a previous run. Why you would increment R5 I cannot guess!

Edited July 15, 2020 by HOME AUTOMATION

[GDMike]

I'm putting things back together, I'm trying to confirm a positive hit, but I'm not finding one, yet. I'll be better to answer that in a moment after I do one more test. You said that once completed, R4 would contain the address of the"S" in the word "Search" in memory. So far..I'm not finding that address in R4.

But I'm not done with my test..

 

[+adamantyr]

Just an observation guys, but if the intent of this thread was to share assembly code samples...

 

It appears it's turned more into a back-and-forth debugging session which is no doubt good stuff, just not related to the thread's original intent.

[GDMike]

True, here we have a piece of code, that needed understanding, I suppose that's the best way to put it. I'd like to use it, but I can't seem to get it figured out. BUT, surely, there's yet, another method of communication buried under my phone, called, messaging within Atariage.

I suppose well use that, and once figured out, then I'll explain what I had to do. Sure

[+9640News]

I can confirm this code works as given below.  A couple of "catcha's" are possible if you do not think things through well enough.

 

First, if you enter a string by typing it in, keep in mind you have likely entered a >0D at the end of the string when you hit enter.  That is an extra byte to the string and that means any text you are searching will also need to have the >0D after the letters to match the string.  Secondly, the string is case sensitive, so String and STRING are two different search parameters.

 

Searching must be in CPU, not VDP ram as the code is presently written.

 

I'm working on a "search and find" string function myself reading in a DV80 file (~3000 sectors), 4 lines at a time.  I now have the reading working properly, moving into CPU, and finding the >0D terminated string.  Next step is to remove the >0D from the search string, convert the string all to upper case, and convert all text read in upper case.  If I get a hit, then display the 4 lines, if not, continue on.

 

Beery

 

 

VALID  DATA 0
SEARCH LI   R3,QUERI        *THIS IS THE LINE TO BL TO!
CMPARE CB   *R3,*R4+
       JEQ  NEXT
       C    R4,R6
       JNE  CMPARE
OUTNO  RT
NEXT   MOV  R4,R5
CONT   CB   *R3,@VALID
       JEQ  OUTYES
       C    R4,R6
       JEQ  OUTNO
       INC  R3
       CB   *R3,*R4+
       JEQ  CONT
RESTAR MOV  R5,R4
       JMP  SEARCH
OUTYES MOV  R5,R4
       DEC  R4
       RT
       END

Set up a buffer labeled QUERI, make sure to fill it with all zeros, before overlaying your search term.

This buffer should have an extra 1 or 2 zeros after it's max. length! This will indicate the search completed successfully, when found by my program.

 

R4=Where to start searching from.
R6=Where to stop searching.

BL @SEARCH

 

This should find the first occurrence, before returning to your program.

R4 will be set to the starting address of the found term.

or

R4 will be equal to R6 if nothing was found.

 Adding the length of the search term to R4, then BL-ing back to SEARCH, should allow you to find the next occurrence.

[apersson850]

This code, cut out from a screen above, doesn't pad LIBAD7 with 18 zeroes.

	CLR	R4
	LI	R9,LIBAD7
	LI	R10,>0000
LIBCLR	MOV	*R10,*R9+
	INCT	R4
	CI	R4,9
	JLT	LOOP

It does read the two bytes at address 0 and copies them five times, for a total of ten bytes, to the area LIBAD7 .. LIBAD7+9.

This code will load 18 zeroes into LIBAD7 and the following 17 bytes.

	LI	R4,9
	LI	R9,LIBAD7
LIBCLR	CLR	*R9+
	DEC	R4
	JNE	LIBCLR

It's also faster, 30% smaller and doesn't use R10.

Edited July 16, 2020 by apersson850

[+Lee Stewart]

Here is a string search routine that works [Note—See better version in  post #158 ]:

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* String Search Routine                     ..Lee Stewart 16JUL2020 *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
*                                                                   *
*   BL to this routine.                                             *
*                                                                   *
*   Input                                                           *
*     R0: Starting address to search                                *
*     R1: Search range (i.e., length of search buffer)              *
*     R2: Address of search string                                  *
*     R3: Length of search string                                   *
*                                                                   *
*   Output                                                          *
*     R0: 0--if not found..address--if found                        *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
 
SEARCH MOV  R2,R4          ; copy search string address
       MOV  R3,R5          ; copy search string size
       INC  R1             ; adjust range for next instruction
SLOOP  DEC  R1             ; decrement search range
       JEQ  SNFND          ; to SNFND if out of range
       CB   *R4,*R0+       ; first char of search string found?
       JNE  SLOOP          ; if not, check next char
       INC  R4             ; if so, set to second search char
SLOOP1 DEC  R5             ; decrement search char count
       JEQ  SFOUND         ; if done, string is found!
       DEC  R1             ; decrement search range
       JEQ  SNFND          ; to SNFND if out of range
       CB   *R4+,*R0+      ; next char found?
       JEQ  SLOOP1         ; if so, check next char
       DEC  R0             ; if not, correct buffer address
       JMP  SEARCH         ; reset search string parameters
SNFND  CLR  R0             ; string not found in range
       RT                  ; return with R0 = 0
SFOUND S    R3,R0          ; we found it! correct address
       RT                  ; return with address of found string

 

As indicated, you need to supply the string search routine in R0 – R3 what you want to find and where to look. Upon return, R0 will contain the address of the found string or 0 if not found.

 

The routine does not insure that the length and range are not 0, but otherwise works with all the tests I threw at it. These tests were probably not exhaustive so let me know if you find a case where this routine fails.

 

...lee

[GDMike]

Super!  I'll try it. But I better Channge the subject soon here. Some are tired of seeing this go on and on...sorry bout that.

 

And I'm exhausting my search online and there is an alternative, some suggest searching backwards is faster because it filters better? I don't see the difference in my imagination...

But I'm all for faster.

 

Edited July 16, 2020 by GDMike

[GDMike]

Where do the parameters get set, before the BL happens or inside search?

Because I'm not getting a match, anytime.

And I set parameters prior to the BL.

Maybe that's why in guessing.

I'm testing R0 and it's always zero

My Params

LI R0,>23A4

LI R1,860

LI R2,>FE6C

Program goes nuts..

 

 

[+Lee Stewart]

7 minutes ago, GDMike said:

My Params

LI R0,>23A4

LI R1,860

LI R2,>FE6C

Program goes nuts..

 

You do not mention R3. You must set R3 to the length of the search string pointed to by R2. And, yes, you set those 4 parameters before you call the function with BL.

 

...lee

[GDMike]

Sorry, but yeah I did set all those prior to the call, and got fireworks screen.

But apparently I was able to reboot.

I'll look and see what I missed.

It works!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Well, you already knew that. 

But I'm able to make it work. I had some issue with the BL

Again, because I'm BLng from another BL and I didn't know if my Params were being remembered...

Go it!!! Oh my my maybe I can eventually end this ordeal tonight.

I've still gotta see what address I got left over and adjusting it to meet my screen needs, but I've pretty much figured that out.. I think.

Wow... hats off to everyone!!

Edited July 16, 2020 by GDMike

[+Lee Stewart]

16 minutes ago, GDMike said:

It works!!!!

 

Like I said, I am not convinced it is foolproof. The routine is currently restarting the search after a failure on the mismatched character. I am thinking it should probably start at the second matched character, i.e., move the search window by only one character upon failure.

 

...lee