Review sources. himem64.asm contains setz instruction. This instruction
only available for 386+, whereas himem should be loadable on 286 also.
MD Further source review would show that HIMEM is for 386 only, as the
MD check_cpu routine shows. That's been a basic requirement of HIMEM since it
Arkady V.Belousov wrote:
MD Simply because many Open Source/FreeSoftware advocates believe that
MD developers should act a certain way towards source code does not mean that
MD it is what everyone else believes or should believe.
You _may_ not believe. There is Microsoft, which doesn't
At 06:25 PM 3/3/2004 -0300, you wrote:
Luchezar Georgiev escreveu:
[...]if anyone has this (or Pat's) book and wants to sell it to me, you're welcome
;-)
I would by one too. anywhere even with a credit card. I have already searched but
could not find it :(
Heh, how bad do you want it?
At 03:49 PM 3/9/2004 +0100, Erwin Veermans wrote:
But on my test-board (440BX) that I use for testing my NwDsk
boot disks EMM38664.EXE immediately hangs my machine.
My config:
Kernel 2033, 0.82pl3, Himem64 3.10
dos=high,umb
stacks=0,0
files=99
lastdrive=z
buffers=-32
When I add /verbose I see
A minor update to HIMEM64, next release slated to be the HIMEM, is available in the
directory at ftp://ftp.devoresoftware.com/downloads via ftp or direct link with most
browsers. The files are HIMEM64.ZIP, containing uncompressed HIMEM64.EXE and
HIMEM64S.ZIP, contain the modified source file
At 07:34 PM 3/10/2004 -0300, Alain wrote:
EMM386 will only allocate VCPI memory from the EMS memory pool. Making it
automatically use the XMS memory pool would require backdoor interaction
with HIMEM[64] and generally make things quite a bit more complex.
Of course, a DOS extender/extended
At 03:38 AM 3/11/2004 +0300, Arkady V.Belousov wrote:
Hi!
10-íÁÒ-2004 15:54 [EMAIL PROTECTED] (Michael Devore) wrote to
[EMAIL PROTECTED]:
MD What would you think about an EMM386 that decided to steal some of your XMS
MD memory at startup, just in case a VCPI-using program wanted it later on? I
At 08:02 AM 3/15/2004 +0200, Luchezar Georgiev wrote:
total(available) EMS 6(5) pages = 96(80) kByte
I'm going to pump up the default EMS allocated by 96K for NOEMS, which should always
leave at least a little bit for VCPI and give more for EMS internal tables with lots
of RAM, like you have.
At 09:52 PM 3/14/2004 -0600, Michael Devore wrote:
At 01:23 AM 3/15/2004 +, Bart Oldeman wrote:
Still have the same (exit) problem as last time. Also something weird is
going on with NOEMS now:
device=emm38664.exe noems /verbose
So for some strange reason emm386 thinks there are only 6(5
Latest test version of EMM386 is at ftp://ftp.devoresoftware.com/downloads in the
files EMM386.ZIP and EMMSRC.ZIP, as executable and source.
These version corrects a problem with memory corruption in UMB's using VCPI,
particularly notable with MCB panic errors.Non-DOS upper memory
At 08:30 PM 3/17/2004 +, Bart Oldeman wrote:
Latest test version of EMM386 is at
ftp://ftp.devoresoftware.com/downloads in the files EMM386.ZIP and
EMMSRC.ZIP, as executable and source.
These version corrects a problem with memory corruption in UMB's using
VCPI, particularly notable with
At 09:00 AM 3/17/2004 -0500, Adam Peart wrote:
I just tried out the new version, and I had the same problem as the previous version.
If I go emm38664.exe /noems, I get the message func 43, out 8800 0006 .
But if I use ems, then I get
mapping UBM's (16k each) at: d800 dc00
umb block 0
At 10:35 PM 3/17/2004 +, you wrote:
On Wed, 17 Mar 2004, Michael Devore wrote:
I suppose I could break up the ZIP to floppy sized units, but I'm not
real thrilled about trying it. I'd very much rather get the CD problem
fixed.
don't you have an old ISA network card you can put in the DOS
At 06:05 PM 3/22/2004 +, Bart Oldeman wrote:
On Mon, 22 Mar 2004, Michael Devore wrote:
I've tried QuickView Pro and a DOS extended PNG viewer and they both are
documented as using an LFB and work fine under EMM386, so we're dealing
with something beyond a simple LFB existence problem here
At 03:17 AM 3/24/2004 -0600, Michael Devore wrote:
Anyway, Duke3D runs in high resolution 800x600 mode now under EMM386. I just need to
add VMware detection for auto UMB exclusion, and then I'll put up the first release
candidate version of EMM386.
Incidentally, a note in case the person named
At 11:06 AM 3/26/2004 -0500, Adam Peart wrote:
Interesting results between noems ems. Before, noems wasn't working, but with this
version it does. With noems:
C:\mem
MEM: error: EMM call 41h
That's right. NOEMS turns off the page frame. Rest of the mem info looks reasonable.
Also, I ran
At 01:15 PM 3/26/2004 +0200, you wrote:
On Thu, 25 Mar 2004 23:45:13 -0600, Michael Devore wrote:
Second problem report: UDMA. Unfortunately UDMA 7.0 fails on my system across the
board, although it finds the controller and identifies it plus the two drives.
Under both HIMEM with and without
At 04:32 PM 3/26/2004 +0100, you wrote:
Hi, I installed the 24 March 2004 version of EMM386 and the test results
are very promising, although I still do not know why you have to use HIMEM
instead of FDXXMS (did not test HIMEM64. EMM386 binary is 30706 bytes). If
you use FDXXMS, system crashes as
At 11:06 AM 3/26/2004 -0500, Adam Peart wrote:
Also, I ran slowdown and it still crashes.
SLOWDOWN 3.10, (C) 1993-2002, Bret Johnson.
I added support for emulation of the WBINVD CPU instruction in EMM386. That appears
to be the last of what it needs, as SLOWDOWN was running on my system.
At 05:16 PM 3/27/2004 -0600, Michael Devore wrote:
NIOS should now successfully load, without any of previously documented EMS setting
restrictions. It may even work. Prior versions of EMM386 used the 24-bit mode of
LGDT and LIDT when V86-PM switching so that a program such as NIOS which used
At 12:18 AM 3/28/2004 +0100, tom ehlert wrote:
Michael,
MD Since you're the maintainer and overall big picture
MD operations man on EMM386
well - I was the programing guy. Now someone else stepped in, and he
has done GREAT. Now I'm left with administrative stuff ;)
MD and I've just been
At 05:34 PM 3/28/2004 +0300, Luchezar Georgiev wrote:
On Sat, 27 Mar 2004 15:23:44 -0600, Michael Devore wrote:
It's an ALi M5229, which is an Acer Labs Aladin IV+ TX PRO if that's what you mean.
I don't know a south bridge from a London bridge or a dental bridge, myself.
M5229
At 12:56 AM 3/29/2004 +0200, Bernd Blaauw wrote:
I'll try DEVICEHIGH with EMM386.
didn't Tom implement a basic VDS option?
DEVICE=EMM386.EXE VDS
I strongly recommend against using the VDS option. It apparently was broken before my
VCPI and UMB work and the UMB code I added at a minimum broke
At 05:16 PM 3/27/2004 -0600, I wrote:
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,
At 04:58 PM 3/29/2004 +0200, Bernd Blaauw wrote:
btw, is FRAME=NONE supported in EMM386.EXE rc2 ?
Not yet, looks like it should be. I'll see about it, read what MS docs say about the
option. Should be a reasonably quick add, since it's awfully close to NOEMS in a lot
of behaviors.
If there is anyone left out there whose version of HIMEM[64] reports using the KBC or
KBC-2 method (displayed at startup), please let me know if you can re-test under a
HIMEM code modification.
A user had an old 386 machine which was incompatible with HIMEM[64]'s current KBC
method. I had to
At 02:57 PM 4/6/2004 +0800, Johnson Lam wrote:
Hi Michael,
To avoid confusing, I re-download the HIMEM64 (Jan 16) / EMM386 (MAR
24) from your site and try again, the KBC A20 run properly (though it
beep continuously for 6 second) under:
I haven't uploaded the modified HIMEM64 source and EXE yet,
Uploaded to ftp://ftp.devoresoftware.com/downloads/ are the files HIMEM64.ZIP and
HIMEM64S.ZIP holding, respectively, an uncompressed test version HIMEM64.EXE and the
modified ASM source from last release HIMEM64, dated April 6, 2004.
The version of HIMEM64 modifies the order of the A20 method
At 09:52 PM 4/6/2004 +0800, Johnson Lam wrote:
I also have to put up the EMM386 with VCPI support final release in the next day or
two, along with actual programming work, so am running a little busy right now.
I misunderstand ... never mind, I'll keep waiting the new one.
(the archive in your
Great. Now that HIMEM is getting wider distribution to the eager hundreds or
thousands, I've additionally collected problem reports with buggy BIOS support for
BIOS method and a failing A20 always on method. It's like a dam busted somewhere
upstream.
For all those asking, reverting to the
At 08:37 PM 4/7/2004 +0200, Eric Auer wrote:
That said: The ratio of viruses in my spam folder sharply increased from
30-40 % on normal days to 65-80 % this week. I got about 250 NetSky T
since Monday. So everybody update their antivirus software and use a
NetSky removal tool (google for it).
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 10:52 AM 4/8/2004 -0400, Patrick J. LoPresti wrote:
It sounds like you cannot trust the BIOS status code, so you need to
test whether it really enabled/disabled the gate. Or, just tell the
user their BIOS is buggy and to get a new machine. :-)
I added enable/disable test, but the report was
At 02:46 PM 4/8/2004 -0400, Patrick J. LoPresti wrote:
Michael Devore [EMAIL PROTECTED] writes:
I added enable/disable test, but the report was that it still fails,
after working for the startup test. Which either means the BIOS is
bugged and fails under stress, or there is something very
At 03:10 PM 4/8/2004 -0500, Michael Devore wrote:
I'm not sure FreeDOS can assume HIMEM has the first shot at machine hardware in its
initial state. It certainly doesn't under VMware, which we have do FreeDOS users
running under. Does VMware reset A20 back to known disabled state at startup
At 03:33 PM 4/9/2004 +0200, you wrote:
missing:
emm386 documentation, specifically
VCPI specific NOFRAME/NOEMS/EMS=/...
options.
Generally, NOEMS and FRAME=NONE, etc. follow Microsoft's EMM386, so I'm not sure how
important that is to add docs anyway.
The two main differences that
At 04:58 PM 4/8/2004 -0400, Patrick J. LoPresti wrote:
Michael Devore [EMAIL PROTECTED] writes:
Although the new A20 test code should work, as it does fine in many
machines and the logic is sound.
I still think instruction reordering is a potential issue.
It might be, it's hard
At 09:31 AM 4/14/2004 +0200, tom ehlert wrote:
*** my conclusion ***
I hate A20 anyway - use always on if found to be on on startup
Good enough for me, I'll move an initial A20 always-on test to front of the method
line on next release.
At 11:47 AM 4/15/2004 +0200, Florian Xaver wrote:
Just tested the combination. Himem64.exe works perfect (seems so). But when i am
using emm386.exe, DUSE (USB driver for extern HDs, CDs etc.) only writes: DOS is in
protected mode and exits.
In the User Guide of DUSE there isn't wrote any
Uploaded to ftp://ftp.devoresoftware.com/uploads are himem64.zip (executable) and
himem64s.zip (source) for a new test release of HIMEM64 (morphing to HIMEM in official
releases). The files are dated April 18, 2004.
This version of HIMEM64 has three new options and greatly changed behaviors to
At 12:30 AM 4/19/2004 +0200, Bernd Blaauw wrote:
Michael,
thanks for the newer release.
I was surprised the /MAX: was in Kilobytes (expected Megabytes like /MAXMEM= has in
NT/2000/XP), but this way it does allow to finetune total memory, and thus for
instance, determine minimum amount of memory
At 05:56 AM 4/19/2004 +0200, Bernd Blaauw wrote:
Upper value should be 4194303, which is (4G / 1024) - 1. Not tested nearly that
high.
what happens for a too high value: ignored, or set to that (4G/1024 -1) value?
(basically same effect I guess..)
It's whatever is standard for out of bounds
At 11:03 PM 4/18/2004 -0500, Michael wrote:
At 05:56 AM 4/19/2004 +0200, Bernd Blaauw wrote:
Upper value should be 4194303, which is (4G / 1024) - 1. Not tested nearly that
high.
what happens for a too high value: ignored, or set to that (4G/1024 -1) value?
(basically same effect I guess..)
Uploaded to ftp://ftp.devoresoftware.com/uploads are a revised himem64.zip
(executable) and
himem64s.zip (source). The files are dated April 19, 2004.
This fixes a bug which occurs with the A20 methods PS/2, KBC, and Port 92. If your
machines use Always On, BIOS, or fast A20 methods, you
At 05:17 PM 4/19/2004 -0500, you wrote:
Uploaded to stupid address deleted are a revised himem64.zip (executable) and
himem64s.zip (source). The files are dated April 19, 2004.
Yes, for those several users more alert than I was and who caught the error, the
revised files are in directory
At 07:14 PM 4/20/2004 +0200, Bernd Blaauw wrote:
Michael,
how does that MAX work in HIMEM64?
it keeps complaining about /MAX:4000 ignored
I'm trying to reduce memory enough to not let the XMS-version of FreeCOM load in
extended memory.
DEVICE=A:\DRIVER\HIMEM64.EXE /MAX:4000
At 08:42 PM 4/20/2004 +0200, you wrote:
Michael Devore schreef:
I need to be able to get any application which uses EMS and fails. What is a TDSK
and can it be downloaded?
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/ramdisk/
1)NOEMS
2)NOEMS NOVCPI
3)EMS=1 FRAME=NONE
4)EMM=
At 04:41 PM 4/20/2004 +0800, you wrote:
Hi,
I just notice the TDSK and some EMS application report neither
controller fail or EMS corrupt by using HIMEM64+EMM38664.
There's definitely a weirdness going on with EMS, but not all EMS, since other
applications are using it okay. May have to quick
At 09:42 PM 4/20/2004 +0200, Bernd Blaauw wrote:
There's definitely a weirdness going on with EMS, but not all EMS, since other
applications are using it okay. May have to quick patch EMM386 if I can find it.
note that tdsk up to and including 2.3x series has sourcecode.
for problems with tdsk
At 09:42 PM 4/20/2004 +0200, Bernd Blaauw wrote:
note that tdsk up to and including 2.3x series has sourcecode.
Alright, I've added support for EMS function 58h in EMM386, and TDSK seems to be happy
running under EMS as well as the original XMS.
Big question for you, and any other interested
At 12:35 AM 4/21/2004 +0400, Arkady V.Belousov wrote:
Hi!
20-áÐÒ-2004 15:26 [EMAIL PROTECTED] (Michael Devore) wrote to
[EMAIL PROTECTED]:
MD Big question for you, and any other interested parties: Do you want me to
MD hold this version EMM386 and see if any other problems shake out of the
MD
At 04:41 PM 4/20/2004 +0800, Johnson Lam wrote:
Hi,
I just notice the TDSK and some EMS application report neither
controller fail or EMS corrupt by using HIMEM64+EMM38664.
Incidentally,if you get TDSK 2.3 past 32M and/or start playing around with the sector
and cluster sizes, TDSK has a strong
Uploaded to ftp://ftp.devoresoftware.com/downloads, yes downloads, are emm386.zip
(executable) and emm386sr.zip (source) fixing two minor problems with the official Tom
Ehlert release of EMM386. The files are dated April 20, 2004.
This version of EMM386 supports EMS 4.0 function 58h, so that
At 02:06 PM 4/21/2004 +0800, Johnson Lam wrote:
Also another application call BLASTER MASTER (Sound editor) also said
EMS Corrupt, I've asked the author, it become free now. I can email
or upload to your FTP if you want.
I grabbed Blaster Master off the web. Turns out that for it to run under
At 06:06 PM 4/21/2004 +0200, Eric Auer wrote:
Hi, if HIMEM64 crashes but FDXXMS PS does not, try the new
/VERBOSE and /METHOD:... command line options of HIMEM/HIMEM64
to find out which of the A20 methods cause the troubles.
You're replying to a glop of mail that was either held or retransmitted
At 01:10 PM 4/21/2004 +0100, Bart Oldeman wrote:
On Wed, 21 Apr 2004, Michael Devore wrote:
At 02:06 PM 4/21/2004 +0800, Johnson Lam wrote:
Also another application call BLASTER MASTER (Sound editor) also said
EMS Corrupt, I've asked the author, it become free now. I can email
or upload
The problem with HIMEM and XMSDSK running under a 2G machine has been resolved.
XMSDSK uses 1 XMS handler per 64M memory allocated. When there are no more XMS
handles, XMSDSK seems to fail checking for a return error code, leading to a crashed
PC. This appears to be a design flaw in XMSDSK.
At 12:05 AM 4/23/2004 -0300, Alain wrote:
Hi Michael,
I am not sure that I understand what you said:
1) I understand that _some_ old hardware had a reset bug (or wasit an old emm386?)
The original EMM386 used output to a port command to reset the PC on Ctrl-Alt-Del
keypress. It never
At 01:52 AM 4/25/2004 +0400, Arkady V.Belousovwrote:
Hi!
24-áÐÒ-2004 23:05 [EMAIL PROTECTED] (Eric Auer) wrote to
[EMAIL PROTECTED]:
EA EMM386 RAM= is well enough implemented if you make it an alias to X= if
EA you ask me.
Wrong.
X= will limit the range checked, same as RAM does, but
At 05:53 PM 4/25/2004 +0400, Arkady V.Belousov wrote:
Hi!
24-áÐÒ-2004 21:51 [EMAIL PROTECTED] (Michael Devore) wrote to
[EMAIL PROTECTED]:
I thought ram by itself meant dynamic EMS allocation as opposed to
allocating a fixed amount (at least, this is what the docs day), that's
how I use ram in M
At 11:36 PM 4/25/2004 +0400, Arkady V.Belousov wrote:
Hi!
25-áÐÒ-2004 11:02 [EMAIL PROTECTED] (Michael Devore) wrote to
[EMAIL PROTECTED]:
I thought ram by itself meant dynamic EMS allocation as opposed to
MD It's not documented that way on any EMM386 docs I see, including
EMM386 may be able
At 07:08 PM 4/25/2004 -0400, Patrick J. LoPresti wrote:
Michael Devore [EMAIL PROTECTED] writes:
I don't do kernel work, but depending on how much you want to dig in
the guts of the problem, you might want to grab the 386SWAT debugger
and load it immediately after the driver, with nothing else
At 04:03 PM 4/26/2004 -0400, Patrick J. LoPresti wrote:
Michael Devore [EMAIL PROTECTED] writes:
Is X=TEST really necessary? Unfortunately yes, at least for some
machines. There exist PC's which place ROM code in the upper memory
area, but without the standard ROM signature of 55h AAh
At 09:28 PM 4/27/2004 -0500, I wrote:
That's why I'd like to see the feedback conduit of Bugzilla -- and Tracker if it is
judged worthy of support -- made more attractive to the casual FreeDOS users.
Alright, after talking the talk, I walked the walk by responding to three open
Bugzilla
At 07:08 PM 4/25/2004 -0400, Patrick J. LoPresti wrote:
Michael Devore [EMAIL PROTECTED] writes:
I don't do kernel work, but depending on how much you want to dig in
the guts of the problem, you might want to grab the 386SWAT debugger
and load it immediately after the driver, with nothing else
on that particular
load/alloc behavior, you'll have to let me know not to load anything else
which uses UMB's
At 06:13 PM 6/18/2004 +0400, Arkady V.Belousov wrote:
Hi!
17-éÀÎ-2004 09:47 [EMAIL PROTECTED] (Michael Devore) wrote to
[EMAIL PROTECTED]:
2Michael Devore: Michael, try to initialize
software will
not work for me. I'm using kernel 2035 and I also tried reverting back to
kernel 2033.
I would greatly appreciate it if Michael Devore could send me an
EMM386.EXE HIMEM64.EXE that will enable me to load my SoundBlaster16 PCI
card drivers. SBINIT.COM in particular... or let me
At 01:15 AM 7/5/2004 -0500, I wrote:
DEVICE=C:\FDOS\BIN\HIMEMORY\EMM386 FRAME=NONE EMM=1024
Alternatively, a more flexible and graceful approach, but depends on the
driver being not totally stupid:
DEVICE=C:\FDOS\BIN\HIMEMORY\EMM386 NOEMS
---
At 07:45 PM 7/5/2004 -0700, you wrote:
From: Michael Devore [EMAIL PROTECTED] Re: Re: EMM386 VCPI/DPMI Help /
I'd probably need a card and a driver to duplicate the problem since I
don't have a DOS compatible sound card.
Not a problem. How where would you like me to send the card driver CD
Irrespective of the upwelling of love flowing from the topic and the fact
that people wish other peoples' dogs endure necrotic syphilis, I'd like, if
possible, to narrowly discuss an issue with developers and resolve it one
way or the other:
Should EMM386 remove its current code which changes
At 07:00 PM 7/6/2004 +0200, Aitor Santamaría Merino wrote:
By the way, it's long since I last watched the EMM sources, but I've
always thought that implementing RAM=/I=/X= couldn't be very difficult
with current sources, by just modifying a bit ScanSystemMemory(), the
current search range is
At 12:53 PM 7/8/2004 +0200, Erwin Veermans wrote:
I cannot oversee compatibility issues here and my interest would
be that whatever is choosen it should be most compatible for most
hardware around. So would it be an option to add an Arkady-A000
switch that will skip the A000-A001 ? Everybody
At 02:02 PM 7/9/2004 +0200, Eric Auer wrote:
One poster said that he would be surprised that no FreeDOS people
jumped the opportunity to help SpinRite, either for increased popularity
and fame of FreeDOS itself or to get something back from GRC personally.
Simple answer: GRC never asked the
At 07:45 PM 7/5/2004 -0700, Brian wrote:
Fix time, effort, and turnaround? Probably moderately easy if the driver
isn't depending on an advanced feature which FreeDOS EMM386 doesn't
support
(e.g. re-mapping the interrupt vectors or VDUs usage).
Thank You! I have every confidence that you can
At 05:09 PM 7/10/2004 +0400, Arkady V.Belousov wrote:
Hi!
8-éÀÌ-2004 22:10 [EMAIL PROTECTED] (Michael Devore) wrote to
[EMAIL PROTECTED]:
MD I only know of one original pmode CWSORT and it a) doesn't use DJGPP
and b)
MD uses a shell sort which doesn't consume indefinite amounts of stack.
1
At 05:15 AM 7/10/2004 -0400, Jeremy wrote:
Michael Devore wrote:
I'll make a bugfixed EMM386 available soon.
cool! Thank you for your all your work debugging these problems!
Jeremy
I'm soon to be off-line for the next 24-48 hours, but I'll post the revised
EMM386 on the ftp site, per usual, when
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
Still being generally tested. Too soon, unless there's a hard deadline to
meet. In fact, I've implemented one more workaround for a SoundBlaster
driver stupidity that chews up the debug interrupt.
At 12:30 AM 7/18/2004 +0200, Eric Auer wrote:
Hi, now that the new EMM386 / HIMEM combo seems to
At 10:40 PM 7/19/2004 +0800, you wrote:
error: Could not allocate code/patch RAM below 4 Mbyte boundary. Try
loading SBEINIT.COM before SMARTDRV.EXE or minimizing VDISK
RAM.
We had a short thread on this recently, but basically you have to give the
SB memory in the 4M range. That
At 09:34 AM 7/20/2004 +0800, Johnson Lam wrote:
error: Could not allocate code/patch RAM below 4 Mbyte boundary. Try
loading SBEINIT.COM before SMARTDRV.EXE or minimizing VDISK
RAM.
We had a short thread on this recently, but basically you have to give the
SB memory in the 4M
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
At 10:41 PM 7/22/2004 +0200, Eric Auer wrote:
Nice. One thing which I remember: XTree file manager had INT 3 (1 byte
opcode) as replacement for INT 21, both to make the code smaller and make
debugging harder. So that falls into the category (why NEWDES?).
NEWDES appears to be a case of the
At 02:34 AM 7/23/2004 +0200, Eric Auer wrote:
Please suggest some nice cozy place in low DOS RAM which can be used
by LBAcache as temporary stack while calling int 13.08, thanks.
I'm missing something here. Why can't you directly allocate stack memory
low at LBAcache startup? It's not that many
At 11:08 PM 7/22/2004 +0200, tom ehlert wrote:
if you didn't make VDS support significant more complete then it was
in the good old days of my code, I would disadvise to enable VDS by
default (no problem if it's an option)
VDS remains an option disabled by default, as it was originally. One
Just to tie up the loose ends...
At 04:35 PM 7/22/2004 -0500, I wrote:
Maybe it works in 2035, as it appears I'm still using 2034, but I doubt it.
Nope and
And may be fixed in 2035, too.
Nope. Both problems also exist with kernel 2035.
Should I get bored and no one else volunteers, maybe I'll
My final word on these. In the grand tradition of programmers everywhere,
I blame the applications themselves for the problems.
At 04:35 PM 7/22/2004 -0500, I wrote:
At 10:41 PM 7/22/2004 +0200, Eric Auer wrote:
GEOS Ensemble Lite - can you explain in what way it is FreeDOS
incompatible?
Ensemble Lite didn't go away after all. Someone here notified the Ensemble
person trying FreeDOS who, in turn, contacted me.
Originally, I got Ensemble Lite past its first error message by loading
SHARE, whereupon Ensemble later caused or encountered a hard
crash. Subsequent to the last
At 10:49 AM 7/28/2004 +0200, Aitor wrote:
Hi,
Well, I tend to be concerned about MS compatibility, but your arguments
are convincing. I was just thinking if it is sensible (I don't know,
opinions wellcome) to call the option /NOALTBOOT instead, so that those
that use this option get not
At 02:21 PM 7/28/2004 -0500, Jim Hall wrote:
Michael Devore wrote:
I would agree with Aitor - the /ALTBOOT option in FreeDOS EMM386 should
act the same as MS-DOS EMM386. Since this option is intended to work the
other way around, the /NOALTBOOT option seems a nice solution.
If there's a later
At 02:51 PM 7/28/2004 -0500, Jim Hall wrote:
Ok.
Since it's already been released, if it stayed as-is for now BUT IS
CLEARLY DOCUMENTED POST-1.0 when the option changed definition, that
should be fine for the end-users.
Just so people don't lose the big picture here: The majority of FreeDOS
At 04:42 PM 7/29/2004 +0200, Bernd Blaauw wrote:
why not use the ALTBOOT behaviour as-is now,
make the ALTBOOT parameter a dummy (like RAM)
and create the NOALTBOOT option.
then DEVICE=EMM386.EXE equals DEVICE=EMM386.EXE ALTBOOT,
and to get the opposite behaviour of these two, use
At 08:02 PM 8/23/2004 +0200, Eric Auer wrote:
Conclusion: I wrote to the list, suggesting that this might be an A20
related problem, and
suggesting to re-add Tom's invention, the refuse to actually disable A20,
to HIMEM (or EMM386: at least MS EMM386 locks the real A20 to on and uses
the paged
At 03:34 PM 8/24/2004 +0800, Johnson Lam wrote:
Verification needs to be either by my testing here or via a reasonably
detailed explanation by a reliable source as to why the feature is desired
or necessary. Alternatively, if you have incontrovertible proof that a
new EMM386 option is vital to
At 02:10 PM 8/24/2004 -0300, Alain wrote:
But, (is there always one?) does the RAM option fall within a
compatibility problem? I use it as default for one reason: I install it
on any client machine and I don't expect it to do any optimization, but to
provide _some_ UMB which ususaly makes a
At 10:31 PM 8/24/2004 +0800, Johnson Lam wrote:
Sorry for my stupidity, I really have no idea what's happen in SB
Emulation.
Last test is a failure. It always report cannot load something into
memory (I'll clean up the mess and post again).
SoundBlaster requires that you use an EMM= setting in
At 04:30 PM 8/24/2004 -0300, Alain wrote:
Michael Devore escreveu:
But, (is there always one?) does the RAM option fall within a
compatibility problem? I use it as default for one reason: I install it
on any client machine and I don't expect it to do any optimization, but
to provide _some_ UMB
Uploaded to ftp://ftp.devoresoftware.com/downloads is the file
share.zip. It contains a modified SHARE.C and uncompressed SHARE.COM
executable.
The changes to SHARE align it with the behavior expected from a DOS 7 share
utility by removing several conditions which previously returned an
At 02:05 PM 8/26/2004 +0800, Johnson Lam wrote:
On Wed, 25 Aug 2004 11:09:50 -0500, you wrote:
Hi Michael,
DEVICE=EMM386.EXE RAM EMM=1024
No, you have to add SB for the SoundBlaster workaround to be
active. Anything up to EMM=2030 or in that neighborhood should work too,
if you want more EMS.
At 06:48 PM 8/24/2004 -0300, Alain wrote:
So now I have something to wish for. It looks that the most compatible
_and_ safe behaviour is to map RAM to X=TEST, which was exactly your first
suggestion :)
Safest, but very incompatible with MS expected RAM behavior. Not the
reverse either, just
At 10:49 PM 8/27/2004 -0300, Alain wrote:
nothing - No UMB available, smaller lower memory, only for problematic cases
Nothing is the same as RAM with FreeDOS EMM386. UMB's are available and
auto-
I like this. Does MSDOS have UMB in this case? I allways understood that
it didn't...
In any case,
1 - 100 of 351 matches
Mail list logo
