A Commodore 64 Emulator in Flutter: Part 9

Foreword

In the previous post we implemented all stack operations for our Flutter C64 emulator. This included pushing and popping the Accumulator and the status register. Also, we implemented the JSR/RTS instructions, which also operates on the stack.

In this post we will be implementing the remaining instructions of the 6502, which includes the following:

• BIT
• JMP (Jump)
• NOP
• Register operations

With these instructions implemented, we can start in the next post to run the Klaus Dormann Test suite on our emulator to see if we have implemented all the 6502 instructions correctly.

Enjoy!

The Jump instruction

Implementing the jump instruction is just a straight forward operation of loading the program counter with a new value. Let us add the selectors for these:

        /*
JMP (JuMP)
Affects Flags: none

MODE           SYNTAX       HEX LEN TIM
Absolute      JMP $5597     $4C  3   3
Indirect      JMP ($5597)   $6C  3   5
         */
      case 0x4C:
      case 0x6C:
        pc = resolvedAddress;

Now, there is two address modes for this instruction: Absolute and Indirect. The absolute address mode we have already implimented in the calculateEffectiveAddress() method, but not the Indirect Address mode. So, within the calculateEffectiveAddress() method, let us add the following selector:

      case AddressMode.indirect:
        var lookupAddress = (operand2 << 8) | operand1;
        return memory.getMem(lookupAddress) | (memory.getMem(lookupAddress + 1) << 8);

The BIT instruction

Next, let us implement the BIT instruction. From the specs, the BIT instruction is defined as follows:

BIT (test BITs)
Affects Flags: N V Z

MODE           SYNTAX       HEX LEN TIM
Zero Page     BIT $44       $24  2   3
Absolute      BIT $4400     $2C  3   4

BIT sets the Z flag as though the value in the address tested were ANDed with the 
accumulator. The N and V flags are set to match bits 7 and 6 respectively in the 
value stored at the tested address.

We implement this as follows:

      case 0x24:
      case 0x2C:
        int memByte = memory.getMem(resolvedAddress);
        _z = ((memByte & _a) == 0) ? 1 : 0;
        _n = ((memByte & 0x80) != 0) ? 1 :0;
        _v = ((memByte & 0x40) != 0) ? 1 :0;

The NOP instruction

The NOP instruction is the short for No Operation. It literally does nothing except for consuming CPU cycles. One of the major uses of this instruction is to reserve some slots in memory where in future you might want to add some more instructions.

Strictly speaking you don't need to implement a case selector for this instruction in our big switch statement decoding the different op opcodes. The surrounding mechanism should just skip to the next instruction.

However, by not implementing a selector for NOP, the default selector will be invoked in the switch statement. The default selector is nice to warn us if we forgot to implement some instructions or we encountered some undocumented instructions in the code. By not giving NOP a selector we will get many false positives by hitting the default selector.

So, the selector for NOP will look as follows:

        /*
NOP (No OPeration)
Affects Flags: none

MODE           SYNTAX       HEX LEN TIM
Implied       NOP           $EA  1   2
         */
      case 0xEA:
        break;

With the Dart language we don't need the break in general. However, when you have blank case like this you will need to add it, otherwise it will fall through to the next case statement with code, which is not what we want.

Register operations

Finally, let us implement the register operations. As per the specs, these are the following Instructions:

Register Instructions
Affect Flags: N Z

These instructions are implied mode, have a length of one byte and require two machine cycles.

MNEMONIC                 HEX
TAX (Transfer A to X)    $AA
TXA (Transfer X to A)    $8A
DEX (DEcrement X)        $CA
INX (INcrement X)        $E8
TAY (Transfer A to Y)    $A8
TYA (Transfer Y to A)    $98
DEY (DEcrement Y)        $88
INY (INcrement Y)        $C8

In previous posts we did implement some of these. Doing some inventory, I found that the following still needs to be implemented:

