Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in 
CSDb User Forums


Forums > C64 Coding > Unstable Illegal Opcodes
2006-09-25 11:21
Cruzer

Registered: Dec 2001
Posts: 767
Unstable Illegal Opcodes

I have always avoided the opcodes that are marked as unstable on Graham's opcode list:

http://www.oxyron.de/html/opcodes02.html

But maybe some of them could be used in some cases after all? Anyone who can shed some light on when excactly they are unstable?

According to Graham's list there are two kinds of unstableness, the first being "unstable in certain matters", which applies to these opcodes:

ahx
shy
shx
tas

The other one doesn't leave much hope: "Highly unstable (results are not predictable on some machines)", but only these two are that bad:

xaa
lax #imm
 
... 21 posts hidden. Click here to view all posts....
 
2008-12-22 11:06
Peiselulli

Registered: Oct 2006
Posts: 47
I remember that I had some problems with this opcode on my first c64 (rest in peace now).

It results different for "LAX #$ff":
Sometimes $FE, sometimes $EF and sometimes $EE.

But in the case of "LAX #$00" there was no problem at all.
2012-02-17 14:04
ready.

Registered: Feb 2003
Posts: 408
I found this about XAA:

http://visual6502.org/wiki/index.php?title=6502_Opcode_8B_(XAA,..)

I still haven't tested it on a real c64, but this is the best description I have found so far about this illegal opcode.
2012-02-17 18:41
Frantic

Registered: Mar 2003
Posts: 1088
Hmm.. I fooled around a bit with LAX imm in VICE now, and it did not work as I expected. For example, just stepping through the following code in the monitor:
loop:
op = *+1
   !byte $ab,0 ;LAX imm
   inc op
   jmp loop

...does not make the A and X registers change value each iteration. Rather, SOMETIMES the A and X register changed value, but not every iteration. When I look at Graham's description of the LAX imm opcode, it seems that it should work just the same as LAX zp for example, but with immediate addressing mode. It says:
   A,X:=#{imm}

...but that seems wrong, judging from what VICE does (if assuming that VICE emulates LAX imm accurately). Anyway, when I look in Ninja's AAY-description of the opcode, it says something else, namely:
  Operation:  X04 <- (X04) /\ M04                       N V - B D I Z C
              A04 <- (A04) /\ M04                       / . . . . . / .

It is not entirely transparent to me what exactly this means, but I take it that not all bits are treated the same way. Well, in fact, when looking at the register values that I get in the VICE monitor, it seems that bit 0 and bit 4 in the immediate operand does not seem to make it into the X and A registers. Is that was the LAX imm instruction is "supposed" to be doing on an "unstable" machine? ...or on a "stable" machine? If this bit dropping is what it is doing (sometimes) on an "unstable" machine, then it seems to me that using something like LAX #0 to set both X and A register to 0 should be safe on any machine, since bit0 and bit4 aren't involved anyway? ...and if this is what LAX imm is supposed to be doing on a "stable" machine, then what is it that sometimes happens on an "unstable" machine? No bit dropping? More bit dropping?
2012-02-18 09:56
tlr

Registered: Sep 2003
Posts: 969
You might be interested in checking this: http://vice-emu.svn.sourceforge.net/viewvc/vice-emu/testprogs/g..

The assumed behaviour of LAX #<imm> is: X,Acc = (Acc | CONST) & #<imm>.

As far as I could tell peiselulli's assumption about LAX #$00 holds. The "& <imm>" would always be honoured on the machines I tested.
2012-02-18 15:06
Groepaz

Registered: Dec 2001
Posts: 6637
Quote:
Hmm.. I fooled around a bit with LAX imm in VICE now

better use the real thing for this kind of stuff =P the opcodes mentioned in this thread are kindof hard to test (and thus to emulate) so there are probably still bugs in the vice cpu core.
2012-02-19 01:03
Skate

Registered: Jul 2003
Posts: 400
i just tried lax# on my c64 and c128d. both worked fine for all 256 values. i tried playing with vic registers, enabling sprites etc. during the tests and apparently, if lax# works on a machine, it works flawlessly.
2012-02-19 07:38
tlr

Registered: Sep 2003
Posts: 969
@skate: as you can see from the runs of my test program the behavior of LAX #<imm> will depend on things like temperature and perhaps voltage on some machines.

As far as I have seen that formula holds though. I.e only CONST is different and it can _change_ over time, but presumably slowly. There might also be correlation effects between registers and CONST.
2012-02-19 12:00
Cruzer

Registered: Dec 2001
Posts: 767
So lax #$00 should always work? And this should be safe too:

lda #$ff
lax #anyValue
2012-02-19 20:14
tlr

Registered: Sep 2003
Posts: 969
Yes it should. Note that ane-lax.prg was primarily designed to test ANE so it only tests the resulting ACC of LAX #<imm>, not X.

IIRC the visual6502 guys tested both Acc, X and flags using a test rig for 6502/6510 chips.
2012-02-20 16:35
Frantic

Registered: Mar 2003
Posts: 1088
Edit: nothing...
Previous - 1 | 2 | 3 | 4 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.


Search CSDb
Advanced
Users Online
doctorfargo/Binary L..
Celtic/NoName/Arsenic
Guests online: 24
Top Demos
1 Edge of Disgrace  (9.7)
2 Coma Light 13  (9.6)
3 Wonderland XII  (9.6)
4 We Are All Connected  (9.4)
5 Deus Ex Machina  (9.3)
6 Andropolis  (9.3)
7 +H2K  (9.3)
8 2011 - A Press Space..  (9.2)
9 Continuum  (9.2)
10 Musik Run/Stop  (9.2)
Top onefile Demos
1 Daah, Those Acid Pil..  (9.6)
2 Dawnfall  (9.3)
3 One-Der  (9.2)
4 Tiki Pahu!  (9.1)
5 Frodigi 2  (9.0)
6 Safe VSP  (9.0)
7 Te-Te-Te-TechTech It..  (9.0)
8 Are we there yet?  (8.9)
9 Cubase64  (8.9)
10 Storebror  (8.8)
Top Groups
1 Booze Design  (9.4)
2 Crest  (9.4)
3 Censor Design  (9.3)
4 Oxyron  (9.3)
5 Chorus  (9.3)
Top Hardware-Gurus
1 Soci  (9.9)
2 Lemming  (9.8)
3 Zer0-X  (9.8)
4 Wiesel  (9.5)
5 Kisiel  (8.5)

Home - Disclaimer
Copyright © No Name 2001-2014
Page generated in: 0.296 sec.