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


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

Registered: Dec 2001
Posts: 999
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
2006-09-25 09:49
Oswald

Registered: Apr 2002
Posts: 4507
usually there's a way to do what you want with illegals, and a way with legals, and 95% of the time the cyclecount are the same. You cant really generalize where and what is useful, using illegals needs quite specific code. But some will prove me wrong lets see :)
2006-09-25 09:50
Ninja

Registered: Jan 2002
Posts: 390
Those opcodes with "AND PCH+1 drops sometimes off" are not that mystical. It drops off, when VIC takes over the bus. Try disabling badlines and it will never drop off (at least on the various machines I checked). Activate a sprite and it will drop off again. Maybe you can time your code to that :)
2006-09-25 10:18
algorithm

Registered: May 2002
Posts: 692
Any examples where Illegal opcodes have been used in VIC trickery? One example I know of is darwin/dreams where 6 sprites over full screen FLI were achieved.

Any more?
2006-09-25 12:00
Cruzer

Registered: Dec 2001
Posts: 999
@algorithm: When Crossbow did 5 sprites over FLI :)

@ninjadrm: What does "drop off" mean in this case? That it doesn't perform the and, or that it adds 1 to the and value?

2006-09-25 13:44
Ninja

Registered: Jan 2002
Posts: 390
@algorithm: Surely some more VIC-tricks have used basic stuff like LAX or SAX.

@cruzer: The AND drops off, so in case for SHX and SHY you have the pretty nice STX abs,y and STY abs,x opcodes. If you time it to VIC access that is :) Geez, I really could finish the article about those one day...
2006-09-25 14:00
HCL

Registered: Feb 2003
Posts: 688
Often you need to use illegals if you want to put magic colors on the leftmost 3 chars of a normal FLI-picture. That's more a conisidence though..
2006-09-25 14:01
Oswald

Registered: Apr 2002
Posts: 4507
ninja, now thats interesting !! could you shortly describe how and what happens ?
2006-09-25 15:49
Frantic

Registered: Mar 2003
Posts: 1390
@Ninja: So.. Does that mean SHX/SHY works in the border or do you have to disable VIC? (I could try it, but only on one machine..)
2006-09-25 16:43
Oswald

Registered: Apr 2002
Posts: 4507
this means imho that if the vic takes over the bus during shx/shy etc, then the and effect is dropped, or something like that :)
2006-09-25 17:56
JackAsser

Registered: Jun 2002
Posts: 1564
What bugs me with the VIC-take over explanation is the fact that the VIC has taken the bus... i.e the CPU doesn't do anything at all.
2006-09-25 18:14
Groepaz

Registered: Dec 2001
Posts: 9100
as i understand it... if its a RRMW, the vic could take over the bus in the M cycle and somehow make the "shortcut" that causes the AND disappear... *shrug*
2006-09-25 19:47
TNT
Account closed

Registered: Oct 2004
Posts: 189
My guess is that AND doesn't disappear, it just does the operation with #$FF which appears on the bus when BA goes low (instead of anding with the last read byte, which was high byte of address). 6510 isn't halted until it does read access.
2006-09-26 03:03
Ninja

Registered: Jan 2002
Posts: 390
TNT: Yeah, this is my assumption, too.
2006-09-26 15:00
Cruzer

Registered: Dec 2001
Posts: 999
Ok, so just to recap... The only unstableness of AHX, SHY, SHX and TAS are that the AND is not performed (or is performed with $ff) if the VIC uses the bus during the execution of the command. So if the code is placed in $ffxx or somewhere else where the values are not affected by the AND, it will be completely safe to use these opcodes?
2006-09-26 18:01
Ninja

Registered: Jan 2002
Posts: 390
Cruzer: Correct. Only that you have to use $FExx, as the AND is performed with PCH+1. $7Exx or $3Exx might also come handy. I think, Graham used this in Oneder.
2006-10-10 11:40
Copyfault

Registered: Dec 2001
Posts: 256
Quote: My guess is that AND doesn't disappear, it just does the operation with #$FF which appears on the bus when BA goes low (instead of anding with the last read byte, which was high byte of address). 6510 isn't halted until it does read access.

Interesting thread...

I must be wrong but I thought #$ff is on the bus when BA goes low, and this happens within those "X" cycles. If the AND is done with the value which is on the bus it should only be stable when BA goes low and it should make problems when BA does not go low (i.e. when there is no X-cycle). AAY64 tells us that the VIC reads the last byte from the actual VIC_bank (modded when in ECM), so does this byte affect the stability, too? Is there any explanation for the page_wrapping behaviour?

Those opcode said to be highly unstable (LAX imm, ANE/XAA imm) should also have some general explanation, no?


