pouët.net

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

dear Danguafer,

no.

Regards, 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. :<

aegis,

lol.

Gratefully,
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.

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

For the record: I'm using NESASM3.

Pushing instruction+1 is just what the 6502 does.

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.

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.

"I'm using FCEUX to test the code. :< "

Use something like Nintendulator to test, its moar accuratez. :3

@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)

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.

"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".

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.

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.



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.

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 :)