• TAX
• TXA
• INX
• TAY
• TYA
• INY

Here is the implementation:

      case 0xAA:
        _x = _a;
        _n = ((_x & 0x80) != 0) ? 1 : 0;
        _z = (_x == 0) ? 1 : 0;

      case 0x8A:
        _a = _x;
        _n = ((_a & 0x80) != 0) ? 1 : 0;
        _z = (_a == 0) ? 1 : 0;

      case 0xE8:
        _x++;
        _x = _x & 0xff;
        _n = ((_x & 0x80) != 0) ? 1 : 0;
        _z = (_x == 0) ? 1 : 0;

      case 0xA8:
        _y = _a;
        _n = ((_y & 0x80) != 0) ? 1 : 0;
        _z = (_y == 0) ? 1 : 0;

      case 0x98:
        _a = _y;
        _n = ((_a & 0x80) != 0) ? 1 : 0;
        _z = (_a == 0) ? 1 : 0;

      case 0xC8:
        _y++;
        _y = _y & 0xff;
        _n = ((_y & 0x80) != 0) ? 1 : 0;
        _z = (_y == 0) ? 1 : 0;

This covers the instructions we wanted to implement in this post. I am not going to write a test program in this post to test the instructions we have implemented, since in the next post we will start to run the Klaus Dormann Test Suite, which will anyway surface any defects.

In Summary

In this post we implemented the remaining instructions for our emulator.

In the next post we run the Klaus Dormann Test Suite on our Emulator to see if we have some defects in our implementation. This will probably go over to multiple posts depending on how many issues we detect.

Until next time!

A Commodore 64 Emulator in Flutter: Part 8

Foreword

In the previous we implemented the compare and branch instructions for our Flutter C64 Emulator.

In this post we will implement the 6502 stack and related operations like pushing/ popping, Jump to subroutine and Return from subroutine.

Enjoy!

The stack concept

The stack is a Last in First out (LIFO) data structure. To visualise a stack in real life, one can look at a receipt stack:

Clearly, one can see that the receipt that is most accessible is the last receipt you have placed on top of the pile.

In a CPU the stack has many uses, like if you were calling subroutines in a nested way, and you want to return to the caller of a subroutine. A stack is perfect for this, because you want access to the last return address.

On the 6502, the stack is 256 bytes in size and lives in page 1 of the memory space. That is the address range $100 - $1ff. On the 6502 the stack grows downwards starting at $1ff, growing down towards $100. Obvious as you pop stuff off the stack it goes back towards $1FF.

On the 6502 the stack has many uses, of which we already mentioned jumping and returning from sub routines. You can also push and pop registers. The 6502 also uses the stack when serving interrupts. Before an interrupt routine is called it stores the state of the CPU on the stack, so if the service routine is finished, it restores the CPU to the state before the CPU was interrupted, and the program continues as if nothing has happened.

Creating the stack mechanism

Let us start by writing some code for implementing the stack mechanism. We start by defining a stack pointer:

int _sp = 0xff;

We start with the initial value of 0x1ff, which is the starting poisition of the stack. We omit the high byte value of 1, and will just prepend it if we need to do any lookups in memory.

Now let us create some push and pop instructions.

  push(int value) {
    memory.setMem(value, _sp | 0x100);
    _sp--;
    _sp = _sp & 0xff;
  }

  int pull() {
    _sp++;
    _sp = _sp & 0xff;
    return memory.getMem(_sp | 0x100);
  }

With the understanding that the stackpointer points to the location where the push will happen, we can use the stackpointer address as is when storing the value of the push and then decrement the pointer thereafter.

However, since the pointer points to the next push location, you cannot use the location as is when doing a pull. You first need to increment the pointer and use that value for the read address. 

