Hi Justin, thanks for your help offer!
Win 3.11 can only run in 386 multitasked mode, which requires extra
kernel support e.g. in the int 13 handler and in some int 2f functions
for managing the int 13 handler and related. So it is no surprise
that Win 3.11 does not run. HOWEVER, it would be interesting to get
fresh test results (kernel 2035, new himem or maybe ms himem, better
no emm386, maybe use DOS=LOW and a non-XMS-Swap FreeCOM for the test
as well) for the 286 mode of Windows 3.0 / 3.1 (use WIN /S to start
in this mode - you may want to use other enable compatibility stuff
options of WIN as well, not sure).
In 286 mode, Windows can run on a 286 (you guessed that, right?).
Aitor suggested that it only runs one DPMI task at a time then,
swapping the other stuff to XMS. That should be much easier to handle
for FreeDOS compared to the fully multitasking 386 mode (/3 mode of
Windows 3.0 / 3.1 - and the same as the only possible mode of 3.11 ...).
Extra explanation about 1049: Abort, Ignore, Retry, Fail should do something
like abort, ignore, retry and fail respectively. Questions are whether this
does actually happen and which exact semantics one would expect for the 4
options. I think it was something like: Abort = abort program, ignore = just
continue as if the access had worked (?), retry = try again (not visible for
the program which tried the access usually), fail = tell the calling program
at once that the access has failed, do not keep trying.
In 1176, we are actually talking about two CONTROLLERS or in other words
three or four floppy drives! Only PC-PC and PC-XT could handle
that, it seems. But maybe some vintage computer expert here knows better.
For each controller you have one ribbon cable and up to two drives - but I
hear that controllers in new PCs now no longer support 2 drives anymore???
Thanks for testing 1743 (interlnk/intersvr). Maybe FreeDOS supports only
interlnk or only intersvr - in that case you can use another DOS for the
other end of the connection. Probably makes no difference, but
you can test with MS command.com if you want. The real problem seems
to be a kernel one. Usual try to use boring memory settings might help,
and maybe STACKS=9,384 (which is by the way also recommended for Windows 3.1).
But maybe INTER* simply relies too much on undocumented MS kernel structures.
And happy testing of Solitaire Suite and the other QB 4.5 / VBDOS issue...
LBACache Slow Computer Test - I own an IBM PS/2 Model 56 SX which is an
Intel 386 SX 20MHz with 12 MB RAM. [and SCSI harddisk]
Sounds good. As told, try with a small cache in 0.25 - 4 MB size range...
Maybe you can find some FreeDOS programs which do not run at all on that PC.
In that case, they probably use floating point calc or other things which
require 386 CPU. I think FDAPM will work (but will it matter? The 386 CPUs
did not need any cooling at all...). UDMA will not work, obviously. Neither
will LBA, but LBAcache should be able to use CHS in that case. You could iuse
OnTrack or EzDrive to install LBA support if you insisted on having LBA, though
...
CD-ROM stuff should work on 386+ but I guess you have no CD-ROM in that PC.
I assume that the oldest PC where CD-ROM can work at all would be 286, but
FreeDOS drivers all require 386+ for CD-ROM. I hope that CHKDSK will not be
too slow (hey, maybe try DOSFSCK...). DEFRAG might be quite slow on your 386!?
Even loading big files in EDIT might be slow...? MODE / DISPLAY should work if
you have EGA or better graphics. Actually all MODE functions should work...!?
Some aspects of FORMAT might be slowish. I assume that GRAPHICS will be slow
unless you use Post Script printers. I wonder if MemTestE would work (this and
other Linux loader style things like MEMDISK / ISOLINUX / ... require a 386,
but maybe MemTestE even needs PCI bus?). MIRROR might be slow but actually I do
not really trust it anyway. MORESYS should work nicely. NANSI should work and
should not cause speed problems. You cannot test SHARE.COM (.COM!) unless you
have a program which uses it, I guess. SORT speed should be acceptable. TE and
TED3 editor speeds should be fine. TICKLE should work as usual. Meybe even the
TICKLEHD (use HD (in upper case) option for CHS...) has effect on your system,
on faster systems the TICKLEHD effect is very small... remember to use FLOP
option of LBAcache when you use TICKLE/TICKLEHD, to speed up floppy access.
UNDELETE should work - try a dirsave of some directory to a file on another
disk and watch the screen output, for example. ZIP / UNZIP should work and
should be fast enough (remember that pre-386 need to use ZIP16 / UNZIP16 and
that you need the CWSDPMI file for *ZIP*). XCOPY should work. (and so on...)
Most other tools (how about cutemouse / mkeyb / ..., will they work on a 286?
Not that you have a 286, just wondering...) should work exactly as usual. You
have a 386, so all HIMEM, EMM386, dos extended programs, caches, XMS swapping
FreeCOM... should all be happy.
Please mail
