Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - New SMS emulator: RetroCopy

Reply to topic Goto page Previous  1, 2, 3
Author Message
  • Joined: 21 Jul 2005
  • Posts: 412
  • Location: GBG
Reply with quote
Post Posted: Thu Jul 30, 2009 2:18 pm
PoorAussie wrote
What is the "broken version" you speak of?

The correct version actually has the SMB logo.
smb1.jpg (53.01 KB)
smb1.jpg

  View user's profile Send private message Visit poster's website
  • Joined: 26 Aug 2008
  • Posts: 292
  • Location: Australia
Reply with quote
Post Posted: Thu Jul 30, 2009 2:26 pm
FluBBa wrote
PoorAussie wrote
What is the "broken version" you speak of?

The correct version actually has the SMB logo.


Ah nice catch. Well RetroCopy seems to handle this particular version the same as other emulators so I should be safe.

How do we entice Maxim to write NESChecker? ;)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Thu Jul 30, 2009 4:36 pm
PoorAussie wrote
How do we entice Maxim to write NESChecker? ;)

1. Invent time machine
2. Go back to 1990 or so
3. Give me a NES (and money for games)

Actually, I looked into it back when I had time to look into things, and because NES games all have a file format and aren't just pure binary dumps (because of the PRG/CHR split), it was a real hassle to support, moreso because you can't lift the CRC32 out of the archive structure so you have to decompress on top of that. Also, multiple file formats = pain.
  View user's profile Send private message Visit poster's website
  • Joined: 11 Nov 2005
  • Posts: 52
Reply with quote
Post Posted: Thu Jul 30, 2009 10:13 pm
just found this thread. nice work.

i really like the boxwork idea. i've been considering a 2d version of this for my emulator for a while, but the logistics of getting high-res scans for EVERY possible game seemed too daunting.

i think a cool thing would be a simple skinning feature for the television and surrounding area since it looks like it will remain 2d. also, a straight-on angle would be nice too as an alternative.

again, good work. wish i could take take that much time away from work to do something fun like this!
  View user's profile Send private message
  • Joined: 12 Jul 1999
  • Posts: 891
Reply with quote
Post Posted: Sun Aug 02, 2009 4:29 pm
PoorAussie wrote
OpenCL for the actual emulation or some other thing like filters? I was using Opengl shaders for filters early on the project before throwing them away. I haven't looked too hard at OpenCL/etc but it's possible they could be used. I'm not sure if they would be suited for emulation, but maybe they would. Either way until the standard really hits it isn't something I want to look at too indepth.

Standard 2-3 year old CPUs are fine for what I do currently. When it comes to SNES/GENESIS a little bit more may be needed. Until the "2-3 year old CPU" can't emulate the things we need maybe OpenCL will be used more. I expect someone will throw out a test soon enough though.


I was thinking about for emulation (every other emulator already has filter effects). Everything I've read about it indicated that all DX10 cards are fully programmable massively parallel workhorses. Given that the GPU is for the most part largely unused in modern computers, OpenCL/CUDA looks like it has the potential to greatly accelerate many processor-intensive tasks... such as cycle-accurate emulators.

Also, I'm curious as to the need for a dual-core CPU. The SMS isn't really what you'd call a multiprocessor machine. Is this something for system stability, or do you have something fancy planned for it, like one core for the system emulator, the other for the rest of the program?

