Freedo Gp2x

[Rivroner]

Good Thank you!

What do you think about performance? Maybe midspeed?

In my PC at 1.99ghz i cannot get fullspeed in Another World for example (50 fps or so).

Thank you.

 

[Squidge]

2nd core == ARM60 emulator -- loads and modifies the code for ARM60 (takes into account R15 usage as operand) for direct execution. replaces hardware access with unique SWI. SWI handler besides handling 3DO SWI calls, recognizez HW access SWI and directs them to 1st core.



I assume by this you will be handling all i/o, ram, etc via swi calls - will that not be a little slow having to context switch for every ram read or write? (and then having to decode the instruction to find out what to do)

Would have though it would be quicker to use the MMU to map stuff into physical ram.

But... it's your baby and you seem to know what your doing, so I'll let you get on with it

 

[skiffex]

There's no linux running, thus my own context switch, optimized for this emu. don't forget that 3do uses SWI calls as well, so i've merely added my own handler. Now, ARM60 was running @ 12mips, while ARM9 runs @200+ -- enough overhead to do anything i want, even slow it down by timer
and mmu doesn't give me any advantage, since 3do doesn't have it and all space is linear.

 

[zodttd]

I learned a good amount from Admin@FreeDO. He definitely seems to have a grasp over what he's doing. Looking forward to the binary.

 

[kevcal]

Well if zodttd's thinking that, then I think we can take this development as excellent news
Hope you managed to eke out a bit of info on the secret (NDAed) hardware..

 

[Squidge]

Well, the MMU would mean you didn't have to change code to SWI calls, you could leave it alone (and not worry about accidentally mis-interpreting data as code), but if you have already designed that part, then it's probably easier to just think of it as a future optimisation technique

Feel free to send me a PM if you want to discuss anything - I have the NDA'd ME docs that you can download from there developer website (no idea if that would be enough, but I would assume so, otherwise it would be a little pointless!).

 

[Exophase]

This is all pretty interesting. I'm going to assume that 3DO games are written at a high level, especially if they're using SWIs for all hardware access. This isn't very surprising based on what I've heard about it. If people were using devkits on Macs then the code was probably pretty portable aside from the syscall interface, which of course would be provided.

So you probably won't have to worry about caching issues, very precise timing, etc; the things that make virtualization difficult or impossible. I will also assume that the games run in user mode, the other issue that makes virtualization not really work (basically, all of these things apply to GBA emulation and is why virtualization will never be a straightforward solution for it, not without any compatability anyway).

Is anything really being changed to SWI calls? It sounds like SWI's are just being remapped to different SWIs. If the code is really pretty high level then the hardware should never be accessed directly with memory mapped I/O, at least not in the user's code. If it is then how can it be replaced with SWIs, aside from replacing every memory access? You can't determine what range a memory access is going to hit all of the time (and even for the times you can, it can be a lot of analysis. Even just doing constant propogation is kind of a pain).

Questions:
If you're running the code directly then why do you have to modify references to R15? It should mean that the code is being ran in the same place too. If it isn't then you aren't running the code directly, you're recompiling it. That comes with the various prices of needing scratch registers, needing to handle indirect branches with lookups, etc.

So what are you patching R15 to?

Is the code even aware of any devices? Does it set up timers in an abstract way, for instance? If the timers are of the nature "make this callback happen ever N microseconds" then you should be able to easily fake that without providing fine granularity most of the time (IE, without having to interrupt your code a lot)

What Squidge says about keeping Linux seems to make enough sense. You can hack MMU, and there's no reason why you have to map SWI calls to SWI calls - you can map them to function calls that perform the same thing. In fact, if the code is very high level, in whatever object code format, then shouldn't you even be able to dynamically link it to whereever you want, without even having to worry about the MMU? I might have a bad idea of exactly what this code is like, but I expect it to be more like relatively abstract code for a modern OS (Windows/Linux) than code for a typical game platform of that era.

 

[Squidge]

Well, another 4 weeks has passed, any news Jaguarandine?

 

[Jaguarandine]

