DOS ain't dead

(I hope this topis will not start another flamewar - please be reserved)

Issue about 4MB barrier with Soundblaster and UIDE can be avoided with resiseable RAM-disks. For this purpose I recomend TDSK.
So - you have to load TDSK (with set 4MB or more RAM-disk) before UIDE. TDSK allocates memory from "base to top" so it will eat the first 4MB of memory. Than you load UIDE which has to allocate space for cache ABOVE these 4MB.
Than, later, in AUTOEXEC.BAT you resize TDSK to zero so a 4MB hole originates in memory.
Now I can whenever start the Soundblaster emulation.

Bad thing is that the drive letter doesn't disappear but I avoid it with JOIN command. I join the RAM-disk drive letter with some deep directory of my disk and problem is "solved".

---
DOS-u-akbar!

Happy to hear you were successful in loading your Soundblaster drivers
before UIDE, Ladislav, which is the most reliable way.

Some of my prior drivers did allocate all XMS memory, return it to the
XMS manager, allocate 2 XMS sections of which the second in "high XMS"
was the driver's buffers, then return the first section to the manager.

I did NOT regard this as perfectly reliable, since I cannot know if it
works with EVERY possible XMS manager. Some are not known to me, and
they may have "bugs"! So, the current UIDE makes only one XMS memory
request.

Your scheme IS reliable, and I commend you for finding a way to do it!

> Issue about 4MB barrier with Soundblaster and UIDE can be avoided with
> resiseable RAM-disks. For this purpose I recomend TDSK.

TurboDSK is a very good program. I use it all the time on my P166 (DR-DOS 7.03, 32 MB RAM). AFAIK, the latest open source version is 2.3, but later tweaked versions (2.41?) exist that supposedly set an env. var. to the drive letter. Here's a brief pro + and con - review of TDSK (both means it could go either way):

+ open source w/ liberal license (I forget, pd??)
+ pretty small .EXE (once UPX'd, eheheh)
+ small cluster size (unlike SHSURDRV's default 4k, min. 1k)
+ resizable from cmdline (unlike VDISK.SYS from DR-DOS)
- can't choose drive letter (unlike XMSDSK or SHSURDRV)
- doesn't return drive letter (unlike SHSURDRV), but FINDDISK fixes this
- source code uses TASM (haven't tried Nomyso on it yet)
+ supports XMS 2.0, EMS 3.2, and (uniquely, AFAIK) conventional memory
- max. 64 MB thanks to XMS 2.0 (unlike 386+ SHSURDRV)
+ works well w/ DC-SK (unlike XMSDSK) or NDN (unlike DNOSP 6.4.0)
+ - NLS support built-in (Spanish and German, IIRC; bloats it up a bit)
+ smaller version (BITDISK, XMS only) if needed
+ doesn't crash if no XMS driver found (unlike XMSDSK)

Just FYI.

---
Know your limits.h

And what about XMSDSK 1.9I by Franck UBERTO?
It can make >64MB, adjustable cluster 1-64s, adjustable size, forcing drive letter, 20kB size.

---
DOS gives me freedom to unlimited HW access.

> And what about XMSDSK 1.9I by Franck UBERTO?
> It can make >64MB, adjustable cluster 1-64s, adjustable size, forcing
> drive letter, 20kB size.

He does mention that it crashes if you're lacking an XMS driver, rather than handling it gracefully. I like being able to choose the driver letter, and the >64MB sized ramdisks more than the upsides of TDSK, though.

Crash?
If I remember well, when XMS driver not present it ask if load XMS driver and then continue. But I admit it may crash for somebody as many other DOS sw/drivers :)

---
DOS gives me freedom to unlimited HW access.

> Crash?
> If I remember well, when XMS driver not present it ask if load XMS driver
> and then continue. But I admit it may crash for somebody as many other DOS
> sw/drivers :)

Yeah, it doesn't happen under all circumstances, and XMSDSK itself doesn't crash, it causes some sort of instability. When it would happen to me, COMMAND.COM would give a "memory allocation error" and then crash, whereas simply commenting out XMSDSK with the same configuration doesn't crash.

Eh, shit...
It does crash on my system, just tried (all of MS-DOS 6.22, 7.1 and FreeDOS). But I swear it was working on my previous hardware.
But I think loading an XMS driver is good idea anyway so I don't much fear about this crash.

---
DOS gives me freedom to unlimited HW access.

> Eh, shit...
> It does crash on my system, just tried (all of MS-DOS 6.22, 7.1 and
> FreeDOS). But I swear it was working on my previous hardware.
> But I think loading an XMS driver is good idea anyway so I don't much fear
> about this crash.

Maybe this will help:

"ReSizeable RAMDisk for FreeDOS (and other DOS). SRDISK is fast and able to use over 32M of XMS and EMS memory. The size of disk can be changed without rebooting or loss of content. Diskcopy compatible."

By Marko Kohtala.
2005-07-23: v2.09c.
Free under GNU General Public License.

Programs in set:
SRDISK.EXE - Formatter program
SRDXMS.SYS - XMS driver
SRDXMSS.SYS - XMS driver (small version)
SRDEMS.SYS - EMS 4.0 driver
SRDEMSS.SYS - EMS 4.0 driver (small version)
SRDEMS3.SYS - EMS 3.2 driver

Project page:
http://sourceforge.net/projects/srdisk/

File Releases page:
http://sourceforge.net/project/showfiles.php?group_id=138699

I know someone who developed an updated version...but he is too busy to publish it now... (