|  Post Your Message | |
| |
| | Previous Messages | Posted By
Crown
on 2004-05-16
08:52:45
|  Re: XAA!
$ff7f and $ff80 is an identifier code, it is $2a for the revision 4 PAL ROM and $5E for the revision 5 PAL ROM. There is also a revision 3 PAL ROM the code value for that is $F1... There are some minor differences beetween the ROM versions....
Also there is two NTSC ROM version known to exist the codes are $90 for Rev 4 and $C4 for Rev5.
The second byte $ff80 is most likely can be decomposed liked this
7th bit PAL/NTSC 1 means PAL
6-4th NC
3-0th Revision number.
The actual ROM images can be found here:
http://www.nic.funet.fi/pub/cbm/firmware/computers/plus4/index.html
|
|
Posted By
Ulysses777
on 2004-05-15
20:15:33
| Re: XAA!
More about $FF7F: It is indeed $2A on the C16, and $5E on the C116/Plus4. (At least on the ones I tried, anyway) 
|
|
Posted By
Csabo
on 2004-05-15
20:01:10
| Re: XAA!
Many thanks for the feedback everyone. Especially to Ulysses777, thanks for doing all this work. It was reassuring to see that at least two of the Plus/4's (4 and 5) produce exactly the "expected" behaviour. (YAPE produces the same results as well.)
This still doesn't mean that the opcode is useless though. A demo can easily test whether the opcode works as expected, and then (through code generation) either use it or not. And of course, if it is used, you can produce those extra 2 soft-sprites on screen, or add those extra 100 dots to your plotscroller. BTW, Questionmark has some code in the initialization routine, that may display message like "invalid processor type". Not sure if it's testing for illegal opcodes.
What about >FF7F on C16's? In some documentations it is mentioned that this byte represents the computer type. $5E = Plus/4, $2A = C16. No value mentioned for the C116. But seeing that it's the same as the Plus/4, maybe this info is completely incorrect?
About the reverse engineered 6502 page: I've seen it before, it was mentioned on the Hungarian forum. It doesn't say much about the actual instructions though. It would be WAY too much work to translate, and to be honest I think the real value there are the pictures. BTW, Utasításdekódoló means Instruction Decoder. In that section they actually mention this opcode: ANE: A = (A | #$EE) & X & #byte , and say that the constant ($EE) is not guaranteed. There's our answer again then, let's spell it out completely: XAA is unreliable.
|
|
Posted By
Ulysses777
on 2004-05-15
10:26:54
| Re: XAA!
Well, as far as the 264 series is concerned, it seems that this opcode is virtually useless.
I've tested Csabo's program on a C116, two C16's and five Plus4's, and almost all of them produce completely different results. (Two of them produce only $00's).
You can see the results in this zip file.
Oh, and $FF7F on my C116 is $5E.
|
|
Posted By
Bacon
on 2004-05-15
07:12:49
| Re: XAA!
According to the Transactor magazine opcode $8B ANDs X with memory, then ANDs the result with (A OR $EE) and stores the result in A. See the "Undocumented 6510 Opcodes" and "Undocumented 6500-Series Instructions" articles at http://www.csbruce.com/~csbruce/cbm/transactor/v6/i5/.
|
|
Posted By
Bionic
on 2004-05-15
05:00:24
| Re: XAA!
Csabo, since you know hungarian, this page may be of help to you:
http://impulzus.sch.bme.hu/6502/
They reverse engineered the entire 6502 from microscopic images of the die. All instruction decoding is performed by a big logic array, which is described (Utasításdekódoló ?) and depicted in the circuit diagram. It should be possible to find out, which functions are triggered by XAA.
Sorry, I do not know hungarian 
Somebody should translate that page, its really a gem hidden from the world..
P.s. you can be pretty sure that 6502, 6507,6510,7510,8510 behave identical in respect to illegal opcodes.
|
|
Posted By
Csabo
on 2004-05-14
23:19:22
| Re: XAA!
That is certainly bad news.
Okay, let's look at this in detail. The XAA is supposed to perform a TXA, so loading $00 into A is probably not necessary. (It should behave the same way without that line.) The second thing is: you perform the same operation each time ($FF AND $FF). It would probably be more interesting to see EACH X value ANDed with $FF, and see which bits are kept. Certain bits will come and go, and that's why you have the variation, but why the rest is zero... That's beyond me.
Two more smaller things, just friendly suggestions, I understand that you are new to this. The BEQ/JMP pair can be replaced with a BNE. BEQ will jump on equal, so if it's NOT equal, it will continue to the JMP line. BNE will jump if it's NOT equal, so that's all you would need. Also, what EQUAL really means is the ZERO bit. This bit is set by INY as well. This means you can simply remove the CPY #$FF line. That way, the loop will execute 256 times, and stop why Y overflows and becomes zero again (which is probably what you intended, and not 255 times). But all that's beside the point
Okay, so how about testing this?
LDX #$00
* $8B, $FF
STA $1100,X
INX
BNE *
BRK
And while you have your C116 on, there's something else that I always wanted to know. Could you go into Monitor and type >FF7F (return) and see what the first byte is?
|
|
Posted By
Ulysses777
on 2004-05-14
20:57:52
| Re: XAA!
I've quickly knocked up the following code to test this (I'm a bit new at machine code, so hopefully this produces something meaningful ):
. 1000 LDY #$00
. 1002 LDA #$00
. 1004 LDX #$FF
. 1006 XAA #$FF
. 1008 STA $1100,Y
. 100B INY
. 100C CPY #$FF
. 100E BEQ $1013
. 1010 JMP $1002
. 1013 BRK
Basically writes the result of XAA into $1100 to $11FE.
I've tried the above code on my C116, and it gives a result of $08 for the first few bytes, then $0C up to around $11BA, then $08 again for the remainder.
|
|
Posted By
Csabo
on 2004-05-14
18:57:19
| XAA!
Good topic, huh? Anyways, I want to bring up this important issue for public discussion. It's about (illegal) opcode $8B. Most places mention the mnemonic as XAA.
What the instruction is supposed to do, is perform a TXA (transfer X to A), and then AND #$XX, where XX is an immediate number.
It's not that simple though. There seems to be some messing around with bits 4 and 0. Coder extraordinaire Graham has a good page on this: http://oxyron.net/graham/opcodes02.html. Even he suggests not to use the opcode ("highly unstable (results are not predictable on some machines)").
However, this is Plus/4 World... It may or may not apply to us. Even if bits 4 and 0 are unreliable, the if rest of the bits work fine, the opcode may still be of GREAT use. I have a piece of code which is like this: TXA, AND #$80 ... some stuff ... TXA, AND #$40 ... some stuff ... etc. Every time XAA could be used instead, it's two machine cycles saved - and that's what optimizing for speed is all about.
Who knows more about this?
I also though of something else: write a small routine, which checks the results for the opcode, and displays a short message. Then we would ask all living Plus/4, C16, C116 owners to run the code and give us the results. While this may not be 100% conclusive, if we see good results for all the bits (except 4 and 0), that's good news.
|
|
| |
Copyright © Plus/4 World Team, 2001-2024. Support Plus/4 World on Patreon |