(sorry, I'm not really a programmer)
  View user's profile Send private message
  • Joined: 26 Aug 2008
  • Posts: 292
  • Location: Australia
Reply with quote
Post Posted: Sun Aug 02, 2009 10:39 pm
unfnknblvbl wrote
I was thinking about for emulation (every other emulator already has filter effects). Everything I've read about it indicated that all DX10 cards are fully programmable massively parallel workhorses. Given that the GPU is for the most part largely unused in modern computers, OpenCL/CUDA looks like it has the potential to greatly accelerate many processor-intensive tasks... such as cycle-accurate emulators.


Well it's hard to know if CUDA on current hardware will be any good for cycle accurate emulators. Someone is just going to have to go off and write one and see. ;) I wouldn't hold my breath though.

unfnknblvbl wrote
Also, I'm curious as to the need for a dual-core CPU. The SMS isn't really what you'd call a multiprocessor machine. Is this something for system stability, or do you have something fancy planned for it, like one core for the system emulator, the other for the rest of the program?


You don't _need_ a dual core CPU to use RetroCopy, it's just pretty much the recommended system. Some features which I haven't announced yet will require at least a dual core machine, so if you don't have one you won't be able to use everything in RetroCopy, but everything you can see in the videos and basic emulation will work "fine" on a single core, provided your single core is very fast.

RetroCopy is multicore aware and will fully use at least two cores. Basically I designed it such that the video+gui is rendered on one core, and the other core just handles the emulation.

Thread 1: GUI, Video effects, Sound output, input
Thread 2: Emulation

So if you don't have a multicore CPU, everything that happens will have to be done on a single thread, which means you lose valuable emulation processing capabilities. :) It also means video effects go on the core which has little happening on it so if your CPU can just barely run the emulation it may mean you can still run HQ2X or something like that.
  View user's profile Send private message Visit poster's website
  • Joined: 02 Aug 2009
  • Posts: 2
  • Location: The Desert
Reply with quote
Post Posted: Tue Aug 04, 2009 5:24 am
FluBBa wrote
What startup values/pattern are you using for RAM on the NES? Or are you just clearing it? (most of the time the broken version of SMB starts in the minus world if emulated correctly).


That doesn't effect the title screen displayed, does it? I had the title screen showing correctly in my video emulation, but during a few video core emulation changes/fixes, it doesn't build it out correctly anymore (haven't looked at it in a month).
  View user's profile Send private message Visit poster's website
  • Joined: 26 Aug 2008
  • Posts: 292
  • Location: Australia
Reply with quote
Post Posted: Tue Aug 04, 2009 1:28 pm
I have a 99% chance of releasing RetroCopy this Friday night for those that are following this. I've got nothing on my plate this week so it's straight sailing into release territory. It's amazing how many things just pop up that you don't think about until you're ready to release something though... I wanted to get it out last week but oh well.

Anyhow a friend and myself put together a light hearted and over adrenalized trailer I guess you could call it for the occasion.

  View user's profile Send private message Visit poster's website
  • Joined: 12 Jul 1999
  • Posts: 891
Reply with quote
Post Posted: Tue Aug 04, 2009 3:14 pm
Hrm. I'll be at work this Friday night. I look forward to seeing how well it runs (or doesn't) on my 900MHz eeePC =)
  View user's profile Send private message
  • Joined: 12 Jul 1999
  • Posts: 891
Reply with quote
Post Posted: Tue Aug 04, 2009 4:43 pm
if I may make a suggestion...

you're going with this new .GAME format for uh.. games, right?

Why then, does the filebrowser in all the screenshots and clips I've seen of RetroCopy display the filename and not the game's name?
Surely if you're going to all the trouble of combining the game file with the cover art and whatever else, you could add in an index file that specifies what the game's actually called, along with the format and region etc. right?

Something like...
<gameinfo>
   <format="SMS">
   <title="My Favourite Game">
   <year="1991">
   <region="EU">
   <input="control pad" "light phaser">
   <players="2">
   <game="./mfg.sms">
   <box="./mfg.png">
</gameinfo>


...of course, I apologise if I've skimmed over the part in this thread where you've already discussed this... =)

I really look forward to trying your emulator. I just recently got myself a Phenom II x4 CPU and then promptly realised I didn't actually do anything that required four cores! :D
  View user's profile Send private message
  • Joined: 06 Jan 2005
  • Posts: 89
  • Location: Namur (Wallonia)
Reply with quote
Post Posted: Tue Aug 04, 2009 7:32 pm
PoorAussie wrote
RetroCopy is multicore aware and will fully use at least two cores. Basically I designed it such that the video+gui is rendered on one core, and the other core just handles the emulation.

Thread 1: GUI, Video effects, Sound output, input
Thread 2: Emulation

So if you don't have a multicore CPU, everything that happens will have to be done on a single thread, which means you lose valuable emulation processing capabilities. :) It also means video effects go on the core which has little happening on it so if your CPU can just barely run the emulation it may mean you can still run HQ2X or something like that.