Before ending this section, let us see if we can implement the basic stack instructions Push accumulator(PHA) and Pull Accumulator(PLA) to see if our stack implementation behaves as expected.

    /*
    PHA (PusH Accumulator)          $48  3
    */
      case 0x48:
        push(_a);
    /*
    PLA (PuLl Accumulator)          $68  4
    */
      case 0x68:
        _a = pull();
        _n = ((_a & 0x80) != 0) ? 1 : 0;
        _z = (_a == 0) ? 1 : 0;

Implementing JSR and RTS

Let us now implement the JSR (Jump to Subroutine) and RTS (Return from Subroutine) instructions.

So, in principle when the JSR executes, it pushes the address of the next instruction on the stack as the return address before jumping to the subroutine. When the subroutine finishes executing and invoke RTS, it pulls this address again of the stack and jump to it.

However, there is a small caveat with this sequence of events. The return address pushed onto the stack is not exactly the return address of the next instruction, but the address of the next instruction -1.

This way of operation of the JSR, the designers of 6502 implemented as a kind of an optimisation. When reading instructions from memory the program counter is incremented by 1 each time, and by the time it needs to push the return address the PC is still pointing to the last byte of the JSR instruction.

Now, if were to implement the JSR/RTS in your emulator with the assumption that the value pushed on the stack is purely the address of the next instruction, without worrying about the -1 stuff, you emulator would probably work fine 99% of the time. That been said, however, I did encounter some magic 6502 code in the past that interrogate the contents of the stack for implementing stuff like copy protection or auto-starting code. In such cases, your emulator might not work correctly with such code if your emulate the JSR instruction doesn't push adresses on the stack following the -1 convention.

So, it is important to adhere to this convention when implementing the JSR/RTS instructions.

Here is the implementation of these two instructions:

/*
MODE           SYNTAX       HEX LEN TIM
Absolute      JSR $5597     $20  3   6
 */
      case 0x20:
        int temp = (pc - 1) & 0xffff;
        push(temp >> 8);
        push(temp & 0xff);
        pc = resolvedAddress;
/*
MODE           SYNTAX       HEX LEN TIM
Implied       RTS           $60  1   6
 */
      case 0x60:
        pc = pull();
        pc = pc | (pull() << 8);
        pc++;
        pc = pc & 0xffff;

Implementing the other stack operations 

Let us now implement the rest of the stack operations.

The simplest of these operations are the transfer between the Stack Pointer register and the X register, which is TSX and TXS. So let us quickly implement them:

/*
        TXS (Transfer X to Stack ptr)   $9A  2
 */
      case 0x9a:
        _sp = _x;
/*
        TSX (Transfer Stack ptr to X)   $BA  2
 */
      case 0xba:
        _x = _sp;

What remains to be implemented is pushing and pulling the status register, that is the register that contains all the flags, like the Zero Flag, Negative Flag, overflow flag and do so on.

At this point the question arises in which order the flags are stored in the status byte that gets pushed onto the stack. One possibility is deciding on the order of the flags yourself and emulation will probbaly work correctly 99% of the time.

However, as I mentioned in the previous section where we implemented the JSR/RTS instructions, you often 6502 machine language programs that inspect the contents of the stack, so if you decide the order of the flags in the status byte yourself, this code might not work correctly.

The question is: How do we find the correct order of the flags in the status register? In the general the web sites that gives you info on the 6502 instructions, don't provide you with this info on the status register.

After digging a bit on the internet, I found the information via the following link:

https://www.princeton.edu/~mae412/HANDOUTS/Datasheets/6502.pdf

They provide a nice diagram for the status register:

Some extra information about the status register is that bit 4 and 5 should be one when pushed on the stack. Similarly, when popping this value back to the status register, we ignore bits 4 and 5. With all this said, let us implement the PHP and PLP instructions:

/*
        PHP (PusH Processor status)     $08  3
 */
      case 0x08:
        push((_n << 7) | (_v << 6) | (3 << 4) | (_d << 3) | (_i << 2) | (_z << 1) | _c);
