Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user MaxHeadroom ! (Registered 2017-01-16) You are not logged in 
CSDb User Forums

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

Registered: Dec 2001
Posts: 865
Unstable Illegal Opcodes

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


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:


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

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

Registered: Oct 2006
Posts: 65
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

Registered: Feb 2003
Posts: 423
I found this about 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

Registered: Mar 2003
Posts: 1274
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:
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:

...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

Registered: Sep 2003
Posts: 1091
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

Registered: Dec 2001
Posts: 7836
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

Registered: Jul 2003
Posts: 451
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

Registered: Sep 2003
Posts: 1091
@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

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

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

Registered: Sep 2003
Posts: 1091
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

Registered: Mar 2003
Posts: 1274
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
Users Online
Scan/House Designs
Guests online: 29
Top Demos
1 Uncensored  (9.7)
2 Edge of Disgrace  (9.7)
3 Coma Light 13  (9.6)
4 Lunatico  (9.6)
5 Comaland 100%  (9.5)
6 Wonderland XII  (9.5)
7 Incoherent Nightmare  (9.5)
8 Comaland  (9.5)
9 Fantasmolytic  (9.5)
10 Wonderland XIII  (9.5)
Top onefile Demos
1 Globe 2016 [reu]  (9.6)
2 Dawnfall V1.1  (9.5)
3 Daah, Those Acid Pil..  (9.4)
4 Treu Love [reu]  (9.4)
5 Dawnfall  (9.3)
6 One-Der  (9.2)
7 Hardware Accelerated..  (9.2)
8 Goatbeard  (9.1)
9 Safe VSP  (9.1)
10 Ächzzeit  (9.1)
Top Groups
1 Censor Design  (9.4)
2 Booze Design  (9.4)
3 Oxyron  (9.4)
4 Crest  (9.3)
5 Arsenic  (9.3)
Top Hardware-Gurus
1 Soci  (9.9)
2 Wiesel  (9.9)
3 Grue  (9.8)
4 Zer0-X  (9.8)
5 Lemming  (9.7)

Home - Disclaimer
Copyright © No Name 2001-2017
Page generated in: 0.788 sec.