I believe I figured out what’s going wrong with the XP crash reports. Turns out it was rather simple. I’m a little irked about the misleading error message we were getting .

On the machine I recreated it on, it actually was due to being unable to find c++ runtimes. I’ll update my original post to point this out as a dependency. You can get those here:
http://www.microsoft.com/download/en/details.aspx?id=5555

I do not have any 64 bit machines, so I’m unable to try any out myself. But, at least one chap sent me his crash details, and it should be the same. So, this may also resolve the issues on 64 bit machines.

My XP machine also got a crash on WaveLib, but I’m pretty sure I don’t have a sound card in it.

Well shoot. I guess version 1.0.0.0 will only work on 32 bit Windows 7. I’m not terribly surprised about 64-bit being an issue, but I am surprised that about Windows XP. Thanks for the feedback. I’ll look into it.

Here’s a general overview of my current set of priorities:
* Full screen (windowed mode).
* Fix WindowsXP.
* Fix 64 bit. I really hope I can get 64 and 32 bit systems to use the same EXE, but I’m a bit worried that I’ll have to have two different sets of deliverables.
* Save/Load NVRAM. (the 3DO save data).

After that, I will:
* Use OpenGL or SDL (for video). My winforms solution for video works, but it’s slow and wasteful.
* USB gamepad support. If I use SDL for video, I can use SDL for input as well.
* Fix/Improve Audio support (it gets very annoying if the framerate drops, which doesn’t happen to me any more, but slower machines would see it).
* Play from CD

I suspect all this will take over a month. If it goes really poorly or I’m less available I suppose it could even take 6 months. I believe the above items will get the emulator to a point where I no longer am the bottleneck of the operation. In other words, things would be at a state where others could jump in and help with the remainder. There is one big item that I can only do so much on.

This is the big item. As far as keeping the console alive, I consider it to be one of the most important:
* Start finding games that are incompatible or don’t load, and attempt to fix them. To set everyone’s expectations, this will be very slow and take a lot of work. I may have to add certain debugging features to the emulator to aid this effort. If anyone feels capable, they could help me in this.

Also this other stuff is less important to me:
* Multiple player support.
* Silly turbo buttons.
* The faux 640×480 support. Don’t be too disappointed with the low priority. It’s an intensive operation, so I believe games really only use it for static full screen images like loading screens. Also, it is not true high resolution, each original pixel just becomes a 2×2 pixel with different shades of the color (like blue vs. dark blue).

I got the controls figured out tonight, and also resolved a speed issue. It’s in a pretty presentable state, so I’m marking the occasion by packaging up version 1.0.0.0!

Not too long ago, I caught wind of the fact that parts of FreeDO’s code went open source. I decided to look into what I could piece together with what was uploaded. I was delighted to find that the provided FreeDO source code is fairly complete!

For the last couple of weeks I’ve been working on testing the code out and ensuring I can hook up to it. The odyssey involved uncovering each feature in a venerable, working state: video, audio, disc access, etc. I am very happy indeed! I am also grateful for the FreeDO developers’ choice in going open source.

At the moment I have only controls to flesh out in order to know that the FreeDO code is working well on it’s own. I don’t expect that will take terribly long, so I have enough confidence to say that FourDO is capable of undergoing a revival.

The key difference time time around is that I will no longer be attempting the high-level approach. To clarify, FourDO is being revived as simply a low-level emulator. Also, to give credit where it’s due, the core of the emulation is powered by FreeDO’s code. FourDO is primarily just a user interface around it.

Since I’ve had to make a few changes to the FreeDO code, the FourDO project includes its own copy of it. I don’t know if any FreeDO development is going to continue, so I’m not particularly worried about branching in this fashion.

I have been using C# for the front-end. This speeds development time considerably, and I’ve been wary of introducing bloated bottlenecks as a result of utilizing the high-level language. So far I have been impressed with the minimal overhead it introduces.

I hope to help breathe a little life into the 3DO emulation scene. With any luck I can have FourDO up to snuff and provide a good framework to support bug fixes or additions to the core that will flesh out the game compatibility.

Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!