omarandlorraine/fake6502

A library that emulates the 6502

fake6502's Issues

first small changes

Here are a couple of 'first' changes I'd like to make to the code.

I'm not trying to change any run-time functionality, or fix any bugs, it's just updating the source files to be more compliant with being a library/module that gets included within another project.

1. fake6502.c

doxygen the header comment and include/update the version number to be a 'current' version.

2. fake6502.h

surround/protect the header file (from multiple includes) by:

#ifndef FAKE6502_H
#define FAKE6502_H
...
#endif

I hope these suggestions are not controversial, and if accepted, I'd like to edit the files and make the changes.

Please also then comment - how do I work with github?

Do I create a new branch (?) within this project, and then push my changes into my branch?

Thanks,
John.

hello

I'm looking to make contact with this project.

I just started using it, it is pretty much exactly what I want, so very happy with it.

I do have some suggestions, and so I'm curious as to how I go about putting them forward?

I am a C developer, so I'd be happy to be making any changes that I suggest.

Thanks,
John.

code and doc updates

For the next set of changes/updates, here is what I'd like to propose:

documentation

Let me know what you'd like to see, in which (maybe new) files?

Do we want a new file for 'history', or should that be in README.md?

If you'd like to suggest a new file layout, I'll go with that, or I can try to develop it.

FYI: I found that:

git log fake6502.c > fake6502_c.log

produces the complete commit history, so we can use that to automate or get a 'history' file started.

code

structs

• I'd like to split (internally) the 'context' struct, into 'cpu' and 'emu' structs, which will then be combined in the 'context' struct.

That would allow the save/restore of each state, separately (useful fro something I have in mind). It's not essential, but would make for better code later on.

• re-instate the 'instructions' counter, again, useful for another change later on.

• uint8_t mem[65536] - replace by a pointer: uint8_t *mem

I can see the use for putting the memory space in the context, but it should be by reference (pointer), rather than by allocation.

As a library, it should not be allocating such memory - it is for the host process to do that (IMHO).

And this change would allow 2 hosted CPU's to share the same memory space - if that's what a user wanted.

For my use case, I already have the 64K allocated, so by having the array in the contact, it is forcing another allocation of memory, which is not going to be used.

source code

• for the option defines (NMOS6502 and CMOS6502), add a logic check, to ensure that one of them has been defined, else give an error.

• move the defines/macros into the header file, so they can be accessed by the host project.

This is something I need to do in my project, as I'm adding some functionality (specific to my project) in my code space, so I need access to them.

• stack pointer (s) - why does it start at 0xfd?

I would have thought that it starts at 0xff.

Break-flag handling in plp() and rti() + irq6502() doesn't respect IRQ flag...

Hi, Happy new year!

I used this code for my tiny (crappy) C64 emulator and ran into some issues with the interrupts.

I think the routines for plp() and rti() should clear the BREAK flag, when reading the status flags from the stack.
Otherwise, the BREAK flag could get set via php() or brk().
Reference: http://wiki.nesdev.com/w/index.php/Status_flags#The_B_flag

Additionally, irq6502() might want to check for the IRQ flag being zero before execution, as the CPU should not react to irqs in that case...?

Thanks & Regards,
Webfra

Overflow flag not properly tested

Apparently there is a difference between how fake6502 originally computed the overflow flag and how this emulator currently does it. I'm not sure why I changed it. (did I find a bug? did I introduce a bug?)

So what I want to see is the overflow flag being tested in the tests.c file.

bra() function miscalculates program counter?

Hi again,
I think I found another issue.
For branches (relative jumps) the new program counter is calculated twice. Once in rel() and then again in bra(). In both places, the program counter is incremented. Therefore, the second calculation results in a wrong jump target address, as it reads the relative jump address from an already advanced PC.
rel() stores its result in c->ea, so I think bra() should just use the stored (and correct) value.
Regards,
Webfra