What is wrong with this logic... I am trying to build a 16 bit IF THEN statement... such as

IF C < 16 THEN (Pass thru to argument...
(If failed...RTS)

Assume these are the current values...
30005 #0
30004 #0

30016- AD 35 75 LDA 30005
30019- C9 00 CMP #0
30021- 90 0A BCC 30033
30023- D0 07 BNE 30032
30025- AD 34 75 LDA 30004
30028- C9 0F CMP #15
30030- 90 01 BCC 30033
30032- 60 RTS
30033- 4C 40 75 JMP 30016

Whoop... I this instance, I want to loop it back to the IF statement... creates an endless loop...

Your source code isn't making a lot of sense. What are these 300.. numbers? What does 30004 #0 mean? Ditto with 30005 #0?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

He's obviously working in base 10, BDD, at least in the source. And 30004 #0 is his way of saying


I added some generic comments that may or may not prove helpful ... let me know if anyone needs me to explain further.

Mike B.

I was thinking the same thing.

Again, you never need a compare-to-zero instruction after a load instruction, or after a logic or arithmetic instruction either. It's a built-in, implied part of the instruction already. I suspect however from your "IF C < 16 THEN" line that the CMP #0 was supposed to CMP #16.

What is at 30005? Is it I/O? If it's RAM, you'll just re-load the same thing again, and keep getting the same result, right? The constants should usually be given descriptive names. Also, why not just branch directly to 30016, instead of to a jump instruction that sends it there anyway? You have a branch to a jump to go back to re-loading 30005 again.

I started trying to make this structured, but I now I thought I better find out better what you're trying to do first.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

It's highly obvious to me what he wants to do ... heck, it's in the title of the thread! I'm just hesitant to blurt out the answer, because I want to give him a chance to work it out for himself.

Mike B.

The only way it makes sense is that all the leading 3's are actually supposed to be $s right?
Even then looking at the dissasembled code on the left the addresses don't match.

Is nobody here ever reading previous answers? Mike B. already said that the numbers are base 10 (decimal) instead of base 16 (hex). I also like the way Mike writes comments in a program. In this case it makes really clear what is going wrong.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

C'mon guys ... he's using DECIMAL!

He has a 16-bit little-endian unsigned integer named C at 30004 ($7534) and 30005 ($7535) and he wants to code:

Naturally, the 6502 may need to test both bytes. If the "high" byte is zero and the "low" byte is below 16 ($10), we're in THEN land. If either or both of those conditions are false, we're in ELSE land.

Mike B.

I am sorry about being a big pain in the butt about this (putting it mildly)...

I figured out what the bug was... take the basic

10 IF C<16 THEN C=C+1:GOTO 10
20 C=0:GOTO 10

Now take what I did...

10000 JSR A
10003 JSR B
10006 JSR (END..BACK TO COMPUTER PROMPT)

A IF C<16 THEN C=C+1:GOTO A
*(IF FAIL...RTS)

B C=0:GOTO A


The first time it fails... it RTS back to the JSR list...
afterwards... it processes B, and then jumps back to A...
however... the 2nd time it fails... the RTS goes back to the JSR
list and not BBB like I wanted.. therfore ending the program.


It was a mistake in logic.

To correct.. I replaced the RTS in the IF statement with a fake (GOTO NEXT LINE)...
the compiler on the 2nd pass determins where in memory those lines are... so it looks
up the list for the current line its on.. (then +1) to create a correct JMP instruction.
Also had to replace the END of program from the bottom of the JSR list to after the
very last compiled statement. Works much better... and just as its equiv applesoft program!
Also went thru a couple pdf manuals late last night on the internet and rewrote the rest of the
if statements for a<c a>c and a=c equivs and all checked out.

Thank you for your help!

He's obviously working in base 10, BDD, at least in the source. And 30004 #0 is his way of saying

Code:
org $7534
dcb 0

.......NOPE... your wrong. When I started learning assembly.. I couldn't take the hex, so I built an assembler that
did everything entirely in decimal... and then has my Assembler.. in basic.. poke the values of the assembly code
I translated from hex... its actually quite a good assembler (for me anyway)... there are also provisions for typing in
other peoples code by putting $ infront of the number and it converts it to decimal for me... can I show a pic here?

Seems we are not talking the same language. Mike was spot on saying you were using base 10 (decimal) and showed an example how it would look like in base 16 (hex). People on this forum definitely need to improve their reading skills!

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Just curious, why could you not "take the hex"?

I admire his spirit. Nail, meet sledgehammer.

There's something to learn here when someone decides creating an assembler is easier than learning a new number system.

As a note, I appreciate that it's like near impossible to get an output of an assembler in anything but hexadecimal (in terms of the assembler listing, and the addresses and op codes and what not), unless, of course, you're running on a PDP-* or something.

However, most any assembler will happily take decimal arguments:

That's perfectly valid code, using decimal values and arguments. The listing, however, will be in hex.

Hexadecimal is popular because it concisely, and regularly, represents 8 bit values well.

The only reason I can think of why the PDP continued with its fixation on octal, on a 16 bit architecture is simply momentum from other machines with other word sizes. I always felt octal was rather horrible. But that's me.

I will hazard the opinion that if you can't get over your aversion to hexadecimal notation you are going to have a rough time with assembly language in general. Use of hex in assemblers and machine language monitors is nearly universal because, as whartung noted, it concisely represents quantities that are multiples of eight bits.

Hex is "strange" to human beings because we are accustomed to base-10, which comes from having 10 fingers and 10 toes. I supposed if we had evolved with eight fingers and eight toes we'd be counting in octal. Regardless, if you stick with learning and using hex it will soon become more-or-less natural to you.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!