SX asm snippet

Rsadeika

I can not figure out what is going on with this program. What I expect is the LED to be off until the IRpin gets an IR signal, then it breaks out of the SNB·loop, turns the LED on, and then loops back to Main, where it turns the LED off, and·finally it waits for an IR signal, again. What it is doing right now, is·the LED goes on, and stays on. When I step it through DEBUG, it works as expected.

Any ideas or suggestions.
Thanks in advance

******CODE
device sx52
device oschs3····· ;High speed crystal, 1MHz - 75MHz
IRC_CAL IRC_FAST·· ;For use with external crystal/oscillator
freq 4_000_000
reset 0······
;; I/O definition
IRpin = re.1···· ;IR detector
LEDon = rd.0···· ;LED

·mov !rd,#%11111110· ;Set rd.0 to output

Main
·setb rd.0········· ;Turn off LED
again
·snb IRpin········· ;Waits for IR signal
·jmp again

·clrb rd.0········· ;Turn on LED
·nop
·nop
·nop
·nop
jmp Main

sleep
end··············· ;End of code

David B

If the mode register is not correctly configured then your direction setting command will not work.

Before you write a value to !rd, you should set the mode register, otherwise you are depending on whatever mode the CPU happened to be in for what effect your value will have.

SX28s and smaller may set the mode with the mode command, but the 48 and 52 need to write the right value to W, then transfer W to the M register.

Look up and read about using the mode register in the documentation.

David

Bean

You may need a delay loop before you start sampling the IRPin. That is probably why it works in the debugger.
Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95

http://www.parallax.com/detail.asp?product_id=30012

"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015

Product web site: www.sxvm.com

Those that would give up freedom for security will have neither.
·

william chan

oschs3 is too fast for 4Mhz.
You should try oschs1 first.....

I think your oscillation is not stable, that's why only debug works b'cos the oscillation is controlled by the SX-Key.

Rsadeika

Feedback:
Since their were a couple of different suggestions made, I want to share my results.

The major culprit is a freq and NOP issue. When I increased the freq setting to 50_000_000, and removed the three NOP's, the program worked as expected. But it was still getting some random flickers on the LED; IR detcter was picking up some random stuff. I inserted a
MODE #$0f
mov w,%11111110
mov !rd,w
that took care of the random flickers, still not sure how that works. Then, one at a time, inserted an NOP, worked as expected. Inserted the second NOP, worked as expected. The third NOP, started disrupting the timing, in this particular case, never gets back to the top of the Main loop, LED never shuts off.

So, I thought the NOP was just a simple 4 cycle timing delay. Why is it having an affect on or with the freq choices? With two NOP's works fine , the third one disrupts everything. I would hate to think of what would happen if I used this within an interrupt.

Any ideas of what the proper use of the NOP instructions are.

Bean

Please post the whole program.

When you say "I inserted a" we have no idea where you inserted it.

I think you meant to do this:

MODE #$1f ' Mode to SET direction on SX48/52
mov w,#%11111110 ' You were missing the "#"
mov !rd,w

NOPs are just that, they should have no effect other than taking 1 cycle (not 4 cycles).

Again please post the whole program and we'll get this problem licked...

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95

http://www.parallax.com/detail.asp?product_id=30012

"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015

Product web site: www.sxvm.com

Those that would give up freedom for security will have neither.
·

Rsadeika

Sorry, I keep thinking, I got straight in my head.



******CODE
device sx52
device oschs3····· ;High speed crystal, 1MHz - 75MHz
IRC_CAL IRC_FAST·· ;For use with external crystal/oscillator
freq 50_000_000

reset 0
····
;; I/O definition
IRpin = re.1···· ;IR detector
LEDon = rd.0···· ;LED

;·mov !rd,#%11111110· ;Set rd.0 to output

·mode #$0f·········· ;0f -> TRIS_
·mov w, #%11111110
·mov !rd,w

Main
·setb rd.0········· ;Turn off LED

again
·snb IRpin········· ;Waits for IR signal
·jmp again

