Re: [Freedos-user] emm386, himem.sys, config.sys

[Rugxulo]

Hi,

On Wed, Oct 16, 2013 at 9:28 PM, Miguel Garza  wrote:
>
> I recently discovered Rufus, the DOS boot disk installer, and
> installed FreeDOS on my thumbdrive. I think it's pretty neat.

Yeah, it's cool.

> Anyways, what I am wondering is, I had come across PictView and tried
> viewing some images with it, but it gives an error and says something
> about not enough memory, will only display the first 54 lines. Then it
> loads the top 2% or so of the image.
>
> I randomly ran across references to emm386.exe. Would loading
> emm386.exe allow PictView to work? I'm assuming something must,
> otherwise PictView seems like a pretty useless program (no offense
> intended).

PictView wasn't written by anybody here. Or at least, I don't recall
ever seeing the author around. The website lists the "update"
(pv194upd.zip) as from "12/1/2000". You could try that if you're still
using "pictview.zip". I honestly don't anticipate further updates
(though one third-party guy said a rumor a few years back ... but I
guess that never happened). But if you're really convinced you found a
bug, maybe you could ping him.

The FAQ says this: "PictView is written mainly in assembler and it
runs on any 386 machine with at least 1 MB of RAM and a VGA adapter."
Though it goes on to mention XMS, which sounds correct (though I admit
to only rarely running pictview.exe as I'm no multimedia buff).

So no, that's not EMS, so you don't need EMM386 at all, AFAIK. You
only need the equivalent of HIMEM.SYS (usually HIMEMX or XMGR or FDXMS
or similar). The file "jemmex.exe" contains "himemx.exe +
jemm386.exe", but I'm not sure that's what you want either.

So yeah, like Louis said, put "DEVICE=c:\fdos\himemx.exe" or
"DEVICE=c:\fdos\xmgr.sys" in your CONFIG.SYS and try again.

But the problem(s) may lie elsewhere. Maybe you don't have enough
conventional RAM free, so try it without a lot of other TSRs loaded,
if you think that might help. BTW, one "bug" that seems to bite me is
it doesn't always seem to like 80x43, so I first have to manually
switch back to good 'ol 80x25 via MODE.

There are other image viewers for DOS, but most are old shareware. I'm
not sure if there is a single preferred viewer. It probably depends. I
don't frequently use a lot of that type of software, but I'm presuming
others here can offer better suggestions.

But just for completeness, here's what I'm thinking of (besides
pictview):   display, see, lxpic, paceplay, duglview, vgapaint, ombra,
... etc. etc. etc.

http://www.bttr-software.de/freesoft/0grpidx1.htm#graphics
http://www.reimagery.com/fsfd/graphics.htm

Well, Blocek (graphical text editor) can view images too, but again,
I'm not sure that's what you want. Any particular file formats or
resolutions you're trying to use?

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] emm386, himem.sys, config.sys

[Louis Santillan]

I don't know how RUFUS is setup, but if it is a FreeDOS distro, it
should have Jemm, or HimemX.  Set one of those up in config.sys.

-L

On Wed, Oct 16, 2013 at 7:28 PM, Miguel Garza  wrote:
> Hi,
>
> I recently discovered Rufus, the DOS boot disk installer, and
> installed FreeDOS on my thumbdrive. I think it's pretty neat.
>
> Other than occasional command-line use in Windows, the last time I
> probably messed with DOS was probably about 20 years ago. And I was
> certainly no programmer then.
>
> Anyways, what I am wondering is, I had come across PictView and tried
> viewing some images with it, but it gives an error and says something
> about not enough memory, will only display the first 54 lines. Then it
> loads the top 2% or so of the image.
>
> I randomly ran across references to emm386.exe. Would loading
> emm386.exe allow PictView to work? I'm assuming something must,
> otherwise PictView seems like a pretty useless program (no offense
> intended).
>
> --
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] emm386, himem.sys, config.sys

[Miguel Garza]

Hi,

I recently discovered Rufus, the DOS boot disk installer, and
installed FreeDOS on my thumbdrive. I think it's pretty neat.

Other than occasional command-line use in Windows, the last time I
probably messed with DOS was probably about 20 years ago. And I was
certainly no programmer then.

Anyways, what I am wondering is, I had come across PictView and tried
viewing some images with it, but it gives an error and says something
about not enough memory, will only display the first 54 lines. Then it
loads the top 2% or so of the image.

I randomly ran across references to emm386.exe. Would loading
emm386.exe allow PictView to work? I'm assuming something must,
otherwise PictView seems like a pretty useless program (no offense
intended).

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] EMM386 and other memory driver safety on mixed hardware - was: ... HP Compaq 6720s

[Eric Auer]

Hi everybody,

I agree that there is some controversy about EMM386 versus JEMM386
and JEMMEX... Basically the former had a focus on careful testing,
while the latter has a focus on "if it is cool for Japheth, it is
also likely to be enjoyed by other users". So the J drivers indeed
are more modern and fancy, yes :) On the other hand, they may have
less fool-proof default settings or even need advanced settings to
behave reasonably well in a one size fits all environment like the
one of Alain: He tries to give one complete working system to his
customers, which have a lot of variety in their hardware and have
no big experience in fine-tuning config or autoexec.

You know that I often say "if it does not work, try again without
EMM driver". This is not meant to blame the driver quality, but I
do think that it is hard for drivers to automatically do the right
thing with EMS and in particular UMB and alas I have to agree with
Alain that the old drivers tried harder to stay safe than J ones.

Also, modern hardware and firmware makes it hard to play safe with
UMB regions, too many unsafe areas are not tagged as such any more.



In a related topic, there are many ways to deal with the infamous
A20 and if you ask me, most software would just work with drivers
that first carefully try a few methods to switch it on, verify it
is on, then ignore further requests to switch it off. :-p A start
would be a config sys kernel option to make sure that only enable
but not disable requests are sent, but of course HIMEM, XMGR or
similar could also enforce this as described above. Would make a
good setting for one size fits all projects, I hope :-)



Finally, I agree with two more things from Rugxulo: If you X=all-
the-useful-UMB-space, why load EMM drivers at all? Most software
is happy with XMS if no EMS is available, so the main job of EMM
drivers today is to provide UMB space and if you have none, not
much use is left for them. On the other hand, EMM drivers can be
a very nice work-around for shaky A20: While EMM drivers are on,
the physical A20 is usually left enabled and the A20 activity to
be seen by DOS is just a simulation created by page table writes.

The second thing to agree with is that a discussion of the ins
and outs is more useful than just a warning - what went wrong?
What should change? Which experiences do the others here have?
What were the bugs in non-J-EMM386 which should be fixed in J?



>> On 2 new machines (last+this month) I had problems with X=TEST,
>> I made it work with
>>   EMM386 NOEMS X=C000-EFFF NODISABLEA20 NOVDS /VERBOSE
>> this was apparently due to some periferal in UMB not detected

The NOVDS and NODISABLEA20 options are both different topics than
the "avoid risky UMB areas" NOEMS X=C000-EFFF ones, so it would
be helpful to know which of the three ingredients were important.

Regards, Eric


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] emm386 expanded memory

[Charlie Wilkes]

Hi,

I have set up a freedos partition on my laptop, and I
am having a problem with expanded memory.  Mi.com says
"some programs might not recognize expanded memory
without a page frame" and indeed I cannot load Master
of Magic because it says I need at least 2,700k of
expanded memory.  I have tried the emm=4096 switch but
I can't get it to work.

The configuration I started with (emm386 with no
switches) worked fine on another machine, so I don't
understand what is going on.  Can anyone suggest how I
might tweak emm386 to solve this problem?

Thanks.

Charlie


  

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 new release 2.20, new HIMEM 3.20

[Michael Devore]

At 11:44 AM 7/28/2006 +0200, Norbert Remmel wrote:
> > Use X=A000-EFFF NOVDS
> >
> > Remove all device drivers.
> >
> > Then change and add as booting works.
>
>O.K. did it and found out the following...
>
>So far no pc crashes with vds disabled (I have not tested all pcs yet,
>but these having had problems this morning don't crash anymore when
>running emm386)

Alright, I assume you mean that you've re-enabled your UMB's by taking out 
the X=A000-EFFF option, but NOVDS is needed for things to work.  Otherwise 
VDS won't be an issue, since it's for remapped memory -- the UMBs -- and 
there won't be any UMBs present using X=A000-EFFF.

The problem is that latest EMM386 didn't change VDS code, so you've 
probably have a slightly different configuration than 
previously.  Something loaded high that wasn't loaded there before.  Or 
maybe in a different order.

You can verify that NOVDS is the solution by not loading any drivers in 
upper memory and see if it's still required.  NOVDS should not be needed 
with no drivers loaded high.

What would be best then is to see exactly which driver loaded high is 
causing the failure unless NOVDS is present.  If I can get a copy of the 
problematic driver I can run it under a debugger or disassemble it and see 
what VDS calls it's making.  Or if it has an basic incompatibility with 
being loaded in upper memory.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 new release 2.20, new HIMEM 3.20

[Jim Hall]

Michael Devore wrote:
> [...]
> This reply also tests whether SourceForge is only delaying freedos-devel, 
> since SourceForge sent my last freedos-user mail right to the list without 
> delay, while an earlier post to freedos-devel is still out there zipping 
> about the ether.
>   

SourceForge's site status page shows there's a known slowdown with email 
lists right now.

-jh


-- 
I'm sorry my president's an idiot. I didn't vote for him.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 new release 2.20, new HIMEM 3.20

[Michael Devore]

At 03:02 PM 7/28/2006 +0200, Eric Auer wrote:

>Would it be possible to have a test binary where the A20
>trick is disabled and another one where the IF trick is
>disabled? Then those, for whom the update makes things
>worse, could check which of the changes caused that.

A20 might be controlled though a new EMM386 option.  That's about as far as 
I'll commit to anything there.  I'd prefer it actually be off by default 
unless the option turns it on, but I suppose that would lead to many users 
asking why their old EXEPACKed stuff doesn't work and needing to be told to 
turn on the EMM386 option.

>However, dos4gw based things like CTS Toasted 96 demo and Descent still
>only work with dos32a. With dos4gw, they reboot or hang.

You're the only one I know who can't get DOS4GW to work.  As you know, it's 
was the first extender tested and continues to be first in-line when 
testing new releases.  It's also the one most people are most likely to 
complain about, and there are no angry mobs with torches descending upon my 
domicile.  Are you sure you don't have a bad EXE for it?  Do you know if it 
works anywhere on your machine under any VCPI-based DOS conditions (not 
Windows box, Windows box takes over most memory management there as DPMI).

>One interesting problem is that FDAPM FLUSH hangs now!

Alright, send me a link to latest FDAPM source.

>  Might be
>A20 related, but then why does it work if only HIMEM is
>loaded?

Several possibilities.  For one, A20 control might not successfully turn 
off A20 with HIMEM on your machine, but it's always going to happen with 
EMM386.  Or, the mapping 64K emulation has a subtle difference in 
behavior.   Or, it's haunted.

This reply also tests whether SourceForge is only delaying freedos-devel, 
since SourceForge sent my last freedos-user mail right to the list without 
delay, while an earlier post to freedos-devel is still out there zipping 
about the ether.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 new release 2.20, new HIMEM 3.20

[Norbert Remmel]

> Use X=A000-EFFF NOVDS
> 
> Remove all device drivers.
> 
> Then change and add as booting works.

O.K. did it and found out the following...

So far no pc crashes with vds disabled (I have not tested all pcs yet,
but these having had problems this morning don't crash anymore when
running emm386)

Concerning the microsoft network client I don't know how to do further
tests. Perhaps you can help.
Some machines work, some won't, but at this time it seems that the
client only stops at two points depending on the hardware: First when
trying to bind the TCP/IP and Netbios protocols to the adapter (calling
netbind.com) and second when trying to get an ip-address over DHCP.
These problems are not relying on the build in ethernet card, since for
example an onboard Intel PRO 1000 ethernet adapter works on one hardware
and on another it won't.

Any further ideas?

Norbert.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 new release 2.20, new HIMEM 3.20

[Michael Devore]

At 10:39 AM 7/28/2006 +0200, Japheth wrote:

>On my machine A20 is always enabled. BIOS int 15h reports kbd and "fast" PS/2
>methods being available, but none works to disable A20. IMO if A20 cannot be
>disabled in real-mode, emm386 shouldn't try to emulate "A20 disable" in 
>v86-mode.

I thought about that prior to the change, but I'm not convinced it's 
true.  A20 always on is because hardware vendors finally grew a backbone 
(much too late) and stopped supporting turning the thing off.  It's not a 
compatibility issue as far as the machine itself, or at least I don't see 
it being machine-specific.

Anyway, leaving A20 always on will always fail EXEPACK and the early PKLITE 
without LOADFIX on high free DOS memory machines.  Who gets blamed and 
flooded with bug reports by typical endusers who encounter that?  Not the 
hardware people and not Microsoft or any of the major software players 
active back when.  Nope, it's FreeDOS itself and FreeDOS developers who 
take the hit.  We may have too, but I hope to avoid it as much as possible.

[Gee, looks like SourceForge has delays in sending out list posts 
again.  What incredibly wonderful timing on its part.]


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 new release 2.20, new HIMEM 3.20

[Florian Xaver]

Hi,

thanks!

> I did some quick testing:
> Windows 3.1 /s still works well, as do various games - Jazz Jackrabbit,
> Raptor, AuGoS, others - and demos - Uneatable, Groovy, Gasoline, Rox...

Eric, "fdapm warmboot" (in QEMU) hangs with latest EMM386.

> However, dos4gw based things like CTS Toasted 96 demo and Descent still
> only work with dos32a. With dos4gw, they reboot or hang. Descent does
> work with dos4gw if emm386 is NOT loaded, though.

DOS32A extender seems to have problems too. MPXPLAY has a problem with  
keyboard  (QEMU).

> One interesting problem is that FDAPM FLUSH hangs now!
> It does work if only HIMEM is loaded and it does work if
> the old EMM386 version is used. Had no time to investigate
> but should be easy to reproduce on your test PC. Might be
> A20 related, but then why does it work if only HIMEM is
> loaded? So my next guess would be the IF patch. I had
> LBACACHE loaded but no DMA drivers during the test.

