Feel free to try it out. You will need the .NET framework (4.0 I believe, sorry!), and hopefully nothing else. I haven't attempted to run it on any machine other than my own, so I haven't ironed out dependencies.

I'm pretty sure I also figured out why my framerate was low. I had been rendering to 640x480 (since the 3DO can technically do with some of its video processing), whereas I think FreeDO normally renders to 320x240. I hope I can get it churning out this resolution while at a reasonable speed, because the 3DO truly does have some minimal capabilities to produce the higher resolution.

I could use a little feedback on the following:
* Does it work on Windows XP? I've used timing mechanisms that might behave differently in XP.
* Are all the controls right? I hooked up each key using a game where I knew the controls. There were some bits in the data that seemed to do the same thing (such as two different bits for the Up button), and I've just picked one of the two.
* Probably more, but be sparing for now. Version 1.0.0.0 sure is hairy.

This certainly may not mean much to many people, but this is a big moment for me. I've spent a very long time researching and plugging away at 3DO emulation, and it almost felt like a waste when I had given up on the high-level approach with the "old" FourDO. But, all that experience enabled me to pick up the FreeDO code leftovers and comprehend it well enough to resurrect it. I feel that the community finally has an open-source 3DO emulator that can be maintained and added to. I take great pleasure in knowing that this helps ensure the longevity of the system as the consoles themselves slowly expire.

I still have a lot of work to do. Thanks to everyone who helped me out! And of course, long live 3DO!

Last edited by JohnnyDude on Mon Aug 08, 2011 1:38 am, edited 1 time in total.

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 640x480 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 2x2 pixel with different shades of the color (like blue vs. dark blue).

Well, I for one am extremely grateful of your efforts. I've been hoping for 3DO emulation to improve for years! While I still have my FZ-1, there's no room for it in my living room, so doesn't get used much these days.

I'll give this a try when 64bit is fixed and nvram is working (I've been against save states for about 2 months now lol). I run Win7 64bit on my laptop with 6GB Ram on a core i7 with a (iirc) nvidia GT 330m (1gb ram).

PS, im trying to think of something where the 64bit and 32bit versions are in the same exe... Does that actually exsist? And why does it not like 64bit when the os runs 32bit apps? Is it really a 64bit issue? You really don't have to answer any of this, im just thinking out loud again.

Fix for Windows XP (+64 bit?)
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 .

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.

- OK, so far here is a crash i was able to get happen more than once. Deselecting run previous image then reopening the emulator results in an unhandled exception. This is fixable by the user by deleting the settings file and opening the emulator again.

- Sometimes the audio garbles like it has a buffer underrun and then is struggling to catch back up. Pausing (F9) and then unpausing seems to get the audio back to normal. This seems to happen more if the emulator is not the window of focus. This is happening as I type on the Killing Time Title screen. Perhaps setting an option to set the priority of the app will fix this or maybe adjustable sound buffer?

- an auto pause when the window loses focus would be nice too!

- More support than just ISO 2048 is needed, it will cause you less headaches too from people that cant convert their images. I used to help with this problem a lot back in the day and it got old really fast. Adding 2352 and bin/cue support will help tremendously.

- The emulator is running great right now. Just need to get more features added to get up to par with the FreeDO Alpha and then start working on some more things. Official Joystick support that works and doesn't cause a migraine!

BryWI wrote:- OK, so far here is a crash i was able to get happen more than once. Deselecting run previous image then reopening the emulator results in an unhandled exception. This is fixable by the user by deleting the settings file and opening the emulator again.

BryWI wrote:- Sometimes the audio garbles like it has a buffer underrun and then is struggling to catch back up. Pausing (F9) and then unpausing seems to get the audio back to normal. This seems to happen more if the emulator is not the window of focus. This is happening as I type on the Killing Time Title screen. Perhaps setting an option to set the priority of the app will fix this or maybe adjustable sound buffer?

I see, I wasn't aware that pausing it caused it to come back to life. I will have to try this. I have found a good way to reproduce this, so if I spend some time on it, I will probably be able to stamp it out.

BryWI wrote:- an auto pause when the window loses focus would be nice too!

Not a bad idea, it's certainly easy enough to implement. I will remember it. I will most likely throw it into the options dialog rather than being precious real-estate on the main menus that the "quick" options have.

BryWI wrote:- More support than just ISO 2048 is needed, it will cause you less headaches too from people that cant convert their images. I used to help with this problem a lot back in the day and it got old really fast. Adding 2352 and bin/cue support will help tremendously.

This will be within the general focus of my next round of updates. I intend to add "Play from CD", "Load binary file", and support for as many formats as I can easily add in. I'm afraid I can't say for sure that 2352 will be added immediately, it kinda just depends on how difficult it ends up being.

BryWI wrote:- The emulator is running great right now. Just need to get more features added to get up to par with the FreeDO Alpha and then start working on some more things. Official Joystick support that works and doesn't cause a migraine!

Thanks for the support! And thanks for the feedback. And I completely agree regarding the joystick configuration FreeDO 2.1; it is astonishingly unintuitive. Even configuring a keyboard was a nightmare, I probably spent a good 10 minutes just getting that set up.

Speaking of fixes to bugs, I have good news for you, in the following post:

Version 1.0.2.0 alpha includes:
* NVRAM support : Quite the lazy job on my part. It just saves to "NVRAM_SaveData.ram" in the same directory as 4DO.exe. This is non-configurable, but it works!
* Fix to a crash on startup resulting from toggling certain settings.