·clrb rd.0········· ;Turn on LED
·nop··············· ;Works as expected at 50_000_000
·nop··············· ;Works as expected at 50_000_000
;;·nop··············· ;This creates a problem
·························· ;prevents completion of
·························· ;jmp Main
jmp Main

sleep
end··············· ;End of code

pjv

Hi There;

If the code you posted is literally what you are executing, then you have two problems with the mode portion.

Firstly, for the SX 48/52 (only) the mode register CANNOT be written directly as you are doing. You do "mode #$0f", and instead you MUST go through the W register to set the mode correctly:

mov w,#modevalue
mov m,w

You see, the SX 48/52 only uses the lower 4 bits (bits 3 through bit 0) of the "mode" write instruction, leaving the 5th bit (bit 4) be whatever its previous state was. On the other hand, transferring w into m transfers all 5 active bits of w (bits 4 through bit 0) into m.

Secondly, again for the SX 48/52 only, your use of a modevalue of #$0f is incorrect for SETTING the direction registers; that is the mode value for READING the direction registers. To SET them you must use a modevalue of #$1F, not the modevalue of #$0f that you have......that value is used·for SETTING·the SX 28 series.

Cheers,

Peter (pjv)

Post Edited (pjv) : 12/13/2005 6:08:35 PM GMT

Rsadeika

Thanks Peter,

I made the suggested changes, the compiler did not complain.

I tried putting in some 'pause' code, as described in the Guenther book, the program did not like it. I can get two NOP's in, but no pause loops.

I am comming to a conclussion that the sx52 is very, very tempermental, or the SX52 proto board has its own temperment (interesting that I give it human qualities). I guess I simply have no idea as to how to get around the problem that is occuring in the very straight forward snippet. And the worst part is, their is no easy method of narrowing down the problem, is it the compiler, the Sx52 proto board, or what. I guess, since no else is posting any concerns about their SX52 proto board experience, then it must be me, as I toss my hands up in the air.

David B

I also had a lot of trouble getting my sx52 to run properly. When I wasn't using the mode and bank commands properly, or was sticking variables into bad memory locations, the chip seemed to me to be flaky, too.

But after I learned about the changed mode command usage, and the changed bank command usage, and the different memory banks as compared to the sx18 or sx28, the chip worked exactly as it should.

You may actually be ok in this specific case with your use of the mode command. The sx28 is documented to reset to a value of mode #$F, which is "set IO direction" mode. I don't know whether the sx52 resets to a corresponding #$1F, but if it does, then you may (accidently) be ok either not setting mode or issuing "mode #$F", because the fifth bit would already be correctly set, even though what Peter and I said about using W to load M instead of "mode" is still what you will need to use for changing modes.

So my advice would be to take it slow and make sure you've taken into account all the things people warn about before totally giving up.

David

Rsadeika

Thanks David,

I have lowered my hands, settled down a bit, and am ready to push forward. If this was easy, then everybody would be doing it.

The next thing I have to get straightened out is the memory usage·thing. I think that the problem is exactly that, even the smallest piece of code, takes up more room than one would expect. I noticed in the debugger, code wise, there is a lot of stuff that gets inserted before it even gets to my piece of code. So, I do not have any idea as to where my code starts or ends in memory, and with paging, another hurdle to get over.

So, now I will take into consideration that the third NOP, in my program, may have gone beyond the page boundry. And that, the many examples that are shown for the sx28, may not function properly on the sx52.

Bean

There are several things that I would change.

1st
Use "RESET Start" and put a Start label where you want your program to start at

2nd use this to set rd.0 to an output

·mov w,#$1F
·mov m,w
·mov !rd,#%11111110

3rd
Because of your code as soon as you turn the LED on you go right back and turn it off, I see no point to the code.
If you want the LED pin to go low when the IRPin goes low then just do this:

Main:
·MOVB LEDon,IRPin
·JMP Main

There is no reason why the number of NOPs would make it not run. It's not the SX52's fault.
Your program should not come anywhere close to a page boundary.

There is something funky in the setup.
I would try removing the IR receiver and just connect the pin with a wire to Gnd or Vcc.

Keep trying different things...

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95

http://www.parallax.com/detail.asp?product_id=30012

"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015

