[Freedos-user] emm386, himem.sys, config.sys
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=60135031iu=/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
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 garz...@gmail.com 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=60135031iu=/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=60135031iu=/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
Hi, On Wed, Oct 16, 2013 at 9:28 PM, Miguel Garza garz...@gmail.com 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=60135031iu=/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
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
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
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.phpp=sourceforgeCID=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
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.phpp=sourceforgeCID=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
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.phpp=sourceforgeCID=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
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.phpp=sourceforgeCID=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
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.phpp=sourceforgeCID=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
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.phpp=sourceforgeCID=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
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.phpp=sourceforgeCID=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
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.phpp=sourceforgeCID=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 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.phpp=sourceforgeCID=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
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
[Freedos-user] EMM386 causes Ctrl-Alt-Del to fail with some video cards
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. Thescreen goes black, but the video and system BIOS boot messages never reappear. Very occasionallythe 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 causes Ctrl-Alt-Del to fail with some video cards
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=lnkkid=110944bid=241720dat=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
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=lnkkid=110944bid=241720dat=121642 ___ 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
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=7637alloc_id=16865op=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 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=7637alloc_id=16865op=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
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=7637alloc_id=16865op=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 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=7637alloc_id=16865op=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
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=7637alloc_id=16865op=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
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=7637alloc_id=16865op=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
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=7637alloc_id=16865op=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
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=7637alloc_id=16865op=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
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_idv37alloc_id865op=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)
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)
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 application/driver and IFNOT application/driver 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)
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
[Freedos-user] EMM386
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
Re: [Freedos-user] EMM386 2.05 update, recommended for all
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
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
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
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
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
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
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
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
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
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
Re: [Freedos-user] EMM386 2.05 update, recommended for all
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
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 Bug Report
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 Bug Report
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, recommended for all
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, recommended for all
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
[Freedos-user] EMM386 2.05 update, recommended for all
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
Re: [Freedos-user] EMM386 VDS test fix, works with HP Pavilion
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
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
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
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
[Freedos-user] EMM386 'horse' went wild
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=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386 'horse' went wild
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=7477alloc_id=16492op=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
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)
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
Hi! 2--2005 21:13 [EMAIL PROTECTED] (Aitor Santamara 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] [-sstack_size] program [arguments] 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
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
[Freedos-user] EMM386 2.02 Stable (should be)
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=7412alloc_id=16344op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386 v2.01 bug
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
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 2.01 question
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
Re: [Freedos-user] EMM386 v2.01 bug
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
[Freedos-user] EMM386 v2.01 bug
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 v2.01 bug
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
Re: [Freedos-user] EMM386 2.01
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 2.01
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
[Freedos-user] EMM386 2.01
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
Re: [Freedos-user] EMM386 2.01
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 tested
-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 - -- http://www.drdos.org -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
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
Re: [Freedos-user] EMM386 2.01
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
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
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
[Freedos-user] EMM386 2.01 Bugfix Released
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
[Freedos-user] EMM386 gun-smoking with HIMEM /max
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...). Interesting enough, you can add a bit (less than 5 MB, did not test the exact value) to the limit before Quarterdeck MFT stops to detect the fact that EMS and XMS have a shared memory pool (MFT only looks at XMS 2.0 values, it seems). With this limit, everything works: GCUBE (PMODE/W), ZIP (CWSDPMI), CTSTOAST (with DOS32A), Jazz Jackrabbit (RTM/DPMI16BI), AuGoS (same)... There must be something interesting about it. The memory statistics tell me that I have *exactly* 27 MBytes (27648kB) of EMS free with this limit, and 27717kB of XMS free. Full usage statistics: 84992kB total, 27717kB free XMS, 344kB locked XMS for EMM386 (includes the 96kB SYSTEM handle for UMBs, I assume, and 248kB other stuff), 15000kB for TDSK ramdisk, 3kB for XMSDSK ramdisk, 4096kB for CDR- cache, 7680kB for LBA-cache, 155kB for FreeCOM XMS swap. Tempting to assume that the actual critical limit is in EMS or VCPI, not in XMS, as at this moment exactly 27 MB EMS are free... Eric PS: Even the MFT EMS benchmark starts working at the same limit, even though the shared pool detection keeps working a bit longer, until you have roughly 32 MB XMS and EMS free instead of only 27 MB. --- 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
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...). With this limit, everything works: GCUBE (PMODE/W), ZIP (CWSDPMI), CTSTOAST (with DOS32A), Jazz Jackrabbit (RTM/DPMI16BI), AuGoS (same)... There must be something interesting about it. The memory statistics tell me that I have *exactly* 27 MBytes (27648kB) of EMS free with this limit, and 27717kB of XMS free. Full usage statistics: 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 -- the nibble code may have a bug or bugs in it. Have to study on the source, see if anything improper leaps out in that area. If present, hopefully that will address the apparent DOS32A limit on 256M VCPI and let us know if it is really there. Perhaps it's getting confused due to a similar/same bug. Otherwise we have a serious problem with 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 gun-smoking with HIMEM /max
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
Re: [Freedos-user] EMM386 v2.0
On Friday 29 April 2005 17:58, Michael Devore wrote: At 03:51 PM 4/29/2005 +0200, you wrote: (...) Aladdin is still not working with EMM386 2.0 (...) You need to use /X2MAX32 option with HIMEM, on the HIMEM line in CONFIG.SYS. I tested Aladdin right before release with it. Nothing to do with EMM386, it doesn't distribute XMS. Sorry - I didn't read exactly about the /X2MAX32... Indeed wit that switch alladin is working ok :) Best regards, Fox -- http://the.killer.webpark.pl --- 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.0 Released
Thanks! I've updated the LSM, mirrored the release, and posted a news item on FreeDOS.org. Should show up in a few minutes. -jh Michael Devore wrote: Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files emmx20.zip, EMM386/HIMEM mostly executable package, and emms20.zip, EMM386/HIMEM mostly source package. Version 2.0 of EMM386 supports sharing of extended memory between EMS, XMS, and VCPI from a common pool. For most users this means no more need to specify EMM= in your EMM386 command, because the full amount of memory is available to all memory classes, more or less. Should you wish to limit memory for EMS/VCPI, you can still use the EMM= setting. Some programs may require this due to their failure to work with too much free memory. Additionally, HIMEM supports the /X2MAX32 option which limits XMS 2.0 memory reported to 32767K, to work around a dumb bug in Disney's Aladdin game, and possibly others. Full XMS memory is still present. EMM386 also has a couple of bug-fixes that will affect almost nobody. Be aware that some 1500 lines of assembly language code were added in this version of EMM386, with another few hundred lines replaced or deleted. The actual code changes exceed that made for earlier VCPI support. Unnoticed (hopefully small) errors are virtually guaranteed. Please test applications and report any problems. Various particulars ensue: With the /X2MAX32 option of HIMEM, full XMS memory is still available for both XMS 2.0 and 3.0 functions, and is fully reported on XMS 3.0 functions, eliminating the previous need to literally reduce all available memory to 32M via HIMEM's MAX option get Aladdin to run. The /? option is supported for HIMEM and EMM386. Running HIMEM and EMM386 at the command line will continue listing commands, as before, but will not complain if /? is present. Use of /? will henceforth be known as the Arkady gambit. The EMS system handle 0 name is preset to SYSTEM. Also, memory for UMBs are allocated to that handle, rather than in a separate handle as before. Since the EMS and VCPI allocators are now decoupled, I reduced maximum available EMS to industry-standard 32M. Mostly this was done because silly EMS-using programs became confused if more than 32M was available. Pumping it back up to 512M would be a small change, but probably unnecessary for anyone. VCPI can go to 4G, theoretically. There is a fix to INT 15h, function 87 in EMM386, but I have forgotten the details. Eric Auer can supply them in exhaustive detail, should one wish. EMS unmap page function 44h, bx = -1, has been broken for about a thousand years. It would map in garbage memory rather than original page frame memory, possibly leading to a crash. Apparently it's not very critical since nobody has noticed going back to the original EMM386 code. On a very trivial note, EMM386 now supports common memory pool-sharing between EMS, XMS, and VCPI, if a HIMEM version which supports INT 2fh function 4309 is present (like recent FreeDOS versions). No more EMM=, usually. As a consequence, the former VCPI reserve was removed. As a further consequence, should you wish to use a nonstandard HIMEM without function 4309 support and do not specify an EMM= setting, there will be approximately zero memory available for EMS and VCPI. If you do that, you are 100% on your own. EMM386's pool-sharing feature is a bit more sophisticated than originally planned. It will search out the closest match to 1.5M available in XMS free handles and use a matching handle to grow its memory allocations. If there is -- as is typical in a vanilla FreeDOS environment -- only one monolithic XMS handle containing all free memory, it will dynamically carve off a 1.5M slice as needed. If there are a litter of small amount of XMS handles of at least 32K size, EMM386 will vacuum them up before carving up bigger pieces. Nor will EMM386 voraciously consume precious XMS handles, given how limited they are in number. After the first couple of 1.5M allocations, EMM386 starts doubling the allocation amount, assuming that an application is after big memory game. With the doubling feature used against a single XMS handle holding all free memory, no more than 13 handles need be consumed before the entire 4G address space is covered. EMM386 will also return XMS blocks to the pool when they are no longer used by any EMS/VCPI allocation, where they may be used again by EMS or VCPI, or allocated via XMS API functions. You should be aware that there is no free lunch and pool-sharing may increase memory allocation timing overhead by microseconds. This would be most noticeable when large blocks of EMS/VCPI are allocated, then freed, since EMM386 will be dipping into and out of the common memory pool as blocks come in and then go out of scope. Hundreds of other small details and comments preempted in interest of time, space, and sanity... Questions,
[Freedos-user] EMM386 v2.0
Hi, I'm just reporting, that Aladdin is still not working with EMM386 2.0 - still the same error message: XMS memory allocating error. When I waste some XMS with EATXMS, the game launch ok. Fox --- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] EMM386 2.0 Released
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files emmx20.zip, EMM386/HIMEM mostly executable package, and emms20.zip, EMM386/HIMEM mostly source package. Version 2.0 of EMM386 supports sharing of extended memory between EMS, XMS, and VCPI from a common pool. For most users this means no more need to specify EMM= in your EMM386 command, because the full amount of memory is available to all memory classes, more or less. Should you wish to limit memory for EMS/VCPI, you can still use the EMM= setting. Some programs may require this due to their failure to work with too much free memory. Additionally, HIMEM supports the /X2MAX32 option which limits XMS 2.0 memory reported to 32767K, to work around a dumb bug in Disney's Aladdin game, and possibly others. Full XMS memory is still present. EMM386 also has a couple of bug-fixes that will affect almost nobody. Be aware that some 1500 lines of assembly language code were added in this version of EMM386, with another few hundred lines replaced or deleted. The actual code changes exceed that made for earlier VCPI support. Unnoticed (hopefully small) errors are virtually guaranteed. Please test applications and report any problems. Various particulars ensue: With the /X2MAX32 option of HIMEM, full XMS memory is still available for both XMS 2.0 and 3.0 functions, and is fully reported on XMS 3.0 functions, eliminating the previous need to literally reduce all available memory to 32M via HIMEM's MAX option get Aladdin to run. The /? option is supported for HIMEM and EMM386. Running HIMEM and EMM386 at the command line will continue listing commands, as before, but will not complain if /? is present. Use of /? will henceforth be known as the Arkady gambit. The EMS system handle 0 name is preset to SYSTEM. Also, memory for UMBs are allocated to that handle, rather than in a separate handle as before. Since the EMS and VCPI allocators are now decoupled, I reduced maximum available EMS to industry-standard 32M. Mostly this was done because silly EMS-using programs became confused if more than 32M was available. Pumping it back up to 512M would be a small change, but probably unnecessary for anyone. VCPI can go to 4G, theoretically. There is a fix to INT 15h, function 87 in EMM386, but I have forgotten the details. Eric Auer can supply them in exhaustive detail, should one wish. EMS unmap page function 44h, bx = -1, has been broken for about a thousand years. It would map in garbage memory rather than original page frame memory, possibly leading to a crash. Apparently it's not very critical since nobody has noticed going back to the original EMM386 code. On a very trivial note, EMM386 now supports common memory pool-sharing between EMS, XMS, and VCPI, if a HIMEM version which supports INT 2fh function 4309 is present (like recent FreeDOS versions). No more EMM=, usually. As a consequence, the former VCPI reserve was removed. As a further consequence, should you wish to use a nonstandard HIMEM without function 4309 support and do not specify an EMM= setting, there will be approximately zero memory available for EMS and VCPI. If you do that, you are 100% on your own. EMM386's pool-sharing feature is a bit more sophisticated than originally planned. It will search out the closest match to 1.5M available in XMS free handles and use a matching handle to grow its memory allocations. If there is -- as is typical in a vanilla FreeDOS environment -- only one monolithic XMS handle containing all free memory, it will dynamically carve off a 1.5M slice as needed. If there are a litter of small amount of XMS handles of at least 32K size, EMM386 will vacuum them up before carving up bigger pieces. Nor will EMM386 voraciously consume precious XMS handles, given how limited they are in number. After the first couple of 1.5M allocations, EMM386 starts doubling the allocation amount, assuming that an application is after big memory game. With the doubling feature used against a single XMS handle holding all free memory, no more than 13 handles need be consumed before the entire 4G address space is covered. EMM386 will also return XMS blocks to the pool when they are no longer used by any EMS/VCPI allocation, where they may be used again by EMS or VCPI, or allocated via XMS API functions. You should be aware that there is no free lunch and pool-sharing may increase memory allocation timing overhead by microseconds. This would be most noticeable when large blocks of EMS/VCPI are allocated, then freed, since EMM386 will be dipping into and out of the common memory pool as blocks come in and then go out of scope. Hundreds of other small details and comments preempted in interest of time, space, and sanity... Questions, comments, problems, let me know. I'll be around for a while as this settles down, then after a suitable break, may take a look at fixing CWSDPMI's faults or
[Freedos-user] EMM386 problem
Hi, I've installed recently FreeDOS on an friend's PC (Cel 850 / 384 MB SDRAM). That PC have a Sound Blaster 64 PCI sound card and I have a big problem to install its driver. The driver must be launched when HIMEM EMM386 are installed, and it needs to have at least 2MB of the first 4MB XMS memory free. I know that sounds weird :) Basically, there should be 2MB of free ram in the range 0MB XMS ... 4MB XMS. The driver need it to load the MIDI samples (they aren't present onboard). The problem is that when I load EMM386, it takes instantly 13'266 kb of XMS memory! Obviously, the first 4MB aren't available anymore :( I tried following EMM386 combinations: EMM386 NOEMS FRAME=NONE X=TEST EMM386 NOEMS I=TEST EMM386 NOEMS SB EMM386 NOEMS SB NOVCPI When I load EMM386 with the NOVCPI parameter, it takes only about 200kb of XMS, so it could be ok, unfortunately the SB driver needs VCPI :( As far as I know, EMM386 souldn't take any XMS?? Of course, I have the latest versions of HIMEM.EXE, EMM386.EXE, COMMAND.COM and KERNEL (these are the only things I load) Best regards, Fox --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386 problem
At 08:03 PM 4/24/2005 +0200, Fox wrote: Hi, I've installed recently FreeDOS on an friend's PC (Cel 850 / 384 MB SDRAM). That PC have a Sound Blaster 64 PCI sound card and I have a big problem to install its driver. The driver must be launched when HIMEM EMM386 are installed, and it needs to have at least 2MB of the first 4MB XMS memory free. I know that sounds weird :) Use EMM=2048 or 1024 or some lower type value somewhere below 3M VCPI must keep a reserve or else things which use VCPI fail, so a default value is used based on total available memory if there isn't an explicit amount set via EMM=. This issue will go away in a few days with next EMM386 release. The real solution, of course, is for the original developers not to have written a driver so stupid as to require using the first 2-4M of extended memory, but it's a reality we have to live with. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386 1.15 release is out
At 05:05 AM 2/21/2005 -0800, Charlie Wilkes wrote: Far out man! I just played Master of Orion for about an hour and it worked great with this version. Not good with mi.com, however... weird characters and a manic counter spinning away at the very bottom of the screen... BONG HIT! Gotta reboot. If you're using version 9 of MI, it works fine here, although it doesn't understand 64M XMS or higher EMS amounts, and NOEMS or FRAME=NONE might confuse it. If not version 9, you can send your copy of MI to me and I'll see if the problem duplicates. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] EMM386 bugs update
Uploaded to ftp://ftp.devoresoftware.com/downloads are the files emmx13b.zip, EMM386 mostly executable package, and emms13b.zip, EMM386 mostly source package. These versions follow the latest EMM386 fileset template directory and naming conventions. EMM386 supports [in|ex]clusion ranges to without rejection. Excluding all UMB's no longer turns off the VDS option. The unimplemented VDS function feedback was corrected for function values 9. /MAX was re-added to HIMEM command line feedback. A minor one-byte too far check for DMA buffering was corrected. An undocumented and likely temporary MEMCHECK option was added to EMM386. MEMCHECK was added after discovering that USBASPI.SYS could provide out of range values to INT 15h function 87h block move, causing a reboot. The cause of this out-of-range value is not known, as it's buried deep in the application, ultimately accessed through an indexed lookup table. MEMCHECK simply checks block moves and rejects any to or from addresses beyond current extended memory limits. This stops USBASPI.SYS from rebooting systems, but unfortunately apparently doesn't fix it enough to make it work properly. Maybe I'll be able to figure out what's happening with it and what is at fault when I get my Lexar JumpDrive from Amazon. EMM386 VDS operation for its supported API subset was checked against MS EMM386 behavior and found to have no errors, other than MS EMM386 mapping the 1M+64K HMA area to 0:0 since it turns A20 off and on dynamically. Everyone who uses UMBs with disk, network, and other DMA-based drivers should repeat this mantra: Failure to operate to expectations does not imply a bug. EMM386 can catch only certain types of DMA access to remapped memory. DMA writes to physical machine addresses; programs write to linear addresses. By trapping standard DMA ports, EMM386 tries to resolve conflicts by changing addresses on the fly and using buffering when it sees a read or write to remapped memory. However, if a piece of hardware uses other ports it will bypass this check. Also, I've uncovered at least a couple ways of using the standard DMA ports that EMM386 does not compensate for -- which may or may not be correctable but requires a testable suspect situation on-site to modify. Different uses of UMBs, with our without VDS, may always fail with certain hardware setups. To help determine what and when to report an error with EMM386, please use the following guidelines: If EMM386 fails at startup with all potential UMB's excluded (X=A000-) on your machine, with or without VDS, there is a major problem and you should let me know. If EMM386 reports an unimplemented VDS function when VDS is specified, let me know and I'll try to add support for that function. If EMM386 fails with only certain UMB's included and works with them excluded, I probably can't help you. Something doesn't like that upper memory block usage and it's likely specific to your machine. If EMM386 fails with certain applications loaded high which work loaded low, I also probably can't help you. Some applications are destined not to live in remapped memory. However, if you send me the application and I can duplicate the problem here, I may be able to determine what's failing and why. If you have strong suspicions of a bug or incompatibility outside of the above guidelines, let me know and I will see what can be done about it. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Freedos-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] EMM386 enhancement, plus cosmetic HIMEM change
Uploaded to ftp://ftp.devoresoftware.com/downloads are the files emm386.zip and himem.zip containing uncompressed executables of, respectively, EMM386.EXE and HIMEM.EXE, plus the source files modified in this latest version. EMM386 adds support for EMS function 51h, reallocate pages. This enhancement allows Lemmings 3 The Chronicles, known in Europe as All New World of Lemmings, to execute, through title screens. My test copy of Lemmings 3 failed due to CPU speed restrictions, but the SLOWDOWN utility allowed it to work a while. I also modified HIMEM so that its text feedback properly showed the /MAX option to be /MAX= instead of a trailing colon. No operational differences were made, just the one text character was changed. If anyone has Lemmings 3 to test and still encounters problems, I will need a patched or updated copy which works with faster machines to test. Otherwise I can't tell whether the instability here is due to the machine slowdown to 5% normal, EMM386, or an entirely different cause. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ Freedos-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386.exe
Hi! 17--2004 16:47 [EMAIL PROTECTED] (Michael Devore) wrote to [EMAIL PROTECTED]: as always, your message appears as 1 long line. Very wide. Manually quoting now.. MD wins and I'll change or not, accordingly. What I won't do is change away MD from using the world-standard multi-platform Eudora after ten+ years along MD with a few million other people. Do you mean, that Eudora can't hardly wrap long lines?! I don't beleive. :) MD I have no idea what Eudora is doing, the e-mails look okay to me going out MD with plain style. By the way, your original quote-back was not wrapped and - original (unqoted) letter my mailer automatically wraps (when viewed or when answered). - quotes in viewed/answered letter are untouched. Thus, if someone answers to your letter (and not _manually_ edits your text), then I see very long (outside screen borders) lines. Sometime I manually edit (your) quotes, when answer to letters (for example, if I answer to letter of Eric, which answers to you), but in last answer to Bernd I remain your long line untouched. MD indented, and Bernd's was, so what does that mean? MD This all would be a good deal easier if sundry people weren't taking this MD silly HTML-email-is-evil, my extra bandwidth bill is .238 more MD euros/dollars when HTML is used, my billable time to scan past a few extra MD lines costs an additional 3 zillion zloty's attitude. Don't forget about time (to receive and process HTML letters), which costs much more. Not all sits on wide bandwith. --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id%62alloc_ida84op=click ___ Freedos-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386.exe
Hi! 18--2004 12:23 [EMAIL PROTECTED] (Michael Devore) wrote to [EMAIL PROTECTED]: no big problem. MD Alright, I changed to hard CR's, I look at source of your letter (which I answer) - no, there are no hard CRs inside paragraphs. :) :( --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id%62alloc_ida84op=click ___ Freedos-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386.exe
At 12:47 AM 5/19/2004 +0400, you wrote: Hi! 18-íÁÊ-2004 12:23 [EMAIL PROTECTED] (Michael Devore) wrote to [EMAIL PROTECTED]: no big problem. MD Alright, I changed to hard CR's, I look at source of your letter (which I answer) - no, there are no hard CRs inside paragraphs. :) :( That's because the option checkbox didn't apply for who knows why. But it's in there now. --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id%62alloc_ida84op=click ___ Freedos-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] EMM386.exe
Hi I am testing the latest Beta of FreeDos9 on my PC: ASUS P4C800E Deluxe with 1024 MB ram with following Config.sys Menu Item 2: !SET dosdir=C:\FDOS !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 ;below is a demonstration of the FreeDOS multi-configuration menu system. !LASTDRIVE=Z !BUFFERS=20 !FILES=40 !DOS=HIGH,UMB !DOSDATA=UMB !set dircmd=/ogn !MENUCOLOR=7,0 MENUDEFAULT=1,5 MENU 1 - Load FreeDOS including HIMEM XMS-memory driver MENU 2 - Load FreeDOS with maximum RAM free, using EMM386 MENU 3 - Load FreeDOS without drivers MENU 4 - Load FreeDOS HIMEM64 MENU 5 - Load FreeDOS TEST 25?DEVICE=C:\fdos\bin\FDXXMS.SYS BIOS NUMHANDLES=64 ;5?DEVICE=C:\fdos\bin\HIMEM.EXE ;5?DEVICE=C:\fdos\bin\FDXMS.SYS ;5?DEVICE=C:\fdos\bin\FDXMS286.SYS 1?DEVICE=C:\FDOS\BIN\HIMEM.EXE 4?DEVICE=C:\FDOS\BIN\HIMEM64.EXE 2?DEVICE=C:\FDOS\BIN\EMM386.EXE NOEMS I=B000-B7FF I=DC00-EBFF I=C800-C8FF ;1?DEVICE=C:\FDOS\bin\atapicdd.sys /D:FDCD0001 1245?SHELLHIGH=c:\command.com /E:1024 /K C:\FDOS\fdauto.bat 3?SHELLHIGH=c:\command.com /D /K set path=C:\FDOS\bin I tried many combination of EMM386.exe I got still: ILLEGAL INSTRUCTION OCCURED CS=ECB0 IP=47CA SS=00CF SP=C1D9 DS= ES00CF EAX=00FCC2D2 EBX=0001 ECX=8C88 EDX=CA52 ESI=2620 EDICD07 EBP=0E5E Opcodes @CS:IP 0F 00 05 03 02 13 03 00 I found no way with EMM386.exe Aborting Is FreeDos supporting 1024MB Ram I didn't found Infos about what FreeDos is supporting? any idea Thanks Toni Switzerland --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click ___ Freedos-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386.exe
Looks like you might have something loaded high in a UMB that is conflicting with your machine environment. Take out the I=C800-C8FF to see if the problem goes away. In fact, you could try full exclusion via X=A000-EFFF (temporarily) to see if there are any UMB conflicts, then bring the UMB's back one at a time if excluding everything clears up the problem. At 08:17 PM 5/17/2004 +0200, you wrote: Hi I am testing the latest Beta of FreeDos9 on my PC: ASUS P4C800E Deluxe with 1024 MB ram with following Config.sys Menu Item 2: !SET dosdir=C:\FDOS !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 ;below is a demonstration of the FreeDOS multi-configuration menu system. !LASTDRIVE=Z !BUFFERS=20 !FILES=40 !DOS=HIGH,UMB !DOSDATA=UMB !set dircmd=/ogn !MENUCOLOR=7,0 MENUDEFAULT=1,5 MENU 1 - Load FreeDOS including HIMEM XMS-memory driver MENU 2 - Load FreeDOS with maximum RAM free, using EMM386 MENU 3 - Load FreeDOS without drivers MENU 4 - Load FreeDOS HIMEM64 MENU 5 - Load FreeDOS TEST 25?DEVICE=C:\fdos\bin\FDXXMS.SYS BIOS NUMHANDLES=64 ;5?DEVICE=C:\fdos\bin\HIMEM.EXE ;5?DEVICE=C:\fdos\bin\FDXMS.SYS ;5?DEVICE=C:\fdos\bin\FDXMS286.SYS 1?DEVICE=C:\FDOS\BIN\HIMEM.EXE 4?DEVICE=C:\FDOS\BIN\HIMEM64.EXE 2?DEVICE=C:\FDOS\BIN\EMM386.EXE NOEMS I=B000-B7FF I=DC00-EBFF I=C800-C8FF ;1?DEVICE=C:\FDOS\bin\atapicdd.sys /D:FDCD0001 1245?SHELLHIGH=c:\command.com /E:1024 /K C:\FDOS\fdauto.bat 3?SHELLHIGH=c:\command.com /D /K set path=C:\FDOS\bin I tried many combination of EMM386.exe I got still: ILLEGAL INSTRUCTION OCCURED CS=ECB0 IP=47CA SS=00CF SP=C1D9 DS= ES00CF EAX=00FCC2D2 EBX=0001 ECX=8C88 EDX=CA52 ESI=2620 EDICD07 EBP=0E5E Opcodes @CS:IP 0F 00 05 03 02 13 03 00 I found no way with EMM386.exe Aborting Is FreeDos supporting 1024MB Ram I didn't found Infos about what FreeDos is supporting? any idea Thanks Toni Switzerland --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click ___ Freedos-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-user --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click ___ Freedos-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386.exe
At 12:50 AM 5/18/2004 +0400, you wrote: Hi! 17-íÁÊ-2004 14:03 [EMAIL PROTECTED] (Michael Devore) wrote to [EMAIL PROTECTED]: as always, your message appears as 1 long line. Very wide. Manually quoting now.. MD wins and I'll change or not, accordingly. What I won't do is change away MD from using the world-standard multi-platform Eudora after ten+ years along MD with a few million other people. Do you mean, that Eudora can't hardly wrap long lines?! I don't beleive. :) I have no idea what Eudora is doing, the e-mails look okay to me going out with plain style. By the way, your original quote-back was not wrapped and indented, and Bernd's was, so what does that mean? This all would be a good deal easier if sundry people weren't taking this silly HTML-email-is-evil, my extra bandwidth bill is .238 more euros/dollars when HTML is used, my billable time to scan past a few extra lines costs an additional 3 zillion zloty's attitude. Then we could auto-send nice looking HTML e-mail to those who support it and plain-text fronts for those who don't. Eliminates the whole problem. Geez, if it worked with Topica, how come SourceForge can't match it there? Doesn't say good things for VA Software's own open-source project they're trying to sell the services for that they can't even support basic mail-list filtering and front-end processing. --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id%62alloc_ida84op=click ___ Freedos-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386.exe
Michael Devore schreef: I have no idea what Eudora is doing, the e-mails look okay to me going out with plain style. By the way, your original quote-back was not wrapped and indented, and Bernd's was, so what does that mean? When replying with your text quoted, I see it as 1 single long line. When receiving my mail with your long line in it, I see it as multiple lines, each one with a quote-sign before it. Maybe even a problem at my end (don't wrap quoted text when replying).. so only problem is in composing. no problem with HTML mail, except that people like to abuse it, especially with the weak security in Outlook Express. HTML mail sometimes is very useful (Record store mailings, computer store mailings, etc..) no big problem. Sourceforge seems more limited than Topica. I wonder how other mailinglists handle it. (probably their own mail-server with newer version of the mailinglist software). -virii -attachments (and size) -html-mail -mail-from-non-subscribed-people. -mail archiving and (online/offline)searching options -Sourceforge archiving troubles - list last indexed on April 4, 2004. 6 weeks ago!!! http://sourceforge.net/mailarchive/forum.php?thread_id=4173237forum_id=36903 -etc Bernd --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click ___ Freedos-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386.exe
Bart Oldeman schreef: p.s. to others, please don't ask me when I'm going to do this or that -- as I said I'm not even sure if there'll be a new FD kernel release or even basic CVS updates before July -- most of the components of my freedos test box are on their way to a container ship due to arrive mid-July... shipping components one-by-one? :) good luck with your new location and job. Looks like you're a real world-traveller (or job-hopper). Not that I'm a programmer, but I'd like to suggest patches to be problem-driven from now on, and not code-optimisations, until the (current) kernel maintainer has more time available. lots of encountered problems, but no easy solutions. a ready-to-apply problem + patch (solution) should smooth the maintainer's activities in the scarce time that he can make free for this project. time to sleep (0:55AM here..), goodnight, Bernd --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click ___ Freedos-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-user
