Curious question about illegal opcodes

[+grafixbmp]

I know that some of the illegal opcodes give standard results like LAX and the 3 cycle nop. But I had read that some illegal opcodes give undesired results like some results that are far out from what is wanted or needed. And some totaly crash the system and need a reset/restart.

 

And what is actualy meant by an unstable opcode?

 

Do some of them give diffrent results each time they are used?

 

If so, given that some have unpredictable results, could a sort of structured subroutine be created using some of thoes bad illegal codes so that a more true RND function can be made?

 

Just thinking that if results from using 1 of them wind up giving results that vary wildly than the use of 2 or 3 of them in a structure of sorts might give a better random result? Any thoughts on this?

 

I figured that in order for this to work, certain provisions need to be made so that areas of the processor that some of thoes codes could affect are not needed at the time, like flags and current states of some of the registers.

Edited October 3, 2008 by grafixbmp

[vdub_bobby]

You should do a forum search, [stella] search, and a Google search for this information; most of the documentation of unstable opcodes is for the C64 but there is some info for the 2600 as well.

[supercat]

If so, given that some have unpredictable results, could a sort of structured subroutine be created using some of thoes bad illegal codes so that a more true RND function can be made?

 

Many of the "unstable" opcodes have behavior which will be influenced by things like temperature, manufacturing lot, phase of the moon, and other factors. The behaviors are not consistent enough be be useful, but are far too consistent to be used for random number generation.

 

Generally, the behaviors of "stable" opcodes result from simultaneous selections of two or more functions. For example, instructions of the form "101mmmxa" will cause an operand to be fetched according to addressing mode "mmm" and then latch it into the register specified by "xa". If xa=00, latch into Y. If x=1, latch into X. If a=1, latch into A. If bits x and a are both set, then latch both X and A registers.

 

In the case of opcodes of the form "100mmmxa", the contents of registers specified by "xa" will be placed on the bus and stored using the addressing mode specified by "mmm". If X and A are placed on the bus simultaneously, the design of that bus in the 6507 is such that zero bits will always win. Thus, the effect of storing X "and" A.

 

Sometimes bus conflicts don't work out so conveniently. If one tries to execute the opcode that "should" be "STY $1234,X", the store will fail because the same internal bus is used to transfer $12+1 to the address bus as is used to transfer the value of Y to the data bus. I'm not quite sure why the conflict causes difficulty, since $12+1 is used on the cycle before the value of Y, but for whatever reason the timing is not resolved. Consequently, both the contents of Y and the MSB of the address get splatted. If there is no page crossing, the instruction will store the value (Y and $13) to $1234+X. If there is a page crossing, it will store the value (Y and $13) to address (Y and $13)*256 + ($34+X) AND 255. Not quite so handy.

[Flipper]

They also don't have standard names. One opcode that I added to my repertoire back in the day was LDAX, but I've seen it called a couple of other names. It was pretty reliable across all addressing modes, and handled the basic ones I used. As you might guess, it loaded A and X in the same cycle. Much faster than LDA/TAX or any other pair.

 

Another issue with undocumented opcodes is that they're only found on the NMOS process 6502s. They become a NOP on all CMOS chips, such as the 65C02 and 65816. Some software was incompatible with 65C02/65816 upgrades on the Apple II and C64 machines, because it used undocumented opcodes in it's protection or for performance.

 

And some of them lock up the CPU. Watching for a program trying to jump to a $02 was a big clue that the protection had failed.

[supercat]

Many of the "unstable" opcodes have behavior which will be influenced by things like temperature, manufacturing lot, phase of the moon, and other factors. The behaviors are not consistent enough be be useful, but are far too consistent to be used for random number generation.

 

Sometimes "unstable" behaviors can be caused by race conditions. There is at least one race condition on the TIA that is readily observable. Enable SCORE mode and turn on bit 7 of PF2. The right half of pixel #79 may be an odd color; the exact behavior seems to depend upon temperature and other weird factors. The problem in that case is that the color circuitry for COLUP0 is being disconnected from the color multiplexer at the same time as the color circuitry for the right half is being connected, and both actions are happening while the output from the multiplexer is being sampled. COLUPF isn't supposed to affect the color of that pixel, but sometimes it does.

[+grafixbmp]

Many of the "unstable" opcodes have behavior which will be influenced by things like temperature, manufacturing lot, phase of the moon, and other factors. The behaviors are not consistent enough be be useful, but are far too consistent to be used for random number generation.

 

Sometimes "unstable" behaviors can be caused by race conditions. There is at least one race condition on the TIA that is readily observable. Enable SCORE mode and turn on bit 7 of PF2. The right half of pixel #79 may be an odd color; the exact behavior seems to depend upon temperature and other weird factors. The problem in that case is that the color circuitry for COLUP0 is being disconnected from the color multiplexer at the same time as the color circuitry for the right half is being connected, and both actions are happening while the output from the multiplexer is being sampled. COLUPF isn't supposed to affect the color of that pixel, but sometimes it does.

That's kinda nifty given it doesn't have a thing to do with opcodes but a nature of the system with undesired results. Like the classic of hiting Hmove and geting black bars. Still, it would be nice to take a new stab at better random number generation. It's a wonder why some sort of cart bankswitching scheme hasn't had some kind of special address call for a RND built right on the cart chip.

[Nukey Shay]

^^ Pitfall II

[+batari]

^^ Pitfall II

Yep, but curiously only used for the electric eel flash, so it's completely irrelevant to the gameplay.

[+grafixbmp]

^^ Pitfall II

Yep, but curiously only used for the electric eel flash, so it's completely irrelevant to the gameplay.

Out of all the possibilities... what a waste.

[+grafixbmp]

I bet the new Melody cart supports a true RND funtion. Could use it natively in the ARM or pass it to the 6502.

[+grafixbmp]

.

Edited November 9, 2009 by grafixbmp

[+grafixbmp]

.

Edited November 9, 2009 by grafixbmp