/*
        PLP (PuLl Processor status)     $28  4
 */
      case 0x28:
        int temp = pull();
        _c = temp & 1;
        _z = (temp >> 1) & 1;
        _i = (temp >> 2) & 1;
        _d = (temp >> 3) & 1;
        _v = (temp >> 6) & 1;
        _n = (temp >> 7) & 1;

We have implemented all instructions for this post. In the next section we will write a test program for all the instructions we have added.

The Test Program

We will use the following for our test program:

0000 A9 0A LDA #$0a
0002 48    PHA
0003 48    PHA
0004 48    PHA
0005 48    PHA
0006 a2 50 LDX #$50
0008 9a    TXS
0009 48    PHA
000a 48    PHA
000b 48    PHA
000c 48    PHA
000d A9 7F LDA #$7f
000f 69 01 ADC #$01
0011 20 19 00 JSR TEST
0014 68    PLA
0015 68    PLA
0016 68    PLA
0017 68    PLA
0018 68    PLA
0019 08 TEST PHP
001a B8    CLV
001b A9 00  LDA #$00
001d 28     PLP
001e 60     RTS

Here we test a couple of operations of the stack. Pushing and pulling elements from the stack, changing the stack pointer, doing a JSR/RTS and pushing and pulling the Status register.

Currently within our emulator, we only have a view of the first page of memory (e.g. bytes 0 to 255). However, when executing the above program it would be nice to extend the view so we can see what is happening on the stack as well. I have made the change and it look like this:

I am not going to cover the changes required to adjust the view like this, but it is available in a git tag I have created here. This tag also contains the test program for this post as binary which will execute as you click the step button.

Lets see how the stack changes as we execute the program. We start by pushing the Accumulator a number of times to the stack. We can see our values towards the end of page 1:

We then change the stack pointer to 0x50 and do a couple of pushes again of the Accumulator. We can now see the contents pushed is now in a different aread in memory:

Next, we force the Overflag flag to be set by doing an addition that causes an overflow after which we push the status register. With the overflow operation we just mange to set as much flags as possible. We then jump to a sub routine which pushes some stuff on the stack.

At this point, our memory dump will look like this:

The return address pushed is 0013. As mentioned in a previous section the return address pushed is always one less than the actual address, because of the design of the 6502.

The value pushed for the Status Register is F0 (e.g. the upper 4 bits set). As mentioned previously, bits 4 and 5 are always set, and because of the operations we did, the overflow flag is set as well as the negative flag. 

We then clear the negative and overflow flag on purpose to see if the PLP instruction at the end of the subroutine restore them for us.

We then correctly return from the subroutine continuing execution at address 0014. We then do a number of pulls to our accumulator to see if we get back the same values that originally pushed. By purpose I have added an extra PLA afterwards to see what it does. And as expected, we get a 00 because that it after the last value.

This concludes what we want o achieve in this post

In Summary

In this post we implemented all stack operations, including push and pull the accumulator and the Status register. We also implemented the JSR/RTS instructions, which also relies on the stack.

We are just about finished with implementing all instructions for the 6502. What remains are the following:

• BIT
• JMP (Jump)
• NOP
• Implied register operations

So, in the next post I will be implementing these.

With the above implemented, we can move onto more interesting things, like running the Klaus Dormann Test Suite on our emulator to see if it behaves like a real 6502. This is very important, because it will help us to emulate a game as accurately as possible.

Until next time! 

A Commodore 64 Emulator in Flutter: Part 7

Foreword

In the previous post we implemented the Logic operator and bit shifting instructions for our Flutter C64 emulator.

In this post we will be implementing the Compare and branching instructions.

The Compare instructions

The comparison instructions remind us of the if statement you get in almost every programming language where you test two numbers to see which one is the biggest or if they are equal.

