Re: [Freedos-devel] Another EMM386 release, bugfixes and enhancements
At 06:05 PM 3/22/2004 +, Bart Oldeman wrote: On Mon, 22 Mar 2004, Michael Devore wrote: I've tried QuickView Pro and a DOS extended PNG viewer and they both are documented as using an LFB and work fine under EMM386, so we're dealing with something beyond a simple LFB existence problem here. that's right. Quake also works in LFB modes (except it didn't startup for me with NOEMS set, but that's a different issue and we already discussed that anyway). I've thrown about everything I could at this Duke3D high res display problem. Downloaded and installed 386SWAT debugger and modified EMM386 to work with it, but when 386SWAT is loaded, Duke3D magically starts working again with EMM386. Very strange. Yes indeed... I can try it in Bochs one day and see what happens, but it's not worth spending any more hours debugging for you then for the time being, agreed. Well what is worth here, of course thanks a lot! Wha-ha! I ran out of ideas and decided to start debugging the 386SWAT debugger to see what it was doing. Turns out on the protected mode entry back to the VCPI handler, I have to LAR the stack segment and zero out the high word if the big bit is clear (protected mode program using SP instead of ESP potentially leaving cruft in the high word). Didn't think of that as an issue because I'm used to thinking of protected mode programs like DOS/4GW as always running 32-bit. So, that was an expensive mistake. Anyway, Duke3D runs in high resolution 800x600 mode now under EMM386. I just need to add VMware detection for auto UMB exclusion, and then I'll put up the first release candidate version of EMM386. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Another EMM386 release, bugfixes and enhancements
At 03:17 AM 3/24/2004 -0600, Michael Devore wrote: Anyway, Duke3D runs in high resolution 800x600 mode now under EMM386. I just need to add VMware detection for auto UMB exclusion, and then I'll put up the first release candidate version of EMM386. Incidentally, a note in case the person named Jose from Brazil who e-mailed me that he can't post messages to the FreeDOS SourceForge mail list because they bounce, and who wanted me to respond to him via e-mail, is still reading the archives. He has forgotten to set his return e-mail address to contain anything other than his name (without an e-mail address). Which means my e-mails to him bounce, too. Which also likely explains why he gets rejects from SourceForge. Might want to fix that situation and try to join the mail list again. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Another EMM386 release, bugfixes and enhancements
On Thu, 18 Mar 2004 07:22:38 -0600, you wrote: Hi Michael, That's interesting. MPXPLAY lets me play a CD with a NUL output, which is mildly amusing to watch. I can run MPXPLAY fine with NOEMS, or EMS set, with DOS=HIGH,UMB, or DOS=HIGH (without UMB). Maybe the problem is with VCPI and your sound card? I'll try other hardware later. Does it fail for you under all the NOEMS and with EMS and with and without UMB's in the DOS= line settings or just particular ones? I'm assuming it works fine with just HIMEM[64] and no EMM386 present. When removing EMM38664 it works fine. I've tried running MPXPLAY with/without EMS, have DOS=HIGH,UMB or remove the line with DOS=, even tried changing CD-ROM driver, no matter how I did MPXPLAY reboot under EMM38664 environment. Since it work smoothly under UMBPCI, must some kind of compatibility problem exist. I post my CONFIG.SYS for reference: =BEGIN= MENU ++ MENU | 0 - FDXXMS + UMBPCI| MENU | 1 - HIMEM64 + UMBPCI | MENU | 2 - HIMEM64 + EMM38864 | MENU ++ MENUDEFAULT=0,8 !VERSION=6.22 !FILES=50 !BUFFERS=10,0 !LASTDRIVE=Z DOS=HIGH,UMB DOSDATA=HIGH 0?DEVICE=C:\FREEDOS\FDXXMS.SYS 12?DEVICE=C:\FREEDOS\HIMEM64.EXE 01?DEVICE=C:\FREEDOS\UMBPCI.SYS 2?DEVICE=C:\FREEDOS\EMM38664.EXE NOEMS DEVICEHIGH=C:\FREEDOS\UDMA.SYS DEVICEHIGH=C:\DOS\OAKCDROM.SYS /D:SHSU-CDN DEVICEHIGH=C:\FREEDOS\NANSI.SYS /S DEVICEHIGH=C:\FREEDOS\TDSK.EXE REM DEVICE=C:\FREEDOS\ATAPICDD.SYS /D:SHSU-CDN SHELL=c:\FREEDOS\COMMAND.COM /E:1024 /P =END= Rgds, Johnson. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Another EMM386 release, bugfixes and enhancements
I just tried out the new version, and I had the same problem as the previous version. If I go emm38664.exe /noems, I get the message func 43, out 8800 0006 . But if I use ems, then I get mapping UBM's (16k each) at: d800 dc00 umb block 0 at d800:000, size = 0x800 paragraphs (32kb) --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Another EMM386 release, bugfixes and enhancements
On Tue, 16 Mar 2004, Michael Devore wrote: Latest test version of EMM386 is at ftp://ftp.devoresoftware.com/downloads in the files EMM386.ZIP and EMMSRC.ZIP, as executable and source. These version corrects a problem with memory corruption in UMB's using VCPI, particularly notable with MCB panic errors. Non-DOS upper memory management is improved. This version should be compatible with a greater range of DOS-extended software. yes, indeed. The MCB problems have disappeared now. Also with NOEMS I now get UMBs. So that's quite an improvement. Duke Nukem 3D reboots the machine as soon as it enters graphics mode. Its setup program (which also uses dos4gw 1.97) works correctly though. DOOM on the other hand works. Will try to run with Causeway and DOS32A later. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Another EMM386 release, bugfixes and enhancements
At 08:30 PM 3/17/2004 +, Bart Oldeman wrote: Latest test version of EMM386 is at ftp://ftp.devoresoftware.com/downloads in the files EMM386.ZIP and EMMSRC.ZIP, as executable and source. These version corrects a problem with memory corruption in UMB's using VCPI, particularly notable with MCB panic errors. Non-DOS upper memory management is improved. This version should be compatible with a greater range of DOS-extended software. yes, indeed. The MCB problems have disappeared now. Also with NOEMS I now get UMBs. So that's quite an improvement. Duke Nukem 3D reboots the machine as soon as it enters graphics mode. Its setup program (which also uses dos4gw 1.97) works correctly though. DOOM on the other hand works. Will try to run with Causeway and DOS32A later. I downloaded Duke Nukem 3D, but turns out it's larger than a floppy, which is the only way I can transfer to the DOS machine. For unknown reasons, although FreeDOS installed everything okay to my machine from CD, the FreeDOS CD driver itself will only read small files of a few K from a burned CD, larger files corrupt the data during COPY and are useless. Unless that's been fixed in last FreeDOS beta release or SHSUCDX has been updated from 2.1 to fix the problem, I'm dead in the water on transferring large files via CD. I suppose I could break up the ZIP to floppy sized units, but I'm not real thrilled about trying it. I'd very much rather get the CD problem fixed. Used to think I'd look into whether there was a programming problem in the process after EMM386's VCPI settled down as my last FreeDOS development interest. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Another EMM386 release, bugfixes and enhancements
At 09:00 AM 3/17/2004 -0500, Adam Peart wrote: I just tried out the new version, and I had the same problem as the previous version. If I go emm38664.exe /noems, I get the message func 43, out 8800 0006 . But if I use ems, then I get mapping UBM's (16k each) at: d800 dc00 umb block 0 at d800:000, size = 0x800 paragraphs (32kb) In the immortal words of those recently watching the unattended robot vehicles in DARPA's Grand Challenge: that shouldn't happen. In fact, I don't know how it would happen, since EMM386 allocates an EMS reserve far higher than 32K with NOEMS, and should always reserve at least the UMB size. What is your physical memory on the machine you are using (e.g. 32M, 256M, 512M)? On the plus side, you should be able to use the SLOWDOWN program you were having problems with earlier, since the failing instruction is now supported/emulated. Or least it should crash further in, if it tries a different such instruction. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Another EMM386 release, bugfixes and enhancements
On Wed, 17 Mar 2004, Michael Devore wrote: I suppose I could break up the ZIP to floppy sized units, but I'm not real thrilled about trying it. I'd very much rather get the CD problem fixed. don't you have an old ISA network card you can put in the DOS machine? Then you could copy via a small network. I have an ssh server running on a Linux box and then transfer files locally using sshdos (sftp); encrypted might be overkill but it's easy and plenty fast with the cross-over ethernet cable. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Another EMM386 release, bugfixes and enhancements
At 10:35 PM 3/17/2004 +, you wrote: On Wed, 17 Mar 2004, Michael Devore wrote: I suppose I could break up the ZIP to floppy sized units, but I'm not real thrilled about trying it. I'd very much rather get the CD problem fixed. don't you have an old ISA network card you can put in the DOS machine? Then you could copy via a small network. Actually the old DOS machine used to be a Linux Internet connection server once upon a time and has two NICs which, judging by the green light, still has one working. Problem is, last I looked, DOS networking to a LAN was one of the blackest voodoo arts, with a great deal of manual setup and intervention. I didn't feel like killing the good part of a day setting things up to talk to my LAN, then trying to get past the W2K and WinXP permissions, just to share a drive with no guarantee of success. Particularly since a good CD read access from FreeDOS would avoid the whole mess. However, inspired by your Linux+ftp remarks, I just looked over latest Knoppix and seems to have a simple way to make DOS disk storage ftp'able with universal IP access. So I think I'll try that, since security isn't a requirement. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Another EMM386 release, bugfixes and enhancements
Latest test version of EMM386 is at ftp://ftp.devoresoftware.com/downloads in the files EMM386.ZIP and EMMSRC.ZIP, as executable and source. These version corrects a problem with memory corruption in UMB's using VCPI, particularly notable with MCB panic errors.Non-DOS upper memory management is improved. This version should be compatible with a greater range of DOS-extended software. Additional details follow: Fixed the VCPI memory allocator which was broken such that it could, depending on uninteresting factors, supply the last 4K page of the last UMB block to a program as a free page or as available to be freed, leading to the UMB block page being overwritten or vanishing. If you had DOS=UMB in your config.sys and used a VCPI-allocating program, this problem would provoke DOS outrage and fatal MCB errors. The UMB handler in EMM386 (external to DOS and generally only useful if DOS is not =UMB) has been upgraded from the relative intelligence of a click beetle to that of an inbred ground squirrel. More specifically: up to eight UMB areas are supported, rather than four; the handler will not fail if the first block is too small, plus it returns the proper largest available block information; the handler will split a UMB block if a request allocation is 2K or more smaller than the actual block size into a smaller available block; and UMB's can now be released as well as allocated. Resizing a block (function 12h) remains unsupported. The V86-illegal instructions mov eax,cr0 and mov ebx,cr0 are emulated in EMM386 for programs which do such curious things. VCPI function 0de07h to return cr0 value is supported. An additional 96K EMS is supplied to EMM386 to provide better support for tables with large extended memory values and leave a little more room for VCPI. The EPROM scanner alignment was fixed per Tom Ehlert's posted code, slightly restyled. NOEMS leaves the following EMS functions available: 40h, 42h-43h, 45h-46h, 4bh-4dh, to better follow Microsoft EMM386. Turbo Debugger 2.5 still fails under NOEMS. NIOS still must either use NOEMS or keep the EMS setting down to not much more than 2M. No probable fix for those situations, they appear inherent to the programs. Under NOEMS, only 1 page of EMS is shown as available with function 42h, to keep DOS/4GW from switching away from XMS to VCPI-only allocations and subsequently failing with out of memory conditions. Any new or pre-existing errors I missed, or modest enhancement requests, let me know. Thanks. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
