C64 ASM Question.

[JohnnyRockets]

Hi y'all!

 

I have the following code:

 

processor 6502

org $033C ;SYS 828

LDA #$48

JSR $FFD2

LDA #$49

JSR $FFD2

 

 

This prints "hi", but when I call this from basic:

 

100 for j = 1 to 10

105 sys 828

110 next j

 

... it only prints "HI" one time (using VICE emulator), or it is printing it 10 times one on top of the other, I'm not sure.

 

The question really is, why doesn't it print: HIHIHIHIHIHIHIHIHIHI ???

 

 

 

Thanks,

 

 

 

JR

[TMR]

If that's the entire assembly program it's because there's no RTS after the two PRINT commands; chances are it's printing the first HI and hitting a BRK that stops everything dead.

[JohnnyRockets]

Hi TMR!

 

Yep, it is as you said!

 

Fixed it! Thanks.

 

Have a great weekend...

 

JR

[Dave Farquhar]

If you're doing a JSR $FFD2 followed by an RTS, you can cheat and do a JMP $FFD2 instead (for the second statement). Not a lot of savings, but it's something.

[JohnnyRockets]

Hi Dave!

 

Thanks, I'm going to investigate that a bit. I am kind of working through a book and we have not come to the JMP command yet. Did I mention I am a bit new to ASM?

 

I appreciate your reply.

 

 

JR

[JohnnyRockets]

Okay, a little more help for the ASM impaired please...

 

Now that I think about it, I'm not sure about something....

 

Why DO you need the RTS? Why must we return from the subroutine (I think that is what RTS does)?

 

Does that return the program back to memory location 033C to start all over again?

 

And you mentioned that in my original iteration, the program probably hit a BRK and ended, but where is the BRK located in the program?

 

Thanks!

 

 

JR

[The Usotsuki]

Exactly - RTS = Return from Subroutine.

 

The BRK opcode is 00.

[TMR]

Why DO you need the RTS? Why must we return from the subroutine (I think that is what RTS does)?

 

Because by calling the routine with a SYS command you've basically started a subroutine and without the RTS the processor doesn't know when to hand control back to the program doing the calling.

 

And you mentioned that in my original iteration, the program probably hit a BRK and ended, but where is the BRK located in the program?

 

There's no way for machine code to know that your code had ended after the second JSR $ffd2 so it just carries on fetching whatever is in memory after that point and trying to execute it. Since the memory is usually filled with patterns of $00 and $ff after powering up, it'll almost certainly hit one of those; $ff isn't a valid command so does nothing when executed, $00 is BRK.

 

BRK forces an interrupt to occur and can be used for debugging purposes, in your program's case it did pretty much the equivalent of slam the Run/Stop and Restore keys.

[GroovyBee]

$ff isn't a valid command so does nothing when executed

 

On the 6510 opcode $FF is the illegal instruction of the form "INS/ISC $nnnn, X"

[TMR]

 

 

On the 6510 opcode $FF is the illegal instruction of the form "INS/ISC $nnnn, X"

 

[shhhh!] It's confusing enough without having to explain there are opcodes in the gaps between opcodes!! =-)

 

[GroovyBee]

It was more of a response to "it does nothing". Whereas in reality it does something that is not expected because the original code is "out out of control" .

[Dave Farquhar]

JR, since your ASM routine resides in the cassette buffer, the 64 just executes whatever random data happens to be in the buffer after returning from your second JSR $FFD2. In those cases, it's always just a matter of time before it runs into an unintentional BRK instruction and stops.