Re: [Freedos-devel] Re: FreeDOS Version 1.0 reviewed
At 05:53 PM 4/25/2004 +0400, Arkady V.Belousov wrote: Hi! 24-áÐÒ-2004 21:51 [EMAIL PROTECTED] (Michael Devore) wrote to [EMAIL PROTECTED]: I thought ram by itself meant dynamic EMS allocation as opposed to allocating a fixed amount (at least, this is what the docs day), that's how I use ram in M$ EMM386. MD It's not documented that way on any EMM386 docs I see, including MD Microsoft's. It wouldn't matter, because we don't support that type of MD behavior anyway. __O\_/_\_/O__ Sharing XMS and EMS memory EMM386 provides EMS/VCPI memory for programs that require it by converting XMS memory to EMS/VCPI memory. When it is loaded, EMM386 reserves the amount of memory specified by the MIN switch for use as EMS/VCPI memory (the default value is 256K). Once this amount of XMS memory is reserved, it is always available as EMS/VCPI memory and no longer available as XMS memory. EMM386 may be able to convert additional amounts of XMS memory to EMS/VCPI memory, up to the amount specified by the MEMORY parameter. EMM386 returns the additional amount back to XMS memory when it is no longer needed as EMS/VCPI memory. That paragraph is only true starting with EMM386 version 4.45, which is introduced with MS-DOS 6.0. There is Microsoft documentation on that EMM386 change, but I'll not re-post the full paragraph. We are MS-DOS 5.0+ compatible, at least as far as general EMS and XMS abilities. Pool sharing previously has been discussed here as a post-1.0 change. The quoted topic is unrelated to the EMM386 RAM option. It has to do with how EMS and XMS memory is allocated from a common extended memory pool. It relates to the (unsupported) MIN and (FreeDOS) EMM= option. To save you time from re-typing doc and spec quotes, you can assume I have access to the EMS 4.0 spec, the DPMI 0.9/1.0 spec, the XMS 3.0 spec, the VCPI 1.0 spec, and the Microsoft HIMEM and EMM386 publicly-disclosed option documentation. --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Intel PRO/1000 driver fails under FreeDOS
In the last major release of my project (http://unattended.sourceforge.net/), I changed my network boot disk to use FreeDOS instead of MS-DOS. Now, my users are reporting that the boot disk no longer works on machines which have Intel gigabit (PRO/1000) networking hardware. I have one machine with such hardware, and I can confirm that Intel's DOS network driver (e1000.dos) appears to be incompatible with FreeDOS. You can download the latest version of this driver from Intel's site: http://downloadfinder.intel.com/scripts-df/File_Filter.asp?FileName=PRODOS2.EXE Or you can download my boot disk itself as a 1.44M floppy image: http://unattended.sourceforge.net/testing/ e1000.img Although the problem is only reproducible if you have PRO/1000 network hardware... Here is what I have observed. If I use a config.sys which is empty except for DEVICE=\net\ifshlp.sys, the driver loads fine. But when the boot disk tries to use the driver to obtain a DHCP lease, it gets an illegal opcode followed by a reboot. The reboot happens too quickly for me to record the hex values. If I add these lines to config.sys: DOS=HIGH,UMB DEVICE=himem64.exe The same thing happens. If I further add: DEVICE=emm386.exe NOEMS (where HIMEM64 and EMM386 were downloaded from ftp://ftp.devoresoft.com/downloads/ yesterday) ...it still happens, only I see this: Illegal Instruction occurred CS=3046 IP=08CC SS=00CF SP=08B8 DS= ES=DC11 EAX= EBX=0F8C ECX=0003 EDX=0AE4 ESI= EDI=000F EBP= Opcodes @CS:IP 63 20 00 00 00 00 00 00 Aborting program ...and it hangs, letting me record the values. Finally, if I change the emm386.exe invocation in config.sys like this: DEVICE=emm386.exe ...then the e1000.dos driver refuses to load at all! It probes the hardware correctly (printing the MAC address etc.), but then it says: Error: Unsuppored Memory Manager Present Unable to initialize protected mode services Action: -Remove all memory managers from this configuration Failure: Driver did not load, NDIS environment invalid (By the way, the same thing happens if I only load himem64.exe and load cwsdpmi before loading the driver. Obviously, the e1000.dos driver does not play nicely with DPMI providers.) This behavior is with the FreeDOS kernel from ke2033_32. I tried one or two of the above permutations under ke2034_32 with the same results. Obviously, the e1000.dos driver is doing something very strange. However, the exact same boot disk used to work fine under MS-DOS (with or without himem.sys), so from my point of view this is a FreeDOS bug. Any ideas? If I were to offer to send someone a PRO/1000 card to experiment with, would any of you be interested? Or do you have any other suggestions? Thanks! - Pat --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: FreeDOS Beta9 RC5 has been released
On Sun, 25 Apr 2004, Aitor Santamaría Merino wrote: Bernd Blaauw escribió: right now on updated ODIN bootdisk the CPI files take almost 600KB (10 * 60KB), which is nearly half the disk! (and makes creating 720KB more difficult). Perhaps it's a question to check the CPI files, perhaps for MOST of the countries, just 2 or 3 of those CPI files are not enough, and not 10 of them. It's just a question of where to put the limit. What was the compression proposal about? Help files or CPI files? For the CPI files it would really help since they compress 90%, and if you concatenate them together and then zip them it only takes up 34K instead of 600K. So a single compressed EGA.CPI would be really nice. Bart --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: FreeDOS Version 1.0 reviewed
At 11:36 PM 4/25/2004 +0400, Arkady V.Belousov wrote: Hi! 25-áÐÒ-2004 11:02 [EMAIL PROTECTED] (Michael Devore) wrote to [EMAIL PROTECTED]: I thought ram by itself meant dynamic EMS allocation as opposed to MD It's not documented that way on any EMM386 docs I see, including EMM386 may be able to convert additional amounts of XMS memory to EMS/VCPI memory, up to the amount specified by the MEMORY parameter. EMM386 returns MD That paragraph is only true starting with EMM386 version 4.45, which is MD introduced with MS-DOS 6.0. There is Microsoft documentation on that EMM386 MD change, but I'll not re-post the full paragraph. This is contradiction: above you say that it's not documented. :) No, I did not. I said the Microsoft EMM386 RAM option did not work that way, as far as causing the sharing of EMS and XMS memory. I did not say Microsoft EMM386 version 4.45 itself did not share. MS EMM386 versions prior to 4.45, however, also do not share the pool. Bottom line: the RAM option does not work the way you apparently believe it does, based on Microsoft's own documentation. --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: FreeDOS Beta9 RC5 has been released
help-files are already collected in a zipfile, Rob worked on that. I suggested compressing the CPI-files to Eric using Gzip, but that would add Zlib to MODE. Eric likes another less efficient but smaller to implement compression algorythm/program. he said it reduces CPI from 58 (60) to 19KB (Gzip: 5KB or 6KB) only providing a few CPI-files will not do. That's the same as only providing most used keyboard layouts: useless for some people. compressing CPI-files allows more programs to be added. Bernd --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: EMM386 ROM/RAM (was: FreeDOS Version 1.0 reviewed)
Hi! 25--2004 15:36 [EMAIL PROTECTED] (Eric Auer) wrote to [EMAIL PROTECTED]: EA X-Spam-Report: Spam detection software, running on the system externalmx-1.sourceforge.net, has EA identified this incoming email as possible spam. The original message EA has been attached to this so you can view it (if it isn't spam) or block EA similar future email. If you have any questions, see EA the administrator of that system for details. EA Content preview: Hi, I thought about ROM/RAM again. Conclusion: X= leave EA area mapped 1:1 and untouched (e.g. for ROM areas and video buffers) I= EA map RAM to this place to create UMB or EMS page frame RAM= assume that EA there already IS RAM at this place, so leave it mapped 1:1 and put UMB EA or EMS page frame there ROM= map RAM to this place which contains a EA copy of the ROM which was at this place, and mark it read-only (copy EA ROM to shadow RAM for speed gain). Notice that most 386/newer computers EA already contain shadow RAM functionality anyway (e.g. NeAT 286/386 EA chipset) so the ROM= function is more or less obsolete. [...] EA Content analysis details: (0.0 points, 5.0 required) EA pts rule name description EA -- -- EA X-Spam-Score: 0.0 (/) EA X-Spam-Report: Spam Filtering performed by sourceforge.net. EA Hi, I thought about ROM/RAM again. Conclusion: EA RAM= assume that there already IS RAM at this place, so leave it mapped 1:1 EA and put UMB or EMS page frame there Wrong. :) I don't know if this is possible with EMM386 (I don't see the consequent option), but looks like you can't reuse available memory (if it there) without remapping other over it. RAM= itself, as explained by MS, only says which region may be used for UMB (if there are no ROMs). --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: FreeDOS Beta9 RC5 has been released
Ooops... Aitor Santamaría Merino escribió: Bernd Blaauw escribió: right now on updated ODIN bootdisk the CPI files take almost 600KB (10 * 60KB), which is nearly half the disk! (and makes creating 720KB more difficult). Perhaps it's a question to check the CPI files, perhaps for MOST of the countries, just 2 or 3 of those CPI files are not enough, and not 10 of them. Ouch, I meant just 2 or 3 of those CPI files ARE enough (no not). Sorry... Aitor (Thanks Eric :)) --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: EMM386 ROM/RAM (was: FreeDOS Version 1.0 reviewed)
Hi, Eric Auer escribió: RAM= assume that there already IS RAM at this place, so leave it mapped 1:1 and put UMB or EMS page frame there Do not mess with terms: RAM= scanable area: scan it, and if found empty, map, and have into account any X=, I= X=unconditionally excluded for UMBs/pageframe I= unconditionally included for UMBs/pageframe Aitor --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Intel PRO/1000 driver fails under FreeDOS
Michael Devore [EMAIL PROTECTED] writes: Since you're failing without HIMEM or EMM386 loaded, you have to be hitting a kernel compatibility, agreed? It can't be a UMB conflict or a p-mode conflict or something failing in EMS/XMS/VCPI/DPMI calls. That actually narrows the field of suspects quite a lot. Yes. Just to be sure, you've tried the bare driver CONFIG.SYS on an MS-DOS system and it worked correctly? The info is a required data point in case the driver normally requires or expects HIMEM, etc. I just double-checked, even booting from physical floppies instead of network boot + memdisk. (Wow, floppies are slow...) My config.sys has: LASTDRIVE=Z DEVICEHIGH=\net\ifshlp.sys FILES=30 (Since I am not loading any memory manager, I presume DEVICEHIGH=... is equivalent to DEVICE=... ?) With MS-DOS, the e1000.dos driver works fine. With FreeDOS (ke2034_32), it crashes as I described: The driver loads, but when tinyrfc.exe tries to obtain a DHCP lease, it gets an invalid opcode. Actually, I think it may successfully obtain the lease; it pauses for a while before crashing. And the floppy itself spins up again. This time, the system did not reboot; instead, it printed the following three messages with about 2-3 seconds between each: Invalid opcode at FFA7 1100 0212 00CF 0070 0800 04B0 0005 0005 01EC 04B0 143F Invalid opcode at 0212 A73B 0886 0202 0E9E 1038 347F 0012 0001 0033 0001 Invalid opcode at 0032 0800 0093 00F3 3D72 B4C3 2851 11B0 1A92 2851 3CFA 4688 2851 At this point I pressed ctrl+pause, and after that the machine was non-responsive (even to ctrl+alt+del). I don't do kernel work, but depending on how much you want to dig in the guts of the problem, you might want to grab the 386SWAT debugger and load it immediately after the driver, with nothing else. It should catch the exception and throw you into the 386SWAT debugger. I know you know assembly language pretty well, plus I can walk you through some basic tests there (obviously a suboptimal situation, but better than nothing). I can (usuall) read other people's code and make trivial changes. It would be a lot nicer if someone intimate with FreeDOS internals could look at this... But I will do what I have to, time permitting. I could test a card here, but since the FreeDOS machine isn't normally hooked into any network, I'm not sure it would do much good. Yeah, the problems don't start until after you actuall use the driver. (Weird about about failing with EMM386 without NOEMS, though. But we can maybe fix that later.) Maybe, but some Google searching suggests that the same thing happens with MS EMM386. The e1000.dos driver really does not like seeing a DPMI provider. Who knows why. - Pat --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] EQUIPMENT WANT
Title: Bestec_FT4U-Finishing Equipment We trade stock ultrasonic cleaning, metal finishing plant and equipment. Ask details Want to SELL Want to BUY Corporate Hotline: +852-82 214 726 Email: ! If you don't wish to receive our ad., please "unsubscribe" here. We apologize for any inconvenience. --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] updates
First a few updates... My considering converting to FreeDOS was because of some recent problems with my system, some of which were problems in Windoze. Eventually (over the course of this weekend) I had to reformat my hard drive. Now that that's over with, I have a few more questions: What system drivers are installed with FreeDOS (other than monitor, keyboard, maybe the A:\ drive)? What utilities are recommended for download management, internet browser, virus/trojan/worm detection removal? Is there an equivalent of Dialup Networking in the FreeDOS system? If not, what options are available for connecting? This last is because I use bellsouth as my isp, I go thru that utility. Thank you for your time. _ Get rid of annoying pop-up ads with the new MSN Toolbar FREE! http://toolbar.msn.com/go/onm00200414ave/direct/01/ --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] updates
On Sun, 2004-04-25 at 22:33, Steve Nickolas - Using Windoze wrote: david lowe wrote: SNIP What utilities are recommended for download management, internet browser, virus/trojan/worm detection removal? I have yet to find them, although I have heard Arachne works well as a browser. There are antivirus programs, but I don't know of any current DOS ones although I think someone was porting CLAMAV? F-PROT is free for individual use under DOS ... I don't think it has a real-time scanning component for dos, but it's been a long time since I've had to worry about viruses under DOS. Regards, Paul --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: Intel PRO/1000 driver fails under FreeDOS
At 07:08 PM 4/25/2004 -0400, Patrick J. LoPresti wrote: Michael Devore [EMAIL PROTECTED] writes: I don't do kernel work, but depending on how much you want to dig in the guts of the problem, you might want to grab the 386SWAT debugger and load it immediately after the driver, with nothing else. It should catch the exception and throw you into the 386SWAT debugger. After paring down my boot disk, I got 386SWAT to fit (with 2K to spare). And by invoking it with DEVICE=A:\386swat.lod TRAPINV, I actually get thrown into the debugger where I used to get invalid opcode + reboot. So it's a start. But I really have no idea what I am looking at... Another thing, besides the register and CPU stuff. Type D 40:7B enter at the command line down at the bottom. What is the byte value of the first entry on the memory display? Want to make sure that BIOS is not flagging the machine as supporting VDS, since that would be A Bad Thing. --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] MODE (DTR working properly)
Hi Eric, I monitored with a RS232 break-out box, DTR raise when BAUDHARD=1. But when it's low, it shows DTR=AUTO. That seems a bit confusing. Rgds, Johnson. --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Re: Intel PRO/1000 driver fails under FreeDOS
Michael Devore [EMAIL PROTECTED] writes: I don't do kernel work, but depending on how much you want to dig in the guts of the problem, you might want to grab the 386SWAT debugger and load it immediately after the driver, with nothing else. It should catch the exception and throw you into the 386SWAT debugger. After paring down my boot disk, I got 386SWAT to fit (with 2K to spare). And by invoking it with DEVICE=A:\386swat.lod TRAPINV, I actually get thrown into the debugger where I used to get invalid opcode + reboot. So it's a start. But I really have no idea what I am looking at... - Pat --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: Intel PRO/1000 driver fails under FreeDOS
At 07:08 PM 4/25/2004 -0400, Patrick J. LoPresti wrote: Michael Devore [EMAIL PROTECTED] writes: I don't do kernel work, but depending on how much you want to dig in the guts of the problem, you might want to grab the 386SWAT debugger and load it immediately after the driver, with nothing else. It should catch the exception and throw you into the 386SWAT debugger. After paring down my boot disk, I got 386SWAT to fit (with 2K to spare). And by invoking it with DEVICE=A:\386swat.lod TRAPINV, I actually get thrown into the debugger where I used to get invalid opcode + reboot. So it's a start. But I really have no idea what I am looking at... First thing to look at is the register values, which are across the top line. We need those values. Then look at the failing CPU instruction line which is highlighted in the main window. That together with the register values should give the immediate reason for failure. The EFL flags value right above the main window would be good info to know, too. --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Intel PRO/1000 driver fails under FreeDOS (MSCLIENT failure)
On 25 Apr 2004 18:10:17 -0400, you wrote: Hi Patrick, With FreeDOS (ke2034_32), it crashes as I described: The driver loads, but when tinyrfc.exe tries to obtain a DHCP lease, it gets an invalid opcode. You report faster than me. I got the same problem when trying MSCLIENT, it does work under FDXXMS+UMBPCI (try it), but fail with HIMEM+EMM386. I'm quite sure the memory manager and hardware not so compatible especially Network Interface Card. I just finished trying all combination including NOEMS, EMS, VDS ... still not working, and I'm better than you. The 3COM 3c905tx-b only fail to BIND and report hardware error. I can still access FreeDOS without hangup. Rgds, Johnson. --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