In machine language, like on the 6502, we mimic the if statement via a compare instruction which subtract the two numbers effecting either the Carry, negative or zero flag. The then part of the if statement we mimic with a branch instruction, where you can say branch to a particular address depending on a certain state of one these flags. More on the branch instructions in another section.

One concern when mentioning the fact that the compare instruction does a subtract, is whether an overflow is a possibility as we experience with an SBC (subtract with carry). Checking the documentation and seeing that no Overflow flag is set by the compare instruction, is indeed confusing.

There is, however, two facts that make the overflow flag not relevant with a compare instruction. One fact is that a compare does an unsigned comparison. The other reason is we only consider the Carry or Zero flag when doing a comparison, and don't really look at the Negative flag.

Let us now see how we can implement the compare instructions in our flutter emulator.

One can get into temptation just to in Flutter to just do a physical subtraction when implementing a compare instruction. However, one would not be able to accurate emulate a 6502 compare instruction when you do this. Let us go into a bit more detail into why this is.

Lets take an example. If a number in the accumulator is bigger than the other number compare. The carry flag needs to set. The carry flag corresponds to bit 8 of the result, or have a weight of 256. So, suppose you compare 2 with 1, you should get the value 257, which is this value in binary:

(1) 0000 0001

If you just do a subtraction in flutter for this, you will just get 1. Strictly speaking, there will still be a carry in the background of Flutter and your CPU the operation is performed, but because the numbers have much more bits in modern day CPU's than 8 bits, like 64 bits, the carry bit will probably be at bit 65 or so.

So, let us see if we can emulate the 6502 compare instructions more accurately. To do this, we meed to understand how the 6502 does subtraction. All this boils down to Two's complement for representing negative numbers. Two's complement basically saus in order to make a number negative, you first need to negate the number (that is making every 1 a zero and every zero a one) and add one to the result.

Say for instance you want to represent -1. First, in binary you have:

0000 0001

Now do the negation:

1111 1110

And then add 1:

1111 1111

At first glance, this number doesn't look meaningful, but lets take an analogy that will shed new light on the meaning of such a number. Everyone knows about an odometer of a car. It starts at 000000 and counts till 999999. When it goes past 999999, it goes back to 000000.

Suppose we could do something interesting. With the odometer at 000000, we go back 3 units, then you are at 999997. Now, if you add 5, you get to (1)000002. The one is in brackets because the digit doesn't really exists on the odometer. But, what we have actually done here was subtracting 3 from 5 using addition! The 999997 is the ten's complement representation of -3.

We can use the same analogy in binary. Lets say you have the 8 bit binary number 0000 0000. If you move back one unit, you get 1111 1111, where everything is zero. This actually corresponds to -1, which we determined earlier.

If you move back one further unit you get 1111 1110 for -2 and 1111 1101 for -3. All this you can verify using 2's complement.

Let us now use this knowledge with a compare. Suppose you want to compare 2 and 1. So, we do 2-1 in binary, with the -1 converted to two's complement:

  0000 0010

+ 1111 1111

(1)0000 0001

We can see we have a carry indicating the first number is bigger than the second. If we swop the number around, i.e. 1-2, we get this:

0000 0001

+1111 1110

1111 1111

In this case 1111 1110 is the two's complement of -2. In this case we dont get a carry with the addition, meaning the first number is smaller.

Let us now do some coding to implement these instructions in our flutter emulator. We create the following compare method which we can use among the different flavours of compare instructions:

  void compare(int operand1, int operand2) {
    operand2 = ~operand2 & 0xff;
    operand1 = operand1 + operand2 + 1;
    _n = ((operand1 & 0x80) == 0x80) ? 1 : 0;
    _c = (operand1 & 0x100) != 0 ? 1 : 0;
    _z = ((operand1 & 0xff) == 0) ? 1 : 0;
  }