I think your emulator will probably interest high-tech fans, as the design is conceived with very high requested capabilities.

I need to precise that using 2 threads on single core systems is perfectly possible. blueMSX, one of the 2 best MSX emulators (with support for the pre-SMS machines), is designed with two threads that do about the same amount of work. One thread is doing the emulation part (including audio) and the other does video related tasks.

Of course, it requests more CPU resource when blueMSX emulates the TurboR machine (an hybride 8bit/16bit) and the video part can suffer (be slower) on older machines.

Actually, blueMSX can be runned on Pentium III 600MHz, but we recommend to have at least a Pentium or AMD Athlon 1.4 GHz.

I don't think the high requested capabilities are justified only by the cycle accuracy. blueMSX is indeed a very cycle accurate emulator. But if you want to add advanced features in an emulator, especially for the developers (for example the visualisation in real time of the audio channels or the VRAM contents), it will request more CPU resources. Probably, your emulator is conceived with this general approach in the mind. Anyway, open source or not, it is always interesting to see a new emulator with original features, even if there's already all a discussion about the rom format.

Benoît Delvaux
blueMSX co-developer
  View user's profile Send private message Visit poster's website
  • Joined: 26 Aug 2008
  • Posts: 292
  • Location: Australia
Reply with quote
Post Posted: Tue Aug 04, 2009 11:21 pm
mars2000you wrote
I need to precise that using 2 threads on single core systems is perfectly possible. blueMSX, one of the 2 best MSX emulators (with support for the pre-SMS machines), is designed with two threads that do about the same amount of work. One thread is doing the emulation part (including audio) and the other does video related tasks.


Well there are some issues with using two threads on a single core systems. But maybe you haven't run into them since you're not using a 3D API. In RetroCopy you get much better performance in single threaded mode ON a single core CPU if the video drivers are spin locking the video thread waiting for VSYNC. Basically the video thread takes away all the CPU time from the emulator thread leaving it a bit messy. If you have good video card drivers (ie something ATI based) it's not such a big concern though.

mars2000you wrote
I don't think the high requested capabilities are justified only by the cycle accuracy. blueMSX is indeed a very cycle accurate emulator.


Is it cycle accurate? The 2.5 source I read (which isn't the latest version granted) seemed to just be adding delays in the Z80 core. When I looked in the VDP core I couldn't really find what I thought would be cycle accurate stuff, but the video code is huge so maybe I missed it. What is the clock speed of the VDP?

So BlueMSX reads memory every 4 clocks depending upon the mode the VDP is in? I couldn't find this code, if you could point it out it would be interesting to me to compare your timings to mine, even though the TMSVDP is slightly different the SMS builds off its timing greatly it seems, plus the SMSVDP of course includes all the old TMS modes.

I'm not sure why the bluemsx VDP is so large though, I know BLUEMSX has multiple graphics chip but in comparison my cycle accurate VDP which supports the SMSVDP and most of its features (I don't have all the TMS modes in yet but they would only add a few more KB to my code) is only 30kb in size compared to 260kb in code size. My cycle accurate VDP is actually less size than my older line accurate VDP I had, which I found surprising.
  View user's profile Send private message Visit poster's website
  • Joined: 06 Jan 2005
  • Posts: 89
  • Location: Namur (Wallonia)
Reply with quote
Post Posted: Wed Aug 05, 2009 12:21 am
You can find the most recent code of blueMSX on our SourceForge page in SVN :

http://bluemsx.svn.sourceforge.net/viewvc/bluemsx/trunk/

(we have recently migrated from CVS to SVN).

The VDP code is so huge because the MSX2 Videochip is very complex and we have to support all his features to get the most complete emulation. It's especially important for some tricks used in demos, but also in some games, like screensplits.

We are pretty sure that blueMSX is cycle accurate because it works with 2 timers and we have tested it on many games/demos with some very technical aspects that require a very good timing to run correctly. The VDP, audio chips and other devices are synchronized to one timer and to reach this goal, some delays (variable following the Z80/R800 instructions) allow an almost perfect synchronisation between the VDP thread and the emulation thread.

