Newbie to emulation questions
Moderator: Moderators
-
- Posts: 345
- Joined: Fri Jul 29, 2005 3:40 pm
- Location: near chicago
i was going to do this. i kinda put that on hold for now. i was looking into different controller and keyboard input libs.
right now i have 2 threads, the nes core thread and the main thread for input. the main thread will set the nes controller variables when changed, then the nes core reads them. its even driven. not sure if this is a good way to code, but works for the time being.
matt
right now i have 2 threads, the nes core thread and the main thread for input. the main thread will set the nes controller variables when changed, then the nes core reads them. its even driven. not sure if this is a good way to code, but works for the time being.
matt
Are there any drawbacks to running one CPU instruction, then 3*(last instruction's cycles) PPU cycles?
Can anything other than CPU writes alter rendering?
Is there a benefit to synching the CPU to PPU cycles?
I don't plan to support MMC2/MMC4/MMC5 initially but what should I be building into the framework so in case I do later on, I don't burn my bridges?
Thanks!
Can anything other than CPU writes alter rendering?
Is there a benefit to synching the CPU to PPU cycles?
I don't plan to support MMC2/MMC4/MMC5 initially but what should I be building into the framework so in case I do later on, I don't burn my bridges?
Thanks!
Last edited by kyuusaku on Thu Sep 21, 2006 4:09 pm, edited 1 time in total.
-
- Posts: 345
- Joined: Fri Jul 29, 2005 3:40 pm
- Location: near chicago
i think you mean cpu cycle ? a cpu instruction is at least 2 cpu cycles
the emu would be more accurate that way. however that would probably cause alot of cache misses and extra funciton calls. this is how nintendulator works (quietust can comment more on his emu).
mine does the catch up method, in the cpu i count the cpu cycles and catch up the ppu to the cycle read. this works for now. i will try to improve it later.
matt
the emu would be more accurate that way. however that would probably cause alot of cache misses and extra funciton calls. this is how nintendulator works (quietust can comment more on his emu).
mine does the catch up method, in the cpu i count the cpu cycles and catch up the ppu to the cycle read. this works for now. i will try to improve it later.
matt
-
- Posts: 345
- Joined: Fri Jul 29, 2005 3:40 pm
- Location: near chicago
-
- Posts: 345
- Joined: Fri Jul 29, 2005 3:40 pm
- Location: near chicago
then i suggest start with the cpu. and the memory functions. and i would update the cpu clock cycles for each cpu cycle needed. get the cpu working.
i think there is a link at the bottom of the cpu page on the wiki, the new wiki.
mine is a double switch statement. i would also suggest this too, as there is less redunant code. you can keep all the addressing modes together and the keep all the instructions together
matt
i think there is a link at the bottom of the cpu page on the wiki, the new wiki.
mine is a double switch statement. i would also suggest this too, as there is less redunant code. you can keep all the addressing modes together and the keep all the instructions together
matt
New questions:
- Are the R,G,B, black background colors from the palette or different entirely? Will something other than $0,1,2,4 really damage the PPU? What do these bits do in monochrome mode? (conflicting information)
-Is it: color mode = background colors, monochrome = emphasis or the opposite or neither?
- I plan to render in real time, pixel by pixel. What would would be the best way for me then to implement a pattern table/nametable viewer? Should I decode the tiles beforehand (ie not render pixel by pixel) and copy them both to the screen buffer and viewer? Would pixel rendering to each be stupidly slow?
-What's the fastest way to fetch pixels?
pixel0 = *palette[((atthi & 0x80)>>4)|((attlo & 0x80)>>5)|((tilehi & 0x80)>>6)|((tilelo & 0x80)>>7)] ?
I notice some emulators use tables to merge bits, could someone please describe a table method?
Thanks
- Are the R,G,B, black background colors from the palette or different entirely? Will something other than $0,1,2,4 really damage the PPU? What do these bits do in monochrome mode? (conflicting information)
-Is it: color mode = background colors, monochrome = emphasis or the opposite or neither?
- I plan to render in real time, pixel by pixel. What would would be the best way for me then to implement a pattern table/nametable viewer? Should I decode the tiles beforehand (ie not render pixel by pixel) and copy them both to the screen buffer and viewer? Would pixel rendering to each be stupidly slow?
-What's the fastest way to fetch pixels?
pixel0 = *palette[((atthi & 0x80)>>4)|((attlo & 0x80)>>5)|((tilehi & 0x80)>>6)|((tilelo & 0x80)>>7)] ?
I notice some emulators use tables to merge bits, could someone please describe a table method?
Thanks
-
- Posts: 345
- Joined: Fri Jul 29, 2005 3:40 pm
- Location: near chicago