nice code too ;D
as we may see there's a lot of ways to emulate the BNE instruction, but just a few of them are really efficient. my code looks quite confusing or complex right now, but i'll optimize it later, when the emulator has been done. thanks again dude! you really helped me out (:

To be pedantic about it, the offset is a signed twos complement value.

you're totally right my friend, but beleave it or not i found some errors while using 2's compliment. but everything went right with 1's complement. so strange :\

the most effective way ever seen

I'm a little puzzled by this code. Does it work if the operand at "memory[pc]" has the value zero? As in:



Which is legal (though useful perhaps only for playing with timing) and when assembled produces:



In the emulator code above, if "zflag" is not zero, "pc" gets incremented by two (past the zero operand value). If "zflag" is zero, "pc" gets incremented by only one (and still points at the zero operand value). Fetching that zero operand as the next instruction would trigger a BRK.

Unless I'm missing something, I do not think this is correct. Perhaps there is another increment somewhere else in the loop?

This absolutely will crash. Get rid of the second PC++.



Remember that the effective address is relative to the PC after the CPU's already read the effective address byte. That is, it's relative to the next instruction.

Since you already post-increment PC when fetching the effective address, PC already points to the next instruction. No need to increment it again if the condition is false.

Lee.

The error is of course mine: run6502 works, after all. The source is macro-heavy and I flattened it incorrectly. I'll try again:

You'll notice it doesn't even read the offset if the condition is false - it's a very efficient emulator.

Whats wrong with



The 6502 is twos complement. Your machine is twos complement*. Why not use it's ability to handle it natively? It will be much faster than messing around with it yourself and branching

* I say this with 99.99% probability

EDIT: Changed PC++ to ++PC to reflect original ordering

Here's one way:



And another:



And one more:



I think I like that last one best, even though it does an "unnecessary read".

Nice! Avoiding an extra branch feels like a good thing, although it's never wise to second-guess micro-optimisations. My ultimate preference would be for code which is "obviously" right, and efficient. Although I like this one, I had to think a bit.

Maybe I like OwenS' code best: inform the compiler of signedness, and have it generate the best machine code for sign-extension. It's short and simple, but you can only write it if you already understand very well what you need to do and how your language works.

I don't think I've yet seen code which would be ideal as a teaching example. Maybe you have to write your own, and struggle.

It's interesting that you can get a long way - even in C - without deeply understanding type conversions and machine operations. It's a good thing that so many people like to write an emulator - the value isn't in having one, but in creating one.

Particularly on x86, where branches can become hideously expensive (Though unlikely in this case, since it's a very short stream of instructions), avoiding them is good. Might as well use the sign extended load instruction:


Where S is the size (b byte, w word, l long, q quad) - thats AT&T syntax, so % designates a register

well this is the code i wrote and it works nice!

This 6502 Cpu emulator was coded in Visual Basic by Don Jarrett. It will prove to be the main CPU emulator used in VB5 Emulators (It's been used in PCSloMo). This is the final release version. Compile it using Visual Basic 5.0.

sorry for revive old posts, but let me just paste my final code:

(C# Language)


tested in almost 5 NES roms and works nice.

_________________
sorry about my english, i'm from Argentina :S

http://felliniycia.comule.com/