I will port the next major release of DOSBox, which appears to have initial support for Windows 3.x

Well win3x works since a good number of dosbox versions now.

But anyways, what games do you want to run with this? Speed will be
a problem unless you port the recompiler somehow.

Thanks for the info. It's been a while since I played around with DOSBox. 😀

I don't have any specific games in mind; however, from what you are indicating, some will rely on the dynamic core for playability?

I am not yet very familiar with the dynamic-core, but it sounds as though it generates native x86 code? Is there some technical info on the extent of this? If it is indeed generating native code, we'd have to generate .NET IL. This would subsequently be JITed by the CLR. Might be an interesting project...

some will rely on the dynamic core for playability?

Well that depends on the games you target the port at. Using the regular
interpretating cores (see core=normal in dosbox.conf for testing)
you won't be able to run duke3d and quake, but many other games
will work (like indy4, larry, wolfenstein3d).

There are two closely related recompilers, one is out for your purposes
(very fast x86 to x86 recompiling using host flags etc.), the other one
might be suitable for x86 to clr recompiling. Don't know if the .net intermediate
language really allows something like that.
See the files in cpu\core_dynrec, they're documented to some extent.

I've started to look at the core_dynrec, and I think that will be a good starting point.

Introduced to .NET 2.0 was Lightweight Code Generation (LCG), which allows you to generate IL for individual methods. These will be JITed by the CLR when you call it. Given the methods are actually allocated by the managed runtime, the garbage collector (GC) can clear them up when no longer referenced.

The other thing I've been looking at changing is the rescaling, as there are two issues for me:

• * Clever use of macros, which there is no equivalent in C#
  * Performance

I'm going to use OpenGL exclusively, given this is targeted at platforms with the CLR. It is also the x-platform graphics API of choice. I plan on experimenting with fragment shaders (GLSL) to do the effects, such as scanline, relieving the CPU. I have 5 books on OpenGL 😐, as I'm contributing to the cross platform implementation of Xna too.

SDL.NET and Tao.OpenGl are great x-platform libraries, that work on the MS and Mono CLRs, providing a great bridge.

Future Project:

I know it's very difficult to benefit from multiple cores in emulation, but I was thinking it might be possible with the dynamic core. In general, the PC is less dependent on cycle exact timing for running most games and apps. It was quite amazing to translate the Frodo C64 emulator, which is a cycle-exact emulator. It was specific enough to raise certain events (particularly of the VIC and SID chips) on both the rise and fall of a single cycle!

Back to DOSBox, my thoughts were:

• * Thread 1
  • * Responsible for emulating the CPU.
    * Within the IL, interleave periodic checks to a flags variable. An example flag would be an interrupt, somewhat like this pseudo-code
    Copy code to clipboard

    1if interrupt_flag==true then call interrupt_handler
    

    * I'm not concerned about using synchronized access to the flags variable either, since if we miss the event on the first check, we'll get it next time.
  * Thread 2
  • * Responsible for emulating the PIC, input, processing video and other secondary tasks.
    * As necessary, the PIC would raise the interrupt flag, causing the CPU in Thread 1 to branch on it's next check and process the interrupt.
    * The CPU can write to the video buffer at any time, as the worst we would see is tearing, just like a real PC. We could emulate the vertical-black stuff, so it wouldn't tear too.

Regarding scalers, you may want to take a look at the directx patches and my OpenGL-HQ addon. The latter uses ARB_fragment_program for scaling, which means it works fairly well on moderately old hardware. It is an external addon, however, since I made it an SDL output driver. Using that, you might even be able to just use my SDL version and don't bother about scaling at all.

Where would I look for this, mate?

Cheers,

Stu

My homepage: http://garni.ch/dosbox/

(If it doesn't work, use google, it's the very first result for "OpenGL-HQ")

Thanks mate - looks very good. Is the SDL team interested in committing your updates?

I created a GLSL shader to emulate a 'scan line' view.

Still working through the port right now, should be a few more weeks before I have something basic working...

No, the SDL folks don't seem anxious to include it in the official distribution.