blueMSX also has a unique timing model to synchronize the MSX time to PC time which is one reason why blueMSX runs more smooth as other MSX emulators sometimes do. We handle directly the RDTSC (Read Time Stamp Counter) instruction instead of relying on a Windows API for timing.
  View user's profile Send private message Visit poster's website
  • Joined: 26 Aug 2008
  • Posts: 292
  • Location: Australia
Reply with quote
Post Posted: Wed Aug 05, 2009 1:11 am
Hmm well I guess firstly I must state I doubt RetroCopy is "cycle accurate" yet, in regards to each cycle being the same emulated as the real system. It has the possibility though since all the components are emulated per cycle at their correct clock speeds. That is to say RetroCopy has control over every single cycle that is emulated. There is no "gap" at any stage where something happens over 5 cycles, or 10 cycles, etc. The VDP and CPU are run exactly like how they are physically, cycle by cycle, side by side, interacting on "virtual pins". RetroCopy takes it's approach from hardware really, which I thought was the best source to get inspiration on how to handle a 100% accurate emulator. I try and copy how the internal chips are designed physically to achieve this.

I guess what I want to know is if BlueMSX emulates the VDP at 10MHz. And if you're not running it at 10MHz how is it handling the ~170 memory reads per line? Because I'm not sure how BlueMSX can achieve cycle accuracy if it does not. At best you would simply get close. Maybe close is fine though for most software, even timing sensitive software, it certainly appears that way for most SMS software.

The reason I made my Z80 100% cycle accurate instead of doing what BlueMSX (and other emulators) has done is because I didn't want to rewrite it in the future. For instance it would appear BlueMSX would have to be rewritten to support proper BUSREQ timing (it latches last cycle of any M-cycle). I don't know if BUSREQ is used on the MSX though so it might not be a concern. That and I wanted to be able to stop at any cycle and be "accurate" as close as possible to a real system at that cycle. Seems to me if you do it any other way you are going to be introducing code which will later need to be rewritten.

That is a luxury of RetroCopy, I haven't needed to support the Pentium 3 500MHz and make compromises to do that, I am starting fresh and it seems like much less of a headache. :) That said it still takes a lot of engineering skill to pull off something like BlueMSX on slower PCs, so I'm not taking a swipe at the developers.
  View user's profile Send private message Visit poster's website
  • Joined: 26 Aug 2008
  • Posts: 292
  • Location: Australia
Reply with quote
Post Posted: Wed Aug 05, 2009 1:18 am
mars2000you wrote
We handle directly the RDTSC (Read Time Stamp Counter) instruction instead of relying on a Windows API for timing.


What problems did you hit relying upon the Windows API since I thought it interfaces with RDTSC when you use the QueryPerformanceCounter type functions?
  View user's profile Send private message Visit poster's website
  • Joined: 06 Jan 2005
  • Posts: 89
  • Location: Namur (Wallonia)
Reply with quote
Post Posted: Wed Aug 05, 2009 3:22 am
PoorAussie wrote
I guess what I want to know is if BlueMSX emulates the VDP at 10MHz. And if you're not running it at 10MHz how is it handling the ~170 memory reads per line? Because I'm not sure how BlueMSX can achieve cycle accuracy if it does not. At best you would simply get close. Maybe close is fine though for most software, even timing sensitive software, it certainly appears that way for most SMS software.


The blueMSX VDP runs at 20MHz (V9938 frequency). It is almost cycle accurate. The sprite emulation is not accurate (generated once per scan line), but the bg map rendering is. The VDP and Z80 run in 'bursts' and is not synced at every clock cycle. This is not at all required to be cycle accurate. What's important is to make sure the Z80 and VDP are in sync when they share data (reads / writes etc). One thing that isn't fully cycle accurate (+/- a few cycles) are when the VDP fetches memory from the bus, which may impact the accuracy on poorly written games (that don't delay enough between outs)
  View user's profile Send private message Visit poster's website
  • Joined: 06 Jan 2005
  • Posts: 89
  • Location: Namur (Wallonia)
Reply with quote
Post Posted: Wed Aug 05, 2009 4:30 am
PoorAussie wrote


What problems did you hit relying upon the Windows API since I thought it interfaces with RDTSC when you use the QueryPerformanceCounter type functions?


Actually, I need to correct my previous words. I thought that the emulator does not use an API, but, in fact, it's using the QueryPerformanceCounter API. By the way, when the first dual core PC's appeared, some AMD users reported speed problems and this API needed to be patched or updated to solve the problem. I guess it is now already an old story ! :)
  View user's profile Send private message Visit poster's website
  • Joined: 26 Aug 2008
  • Posts: 292
  • Location: Australia