Product web site: www.sxvm.com

Forget about the past, plan for the future, and live for today.
·

Rsadeika

Bean,

Thanks for the detail. As to the 1st point, I tried RESET Main instead of RESET 0, that corrupted my results. The 2nd point, I finally figured that one out, and my code is exactly like your code. 3rd point, I wanted to create some code that would tell me that my IR detector was working properly (I already fried two of them) as I pushed a button on the remote controll. When the snippet is working, and·I hold the button down, the LED flashes, as expected,·I wanted to put in a slight pause so the LED stays on for a second.·I am trying to lay the ground work for a functioning IR remote controll program in assembly.

After I get this small snippet to work then I want to go ahead and add the rest of the code, capture the remote controller command code, and start working with the data.

One way to learn is if you build it yourself, hopefully, this is not re-inventing the wheel.

Oh, I tried Guenthers tut003.src, on the SX52 proto board, that did not work either. The LED turned on and stayed on. That code is supposed to pause, turn the LED on, pause, and turn the LED off. So, there is something strange that is going on, that is what is so frustrating.

Rsadeika

Here is a new snippet, right out of Guenthers book. I had this code setup on my SX28 tech ·board, so I know that it works.

I made the modification for it to run on my SX52 board. All I have is an LED circuit on the breadboard, just as described in the book. Again, what is expected is a pause, turn the LED on, a pause, turn the LED off, jmp to the top of the loop and do it over again and again.

When I run it, the LED turns on and never turns off, no pauses what so ever. In the tutorial a freq 50_000_000 is used, so the freq are matched. The only difference is, the tut uses OSCHS2, I use the OSCHS3.·So, I am wondering, does the SX52 have some kind of effect on the pause part of the the code. On the SX28 you could definitely see the LED pause.

Ray



*****CODE

;;;
;; tut003sx52.src
;;;

device sx52
device oschs3····· ;High speed crystal, 1MHz - 75MHz
IRC_CAL IRC_FAST·· ;For use with external crystal/oscillator
freq 50_000_000

RESET Main

·org $08
Counter1 ds 1
Counter2 ds 1
Counter3 ds 1

·org $100
Main
·mov w,#$1f········· ;SX52 specific
·mov m,w

·mov !rd, #%11111110


Loop
·decsz Counter1
·· jmp Loop
·decsz Counter2
·· jmp Loop
·decsz Counter3
·· jmp Loop
·clrb rd.0
Loop1
·decsz Counter1
·· jmp Loop1
·decsz Counter2
·· jmp Loop1
·decsz Counter3
·· jmp Loop1
·setb rd.0
jmp Loop

end··············· ;End of code

David B

You've run into one more of the minor differences between the sx52 and the sx28's.

In the sx52, variable space starts at $A, not $8.

David

pjv

David, You're The Man.....nice find!

So in starting the variables in the wrong spot (at $08 instead of at $0A) the variable "Counter1" lands right on top of Port D, and Counter2 lands right on top of port E.

Clearly then, the program starts a $100, sets the mode (now correctly), and configures port D as all inputs except for bit 0 as an output. Good so far.

The value of port outputs are not defined at power-up, so reading port D would produce either 0000_0000 or 0000_0001, as bits 7 through 1 are inputs which read as zero, and only bit 0 is an output.

Now the trouble starts.

The next instruction decrements Counter1 which really is port D. So the value of port D is decremented. If it had been 0000_0000 at power up, now Counter1 (port D) will have a content of 0000_0001, yielding a no-skip condition, so proceding on to the next instruction which jumps back to "loop".

Again the next instruction decrements Counter1 (port D), which will subsequently contain 0000_0000 and yields a skip condition.

So the next instruction attempts to decrement Counter2 (port E) which has not been configured as an output, so its value is not decrementable and remains 0000_0000, never yielding a skip condition, hence always jumping to "loop".

So what we have here is an endless loop with port D bit 0 (LED ) alternating on/off every time through the loop, because that bit is altered by the decrementing instruction. So the LED sees a very fast 50% duty cycle and will appear as steady "on" at half brightness.

The fix of course as David alludes is starting the variables at $0A.

