Page 1 of 1
Cycles Per Second
Posted: Fri Dec 14, 2012 10:18 am
by MadDoc
I have just finished my 6502 core in Real Studio and am currently testing all of the opcodes.
My end game is to emulate the NES. One thing I'm not sure about is how many cycles the 6502 (I know, it was actually a Ricoh chip, not a stock 6502) the chip in the NES was capable of executing per second. I need to know this so that I can throttle how many executions per second my emulated chip performs because at the moment, I think it is performing 250,000 - 800,000 cycles per second.
Thanks in advance,
MadDoc
Re: Cycles Per Second
Posted: Fri Dec 14, 2012 1:03 pm
by Klaus2m5
In the 6502 the number of cyles per second is equal to the frequency of the oscillator used to drive the cpu. In a NES with 1.79 MHz the CPU executes 1,790,000 cyles per second.
What you really want is the number of cycles per instruction. These are defined per instruction and you can find them in the instruction set table published in datasheets, programming manuals or here:
http://www.6502.org/tutorials/6502opcodes.html (cycles under the TIM column)
Re: Cycles Per Second
Posted: Fri Dec 14, 2012 4:39 pm
by MadDoc
I should have been a bit more specific - my fault.
My opcode methods do already increment the number of cycles each opcode takes accurately depending on the address mode (varies between 2 and 7 cycles). My question should have read, how many of these cycles occur per second on the actual 6502? If it's 1.79 million then I have a lot of optimising to do because I think I'm only hitting 500,000 at the moment...
Re: Cycles Per Second
Posted: Fri Dec 14, 2012 7:12 pm
by GARTHWILSON
My question should have read, how many of these cycles occur per second on the actual 6502? If it's 1.79 million then I have a lot of optimising to do because I think I'm only hitting 500,000 at the moment...
I'm still not sure what your thinking is. The processor uses
all the cycles, although a few of them are for internal operations that have no bus activity. Depending on what you're doing, the average is about four clocks per instruction. If you're using a lot of indexing and indirects, it will be a little more, or OTOH if you have a lot of zero-page accesses without indirection it will average a little less than 4 clocks per instruction. If you have a 1.79MHz clock and you're executing 500,000 instructions per second, your average is 3.6 clocks per instruction, slighly better than the 4 that I mentioned.
I like to call them "clocks" instead of cycles though, because sometimes people coming in new from other processors think of an "instruction cycle" or "machine cycle" that's four or more clock pulses. On the 6502 they're the same thing.
Re: Cycles Per Second
Posted: Fri Dec 14, 2012 7:18 pm
by Arlet
@GARTH: MadDoc wants to know the clock frequency that the 6502 was running at in the NES. The answer is 1.79 MHz. The emulator currently runs at 500 kHz, so it needs serious optimizing.
Re: Cycles Per Second
Posted: Fri Dec 14, 2012 7:38 pm
by GARTHWILSON
<light goes on> Ah, ok. That makes sense.
Re: Cycles Per Second
Posted: Fri Dec 14, 2012 8:37 pm
by Klaus2m5
Oh, by the way, the 1.79 MHz is the NTSC version of the NES (Ricoh 2A03 cpu). The PAL version is 1.66 MHz (Ricoh 2A07 cpu).
There is no oscillator with that speed as I thought, but a master clock with a clock divider.
http://wiki.nesdev.com/w/index.php/Clock_rate
Re: Cycles Per Second
Posted: Fri Dec 14, 2012 11:31 pm
by whartung
500 kHz?
How is this being done? My naive implementation clocks in at 10.6M instructions/sec. That's not MHz, that's instructions. If we just swag 2.5 cycles per instruction, that's 25ishMHz.
Typically I'd think simulators would start faster and then slow down as they get more sophisticated.
Re: Cycles Per Second
Posted: Sat Dec 15, 2012 12:35 am
by halkun
500 kHz?
How is this being done? My naive implementation clocks in at 10.6M instructions/sec. That's not MHz, that's instructions. If we just swag 2.5 cycles per instruction, that's 25ishMHz.
Typically I'd think simulators would start faster and then slow down as they get more sophisticated.
My AVR version is running pretty swiftly too, and it's even broken
I think it has to do with the fact he's using
Real Studio which appears to be a "programming for those who hate programming" kind of solutions. (Or more of a "You can take my Visual Basic when you pry it from my cold, dead, hands" kind of programming philosophy.)
He might be hitting a limitation of the language itself.
Re: Cycles Per Second
Posted: Sat Dec 15, 2012 6:36 am
by BigEd
Ah, I'd taken Real Studio to be an IDE, but I see you're right - it's a language. So the nature of the compiler is going to be a factor, assuming it is a compiler. If it doesn't compile to native code, that would be an additional handicap.
(Let's not be insulting in our critiques, please)
Cheers
Ed
Re: Cycles Per Second
Posted: Sat Dec 15, 2012 4:24 pm
by halkun
Sorry, Didn't t mean to belittle the user. In a previous job I worked with a programmer who refused to get off of VB6 and go to .net
Kicking and screaming he went, going on about how Microsoft is destroying the language, and how they were turning their back on programmers. His biggest complaint? That Microsoft changed the Boolean value of "True" from -1 to 1 in vb.net, forcing him to have to rewrite his code from VB6. Whenever I see anything VB related, I get little chills.
On the flip side, Visual Basic (RealBasic, which is what OP is using, is a Visual Basic clone), is a great way to cut your teeth on beginning computer concepts. It's how *I* learned how to code for windows back in VB3. However, as fun is VB is, it should not be used for production code. It will cause massive problems. There are companies that used VB apps for their mission-critical operations, (I currently work for one), and found they can't go from 16 to 64 bit systems. Now every system in our field force is stuck with win7 machines with only 4GB of ram because going to 64-bit Win7 will cause half of our application suite to crash.
Just remember, the choices you make now impact how things go in the future...
I guess that goes for anything really.
Re: Cycles Per Second
Posted: Sat Dec 15, 2012 4:32 pm
by Dajgoro
Sorry, Didn't t mean to belittle the user. In a previous job I worked with a programmer who refused to get off of VB6 and go to .net
Kicking and screaming he went, going on about how Microsoft is destroying the language, and how they were turning their back on programmers. His biggest complaint? That Microsoft changed the Boolean value of "True" from -1 to 1 in vb.net, forcing him to have to rewrite his code from VB6. Whenever I see anything VB related, I get little chills.
On the flip side, Visual Basic (RealBasic, which is what OP is using, is a Visual Basic clone), is a great way to cut your teeth on beginning computer concepts. It's how *I* learned how to code for windows back in VB3. However, as fun is VB is, it should not be used for production code. It will cause massive problems. There are companies that used VB apps for their mission-critical operations, (I currently work for one), and found they can't go from 16 to 64 bit systems. Now every system in our field force is stuck with win7 machines with only 4GB of ram because going to 64-bit Win7 will cause half of our application suite to crash.
Just remember, the choices you make now impact how things go in the future...
I guess that goes for anything really.
O.T. Ah, I know the feeling, luckily I just moved from QBasic to VB6 when I realized that VB6 reached the end of the line, and that everything I learned on it is now useless, and that i must start over... The thing I loved most were the Inp and Out functions for the LPT port, so I could simply connect some diy contraption to my computer.
Re: Cycles Per Second
Posted: Mon Dec 17, 2012 12:33 pm
by MadDoc
Thanks everybody for the explanation. Yes, I was wondering how many clock cycles the CPU executes/sec - looks like it's 1.8 million.
I've managed to get the simulator to run at > 3 million cycles/second after compiling it (it was running at 500K in the IDE). Not ideal but faster than the original so it may still be possible to build a functioning emulator in Real Studio after all.
On a related note - Real Studio is not as simplistic as you might think. Obviously it's never going to be as quick as C but it's a pretty flexible and powerful language and I like the fact it compiles to Mac, Windows and Linux from a single code base.
I'm undertaking this project more as a "can it be done" project to see what Real Studio is capable of.