'LXA' stable?

[Wickeycolumbus]

I attempted to use the illegal opcode 'LXA' (which ANDs the argument with the accumulator and transfers result to X), and it doesn't seem to work in Stella. In my situation, A contained zero, the argument was 7, and somehow the result was 6. Does this instruction work properly on real hardware? Or perhaps I don't correctly understand how it works...

[eshu]

I attempted to use the illegal opcode 'LXA' (which ANDs the argument with the accumulator and transfers result to X), and it doesn't seem to work in Stella. In my situation, A contained zero, the argument was 7, and somehow the result was 6. Does this instruction work properly on real hardware? Or perhaps I don't correctly understand how it works...

 

Hi,

 

I think you're talking about the opcode I've seen referred to as ATX - which I think unfortunately is not stable. Someone really should do a definitive list of which illegal opcodes are stable - so far the usefull ones I'm aware of are (illegal NOPS not included): LAX, SAX, SBX, DCP, ASR. I think there are other stable ones, but not that I've had a use for....

 

Cheers

 

 

Edit: I knew I had the information from somewhere - I think the conclusion of this conversation: Stella Mailing List is that it is unstable.

Edited September 2, 2010 by eshu

[Wickeycolumbus]

I attempted to use the illegal opcode 'LXA' (which ANDs the argument with the accumulator and transfers result to X), and it doesn't seem to work in Stella. In my situation, A contained zero, the argument was 7, and somehow the result was 6. Does this instruction work properly on real hardware? Or perhaps I don't correctly understand how it works...

 

Hi,

 

I think you're talking about the opcode I've seen referred to as ATX - which I think unfortunately is not stable. Someone really should do a definitive list of which illegal opcodes are stable - so far the usefull ones I'm aware of are (illegal NOPS not included): LAX, SAX, SBX, DCP, ASR. I think there are other stable ones, but not that I've had a use for....

 

Cheers

 

Thanks for the reply, yes that's the one (DASM calls it lxa). Too bad, it seems pretty useful

[Omegamatrix]

Someone really should do a definitive list of which illegal opcodes are stable - so far the usefull ones I'm aware of are (illegal NOPS not included): LAX, SAX, SBX, DCP, ASR. I think there are other stable ones, but not that I've had a use for....

 

 

I've had problems with ASR on a late Taiwanese Atari Jr. It's too bad because it was a useful opcode to save 1 byte and 2 cycles.

[eshu]

Someone really should do a definitive list of which illegal opcodes are stable - so far the usefull ones I'm aware of are (illegal NOPS not included): LAX, SAX, SBX, DCP, ASR. I think there are other stable ones, but not that I've had a use for....

 

 

I've had problems with ASR on a late Taiwanese Atari Jr. It's too bad because it was a useful opcode to save 1 byte and 2 cycles.

 

Thanks - I thought that one was considered stable...

[supercat]

Thanks - I thought that one was considered stable...

 

I thought asr was stable at least when the D flag is clear; with the D flag set, its behavior is weird whether or not it's stable.

[gorgh]

From my own experience with alari XL/XE I can say that Illegal opcodes ain`t called "illegal" for nothing. Even if they work on 4 machines, on 5th they will crash. In 6502 CPU case it`s mainly because there were many different models produced,so it could be the same with 6507. I used illegals in my game for soft sprite routine, and it worked perfectly on my machine, but then I sent it to competition and the effect was like this:

[eshu]

From my own experience with alari XL/XE I can say that Illegal opcodes ain`t called "illegal" for nothing. Even if they work on 4 machines, on 5th they will crash. In 6502 CPU case it`s mainly because there were many different models produced,so it could be the same with 6507. I used illegals in my game for soft sprite routine, and it worked perfectly on my machine, but then I sent it to competition and the effect was like this:

 

Do you remember off hand which opcodes you used - obviously some are more stable than others, but I thought SAX and LAX were very reliable because of the way they work. (There's a decent description of how LAX works here: http://www.pagetable.com/?p=39)

[gorgh]

I used SAX ($87) and ANDX ($8bff; @ and X -> @), I`m not sure which one of them coused troubles though.

[eshu]

I used SAX ($87) and ANDX ($8bff; @ and X -> @), I`m not sure which one of them coused troubles though.

 

I think the opcode your calling ANDX is XAA/ANE in the documents I've read, and not considered stable - so I would bet that was the problem.

 

From: http://www.ffd2.com/fridge/docs/6502-NMOS.extra.opcodes

 

OPCODE BIT-PATTERN: 10x0 1011

Now it is time to discuss XAA ($8B) and OAL ($AB). A fair bit of

controversy has surrounded these two opcodes. There are two good reasons

for this. 1 - They are rather weird in operation. 2 - They do operate

differently on different machines. Highly variable.

 

Here is the basic operation.

 

...

 

On my 64, XAA works like this. While X is transfered to A, bit 0 and bit 4

are not. Instead, these bits are ANDed with those bits from A, and the

result is stored in A.

Edited September 10, 2010 by eshu

[gorgh]

Yeah, I checked it and it`s probably this opcode.I`ve used it cause The description I`ve read stated that It`s stable with $ff argument which excludes the influence of internal CPU register.

Edited September 10, 2010 by gorgh

[eshu]

Yeah, I checked it and it`s probably this opcode.I`ve used it cause The description I`ve read stated that It`s stable with $ff argument which excludes the influence of internal CPU register.

 

All the good docs out there are for the c64, so it's hard to know exactly how some stuff will work on other machines - because the 2600 doesn't have hardware interupts, the illegal/undocumented opcodes generally behave quite well.

 

From one of the documents:

ANE $8B A = (A | #$EE) & X & #byte

same as

A = ((A & #$11 & X) | ( #$EE & X)) & #byte

 

In real 6510/8502 the internal parameter #$11

may occasionally be #$10, #$01 or even #$00.

This occurs when the video chip starts DMA

between the opcode fetch and the parameter fetch

of the instruction. The value probably depends

on the data that was left on the bus by the VIC-II.

 

Obviously the atari 8-bit doesn't have a vic-2 chip, but is it possible that something else might be putting data on the bus whilst your code is running that opcode? If it's happening in one place, and not another it sounds like it must be caused by something like this....

[gorgh]

 

Obviously the atari 8-bit doesn't have a vic-2 chip, but is it possible that something else might be putting data on the bus whilst your code is running that opcode? If it's happening in one place, and not another it sounds like it must be caused by something like this....

 

In that case Antic might cause this trouble. I deleted information that it sometimes works and sometimes not, because it doesn`t work at all, only if the accumulator is 0 the result is correct

Edited September 10, 2010 by gorgh

[eshu]

 

Obviously the atari 8-bit doesn't have a vic-2 chip, but is it possible that something else might be putting data on the bus whilst your code is running that opcode? If it's happening in one place, and not another it sounds like it must be caused by something like this....

 

In that case Antic might cause this trouble. I deleted information that it sometimes works and sometimes not, because it doesn`t work at all, only if the accumulator is 0 the result is correct

 

I'd love to see the section of code, if you have it at hand - I'm guessing you're doing some kind of masking - I would have thought it would be possible with only SAX in the same number of cycles, but I can't quite get my head around it without the code...

[gorgh]

here`s the code:

; soft sprite procedure
mix ldy #0
   lda $60,y  ;screen background on zero page
   ldx $a400,y ; mask
   xand #$ff
   ora $9800,y ; sprite shape
   sta $a300,y
   iny
   cpy #$90
   bne mix+2

Edited September 10, 2010 by gorgh

[eshu]

here`s the code:

; soft sprite procedure
mix ldy #0
   lda $60,y  ;screen background on zero page
   ldx $a400,y ; mask
   xand #$ff
   ora $9800,y ; sprite shape
   sta $a300,y
   iny
   cpy #$90
   bne mix+2

 

wouldn't:

 

mix ldy #0
   lda $60,y  ;screen background on zero page
   and $a400,y ; mask
   ora $9800,y ; sprite shape
   sta $a300,y
   iny
   cpy #$90
   bne mix+2

 

do the same with 2 less cycles, or am i missing something?

[gorgh]

 

do the same with 2 less cycles, or am i missing something?

 

yeah, good point, I guess I wanted to test Ilegals and didn`t noticed that it works slower, just missed that

 

Anyways, using SAX and LAX (f.e.) could be useful, but first one have to check if they work properly on different machines , it could ba a simple code that could be tested by the Harmony cartridge owners, I`ll try to write such code for A XL/XE .

Edited September 10, 2010 by gorgh

[eshu]

 

do the same with 2 less cycles, or am i missing something?

 

yeah, good point, I guess I wanted to test Ilegals and didn`t noticed that it works slower, just missed that

 

Anyways, using SAX and LAX (f.e.) could be useful, but first one have to check if they work properly on different machines , it could ba a simple code that could be tested by the Harmony cartridge owners, I`ll try to write such code for A XL/XE .

 

LAX is listed as unstable in some of the c64 documents, but I think it's been heavily tested on 2600 - I think it's another issue with interrupts and something else interacting with the data bus which doesn't happen on the 2600 - don't know how it will work on XL/XE though, have fun finding out

 

I have a load of code where I want to set up a reference into a table of 8-byte objects and I'm using:

 

LAX Index,y

AND #%00000111

STA AddressHi

LDA #%11111000

SAX AddressLo

 

Which is a hell of a lot faster than multiplying by 8, and just means storing the values in the index in a funny bit order (43210765) - so I really hope those two opcodes are alright....

Edited September 10, 2010 by eshu

[gorgh]

yeah, definitely there are serious advantages of using illegal opcodes

[supercat]

LAX is listed as unstable in some of the c64 documents, but I think it's been heavily tested on 2600 - I think it's another issue with interrupts and something else interacting with the data bus which doesn't happen on the 2600 - don't know how it will work on XL/XE though, have fun finding out

 

Some of the unstable instructions decode to multiple instructions with behavior which is contradictory or involves odd feedback. The LAX instruction, for any mode other than immediate, decodes to two instuctions (LDA and LDX) whose behavior is identical except that one hits the load-enable signal for the accumulator, and the other hits load-enable for the X register. Since both instructions cause the same data to be loaded onto the internal operand-input bus, the effect is that the data gets loaded into both registers.

 

The SAX instruction decodes to two instructions (STA and STX) whose behavior is identical except that one hits the output-enable signal for the accumulator, and the other hits the output-enable signal for the X register. Although it would seem that this would cause ambiguous behavior, it turns out that during one half each cycle the inernal operand-output bus is set to all "1"'s, and the read-enable signals for the accumulator and X register (and Y register, stack pointer, etc.) only allow those registers to set the internal operand-output bus bits to "0". Thus, if a bit is zero in either the accumulator or the X register, it will be stored as zero; if it's set to "1" in both, then nothing will pull down the bus so it will output "1".

 

The problem with LAX immediate is that its decode is a combination of LDA, LDX, and TAX. This causes the current contents of the accumulator to be merged in with the value loaded from the data bus. Normally, during an LDA or LDX instruction, it doesn't matter if the operand-input bus is stable during the whole half-cycle for which they're enabled. Nothing is reading from the registers while they are being loaded; as long as the bus has stabilized before the load-enable signal goes away, the registers will end up with the correct value. The LAX opcode, however, enables the "output accumulator" signal as well as the "feed output bus to input bus" signal. My 6507 documentation doesn't show which buses have "true" or "inverted" logic levels, but a natural implementation would likely use the opposite signal polarity for the output bus and input bus (so the connections between them would be inverting buffers). Under that scenario, LAX would represent a race condition to see which bus got a "low" signal first. A variety of factors could influence "who wins" such a race.

 

It's interesting to note that both the TIA and 6507 share some design techniques, both would appear to be designs which sufficiently well-synchronized to be free of odd timing dependencies, but both have at least one seemingly-impossible race condition (the TIA's race condition occurs at mid-screen when using score mode if PF2.7 is set; there may be a half-pixel-wide odd-color stripe in that case).

[Nukey Shay]

I've had problems with ASR on a late Taiwanese Atari Jr. It's too bad because it was a useful opcode to save 1 byte and 2 cycles.

 

IMO that's no problem. So long as you know where a (needed) instruction fails, who cares if it doesn't work on some unofficial hardware? Just add the info as a footnote:

This program may not work correctly on 3rd-party hardware.

[Omegamatrix]

I've had problems with ASR on a late Taiwanese Atari Jr. It's too bad because it was a useful opcode to save 1 byte and 2 cycles.

 

IMO that's no problem. So long as you know where a (needed) instruction fails, who cares if it doesn't work on some unofficial hardware? Just add the info as a footnote:

This program may not work correctly on 3rd-party hardware.

Oh, it was official hardware. It was manufactured in Taiwan, and not in Sunnyvale California. Here from the Stella Mailing list is where I learned other people had problems with these particular Jr's:

 

http://www.biglist.com/lists/stella/archives/200108/msg00404.html

 

 

Go through that and a few messages following and you'll hear details on how Thunderground's score is messed up, and the serial number of the Jr is mentioned. Here is a post of mine with pics of the problems I had with Thunderground:

 

http://www.atariage.com/forums/topic/167678-strange-color-problem-with-stella/page__view__findpost__p__2075498

 

 

Getting back to ASR, I'll probably write a test program tomorrow to confirm it was failing. Then other people can test it on their consoles to see if ASR passes.

[jdrose]

Is there a good guide to illegal opcodes that are useful specifically in the 2600 environment?

[Thomas Jentzsch]

I have a load of code where I want to set up a reference into a table of 8-byte objects and I'm using:

 

LAX Index,y

AND #%00000111

STA AddressHi

LDA #%11111000

SAX AddressLo

Smart!

 

Compared to

LDA Index,y
AND #%00000111
STA AddressHi
EOR Index,y
STA AddressLo

...that saves 2-3 cylces.

 

Must remember that one...

 

BTW: I have always been using this as a reliable reference for illegal opcode stability.

Edited April 12, 2013 by Thomas Jentzsch

[jdrose]

"BTW: I have always been using this as a reliable reference for illegal opcode stability."

 

Thank you.