Google is your friend. First link on HIEW search goes to
http://www.serje.net/sen/
also
http://webhost.kemtel.ru/~sen/
which both allow downloading 6.11 as the LATEST FREE version. It can be downloaded,
since I just tried it.
There is also a different e-mail address than the one you used
This one should be getting close. The second release candidate version of EMM386 with
VCPI support is available at ftp://ftp.devoresoftware.com/downloads in the files
EMM386.ZIP and EMM386SR.ZIP, as executable and ASM+C source. They are dated March 27,
2004.
This version of EMM386 corrects
The final release of EMM386 with VCPI support, version 0.90, is now available at
ftp://ftp.devoresoftware.com/downloads as the files emm090.zip (executable) and
emm090sr.zip (asm and C source modifications to the original file set).
This version of EMM386 contains no changes to VCPI behavior
At 04:50 AM 4/24/2004 +0200, Bernd Blaauw wrote:
smallest allowable blocksize seems to be 4KB,
so I'd like a utility which can check each 4KB.
UMBPCI can do this right now (and even use it),
UMBCHK cannot (16KB only),
Emm386 I'm not sure if it can check in 4KB blocks,
but it can use no smaller
At 05:26 AM 4/24/2004 +0200, Bernd Blaauw wrote:
Michael Devore schreef:
DOS can deal with blocks down to 16 bytes, so you could probably run UMB size down
that low,
although the overhead there wouldn't be worth it. But 1K (or less) is feasible.
It's a matter of how hard you want to squeeze
At 03:16 PM 4/27/2004 +0200, Eric Auer wrote:
Hi, I would call X=TEST either HIGHSCAN or SAFESCAN if you
were to ask me what syntax should be used to exclude all
high areas which contain other than all-0 / all-ff.
By the way, while googling for NoMovExBDA I found that in
EMM386 of DOS 6.22 /
Looks like you might have something loaded high in a UMB that is conflicting with your
machine environment. Take out the I=C800-C8FF to see if the problem goes away. In
fact, you could try full exclusion via X=A000-EFFF (temporarily) to see if there are
any UMB conflicts, then bring the
At 12:50 AM 5/18/2004 +0400, you wrote:
Hi!
17-íÁÊ-2004 14:03 [EMAIL PROTECTED] (Michael Devore) wrote to
[EMAIL PROTECTED]:
as always, your message appears as 1 long line. Very wide. Manually quoting now..
MD wins and I'll change or not, accordingly. What I won't do is change away
MD from
At 12:47 AM 5/19/2004 +0400, you wrote:
Hi!
18-íÁÊ-2004 12:23 [EMAIL PROTECTED] (Michael Devore) wrote to
[EMAIL PROTECTED]:
no big problem.
MD Alright, I changed to hard CR's,
I look at source of your letter (which I answer) - no, there are no
hard CRs inside paragraphs. :) :(
That's because
Nothing unexpected here. You cannot use EMM386 with a program which is
(badly) written so as to not work under virtual 8086 mode. Use HIMEM only.
UBMPCI if it works, since it uses BIOS hardware rather than software to get
UMB's. Loading before HIMEM is asking for trouble since DUSE
Uploaded to ftp://ftp.devoresoftware.com/downloads are the files emm386.zip
(uncompressed executable) and emm386sr.zip (revised source code) for EMM386.
This version of EMM386 corrects an error with its GDT setup that led to a
crash when it was used with one or more versions of SoundBlaster
Uploaded to ftp://ftp.devoresoftware.com/downloads are the files emm386.zip
(uncompressed executable) and emm386sr.zip (revised source code) for EMM386.
This relatively minor update adds an SB option, adds silent recognition to
the bare RAM option, and restores the VDS experimental option for
Uploaded to ftp://ftp.devoresoftware.com/downloads are the files emm386.zip
and himem.zip containing uncompressed executables of, respectively,
EMM386.EXE and HIMEM.EXE, plus the source files modified in this latest
version.
EMM386 adds support for EMS function 51h, reallocate pages. This
Uploaded to ftp.devoresoftware.com/downloads is an updated emm386.zip, the
full FreeDOS file set of HIMEM and EMM386 files.
EMM386 has several enhancements. It adds support for the most-used API
subset of VDS with the VDS option, allowing network drivers to be loaded
high in UMBs. All moves
At 03:48 PM 11/26/2004 +0100, Eric Auer wrote:
Hi, I have looked at the X-Spam-Scores of my list mail folder.
My plan is to throw away mails with a score of 3.0 or higher.
Of almost 8000 checked mails, there would be 13 false positives.
I am explaining those below. A possible reaction could be to
Uploaded to ftp://ftp.devoresoftware.com/downloads are the files
emmx13b.zip, EMM386 mostly executable package, and emms13b.zip, EMM386
mostly source package.
These versions follow the latest EMM386 fileset template directory and
naming conventions. EMM386 supports [in|ex]clusion ranges to
At 01:43 PM 12/30/2004 +0300, Arkady V.Belousov wrote:
BTW, this raise two questions to Michael Devore:
- may EMM386 autoinclude given region in some way, if there will not be
detected mono adapter/mode? QEMM386 does this.
Automatically as default? No. Fails the rule of least surprise
At 01:43 PM 12/30/2004 +0300, Arkady V.Belousov wrote:
- what happen if I=B000-B800 will be used on system with mono adapter/mode?
Oh, you mean if you designate a UMB which has memory addresses used by the
active screen, what would happen to the display? You'd get screen which
doesn't update
At 06:16 PM 12/30/2004 +0100, Eric Auer wrote:
Which reminds me that VDS should probably be
on by default
No.
but on the other hand is probably not stable enouh for
that yet?
Cite?
And, by the way, what exactly where the effects of the SB
switch for EMM386? Would be cool if that stuff could be
At 01:22 AM 12/31/2004 -0800, 16BIT wrote:
Grub for DOS prints the following error message if I try and run it with
FreeDOS:
-
Sorry! Currently supported DOS versions are: MS-DOS 3.30 and later;
FreeDOS kernel build 2029 and, hopefully, 2032 and later.
-
A rather
At 12:54 AM 1/8/2005 +0300, Arkady V.Belousov wrote:
MD You'd get screen which
MD doesn't update after EMM386 loads.
Ie., current EMM386 doesn't check that such maping is wrong and, thus,
we get hanging machine (because all subsequent screen outputs will
overwrite code, which will loaded
At 12:34 AM 1/7/2005 +1300, Bart Oldeman wrote:
An extract from the patch in grub013.zip is below. It's far nastier. Very
nasty. It's code that assumes that the binary code of FD-kernel's IRQ
stack handling never changes, noone uses STACKS=0, and MS HIMEM may be
loaded (int15 hooked by himem.exe
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files
emmx14.zip, EMM386/HIMEM mostly executable package, and emms14.zip,
EMM386/HIMEM mostly source package.
This EMM386 version 1.14 update contains a number of revisions and is
generally recommended for everyone. It corrects
At 02:48 PM 2/9/2005 +0100, Robert Urban wrote:
USB-ZIP is generally documented on the net as the most compatible one to
choose for USB flash drive booting. It's the only selection that works
for
booting my USB stick here. But mine does boot up as a large A:, which you
might not find
At 09:39 PM 2/9/2005 +0100, Robert Urban wrote:
Not sure why you're having so many problems, although I admit that I hand
punched in a few values in the boot sector to make sure mine
booted. What's the brand and size of your flash drive? If I see one
locally and its cheap enough, maybe I'll
At 09:56 PM 2/16/2005 +0100, Eric Auer wrote:
If you use FreeDOS to load WinCE, please behave better than
Neoware.com which have hidden the FreeDOS copyright messages
on their old Eon systems (with FreeCOM 0.76b from 3/1999, FDXMS
driver from 1995, ancient kernel...). Their config sys just
loaded
At 10:23 AM 2/18/2005 -0800, Charlie Wilkes wrote:
MOO is one game that is pretty tender under
FreeDOS. I have only been able to make it work at all
with MS emm386.
Masters of Orion should work without problem under EMM386 as of most recent
1.14 version, although the accompanying bug in the
At 07:31 PM 2/18/2005 -0800, Charlie Wilkes wrote:
I worded my question poorly. What should the line in
my config.sys look like to play MOO?
Don't use NOEMS or FRAME=NONE options. EMM386 defaults will work, unless
you have an low memory machine of 8M or less. Then you should explicitly
use
At 05:05 AM 2/21/2005 -0800, Charlie Wilkes wrote:
Far out man! I just played Master of Orion for about
an hour and it worked great with this version. Not
good with mi.com, however... weird characters and a
manic counter spinning away at the very bottom of the
screen... BONG HIT! Gotta reboot.
At 10:57 AM 2/23/2005 +0200, Florian Xaver wrote:
Whatever MPXPLAY did, it's the first DOS application that actually played
sound files on my RealTek AC'97 machine, so they have impressed
me. Maybe somebody can convince them to list FreeDOS as a supported OS,
besides MS-DOS and DOSBox.
Yes,
At 06:44 PM 3/12/2005 -0800, root wrote:
Bernd Blaauw wrote:
FDXMS286 should have worked on your computer, and HIMEM probably should
have refused to load at all, as it currently cannot handle 286.
Great to see someone who can actually test/experiment on pre386 equipment.
I do not know if there
At 04:36 PM 3/13/2005 +0100, Bernd Blaauw wrote:
probably better, make HIMEM compatible to 286+, which would end up in a
single unified XMS driver.
Adamantly and permanently opposed. And you might be too, with the
potential size increase and performance decrease in HIMEM after the
significant
At 04:36 PM 3/13/2005 -0800, root wrote:
Yes, under every version of DOS that I'm aware of, HIMEM.SYS is an XMS
driver for 286 and above.
Not true of MS-DOS 7.x. FreeDOS reports as 7.10, also.
Most people that have/had a 386+ just run EMM386 in addition to HIMEM,
I'm assuming for the purpose
At 09:24 PM 3/15/2005 -0300, Carlos AB wrote:
The wiki site for Fd-doc is almost ready and I though it would be nice to
have your opinions, comments and help, before it goes public. So here is
the address:
http://fd-doc.sourceforge.net/pmwiki.php
Spread the word. :)
Improvement suggestion: In big
At 02:49 PM 3/18/2005 +0200, Kristaps Kaupe wrote:
I had problems with DJGPP (long compile times, mystical error messages) until
I removed FreeDOS EMM386 from my CONFIG.SYS.
Heavy port I/O and use of software interrupts are way too freaking slow in
V86 mode, no doubt about it. No way around it,
At 06:24 PM 3/18/2005 +0100, Eric Auer wrote:
Heavy port I/O and use of software interrupts are way too freaking slow in
V86 mode, no doubt about it. No way around it, either, as it's the nature
of V86 mode.
Not true - in Pentium and newer CPUs, you have VME, which allow
software interrupts
At 06:24 PM 3/18/2005 +0100, you wrote:
Not true - in Pentium and newer CPUs, you have VME, which allow
software interrupts and the interrupt enable flag to be handled
by hardware even for V86 tasks.
And following-up with a more accurate answer, no, your VME does NOT
help. You have to
At 03:41 AM 3/19/2005 -0300, Jose Antonio Senna wrote:
MDGNU-ish type stuff suffers from the we despise everything related to
MDMicrosoft and Not Invented Here syndromes, and its relationship with
DOS
MDis often uneasy. That said, DJGPP has never given me a problem when
MDtesting recent EMM386
At 01:26 PM 3/19/2005 +0300, Arkady V.Belousov wrote:
MD Could be interesting to add the required TSS fields and throw the VME
MD switch in EMM386. Then benchmark against non-VME and see if there is a
Just for information:
__O\_/_\_/O__
At 01:59 PM 3/19/2005 +0100, Eric Auer wrote:
Many illegal memory accesses in programs which won't fail under HIMEM will
fail with EMM386 loaded. EMM386 does not allow memory reads/writes
outside
of the actual PC memory range due to protected mode /V86...
You forget that the MEMCHECK switch
At 01:11 PM 4/15/2005 +0100, Roberto Waldteufel wrote:
Hi All,
No I am not using Himem.Sys or Himem.exe. I am writing for 32-bit
protected mode, so I need DPMI for the flat memory model, which in theory
should enable the use of all 4 GB of RAM on my system, not just extra high
memory in the
At 08:03 PM 4/24/2005 +0200, Fox wrote:
Hi,
I've installed recently FreeDOS on an friend's PC (Cel 850 / 384 MB SDRAM).
That PC have a Sound Blaster 64 PCI sound card and I have a big problem to
install its driver. The driver must be launched when HIMEM EMM386 are
installed, and it needs to have
At 03:52 PM 4/26/2005 +0100, Roberto Waldteufel wrote:
I have a system with 4 GB RAM and am aiming to write and execute programs
that will use as much as possible of this RAM while running in 32-bit
protected mode (via the GO32 program, linked into my code at compile
time). The main problem has
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files
emmx20.zip, EMM386/HIMEM mostly executable package, and emms20.zip,
EMM386/HIMEM mostly source package.
Version 2.0 of EMM386 supports sharing of extended memory between EMS, XMS,
and VCPI from a common pool. For most
Catching up...
At 01:23 PM 4/5/2005 -0700, Charlie Wilkes wrote:
I have been trying to figure out how to use this
program for basic drafting and rendering, running it
on 3 platforms -- win95osr2 DOS window, win98se DOS
window, and FreeDOS. It runs fine on the windows
systems but crashes in
At 12:56 PM 4/29/2005 +0200, you wrote:
Yes, BUT: You still forgot to compile with FORSYS defined, so prf.c still
outputs to BIOS instead of to (redirectable) DOS.
I didn't forget and I did look at the code. The #define explicitly
indicated for SYS files, use it the way it is set up. One of the
At 07:52 PM 4/29/2005 +0200, Eric Auer wrote:
Quite a while ago, when we had the same discussion, I showed you some
documentation (PC DOS stuff afair?) which explicitly states that you
can use int 21.01 ... int 21.0c at almost any time. That includes that
you can use them from within SYS files and
At 07:52 PM 4/29/2005 +0200, Eric Auer wrote:
Same for Jazz Jackrabbit (RTM/DPMI16BI) game and the
Jazz Jackrabbit DOS link goes to a Win32 version of the game. So much
for that guy.
GCUBE is one of those tarball atrocities. No thanks, unless you have an
already compiled and readily
At 07:52 PM 4/29/2005 +0200, Eric Auer wrote:
CTSTOAST 1996 demo (when started with DOS32a) hangs at once if pool
sharing is on.
AuGoS Go player (same DOS extender). For AuGoS, things are even worse:
Alright, I'm going to scream now. Augos.exe fails for me with a runtime
error EVEN IF I don't
At 10:37 PM 4/30/2005 +0200, Eric Auer wrote:
For me, it complains about my DOS4GW, but it runs okay in EMM386 1.15
as long as I start it with help of DOS32A.
At long last, a clue. Turns out your favorite DOS32A doesn't like it when
more than about 256M of VCPI is available. It either locks up
At 07:52 PM 4/29/2005 +0200, Eric Auer wrote:
GCUBE intro crashes on second call with EMM386 2.0: DOS tells that the
MCB at d0cf:0 has been zeroed out. Does not happen with EMM386 1.15...
Very trippy, that GCUBE, looks like a hi-rez television version of an 60's
acid trip. Well, it's a smoking
At 08:17 AM 5/1/2005 +0200, Eric Auer wrote:
Hi, I did extensive testing with HIMEM /max=... to limit the
amount of available XMS memory. The biggest value for /max which
works for me is 84992, one kilobyte more and ZIP starts to
crash (emm386 illegal instruction message, cs:ip at 0:b, ds=f,
At 02:07 AM 5/1/2005 -0500, I wrote:
Could be the sideways nibble that EMM386 does if it doesn't have a full
(1.5M * n) pool allocation block from a previous allocation. It tries to
eat 32K off an adjacent address free XMS handle and pass it over to the
currently used handle to fill out the
At 07:52 PM 4/29/2005 +0200, Eric Auer wrote:
More problems ahead. I tested several programs with EMM386 2.0,
setting X=TEST VDS. Many failed. Most of them did work, however, when I
added EMM=20480 to the settings, to disable the EMS / XMS / VCPI memory
pool sharing. Some programs still failed
At 10:22 PM 5/2/2005 +0200, Fox wrote:
Hi,
I tried the EMM386 v2.0, and there is a weird behave:
When I boot the PC, my apps works ok (I tested with JAZZ JackRabbit, LAME,
MPXPLAY and FastTracker 2). But when I quit the app and want to launch
another one from the list, the second app is freezing
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files
emmx201.zip, EMM386/HIMEM mostly executable package, and emms201.zip,
EMM386/HIMEM mostly source package.
EMM386 Version 2.01 is a bugfix release for Version 2.0. It is
required for everyone who has version 2.0, and is a
At 01:59 AM 5/2/2005 +0200, Aitor Santamaría Merino wrote:
Michael Devore escribió:
It should clear up your DOS extender problems, anyway. Except for
DOS/32A having a hard limitation of 256M VCPI. That bit of stupidity on
its part will take user intervention to circumvent.
Hi Michael,
I like
At 02:57 PM 5/3/2005 +0200, Fox wrote:
Jazz - don't ran. Just showed Unhandled exception 000E at 0020 1BEF ErrCode
0002, but not hanged.
Is this that Jazz Jackrabbit thing? You would be the second person
reporting a problem there. Any link to get the DOS version for me to
test? I Googled for
At 02:59 PM 5/3/2005 +0200, Eric Auer wrote:
todo.txt emm386.txt and emm386.lsm are all outdated
Not my file, not my file, and fully up to date.
Sorry. Did not mean to annoy you. So: Tom, could you update those files?
Thanks.
I don't know what you're talking about, actually. The first two
At 08:22 PM 5/3/2005 +0200, Fox wrote:
You found the Jazz 2 game, which is indeed for Windows.
Jazz 1 can be downloaded from http://www.dosgamesarchive.com/download/game/111
Jazz runs okay for me, at least as far as running the green rodent around
and shooting things. Only problem I have with
At 02:57 PM 5/3/2005 +0200, you wrote:
0002, but not hanged. Then I wanted to run RAR32 but it frozed up :(
The good news is that RAR32 is working at all (don't worked with the EMM386
1.5) :-)
RAR32 also runs okay for me IF I limit free XMS to 429M. If I have more
than 429M available, RAR32 say
At 03:16 PM 5/4/2005 +0200, Fox wrote:
When I load EMM386 with the VDS option and I want to listen to music (MP3)
with MPXPLAY (the DOS32 version) from CD-ROM, the sound is garbled. When I
listen from hard disk, it's ok.
The thing to remember about the VDS option is that it doesn't change
At 08:38 AM 5/4/2005 +0200, Roberto Mariottini wrote:
I don't think it's still available, because today the french site links to
Borland USA for downloads. So no more free french beer :-(
Still I have that copy of BP 7 downloaded legally, I can send it to you to
test it with your environment,
At 07:31 AM 5/4/2005 +0200, Fox wrote:
My CPU is a Celeron 766 MHz FC-PGA
Maybe it's ok because I gave you a link to the shareware version... (I have
the full one). I will pack my copy of the game and will send it to your ftp
(devoresoftware/incoming), so you will have exactly the same program as
At 08:38 AM 5/6/2005 +0200, Fox wrote:
On Thursday 05 May 2005 23:19, Arkady V.Belousov wrote:
What program reports occupied?
The FreeDOS MEM (it's the only program I know which i able to play with
memory
bigger than 64MB)
You'll need to post a MEM /X report and CONFIG.SYS. I don't know
At 04:52 PM 5/6/2005 +0200, Florian Xaver wrote:
As i understand, emm386 switches the pc into protected mode (so it needs
VCPI).Then... is it in V86 mode? So wouldn't it be possible to make a
better error handling. I mean, if a program hangs or so, that not the
computer hangs and that you can
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files
emmx202.zip, EMM386/HIMEM mostly executable package, and emms202.zip,
EMM386/HIMEM mostly source package.
EMM386 Version 2.02 is a stable release with small bug fixes over version
2.01 and compatibility enhancements. It
At 07:41 AM 5/28/2005 -0700, coralline algae wrote:
I am testing a program pari/gp which i downloaded from here
ftp://megrez.math.u-bordeaux.fr/pub/pari/dos/
only two files are necessary for the dos install
gpb_210.zip
gprt.zip
tested initially on freedos b9sr1 with emmx202.zip
version of
resent with address corrections for freedos-user list
At 05:54 PM 6/3/2005 -0300, Enrique Mora wrote:
Hi. I have a problem. When i use EMM386.exe and HIMEM.EXE all the programs
that I put in upper memory faild.
14?DOS=HIGH,UMB
4?DEVICE=C:\FDOS\FDXMS\FDXMS.SYS
At 04:51 PM 6/4/2005 +0400, Arkady V.Belousov wrote:
MD If X=TEST without I= and the VDS option don't change anything, the best
MD thing to try is to do a full exclude of all high memory as in X=A000-EFFF
MD (keep VDS too), in order to be sure that the problem really is with high
MD memory
At 09:13 PM 6/2/2005 +0200, Aitor Santamaría Merino wrote:
Michael Devore escribió:
At 03:07 PM 5/3/2005 -0500, I wrote:
Ha! What is up with these goofball extender limitations? RAR32 uses
RSX extender. I can't decide if there is a weird bug in EMM386 that
makes DOS/32A unhappy
At 01:34 PM 6/6/2005 -0300, Enrique Mora wrote:
Hi!! Thanks for help me!!
When i used umbpci the lh work correct but umbpci put only 122Kb in upper
memory and i need 150kb because i use PC/TCP packets for my program to
cumunicate whit a central server.
I can't help further until you tell us
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files
emmx203.zip, EMM386/HIMEM mostly executable package, and emms203.zip,
EMM386/HIMEM mostly source package.
EMM386 Version 2.03 is a minor update, recommended for those using programs
which are bound to the WDOSX DOS
At 04:48 PM 7/5/2005 -0800, Brolin wrote:
The DOS version of the OpenWatcom debugger (BINW\WD.EXE) behaves strangely
when using FreeCOM on Win98. There are no problems with WD when using
Win98's COMMAND.COM on Win98, nor are there problems when using FreeCOM on
FreeDOS rather than Win98.
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files
emmx204.zip, EMM386/HIMEM mostly executable package, and emms204.zip,
EMM386/HIMEM mostly source package.
EMM386 2.04 and HIMEM 3.11 are bugfix updates. HIMEM 3.11 is a recommended
update for all FreeDOS users. EMM386
At 03:29 PM 7/9/2005 -0800, Brolin wrote:
Michael Devore wrote:
WD is plain old goofy. It has had a slightly unstable reputation under
DOS for over ten years. You could be seeing nothing more than the OS
memory image having different byte values at a particular location(s), or
slightly
At 11:08 PM 7/10/2005 +, Mark Bailey wrote:
SWITCHES=/F
DOS=HIGH,UMB
DEVICEHIGH=a:\HIMEM.SYS /NUMHANDLES=128 /TESTMEM:OFF /Q
DEVICEHIGH=A:\UMBPCI.SYS
This is a strange example since DEVICEHIGH simply won't work (because it
can't) before upper memory is actually available. That won't
At 08:38 PM 7/11/2005 +0200, Eric Auer wrote:
Hi, the fancy windowed desktop which only contains a text editor
and some small tools and comes with 2 bmps for unknown reason GVEdit:
http://homepage.ntlworld.com/gvision/gv/gvedit.zip
... crashes for Blair with HIMEM and FDXXMS.
GVEDIT fails
At 01:31 PM 7/12/2005 -0400, Mark wrote:
OK, here is the config.sys file I used with emm386. Note
that including NOEMS on the command line causes the
installhigh to FAIL with:
DOS/32A fatal (1002): DOS reported insufficient memory
Well, the problem is here. You need the NOEMS option to free
At 02:11 AM 7/13/2005 +, you wrote:
Hi Michael:
Thanks again for the help. That didn't change the symptoms at
all from just using NOEMS...still get the error from DOS/32A!
What does DOSDATA=UMB do? I am booting from a USB floppy
drive most of the time...occasionally from a CD with a
At 08:23 AM 7/13/2005 -0400, Mark Bailey wrote:
OK. Development Kernel, Development command.com, Development SYS,
new emm386/himem, NTFS4DOS 1.4. The INSTALLHIGH failed.
Interestingly, a LOADHIGH failed with ALMOST the same error
and a little more information:
DOS/32A fatal (1001): DOS
At 04:14 PM 7/13/2005 -0400, Mark Bailey wrote:
Will try DOS=HIGH only. Thanks! Too bad UMBPCI doesn't
work on all the computers. :-(
Well, if DOS=HIGH doesn't do it, I may have to d/l NTFS4DOS myself, force
64K UMB, and see if I get the same fragmentation. Something bizarre going
on
At 01:24 AM 7/14/2005 +, Mark wrote:
FreeDOS, development kernel, command.com, sys
Newest HIMEM/EMM386
Conventional Memory639 384255
Upper64 4 60
If you e-mail me your copy of NTFS4DOS.EXE I'll see if the problem
duplicates
At 12:37 AM 7/21/2005 +0200, Bernd Blaauw wrote:
[EMAIL PROTECTED] schreef:
Meanwhile, personally, I don't recommend using FreeDOS FDISK! :-(
Mark
I hope you have the option of using FreeDOS FDISK running under as many MS
components as you can (kernel, shell, himem, emm386). A Win98
At 12:05 AM 7/21/2005 +, Mark wrote:
Make config.sys
a:\device=himem.exe
Reboot.
The DIR commands now work. Reboot again.
Kernel still recognizes the partitions. emm386.exe not run.
FDISK did NOT trash my MBR. Bare himem.
Doesn't make much sense. EMM386 is effectively out of the
At 03:11 PM 7/21/2005 +, Mark wrote:
I'll try that. I'm only willing to run this on the one computer...too
risky for any others. I'm not blaming fdisk, but do not consider
running it safe. If I do not run fdisk, the disk partition table does
not get destroyed!
Well, maybe I'm wrong and
At 04:01 PM 7/21/2005 -0500, I wrote:
When you invoke FDISK without arguments, it goes into the
Interactive_User_Interface() routine. That, in turn, asks about FAT32
support, via Ask_User_About_FAT32_Support() function. OK so far. After
that call -- without any further prompting -- FDISK
At 11:40 PM 7/21/2005 +, Mark wrote:
Are any of the tests that have been suggested (other kernels,
MS-DOS, ommitting VDS, trying UDMA2, older versions of
FDISK, etc.) going to help in getting this problem fixed? I have
a repeatable problem (always a good thing) and have, I think,
done a
At 08:36 PM 7/22/2005 +0100, Gerry Hickman wrote:
[EMAIL PROTECTED] wrote:
By the way, I consider this bug extremely serious.
I agree, and Michael's post would appear to confirm that FDISK is far from
read-only, but has this bug always been there, or is it only in recent
development
At 11:33 PM 7/23/2005 +, you wrote:
This may be a side effect of memory corruption with EMM386. In
fact, it appears to be a result of some interaction with EMM386.
I do not believe the hard disk in question is faulty and I do not
believe that it has non-standard parameters.
Doubtful.
At 03:29 PM 7/23/2005 +0100, Gerry Hickman wrote:
Biggest mitigating factors are that if your hard drive behaves without
errors, is reasonably standard with expected parameters, and there is no
corruption of the program, the MBR write on startup won't occur.
Ah, so this bug only happens with
At 01:29 AM 7/26/2005 +, Mark Bailey wrote:
I have another FreeDOS problem with NTFS4DOS. This one DOES
NOT affect MS-DOS (I think it's called 7.1...version from Windows98SE).
The problem is a divide error. Without himem.exe loaded, I get
Divide error
Happens on all the machines all
At 12:22 AM 7/28/2005 +, Mark Bailey wrote:
Help! How do I start to debug this?!?! This is the same machine
which has FDISK overwriting the partition table whenever it is run
with EMM386.
Exclude all high memory via X=A000-EFFF and add NOEMS option. Those two
options only, unless your
At 11:53 PM 7/28/2005 +, Mark wrote:
Do I need VDS? :-) What does it do? How can I help
identify the problem? I do have the Haunted HP Pavilion (TM)!
Turn it off if everything works without it. It's just for upper memory
reporting of true physical address instead of logical address
At 10:13 AM 7/29/2005 +, Mark Bailey wrote:
This appears to be the same bug that caused FDISK to
wipe out the MBR, so it at least appears that just initializing
the VDS functions is trashing something in memory.
No such thing. VDS functions just are, they don't initialize. Only thing
At 12:42 PM 7/29/2005 -0500, I wrote:
Ha! That's it. Some SCSI BIOS uses INT 4BH. It must be passing the
register value that VDS interprets as a VDS function, which means AH =
81h. Hmm, let me look things over to see if there's a way to resolve the
conflict by further determining the
At 02:58 PM 7/29/2005 -0400, Mark wrote:
Does this provide a means of easily identifying the affected
machines? How do I check the Haunted HP Pavilion? :-)
Here's what to do:
Go to ftp.devoresoftware.com/downloads/emm386 and download
EMMBLORT.ZIP. Try that version of EMM386.EXE with your
At 10:05 PM 7/29/2005 +0200, Bernd Blaauw wrote:
Michael Devore schreef:
Go to ftp.devoresoftware.com/downloads/emm386 and download
Let me know if that fixes or modifies the current behavior with VDS
parameter.
no change in VMware Workstation 4.5.2 (PC emulator, Intel P4 processor
At 03:07 AM 7/30/2005 +, Mark Bailey wrote:
VOL C: works normally. Without device=a:\udma2.sys,
vol c: hangs and forces a reboot. (That's the old behavior
which I checked to make sure of the test case).
This does not appear to be a seperate issue.
Actually it muddies the waters by
At 04:05 AM 7/30/2005 +, Mark wrote:
Well, the E000 message is repeatable on this box...
Thanks again for all of your help!
Well, we can check if your VDS vector is okay pretty easily. Try this with
the test EMM386 using VDS option. Don't type VOL first to crash things or
load UDMA.
1 - 100 of 193 matches
Mail list logo