Reply with quote
Post Posted: Wed Aug 05, 2009 4:37 am
Last edited by PoorAussie on Wed Aug 05, 2009 4:44 am; edited 1 time in total
mars2000you wrote
The blueMSX VDP runs at 20MHz (V9938 frequency). It is almost cycle accurate. The sprite emulation is not accurate (generated once per scan line), but the bg map rendering is.


Doesn't this contradict with your statement earlier that blueMSX is fully cycle accurate? Or what did you mean by that?

RetroCopy emulates the VDP pretty much like it is the VDP. In theory I could output an analog TV signal just like the original did or read from the real RAM chip by connecting the pins to the parallel port on the PC.

mars2000you wrote
The VDP and Z80 run in 'bursts' and is not synced at every clock cycle. This is not at all required to be cycle accurate. What's important is to make sure the Z80 and VDP are in sync when they share data (reads / writes etc).


Yep, if there is some performance gain to be had I can understand not having them sync at every cycle, it's probably a little faster. I think it would require kludges though to support different systems in this manner. If you connect them in cycle sync then you can treat them like real hardware more easily. Since blueMSX only supports the MSX this is something you can do that I cannot easily.

Like I've said previously, a Core2 @ 600MHz should be able to run my master system emulator at fullspeed and this is in what I call an unoptimized state. There is room for another 20% improvement. Syncing at every cycle isn't as costly as perhaps people think.

mars2000you wrote
One thing that isn't fully cycle accurate (+/- a few cycles) are when the VDP fetches memory from the bus, which may impact the accuracy on poorly written games (that don't delay enough between outs)


Well I've logged games which abuse the memory timing on the Master System and it's over 50. So in over 50 cases in current emulators data is getting written that perhaps shouldn't. I haven't noticed any visible artifacts yet though (most of the time it's just a single byte being written that shouldn't). It's hard to know for certain whether all these games have bugs or they are abusing some unknown aspect of the timing.

I guess the worrying thing if you don't emulate this is, not only are you not cycle accurate but games could be changing their behaviour, if only slightly, due to not properly emulating this effect.

I was thinking of adding support for the MSX to RetroCopy, but the fact it was a Japanese computer mostly and not a console bothered me a bit. But I already have all the pieces to successfully emulate the base console at a very high accuracy... maybe one day.
  View user's profile Send private message Visit poster's website
  • Joined: 26 Aug 2008
  • Posts: 292
  • Location: Australia
Reply with quote
Post Posted: Wed Aug 05, 2009 4:39 am
mars2000you wrote
By the way, when the first dual core PC's appeared, some AMD users reported speed problems and this API needed to be patched or updated to solve the problem. I guess it is now already an old story ! :)


Yeah thats true! I still set the affinity to a single core when doing these in case the CPU has a bug with the timers. I think there were two separate issues, that QueryPerformanceCounter was happening on two different cores between readings and the other was to do with AMD SpeedStep reducing the clockspeed and it affecting it.
  View user's profile Send private message Visit poster's website
  • Joined: 06 Jan 2005
  • Posts: 89
  • Location: Namur (Wallonia)
Reply with quote
Post Posted: Wed Aug 05, 2009 5:30 am
PoorAussie wrote


Doesn't this contradict with your statement earlier that blueMSX is fully cycle accurate? Or what did you mean by that?


I have spoken about "almost perfect accuracy", so it means that there are still some little things to improve and we'll do that if we think it's really required for the final result. In the case of the sprites, the way it works in blueMSX does not affect the final result, there's no visible difference with the result on a real machine.

