5

I'm running the example code from Assembly Lines chapter 5 programs 2A and 2B which print the entire character map for the Apple II and then are supposed to break, however my code is looping permanently. Here is the code:

      ORG $300
HOME  EQU $FC58
CTR   EQU $06
COUT  EQU $FDED

START JSR HOME
      LDA #$FF
      STA CTR
LOOP  LDA CTR
      JSR COUT
      DEC CTR
      BEQ END
      JMP LOOP
END   RTS

I have double checked the book and don't think I mistyped anything but the program just loops over and over, almost like the zero flag isn't ever properly set. I know the zero flag works for dex and dey because I've used those for loop counters in prior exercises.

Thanks!

Improve this question
12
  • 1
    Not an Apple programmer, but my first thought is - does DEC set the condition codes? I've used computers where "SUB #1" and "DEC" are not identical.
    – dave
    Commented Oct 4 at 19:18
  • I see what you're saying - the zero flag may be getting cleared by DECing the memory before checking the BEQ condition. I'll swap those and see if it makes a difference. Thanks for the suggestion, dave!
    – Eric Noble
    Commented Oct 4 at 19:27
  • @Justme I think that's a typo and that you meant N and Z, the latter of which is what BEQ checks.
    – Tommy
    Commented Oct 4 at 19:44
  • 1
    Check that COUT equate - I'm not familiar with the specific assembler you're using here (I'm a KickAssembler user) but I suspect whatever the JSR #FDBD instruction is being assembled as, it's not what you think and the DEC afterwards isn't being executed. Have a look at the assembler output to see what opcodes it produced. Also, get yourself a good debugger so you can single-step the code and watch register values as it executes.
    – Eight-Bit Guru
    Commented Oct 4 at 20:14
  • @Eight-BitGuru I do know the dec is happening because without it the character printed to screen would not be changing - the dec both decrements the loop & the character to be printed. Still puzzling this one. I am using Merlin Pro 2.43 :) Heard good things about KickAssembler though.
    – Eric Noble
    Commented Oct 4 at 20:30

1 Answer 1

Reset to default
7

For those who come here scratching their heads, this is explained later in Assembly Lines - I was attempting to BRUN the assembled code, however that struggles with properly exiting when printing some control codes using COUT specifically. The solution was to BLOAD the code and then run it with CALL 768. Loops just fine now. Not a code error at all but a quirk of the Apple II Monitor.

Improve this answer
2
  • The debuggers in modern emulators can be very helpful when something seems to go off into the weeds. See e.g. 6502disassembly.com/applewin-dbg.html
    – fadden
    Commented Oct 5 at 15:47
  • Perhaps you can incorporate this circumstance into the question?
    – user3840170
    Commented Oct 5 at 17:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .