Wickeycolumbus Posted September 1, 2010 Share Posted September 1, 2010 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... Quote Link to comment Share on other sites More sharing options...
eshu Posted September 2, 2010 Share Posted September 2, 2010 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Wickeycolumbus Posted September 2, 2010 Author Share Posted September 2, 2010 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 Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted September 2, 2010 Share Posted September 2, 2010 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. Quote Link to comment Share on other sites More sharing options...
eshu Posted September 2, 2010 Share Posted September 2, 2010 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... Quote Link to comment Share on other sites More sharing options...
supercat Posted September 7, 2010 Share Posted September 7, 2010 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. Quote Link to comment Share on other sites More sharing options...
gorgh Posted September 10, 2010 Share Posted September 10, 2010 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: Quote Link to comment Share on other sites More sharing options...
eshu Posted September 10, 2010 Share Posted September 10, 2010 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) Quote Link to comment Share on other sites More sharing options...
gorgh Posted September 10, 2010 Share Posted September 10, 2010 I used SAX ($87) and ANDX ($8bff; @ and X -> @), I`m not sure which one of them coused troubles though. Quote Link to comment Share on other sites More sharing options...
eshu Posted September 10, 2010 Share Posted September 10, 2010 (edited) 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 Quote Link to comment Share on other sites More sharing options...
gorgh Posted September 10, 2010 Share Posted September 10, 2010 (edited) 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 Quote Link to comment Share on other sites More sharing options...
eshu Posted September 10, 2010 Share Posted September 10, 2010 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.... Quote Link to comment Share on other sites More sharing options...
gorgh Posted September 10, 2010 Share Posted September 10, 2010 (edited) 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 Quote Link to comment Share on other sites More sharing options...
eshu Posted September 10, 2010 Share Posted September 10, 2010 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... Quote Link to comment Share on other sites More sharing options...
gorgh Posted September 10, 2010 Share Posted September 10, 2010 (edited) 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 Quote Link to comment Share on other sites More sharing options...
eshu Posted September 10, 2010 Share Posted September 10, 2010 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? Quote Link to comment Share on other sites More sharing options...
gorgh Posted September 10, 2010 Share Posted September 10, 2010 (edited) 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 Quote Link to comment Share on other sites More sharing options...
eshu Posted September 10, 2010 Share Posted September 10, 2010 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
gorgh Posted September 11, 2010 Share Posted September 11, 2010 yeah, definitely there are serious advantages of using illegal opcodes Quote Link to comment Share on other sites More sharing options...
supercat Posted September 11, 2010 Share Posted September 11, 2010 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). Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted September 11, 2010 Share Posted September 11, 2010 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. Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted September 11, 2010 Share Posted September 11, 2010 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. Quote Link to comment Share on other sites More sharing options...
jdrose Posted April 11, 2013 Share Posted April 11, 2013 Is there a good guide to illegal opcodes that are useful specifically in the 2600 environment? Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted April 12, 2013 Share Posted April 12, 2013 (edited) 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 Quote Link to comment Share on other sites More sharing options...
jdrose Posted April 14, 2013 Share Posted April 14, 2013 "BTW: I have always been using this as a reliable reference for illegal opcode stability." Thank you. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.