Quote
.. If you connect them in cycle sync then you can treat them like real hardware more easily. Since blueMSX only supports the MSX this is something you can do that I cannot easily.


blueMSX supports also the SVI-318/328, the ColecoVision, the Sega SG-1000, SC-3000 and SF-7000 and we have plans to support ColecoAdam and SMS.

Quote

I was thinking of adding support for the MSX to RetroCopy, but the fact it was a Japanese computer mostly and not a console bothered me a bit. But I already have all the pieces to successfully emulate the base console at a very high accuracy... maybe one day.


It should be nice to have another MSX emulator, specially reserved for high-performance PC's. Actually you can see the MSX on two ways : a console with a keyboard OR a computer with so many good games ... The Sega SC-3000 and SF-7000 can also be seen like that, but they didn't have the same success as the MSX family.
  View user's profile Send private message Visit poster's website
  • Joined: 26 Aug 2008
  • Posts: 292
  • Location: Australia
Reply with quote
Post Posted: Wed Aug 05, 2009 12:05 pm
mars2000you wrote
I have spoken about "almost perfect accuracy", so it means that there are still some little things to improve and we'll do that if we think it's really required for the final result. In the case of the sprites, the way it works in blueMSX does not affect the final result, there's no visible difference with the result on a real machine.


We probably have different philosophies. Unless what I'm emulating is 100% accurate to the real machine I'm not happy! :) That's my goal anyhow. Virtual consoles that can be used as a direct replacement for physical machines, hook up virtual components to real ones and they work!

mars2000you wrote
It should be nice to have another MSX emulator, specially reserved for high-performance PC's. Actually you can see the MSX on two ways : a console with a keyboard OR a computer with so many good games ... The Sega SC-3000 and SF-7000 can also be seen like that, but they didn't have the same success as the MSX family.


I'm not aiming RetroCopy at anything in particular (outside of multicore machines for certain features). I believe RetroCopy is pretty efficient however, it's just if you want accuracy you need power! Since you can buy a motherboard, CPU and RAM for about $120 that will completely dominate RetroCopy it is never going to be an issue for me to tell people to upgrade if they want to use it. For every user that is holding onto their Duron 800MHz there is another user wondering why they bought their Phenom II. We have to give the latter a present for purchasing and the former a reason. Outside of emulation and games there is little reason to keep upgrading CPUs for deskop users, it's one of the last frontiers for the desktop in regards to why people are purchasing something faster. The last Steam survey had about 75% of it's ~20 million users on multicore systems and it's growing every month.

http://store.steampowered.com/hwsurvey/cpus/

My idea with RetroCopy was only to emulate consoles which were easy to use, so I'll probably get around to things like the SG1000 and COLECOVISION because they are plug and play. Old computers whilst they hold a spot in my heart just aren't easy enough for my liking. Though I've seen the C64 emulator on the IPHONE which got me thinking about that in a different light... so you can never say never.
  View user's profile Send private message Visit poster's website
  • Joined: 21 Jul 2005
  • Posts: 412
  • Location: GBG
Reply with quote
Post Posted: Wed Aug 05, 2009 12:50 pm
PoorAussie wrote
Since you can buy a motherboard, CPU and RAM for about $120 that will completely dominate RetroCopy it is never going to be an issue for me to tell people to upgrade if they want to use it.

Well, for that kind of money you can also get a ToToTek cart (and a SMS) ;)
  View user's profile Send private message Visit poster's website
viletim!
  • Guest
Reply with quote
Post Posted: Wed Aug 05, 2009 2:48 pm
FluBBa wrote
PoorAussie wrote
Since you can buy a motherboard, CPU and RAM for about $120 that will completely dominate RetroCopy it is never going to be an issue for me to tell people to upgrade if they want to use it.

Well, for that kind of money you can also get a ToToTek cart (and a SMS) ;)


And you'd have to hang on to that old PIII anyway 'cause the ToToTek cart needs a parallel port.
 
  • Joined: 24 Jun 2009
  • Posts: 4
  • Location: Netherlands
Reply with quote
Post Posted: Wed Aug 05, 2009 4:33 pm
PoorAussie wrote
FluBBa wrote
What startup values/pattern are you using for RAM on the NES? Or are you just clearing it? (most of the time the broken version of SMB starts in the minus world if emulated correctly).


