[GEM Development] Multitasking OpenGEM on its way

[John Elliott]

: > I think the original intent was that the user creates a RAM drive as their
: > last drive letter, placing it in extended/expanded memory -- that way XM can
: > stash its 'swap' in memory that it otherwise didn't know how to access.
: 
: Yes, this would make sense.  Now there is a question: is it better to
: use a RAM drive or my existing SUBST solution?  Let's not just talk
: performance here, but also ease-of-use and likelihood to succeed.  Can
: we have an automated (batch-file created) RAM drive that works on all
: DOS versions?

  The behaviour of the GDOS wrt swapdrives can be customized. Search for the
'zyxg' byte sequence in GEMVDI.EXE; the following 3 bytes control its
behaviour:

	DB	swapdrive. Valid values are:
		0 => Use C:\GEMSYS
		1 => Use highest available drive
		ASCII letter => use specified drive

	DB	esckey. Scancode for task switcher key.
	
	DB	fcflag. Normally 1; if set to 0, GEM itself will be swapped
		to C:\GEMSYS.

  I suggest setting the first byte to 0 and seeing if the result works in
DOSBox. Hard drives are fast enough these days that there's no real point in
swapping to RAMdisc; particularly if there's a good cache in use.

-- 
John Elliott