Next Generation Emulation banner

RetroCopy v0.100b Released

28K views 179 replies 24 participants last post by  @ruantec  
#1 · (Edited)
RetroCopy : Accurate emulator for the Nintendo and Master System

RetroCopy is an attempt to emulate the Sega Master System and Nintendo Entertainment System at the cycle level. I believe it is the first attempt at a fully cycle accurate Master System emulator.

It also includes a custom OpenGL powered 3D interface which shows things like the gameboxes. It is currently only available for Windows, with 32bit and 64bit versions available. You can download it at the above website.



 
#6 ·
Thanks for the kind words guys! :)

Can you please explain more about cycle level and the difference with other methods.
Well the basic difference is that cycle accuracy is about as accurate as you can possibly emulate a system. Now there is a bit of a misconception with the concept of cycle accuracy since some emulators claim to be cycle accurate when maybe only one part of the emulator is. The kind of cycle accuracy I am talking about is the total system.

In the Master System for example there is a clock which runs at ~50MHz. Thankfully I don't need to emulate all the 50MHz (which would be slower) because all the main components run on a lesser ratio which still enables accurate emulation. I emulate the Master System at close to 11MHz, which is the video processors real speed, and the audio/Z80 run at almost 4MHz on a divisor that is a third of the VDP. So in the exact way that the real clock is driving all these components, RetroCopy is driven in the same manner, cycle for cycle.

Other emulators usually are instruction accurate, that is they emulate one instruction of one of the CPUs, and then perform various tasks depending upon how much time that one instruction took. Since an instruction is usually always multiple cycles long (in the Z80 case, some are over 20 cycles long), the amount of accuracy you can get is based on the average instruction cycle length. Some emulators have "hacks" if I could use that term without offending, to increase the accuracy at not much cost to speed, like adding delays where appropriate in the IO, etc. RetroCopy's aim is to be accurate down to every cycle, whereas an instruction accurate emulator could possibly only claim accuracy down to about 45 (system) cycles.

To give an overall assessment of the types of accuracy, RetroCopy could be used to replace real hardware if there were ways to physically connect a PC to the real master system. I'm not aware of any other emulator that would be capable of that but it shows how close to hardware the emulation is. I'm not concerned with running RetroCopy on old PCs which has allowed me to really target accuracy over everything else.

Another thing I want to mention is I say RetroCopy is "cycle accurate" but that is a misleading term everyone throws about. I know RetroCopy isn't yet accurate down to every cycle, but it is my aim to be cycle accurate. RetroCopy *CAN* be cycle accurate, which is I guess the biggest difference between it and most others. Also just because RetroCopy is very accurate doesn't mean something which is 50 times less accurate won't be able to play 99% of the games on a system. Something like RetroCopy is for the emulation purist that wants something to be extremely accurate to real machine.
 
#7 ·
Cycle accurate emulation seem to be the new big thing these days (what with bsnes being available too), and that's great. It's great that we've reached the point where we have hardware that can provide truely accurate emulation of older systems. While this is unrealistic for emulation of newer hardware (thus the approach taken by PCSX2 makes the most sense), this would be the best solution for something like the Master System or NES.

Awesome stuff.
 
#10 ·
Gotta love the TV-like output.

Only problem here is that the font of the user interface looks awful on the monitor's high resolution (so bad that the text is unreadable). I guess that's just ATi's bad OpenGL support for my card (Mobilty Radeon X600).

Nice work so far btw. :)
 
#11 ·
Gotta love the TV-like output.

Only problem here is that the font of the user interface looks awful on the monitor's high resolution (so bad that the text is unreadable). I guess that's just ATi's bad OpenGL support for my card (Mobilty Radeon X600).

Nice work so far btw. :)
Could you take a screenshot of how it looks. Might give an insight into the issue.

What is your monitors resolution?
 
#13 ·
Wow that is horrible. Does that card support NON POWER OF 2 textures? I'm guessing no. It looks like the filtering it's doing is very corruptive.

Have you tried forcing on disabling/enabling of AF/AA to see if it fixes anything? Maybe another driver would work too, but yeah that's definitely an OpenGL issue. ;)
 
#18 ·
I'm using linear filtering for the min and mag filter, which basically shouldn't use MIPMAPs. The GUI however uses "nearest" pixel because there is no filtering needed for it, everything is showed 1:1. There is no AF or anything of that nature though. To me it almost looks like it's using the "nearest" pixel of an inferior version of the texture, like a mipmap.
 
#20 ·
There you are :p
Maybe you missed the edit, but the GUI is nearest pixel for both. How textures are filtered depends upon their use in RetroCopy. Since the GUI textures are only displayed in a 1:1 fashion there is no need for filtering, in fact it's better quality without it (on most computers I should say :p)
 
#22 ·
I would say just try another driver, even reverting back to old ones. One of my NVIDIA OpenGL drivers would not let me debug my applications at all and it caused weird bugs in my programs that took me a while to recognize had nothing to do with something I had done. Changing back to an older driver fixed all my issues. Unfortunately OpenGL seems to be the redheaded stepchild on Windows that ATI/NVIDIA don't care so much about. Linux support for OpenGL on the same hardware seems much better.
 
#23 · (Edited)
Cycle accuracy is a load of horse **** and the perception that its required does more harm then good.

People should stop going :D everytime its mentioned because it just proves that they know NOTHING.

I would say just try another driver, even reverting back to old ones. One of my NVIDIA OpenGL drivers would not let me debug my applications at all and it caused weird bugs in my programs that took me a while to recognize had nothing to do with something I had done. Changing back to an older driver fixed all my issues. Unfortunately OpenGL seems to be the redheaded stepchild on Windows that ATI/NVIDIA don't care so much about. Linux support for OpenGL on the same hardware seems much better.
If nvidia's opengl ICD on windows has issues, report it. Nvidia does care, unlike ATI.
 
#25 ·
Would you?, because even though i have a clue to it. Most others don't, and just think its important to have for the games to run properly.

Actually, its the cause of a great deal of strife within the emulation community where people who decide that cycle accuracy is not required are labelled hacks and failure.

Cycle accuracy also has its faults, specifically where games run poorly on the original hardware, and specific improvements can be made within the Core timings to improve them.
 
#26 ·
I really have no idea what this means which is why I was asking. All I know about it is over at the MAME forums people from time to time ask why a certain game runs slow and the answer always has something to do with accuracy over playability. Is this cycle accuracy thing what they are talking about? I myself would sacrfice some speed to have the games look and sound exactly like the originals but I guess the question then is can that level of duplication be achived with something not "cycle accurate"? Being that I have no idea what is going on under the hood of these emulators I am unable to pick a side on my own and end up following the crowd.