dosbox-daily

Daily build of dosbox trunk

It contains the following patches:
1. sergm mt32 patch. It will ask for the rom location on install.
2. kjliew version of the > 2 gb image patch (for windows 95 games).
3. the last iteration of kekko glide emulation (not wrapper) patch.
4. All the gl shaders from https://github.com/tyrells/dosbox-svn-shaders

To prevent glitches using glshaders, turn off the scaler with 'none'.

Glide emulation is extremely resource intensive, and is only really usable with the hardware output. I also recommend getting familiar with the voodoo env variables - at least to remove the splash screen.
http://www.mdgx.com/3dfx.htm

The Glide patch is also in maintenance mode and some features were never completed. For instance, if you use it, you can't toggle fullscreen at will, only before the dll/ovl is started, or from a conf file.

The ppa also contains additional scripts 'dosboxmount' and 'copy-on-write-drive' that mount a writeable overlay for read-only directories and show a list of ready to play dosbox conf files from scanning that overlay filesystem for those files.

copy-on-write-drive is suitable for playing games from read-only filesystems, such as a squashfs mount or a blueray or dvd disc. It prevents the original install directory from being modified if used on a writable game dir. It does not have to be used with dosbox, or even for games (I also use it for retroarch cores that use writable game files).

To create in bash a unformatted DOSBox compatible HDD image with block size in bytes 512, cylinders (C, replace by what you want, max 1023), 255 heads and 63 sectors:

dd if=/dev/zero of=dsk.img bs=512 count=`echo $[(( (C+1) *255)+1)*63]`

Different C will get you various sizes, for instance, C=1023 (the max)
will get you 8.4 gb and C=255 will get you 2 gb. You can search for 'CHS calculator' on google and fill in every value but the cylinders to see other sizes as cylinders varies. Notice that the available size in the emulated windows is not equal to the size of the image outside, because of the block size. In short, if your image is going to be filled with many small files, and as each file has at least 1 block used, a large block size may waste a lot of space, and making a 'very large' image to hold both windows (lots of small files) and a game (some large files) may be a waste of space (i use 2 drives, one for windows in FAT16 and another for the game in FAT32).

To mount the 8.4 gb image for a secondary windows drive (notice '-fs none' has no relation to if the HDD is already formatted, just that DOSBox won't attempt to access it as FAT16), with the first number being HDDs equivalent to 'd' (2 being 'c'):
imgmount 3 dsk.img -size 512,63,255,1023 -fs none

To mount a (smaller) bootable HDD after formatting it as FAT16 with windows fdisk (the kjliew patch dosbox DOS shell doesn't support reading more than 255 cylinders as FAT16, and FAT32 is unsupported in the shell):
imgmount c dsk.img -size 512,63,255,255

Both kind of mounts can be managed by windows after the boot but FAT16 formatted images can be accessed from the Dosbox shell after mounted (without -fs none), and this trick can be used to place files on the windows drive, which is useful to autostart a game by copying a bat to c:\WINDOWS\STARTM~1\PROGRAMS\STARTUP\ before unmounting, remounting with '-fs none' and booting windows 95.

You can use other geometries with the -size parameter, but the default for dosbox with the kjliew patch is 512 bytes per sector, 63 sectors, 255 heads and a variable number of cylinders but not more than 1023 for '-fs none' and not more than 255 for FAT16; so omitting the -size will try to mount assuming '-size 512,63,255,[1-1023]' geometry and deduce the cylinders, which might break a existing image formatted or created differently.

So it's better to always specify the -size on the conf files when using imgmount for a HDD, as a question of forward compatibility if another patch or upstream decides to change the default again.

Don't ask for support on the dosbox forums; you won't get it.