This isn't specific to the Android progress, but I'm wondering about the choice of showing the flags in an unconventional order:
N Z C I D V

I think it's normal to show them in the order they are in the status register, even though that raises the difficulty of dealing with the other two bits. Note that B will always show as set to 1.
N V - B D I Z C

This presentation helps with understanding BIT, at least, and with the result of PLP (or PLA if pulling a status register copy)

(Sorry if this is awkward because it's a different order from the one in your master instruction table.)

I like the suggestion of showing the flags in the order they are stored in the status byte. This can help a lot when doing debugging to keep one's mind together.

I will adjust the display order of the flags in my next blog.

Just on the Blogger admin. I have added a short note on the JavaScript emulator blog on where to find the Android C64 Emulator series.

That is just one feature I found missing from blogger. If you want to start a new blog series, you need to create a site with a different blogspot.com alias. And there is not really a straightforward way to keep your different blog series together.

A just released the next part on my series, creating a C64 emulator from scratch for Android. In this post we will be adding the Comparisons and branching instructions to our emulator.

Here is the link:

http://androidemufromscratch.blogspot.c ... ching.html

Just seen it - thanks for the credit. But... I see you say
"Secondly you will see that we hardcode the letter B for bit 4 of the status register. This is called the break flag. We will only implement functionality for setting and clearing this flag in later posts. For now we will just default it to B (This flag is set like 90% of the time)."
and this might be heading for trouble. The B flag is set 100% of the time. It's the B bit which might be zero, but it's only zero as written to the stack. The B flag is never seen (and in fact, doesn't exist! But that's even more confusing.)

I think this is more than me being pedantic - if you write an emulator which models a B bit which can be zero, you'll find yourself having to OR in a 1 when you push the value. I think it's more logical to follow the hardware, although the amount of code is probably the same in both cases. Either way, it's fairly easy to get this wrong!

I fully agree, one can easily get the inner workings of the break flag wrong, especially when you don't work withvit regularly

Probably the first I was forced to read up on how the break works, was when I ran the Klaus Test Suite on my JavaScript emulator. This Test Suite do some sanity checks on how you have implented the Break flag logic.

I have just released the part on series on writing a C64 emulator for Android.

In this post we will be implementing the Stack and related operations.

Here is the link:

http://androidemufromscratch.blogspot.c ... tions.html

I have just released Part 8 in my series for creating a C64 from scratch for Android. In this post we will implementing the remaining 6502 instructions within our emulator. So, after this post we will be ready to run a Test Suite on our emulator.

Here is the link:

http://androidemufromscratch.blogspot.c ... tions.html

How good is Android at inlining functions? In the Javascript emulator inside WFDis, where I have an arbitrary obsession with small code size, I do things like this: (paraphrased)


Instead of having stuff like setting flags, masking to 8-bit values, etc as repeated operations in every instruction, they're handled by small utility functions which end up getting inlined which would be equivalently fast. But besides just being small, they're also very readable and reusable without copy/paste bugs.

(Of course, I also have resolveRead and resolveWrite, which do the Right Thing™ based on the current instruction's addressing mode, which is a slower dispatch, but keeps the code small which is a higher priority. )

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

The native parts of an Android application (like my cpu.c and memory.c) is written in C. So yes, I think one might be able to inline functions within an Android application.

To be honest, I haven't thought about using inlining within my Android application, but this is definately a nice suggestion.

I am going to play around a bit with inlining and give some feedback in my next post.

I have just released part 9 in my series on writing a C64 emulator from scratch for Android. In this post we will attempt to run the Klaus Test Suite on the emulator to surface potential implementation bugs.

Here is the link:

http://androidemufromscratch.blogspot.c ... suite.html

I have just released Part 10 in my series on writing an Android C64 emulator from scratch. In this post we we will be booting the C64 system with its ROMS, Kernal and Basic.

I will also be covering Compacting the code of the Instruction decoding switch statement with the aid of inlining utility functions, as suggested by @WhiteFlame.

Here is the link:

http://androidemufromscratch.blogspot.c ... ystem.html

Cool, I'm curious if you measured any execution speed difference in doing that change.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

I'm gonna speculate that the execution speed is about the same ... the tangible benefits here are probably source size and coolness factor.

Mike B.

You are quite right @MikeB!

I ran some performance timers and couldn't really spot any performance penalty with the inlining.

On my Samsung Galaxy I got on average between 1 and 2 milliseconds per batch of 20000 emulated 6502 Cpu cycles when running the Klaus test suite for both uninlined and inlined versions.

It should be good for maintainability though? lib6502 does something like it, but very extreme, and using preprocessor macros.