I now see you have commented-out two of the branches. So you get ZERO for negative, blanks for the other two.
You are also branching before you do the ED of the PAY, so you'll not get that at all for negative, but you will for positive and zero.
These are not Assembler errors, or logic errors, they are programming errors pure and simple. You have to honestly understand how they came about.
There is the logic, and there is the language. There is also the code to implement the logic.
You can't (yet) just sit down and start writing a program. You have to think about it. You have to "jot it down" in whatever way is comfortable for you (diagrams of some sort, pseudo-code of some sort, doesn't matter what) and then you have to set down some input data which will test your "program" (as you get more experienced this will become "parts of program" and then with more experience, you'll be writing the code without the actual diagramming/pseudo-code, it'll be "in your head"). You need good test data, some normal stuff, some abnormal stuff, and some stuff to test the upper and lower limits. That'll get you a general covering. Then from the data, work out your expected results. Then, work through your diagram/pseudo-code with the input data, recording the changes, and seeing if the expected results appear. If they don't, re-work it. Don't just "add in lines"/"comment out lines" and see what happens with real code. Once you are getting the expected results "by hand", then do the code, test with the same data. You'll know that either it is the implementation when an error occurs, or you can't hack the initial design.
This isn't Assembler advice, it is programming advice, learning to use a language advice. For me there are no short-cuts to this. Look at your program, the evidence is there: you've been through it multiple times, twitching it here, bodging it there. You've taken a "short cut" and wasted so much time in doing so and it still doesn't work.
If you don't sort your method out, then you'll be no good at writing code (any sort) for anyone else, only for yourself, because you'll put up with your limitations.
This may not count as what you want to hear, but you have to sort it out, otherwise you'll keep making basic errors and blaming it on the new instructions you are trying to master (first it was the BC, then the "logic", but all the time just dumb, no other way to say it, errors). It is enormously important in programming to recognise that when something doesn't work, it is because you have dome something (or some things) wrong. You, twice, looked at the wrong thing because you dind't realise how bad a mistake(s) you could make with plain programming.
My patience has its limit. I think you need a big improvement, even if you have to take a backward-step-or-two and invest your time differently, or I am out as well. We are not teachers per se. You can learn much, but you have to get your own basics working for yourself.
Please read this through several times. I'm trying to help by writing this, as it is the last-chance-saloon. If you do the same again, I'm keeping shtum.
- These users thanked the author BillyBoyo for the post:
- RISCCISCInstSet (Mon Nov 12, 2012 4:55 am)