Just clearing the RAM to zero. What is the "broken version" you speak of? I have noticed a few SMBs which have weird behaviour, but I thought they were hacks.


Correction: NES internal RAM should be set to $FF on power up. And yes, there are plenty of broken hacks around that work on nesticle but not on a NES.

PoorAussie your emulator looks great judging from the videos :) but, tell us one thing, how can you be so confident about its accuracy without having got a SMS (and some sort of flash cart) in order to test all those itty bitty details noone knows about?
I know from experience that writing an emulator based on technical documents and test roms is very different compared to one based on that plus your own research on the original hardware.

As for blueMSX, this is not an MSX forum :P and no it's not cycle accurate, the VDP emulator is basically a black box. Cycle accuracy doesn't merely imply that all games and demos look flawless from user POV.
  View user's profile Send private message Visit poster's website
  • Joined: 26 Aug 2008
  • Posts: 292
  • Location: Australia
Reply with quote
Post Posted: Wed Aug 05, 2009 11:07 pm
hap wrote
Correction: NES internal RAM should be set to $FF on power up. And yes, there are plenty of broken hacks around that work on nesticle but not on a NES.


Thanks for pointing that out. Do any real games take advantage of that? I had noticed that some SMB's that I had would either fail to work or be extremely dodgey. I pretty much compared my output to those of Nestopia and Nintendulator to get a good idea of what should be happening. The inside work done on the NES is much higher than on the SMS side, which is why their cycle accurate emulators came out first.

hap wrote
PoorAussie your emulator looks great judging from the videos :) but, tell us one thing, how can you be so confident about its accuracy without having got a SMS (and some sort of flash cart) in order to test all those itty bitty details noone knows about?
I know from experience that writing an emulator based on technical documents and test roms is very different compared to one based on that plus your own research on the original hardware.


Well there has been some work done by Flubba that no one has used yet in regards to interrupt accuracy, spritehits and a few other things in his tests. His work is like that of Quietust's early test ROMs.

There are some unknowns that I would like to figure out eventually, especially the exact timing of the VRAM accesses per line, and register latching (which ones are immediate, etc). I guess I can be confident about it's accuracy to some extent because when you emulate something on a cycle per cycle basis, copying the internal hardware on every one of those cycles (as much as I know and have reversed/guessed), that if it works you are pretty close to the original. We also know about 98% of how the VDP works, so that helps.

My approach to emulating these devices has been much more like hardware design than I have seen in other emulators. Even when it wasn't optimal to be combining registers/addresses like the real VDP does every clock that is what I did so that if they are updated it happens like the real machine. Others seem to like the approach of "well we'll cache that and then update the cache if it changes" and they take this approach to everything they touch. Leading to complicated code and bugs. Basically I want every cycle of the virtualVDP to comparable to the real one, so that in the future it may be possible to use the real one in RetroCopy or the virtual one on a real console.

