Paul,
My apologies for my late reply -- busy with other things.
> ... I noticed that the newer versions of Unetbootin will cause XMGR to
> freeze. I have reported this as a bug to Unetbootin:
> <https://bugs.launchpad.net/unetbootin/+bug/556416>
>
> ... but I thought that maybe Mr. Ellis can add some comments on the bug
> ticket with more detail ...
Regrettably, I cannot. I wrote XMGR as a "pure DOS" memory-manager, and
I have no experience with Unix, SysLinux, nor Windows Vista [I still have
V4.0 Windows/NT, which saves me paying $250 "tribute" every 6 months to a
certain Redmond, WA "gazillionaire" for his latest collection of BUGS!!].
Thus I have no way to debug what the high-level Unetbootin software does.
> ... perhaps there are some command-line options that can make XMGR work
> with the current version until they fix their bug?
In whatever CONFIG.SYS file is used on your "boot" diskette, you can test
the following --
A) When no /Mn switch is given, XMGR will use "temporary" memory starting
at 5000:0000h (320K) for its own diskette "workspace", also when it is
run in "boot" mode till JEMM386/EMM386 loads, and XMGR then moves into
upper-memory. Try specifying /M6 (384K), /M7 (448K), or other values
of /Mn since UnetBootin may now be using part of the 320K memory area!
B) If you are using /N80 or /N128 (80 or 128 XMS memory "handles"), check
if /N48 or no /N switch "survives" your boot load. If so, you should
tell the Unetbootin people that their program has become TOO LARGE!
C) When no /Tn switch is given, XMGR defaults to /T3 and will use all the
possible BIOS calls to get available XMS memory. Try using /T0 which
limits XMGR to the original 64-MB of memory, and try using /T1 and /T2
separately to see if they cause any difference. If these switches do
give some difference, the Unetbootin people are "playing new games" in
declaring available memory, and you need to GRIPE at them about this!!
D) If your "boot" diskette also uses the UMBPCI driver, and you load XMGR
with its /W "workspace" switch, try omitting /W. If this works, then
Unetbootin is no-longer declaring a 512-byte DOS "workspace" area that
XMGR can use. XMGR will then set its own area in low-memory, costing
512 bytes, but it should still work fine thereafter.
If none of the above helps, then as you noted on the "Launchpad" buglist,
I suggest that you KEEP the previous Unetbootin program, especially since
you also note on that list that RAMdisk also fails when used with the new
Unetbootin release.
Jack R. Ellis ---
(Account disabled on user's request.) |
Thread view
Board view
