Dreamcast Emulator For Pandora?

[Exophase]

Anyway 5x is certainly not enough, unless you sacrifice accuracy and the HW is trivial.

That's entirely variable depending on what you're emulating. I don't know what you mean by "trivial", but "powerful" does not necessarily mean "needs more overhead to emulate", and I take it that by trivial you mean not powerful.

Even 12x is not enough. Look at the Amiga with its a 68k @ 7.x MHz. Even though the ARM of the GP2X has probably 50x more power (taking into account 1 68k instruction was at least 4 cycles), it's a pain to emulate because its hardware was powerful and used to a point where if you are not cycle accurate enough some programs will never work.

I don't think anyone took "Nx power" to mean multiply one CPU MIPS rate vs another (although in this case you're not accounting for cache misses on the GP2X, but we'll ignore that). On the other hand, your example doesn't really demonstrate anything because you have no idea how efficient that Amiga emulator is, or isn't. There actually are techniques to provide cycle accuracy without interleaving everything on a near or per-cycle level, but this is what a lot of emulators do anyway.

Actually, I'm kinda tired of the opinion of many technically oriented people, some emulator authors themselves, who have a major obsession with accuracy (what I mean is emulating things beyond the point that any software would require) and insist that efficiency in an emulator is nothing more than a sacrifice of accuracy, so trying to optimize is irrelevant to them.

I also don't agree with you that doing a CPU recompiler is the "easy" part, and I don't think the PCSX2 team would either (judging by the blog posts regarding this alone). Sure, you can do a simple one, but since it's an optimization in the first place, how little should you be satisfied with? Recompilers are a bottomless pit of analysis, optimization, and run time support (self modifying code...)

I kinda hope that people, at least here, could stop saying whatever multiplier is necessary for emulation altogether. It's bad enough that it has no real meaning to begin with, but people basically pick whatever number is convenient for the point they're trying to make anyway.

 

[Prophet]

I kinda hope that people, at least here, could stop saying whatever multiplier is necessary for emulation altogether. It's bad enough that it has no real meaning to begin with, but people basically pick whatever number is convenient for the point they're trying to make anyway.

True.

Long ago I used to subscribe to the general conventions (back in the day "10x" was bandied about, then later 3 - 5x usually referring to CPU speed), but I've seen them shattered so many times now.

gpSP is a great example - you did brilliant work there. Prior to that, I never expected to see GBA emulated full speed at zero frame skips on the PSP.

And I'm reminded of UltraHLE, which had Zelda and Mario going full speed back on 300Mhz Pentium 2's!

So who knows what's truly possible until someone talented enough digs into the hardware and finds out?

I still doubt Dreamcast emulation... but as I said before, I'm happy to be proven wrong.

 

[ldesnogu]

I don't think I said, explicitly or not, that any multiplier would make sense.

My point is very simple: if you want an emulator for a rather complex hardware that will be able to run *any* software for the emulated platform you will pay a high price. If you just want to run a subset of what the platform is able to run, then yes you can take some shortcuts that will improve speed tremendously, while still providing the user a good experience.

But then your emulator will not run some code that some user will want. If you don't believe some cycle accuracy is needed, I invite you to run some Atari ST and Amiga demos on simple emulators. For instance, on the Atari if you are not able to say at what time during the screen redraw some HW registers were written you will miss fullscreen hacks. Of course you will be able to provide some workaround to emulate this, but if you had not provided any way in your CPU emulator to count cycles accurately enough, you will have to rewrite it, which might prove a huge task if you are using dynamic recompilation.

UltraHLE is probably a good example: it only emulates some games, not all, due to its design. I agree this can satisfy the majority of users, but not all of them.

As far as CPU emulation is concerned, I surely was not explicit enough What I meant is that one can get instruction set emulation rather quickly in place. But then of course making that fast will be a never ending task, which can become as complex as writing an optimizing compiler. I have been writing CPU emulators for more than 10 years, simulating from 8 bit (6809) to 32 bit out of order cores, using from SPARC assembly language to higher-level proprietary language, with varying degrees of accuracy, professionally or not, so I feel inclined I have the right to think what is easier

You may dismiss my thoughts as non applicable or even as bullshit, but it's just we have differing point of views

 

[Exophase]

I don't think I said, explicitly or not, that any multiplier would make sense.

Sorry, I wasn't addressing you on this one.