A couple weeks ago Admin@FreeDO was willing to talk with Zodttd about the issues he was having; not sure if they ever had that conversation. I think Zod is really busy lately.

I'll try and get an update on FreeDO GP2X sometime next week.

 

[zodttd]

I'm pretty busy, true. But I'd like to see how this emulator is progressing. An alpha would be fun of course.

 

[Exophase]

I wanna talk to the guy too. :B

 

[saehn]

Here's a list of some of the top 3DO games in the meantime:

http://www.gamespot.com/games.html?type=ga...amp;platform=15

Had to look it up, I wasn't familiar with this console at all. Seems that many other people weren't. I guess that was the problem.

If this works out, that would bring some more solid gaming titles to the GP2X. Cool news, good luck.

 

[Jaguarandine]

saehn: A lot of the games in that list are great, like Super Turbo, or Need For Speed. However, others like Doom or Jurassic Park are terrible. AFAIK, GameSpot has never officially rated any 3DO games at all. The link in this thread that points to the older thread (in the first post) has some good info. Here's another great 3DO site:
http://cdinteractive.co.uk/3do/forum/index.php

Edit: Almost forgot the main reason I was bumping this thread! Admin@FreeDO says the emulator progress is going really well. Actually, he believes it's more of simulator than an emulator at this point.
One of the main problems with the PC port of FreeDO was the sound. Admin says that this issue has actually been fixed in the GP2X port.

 

[b._.o._.b]

Edit: Almost forgot the main reason I was bumping this thread! Admin@FreeDO says the emulator progress is going really well. Actually, he believes it's more of simulator than an emulator at this point.
One of the main problems with the PC port of FreeDO was the sound. Admin says that this issue has actually been fixed in the GP2X port.

Good news!
Would be amazing if FreeDO could actually run on the GP2X, whether is simulated or emulated

 

[DaveC]

Actually, he believes it's more of simulator than an emulator at this point.
One of the main problems with the PC port of FreeDO was the sound. Admin says that this issue has actually been fixed in the GP2X port.

What exactly does this mean? A simulator? Does that mean that he isn't actually emulating the hardware but rather writing a program that runs the games as if they were running on a 3DO? I thought that was an emulator. Maybe he could clarify, sounds interesting.

I just hope it would be able to "simulate" Monster Manor, PO-ed, maybe Shockwave. I think Killing time would be too much though, a real 3DO couldn't even run it without alot of frameskip

 

[Shadowsithe]

Definitely good to hear a little "I'm still here" every now and then.

 

[Exophase]

Actually, he believes it's more of simulator than an emulator at this point.
One of the main problems with the PC port of FreeDO was the sound. Admin says that this issue has actually been fixed in the GP2X port.

What exactly does this mean? A simulator? Does that mean that he isn't actually emulating the hardware but rather writing a program that runs the games as if they were running on a 3DO? I thought that was an emulator. Maybe he could clarify, sounds interesting.

I just hope it would be able to "simulate" Monster Manor, PO-ed, maybe Shockwave. I think Killing time would be too much though, a real 3DO couldn't even run it without alot of frameskip


I want to know that too.. I've heard a few emu authors say they're "simulating rather than emulating" but in the end it has meant almost nothing.

 

[slaanesh]

Isn't simulation just a higher level of emulation?
Simulation may end up doing the same thing as emulation but not "bothering" to emulate some fine details which may be lost anyway?
For example, instead of exactly emulating graphic hardware to draw a graphic element, a simulation may do just the same thing but in a way that's native to the host machine and therefore less time consuming. The end result may appear to be the same to the end user but the way in which it is done might be completely different to how the emulated machine would have done it orginally.

 

[Playdough]

Cool.

 

[Squidge]

Admin@FreeDO says the emulator progress is going really well.
One of the main problems with the PC port of FreeDO was the sound. Admin says that this issue has actually been fixed in the GP2X port.

Could we have more info than "going really well" ? I assume from your later comment that the emu/sim already has sound? In which case, how fast is it going currently, whats the current computability rate? will there be an alpha soon?