You can get a pretty good idea of the mindset of the VDP engineers through reading their manuals and then also through going "how the hell does the VDP do this?". People know for instance that a tile is drawn at a certain spot, but I looked at it like "how is it doing this?" - "how is scrolling working internally?". Things like the first 8 pixels being blanked (not the MASK register which is separate) when hscrolling, why do people think the VDP does this? :) To most emulators it's like "meh, just overwrite those first 8 pixels with the border color". In my emulator it's 100% important to how scrolling works, similar to the real hardware ( I hope ). Also other things like the VDP reading sprites on pretty much every line and updating certain registers. In most emulators you could simulate this rather easily (I don't think any do it yet though), but in my emulator it's actually important to memory accesses as the sprite reads are taking away user writes.

You are right that I cannot prove beyond a 100% doubt some of the stuff I have guessed, I hope to in the future. The good thing is whatever I do have to change will easily be fixed in my emulator because what I have in there now must have to be extremely close to the real thing AND I have every cycle to "insert/update" any changes.

BTW I have designed many such "crazy optimized emulators" and helped many people with theirs, it's just now I am over that. We also have the luxury of the cheapest CPUs you can buy today being able to do what I want.

hap wrote
As for blueMSX, this is not an MSX forum :P and no it's not cycle accurate, the VDP emulator is basically a black box. Cycle accuracy doesn't merely imply that all games and demos look flawless from user POV.


Well that is what I thought when I looked at blueMSX a while ago, that I'm not sure how they are claiming cycle accuracy. To me it is like saying KEGA emulates the VDP at 10MHz because it draws 256 pixels per line. ;)

Until you are down in every cycle, or at the very least from the virtual machines point of view accurate at every cycle it can read, how do you claim such things? But oh well, it's marketing more than anything I guess. I have claimed such things like "cycle accurate" but it is misleading because I know I'm not accurate down to every cycle yet. I guess a better term to describe "this emulator is trying to be cycle accurate" or "this emulator has the capability to be cycle accurate" would be a bit better, but they only make sense to developers and enthusiasts I would say.

I think people like Flubba who write tests (and the guys who do it on the NES) are the ones who help greatly in the emulator community with accuracy. Because it gives end users a benchmark that they can see.
  View user's profile Send private message Visit poster's website
  • Joined: 24 Jun 2009
  • Posts: 4
  • Location: Netherlands
Reply with quote
Post Posted: Thu Aug 06, 2009 3:31 pm
Quote
Thanks for pointing that out. Do any real games take advantage of that?
"Minna no Taabou no Nakayoshi Daisakusen" doesn't work with RAM cleared to 0, and according to Disch, the random battle order in Final Fantasy 1 is not the same as on the NES if RAM isn't cleared with $FF. I consider it a programming error if a game relies on initial RAM contents though.

Quote
There are some unknowns that I would like to figure out eventually (...)
Get a SMS from ebay already. ;p Even I (still) have one, minus some games I sent to Bock 10yrs ago. :P

Don't get me wrong on blueMSX btw, I love it, and don't care about cycle accuracy if I just want to play those old games.
  View user's profile Send private message Visit poster's website
  • Joined: 26 Aug 2008
  • Posts: 292
  • Location: Australia
Reply with quote
Post Posted: Fri Aug 07, 2009 12:23 am
hap wrote
Get a SMS from ebay already. ;p Even I (still) have one, minus some games I sent to Bock 10yrs ago. :P


I will eventually.... it's hard to justify purchasing a SMS again to the "dragon lady" because over the years I must have bought about 10 and always end up giving them away when space gets tight. But I want to get two (VDP1/2) soon, and I have to source some sort of development device for it also which adds to the price.

hap wrote
Don't get me wrong on blueMSX btw, I love it, and don't care about cycle accuracy if I just want to play those old games.


For some reason I always prefer playing on the most accurate emulators provided they have the features I want, which are few and far between really. You either seem to get midlevel accuracy and great features or super accuracy and a "japan/usa" menu switch. I think Nestopia is probably the best at offering both, at least that I've seen. I guess the issue with emulators is if you can write something like BSnes/Nestopia/Meka/Fusion/Regen/etc you can also get paid a lot of money doing other things. So you have to rely on either free time for these people (which gets less and less the older they get) or hope that they stay in college to complete a triple degree.

Some people seem to only like playing on real consoles but I can't really stand the ergonomics of doing that anymore. I'd rather emulate it and use a joypad which won't give you carpal tunnel. ;)
  View user's profile Send private message Visit poster's website
unfunkistoolazytologin
  • Guest
Reply with quote
Post Posted: Fri Aug 07, 2009 2:23 pm
Soooo... Friday, huh? I was looking forward to giving my poor eeePC a heart attack, too! :D

Nah seriously though, take your time and be sure you're happy with it before a public release. =)
 
  • Joined: 26 Aug 2008
  • Posts: 292
  • Location: Australia
Reply with quote
Post Posted: Fri Aug 07, 2009 2:39 pm
Well in my timezone I'm a few minutes late but it's still Friday somewhere in the world... ;)

http://www.smspower.org/forums/viewtopic.php?t=11884
  View user's profile Send private message Visit poster's website
Reply to topic Goto page Previous  1, 2, 3



Back to the top of this page

Back to SMS Power!