See above. I tested with UDMA driver.

> Last but not least I found an evil bug in FreeCOM: If you
> COPY things, possibly depending on whether source and/or
> target drive spec contain a drive letter, FreeCOM manages
> to overwrite the first 4 bytes of the full filename with
> what looks like 2 words of garbage (it displays the name
> because it shows a file access error). Then it often hangs.
> The decision whether a COPY action overwrites a file also
> seems to suffer from this.

FreeCM 0.84-pre2: What should "copy d: ." do? :-))
I wanted to copy the new himem.exe and emm386.exe with "copy d: ."  
(instead d:\*.*) to the FreeDOS
directory, old files should be overwritten. FreeCOM copied one file  
(emm386.exe). Is this ok?


> FreeCOM with LFN is definitely cool but things like those
> make me happy about still having 0.82pl3 as fallback :-p :-).

I don't like a base disc without DOSLFN and with LFN=N. Please include the  
LFN driver!

Bye

PS: Last tests were under QEMU (Windows), I haven't more time today and  
tomorrow for testing :-(
-- 
Florian Xaver

Webdesign, Sword (DOS GUI): 
oZone - desktop enviroment  f. DOS, Win, Linux: 
Dr-DOS  Wiki: 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 new release 2.20, new HIMEM 3.20

[Eric Auer]

Hi Michael!

> Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386/ are the files
> emmx220.zip, EMM386 version 2.20 memory manager, mostly executable files;
> and emms220.zip, source code files.

Thanks for the update!

> This release of EMM386 and HIMEM has several changes and fixes, two of a
> low-level nature, but at a guess, relatively few current users will be
> affected.  Two bugfixes in the advanced EMS 4.0 handle name function 54h
> were made. EMM386 added support for A20 control, allowing old EXEPACKed
> programs to work without LOADFIX.  A minor XMS free block fragmentation
> issue with EMS and VCPI was corrected. A fix to XMS API function 88h
> reporting highest memory address off by a teeny.  Due to changes in INT
> processing, QEMU should now work with EMM386 and CTMOUSE (this is untested).

Would it be possible to have a test binary where the A20
trick is disabled and another one where the IF trick is
disabled? Then those, for whom the update makes things
worse, could check which of the changes caused that.

I did some quick testing:
Windows 3.1 /s still works well, as do various games - Jazz Jackrabbit,
Raptor, AuGoS, others - and demos - Uneatable, Groovy, Gasoline, Rox...

However, dos4gw based things like CTS Toasted 96 demo and Descent still
only work with dos32a. With dos4gw, they reboot or hang. Descent does
work with dos4gw if emm386 is NOT loaded, though.

Lemmings 3d now works just fine, I think it worked worse with the
old EMM386 but had no time to test.

One interesting problem is that FDAPM FLUSH hangs now!
It does work if only HIMEM is loaded and it does work if
the old EMM386 version is used. Had no time to investigate
but should be easy to reproduce on your test PC. Might be
A20 related, but then why does it work if only HIMEM is
loaded? So my next guess would be the IF patch. I had
LBACACHE loaded but no DMA drivers during the test.

Last but not least I found an evil bug in FreeCOM: If you
COPY things, possibly depending on whether source and/or
target drive spec contain a drive letter, FreeCOM manages
to overwrite the first 4 bytes of the full filename with
what looks like 2 words of garbage (it displays the name
because it shows a file access error). Then it often hangs.
The decision whether a COPY action overwrites a file also
seems to suffer from this.

FreeCOM with LFN is definitely cool but things like those
make me happy about still having 0.82pl3 as fallback :-p :-).

Eric



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 new release 2.20, new HIMEM 3.20

[Japheth]

On my machine A20 is always enabled. BIOS int 15h reports kbd and "fast" PS/2 
methods being available, but none works to disable A20. IMO if A20 cannot be 
disabled in real-mode, emm386 shouldn't try to emulate "A20 disable" in 
v86-mode.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 new release 2.20, new HIMEM 3.20

[Michael Devore]

At 02:34 AM 7/28/2006 -0500, I wrote:
>Use X=A000-EFFF NOVDS
>
>Remove all device drivers.
>
>Then change and add as booting works.

Also, pure boot failure almost has to be A20-related.  Nothing else is 
related to vanilla-configured boot.  Manager, kernel, hardware, driver, 
application, something A20-involved.

I don't trust A20 control, even as an emulation.  It's a truly horrible PC 
hardware hack that they should have taken behind the barn and shot after 
80286 machines were released.  It will likely always cause compatibility 
issues at one level or another, and it may be that EXEPACK without LOADFIX 
support simply isn't worth the risk.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 new release 2.20, new HIMEM 3.20

[Michael Devore]

At 09:18 AM 7/28/2006 +0200, Norbert wrote:

>Do you have an idea, why the Pentium III machine is o.k. now and the
>others not?

Use X=A000-EFFF NOVDS

Remove all device drivers.

Then change and add as booting works.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 new release 2.20, new HIMEM 3.20

[Norbert Remmel]

> Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386/ are the files
> emmx220.zip, EMM386 version 2.20 memory manager, mostly executable files; 
> and emms220.zip, source code files.

Thank you for the new release.

While testing I discovered the following...

Do you remember the pentium III machine with 3COM 905B 10/100 PCI
ethernet adapter? It's fully working now!!!
Microsoft Network Client successfully initializes and logs on to domain.

But a lot of machines that worked with your last version 3.13 won't work
anymore.
The second machine I mentioned in my last posts about emm386 completely
stops responding while initializing emm386 throwing out error messages
this fast on the screen, that I can't read what might be wrong. The only
thing I can see, that there's ouput of some registers like eax. Stopping
of these error messages isn't possible by pressing "Pause", "Ctrl-Break"
or "Ctrl-C".

Another machine (Pentium 4 2,4GHz, Phoenix BIOS, 845G Chipset, Intel
Extreme Graphics onboard) also stops responding while starting emm386.
No keys can be pressed and the floppy light doesn't stop flashing.

Some other machines stop responding while trying to get an IP-address
over DHCP.

Do you have an idea, why the Pentium III machine is o.k. now and the
others not?

Norbert.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] EMM386 new release 2.20, new HIMEM 3.20

[Michael Devore]

Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386/ are the files
emmx220.zip, EMM386 version 2.20 memory manager, mostly executable files; 
and emms220.zip, source code files.

This release of EMM386 and HIMEM has several changes and fixes, two of a 
low-level nature, but at a guess, relatively few current users will be 
affected.  Two bugfixes in the advanced EMS 4.0 handle name function 54h 
were made. EMM386 added support for A20 control, allowing old EXEPACKed 
programs to work without LOADFIX.  A minor XMS free block fragmentation 
issue with EMS and VCPI was corrected. A fix to XMS API function 88h 
reporting highest memory address off by a teeny.  Due to changes in INT 
processing, QEMU should now work with EMM386 and CTMOUSE (this is untested).

Four of these five issues were found by Japheth.  In keeping with my past 
unilateral and officially unsanctioned declarations, I hereby proclaim 
Japheth to be FreeDOS Contributor Of The Month.  All hail Japheth.

A glutton for further information?  Read on.

EMS 4.0 function 54h subfunction 0, get all handle names, didn't place 
correct information in the returned buffer.  Subfunction 1, search for 
handle name, was naughty and failed to search the right string.  However, 
almost nothing uses the advanced EMS handle name management -- besides the 
test program used, I think I've seen exactly one EMS-based program which 
would use the functions, but not critically depend on them -- so the 
bugfixes are mostly for forms sake.

EMM386 now supports the global and local A20 control functions.  Previously 
it would inhibit A20 disable so as not to map itself out during its 
operation, turning the computer into an inefficient bread toaster.  Rather 
than actually turn off A20, EMM386 simply maps the first 64K address space 
into the HMA area on an A20 disable call.  This approach allows EMM386 to 
keep working while allowing it to support programs which were compressed 
with the annoying EXEPACK, since EXEPACK counted on wrapping from high 
addresses to low addresses and the FreeDOS kernel adjusts for that by 
turning on and off A20.  Eric Auer provided most of this idea, so he is 
declared runner-up FreeDOS Contributor.  I think the prize for that is a 
pack of stale chewing gum, but I haven't checked the rules recently.

Note that A20 control functions do give one an interesting new way to crash 
the computer should one fool with them indiscriminately, since mapping out 
the HMA memory when DOS Is loaded leaves a nice 64K hole filled with 
garbage where most of DOS used to live.  Also note that to do this, an 
unused EMS function (3fh) was co-opted for FreeDOS use.  That's the way 
QEMM does it, and I figured if QEMM can do it, so can we.

The EMS/VCPI allocator in EMM386 will now walk XMS blocks after freeing a 
shared XMS block and trying to merge any adjacent free blocks it 
finds.  Previously, fairly minor fragmentation of the free block area could 
occur.  While this would not cause failure of applications, it could prove 
annoying to advanced programmers or programs.

XMS function 88, highest memory address was still not quite right.  It 
usually reported one byte too high of an address.  Actually, the whole 
lower word was being zeroed, but since most memory comes in 64M increments, 
that part of the problem was never noticed and only the highest+1 byte bug 
would be seen.  I don't think many, if any, programs use this value, but it 
was sloppy coding that broke spec and needed fixing.  I blame my 
garbageman.  Not that my garbageman wrote or had anything to do with the 
code whatsoever, but I haven't blamed him for anything yet, and he'll never 
know.

EMM386 properly turns off the real mode INT flag inside it's protected mode 
processing  routines before transferring to the interrupt.  Hopefully Qemu 
now works with CTMOUSE.  Feedback on that point is appreciated.  That's the 
only thing reported which is affected by the change, although theoretically 
other situations may exist.  Probably do.  Like the song says, it's a big 
old goofy world.

