Xbox port

[incrediclint]

I'd like to have a go at porting 4DO/Freedo to xbox but I'm completely new to emulator coding. I've got everything needed to do the port and thorough experience in DirectX/D3D coding, I am however not to familiar with the 3do hardware nor the freedo core library. Any chance you could give me some clues about it's usage?

I know I'll have to write Xbox SDK/DX8 wrappers for freedo code, I just don't know what code does what in freedo. Hoping your guidance can save me some headaches/time.

EDIT: I realize the performance will more then likely be horrible, but I'd like to atleast get it to run and then come back and do optimizations later.

[BryWI]

Johnny might have some more information for you but if you look in the SVN there is a DOC folder with a bunch of information. Im not sure if it's what you are looking for but it might be a start.

I also have a feeling that you might get some questions since you have experience in DirectX/D3D coding. It's not my call (nor my emulator ), but some help might be needed in that area with some quirks and getting hardware acceleration working (that might be further down the road yet though).

If the docs do not help and/or there is specific questions, post them and hopefully Johnny can give you an answer.

[Johnny]

I'd be happy to help out. I didn't learn all this 3DO-specific domain knowledge for nothin!

To start you off, 4DO uses the source code from FreeDO's core emulation. If you get 4DO's source, you'll see being compiled and created into a DLL called FreeDOCore.dll. So, my advice and input for you would really be tailored depending on how you architect the XBox port...

I think you'd end up re-writing a lot of the code in 4DO; you might even end up with a FreeDO port more than a 4DO port. You could choose to just tie into the FreeDOCore's interface. This wouldn't be a bad idea. If there are improvements to the FreeDO core in the future, I doubt there are going to be considerable changes to that interface.

Maybe that will help spark your interest. Feel free to ask more questions!

[Johnny]

I've got everything needed to do the port and thorough experience in DirectX/D3D coding, I am however not to familiar with the 3do hardware nor the freedo core library.

BryWI is right that I want to take advantage of your presence for 4DO's gain. I would love some advice on the small amount of DirectX use I have in 4DO. There have been crash reports on some machines during initialization; I suspect I'm doing something too complicated for the task. Would you mind if I pitched a few questions?

[incrediclint]

Yea, I'll have to re-write the UI completely for the xbox port. I'm looking into some emulators that were already ported to xbox to see if I can start with those emu's UI code rather then starting from scratch.

I downloaded the source for 4do from the svn repo and saw that your using slimDX. I'm not sure what help I can offer, I've built three DX engines from the ground up and have tried in the past to stay away from using other people's code/libraries being that DX is pretty good by itself. Always starting from scratch has also meant that my projects tend to take a long, long, time to complete, so with this project I'm trying to change that.

I've also barely touched C# and have always focused on C++, so I'm a bit behind the times I suppose.

I'll help any way I can. Freedo2.1 runs better for me then 4DO, but only slightly (FPS spikes).

I'm quite lost when I look at the freedo core code, I'm very much used to more modern coding styles/naming conventions. What I'd like to know is what in the freedo core do I need to concern myself with to get the bios loaded and ready to be rendered to the screen?

[Johnny]

It sounds like you've got the skills to pay the bills. You won't have to learn much about that core, and I think you'll be pleasantly surprised at how quickly you can get it up and running. How exciting!

At a high level, there are only two "openings" in the core you'll need to worry about. One is input and the other is output. If you look at the version compiled in 4DO, they are _freedo_Interface and _ext_Interface.

_freedo_Interface is your input. It takes a "procedure" (int) and a "datum" (void pointer). As you can probably guess, that splays out to several various functions. The majority of these functions only need to be called once during startup.

What you call first is FDP_INIT, and you send it a callback location for _ext_Interface. This will allow the core to ask you for stuff and signal you for things. Similarly, this has a "procedure" and "datum". These are all relatively simple.

In 4DO's code, you could look at FourDO\Emulation\FreeDO\FreeDOCore.cs for a more human-friendly (and type safe) representation of both of the functions' procedures and data types.

FDP_INIT will ask several things of you (for example, it will want you to give it a pointer to a block of memory it'll use for the 1MB ROM), all of which you'll have to respond to correctly. You can refer to FourDO\Emulation\GameConsole.cs to see how it responds to the callbacks (look for functions called ExternalInterface_*).

So, the amount you'll have to learn will be very manageable! I'm sure that'll get you started. In the meantime, I will selfishly ask for your help in return by asking DirectX questions, so please keep an eye out for another thread spawning out soon.

[incrediclint]

So I've figured out how to get the bios loaded and whatnot, thanks to your help. I've managed to get some garbled output to the screen as well. I'm trying to figure out the GLUT stuff now and using your code as a starting point from the VDLframe/VDLLine stuff.

Code: Select all

*destPtr++ = (unsigned char)(linePtr->xCLUTG[(*srcPtr) & 0x1F]);
*destPtr++ = linePtr->xCLUTG[((*srcPtr) >> 5) & 0x1F];
*destPtr++ = linePtr->xCLUTR[(*srcPtr) >> 10 & 0x1F];

I figure the 2nd/3rd lines are the green/red components of the pixel, but what's the first line do and why isn't linePtr->xCLUTB used?

[incrediclint]

I've got the 3do logo displaying now, but it doesn't move on to the 'Insert CD' screen yet. Your code has helped a ton in understanding the freedo core.

[BryWI]

Congratz! Looks like you are making a good amount of progress.

[Johnny]

I figure the 2nd/3rd lines are the green/red components of the pixel, but what's the first line do and why isn't linePtr->xCLUTB used?

Oh my, That's interesting. I think that's probably a bug. I imagine I didn't catch it because the color tables were all identical when I was futzing around with the code at the beginning.

I'm glad to hear things are starting up for you. Assuming you're able to debug 4DO, you should be able to get to the "insert CD" screen.

I don't know if this will be important or not, but one of the BIOS's was freezing up on 4DO if the controller input was wrong. I'm unsure if sending all 0's to that buffer will avoid it or not. 4DO currently emulates as if 6 controllers are always attached. If you want to look into it, you'll find that code in JohnnyInputPlugin.cs