Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Does anyone have ChocoDos?

Recommended Posts

Probably pointless but I have heard about ChocoDos before (the one by @RestlessRodent). Does anyone have binaries or source code of it?

Share this post

Link to post

Wow, a DOS clone of DOOM.EXE would be excellent. Imagine something like that but made using an open source compiler (DJGPP) and some free sounds library (instead of the forbidden DMX). It would be a cool challenge to compare its sounds with vanilla Doom's.


Once that is made, we're finally free from operating systems! DOSBox all the way!!

Share this post

Link to post

I considered doing this. I've done a few related things.


I ported the original Boom 2.02 source from DJGPP to Open Watcom. I used input code from Heretic and audio from RoTT.


I managed to get the Heretic and Hexen sources to compile verbatim using the leaked DMX files and the original Watcom compiler.


I also contributed some changes to Chocolate Doom that allows it to compile with Open Watcom. I should probably check to see if this works with SDL 2.


At the end of the day the only thing I can say is that these things all worked, but are otherwise uninteresting.

Share this post

Link to post

I've always had in mind the possibility of doing a DOS port of Chocolate Doom. Done properly it should remove the dependency on SDL since that's never going to run on DOS. As I recall, the ChocoDos port being discussed here was trying to reimplement bits of the SDL APIs under DOS.


What's needed should be something like:

  1. Reimplement all the i_*.[ch] files using DOS APIs. For example an implementation of i_video.c that writes to VGA, etc.
  2. txt_dos.c to replace txt_sdl.c (should mostly be a thin wrapper around the DOS text screen buffer)
  3. pcsound_dos.c (ie. set the right DOS registers to drive the PC speaker)
  4. opl_dos.c (drive a real OPL chip)
  5. net_dos.c that will send and receive packets using the {ipx,ser}setup networking interface

(1) should be the majority of the work but (2)-(5) should actually be relatively trivial. Chocolate Doom's codebase is structured in such a way that they're just new implementations of existing interfaces.

Share this post

Link to post

Maybe 5 could get a recursive import into Chocolate Doom proper while linking with libpcap, like PCem and (NE2000 patched versions of) Dosbox can do.

Share this post

Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now