This method starts off with doing twos complement, but we and the result of the negate with 0xff, so we just sit with the lower 8 bits. Our flutter emulator will probably run on 64 bit machines, which meand if we do a negate, we will probably sit with a 64-bit number where bits 8 to 63 are ones, which will probably give us a result which we don't want.

The rest of this method is pretty straight forward. Bit 7 of the result is the negative flag, Bit 8 is the carry flag. Also we use the lower 8 bits to check if the result is zero. 

With this method implemented, we can now implement the individual compare opcodes. Lets start with the CMP instructions:

/*
CMP (CoMPare accumulator)
Affects Flags: N Z C

MODE           SYNTAX       HEX LEN TIM
Immediate     CMP #$44      $C9  2   2
Zero Page     CMP $44       $C5  2   3
Zero Page,X   CMP $44,X     $D5  2   4
Absolute      CMP $4400     $CD  3   4
Absolute,X    CMP $4400,X   $DD  3   4+
Absolute,Y    CMP $4400,Y   $D9  3   4+
Indirect,X    CMP ($44,X)   $C1  2   6
Indirect,Y    CMP ($44),Y   $D1  2   5+

+ add 1 cycle if page boundary crossed
 */
      case 0xC9:
        compare(_a, arg0);
      case 0xC5:
      case 0xD5:
      case 0xCD:
      case 0xDD:
      case 0xD9:
      case 0xC1:
      case 0xD1:
        compare(_a, memory.getMem(resolvedAddress));

Pretty straightforward, and we pass the value of the accumulator in, in both cases.

Lets do the same with CPX and CPY:

/*
CPX (ComPare X register)
Affects Flags: N Z C

MODE           SYNTAX       HEX LEN TIM
Immediate     CPX #$44      $E0  2   2
Zero Page     CPX $44       $E4  2   3
Absolute      CPX $4400     $EC  3   4
 */
      case 0xE0:
        compare(_x, arg0);
      case 0xE4:
      case 0xEC:
        compare(_x, memory.getMem(resolvedAddress));

/*
CPY (ComPare Y register)
Affects Flags: N Z C

MODE           SYNTAX       HEX LEN TIM
Immediate     CPY #$44      $C0  2   2
Zero Page     CPY $44       $C4  2   3
Absolute      CPY $4400     $CC  3   4
 */
      case 0xC0:
        compare(_y, arg0);
      case 0xC4:
      case 0xCC:
        compare(_y, memory.getMem(resolvedAddress));

So, we pass in the value of register x for CPX instructions and the value of register y for CPY instructions.

This conclude all the compare instructions.

Branching Instructions

Let us now look at the branching instructions. Every branching instruction branch depending on the state of a certain flag, whether it is the Carry flag, Zero Flag, Negative flag and so on.

With a branch instruction we don't supply an absolute address to jump to if the branch condition is true, but a relative address that you need to add to the program register to find the destination address.

Let us write a quick 6502 machine code program to understand the branch instructions better:

4000 A9 05 LDA #$5
4002 38    SEC
4003 E9 01 SBC #$1
4005 D0 FC BNE $FC
4007 A9 22 LDA #$22

Here we have a program where we basically have a loop where the Accumulator starts with value 5, and gets decremented till it reaches zero.

The controller of the loop is at address 4005, the BNE (Branch if not equal) instruction, that will keep branching back to the SBC instruction at address 4003 until the zero flag is set.

Now the paramter of the BNE instruction might look confusing, but in actual fact, it is a 8 bit two's complement number you need to add to the program counter if the branch is to be taken. This means you can jump in the range -128...127.

In our example, the parameter $FC is the two's complement for -4. Now when we want to execute the BNE, program counter is just after this instruction, which in this case is 4007. Subtract 4 from this, and you are at address 4003, which is where we want to be.

With all this said, let us see if we can emulate the branch instruction in Flutter. All in all this boils down to adding a byte value to a 16-bit value, with a twist: The byte value is signed! This is a bit tricky to emulate on most platforms, because if you add a byte value to a 16-bit value, the value will always go up, and not down if it is negative.

