I'm playing around with writing an 6502 emulator for fun. I found this, it contains
a detailed instruction set reference, but I do not understand all the peudo code logic. Some of it such as the flags and the accumulator.

I have seen the same pseudo code a few other places, so it must be common way to describe the 6502 logic.
So, where do read up on it?

Thanks in advance!

Looks like a good reference, and it looks like it's drawn from Rockwell's documentation.

Pseudocode should look very familiar and understandable to anyone familiar with a regular programming language like C or Java. Could you illustrate your difficulty with an example? Have you read any emulator code? Maybe the more concrete form of a working program would make more sense to you. There are several listed at http://6502.org/tools/emu/ and many of them are open source.

[The trouble with pseudo code, and code, is that it may contain bugs. So the best reference would be the code of an emulator which is known to have very high quality - one which passes Klaus' test suite for example, or Wolfgang's.
(See http://visual6502.org/wiki/index.php?ti ... stPrograms)]

I see my error, I wrote the question in a hurry. It isn't the pseudo code I don't understand, it is the variable names!
But yeah, I have been looking at a few emulators and they use the same variable names as in the link given above.

I see there's a section about the flags at
http://homepage.ntlworld.com/cyborgsyst ... .htm#FLAGS

Does that resolve your difficulty?

A very common failure when an emulator is thoroughly tested is the B bit - the physical reality is that there is no B flag in the CPU, but bit 4 of the byte written to the stack will be zero only if the write was caused by an interrupt. (I hope I got that the right way round.) It's almost the same as saying there's a B status bit, but not quite! I think the best way to model it is to force the modelled status bit to a 1, just the same as the unused bit. Another way to model it is to fiddle with the status byte as you write it to the stack.

Thanks, it solves most of it
However I still don't get the A.7 or t.7 as seen in the ADC description. My best bet is that it has something to do with bit shifting or masking.

OK, that .7 notation is saying to take bit 7 of the variable in question. If it were a byte, that would be the top bit. If a signed byte, it would be the sign bit. So there will be various ways to get hold of that bit in your language of choice, including shifting or masking. Possibilities might include, very approximately,
(unsigned)A>127
(signed char)A < 0
(A && 0x80)==0
(A && 0x80)>>7
but of course I might have the sense of the bit flipped.

Thank you very much for your help.
I think i have what I need. I can test it out in a few hours when I get home

Glad to be useful! Now, I feel a digression coming on...

It's a funny thing that you can get a long way with programming - even in assembly language - without really getting to grips with bits. But to write an emulator, I think you do need to dig in. A lot of assembly language introductions like to put in a chapter early on about hexadecimal - I wonder if that's not really necessary. Perhaps it should be marked as optional, to be revisited if need be.

Having said which, &8000 is a lot more meaningful than 32768, once you know a bit about hardware.

(It might be that you're fine with bits, just that the notation was an oddity.)

I'll give you that one, I do get along with hex and binary (can't convert back and forth in my head though), but bit manipulation is not something I do very often.
That is hopefully going to change with this project.

WARNING! Pedantry coming!

From the referenced Rockwell 6502 page:

Code:

ChkBrk: ; Check if Interrupt was caused by a BRK
         TSX                ; Get Stack Pointer to X
         INX                ; =Address where Y is stored
         INX                ; =Address where X is stored
         INX                ; =Address where A is stored
         INX                ; =Address where P is stored
         LDA  $0100,X       ; Get Stack copy of PSW to A
         AND  A,$10         ; Isolate P.B
         BEQ  NotBrk        ; If P.B=0, skip BRK Handling code

Now, I don't intend to pick on anyone's effort to improve their understanding of the 6502. However, some of the code examples on that page don't necessarily set forth an optimum style to the assembly language programmer who is learning the craft. I think most experienced programmers would write the above as:

Code:

ChkBrk: ; Check if Interrupt was caused by a BRK
         TSX                ; Get Stack Pointer to X
         LDA  $0104,X       ; Get Stack copy of PSW to A
         AND  A,$10         ; Isolate P.B
         BNE  IsBrk         ; If P B=1 handle BRK
;
;
;   fall thru to IRQ handler...
;

A fundamental programming principle that should be observed, especially in time-sensitive functions, is to arrange branches so that they are not taken in the most common of cases. Also, there is no need to consume eight clock cycles with aligning .X to point at the stack copy of SR, given that the 6502's stack is in an immutable place. Might as well make the assembler do the grunt work. Of course, the above will blow up if $0104,X evaluates to an address that is higher than $01FF. However, that would only occur if the stack pointer was $03 or lower when the interrupt occurred.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

At the assembly language level, bit manipulation is actually quite easy, and often necessary. Anything involving I/O hardware unavoidably involves setting, clearing, shifting, masking, and testing bits. In 6502 assembly language, the usual notation for referring to a bitwise value is %xxxxxxxx, where each x represents a single bit and % tells the assembler that the value is binary (% is referred to as the radix). For example, here's how that would be used in code that tests to see if the serial shift register in a 65C22 has completed a full shift (ISR means interrupt status register):

Code:

         LDA #%00000100        ;test mask to check bit 2 of ISR
;
SRTEST   BIT VIA1ISR           ;shift register done?
         BEQ SRTEST            ;no, keep waiting

Speaking from my perspective, I find binary representation easier to visualize than with using other radices.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!