My point is very simple: if you want an emulator for a rather complex hardware that will be able to run *any* software for the emulated platform you will pay a high price. If you just want to run a subset of what the platform is able to run, then yes you can take some shortcuts that will improve speed tremendously, while still providing the user a good experience.

But then your emulator will not run some code that some user will want. If you don't believe some cycle accuracy is needed, I invite you to run some Atari ST and Amiga demos on simple emulators. For instance, on the Atari if you are not able to say at what time during the screen redraw some HW registers were written you will miss fullscreen hacks. Of course you will be able to provide some workaround to emulate this, but if you had not provided any way in your CPU emulator to count cycles accurately enough, you will have to rewrite it, which might prove a huge task if you are using dynamic recompilation.

UltraHLE is probably a good example: it only emulates some games, not all, due to its design. I agree this can satisfy the majority of users, but not all of them.

What you're saying is more of a broad generalization or rule of thumb than a matter of fact. I see basically three problems with it:

1) Accuracy and compatibility are not the same thing. There are platforms where not a single piece of software ever written will rely on cycle accurate emulation of all components (especially ones where the software was created to be ran within varying setups to begin with such as PC). This is more true the more complex and difficult to predict the CPUs in question become. More modern software is also developed within sandboxes that helps prevent it from relying on buggy behavior. There are many "illegal" states that an emulator may not need to worry about (such as say, unaligned accesses in a PS1 emulator) and sometimes even entire ranges of instructions that aren't ever used, or subtle CPU bugs or undefined behavior that doesn't need to be reproduced. No PS1 emulators are not cycle accurate in the accepted sense, but their compatibility is within margin of error where you don't know if doing so would improve a single game.

I could basically say the same thing to you about GBA, PS1, N64, etc (basically, anything much newer that would need more resources when emulating now) emulation. Of course cycle accuracy is needed sometimes, but it isn't always.

2) Cycle accuracy does not necessarily mean a "high price." As I mentioned, you can either log or catch up in many cases, rather than interleaving operations. It also depends on how many components are in the platform. You used Amiga and Atari ST as an example, but not every platform has a programmable blitter.

3) There's no reason why an emulator has to implement things in only one way. This can often be done without actually detecting software on a case per case basis.

In UltraHLE's case, the design of the emulator was more because they didn't have access to documentation than because it was done for speed. Almost every emulator since then has used HLE for the RSP and the compatibility has gotten relatively high. For the few cases that use custom microcode an LLE implementation could easily be fallen back up on (see point 3).

As far as CPU emulation is concerned, I surely was not explicit enough What I meant is that one can get instruction set emulation rather quickly in place. But then of course making that fast will be a never ending task, which can become as complex as writing an optimizing compiler. I have been writing CPU emulators for more than 10 years, simulating from 8 bit (6809) to 32 bit out of order cores, using from SPARC assembly language to higher-level proprietary language, with varying degrees of accuracy, professionally or not, so I feel inclined I have the right to think what is easier

You may dismiss my thoughts as non applicable or even as bullshit, but it's just we have differing point of views

You said dynamic recompilation, not just CPU emulation. Writing a naive interpreter is easy if you know how the CPU works. Writing one in assembly language doesn't necessarily make this harder. Writing a more efficient one is harder, and writing a recompiler is harder still. Maybe to you writing a commercial grade emulator for an out of order core is "the easy part", but if you weren't writing it for cycle accuracy then that complexity isn't really relevant, and if you were then I doubt you were writing a recompiler. Naturally, I'd like to have an idea of what recompilers you've written for what platforms (to what hosts).

 

[ldesnogu]

Oh I see why we don't agree: you took my original statement that CPU emulation was the easy part, as writing a dynarec is easy.
That's not what I meant, and my previous answer made it clear when I said that this can be made as complex as one wants

I agree on all the points you made (except that if your GBA emulator is able to run ARMWrestler emulator checker, then you have implemented at least one UNPREDICTABLE behaviour ).

But I still stand to my claim: not all emulators fit everyone needs.

I will give a simple example: I applied static recompilation to an Atari ST program; I did that to see what could be gained. The end result was a program more than a thousand faster than the original Atari when run on an AMD 3500+. But my "emulator" will only run *one* ST program

Now take Aranym (a dynarec) for Atari, it doesn't run any demo (at least that's my understanding).

And then you have Hatari which runs many (most?) demos.

