Quote: Original post by WazzatMan
I'd definitely like to see the progress on this project as it unfolds.

Agree with this.

Quote: Original post by essial
If enough people actually want me to blog about it then I will, I just figured there wouldn't be too much interest as this is not exactly something new :)

If you do a good job of documenting what youve done and why, etc, that might be new.

If I was doing something this interesting, I would blog it :)

Alright, I'll start a blog. I haven't gotten into blogging yet, so what site would you guys suggest I use? Once I set it up I'll post here with the URL. Again, I've got a lot to do today so I wont have any more updates until tomorrow but tonight when I get home I'll check your replies and start blogging my progress. Thank you for your interest in this project :)

Quote: Original post by essial
Alright, I'll start a blog. I haven't gotten into blogging yet, so what site would you guys suggest I use?

This one? [wink] Other people have written about emulator projects in the GameDev journals in the past.

Alright, I have created a blog here. I JUST created it, and I haven't done anything with blogging yet so it may not be until tomorrow (monday) before the site makes any sense, so have some patience :)

Quote: Original post by essial
Yeah right now I am fighting an issue that seems to be related to a stack overflow (meaning, when RTS is called, the wrong address is poped off the stack. It's pretty obvious when seen through my CPU trace:

[#$F4FA] $18 <- CLC (Clear Carry Flag)
[#$F4FB] $F0 <- BEQ (Branch if Equal)
[#$F4FD] $38 <- STC (Set Carry Flag)
[#$F4FE] $66 <- ROR (Rotate Right)
[#$F500] $66 <- ROR
[#$F502] $66 <- ROR
[#$F504] $66 <- ROR
[#$F506] $66 <- ROR
[#$F508] $66 <- ROR
[#$F50A] $66 <- ROR
[#$F50C] $66 <- ROR
[#$F50E] $60 <- RTS (Return from subroutine)
[#$0FE5] $0 <- BRK (Break - This address should not be executed at)
[#$0FE6] $0 <- BRK (Break)
[#$0FE7] $0 <- BRK (Break)

So hopefully I can figure this one out and get mario and donkeykong running.

It seems unlikely that you have bugs in your RTS code because then nothing else would likely work. Are you handling mirroring correctly? Some memory areas on the NES are mirrored (this is common in most computer systems), meaning different addresses point to the same physical memory. A simple way to debug this problem would be to keep track of where each JSR is writing the return address to and then making sure it matches the address that RTS is reading from.

Yes I BELIEVE I have properly mirrored all addresses in both the 2A03 processor, as well as the NES PPU (for writes to the I/O addresses from the processor). What I'm going to do tonight is run nestress.nes, and follow the source code line for line to see if anything odd turns up. I know my RTS function itself is good -- I'm mainly leaning towards stack thrashing or something annoying like that.

Very jealous! Thanks for creating the blog, it's nice to see projects like this as they're coming along.

For your information, here is my mirroring logic for the CPU:

if ((newAddr >= 0x0800) && (newAddr < 0x2000)) {	newAddr %= 0x0800;} else if ((newAddr >= 0x2008) && (newAddr < 0x4000)) {	newAddr = 0x2000 + ((newAddr - 0x2008) % 0x08);}

I obviously do this for both reads and writes. And ALL reads/writes done on the processor goes through these methods (I don't index the memory array directly, the processor class doesn't even have access to it at all!).

YAY figured it out :D The stack is TOP DOWN, I was working the stack in reverse. I knew I was in the right area. ALL games are running without crashing now :) I guess it's on to the PPU tonight to get some awesome screenies up tomorrow.