pouët.net

6502 ASM and Registers

category: code [glöplog]
 
Hey guys,

This is the first time I'm coding with assembly and I have some doubts regarding the CPU registers. Are they guaranteed to have an initial value when I start the system (the system in question is a NES)? And what about other devices' registers?

Thanks in advance,
Danguafer
added on the 2012-04-06 10:49:29 by Danguafer Danguafer
dear Danguafer,

no.

Regards, aegis.
added on the 2012-04-06 11:08:39 by aegis aegis
And another fucking problem:

0xC00C BRK
0xC00D JUMP $C00D

If the program counter is 0xC00C during BRK, why is it pushing 0xC00E instead of 0xC00D (next instrunction)?

I'm using FCEUX to test the code. :<
added on the 2012-04-06 11:09:52 by Danguafer Danguafer
aegis,

lol.

Gratefully,
Danguafer
added on the 2012-04-06 11:11:21 by Danguafer Danguafer
That's weird about the break. If it's pushing $c00e when the next 3-byte instruction is at $c00d, it will end up in the middle of the instruction! To be honest I never examined the stack after an interrupt/jsr, but I guess this might be how it's supposed to behave.
added on the 2012-04-06 11:48:56 by linde linde
Just read this: "Regardless of what ANY 6502 documentation says, BRK is a 2 byte opcode."

Source: http://nesdev.parodius.com/the%20'B'%20flag%20&%20BRK%20instruction.txt

The problem is that my assembler is considering it an 1byte opcode. :P
added on the 2012-04-06 12:02:38 by Danguafer Danguafer
For the record: I'm using NESASM3.
added on the 2012-04-06 12:04:54 by Danguafer Danguafer
Pushing instruction+1 is just what the 6502 does.
added on the 2012-04-06 17:41:55 by xeron xeron
If it's a padding byte could you not drop an extra byte in on the end? (.byte $EA or something) I used DASM to do some NES stuff but that has the same behaviour afaict.




added on the 2012-04-06 18:01:18 by 4mat 4mat
Quote:
"Regardless of what ANY 6502 documentation says, BRK is a 2 byte opcode."
I would actually believe this. There are other cpu's with similar behavior; for instance the HALT opcode for the Gameboy cpu is supposed to be two bytes as well.
added on the 2012-04-06 19:10:35 by ferris ferris
"I'm using FCEUX to test the code. :< "

Use something like Nintendulator to test, its moar accuratez. :3
added on the 2012-04-07 04:36:49 by mudlord mudlord
@4Mat
Yes, you can use BRK for debugging, back in the old days it was commonly implemented (f.e.: http://forum.6502.org/viewtopic.php?t=1649&sid=75a3b25b8bd51fef56470b09ee30af61)
added on the 2012-04-07 10:25:22 by vscd vscd
What Xeron said. The opcode is 1 byte, $00, period.

And it has to be that way. BRK is intended to implement breakpoints, so its opcode must not be larger than the CPU's smallest opcode. Btw, look at the x86, which has a special opcode for int 3 which is one byte only, whereas the general int instruction uses 2 bytes.
added on the 2012-04-07 11:45:29 by Moerder Moerder
"Regardless of what ANY 6502 documentation says, BRK is a 2 byte opcode."

"What Xeron said. The opcode is 1 byte, $00, period."

Context. :)
BRK in itself is one byte of course, but what the quote refers to is that the opcode should appropriately be seen as two bytes (BRK + padding.) Language. :p

I wonder if this was originally a bug or a feature. I.e. if it was meant to work this way or if just happened to work this way because the instruction reuses the same circuitry as something else, and later became a "feature".

Quote:
I would actually believe this. There are other cpu's with similar behavior; for instance the HALT opcode for the Gameboy cpu is supposed to be two bytes as well.
Kind of different situation. 6502's BRK was designed/useful to work this way, or at least this mode of operation was supported. The GB's HALT opcode problem is purely a bug, where the same byte is repeated when it shouldn't be. This problem was fixed on GBC, so you know it was a bug. This glitch has no useful purpose, except maybe detecting that you're on a GBC when you don't have access to the initial values of the CPU.
added on the 2012-04-07 15:29:01 by nitro2k01 nitro2k01
Well, the author of that document can see BRK as a two byte op, if he likes. As far as I'm concerned I'll consider him fractally wrong.

Quote:
I wonder if this was originally a bug or a feature. I.e. if it was meant to work this way or if just happened to work this way because the instruction reuses the same circuitry as something else, and later became a "feature".


Could be a bug. Could also be that they had a number of use cases for BRK in mind and optimized it for the in their opinion most common one.
added on the 2012-04-08 12:38:17 by Moerder Moerder
brk is effectively a 2 byte instruction although the second byte is ignored.

what I meant to say earlier is that jsr and brk push pc+1, because they use the same mechanism to push the pc. Genuine interrupts push the real pc.

so... Rts expects pc+1, but rti does not. So brk/rti don't correspond as expected.

(I wrote a 6502 core :)
added on the 2012-04-09 00:23:19 by xeron xeron

login