EDIT: I did not develop any dynarec from scratch, but played with many different ones both as a user and as a hacker.

 

[Classic Team]

To the point, I don't think it's gonna happen. If it ever does, the speeds will be so tarable you'll never use the emulator agian. (maybe 5 - 10 FPS, if your lucky. ) Be happy your getting better PSX emulation and N64 emulation. That... or wait for the NEXT gen Pandora to come out. >_<

 

[Exophase]

Oh I see why we don't agree: you took my original statement that CPU emulation was the easy part, as writing a dynarec is easy.
That's not what I meant, and my previous answer made it clear when I said that this can be made as complex as one wants

Oh, okay, then I guess we agree ;D

I agree on all the points you made (except that if your GBA emulator is able to run ARMWrestler emulator checker, then you have implemented at least one UNPREDICTABLE behaviour ).

Which behavior? gpSP passes ARMWrestler fine.

But I still stand to my claim: not all emulators fit everyone needs.

Of course. Some users will even prefer more accuracy so that the emulator is a good gauge of speed or helps them bugtest more against the real machine. Emulators are usually more permissive than the real hardware; this isn't a problem for working software but for broken software.. Fortunately, handheld devices really don't ever have to be useful as homebrew development aids.

I will give a simple example: I applied static recompilation to an Atari ST program; I did that to see what could be gained. The end result was a program more than a thousand faster than the original Atari when run on an AMD 3500+. But my "emulator" will only run *one* ST program

I've actually never been a strong supporter of static recompilation for the inherent problems it has. I'd be very interested in seeing your code though, if that's possible. Was the ST program that it runs written specifically for it?

Now take Aranym (a dynarec) for Atari, it doesn't run any demo (at least that's my understanding).

I've never heard of it, but I'll see what information I can find. Naturally, dynamic recompilation in its most typical, pure form is not good for older machines (and usually not nearly as useful either). I wouldn't implement a straight dynarec in my PC-Engine emulator, although I desperately want to implement a hybrid one that falls back on the interpreter for providing the proper block cycle granularity (and executing code in RAM to some extent, perhaps). Of course, we both know that the more a CPU needs cycle accuracy the less it probably needs a dynarec for performance reasons anyway, and the other components in the platform will tend to demand more to emulate.

And then you have Hatari which runs many (most?) demos.

Is this a run of the mill interpreter? I'll have to look at it too.

You'll have to excuse my attitude against what I've seen as kind of an accuracy obsession amongst many these days, let me try to explain where I'm coming from a little more...

Naturally there's a huge difference between an emulator that runs only a small fraction of software and one that runs over 90%. Both could be useful, but most will not settle for the former. My problem is that accuracy has basically been idealized to the point where to many an emulator with 95% compatibility is considered trash, even if the games it doesn't play are ones no one cares about. Or if it only has very minor glitches in a few games (like a junk scanline at the top or bottom). I constantly see a push to make a "more accurate" emulator for some platform. I suppose that this is done more these days because really the platforms have been emulated well ages ago, and you can afford more now to write a slow emulator.

It really goes along with a trend in general in programming, where efficiency is ignored because it cannot be noticed on the average user's machine anymore (to an extent), and instead other things are praised. Sometimes there are really no compatibility problems at all with existing emulators, and attempts at "accuracy" are merely praised for being something new, rather than addressing what problems the original emulator might actually have.

In the mean time, open source emulators caring less and less about efficiency has meant that a lot of code has had to be rewritten and rethought when ported to handhelds, if not abandoned for new emulators entirely. Handhelds will continue to grow more powerful, but efficiency for the sake of battery life will always be important.

