Together with registers A, X and Y as well as program counter I managed to run a small assembler program today.Test-driven development is a software development process where you write a test before writing a code that satisfies that test, then refactor and continuously validate that the requirements are still fulfilled. I have also implemented some parts of the Memory class. I have now implemented LDA, LDX, LDY, STA, STX, STY and ADC with all the available addressing modes. I then began the big work to implement the opcodes. I then copies a list of opcodes from a 6502 FAQ and created defines for each opcode mapped to the hexcode, so I can use that instead of hexcodes in my emulator. I am pretty sure that KDevelop is a great environment, but I love Emacs and the productivity I get there.Īs a first thing I created classes for a MOS6502 processor and for Memory. But after some hours I realized that I missed my Emacs editor so much that I switched to my normal setup with Emacs and make. I began trying to write it in KDevelop, the integrated development environment used by the KDE project. I will write it in C++ under Linux, my favorite platform. Some days I started my work on this project. The 6502 can be set in a decimal mode where arithmetic operations go by base 10 instead of 16. I still need to add handling of the C and V flag, but after reading some on it it should be no big problem. It has shown out to not be optimal when flag handling comes in count. I need to refactor some of the memory decoding handling.
Then, when needed, I decode them as shown above. Now the flags internally contain the value of the latest operation that can affect them. Those flags are only read through branch instructions and used in a few other cases. That means that I called "Z = !!result" and "N = !!(result & 0x80)" a lot of times. My opcodes had macros calculating those flags for all instructions where it was applicable. The N and Z flags, telling if the last operation resulted in a negative or zero result, should be handled lazy. I realized that I did at least one thing in a not optimal way. Yesterday I read some on performance tuning for emulator programming. Good is that my CPU seems to be fully implemented! Now I need to investigate the rest! There seems to be binary formats for this that I probably want to support as well. I should at least add a function that loads binaries to specified memory locations. I need something like that to test and debug my processor.Īfter that I will implement some initial binary loading for my memory class. Plans now are to add a new thread to my emulator, allowing access to memory and registers during execution. I borrowed some idead, mainly the binary arithmetics, from Frodo here. Yesterday I implemented the decimal version of the ADC and ABC functions, allowing addition and subtraction decimally. The execution speed, mainly be using a more lazy flag approach, seems to be faster as well. I have now rewritten it with better macros and the opcodes are now around 2-3 lines of code. I had already used macros for such things as memory address decoding and memory retrieval, but still every opcode was around 4-6 lines of code, code that had to be correct and maintained. When completing the flag handling and the decimal arithmetic mode I realized that my opcode implementations were inefficient. #define POP_BYTE_STACK(b) memory->mem[ (++SP) \įirst time ever syndome.
#define READ_ADDR_ABS() (READ_BYTE_IMM() \ #define READ_ADDR_ZP_Y() ((READ_BYTE_IMM() + Y) & 0xff) #define READ_ADDR_ZP_X() ((READ_BYTE_IMM() + X) & 0xff) #define READ_BYTE_IMM() read_byte( PC++ ) The code is a bit more linebreaked here, just to fit the stupid fixed blog width. It is also generally faster implementing it as macros as real functions.īelow you can see macros helping with data retrieval. By using macros the opcode implementations can be kept down to 2-3 lines of code instead of 6-7, which makes it much easier to maintain. The main reason is the similarities between opcodes, that the way the read operands are similar. In this project i have written more macros than ever before.
0 kommentar(er)