This expample demonstrates several things:

1. Post your COMPLETE code including the things you think are not important. In this case the "org $08" was the culprit, and was not shown until the last post.

2. Debugging with the SX-Key and single stepping would have shown the sequence and isolated the programming error immediately.

3. Guenther's simulator also would have shown up the problem immediately.

4. Things are not always what they appear. The statement "the LED turns on and never turns off" is an incorrect observation. It DOES turn on and off, just very rapdily. Again, single stepping in debug or SX-Sim demonstrates this.

Use these tools and they WILL save you a lot of agravation.

All in all, a very good learning exercise for Rsadeika, and probably good advice for all beginners.

Cheers,

Peter (pjv)

Rsadeika

Thank You David and Peter,

I did not run the program through the debugger because I was so convinced that the pauses were supposed to be visible. Now, I am starting to see how to use the tools, from now on I will have to be a little less stuburn and little more logical.

The other big problem that I found was, I had a corrupted SX-Key system. It was very subtle, when I was doing a Save or a Run, the changed file was not really being saved, not on the first try, so that added to the confusion of everything. I stumbled across that late last night, double checked this morning, the problem was there. So I did a new install of the latest SX-Key system, and I noticed some other problems disappeared. The only thing that I did recently was update the SX/B stuff as it became available. So now I am very suspect of my SX-Key system, everything else on my·computer is in order, only the SX-key got corrupted somehow.

Thanks again guys

Rsadeika

The drama continues,

I changed the org $08 to $A. This time I ran it through the debugger first. As I single stepped through the program everything was working until it got to first Loop. The loop gets stuck at decsz Counter1 jmp Loop. The reason the LED never pauses is because it never gets out of that first Loop. I ran it through the walk function, it just continued to loop in the same place. I tried changing some of the org values, like changing it back to $08 to see what would happen, same thing, never gets out of the first decsz loop.

The way I understand decsz to work is the Counter1 gets assingned a size and location, in this case $0a is the location, the decrement starts at·7 (eight bits)·and decreases its way back to 0, at which point it moves to the next decsz. Since it gets stuck in the loop,·it never reaches 0,·so it just keeps on looping. So now I am wondering if Counter1 has really been treated like a variable or for some reason its being·treated like a label. I think I am in over my head on this one.

The SX-sim confirms the constant looping in the same place.

Ray

pjv

Ray;

PLEASE, HOW MANY TIMES DO YOU NEED TO HEAR THIS.....POST YOUR NON-WORKING CODE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

There is obviously a problem with what you're doing because it works perfectly on my test set-up as well as in Guenther's simulator, and that uses no hardware.

So by not posting EXACTLY what you are running, you're your own worst enemy by just making us guess, and that's a waste of your time as well as ours.

And that's unfair. So unless you participate better, I'm outta here!

Peter (pjv)

Bean

You do realize that the first loop WILL loop for 255 times before it falls through to the next loop ?
Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95

http://www.parallax.com/detail.asp?product_id=30012

"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015

Product web site: www.sxvm.com

Forget about the past, plan for the future, and live for today.
·

David B

Well, I don't get it.

I ran that code in SxSim, and while it did spend most of its time in the decrement $0A loop, every time it passed zero it DID decrement $0B, just like it is supposed to.

Are you sure your SIM test isn't decrementing $0B on every zero pass of $0A?

Rsadeika

The code has not changed, the code is a cut and paste from my·computer to this post.

Bean, when I had it in Walk, I am·pretty·certain that I let it run long enough, I checked again, I let it run for at least a minute. It never gets out of the first Loop. What I expected it to do was walk in the first Loop, then move down to the second Loop1, do its·walk in there, and then head back to the top, and do it all over again.

Now their is something wrong, if Peter is running the same code on his system, and it works for him, and I am running the same code on my system (just did a fresh installation of SX-Key), and it does not work the same way as Peter describes it, then maybe my sytem is corrupted again.



*****CODE

;;;
;; Tut003.src
;;;

device sx52
device oschs3····· ;High speed crystal, 1MHz - 75MHz
IRC_CAL IRC_FAST·· ;For use with external crystal/oscillator
freq 50_000_000