At any rate, I don't really like the connotation that just because an emulator is faster it necessarily must be less compatible or even accurate than the competition, or that it must be. Another emu author once said about gpSP in response to a compatibility question someone had, that because of how gpSP is written it won't run some games. This really isn't true (and it was an assumption he made), and I find it rather insulting, as it seems to suggest that the only way higher performance can be achieved is by reducing accuracy, rather than thinking of more clever ways to write the code. It's probably the sentiments from the opposite side that prompts this - emulator authors that insist that their slow emulators must be as slow as they are due to high accuracy (byuu once suggested that BSNES could not be made 2x faster while retaining the same accuracy - I've seen enough of the source code to think that it very well probably could be).

 

[javaJake]

I kinda hope that people, at least here, could stop saying whatever multiplier is necessary for emulation altogether. It's bad enough that it has no real meaning to begin with, but people basically pick whatever number is convenient for the point they're trying to make anyway.

Alright, my mistake. Sorry about that.

 

[IcantDeleteThisAccount]

I personally think Craig opinion is the one that makes the most sense. I don't expect full speed Dreamcast emulation but, I can see dreamcast emulation being possible but the code like the psx4gp2x would have to be highly optimized in order to get anything that is relatively playable. Lets just leave it at that and call it a day folks. If some one wants to tackle the project people will help you best they can. Other then that lets stop the arguing. I gotta play my dreamcast today because of you people now though.. getting nostalgic.

 

[Svartalf]

http://en.wikipedia.org/wiki/Dreamcast

QUOTE
CLX2, 7.0 Mil polygons/second peak performance, supports Trilinear filtering. Actual maximum in game performance (with full textures, lighting, gameplay, etc.) of over 5 Mil polygons/second.

Brutal GPU. I doubt this OMAP can emulate that.


Heh... Does ANYONE read the specs? No.

http://focus.ti.com/docs/prod/folders/print/omap3530.html

QUOTE
2D/3D Graphics Accelerator (OMAP3530 Device Only)

* Tile Based Architecture delivering 10 MPoly/sec
* Universal Scalable Shader Engine: Multi-threaded Engine Incorporating Pixel and Vertex Shader Functionality
* Industry Standard API Support: OpenGLES 1.1 and 2.0, OpenVG1.0 and Direct3D Mobile
* Fine Grained Task Switching, Load Balancing, and Power Management



Heh...

The GPU's performance isn't the snag.
The CPU's performance might be an issue.

But the lack of proper programming information for the original PowerVR will be the thing that dooms any effort to get an emu for Dreamcast- on any platform you care to name. Without it, you don't have a way to make the mappings for the register calls, etc. to your platform's 3D framework.

 

[Exophase]

But the lack of proper programming information for the original PowerVR will be the thing that dooms any effort to get an emu for Dreamcast- on any platform you care to name. Without it, you don't have a way to make the mappings for the register calls, etc. to your platform's 3D framework.

Funny, Dreamcast emulators are doing pretty well for doomed projects. I think the hardware features in PowerVR (especially order independent translucency) is hurting them more than lack of understanding of how the hardware works.

 

[Chip]

I'm concerned that all the technical discussion might be muddying the waters for some of the new members. I'd just like to reiterate that the final answer to the big question at hand is still "No."

There will never be a Dreamcast emulator for Pandora which will run commercial games in any playable fashion. No matter what fancy programming tricks you pull out, no matter how long you "optimize" the code, no matter if we all got together, held hands, and wished real hard.

I just want that to be perfectly clear.

 

[IcantDeleteThisAccount]

I'm concerned that all the technical discussion might be muddying the waters for some of the new members. I'd just like to reiterate that the final answer to the big question at hand is still "No."

There will never be a Dreamcast emulator for Pandora which will run commercial games in any playable fashion. No matter what fancy programming tricks you pull out, no matter how long you "optimize" the code, no matter if we all got together, held hands, and wished real hard.

I just want that to be perfectly clear.



My mommy told me dreams can come true!!!

 

[Svartalf]

Funny, Dreamcast emulators are doing pretty well for doomed projects. I think the hardware features in PowerVR (especially order independent translucency) is hurting them more than lack of understanding of how the hardware works.

Can they drive the 3D portions of the chip like Shenmue I and II could? If not, you're not talking the same class of "works" that I'm talking about. If I remember correctly, they didn't have a handle on 3D with the emus at this point. Framebuffer support doesn't count.

I'm concerned that all the technical discussion might be muddying the waters for some of the new members. I'd just like to reiterate that the final answer to the big question at hand is still "No."

Now, considering that I just pointed out a SOLID technical reason why it's probably going to be a "No", why did you feel the need to do that?

QUOTE

There will never be a Dreamcast emulator for Pandora which will run commercial games in any playable fashion. No matter what fancy programming tricks you pull out, no matter how long you "optimize" the code, no matter if we all got together, held hands, and wished real hard.



Brilliant question: Is this because you don't believe that it's technologically possible (it doesn't have what it takes) or that it's not logistically possible (not enough of the right kind of bright minds available to do the work...)? If it's not one of the two, what would your reasoning for it to be that you feel the need to shoot it down the way you are right now (It's a technical discussion, probably ought to be moved elsewhere- but it's not a "It will happen if we wish real hard" discussion from what I understood reading things.)

 

[Exophase]

Funny, Dreamcast emulators are doing pretty well for doomed projects. I think the hardware features in PowerVR (especially order independent translucency) is hurting them more than lack of understanding of how the hardware works.

Can they drive the 3D portions of the chip like Shenmue I and II could? If not, you're not talking the same class of "works" that I'm talking about. If I remember correctly, they didn't have a handle on 3D with the emus at this point. Framebuffer support doesn't count.


They definitely have a "handle" on 3D and are emulating far more than just framebuffer support. Yes, there are glitches, but like I was saying that has more to do with the differences in architecture than a lack of understanding of how they work.

I stole this off of an ngemu post and uploaded it to my own space so you could view it without logging in there:

http://exophase.devzero.co.uk/Makaron_i686...00-04-40-35.jpg

That good enough for "works"?

Brilliant question: Is this because you don't believe that it's technologically possible (it doesn't have what it takes) or that it's not logistically possible (not enough of the right kind of bright minds available to do the work...)? If it's not one of the two, what would your reasoning for it to be that you feel the need to shoot it down the way you are right now (It's a technical discussion, probably ought to be moved elsewhere- but it's not a "It will happen if we wish real hard" discussion from what I understood reading things.)

He made it very clear that he believes no amount of programming skill would make it possible.

 

[TheLonelyGod]

We already know about speed. It will run like shit and will probably never be seriously attempted for that reason. Any of the people with their heads in the clouds saying 'YOU CAN EMULATE A PS3 IF YOU JUST BELIEVE'!! are absolutely full of it.

or you have a computer from the future and a hell of time to code

 

[Svartalf]

They definitely have a "handle" on 3D and are emulating far more than just framebuffer support. Yes, there are glitches, but like I was saying that has more to do with the differences in architecture than a lack of understanding of how they work.

I stole this off of an ngemu post and uploaded it to my own space so you could view it without logging in there:

http://exophase.devzero.co.uk/Makaron_i686...00-04-40-35.jpg

That good enough for "works"?



Whoo... I'll reserve my full judgment until I see it with my own two eyes (Any way I could be connected up
with a copy of the emu that made that screenshot? ) If so, that's mighty impressive. It would remain to be seen if there's enough cycles left on the CPU after the dynrec core and other pieces dealt with everything. If there's a lot of overhead present in the redirector for the PowerVR chip, it's going to kill the whole premise as dead as if you didn't have half of what it appears they all have now.

He made it very clear that he believes no amount of programming skill would make it possible.

I was trying to elicit what his grounds for those beliefs were...

 

[Chip]

Now, considering that I just pointed out a SOLID technical reason why it's probably going to be a "No", why did you feel the need to do that?

Because there are several hundred new forum members who have no idea what your post means. All some people see is four pages of complicated discussion about the technical details of DC emulation, and I assure you some of them will take that to mean "It's totally going to happen". I'm not trying to tell the people having the discussion anything they don't already know.

QUOTE
Brilliant question: Is this because you don't believe that it's technologically possible (it doesn't have what it takes) or that it's not logistically possible (not enough of the right kind of bright minds available to do the work...)?


Both. I think playable DC emulation is beyond the capabilities of the OMAP3530 hardware. Furthermore, even if the hardware could just barely squeak it out with some really perfect code, it would take a team of experts paid to work on it full time, in order to get perfect code. That's never going to happen. It is easier to just outright deny the possibility then to admit an infinitely improbable possibility.

Take my word on it - This question will come up again. Probably several times before actual launch. If I seem overly blunt or negative, it is to at least try to cut down on the "I saw somewhere that DC emulation was possible. When are we getting that? Because that's the whole reason I bought a Pandora." We're already seeing it with N64 emulation. Someone mentioned that it might be possible down the line, and now half the board assumes it is a given.

 

[Svartalf]

Take my word on it - This question will come up again. Probably several times before actual launch. If I seem overly blunt or negative, it is to at least try to cut down on the "I saw somewhere that DC emulation was possible. When are we getting that? Because that's the whole reason I bought a Pandora." We're already seeing it with N64 emulation. Someone mentioned that it might be possible down the line, and now half the board assumes it is a given.



Fair enough...

 

[Game_over]

This discussion ended gently.