Lets look at a couple of ways to solve this. Off the bat, one would probably do something like this in Flutter:

    if (operand1 > 127) {
      operand1 = operand1 | 0xff00;
    }
    return (pc + operand1) & 0xffff;

So, if we see our offset is negative, e.g. our byte value is bigger than 127, we pad bits 8-15 with ones. If we then add this to the program counter, the lower 16 bits of the result would indeed be the result of a subtraction.

This is indeed a solution, but can't we make it more elegant? Lets look a bit what the famous C64 emulator, VICE do with this:

So, in VICE, if the branch is to be taken it does something very fancy when calculating the destination address. It casts the byte to a signed char! This is a very nifty trick which the C language provides. By casting a byte as a signed value, the C compiler honours the fact that this byte is a twos complement value, and thus if the value of the byte is negative, it will do the subtraction for you.

However, that nifty trick is in C and not in Flutter in which we develop this emulator. So, the question is: Is there a similar nifty trick we can use in Flutter for this? Indeed there is. In Flutter for every int, there is a toSigned() method you can call. As parameter, you pass it the number of bits your number is wide, assuming the last most significant bit is the sign bit. So, if you do something like the following:

0xfe.toSigned(8)

You will get back -2. 

We now have enough info to calculate an address for the relative address mode in the method calculateEffectiveAddress:

 int calculateEffectiveAddress(int mode, int operand1, int operand2) {
    var modeAsEnum = AddressMode.values[mode];
    switch (modeAsEnum) {
...
    case AddressMode.relative:
        return (pc + operand1.toSigned(8)) & 0xffff;
    }
...
    return 0;
  }

Next, we implement the following method:

 branchConditional(bool doBranch, branchAddress) {
    if (doBranch) {
      pc = branchAddress;
    }
  }

And finally, we can implement all the branch instructions:

    /*
    BPL (Branch on PLus)           $10
     */
      case 0x10:
        branchConditional(_n == 0, resolvedAddress);
    /*
    BMI (Branch on MInus)          $30
     */
      case 0x30:
        branchConditional(_n == 1, resolvedAddress);
    /*
    BVC (Branch on oVerflow Clear) $50
     */
      case 0x50:
        branchConditional(_v == 0, resolvedAddress);
    /*
    BVS (Branch on oVerflow Set)   $70
     */
      case 0x70:
        branchConditional(_v == 1, resolvedAddress);

    /*
    BCC (Branch on Carry Clear)    $90
     */
      case 0x90:
        branchConditional(_c == 0, resolvedAddress);
    /*
    BCS (Branch on Carry Set)      $B0
     */
      case 0xB0:
        branchConditional(_c == 1, resolvedAddress);
    /*
    BNE (Branch on Not Equal)      $D0
     */
      case 0xD0:
        branchConditional(_z == 0, resolvedAddress);
    /*
    BEQ (Branch on EQual)          $F0
     */
      case 0xF0:
        branchConditional(_z == 1, resolvedAddress);

A Test program

Let us end this post where we a write a quick test program doing a compare and branch.

At this point of writing the test program, it really start to be become convenient to have the DEX and DEY commands, which we don't have implemented at the moment. So, I took the liberty to implement them in the emulator. I will not show the implementation here, but you are welcome to look at that on my github page.

So, here is the test program:

4000 A2 0A LDX #$0A
4002 CA    DEX
4003 E0 04 CPX #$04
4005 D0 FB BNE LOOP
4007 A9 15 LDA #$15

This program will loop with values from $a to $4 in register X.

You can find this program as binary as well as the state of our emulator as per this post, via this tag:

https://github.com/ovalcode/c64_flutter/releases/tag/c64_flutter_part_7

In summary

In this post we implemented the brnach and compare instructions.

In the next post we will be implementing stack operations in our emulator.

Until next time!