Also, sorry to just drop in a copy+paste from my sourceforge news feed, but this is also relevant:In other news, I've been attempting to touch base with any remainders of the FreeDO development team. There are several versions of FreeDO that were never "officially" released. These versions have noticeable improvements (mainly graphics) in the core that I would like to make use of. It seems like a waste to have two 3DO emulators developed simultaneously when there is such little development going on at all. I'm unsure if this will mean me merging into what's left of the FreeDO development effort, or if it means them merging into 4DO, or if it means that my diplomatic efforts fail and I'm just given the finger and told to mind my own business. I'm pretty certain that it will affect what happens with 4DO in the future.

I got in touch with the FreeDO developer I know (Altmer), and he is apparently still working on it, though slowly. I don't know this for sure yet, but I think he was single-handedly responsible for the post-official releases like "2.1 alfa". Those versions have improvements that I would like to incorporate into 4DO if possible...

I think we both should be working on the same emulator. However, I don't really know that Altmer would be cool with me swooping in, taking his work, and rebranding it as "4DO". So, I've offered to join up with him, which may mean I'd help improve FreeDO and leave 4DO alone. I'm unsure if he's even interested in accepting help or open-sourcing what he's done.

Altmer provided me with some helpful information. He tells me that the FreeDO source that is available on google code includes many of the improvements from FreeDO 2.1. As far as 4DO is concerned, that's great news.

He is also working on a "new" emulator. New as in not FreeDO. One of the things he intends to include is the hardware accelerated graphics (which I referred to on another thread). I don't really know what else the new emulator involves other than a rewrite. He also figures it would be difficult to work together on it. Considering the language barrier, I have to agree. He seems willing to make his new emulator open source as well, when it's finished Note: This is wrong, see post below. He also said he could try to keep the interface similar to the one FreeDO had so that I could more easily use it with something like 4DO. That's a minor point. But, that's all the info I have.

So, it looks like there is no FreeDO development going on whatsoever, and FourDO is using the latest copy. Altmer is working on a new, different (low-level) emulator, and meanwhile I'm adding features to 4DO to basically produce a more swanky version of FreeDO. Hopefully some day in the future, Altmer's new emulator is released and a clear improvement, and 4DO or something like it can help out by plugging in and padding out the interface with features. As far as I know, that sums up the only 3DO emulation development going on in the world.

Back in 4DO land, I have been working on getting CD-Rom support online. Some games load just fine. For some reason, on other games I'll get a "give up" error visible on the screen after it fails to load. I think this may be the copy protection I've heard about. I have noticed that 2.1 FreeDO does not have the problem, so I am going to try to iron out what I'm missing.

Last edited by JohnnyDude on Sat Aug 13, 2011 1:08 am, edited 1 time in total.

Welp, might as well return after 4 years to make the same (and only) post I did last time.

Does anyone have an ideas on running Crash n Burn (game cycles the 'total eclipse' demo over and over. You are originally given a selection screen for that or CnB)? Is it just a game that won't work no matter what, or an unsolvable glitch, or something possibly fixable? I asked back in 07, and it was remarked as an 'unsolvable' issue on FreeDO.

Regarding the edit above, Altmer provided clarification that his new emulator will NOT be open source, but that the interface to it will be. Bummer. But, at least having an open interface allows for a new UI to be thrown on top of it.

Vicious wrote:Does anyone have an ideas on running Crash n Burn (game cycles the 'total eclipse' demo over and over. You are originally given a selection screen for that or CnB)? Is it just a game that won't work no matter what, or an unsolvable glitch, or something possibly fixable? I asked back in 07, and it was remarked as an 'unsolvable' issue on FreeDO.

Sorry, but I don't think Crash'n'Burn works with 4DO. I figure this because I've heard Crash'n'Burn doesn't work with any version of FreeDO, and I have not made significant changes to "the core".

Minor changes:
* I added a "File -> Close" option to close whatever is currently open.
* The option to "load state" on startup has changed into an option to "load state" whenever a game loads. For example, if you open a different game while 4DO is open, it'll do an automatic "load state" for that game.
* 4DO now remembers the directory that you last selected a CD image file from.
* I renamed some of the menu items to make their use more clear.

I took way longer than I anticipated figuring this out. This one cost me a lot of time, so hopefully you folks just flat-out love that CD support! Woohoo! Long live 3DO!

The next feature I will concentrate on is the Joystick/Controller support. I may also do a little housecleaning. I think it's about time I got an installer for the folks less capable installing the dependencies. Also, I'm avoiding any use of residual files like user settings in "C:\Documents and Settings\etc\etc" and trying to keep all settings and files just plainly in the 4DO directory. Keeping with this trend, I also intend to do this for save states. So, save states will likely be moved to a "SaveState" folder that pops up in the same directory that 4DO gets run in. I'm also not so sure I like the "save slot" idea as currently implemented. With emulators I've typically found that I fumble and press the change save slot buttons on accident. I would also like to save screenshots with each save state, but the current system doesn't have anywhere of use that I could provide a screenshot. I'm uncertain how I'd prefer it to work, though. If anybody has seen nifty, intuitive ideas regarding save states in an emulator, I'd like to hear them.

So... how many people are still left that are even interested in a 3DO emulator anyway? A dozen? My guess is somewhere around a hundred.

I was getting a bit tired of SourceForge's cumbersome system. I decided to create a minimally functional website to serve as my news platform. I spent some time today wrestling with PHP, MySQL and WordPress, but it's ready to go! I have also retro-fitted it with posts from this forum as well as sourceforge news sites.

NVRAM seems broken. It creates a file in the emulator directory but it is never written to after initial file creation, not upon closing game or closing emulator. Need For Speed refuses to even play because it thinks the NVRAM is Full. Some games will save to NVRAM and load from it but it seems NVRAM is just being updated in the emulator but never to the file. Im not sure why Need for speed thinks nvram is full, this might be a different problem all together. Hope you can get this sorted out. good luck!