STZ zp Opcode effect on various Retro-computers/consoles

[leeeeee]

Faster, shorter, no decimal mode problems.

Code: Select all

1536: PHA
1537: LDA #2    ;color value
1539: STA 53272 ;store color register
1542: CLD       ;clear decimal mode
1545: ADC #2
1548: STA 1538  ;modify the code itself
1545: PLA
1546: RTI

Lee.

[AtariKSI]

BigEd wrote:

Hi AtariKSI, and welcome!
STZ direct is opcode $64. At http://visual6502.org/wiki/index.php?ti ... 56_Opcodes we learn that this is indeed a NOP on the NMOS 6502 - it is unspecified behaviour, but turns out to be a nop. It's a 3-cycle NOP and you'll see that there are some 2-cycle NOPs.

Is that true for all 6502s w/o the extended instruction set? Because each company seemed to have its own variant. Atari 400/800 used a generic 6502. Atari 800XL/XE used a 6502C w/halt line. Commodore 64 seemed to use one with an extra I/O port and more pins. Atari 2600 had one with less pins.

Quote:

Two things bother me a bit: you perform PLA and RTS - does this mean you expect to run this code in an interrupt routine? It would not be safe to do that, because the stacked return address for RTS and RTI are different by 1. And yet, since the processor won't change while you're running, I don't see why you would want to run in an interrupt routine. As with Jeff, I think there's something about your environment which isn't familiar to us.

If you only check for 6502 or 65C02 at initialisation time, you don't, presumably, care about saving a few bytes or cycles in the check. I see the point about being unable to SED if there's a chance of NMIs and if the NMI routine will fail if decimal mode is set. And yet: how badly will it fail? Does it really use ADC or SBC in an NMI routine? If you only perform the check once, are you in fact safe?

At http://www.oxyron.de/html/opcodes02.html you'll find other undocumented behaviour.
...

They can fail badly since it all depends on what they do with their calculations. They can even hang by providing wrong values that are not supposed to exist within the application as a result of a decimal mode calculation. DLIs like the example I gave is just my own made up example on the spot but they don't always involve colors.

[AtariKSI]

leeeeee wrote:

Faster, shorter, no decimal mode problems.

Code: Select all

1536: PHA
1537: LDA #2    ;color value
1539: STA 53272 ;store color register
1542: CLD       ;clear decimal mode
1545: ADC #2
1548: STA 1538  ;modify the code itself
1545: PLA
1546: RTI

Lee.

That's just one made-up example. Most of the games/applications are already written and exist as cartridges (ROM) or disks and can't really go and modify them. Nor can you insert a CLD in most cases as they are time-critical. Some applications change color in the middle of the screen so adding 2 cycles moves the entire timing off by a certain number of pixels.

[BigEd]

It's certainly possible that different 6502 implementations will have different reactions to the unspecified opcodes. I think the usual second-source arrangement is to have a copy of the masks, so the digital behaviour will be identical. Some of the non-nop opcodes have some analogue behaviour, so they would be more likely to vary. My guess would be that the NOPs and their cycle counts are fairly likely not to vary, among the original generation of implementations. Of course, any re-implementation from scratch could be very different - if there are any of those.

It's this kind of vague statement which explains why cautious people don't try to use undocumented behaviour!

Cheers
Ed