Unfortunatly I do not have the time to test things on my own atm - maybe in some weeks.

CF
2006-10-10 12:50
Frantic

Registered: Mar 2003
Posts: 1390
Accurate descriptions of the "highly unstable" ones (as mentioned, LAX imm, ANE/XAA imm..) would be very interesting indeed. I could use LAX imm every now and then for sure...
2006-10-10 15:25
Graham
Account closed

Registered: Dec 2002
Posts: 990
LAX #imm is only unstable on some CPUs and it's much more unstable there compared to the AND of SHX etc, so it's propably not bound to VIC activity.
2006-10-11 10:12
Copyfault

Registered: Dec 2001
Posts: 256
LAX imm and ANE imm might also depend on some other things like CIA, cpu type (6510 or 85xx) or what else is sitting in the breadbin. Does "only unstable on some cpus" mean that for most of the cpus LAX imm is completely stable? And does this really only depend on the cpu used? Don't know how many tests (on way too much different machines) would be necessary to find this out...

It would really puzzle me if the highly unstable opcodes are capable of giving truly random results - there must be some explanation for what the whole system does when the cpu is fed with these ops.

CF
2006-10-11 10:33
WVL

Registered: Mar 2002
Posts: 849
Quote: LAX imm and ANE imm might also depend on some other things like CIA, cpu type (6510 or 85xx) or what else is sitting in the breadbin. Does "only unstable on some cpus" mean that for most of the cpus LAX imm is completely stable? And does this really only depend on the cpu used? Don't know how many tests (on way too much different machines) would be necessary to find this out...

It would really puzzle me if the highly unstable opcodes are capable of giving truly random results - there must be some explanation for what the whole system does when the cpu is fed with these ops.

CF


The best check would ofcourse be to swap the CPU's if you find a system that is highly unstable and a completely stable one. For now all my machines seem to be 100% reliable on LAX #Imm.
2008-12-21 23:54
AlexC

Registered: Jan 2008
Posts: 276
Quote: The best check would ofcourse be to swap the CPU's if you find a system that is highly unstable and a completely stable one. For now all my machines seem to be 100% reliable on LAX #Imm.

I confirm - all my machines produce stable results with LAX #imm. However I am wondering if anyone actually did any further research into XAA cases. It seems to me that on mine C128D this instruction is also stable always producing the same result.
2008-12-22 10:06
Peiselulli

Registered: Oct 2006
Posts: 71
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 13:04
ready.

Registered: Feb 2003
Posts: 438
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 17:41
Frantic

Registered: Mar 2003
Posts: 1390
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 08:56
tlr

Registered: Sep 2003
Posts: 1248
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 14:06
Groepaz

Registered: Dec 2001
Posts: 9100
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 00:03
Skate

Registered: Jul 2003
Posts: 477
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 06:38
tlr

Registered: Sep 2003
Posts: 1248
@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 11:00
Cruzer

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

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

Registered: Sep 2003
Posts: 1248
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 15:35
Frantic

Registered: Mar 2003
Posts: 1390
Edit: nothing...
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
ZeSmasher/F4CG
The Shocker
Karmic/HVSC/ONS
Dymo/G★P
KAL_123
Mythus/Delysid
Jazzcat/Onslaught
Knobby
TheRyk/MYD
Six/G★P
iceout/Avatar/HF
iAN CooG/HVSC
Guests online: 45
Top Demos
1 Uncensored  (9.7)
2 Unboxed  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.7)
5 Comaland 100%  (9.6)
6 Lunatico  (9.6)
7 The Shores of Reflec..  (9.5)
8 Rivalry  (9.5)
9 X Marks the Spot  (9.5)
10 C=Bit 18  (9.5)
Top onefile Demos
1 Tribute to Ben - Las..  (9.8)
2 Gumbo Revised  (9.6)
3 Crystal Gazer  (9.6)
4 Smile to the Sky  (9.5)
5 Dawnfall V1.1  (9.5)
6 Daah, Those Acid Pil..  (9.5)
7 Instinct  (9.5)
8 Innervasion  (9.5)
9 Merry Krampus  (9.5)
10 Pandemoniac Part 5 o..  (9.5)
Top Groups
1 Oxyron  (9.4)
2 PriorArt  (9.4)
3 Fossil  (9.4)
4 Booze Design  (9.4)
5 Censor Design  (9.4)
Top Swappers
1 Derbyshire Ram  (10)
2 Splatterhead  (9.8)
3 Zyron  (9.8)
4 Walker  (9.8)
5 Jerry  (9.8)

Home - Disclaimer
Copyright © No Name 2001-2020
Page generated in: 0.06 sec.