Oh yes, I changed two comments in EMM386C.C from /* to #if 0.  Not because 
I think it really needed to be done, or because I think it's of much 
use.  No, I did it because I am broken and feeble old man who ran out of 
jokes for why not to do it long before its cheerleader(s) ran out of pixels.

Since low-level changes were made to this version of EMM386, please keep an 
eye out for any problems and report them as soon as you can.  While I don't 
anticipate new problems, I certainly recognize the perversity of the 
universe to make them happen.  It's possible that the expanded A20 function 
support, the IF status modification, or coding changes will wreak havoc in 
one fashion or another.  I'll post a quickfix release if anything 
immediately crashes in a semi-spectacular way.

Will this version of EMM386+HIMEM be in the initial FreeDO 1.0 release?  I 
dunno, but judging by the announcement, I'd guess n

[Freedos-user] EMM386 2.11 minor update, VDS fix

[Michael Devore]

Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386/ are the files
emmx211.zip, EMM386 version 2.11 memory manager, mostly executable files; 
and emms211.zip, source code files.  2.11 is a minor update from 2.10 -- 
minor, of course, unless you need it.

EMM386 2.11 fixes a problem with a few VDS routines where general registers 
would be unexpectedly changed from their entry values.  If you needed to 
put the NOVDS option in your EMM386 command line to make it behave, or if 
EMM386 didn't work for you and you didn't know to try the NOVDS option, 
this fix may help.  If the NOVDS option didn't fix things in prior EMM386 
releases, 2.11 isn't going to help you.   If you don't know what the heck 
VDS is, and things are working okay, you probably don't need the update.

Please remember to first try the X=TEST option if you're having problems 
with EMM386.  It clears up many problem reports.  I probably should create 
a detailed write-up of how to trouble-shoot common EMM386 problems, if I 
can figure out how those newfangled wikis work.

That is all.



-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 causes Ctrl-Alt-Del to fail with some video cards

[chris evans]

It probally general protection fault interaction between the vesa 3.0 
video driver and the memory mapped regions that video card wants to 
access.  Have EMM386 exclude the memory area a000-h.


--chris
http://nxdos.sourceforge.net/

John Hupp wrote:

Hello, all.  Here is another issue arising from my check-out of the 
new Service Release 2.
 
I find that loading EMM386.EXE can cause Ctrl-Alt-Del to fail.  I boot 
fine, then press Ctrl-Alt-Del from the DOS prompt.  The screen goes 
black, but the video and system BIOS boot messages never reappear.  
Very occasionally the keyboard is locked altogether and does not 
execute Ctrl-Alt-Del.






---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 causes Ctrl-Alt-Del to fail with some video cards

[Michael Devore]

At 06:15 PM 4/14/2006 -0400, you wrote:
Hello, all.  Here is another issue arising from my check-out of the new 
Service Release 2.


I find that loading EMM386.EXE can cause Ctrl-Alt-Del to fail.  I boot 
fine, then press Ctrl-Alt-Del from the DOS prompt.  The screen goes black, 
but the video and system BIOS boot messages never reappear.  Very 
occasionally the keyboard is locked altogether and does not execute 
Ctrl-Alt-Del.

I trigger the problem even with this minimal DOS configuration:

CONFIG.SYS (from either the hard drive or floppy)
DOS=UMB
DEVICE=C:\FDOS\BIN\HIMEM.EXE
DEVICE=C:\FDOS\BIN\EMM386.EXE


That's not minimal.  Recommended minimal is EMM386 X=TEST.  Most minimal 
would be EMM386 NOEMS NOVDS X=A000-EFFF.


You should also try NOALTBOOT option since you're having problems with 
Ctrl-Alt-Del.  ALTBOOT is the default condition.





---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] EMM386 causes Ctrl-Alt-Del to fail with some video cards

[John Hupp]

Hello, all.  Here is another issue arising 
from my check-out of the new Service Release 2.
 
I find that loading EMM386.EXE can cause 
Ctrl-Alt-Del to fail.  I boot fine, then press Ctrl-Alt-Del from the DOS 
prompt.  The screen goes black, but the video and system BIOS boot 
messages never reappear.  Very occasionally the keyboard is locked 
altogether and does not execute Ctrl-Alt-Del.
 

The problem seems to be related to interaction with 
certain video cards - perhaps just PCI cards or cards with a BIOS.  I had 
the problem with these cards:
- Diamond Stealth 64 DRAM PCI v2.09 (S3 Trio64 
chip) circa 1994-95 - confirmed with two identical cards
- ATI 3D PCI (Rage LT Pro AGP chip) circa 
1998-99
 
I did not have the problem with these 
cards:
- Diamond Viper PCI v3.08 (Weitek Power 9000-9001 
chipset) circa 1993-94
- ATI Mach64 PCI (ATI Mach64 chip) circa 
1994-95
- unbranded PCI card (Avance Logic ALG2302 chip) 
age unknown
- Trident 9680 PCI (Trident TGUI9680 chip) circa 
1994-95
 I trigger the problem even with 
this minimal DOS configuration:
 
CONFIG.SYS (from either the hard drive or 
floppy)
DOS=UMB
DEVICE=C:\FDOS\BIN\HIMEM.EXE
DEVICE=C:\FDOS\BIN\EMM386.EXE
 
(I tried various combinations of EMM386 options: 
NOEMS, X=Test, VDS)
(I also tried SWITCHES=/E/F/N)
 
AUTOEXEC.BAT: none
 
Further as-tested system info:
- M Tech R534F Super Skt 7 AT-style mobo with SiS 
5571 chipset
Pentium 100
16 MB
(2) 2.1 GB FAT32 partitions
CD-ROM
floppy
AT keyboard (NOTE: I tried a different known-good 
keyboard to eliminate that possibility)
no mouse connected
 
--John Hupp

Re: [Freedos-user] EMM386 2.08/Nomyso 2.0 Available

[Michael Devore]

At 08:37 PM 12/3/2005 +0100, Bernd Blaauw wrote:


Another victim / testcase could be UMBPCI, as it's written in TASM.
Either the 1995 version, or Uwe Sieber's current one
(sources only available on request)


My interests lie in converting sources which could help people without 
destroying the original source setup, so old unused source isn't that 
interesting.  If one has to go ask the maintainer for the current source, 
he must be comfortable using TASM for the latest releases.


I'll try to fix trouble if it's out there creating problems, but knocking 
on trouble's door and inviting it to come out and bite me seems a bit extreme.





---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.08/Nomyso 2.0 Available

[Michael Devore]

At 01:27 PM 12/3/2005 -0600, I wrote:

The three people following to this point might wonder why Nomyso doesn't 
just eliminate the 'DWord' in the $DEFINE statement and eliminate the 
problem.  Well, you can't automatically do that because the DWORD would be 
necessary in some cases where you might use the %define'd _ScreenArea, such as:


mov eax,_ScreenArea


Correction.  The 'mov eax,_ScreenArea' instruction would work without the 
DWORD attribute because the data size is known through the register size.


Other instructions such as 'push _ScreenArea' would not work without the 
DWORD attribute because NASM doesn't know the size of data to push without it.





---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.08/Nomyso 2.0 Available

[Bernd Blaauw]

Michael Devore schreef:

At 11:02 PM 11/28/2005 -0800, Blair Campbell wrote:


I would personally really appreciate the ASM in FreeDOS HELP being a
test case, as this assembler won't even compile with Arrow Assembler
or the Watcom Assembler (which both use older MASM/TASM syntax,
afaik).

Another victim / testcase could be UMBPCI, as it's written in TASM.
Either the 1995 version, or Uwe Sieber's current one
(sources only available on request)

Bernd



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.08/Nomyso 2.0 Available

[Michael Devore]

At 11:02 PM 11/28/2005 -0800, Blair Campbell wrote:


I would personally really appreciate the ASM in FreeDOS HELP being a
test case, as this assembler won't even compile with Arrow Assembler
or the Watcom Assembler (which both use older MASM/TASM syntax,
afaik).


The only ASM file I found in FreeDOS HELP was conio.asm.  It substantially 
converted with Nomyso 2.0 as-is.  There remained three problem areas: local 
labels in macros, improper bracketing in certain circumstances, and DGROUP 
group listing.


I fixed the local label in macro situation, and the DGROUP problem.  The 
bracketing was made a bit more robust.  In doing so, I discovered an error 
in the original Nomyso 2.0 for EMM386 which fortunately was minor: the 
_pause macro which isn't used in normal build had a memory reference error, 
and the very seldom used SB option code translated one line 
improperly.  Neither problem should affect people who would develop with a 
translated EMM386, but they're fixed now for next Nomyso.


The bracket problem highlighted one of the fundamental reasons you can 
never fully automate the translation process for all MASM/TASM source files 
.With the line:


_ScreenArea EQU DWord Ptr _ScreenOffset

translated to:

%DEFINE _ScreenArea DWord [_ScreenOffset]

things will still fail under NASM for lines like:

les di, _ScreenArea

Why?  Because NASM won't take a DWORD attribute for a 'les' argument, even 
though it IS a DWORD being used.  In fact, I tried different combinations 
of DWORD, WORD, NEAR, and FAR, and NASM won't take any of them.  I think 
that's a bug in NASM, but I can't figure out what it really thinks it 
should take as an attribute, so who knows.


The three people following to this point might wonder why Nomyso doesn't 
just eliminate the 'DWord' in the $DEFINE statement and eliminate the 
problem.  Well, you can't automatically do that because the DWORD would be 
necessary in some cases where you might use the %define'd _ScreenArea, such as:


mov eax,_ScreenArea

However, because I am insane, I added the ability to fully automate the 
conio.asm conversion by adding a -x option to Nomyso, allowing 
post-processing lines with s// regular expressions.  Consequently, with the 
current (unreleased) Nomyso:


 ./nomyso/pl -x'/(%define\s+.*\s)dword\s+(.*)/$1$2/i' conio.asm nconio.asm

conio.asm is fully translated and NASM ready following the problematic 
DWord purge by that demented 'x' option.  NASM -O99 -f obj nconio.asm is happy.


I can't say whether the translated conio.asm actually works along with all 
its C source, but it does assemble without errors.  If you want the latest 
Nomyso immediately for converting conio.asm, let me know.  Otherwise I'm 
going to wait and see if the ATAPICD translation needs any non-major 
changes to Nomyso before releasing a new public version.





---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.08/Nomyso 2.0 Available

[Michael Devore]

At 07:15 PM 12/1/2005 +, Gerry Hickman wrote:


What we do know is this:

2. EMM386 with SCSI controllers and VDS enabled is completely unusable and 
should never be tried outside the test lab.


What?  Completely untrue.  More like 2.  EMM386 with SCSI and VDS works on 
all tested systems, but unverified reports are that there are problems with 
some SCSI setups.


3. EMM386 used with SCSI without VDS appears to work, but no one would 
trust it in a business production environment, but for testing and home 
PCs it seems fine.


Nonsense.  I could make the same claim about trusting DOS itself in a 
business production environment because of its lack of operating system 
protection.


I realize you personally have had some problems with EMM386 that cannot be 
duplicated elsewhere, but I would appreciate you not posting things these 
claims.  They are inaccurate and needlessly damaging to proper 
distribution, use, and testing of EMM386 by endusers.


By the way, EMM386 can always give a system more upper memory than UMBPCI.




---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.08/Nomyso 2.0 Available

[Gerry Hickman]

Blair Campbell wrote:


Speaking of bugfixes, a person on FreeDOS IRC has mentioned many times
that the latest versions of HIMEM/EMM386 won't work with certain hard
drives, but will work with others.  AFAIR, he also says that NOVDS
does nothing to change this.


Sorry, but "mentioning it on IRC many times" with zero technical 
background is NOT the way to get these things working. This person needs 
to post on here with exact FDCONFIG.SYS, controller model/firware, 
hard-drive model, and definition of "won't work". For a start we need to 
know whether they're talking about "hard drives" or "controllers"?


What we do know is this:

1. HIMEM is rock solid with a huge range of ATA/SCSI/SATA controllers 
and just about any make of hard drive.


2. EMM386 with SCSI controllers and VDS enabled is completely unusable 
and should never be tried outside the test lab.


3. EMM386 used with SCSI without VDS appears to work, but no one would 
trust it in a business production environment, but for testing and home 
PCs it seems fine.


4. EMM386 with IDE/ATA is probably fine, and anyway if the machine has 
IDE/ATA it's probably not a very important machine.


5. EMM386 with SATA - I've never tested this.

If you have mission critical machines, they'll probably have SCSI and in 
that case I'd recommend HIMEM with UMBPCI. I've tested this on a huge 
range of hardware, servers, clients, SCSI, ATA, SATA and I've not seen a 
single problem. It also gets round some strange issues you sometimes see 
when the prog don't like prot-mode. One I can think of is Partition 
Magic under DOS which does not like EMM386 to be loaded, complaining 
there's only 32Mb of RAM because of it.


--
Gerry Hickman (London UK)


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.08/Nomyso 2.0 Available

[Michael Devore]

At 11:52 PM 11/29/2005 +1300, Bart Oldeman wrote:


On Mon, 28 Nov 2005, Blair Campbell wrote:


PS:  If the C is ever to be compiled with Watcom C, as Bernd
suggested, the global functions in the asm would need to have a _ in
front instead of behind, as this is (for some weird reason) the way
OpenWatcom does things.


I think you have this the wrong way around.

The reason is not so weird, as it avoids severe bugs interfacing. The _ is 
put the other way because the calling convention is different, so just 
changing the _ isn't enough, you also need to convert stack to register 
parameter passing.


Moot point with EMM386, I believe, since it does not pass 
function/procedure parameters between the ASM portion and C portion.  It is 
only a variable- and address-based communication.  EMM386 should be 
impervious to stack and register issues for C passing conventions as long 
as the names match up.


Obviously there are many other applications interfacing C and assembly 
language which pass parameters across the languages and do need to consider 
the naming conventions (although naming compliance could conceivably be 
automated via a user-selectable translator option, as well).





---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.08/Nomyso 2.0 Available

[Michael Devore]

At 11:02 PM 11/28/2005 -0800, Blair Campbell wrote:


Speaking of bugfixes, a person on FreeDOS IRC has mentioned many times
that the latest versions of HIMEM/EMM386 won't work with certain hard
drives, but will work with others.  AFAIR, he also says that NOVDS
does nothing to change this.


Possibly one of the SCSI drivers, but without a test machine to see what's 
in conflict, nothing I can do.  All the SCSI drive machines I've been able 
to test with now work with EMM386.


Also, I've found some people allow too many memory areas in upper memory 
and trash BIOS drivers.  Either they I= include too much, or X=TEST can't 
catch quite everything.  Best way to determine if upper memory conflict is 
present is to temporarily X= the entire upper memory range and see if the 
problems persist or go away.  Then narrow down the range which needs to be 
excluded.



BTW, with NASM, does optimizing EMM386 or HIMEM for newer CPUs result
in smaller object files?


That would be a coding instruction-based optimization, rather than an 
assembler style based optimization.  I don't think there is all that much 
above a 386 instruction level which would help HIMEM/EMM386, plus you 
either ruin 386 compatibility or you get into CPU versioning of the 
programs, which sounds horribly messy.





---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.08/Nomyso 2.0 Available

[Bart Oldeman]

On Mon, 28 Nov 2005, Blair Campbell wrote:


PS:  If the C is ever to be compiled with Watcom C, as Bernd
suggested, the global functions in the asm would need to have a _ in
front instead of behind, as this is (for some weird reason) the way
OpenWatcom does things.


I think you have this the wrong way around.

The reason is not so weird, as it avoids severe bugs interfacing. The _ is 
put the other way because the calling convention is different, so just 
changing the _ isn't enough, you also need to convert stack to register 
parameter passing.


If you want a _ in front with OW, and stack calling conventions, like 
Turbo C, all you need to do is to decorate the function with _cdecl in the

C or H file.

Bart


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.08/Nomyso 2.0 Available

[Blair Campbell]

> I anticipate that Version 2.08 of EMM386 is the final non-bugfix release I
> will create (bugfix versions will continue, as necessary).  I've

Speaking of bugfixes, a person on FreeDOS IRC has mentioned many times
that the latest versions of HIMEM/EMM386 won't work with certain hard
drives, but will work with others.  AFAIR, he also says that NOVDS
does nothing to change this.

> .  If any of you have suggestions for an open source application written in
> MASM or TASM which could use an automatic conversion to NASM, let me know
> and I'll consider making it the test case for Nomyso version 2.5 or 3.0.

I would personally really appreciate the ASM in FreeDOS HELP being a
test case, as this assembler won't even compile with Arrow Assembler
or the Watcom Assembler (which both use older MASM/TASM syntax,
afaik).

BTW, with NASM, does optimizing EMM386 or HIMEM for newer CPUs result
in smaller object files?

PS:  If the C is ever to be compiled with Watcom C, as Bernd
suggested, the global functions in the asm would need to have a _ in
front instead of behind, as this is (for some weird reason) the way
OpenWatcom does things.  To get other ASM/C projects to compile with
OpenWatcom, I have changed any instances of _function in the asm to
_function_, and then used defines in the C source code to append a _
to the opposite side of the function.  Just a tidbit.


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] EMM386 2.08/Nomyso 2.0 Available

[Michael Devore]

Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files 
emmx208.zip, EMM386/HIMEM mostly executable package (EXEs compressed via 
mutant UPX), and emms208.zip, EMM386/HIMEM mostly source package.  Nomyso 
version 2.0 was uploaded to ftp://ftp.devoresoftware.com/downloads/nomyso 
named nomyso20.zip.  nomyso is the newly chosen subdirectory for all Nomyso 
versions.


Version 2.08 of EMM386 is strictly a compatibility release to help ease 
transition for Microsoft EMM386 setups, increasing the number of identical 
options allowed in both EMM386 versions.  Specifically, EMM386 will now 
accept NOHI and NOMOVEXBDA without complaint, although these two options 
are no-op's.  That is, the two option do not change behavior on the part of 
FreeDOS EMM386 because it never performs the actions these options 
inhibit.  In addition, MIN=### is accepted as a synonym for the EMM=### 
option because, since the EMS/XMS pool-sharing feature was implemented, 
FreeDOS and Microsoft EMM386 act the same for the two options.  Also, a few 
cosmetic source code cleanups were made to EMM386.ASM for better 
NASM-conversion via Nomyso.


Nomyso has grown considerably from version 1.0 to 2.0 and has moved from 
semi-toy to useful program status.  Nomyso version 2.0 converts EMM386.ASM 
source to assemble under NASM.  Although Nomyso will not automatically 
convert many MASM/TASM programs, it now stands a decent chance of 
converting significant parts of a lot of the programs out there, depending 
on their style and complexity.


I anticipate that Version 2.08 of EMM386 is the final non-bugfix release I 
will create (bugfix versions will continue, as necessary).  I've done all 
the new design and enhancements I want to do, or think are necessary.  The 
ability to assemble and test with NASM may expand the pool of potential 
developers, although any such changes should still be discussed with -- and 
need be approved by -- the HIMEM/EMM386 maintainer(s).


For my part, on the FreeDOS-related front, I will likely continue work on 
Nomyso.  There is even a faint chance I will someday document advanced 
HIMEM and EMM386 options and behavior, or heck, maybe clean up that really 
lame Wikipedia Encyclopedia entry for FreeDOS.


The few minor source changes made to EMM386.ASM and NASM-specific notes follow:

 - EMM386 was sloppy with its case in 6-8 source lines, a fact that was 
masked by TASM ignoring variable case.  NASM is case-sensitive and complained.


 - NASM does not support PUBLIC/GLOBAL declarations after the variable 
declaration, so two PUBLIC declarations were moved.


 - One routine labelled 'pause' was a problem because pause is a recently 
added CPU opcode (who knew?).  Also a macro generated labels of INT1 and 
INT3, which are consider special CPU opcodes.  Changes were made to avoid 
creating labels which matched valid CPU opcodes.


 - Although limited macro conversion support is present in Nomyso v2.0, 
passing a hexadecimal value as a beginning value was causing problems and 
would have required me to extensively rewrite the macro converter to insert 
multiple lines and %ifnum's for a mere four source lines in EMM386.ASM.  So 
I got lazy and changed the hexadecimal values to decimal values instead.


Note that NASM is slightly less efficient than TASM when generating object 
code so there will be a slight increase in the EMM386 binary size, although 
the increase was well under 1%.  In fact, NASM is better than TASM at one 
type of optimization, but not enough to overcome other misses.


Also note that it turns out that with the more complex EMM386 source, NASM 
mirrors the past problems with HIMEM for five, six, and seven passes.  Only 
with eight passes, i.e. NASM -O8 -f OBJ EMM386.ASM, does the OBJ generate 
properly.  To forestall future problems with ever more complex programs, I 
strongly recommend just using -O99, as is commonly found in NASM 
builds.  99 passes should be enough, and NASM will stop at the last pass 
which makes no changes, so it's doubtful anything near that many will 
actually occur.


More information on Nomyso is available at www.devoresoftware.com/nomyso 
.  If any of you have suggestions for an open source application written in 
MASM or TASM which could use an automatic conversion to NASM, let me know 
and I'll consider making it the test case for Nomyso version 2.5 or 3.0.





---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] emm386 on 286 (was: FreeDOS Post-1.0 todo list)

[Arkady V.Belousov]

Hi!

7-Окт-2005 02:09 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-user@lists.sourceforge.net:

>>DEVICE=HIMEM...
>>DEVICE=FDXMS286...
>>DEVICE=EMM386...
MD> Seriously, you think that stacking up duplicate drivers and expecting them
MD> to all fail gracefully in line with the current CPU is a good way to handle
MD> the default boot process?

 This way is ideal for generic boot diskette, which not requires user
intervention to boot process.




---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] emm386 on 286 (was: FreeDOS Post-1.0 todo list)

[Michael Devore]

At 04:46 AM 10/7/2005 +0200, Eric Auer wrote:


The test already is performed inside the driver, and cannot be performed
in an errorlevel-generating tool. Because errorlevels are not used in
context of DEVICE=... loading. The "autoconfigure" would look like this:

DEVICE=HIMEM...
DEVICE=FDXMS286...
DEVICE=EMM386...


Seriously, you think that stacking up duplicate drivers and expecting them 
to all fail gracefully in line with the current CPU is a good way to handle 
the default boot process?  You want to depend on a solid but harmless fail 
condition to make things work every time?


I'm not much of one to volunteer people into more kernel work, but for 
cripes sake, if you're doing to do any conditional configurations at 
boot-time on the CONFIG.SYS, _that_ is where it belongs.  IF 
 and IFNOT  conditionals would do 
the trick.  It's not like CONFIG.SYS processing hasn't already been 
extended for FreeDOS a lot more than that already.


Or possibly easier...have the boot loader/new installation optionally able 
to launch an appropriate CONFIG conditionally based on the detected 
CPU.  Start with a CONFIG.386 -- and for the benighted few a CONFIG.86 and 
CONFIG.286 -- whichever one is correct gets brought in during installation 
and renamed to everybody's favorite CONFIG.SYS at the end of install.


Just think, with conditional CONFIG.SYS processing, you could even expand 
flexibility to dynamically bypass known problem -- or include required -- 
driver configurations with SCSI drives, flash drives, goofball BIOSs, 
etc.  Consequently you might become a world-wide marvel, millions possibly 
singing hosannas to your name, and you could be more popular than Linus 
(not Torvalds or Pauling, of course, I mean Linus Scudwomper who inflates 
balloons and female dolls for a living in Trenton, New Jersey, but still...).





---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] emm386 on 286 (was: FreeDOS Post-1.0 todo list)

[Eric Auer]

Hi Michael,

> You cannot simultaneously argue that 
> EMM386 may use a 386-level test to help configure loading at boot time, yet 
> a separate program cannot legitimately perform the same test.  The nature 
> of EMM386 and HIMEM precludes loading them at a subsequent DOS prompt.

Hmmm... misunderstanding? I mean: The normal case to load EMM386 is to
use DEVICE=...emm386... - NOT to load it from the prompt. I think we
agree there...

> Either you can auto-configure at boot based on a 386-level test or you 
> cannot.  Whether the tests are performed inside or outside a particular 
> device driver is irrelevant.

The test already is performed inside the driver, and cannot be performed
in an errorlevel-generating tool. Because errorlevels are not used in
context of DEVICE=... loading. The "autoconfigure" would look like this:

DEVICE=HIMEM...
DEVICE=FDXMS286...
DEVICE=EMM386...

On a 386 or better, things work as intended: Himem loads, then fdxms286
refuses to load because XMS is already present, then emm386 loads, fine.
On a 286, the IDEA would be: Himem refuses to load, as no 386 is present
... then fdxms286 loads. Then emm386 refuses to load, as there is still
no 386 CPU. Would be nice to have that.

The PROBLEM with the idea is: Current emm386 / himem versions FIRST use
386 code and THEN test whether there is a 386 at all. So they just crash
without further message on a 286. Which means that the nice trick for
doing an "universal 286 386 config sys" (I think it was invented by
Bernd?) does not work with the current emm386 / himem. But then again,
those drivers already do contain a 386-cpu-detection. Only at the wrong
place (after first use of 386 specific machine code). Plus the sy3pack
stub contains one LSS (no further 386 specific code). I hope that did
clarify the "smooth abort on 286 wish" and the why of that wish :-).

Eric



---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386

[Michael Devore]

At 08:20 PM 9/25/2005 -0300, you wrote:


 In addition, version 2.06 crashes FreeDOS. Versions 2.00 to 2.04 did work.


I think I would have noticed this.  Along with a few hundred other people.




---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very

own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] EMM386

[Jose Antonio Senna]

 As everybody probably knows by now, EMM386 works with the 386-optimized
freedos kernel. I am currently using it with kwc38616 build of 20 September.
 Stability with Lynx also improved . It seems that in this respect the
classification of EMM386 shall now be "useable".
 A problem that appeared with version 2.05 worsened with 2.06:
Arkady's MEM with option /e does not report EMS, but instead
   MEM: error: EMM call 41h
 In addition, version 2.06 crashes FreeDOS. Versions 2.00 to 2.04 did work.
 Regards
   JAS
 



---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] EMM386 2.06, optional update

[Michael Devore]

Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files 
emmx206.zip, EMM386/HIMEM mostly executable package, and emms206.zip, 
EMM386/HIMEM mostly source package.


This release of EMM386 has modifications attempting to reduce conflicts 
with SCSI and VDS, along with minor internal tweaks.  Version 2.06 fixes a 
problem with the NOVDS option; corrects a problem with applications, 
specifically PKUNZIP, that query EMS when the NOEMS option is not present; 
and allows an expanded range with the I= option for gaining more upper 
memory.  If you don't have problems with 2.05 and don't want the new stuff, 
you don't need to update to 2.06.


Going down the list...

The NOVDS option was broken, as previously announced.   Fixed.

The post-initialization patching out of the device driver entry point for 
EMM386 was broken and caused crashing problems with PKUNZIP and other 
EMS-querying applications via IOCTL functions unless the NOEMS option was 
specified, also as previously announced.  Fixed.


In an attempt to clear up some problems with VDS, the VDS function 
dispatcher is more forgiving.  If a VDS function is specified which is 
reserved, but unused, the VDS dispatcher will pass the call along to the 
original interrupt handler unchanged.  Will this make computers with VDS 
conflicts work better?  No idea, it's just an attempt to allow SCSI 
commands which do not directly intersect with VDS commands go their way 
unhindered.  There may be -- and likely are -- conflicts that cannot be 
resolved in this manner, but hopefully it helps out some people.  And for 
all I know, there may remain a bug in a VDS function that only certain 
computers encounter.   Untested do to lack of a problem machine, hope it works.


The allowed I= ranges for EMM386 have been expanded to F000-F7FF.  You may 
re-use this area at your own risk.  Some BIOS's are tolerant of it.  I 
myself re-used F000-F1FF here to load a mouse driver with no immediate ill 
effect (it looks like the computer stored the BIOS setup screens and code 
there).  However, your computer may well crash, act weird, or otherwise 
deviate from expectations when including anything in the new ROM BIOS 
range, depending on what lives there.


The default MAX setting of EMM386 was lowered, yet again, to 120M.  Seems 
that TDUMP is unhappy with VCPI free amounts greater than 127M.  TASM 
works, TD works, TLINK works, not TDUMP.  It coughs up a rolling error 
message about ignoring and losing VCPI pages.  Bogus, near as I can tell, 
as VCPI allocations and free were stress tested for failures up to 156M 
here, besides the other Borland utilities working fine.  But I give up.  It 
wants less VCPI, it gets less VCPI.  You can always manually increase it to 
a larger value if you want.


Finally, the VCPI shared client/server GDT mapping in the first 4M was 
reduced from 2M to 1.75M.  Because I can, because somebody wanted it 
smaller, and because nobody else really cares.  Apparently some drivers, 
like the well-documented (here) as stupid SoundBlaster, fight over the 
lower 4M address space and this change gives them a larger ring to fight 
in.  That's about as low as it's going to go though, so device drivers, go 
nuts with that extra 256K.  Win one for the FreeDOS fish flipper.





---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very

own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.05 update, recommended for all

[Arkady V.Belousov]

Hi!

22-Сен-2005 09:25 [EMAIL PROTECTED] (Brolin Empey) wrote to
freedos-user@lists.sourceforge.net:

>>  No, error message says parsing error, not read error. For me, there
>> looks like broken memory contents.
BE> The line in question is indeed syntactically correct.

 Yes, I see.

BE> The error message is caused by a read error because

 Again: this error message indicates error in parsing. Because line in
quesion is correct, then error is in broken memory (for example, some wring
code incorrectly writes to wrong memory places).




---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.05 update, recommended for all

[Brolin Empey]

Arkady V.Belousov wrote:

Hi!

22-Сен-2005 02:07 [EMAIL PROTECTED] (Bernd Blaauw) wrote to
freedos-user@lists.sourceforge.net:

BB> it sounds like VDS again to me. That has the effect that no more can be
BB> read from harddisk,
BB> which would explain the error about the cdromdrive, which seems like
BB> perfectly fine syntax
BB> (yes, config.sys is buffered first by kernel)

 No, error message says parsing error, not read error. For me, there
looks like broken memory contents.



The line in question is indeed syntactically correct.

The error message is caused by a read error because (1) everything works 
fine when using either EMM386 v2.04 or EMM386 v2.05 with VDS disabled 
(NOVDS parameter); (2) the kernel cannot read the command interpreter 
from the disk; (3) the kernel cannot read any file specified when it 
asks for the full path to the command interpreter to use.


Of course, it would make much more sense if the kernel could report that 
it was unable to read the specified file from the disk instead of 
reporting parsing errors on lines which are perfectly valid.



---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very

own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.05 update, recommended for all

[Arkady V.Belousov]

Hi!

22-Сен-2005 02:07 [EMAIL PROTECTED] (Bernd Blaauw) wrote to
freedos-user@lists.sourceforge.net:

BB> it sounds like VDS again to me. That has the effect that no more can be
BB> read from harddisk,
BB> which would explain the error about the cdromdrive, which seems like
BB> perfectly fine syntax
BB> (yes, config.sys is buffered first by kernel)

 No, error message says parsing error, not read error. For me, there
looks like broken memory contents.




---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.05 update, recommended for all

[Arkady V.Belousov]

Hi!

21-Сен-2005 16:42 [EMAIL PROTECTED] (Brolin Empey) wrote to
freedos-user@lists.sourceforge.net:

BE> CONFIG.SYS* error in line 26**
 12?DEVICEhigh=C:\FDOS\bin\vide-cdd.sys /D:vide
BE>  ^
BE> * this is wrong: FDCONFIG.SYS is being parsed, *not* CONFIG.SYS!
BE> ** this too is wrong: 26 is zero-based; the "error" is really on line 27

 I was fix both things in my config.c, but don't know, if Jeremy import
it completely.




---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.05 update, recommended for all

[Michael Devore]

At 08:05 PM 9/21/2005 -0500, I wrote:


At 05:48 PM 9/21/2005 -0700, Blair Campbell wrote:

I think that it'd be really nice to have a utility to detect the
instances where VDS would fail because then distros like mine can add
the NOVDS option in the installed config.sys and a user could save
much trouble by not having to boot without EMM386 and edit config.sys.


If I could detect when VDS would fail, I could make it not do so, with a 
high likelihood of success, depending on severity of the conflict.  HOW to 
detect when VDS is in conflict is the $64,000 question.  Without MS-style 
resources to acquire 100's of different test machines, we're kind of stuck.


Given the three VDS problem reports, I've added a basic VDS filter to 
EMM386, such that reserved but unused VDS functions aren't processed with 
failure return code, but passed on to the default interrupt, in the hope 
that they're really SCSI functions to be sent on down the line.  I'll post 
it as a version 2.06 in a day or two.


No idea whether it will make a difference, but the two diametrically 
opposed camps of "fail if UMBs and VDS off" versus "fail if VDS on and 
using certain SCSI drives" issue has got to be addressed.





---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very

own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.05 update, recommended for all

[Brolin Empey]

Michael Devore wrote:

At 04:42 PM 9/21/2005 -0700, Brolin Empey wrote:


FastTracker 2.08 runs fine for me under latest HIMEM and EMM386.
PKUNZIP failing unless the NOEMS option is specified, now that's a 
problem I'm working on.



EMM386 v2.05 breaks my FDCONFIG.SYS! When booting, I get the following 
output:



FreeDOS HIMEM64 3.11...
HIMEM - KBC A20 method used
EMM386 2.05...
CONFIG.SYS* error in line 26**
>>>12?DEVICEhigh=C:\FDOS\bin\vide-cdd.sys /D:vide



EMM386 isn't involved in parsing CONFIG.SYS at all, but you can try the 
emmflesh.zip update if you want to see about the latest.




The problem is now solved. :) I tried the latest EMM386, but could only 
boot by using the NOVDS parameter. Of course, this is no use when it 
comes to running FastTracker II since FT2 refuses to run, saying that 
"The memory manager does not support Virtual DMA Specification at 
:". It never occurred to me until now to try booting *without* 
EMM386, so I tried this next. FT2 now seems to work fine, at least for 
long enough to play back a couple of tracks on the PC speaker. 
Relatively simple songs actually sound quite good on the speaker. :)



---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very

own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.05 update, recommended for all

[Michael Devore]

At 05:48 PM 9/21/2005 -0700, Blair Campbell wrote:


> it sounds like VDS again to me. That has the effect that no

I think that it'd be really nice to have a utility to detect the
instances where VDS would fail because then distros like mine can add
the NOVDS option in the installed config.sys and a user could save
much trouble by not having to boot without EMM386 and edit config.sys.


If I could detect when VDS would fail, I could make it not do so, with a 
high likelihood of success, depending on severity of the conflict.  HOW to 
detect when VDS is in conflict is the $64,000 question.  Without MS-style 
resources to acquire 100's of different test machines, we're kind of stuck.





---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very

own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.05 update, recommended for all

[Blair Campbell]

> it sounds like VDS again to me. That has the effect that no

I think that it'd be really nice to have a utility to detect the
instances where VDS would fail because then distros like mine can add
the NOVDS option in the installed config.sys and a user could save
much trouble by not having to boot without EMM386 and edit config.sys.


---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.05 update, recommended for all

[Bernd Blaauw]

Michael Devore schreef:

EMM386 isn't involved in parsing CONFIG.SYS at all, but you can try 
the emmflesh.zip update if you want to see about the latest.


it sounds like VDS again to me. That has the effect that no more can be 
read from harddisk,
which would explain the error about the cdromdrive, which seems like 
perfectly fine syntax

(yes, config.sys is buffered first by kernel)

try updating EMM386 first to the version that Michael mentions (see this 
mailinglist),

then try adding NOVDS

if all fails, try loading UDMA2.SYS after HIMEM but before EMM386

I'm too tired now to confirm the issue, will try to do so tomorrow.

Bernd



---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very

own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.05 update, recommended for all

[Michael Devore]

At 04:42 PM 9/21/2005 -0700, Brolin Empey wrote:


FastTracker 2.08 runs fine for me under latest HIMEM and EMM386.
PKUNZIP failing unless the NOEMS option is specified, now that's a 
problem I'm working on.


EMM386 v2.05 breaks my FDCONFIG.SYS! When booting, I get the following output:


FreeDOS HIMEM64 3.11...
HIMEM - KBC A20 method used
EMM386 2.05...
CONFIG.SYS* error in line 26**
>>>12?DEVICEhigh=C:\FDOS\bin\vide-cdd.sys /D:vide


EMM386 isn't involved in parsing CONFIG.SYS at all, but you can try the 
emmflesh.zip update if you want to see about the latest.





---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very

own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.05 update, recommended for all

[Brolin Empey]

Michael Devore wrote:

At 05:05 PM 9/19/2005 -0700, Brolin wrote:

Firstly, I have not tested this new release. That said, what is the 
status with regards to having FastTracker II working on FreeDOS?



FastTracker 2.08 runs fine for me under latest HIMEM and EMM386.

PKUNZIP failing unless the NOEMS option is specified, now that's a 
problem I'm working on.





EMM386 v2.05 breaks my FDCONFIG.SYS! When booting, I get the following 
output:



FreeDOS HIMEM64 3.11...
HIMEM - KBC A20 method used
EMM386 2.05...
CONFIG.SYS* error in line 26**
>>>12?DEVICEhigh=C:\FDOS\bin\vide-cdd.sys /D:vide
^
Kernel: allocated 37 diskbuffers = 19684 bytes in HMA
Bad or missing command interpreter: 12?SHELL=D:\Programs\4DOS\4DOS.COM 
D:\Programs\4DOS /PC:\FDOS\fdauto.bat

Enter the full shell command line: _


* this is wrong: FDCONFIG.SYS is being parsed, *not* CONFIG.SYS!
** this too is wrong: 26 is zero-based; the "error" is really on line 27

Even if I enter the full path to FreeCOM or 4DOS, I simply get this 
prompt for the command interpreter again.


If I revert to using EMM386 v2.04, everything works fine.

Here are the contents of my FDCONFIG.SYS:
(the menu names/labels don't mean much since I never bothered to change 
them from the (FD)CONFIG.SYS included with the Beta 9 SR1 CD release.)



!COUNTRY=046,850,C:\FDOS\BIN\COUNTRY.SYS
!SET lang=EN
;for help on commands, see file config.sys in your FreeDOS directory
;www.benq.com/ss_download/drivers/storage/cd-rom/drivers/dos/apicd214.exe
;DOS=HIGH is still buggy (try running HELP), as is CDROM-driver. (see 
website)

!BREAK=ON
!LASTDRIVE=Z
!BUFFERS=20
!FILES=60
!DOS=HIGH,UMB
!DOSDATA=UMB
!set dircmd=/oge /4
!MENUCOLOR=10,1
MENUDEFAULT=1,5
MENU 1 - Load FreeDOS with maximum RAM free, using EMM386
MENU 2 - Load FreeDOS including HIMEM XMS-memory driver
MENU 3 - Load FreeDOS without drivers
;1?DOS=HIGH
12?DEVICE=C:\FDOS\BIN\HIMEM.EXE
;/verbose
1?DEVICE=C:\FDOS\BIN\EMM386.EXE RAM X=TEST SB
;1?DEVICE=C:\FDOS\BIN\EMM386.EXE
;/verbose
;1?DEVICE=C:\FDOS\BIN\XDMA.SYS
;DEVICE=d:\programs\dev\386swat\386SWAT.LOD altscr dvga
;12?DEVICEhigh=C:\FDOS\bin\liteon.sys /D:liteon /DMA
12?DEVICEhigh=C:\FDOS\bin\vide-cdd.sys /D:vide
12?SHELL=D:\Programs\4DOS\4DOS.COM D:\Programs\4DOS /PC:\FDOS\fdauto.bat
3?SHELL=D:\Programs\4DOS\4DOS.COM D:\Programs\4DOS /PC:\FDOS\setenv.bat
;12?SHELL=C:\fdos\COMMAND.COM C:\ /E:8192 /P=C:\FDOS\fdauto.bat
;3?SHELL=C:\fdos\COMMAND.COM C:\ /E:8192 /D /K set path=C:\FDOS\bin



---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very

own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.05 update, recommended for all

[Florian Xaver]

Michael, thanks again for this wonderful driver!

Bye, Flo


---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very

own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] EMM386 2.05, if you have problems...

[Michael Devore]

If you have any problems with EMM386 2.05, try the unofficial release 
emmflesh.zip at
ftp://ftp.devoresoftware.com/downloads/emm386 as it has a couple of 
relatively minor fixes in the EMM386.EXE file that will affect some 
users.  Be aware that this unofficial version is not EXE compressed in size 
and still reports version 2.05.


If you don't have problems, don't bother.  The fixes -- should you ever 
need them -- will be in a future 2.06 version, to be released when 
additional feedback and testing of 2.05 is done, and more serious bugs or 
feature updates, if any, are finalized.


Specifically, if you want to use the NOVDS option, the parsing was screwed 
up (hey, I thought that the parser respected whitespace and placed it after 
VDS), so that NOVDS was never triggered properly.  This was fixed.


Also, the device driver entry wasn't patched out after initialization 
because I didn't realize that EMM386 did that based on stack locations, 
which means that the patching out after additional register saves actually 
overwrote two of the saved 32-bit register values.  Fortunately, those 
registers were noncritical general registers, not segment registers, and 
shouldn't affect 386-builds of the kernel.  More problematic is there are 
programs which call IOCTL functions on the EMS driver name and if the 
driver isn't patched out, they go slightly insane.  This is what happened 
with PKUNZIP unless the NOEMS option was present to change the default EMS 
driver name.





---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very

own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.05 update, recommended for all

[Michael Devore]

At 05:05 PM 9/19/2005 -0700, Brolin wrote:

Firstly, I have not tested this new release. That said, what is the status 
with regards to having FastTracker II working on FreeDOS?


FastTracker 2.08 runs fine for me under latest HIMEM and EMM386.

PKUNZIP failing unless the NOEMS option is specified, now that's a problem 
I'm working on.





---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very

own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.05 update Bug Report

[Daniel Quintiliani]

Bernd Blaauw wrote:

> 
> MEM (1.6) itself is broken, get 1.7beta or 1.8alpha
> both available at: http://wiki.fdos.org/Main/mem
> 
> Please report back if that solves your UMB Corruption error or not.
> 
> Bernd
> 

Thank you, MEM 1.7beta works fine. -Dan



---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.05 update, recommended for all

[Gerry Hickman]

Hi Michael,

Nope, there are documented instances of SCSI drivers being incompatible 
with VDS.


Sure, but as I understand it, this VDS problem will occurr even when 
there's NO driver loaded (e.g. pure INT13)?


In those cases, they share the same interrupt and potentially 
the same register values which VDS uses to determine its functions


OK, is this related?



If it's about busmastering and IDE, it's hardly surprising it doesn't 
work with SCSI (kind of not needed). If it's about something else...


and 
what to do.  Obviously if SCSI wants to read a disk sector and VDS 
thinks you want to check for contiguous memory amounts, something is 
going to wind up very unhappy.


Right. I'm wondering how they used to manage with Adaptec and DOS in the 
early days - maybe they used to just disable VDS? Maybe that's the 
correct thing to do when using SCSI?


Oh, 3.5) I was bored and it was a mild diversion.  And, 3.75) It gave me 
an excuse to start working with Perl and Cygwin-based utils a bit more


Excellent idea!

--
Gerry Hickman (London UK)


---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very

own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.05 update, recommended for all

[Michael Devore]

At 05:05 PM 9/19/2005 -0700, Brolin  wrote:

Firstly, I have not tested this new release. That said, what is the status 
with regards to having FastTracker II working on FreeDOS? My FreeDOS 
installation consists mainly of what was distributed with the Beta9 SR1 
CD, so some of the components may be fairly old.


If you're asking me personally, I don't have a clue.  If you're asking the 
list, hopefully someone will have the answer.


Should FastTracker work without EMM386 loaded and NOT work with EMM386 
loaded as the ONLY difference, it may be a compatibility problem with 
EMM386, otherwise not very likely to be related to it.





---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very

own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.05 update, recommended for all

[Brolin]

Michael Devore wrote:
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files 
emmx205.zip, EMM386/HIMEM mostly executable package, and emms205.zip, 
EMM386/HIMEM mostly source package.


Firstly, I have not tested this new release. That said, what is the 
status with regards to having FastTracker II working on FreeDOS? My 
FreeDOS installation consists mainly of what was distributed with the 
Beta9 SR1 CD, so some of the components may be fairly old. I did however 
 download your previous EMM386 and HIMEM release back in July or August.



---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very

own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.05 update Bug Report

[Bernd Blaauw]

Daniel Quintiliani schreef:

This update breaks MEM. While it finally allows OpenGEM to work at the
same time as my plug-n-play SoundBlaster AWE64, upon running the latest
stable version of MEM, I get "MEM: UMB Corruption."

-Dan
  

MEM (1.6) itself is broken, get 1.7beta or 1.8alpha
both available at: http://wiki.fdos.org/Main/mem

Please report back if that solves your UMB Corruption error or not.

Bernd



---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very

own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.05 update Bug Report

[Daniel Quintiliani]

Michael Devore wrote:
> Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files
> emmx205.zip, EMM386/HIMEM mostly executable package, and emms205.zip,
> EMM386/HIMEM mostly source package.
> 
> This version of EMM386 has a number of compatibility changes to enhance
> operability with a variety of DOS applications and environments without
> the need for advanced option tweaking.  As a result of the seven changes
> to EMM386 and two changes to HIMEM, this is a recommended released.
>

Hi,

This update breaks MEM. While it finally allows OpenGEM to work at the
same time as my plug-n-play SoundBlaster AWE64, upon running the latest
stable version of MEM, I get "MEM: UMB Corruption."

-Dan



---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.05 update, recommended for all

[Michael Devore]

At 11:21 PM 9/19/2005 +0100, you wrote:

A better option would be to get to the bottom of why SCSI and VDS do not 
like each other. SCSI is a drive interface - I don't see how it can be 
affected by VDS unless there's something bigger going on. It may he SCSI 
is merely showing up the problem, as opposed to BEING the problem?


Nope, there are documented instances of SCSI drivers being incompatible 
with VDS.  In those cases, they share the same interrupt and potentially 
the same register values which VDS uses to determine its functions and what 
to do.  Obviously if SCSI wants to read a disk sector and VDS thinks you 
want to check for contiguous memory amounts, something is going to wind up 
very unhappy.


Is that what the problem is with your SCSI setup(s)?  Can't say, good 
chance it's a failure elsewhere, or it could be the fundamental failure 
described above.  If you want me to get to the bottom of your particular 
VDS failure, then you or someone else will need to send me a machine that 
demonstrates the problem, same as Mark Bailey did with his 
laptop.  Otherwise, it's all conjecture here.


the amount up to $60.00 and made the contribution on August 9, specified 
for where it was most needed with the title 'FreeDOS'.  Confirmation 
e-mail available on request.


Very nice, but I don't get it? You are spending hours developing this 
excellent Free software, and then paying out to charities based on it's 
popularity??


I was interested in knowing how many people overall, more or less, 
downloaded from my site for FreeDOS.  The contribution served three 
purposes:  1) it motivated interested people to download the latest rather 
than wait for release+n like people tend to do; 2) it gave me a better 
baseline against people who solely hit the site to download files simply 
because they are there (BBS'ers used to call them file-rapers); and 3) it 
made a little money for a universally helpful charity that could use it.


Oh, 3.5) I was bored and it was a mild diversion.  And, 3.75) It gave me an 
excuse to start working with Perl and Cygwin-based utils a bit more to 
process the results, instead of coding something up in C/C++ overkill as I 
typically have done.





---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very

own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.05 update, recommended for all

[Bernd Blaauw]

Gerry Hickman schreef:
A better option would be to get to the bottom of why SCSI and VDS do 
not like each other. SCSI is a drive interface - I don't see how it 
can be affected by VDS unless there's something bigger going on. It 
may he SCSI is merely showing up the problem, as opposed to BEING the 
problem?
VDS being enabled by default *will* cause people to report any problems 
with SCSI setups.
Previously VDS was omitted by default, so people would never find out 
there would have been an issue.
the amount up to $60.00 and made the contribution on August 9, 
specified for where it was most needed with the title 'FreeDOS'.  
Confirmation e-mail available on request.


Very nice, but I don't get it? You are spending hours developing this 
excellent Free software, and then paying out to charities based on 
it's popularity??
non-commercial programmers take their time to make their software as 
good as possible, there's no pressure except for the desire to make good 
enough (or even perfect) software. I'm glad Michael wants to deliver 
such quality and keeps improving these memory managers.
The better the quality and reputation, the more downloads, the more 
testing, and more remaining issues exposed --> goto begin :)
Michael's charity helps the charity itself, and it helps getting EMM386 
more exposure and testing.
As you can see from the changelog, most bugs seem to be detected by 
Michael himself. That's quite impressive, as most people are blind with 
regard to their own code, meaning their code is too familiar to look at 
it properly as a critic.


Happy bughunting people, and thanks for the release, Michael :)




---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very

own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.05 update, recommended for all

[Gerry Hickman]

Hi Michael,


This version of EMM386 has a number of compatibility changes


Cool.

While on the topics of VDS, the VDS option is now on by default.  Too 
many environments require this to leave it as optional, plus a default 
on condition matches Microsoft EMM386.  There exist SCSI setups which 
will REQUIRE you to turn off VDS support via the new NOVDS option.  
Unfortunately for those SCSI-ites, the people who need VDS outnumber the 
people who need to not have VDS, so they lost out.  Or maybe the people 
who need VDS just yell louder.  Ahh well, same difference to me.  I like 
quiet.


A better option would be to get to the bottom of why SCSI and VDS do not 
like each other. SCSI is a drive interface - I don't see how it can be 
affected by VDS unless there's something bigger going on. It may he SCSI 
is merely showing up the problem, as opposed to BEING the problem?


the amount up to $60.00 and made the contribution on August 9, specified 
for where it was most needed with the title 'FreeDOS'.  Confirmation 
e-mail available on request.


Very nice, but I don't get it? You are spending hours developing this 
excellent Free software, and then paying out to charities based on it's 
popularity??


--
Gerry Hickman (London UK)


---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very

own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] EMM386 2.05 update, recommended for all

[Michael Devore]

Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files 
emmx205.zip, EMM386/HIMEM mostly executable package, and emms205.zip, 
EMM386/HIMEM mostly source package.


This version of EMM386 has a number of compatibility changes to enhance 
operability with a variety of DOS applications and environments without the 
need for advanced option tweaking.  As a result of the seven changes to 
EMM386 and two changes to HIMEM, this is a recommended released.


Briefly, besides various fixes and compatibility modifications, the VDS 
option now defaults to on, with a new NOVDS option to turn it off (NOVDS 
possibly required for some SCSI disk drivers); the XMS memory manager 
supports growing memory blocks on resize for the Graphics Vision text 
editor; and a limited MEMCHECK default of 3-4G is present for MMIO-based 
devices such as USBASPI.SYS, with the ability to turn it all off by use of 
the new NOCHECK option.


Particulars ponderously proceed post-paragraph:

The HMAMIN setting of HIMEM never up-converted its K setting to actual 
bytes as required internally, plus it allowed 64K instead of a maximum of 
63K.  Bad HMAMIN, bad boy.  Fixed.


The NOVCPI option was blocking allocation of UMBs.  This was overly 
aggressive, even for a severe option like NOVCPI, and it was chastised back 
to proper behavior.  Regardless of that whoopsie, friends don't let friends 
use NOVCPI, as it is almost never a good idea.  Unless you know exactly why 
you are using NOVCPI, don't.


There was an error when parsing EMS, such that an EMS page frame was marked 
present even if there was insufficient upper memory (i.e. no 64K contiguous 
block) to place it properly.  The problem would not be present if you 
specified NOEMS and even without NOEMS it would not cause misbehavior 
unless you used an application which depended on EMS and a page 
frame.  Admittedly, it was an error with a nasty bite, but one had to 
wander far into the hinterlands of nontypical environments to get 
bitten.  Such is how developers rationalize away crippling guilt.  And 
minor bugs.


The EMM386 driver saves the full 32-bit part of all general registers it 
uses, as well as segment registers.  This may or may not clear up problems 
with 386-optimized kernels.  I can't test.  It consumes an additional 22 
bytes of stack, which I'm thinking probably shouldn't be a problem.  Of 
course, I used to think an incompetent buffoon probably wouldn't make a 
second term as President, and now look what the USA is stuck with, so 
counting on me to tell you whether a particular kernel version is safe 
seems chancy.


HIMEM's XMS API supports growing a block on resize; previously only 
shrinking was supported.  Sufficient contiguous memory must be available to 
simultaneously hold the old block and the new block or else it will 
fail.  This feature was added because the Graphics Vision text editor did 
not gracefully handle a failed XMS growing resize, although resizing is 
never guaranteed.  I don't know whether it's a bound-in extender fault or 
an application fault, but something is acting goofy in there and we're 
stuck writing the work-around for it.  Not that I feel crabby about it.


EMM386's VDS option had a bug in the scatter/gather function and made 
various setups, such as Bernd's VMWare and Mark Bailey's laptop, cry in 
grief and frustration at the unfairness of it all.  The evil error was 
corrected to help better balance Universal Justice towards the Good Guys.


While on the topics of VDS, the VDS option is now on by default.  Too many 
environments require this to leave it as optional, plus a default on 
condition matches Microsoft EMM386.  There exist SCSI setups which will 
REQUIRE you to turn off VDS support via the new NOVDS 
option.  Unfortunately for those SCSI-ites, the people who need VDS 
outnumber the people who need to not have VDS, so they lost out.  Or maybe 
the people who need VDS just yell louder.  Ahh well, same difference to 
me.  I like quiet.


EMM386 internally defaults its MAX setting to 256M, so that unless you 
explicitly specify a MAX= setting more than 256M, available VCPI will not 
exceed this amount.  This change was made solely to accommodate the DOS/32A 
extender complaining when large amounts of free VCPI memory are 
available.  Applications which used the extender would fail with a fatal 
error in such cases, including MPXPLAY -- an otherwise extremely impressive 
DOS program that deserves major kudos.  It appears that DOS/32A is dumb as 
a leaf of lettuce about the whole lots of VCPI available thing, which kind 
of sours me on those rabid endorsements of it.


The final change is to ensure better compatibility with device drivers that 
use MMIO (memory-mapped I/O) to high addresses outside of normal RAM, such 
as USBASPI.SYS.  Previously, the MEMCHECK option was required.  EMM386 now 
defaults to operating as if MEMCHECK was present IF the source or 
destination address range starts (not ends) within the 3G-

Re: [Freedos-user] EMM386 VDS test fix, works with HP Pavilion

[Michael Devore]

At 01:46 PM 8/7/2005 +0100, Gerry Hickman wrote:


I then rebooted without VDS and everything worked correctly.

I then rebooted with VDS again, and everything was messed up.

Thing is, I have no idea what VDS is for, and don't know if I'd ever need it!


When VDS becomes a default option, either the SCSI incompatibility needs to 
be worked around (possibly by a special SCSI detection sequence), or else 
you will need to turn off VDS through a NOVDS option.  Theoretically, a 
SCSI drive could need VDS support to run drivers in which are loaded in 
upper memory, although I'm not sure SCSI can always peacefully co-exist 
with EMM386.  It's famously incompatible with MS EMM386 in certain situations.


Consequently, it would be nice to get your SCSI-based machines -- and any 
others with problems -- working with VDS option present, if possible.





---
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 VDS test fix, works with HP Pavilion

[Gerry Hickman]

Hi Michael,

Okay, if you've been following the VDS bouncing ball, be aware there is 
now a new EMM386 test release, called emmchimp.zip at 
ftp.devoresoftware.com/downloads/emm386 which does fix the problem using 
the VDS option of EMM386 on the original problematic HP Pavilion laptop.


The problem on the Pavillion was probably not related to the way VDS 
interacts with SCSI. I don't know, does the HP have SCSI?


Anyway, I tested the "chimp" build and unfortunately I still see random 
problems using SCSI with VDS enabled. Note that I did not load any ASPI 
drivers, this is pure INT13.


1. FDISK /INFO

One minute it says there's "no fixed drives", then the next it finds one 
fixed drive instead of two, but claims it's not been partitioned.


2. FDISK /STATUS

Finds both hard drives but claims they are 8Gb instead of 36Gb

3. LBACACHE

Only finds one drive instead of two - hard to tell if geometry is mapped 
correctly.


I then rebooted without VDS and everything worked correctly.

I then rebooted with VDS again, and everything was messed up.

Thing is, I have no idea what VDS is for, and don't know if I'd ever 
need it!


Here's the section of FDCONFIG.SYS related to this:

DEVICE=DRIVER\HIMEM.EXE /NOABOVE16 /X

; rem TESTING VDS option with EMM386 "chimp"
DEVICE=TESTING\EMM386.EXE VDS NOEMS X=TEST /verbose

--
Gerry Hickman (London UK)


---
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 VDS test fix, works with HP Pavilion

[Bernd Blaauw]

Michael Devore schreef:
I would like anyone who has had a problem with VDS -- judging by 
feedback that being Gerry Hickman, Bernd, and untold legions of lurkers  
-- to try this version of EMM386 and see if VDS works for them.  If 
we're all astoundingly lucky, this test release fixes everything.  If 
not, you need to tell me.  In fact, you really need to tell me either way.


it works perfectly now within VMware, thank you (and Mark) very much for 
solving this issue.


I unilaterally crown Mark Bailey as FreeDOS User Of The Month for 
shipping a nice laptop to some crusty bastard he doesn't even know and 
trusting me to actually send it back.  In fact, I feel so big-hearted 
and benevolent about the whole thing I won't be invoicing FreeDOS 
International Incorporated for the $40 USB floppy drive I purchased 
since the damn laptop BIOS didn't have an option to boot from my FreeDOS 
flash stick.


enjoy the USB drive, Michael :)

one more less issue to go for a perfect/ideal/very_usable EMM386.

Bernd



---
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] EMM386 VDS test fix, works with HP Pavilion

[Michael Devore]

Okay, if you've been following the VDS bouncing ball, be aware there is now 
a new EMM386 test release, called emmchimp.zip at 
ftp.devoresoftware.com/downloads/emm386 which does fix the problem using 
the VDS option of EMM386 on the original problematic HP Pavilion laptop.


How do I know?  Because Mark Bailey sent the unhappy machine for testing 
here, which arrived today.  I subsequently found a bug in the VDS 
scatter/gather lock function (8105h) which causes failure if the passed 
address to be processed is not aligned on a 4K boundary.


I would like anyone who has had a problem with VDS -- judging by feedback 
that being Gerry Hickman, Bernd, and untold legions of lurkers  -- to try 
this version of EMM386 and see if VDS works for them.  If we're all 
astoundingly lucky, this test release fixes everything.  If not, you need 
to tell me.  In fact, you really need to tell me either way.


I unilaterally crown Mark Bailey as FreeDOS User Of The Month for shipping 
a nice laptop to some crusty bastard he doesn't even know and trusting me 
to actually send it back.  In fact, I feel so big-hearted and benevolent 
about the whole thing I won't be invoicing FreeDOS International 
Incorporated for the $40 USB floppy drive I purchased since the damn laptop 
BIOS didn't have an option to boot from my FreeDOS flash stick.


Oh yeah, like last three times, as an unofficial release this means no 
visible version changes, no EXE compression, no redistribution as an 
official-type release, no fooling.





---
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 'horse' went wild

[Johnson Lam]

On Mon, 01 Aug 2005 23:02:59 +0100, you wrote:

Hi,

My painfully research result, may help you to optimize the CONFIG.SYS:

>rem Why do some people run non-SCSI drives?
>;DEVICE=DRIVER\UDMA2.SYS

Because SCSI means expensive!!

>rem This is not open source!
>DEVICEhigh=OTHER\VIDE-CDD.SYS /D:FDCD

But efficient and FREE

>rem This is Microsoft, yikes
>devicehigh=OTHER\ramdrive.sys 4096 512 1024 /e

If you hate M$, try the OpenSource Resizeable RAMDISK (SRDISK)

>BUFFERS=20

BUFFERS=-1


Rgds,
Johnson.



---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] EMM386 'horse' went wild

[Gerry Hickman]

Hi,

I tested EMM386 "horse" with VDS option, and on this system it's still 
total meltdown. All hard drive info misreported. Too scared to continue 
in case can't boot anymore.


Asus A7V333 latest BIOS
Adaptec 29160N SCSI host adapter with 2 x 36Gb drives
FreeDOS Beta9sr1 except HIMEM64 3.10a and EMM386 "horse"

FDISK and PQMAGIC claim there are no partitions defined and give totally 
crazy readings for physical disk sizes.


FDCONFIG.SYS follows (look out for line wrap):

; rem FDXMS gives VDISK error on some soft reboots
; rem FDXMS gives warning about an interrupt not being supported by EMM386

;device=special\fdxms.sys

DEVICE=DRIVER\HIMEM.EXE /NOABOVE16 /X

; rem VDS option with EMM386 v2.03 corrupts everything
; rem TESTING VDS option with EMM386 "horse"
DEVICE=TESTING\EMM386.EXE NOEMS VDS X=TEST /verbose

; rem UMBPCI found to be more stable for UMBs on every system tested
;device=other\umbpci.sys

rem Load the SCSI for 29160N card, wait, we're using INT13 instead!
;device=other\aspi8u2.sys /d

rem UDMA hard drives, don't have any non-SCSI drives in this system
rem Why do some people run non-SCSI drives?
;DEVICE=DRIVER\UDMA2.SYS

rem This is not open source!
DEVICEhigh=OTHER\VIDE-CDD.SYS /D:FDCD

rem This is Microsoft, yikes
devicehigh=OTHER\ramdrive.sys 4096 512 1024 /e

rem This is version from MSCLIENT 3.0, look out for version mismatch
;devicehigh=OTHER\ifshlp.sys

rem lbacache tuns switch is needed for SCSI and UMBPCI
rem but it doesn't seem to be needed on the 29360N card
INSTALLhigh=DRIVER\LBACACHE.COM
SHELL=COMMAND.COM A:\ /E:1024 /F /MSG /P=.\FREEDOS\FDAUTO.BAT

DOSDATA=UMB
DOS=high,UMB
FILES=20
BUFFERS=20
LASTDRIVE=Z



--
Gerry Hickman (London UK)


---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] EMM386 2.04/HIMEM 3.11 update, recommended

[Michael Devore]

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 2.04 is less important, but probably 
a good idea.


This release of HIMEM fixes a problem with the /NUMHANDLES option.  If the 
number of handles was less than 72, XMS handles reporting utilities such as 
MEM.EXE might display garbage values.  Also, since HIMEM placed the handle 
count in the wrong memory location -- potentially a critical flaw for a 
small, but indeterminate number of users -- everyone should update to the 
latest version.  The latest EMM386 release fixes two errors with EMS.


Details and big-time money offer follow:

The /NUMHANDLES problem with HIMEM which resulted in garbage value reports 
was due to HIMEM continuing to report a default 72 handles even when less 
memory was allocated for the smaller number of requested handles.  MEM 
would read past the real handle information and interpret junk as valid 
handle values.  This effect was benign but quite ugly.  The proper handle 
value was punched in memory about 64 bytes higher than it should have 
been.  Yikes.  That bug will teach me to use the pure structure offset in 
assembly language when addressing variables relative to the structure, 
rather than an instantiated structure address offset.  You dummy.


EMM386's EMM= option had a rounding error which could cause problems with 
EMS page allocation and release, typically when low (sub 2M) values were 
used for EMM=.  If you did not use the EMM= option or did not use EMS, this 
error would not affect you.


EMM386 fixes an error in EMS function 51h, reallocate pages, when the count 
of pages was shrunk.  Improper EMS page pointers would be updated with 
subsequent woe.  Also, a couple of sanity checks were added to the EMS 
allocate/release pages functions to stop the worst of bad pointer memory 
overwrite crashes when things went wrong, in the internals gone wacky sense 
of wrong.  Things will remain wrong, but now they may not crash you into 
auto-reboot before you have a chance to notice and report the state of 
wrongness.


VCPI function DE01, Get Protected Mode Interface, saves the high word of 
EAX across the call, where it did not before.  Nothing known needs this, 
but since the previous problem with WDOSX and VCPI function DE04, I decided 
it was best to put the VCPI functions on their best behavior.


Finally, to help counterbalance recent nastiness and ranting on- and 
off-list by a few (possibly including myself depending on who you ask), I 
will donate $0.10 to the International Federation of Red Cross and Red 
Crescent Societies (www.ifrc.org) for each unique IP address downloading 
either the source or binary package of EMM386 2.04 from my ftp site for the 
month of July.  This offer is subject to change or withdrawal in the 
unlikely event of impending poverty due to my site being slashdotted or 
otherwise subjected to site hammering.  Suspicion of serious abuse will 
result in disallowing broad IP ranges without recourse, including possible 
innocent parties in the middle of the range, so please think twice about 
having your ten grandmothers and 322 cousins download to "help out".





---
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP, 
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar

___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] EMM386 2.03 (minor, for WDOSX)

[Michael Devore]

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 extender.  It fixes an error which could 
cause those programs to crash or fail at startup.  If you do not ever use 
the WDOSX extender, 2.03 should operate no differently than 2.02.


Specifically, 2.03 saves the high word of the EAX register when servicing 
VCPI function DE04h, allocation 4K page.  WDOSX apparently uses the high 
word of the EAX register across the DE04h call, and certain values can make 
it fail.


This version of EMM386 also adds an IRETD after the HLT emulation 
instruction in the monitor code, as a safety net should the CPU continue 
after the HLT instruction.  This may help developers with QEMU debugging.


Notice that I am at off-development status for the summer.  This notice 
directly applies to the clown attempting to revive moribund driver projects 
so as to locate a developer more pliable to his personal software 
vision.  The notice does not apply to bugfixes and FreeDOS users who have 
legitimate high-priority items.  I will continue work as needed on those 
items, time permitting.





---
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.01

[Michael Devore]

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 with >256M and RSX >429M, or if the weirdness is 
in the extenders themselves.

Precisely I wanted to ask about EMX/RSX, as it seems quite difficult to
google.

- what EMX is exactly
- how does it relate to RSX.EXE?
- how does it compare to WDOSX, if it can be compared?


EMX/RSX came from one or more of the GCC camp of DOS-compatible 
developers.  It appears pretty old, older than WDOSX.  Think it should have 
been superseded by CWSDPMI, since there are references to the older GO32 
extender coincident with EMX/RSX documentation, but maybe not.


EMX must be necessary for OS/2 besides RSX because OS/2 is a DPMI server 
and DPMI is EMX's responsibility.


The basic explanation I came up with on brief research is that RSX is the 
VCPI-based extender and EMX is the glue to provide an interface to an 
existing DPMI server and/or acts as a DPMI server itself.  EMX is dependent 
on RSX being present, but RSX is only dependent on EMX for DPMI 
services.  That understanding could be wrong or backwards.





---
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r 
___

Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.01

[Arkady V.Belousov]

Hi!

3-Июн-2005 20:53 [EMAIL PROTECTED] (Aitor Santamar?a Merino) wrote to
freedos-user@lists.sourceforge.net:

ASM> Thanks, I read that, but I was wondering if someone could explain a
ASM> little bit more, does RSX/EMX provide DPMI as well, does it get the
ASM> system into protected mode, running as a single task a-la EMM386 or such
ASM> details

 Not me - I wasn't deal with protected mode programming.

ASM> Mere curiosity, but there isn't much documentation around.

__O\_/_\_/O__
Rainer Schnither
email to rainer at mathematik.uni-bielefeld.de
_
  O/~\ /~\O
__O\_/_\_/O__
   RAR/DOS32 is built by EMX C compiler and uses RSX DPMI extender.
EMX can be downloaded from ftp://ftp-os2.nmsu.edu/pub/os2/dev/emx/v0.9d
RSX - from ftp.uni-bielefeld.de/pub/systems/msdos/misc
_
  O/~\ /~\O




---
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r 
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.01

[Aitor Santamaría Merino]

Hi Arkady,

Thanks, I read that, but I was wondering if someone could explain a 
little bit more, does RSX/EMX provide DPMI as well, does it get the 
system into protected mode, running as a single task a-la EMM386 or such 
details

Mere curiosity, but there isn't much documentation around.

Aitor

Arkady V.Belousov escribió:

Hi!

2-Июн-2005 21:13 [EMAIL PROTECTED] (Aitor Santamarэa Merino) wrote to
freedos-user@lists.sourceforge.net:

ASM> - what EMX is exactly
ASM> - how does it relate to RSX.EXE?

copying.rsx:
RSX : DPMI-DOS 0.9/1.0 extender for 80386+ processors

rsx.exe:
RSX (32-bit 5.21) DPMI DOS extender for emx and rsxnt programs.
Copyright (c) Rainer Schnitker 1993-1998. All rights reserved.

emx.exe:
emx 0.9d (rev 61) -- Copyright (c) 1991-2000 by Eberhard Mattes
Usage: emx [-cdeoqOV] [-s]  []

 As I understand, EMX is a layer, which allows to run OS/2 programs
outside of OS/2. And Eugene Roshal selects EMX/RSX because this property.

ASM> - how does it compare to WDOSX, if it can be compared?

 Don't know, but I don't hear about OS/2 in context of WDOSX, which is
win32 emulator.




---
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r 
___

Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user




---
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.01

[Arkady V.Belousov]

Hi!

2-Июн-2005 21:13 [EMAIL PROTECTED] (Aitor Santamarэa Merino) wrote to
freedos-user@lists.sourceforge.net:

ASM> - what EMX is exactly
ASM> - how does it relate to RSX.EXE?

copying.rsx:
RSX : DPMI-DOS 0.9/1.0 extender for 80386+ processors

rsx.exe:
RSX (32-bit 5.21) DPMI DOS extender for emx and rsxnt programs.
Copyright (c) Rainer Schnitker 1993-1998. All rights reserved.

emx.exe:
emx 0.9d (rev 61) -- Copyright (c) 1991-2000 by Eberhard Mattes
Usage: emx [-cdeoqOV] [-s]  []

 As I understand, EMX is a layer, which allows to run OS/2 programs
outside of OS/2. And Eugene Roshal selects EMX/RSX because this property.

ASM> - how does it compare to WDOSX, if it can be compared?

 Don't know, but I don't hear about OS/2 in context of WDOSX, which is
win32 emulator.




---
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r 
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.01

[Aitor Santamaría Merino]

Hi there,

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 with >256M and RSX >429M, or if the weirdness 
is in the extenders themselves.



Precisely I wanted to ask about EMX/RSX, as it seems quite difficult to
google.

- what EMX is exactly
- how does it relate to RSX.EXE?
- how does it compare to WDOSX, if it can be compared?

Thanks in advance,
Aitor








---
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] EMM386 2.02 Stable (should be)

[Michael Devore]

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 is a generally recommended 
upgrade, but not critical.

EMM386 fixes an error which causes a tiny memory leak when allocating 
VCPI/EMS.  It fixes a more serious bug where -- under rare circumstance -- 
EMM386 incorrectly believed it was out of memory.  This was only known to 
happen with the Deskwork RAMdisk utility present, but it could possibly 
happen for other applications or environments.  EMM386 will also warn if an 
old or out-dated HIMEM version is used which does not allow XMS/EMS/VCPI 
common pool sharing.

Version 2.02 adds the new MAX= option to limit amount of available VCPI, 
and EMS if <32M.  Use this with versions of DOS/32A which fail if more than 
256M of VCPI is available.  2.02 also adds emulation support for the CPU 
RDTSC instruction in early Pentium and AMD chips.

Blathering on...
The memory leak bug would lead to temporary loss of 0-2% of allocated 
memory as unavailable for use due to invalid memory alignment skipping past 
0-3 available pages of memory per block.

The bug with DeskWork RAMdisk was due to an error where small free XMS 
blocks of <4K could, under certain circumstances of memory alignment, lead 
the EMS/VCPI allocator to believe there was no more free XMS to use, 
despite whatever free XMS blocks may exist.

The RDTSC emulation is as described.  Not much more to say about it.  It 
appears to be an Intel faulty design in Pentium chips, aped by comparable 
AMD processors.  Pentium Pro, II, and later chips do not have the 
problem.  As a consequence of my not having an old chip, the modification 
is untested.

If someone should decide on a whim, through curiosity, by mistake, or via 
basic stupidity, to use an out-dated or substandard XMS memory manager 
which does not support INT 2Fh function 4309h, thereby forcing EMM386 to 
turn off common pool-sharing, EMM386 will provide a startup warning message 
to the effect that the user should upgrade or use an explicit EMM= option 
sized allocation.

EMM386 supports the MAX= option which allows limiting the available 
VCPI to the MAX setting.  If less than 32M, it will also limit EMS.  EMM386 
is smart enough to throttle its doubling of XMS block allocations 
(currently 1.5M, 1.5M, 3M, 6M, 12M, etc) back down to a value under 
MAX.  MAX usage will be accurate to within approximately 1.5M.  As a 
vaguely amusing side-note, given the separate EMS and VPCI allocator, using 
up VCPI to MAX limits still allows EMS to separately use memory up to the 
MAX setting.

The MAX option is mostly for extenders or programs which inexplicably throw 
a tantrum if allowed too much free VCPI memory.  At least some versions of 
DOS/32A act this way.

The RSX DOS extender used by RAR32 throws a tantrum in a slightly different 
way.  If EMM386 is loaded, and more than 429M of memory is available EVEN 
IF almost all of memory is either left as XMS or taken from XMS to VCPI, 
then RSX will give an out of memory error.  It will not do that if EMM386 
is not loaded.  This includes any EMM386 MAX setting or use of a fixed pool 
via the EMM= option (as far as I could test, anyway).  You must use the 
/MAX=### option of HIMEM, not EMM386, to limit total memory to get around 
the problem.  RAR32 sobs quietly to itself over such bizarre behavior in 
its forced coupling with RSX.

This version is considered stable.  No more than the normal complement of 
bugs are expected to exist.  I will be available to fix those and answer 
the occasional inquiry, but otherwise am taking the summer off from 
anything that involves EMM386 and HIMEM.  Should anyone desire new features 
or a novelization on the perils of VCPI, they need look towards another 
EMM386 related/interested developer type of person, place or thing.


---
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] emm386 2.01 question

[Michael Devore]

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 terminate the program and work
continuesly. So that the program work in ring 3?
It is in V86 mode, but doesn't help a great deal.  Almost all DOS extended 
programs have their own address space and exception handling and EMM386 
isn't in control.  In "real" mode under the V86 monitor, a program which 
trashes any critical component of DOS or a driver before hitting an 
exception will crash the system.  And if they don't do that, there remain 
many ways to lock up a machine that is unrecoverable.

Despite this, EMM386 can successfully recover from some application errors 
with an abort message and termination to DOS.  It happens in my DOS 
sessions.  Go into DEBUG and Assemble the protected instruction LSL 
AX,AX.  You'll see it happen.



---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] emm386 2.01 question

[Florian Xaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
One question :-)
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 terminate the program and work
continuesly. So that the program work in ring 3?
Bye, Flo (sorry for the bad English, but i am very tired)
- --

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCe4SSq2aHU5S35E0RAow0AKDLEM2MENISXxuhWH983TJnQKjD7ACfQ/7C
kxZOSLt0olhfY6o55D/EZ1A=
=g92p
-END PGP SIGNATURE-
---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 v2.01 bug

[Michael Devore]

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 what 
occupied means.  EMM386 doesn't allocate EMS or VCPI until it's needed by 
something.


---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 v2.01 bug

[Fox]

On Thursday 05 May 2005 23:19, Arkady V.Belousov wrote:
> Hi!
>
> 5-Май-2005 08:55 [EMAIL PROTECTED] (Fox) wrote to
> freedos-user@lists.sourceforge.net:
>
> F> No, my system is just fine. It's a Cel 850 with 384 MB RAM (by the way,
> if I F> don't specify the /MAX=129000 parameter on HIMEM, then at boot all
> my XMS F> memory is reported as occupied (with only about 1MB free)!) and a
> DVD drive.
>
>  What program reports "occupied"?

The FreeDOS MEM (it's the only program I know which i able to play with memory 
bigger than 64MB)

Fox


---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r 
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 v2.01 bug

[Arkady V.Belousov]

Hi!

5-Май-2005 08:55 [EMAIL PROTECTED] (Fox) wrote to
freedos-user@lists.sourceforge.net:

F> No, my system is just fine. It's a Cel 850 with 384 MB RAM (by the way, if I
F> don't specify the /MAX=129000 parameter on HIMEM, then at boot all my XMS
F> memory is reported as occupied (with only about 1MB free)!) and a DVD drive.

 What program reports "occupied"?




---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r 
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 v2.01 bug

[Fox]

On Wednesday 04 May 2005 20:09, Michael Devore wrote:
> Is the sound garbled because your CPU is maxed out, the CD transfer is too
> slow, or because something is causing corruption? If your CPU is maxed out

No, my system is just fine. It's a Cel 850 with 384 MB RAM (by the way, if I 
don't specify the /MAX=129000 parameter on HIMEM, then at boot all my XMS 
memory is reported as occupied (with only about 1MB free)!) and a DVD drive.

> If you think you're getting corruption, try X=A000-EFFF in your EMM386 line
> to temporarily exclude all high memory.  Perhaps there is a conflict with a
> UMB block.  If that clears up the problem, then you'll need to figure out
> exactly which 4K block(s) (for example D800-DBFF and EC00-EFFF) need to be
> excluded to get back the rest of your upper memory.  If that does not clear
> it up, look to what drivers could be using VDS.  Few things do, UDMA is
> one, network drivers are another, and I don't know if MPXPLAY does or
> not.  If possible, try turning off VDS option for those applications and
> see if your music starts working.

Indeed, I'm using an UDMA CD driver (when using the default FreeDOS driver 
files with bitrate higher than 160kbps are garbled because of the poor 
transfer). It's the same driver that I told about some times ago (but not the 
same PC). When CD driver loaded into High memory, the PC hangs when I try to 
load something from CD, when I load it into low, it's ok IF there isn't the 
VDS parameter in EMM386 (otherwise the sound is crappy and the PC hangs at 
MPXPLAY's exit).

Offtopic:
I remarked recently that the high mem amount has decreased on my PC (the one 
about which I posted bug reports in Bugzilla) from 160kb to 152kb (I don't 
know why) and my UDMA CD driver is working just fine (no matter low or high 
mem)!


Fox


---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.01

[Michael Devore]

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 I
Works fine for me.  Try turning off your sound card and see if it works 
since I don't have one that it knows.  Also try with minimal HIMEM/EMM386 
CONFIG.SYS and AUTOEXEC.BAT to see there is a driver conflict.  Also, post 
your MEM /X output.


---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.01

[Michael Devore]

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, if you think it's enough legal.
Legal enough for me.  I'm just going to test BP 7 and try to improve 
general OS compatibility, not work with it for any real purposes.

Used to be, commercial companies quietly supported that sort of 
distribution since it helped out their end-users and improved their 
product.  I have two big boxes full of software for those purposes slowly 
rotting away somewhere in my basement.  Now, because of the draconian 
anti-piracy legislation passed across the world on one side and massive 
abuse by software thieves on the other side, they can't/won't support that 
approach even unofficially.


---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 v2.01 bug

[Michael Devore]

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 
anything at all about how EMM386 works.  It's only an interface for other 
applications and strictly an informational interface at that, dealing with 
what memory (re)maps look like and their alignments.  So whatever is 
happening with VDS present is occurring due to a program and not EMM386.

Is the sound garbled because your CPU is maxed out, the CD transfer is too 
slow, or because something is causing corruption? If your CPU is maxed out 
or CD transfer speed, there is not much I can tell you other than trying 
options to reduce CPU load or speeding up CD (by caching or better DOS 
driver or faster drive or what have you).  Playing music under DOS in an 
unoptimized system could push things too hard.

If you think you're getting corruption, try X=A000-EFFF in your EMM386 line 
to temporarily exclude all high memory.  Perhaps there is a conflict with a 
UMB block.  If that clears up the problem, then you'll need to figure out 
exactly which 4K block(s) (for example D800-DBFF and EC00-EFFF) need to be 
excluded to get back the rest of your upper memory.  If that does not clear 
it up, look to what drivers could be using VDS.  Few things do, UDMA is 
one, network drivers are another, and I don't know if MPXPLAY does or 
not.  If possible, try turning off VDS option for those applications and 
see if your music starts working.

I don't know where your INT changed messages are coming from or what they 
are about.


---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] EMM386 v2.01 bug

[Fox]

Hi,

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.
If I load EMM386 without the VDS option, the music is ok on the disk and on 
CD. By the way, when the sound is garbled and I want to quit MPXPLAY, I get a 
lot of "INT changed" messages which fills up the screen and the PC hangs.
When EMM loaded without VDS, I got only one message about "INT changed" and I 
can still use the PC.

Fox


---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.01

[Roberto Mariottini]

Hi,
Michael Devore wrote:
I don't do Pascal so I don't have that compiler.  I'm assuming that BP 7 
is simply not available for download anywhere other than transient 
illegal warez sites so I probably can't get and test it.
I downloaded BP 7 in a legal way a couple of years ago from the Borland 
France site (www.borland.fr). It required a simple free registration, to 
get their little french newsletter by e-mail trice a year.

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, if you think it's enough legal.

Ciao
---
http://www.mariottini.net/roberto/
---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.01

[Fox]

On Tuesday 03 May 2005 21:36, Michael Devore wrote:
> Jazz runs okay for me, at least as far as running the green rodent around
> and shooting things.  Only problem I have with Jazz is the need to run
> SLOWDOWN to get my computer to 20% speed to avoid the Turbo Pascal runtime
> error 200 problem.  Do you have to run SLOWDOWN or another slow-style
> program ot make Jazz work, or is your CPU slow enough it's not a
> problem?  What's your testing CPU?

I don't need to slowdown my CPU anymore with Jazz, as I patched the JAZZ.EXE 
file with TPPATCH.EXE :)
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 I 
have.

Regards,
Fox


---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.01

[Michael Devore]

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 with >256M and RSX >429M, or if the weirdness is in the 
extenders themselves.
Well, trying to figure it out, I did find a fairly innocuous bug where 
blocks could slightly underuse allocated XMS and waste a few K here and 
there, but not big amounts.  So the extender limits weren't totally a waste 
of time to check out.  But they still exist, for reasons I can't fathom.

I'll put the minor bugfix in a version 2.02, but no hurry.  Maybe add MAX= 
option then.  See if any real bugs crop up over the next three or four 
weeks that need immediate attention.


---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.01

[Michael Devore]

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 it's "out of memory".

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 with >256M and RSX >429M, or if the weirdness is in the 
extenders themselves.


---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.01

[Michael Devore]

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 Jazz is the need to run 
SLOWDOWN to get my computer to 20% speed to avoid the Turbo Pascal runtime 
error 200 problem.  Do you have to run SLOWDOWN or another slow-style 
program ot make Jazz work, or is your CPU slow enough it's not a 
problem?  What's your testing CPU?


---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.01

[Michael Devore]

At 08:22 PM 5/3/2005 +0200, Fox  wrote:
By the way, I get exactly the same error when trying to launch Borland Pascal
7 (BP.EXE)
I don't do Pascal so I don't have that compiler.  I'm assuming that BP 7 is 
simply not available for download anywhere other than transient illegal 
warez sites so I probably can't get and test it.


---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.01

[Fox]

On Tuesday 03 May 2005 19:16, Michael Devore wrote:
> At 02:57 PM 5/3/2005 +0200, Fox wrote:
> 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 it, but the "DOS link" I found actually led to a
> Windows version, as I found after the download.

You found the Jazz 2 game, which is indeed for Windows.

Jazz 1 can be downloaded from http://www.dosgamesarchive.com/download/game/111

By the way, I get exactly the same error when trying to launch Borland Pascal 
7 (BP.EXE)

Best regards,
Fox


---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.01

[Arkady V.Belousov]

Hi!

3-Май-2005 12:16 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-user@lists.sourceforge.net:

MD> I'm pretty sure I have/had RAR32, somewhere, but it wasn't in the test

http://www.rarlab.com/rar/rarx341.exe




---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r 
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] emm386 2.01 tested

[Florian Xaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
Now MPXPLAY doesn't shut down at start up, but randomly if i change
directory. I am using the PMODE/W driver. It seems, that PMODE/W has
this problem...
(I am also using it under WinXP and there isn't any problem. Also
without EMM386, there is no problem.)
Hope i can you tell you more tomorrow.
Bye, Flo
- --

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCd7T+q2aHU5S35E0RAk1VAKDPYml18yRmHaV6KU70SG6lpWK4vgCbBKpv
ksHONTYM8E6gCt7/mUYdJcc=
=gNWc
-END PGP SIGNATURE-
---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 2.01

[Michael Devore]

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 it, but the "DOS link" I found actually led to a 
Windows version, as I found after the download.

I'm pretty sure I have/had RAR32, somewhere, but it wasn't in the test 
suite.  I'll have to dig around, see what's stuffed in the test disks.


---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] EMM386 2.01

[Fox]

Hi,

My today's FreeDOS session looked like that:

RAR 3.2 (RAR32.EXE)
ATOMINO
LAME
MPXPLAY (The DOS32 version)
Jazz -> don't ran. Just showed "Unhandled exception 000E at 0020 1BEF ErrCode 
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) :-)

Fox


---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] EMM386 2.01 Bugfix Released

[Michael Devore]

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 recommended upgrade 
for earlier 1.x EMM386 versions.
Approximately half of all users will experience a fatal error in version 
2.0 that 2.01 fixes, and another bug fixed in 2.01 could cause a crash for 
any user as they run applications, although it is much less common.

EMM version 2.01 also supports the CPU WRMSR instruction and DOS 
redirection of help screen output, as does the HIMEM included.

This version should be quite a bit more stable, but the possibility of 
lingering or less serious bugs after the extensive 1.x -> 2.0 rewrite is 
moderate.  Please report any problems.

A quick rundown of change details follows:
During initialization when pool-sharing was present (no EMM= setting), 
EMM386 could compute an odd 16K amount of free memory, depending on total 
available XMS memory.  The odd 16K was not properly masked to an even 32K 
border, leading to immediate fatal errors when an application using EMS or 
VCPI was used and memory allocated to the program.  It was pure luck 
whether your machine computed an odd or even amount of 16K blocks 
available, so approximately 50% of all users were probably affected.

Another error that could occur during runtime allocation of XMS to an 
EMS/VCPI memory was a 8-bit value overflow if the value was 0FDh or 
higher.  This could happen any time a new XMS allocation was made to 
EMS/VCPI pool allocation blocks.  I'd roughly guess 5-10% of users might 
encounter the problem over the lifetime of a DOS session.

EMM386 and HIMEM allow DOS redirection of their command line output to a 
file or through MORE, etc.  Whoopee.  The relevant modification is in 
PRF.C.  Alert code browsers may note the user of an extremely dumb #ifdef 
to change to this behavior.  Borland/Turbo C doesn't like #ifdef 0 for 
reasons which escape me, so I just forced it to work rather than waste time 
fooling around guessing how the compiler's brain worked.

The protected CPU instruction WRMSR is supported via EMM386 emulation in 
its exception handler, to match its twin instruction RDMSR.

Two trivial wording changes were made to HIMEM.

---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 gun-smoking with HIMEM /max

[Michael Devore]

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, es=0...).
Well, hey, finally.  If I set /MAX=300M, suddenly everything related to EMS 
and VCPI is totally hosed, just like with your stuff.  Now if I can track 
the problem down with the limited tools that work when it's in such a sorry 
state.


---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] EMM386 gun-smoking with HIMEM /max

[Michael Devore]

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 block.  Since that portion of the 
code was never stress tested -- I never had the proper XMS fragmenting
Well, that checked out okay.  I'm back to having a fully working system and 
trying to figure out ways to make it crash.


---
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user