reset Main

·org $0a
Counter1 ds 1
Counter2 ds 1
Counter3 ds 1

·org $100
Main
·mov w,#$1f
·mov m,w
·mov !rd,#%11111110

Loop

·decsz Counter1
·· jmp Loop
·decsz Counter2
·· jmp Loop
·decsz Counter3
·· jmp Loop
·clrb rd.0

Loop1
···· ·decsz Counter1
·· jmp Loop
·decsz Counter2
·· jmp Loop
·decsz Counter3
·· jmp Loop
·setb rd.0
·jmp Loop

end

pjv

OK Ray;

The problem is in your code!

In the bottom, "Loop1" section, you are now returning by juming to "Loop" instead of "Loop1" as you had posted earlier, and that's the code the rest of us are successfully running.

Cheers,

Peter (pjv)

Rsadeika

Sorry, another lesson learned. Sorry about the waste of time.

Ray

pjv

Ray it's not a waste if you learned something and take it to heart!

A good lesson for all beginners; be as detailed as practical, and describe the problem as precisely as possible.

Cheers,

Peter (pjv)

Rsadeika

The new code is a fully functinal, adjusted to run on the SX48/52 proto board. After a couple of written brow beatings, I finaly got it. Hopefully I will not get lazy again, and revert back to my old ways.

David mentioned that you first have to get the concept of variable memory and program memory straight in your head. So, here goes. From the compiler point of view, for the beginer, there are two areas in processor memory, one for the variables and one for the program space. From the programmers point of view, I have to define or designate which is which. As an aside, for the 16bit x86 assembly people, think DATA segment (DS)·and CODE segment (CS).

Start with the variables, for the SX28 it is $08, for the SX52 it is $0A. So, when you code org $0A, SX48/52 specific,·the compiler is alerted that everything·after this point is going to be variables, and to be put into the variable memory space.

For the program, or code, you would use RESET plus a label, for example RESET Main. The compiler is alerted and it will place the code into the program memory. I lean towards stucture, so I know what is what.

The trick is that you want keep the contents seperate, if you place a variable, or at least what you want·to be treated as a variable, into the program space, that is going to be a problem.

So now you are thinking, where does variable space end and where does the program space begin, from a programmers poit of view. For the variables it is org $08 or $0A, as explained earlier. And RESET for the program, or code. You have to be very aware of this, you do not want to be putting code into variable space and vice-versa.

Best thing that I can recomend is, take some example code, like Guenther's , which I have at the end of this post, run it first, to make sure it works, then use the spider (debugger) to play around with. Change some of the org values around an see what happens.

If I went astray somewhere, somebody put me back on track. I feel that this concept is very, very important, and you may want to make sure that it is well embedded in the brain. I know some of this was being talked about in another thread, but I wanted to keep as simple as possible, and not get into the minutae of achitecture, and other stuff.





******CODE

;;;
;; Tut003.src
;;;

device sx52
device oschs3····· ;High speed crystal, 1MHz - 75MHz
IRC_CAL IRC_FAST·· ;For use with external crystal/oscillator
freq 50_000_000

reset Main················ ;Label where the program starts

;Data memory
·org $0A··········· ;SX52 -> $0A, SX28 -> $08 Data memory
·························· ;························ satrt
Counter1 ds 1
Counter2 ds 1
Counter3 ds 1
;End of data

;Code memory
·org $0············ ;Code memory start position
Main
·mov w,#$1f········ ;
·mov m,w
·mov !rd,#%11111110

Loop

·decsz Counter1
·· jmp Loop
·decsz Counter2
·· jmp Loop
·decsz Counter3
·· jmp Loop
·clrb rd.0

Loop1
···· ·decsz Counter1
·· jmp Loop1
·decsz Counter2
·· jmp Loop1
·decsz Counter3
·· jmp Loop1
·setb rd.0
·jmp Loop



jmp $····· ;I like to use this to end my code
·········· ;at this point it is in endless loop.
end

Bean

Just one small correction. There is only one ORG pointer. Just because you set the ORG $0A does not tell the assembler that you are defining variables. That is done on a line-by-line basis.
It's kind of ignorant but if you do this:

ORG $0A

counter1 DS 1 ; counter1 = $0A in VARIABLE space

NOP ; This instruction is at address $0B in CODE space

counter2 DS 1 ; counter2 = $0C in·VARIABLE space

NOP ; This instruction is at address $0D in CODE space

counter3 DS 1 ; counter3 = $0E in·VARIABLE space

So you see the ORG pointer is incremented the same for variables or instructions. You see how we have left "holes" in the variables space and in the code space.
Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95

http://www.parallax.com/detail.asp?product_id=30012

"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015

Product web site: www.sxvm.com

Forget about the past, plan for the future, and live for today.
·

Rsadeika

Bean,

This could cause some serious nitemares.

Wow, I thought I was making some headway.

Back to square one, org $00 - $07 (SX-28), these are designated for other things, $08 is the first position where you can start variables or CODE, and the compiler sorts the two apart. In your example, the NOP $0B, and NOP $0D would be CODE·addresses, and $0B and $0D positions·would still be availble in the variable space. What I get out of this, is that there is a specific area where you can start, $08 (SX-28), the RESET is a programming convience tool.

Technically it is not as complex as I thought, you have to start at certain point, $08 or $0A, and the compiler decides according to the text of your program, in this particular case Counter DS 1, is to be treated as a variable, and it is put into the variable memory space, code, decsz Counter1, is treated as CODE and put into program memory space. The trick is to keep everything straight in your head, making sure that program is in the sequence that you want.

Am I getting close.

Ray

Guenther Daubach

Rsadeika,

the RESET is not just a programming convenience tool - it is an important directive.

When any SX starts program execution after a reset or power-on, it reads and executes the instruction located at the highest available program memory first, so this address should always contain a JMP instruction sending program execution to a point where YOU want to start it.

With a directive like

RESET Main

the assembler automatically generates a JMP <address of main> for the highest location in program memory. Note that after power-on/reset, the high page select bits in the STATUS register are automatically cleared, i.e. PAGE 0 is automatically selected. This is why the start of the main program can only be located in the first page of program memory.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

G

pjv

Hi Ray;

You are indeed very close.

There are two addressable sections to the processor's memory; the RAM (variables) part and the ROM (program code) part. They are separate.

The org $xx command is used to set the starting point of either section; the compiler understands the DS or DW assignments to imply RAM, and all other assignments as ROM. As Bean pointed out, every RAM assignment and every line of code increments the memory pointer, so it is usual to not inter-mix varable assignments inside of your code. If you do, you will need to specifically keep track yourself otherwise you will get a mess.

So it is easiest to define ALL your variables at the beginning of your program after setting the org to $08 or $0A, followed by the code portion after setting org to $0, or $100, or whatever. The compiler will realize that code statements are not intended for the RAM section, and in ROM you need not "skip over" the area of $0 through $0A.

RESET is the reserved word that references the start point of your program (any point you choose) on a power-up or reset. The org $00 location is somewhat special; only if you have interrupts enabled. That is the point where the processor goes to on detection of an interrupt, and it will be the first loction of any ISR routine you might have.

That is why typically you see the "Main" programs starting at some point other than $00; for convenience often at a new page, say $100, but could be anywhere.

Post Edit;

Yes, Guenther adds another important point. Let me explain that in some other words.·When the processor powers up, it executes the topmost instruction of ROM memory, and that location must hold a·"jump to address" instruction specified by the RESET word. That is how·the program·can start anywhere you choose. It might be that it is restricted to anywhere in the first page......I need to check that for myself; never been an issue.

You don't need to code that topmost instruction, the assembler does that for you, but you DO need to specify the jump-to address, and that is done with the RESET word.

Have fun.

Cheers,

Peter (pjv)


Post Edited (pjv) : 12/15/2005 10:13:33 PM GMT

Guenther Daubach

Peter,

the SX datasheets say that the page select bits in the STATUS register are all cleared at power-on/reset. Thus page 0 is in force when the first JMP at the highest program memory location is executed. SASM will even generate a "Reset address not in page 0" error if you try to place it into some other page.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

G