Re: [Freedos-devel] EMM386 options, was: Idea about Virtual PC compatibility / A20 handling
Michael Devore escreveu: So now I have something to wish for. It looks that the most compatible _and_ safe behaviour is to map RAM to X=TEST, which was exactly your first suggestion :) Safest, but very incompatible with MS expected RAM behavior. Not the reverse either, just something quite different. I don't expect users would want RAM == X=TEST. Ok. If you say so, I agree. And even more because of what is below ;-) nothing - No UMB available, smaller lower memory, only for problematic cases Nothing is the same as RAM with FreeDOS EMM386. UMB's are available and auto-scanned for ROM signatures in range C000-EFFF. EMS is present, I forget the formula for how much but could look it up. Probably defaults to 32M, or successively halving that until sufficient memory exists. I like this. Does MSDOS have UMB in this case? I allways understood that it didn't... In any case, NOEMS - I don't use EMS and UMB is enabled. Basic use, could be UMBPCI but this is hardware dependent. VCPI is only needed because it of EMM386 itself. NOEMS leaves support for a few EMS calls on with MS-DOS, which is stupid, but could be for easier VCPI support. FreeDOS EMM386 also supports these EMS calls under NOEMS because several programs have come to depend on this MS-DOS stupidity. Then there's the EMM device driver renaming, but don't get me started... VCPI pool allocation is made with NOEMS up to 12M automatically, based on 1/4th of available memory. I think. Documented in EMM386C.C and EMM386.ASM source. Just to put the point over the "i"s (just a badly translated saying): In this case UMB is available? I understand that the answer is yes, but it is not clearly stated in the above paragraph. Even it the implementation is stupid, IMHO the inportant fact of this option is liberating 64k on UMB :) RAM - EMS and UMB available Default option with FreeDOS, no difference if it's there or not. OK. NOEMS RAM - Maybe here the RAM option should not be used (not needed), correct? Same as NOEMS, above. Ok, --- One more question: How do I turn off UMB? This is what I understood so far (please correct me if in error) With both UMB and EMS: nothing (this needed RAM in MSDOS) With UMB but not EMS: NOEMS No UMB but with EMS:??? (this was nothing in MSDOS) Neither UMB nor EMS:don't load EMM386 There is still a "???" :( May I suggest a table similar to this in the docs or even help? thanks for everything so far, Alain --- 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=5047&alloc_id=10808&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Volunteers wanted: BOCHS for DOS (Dos-Box)
Hi, Tom Brett (tombrett X mailblocks.com, replace the X by @...) writes: Dos Box(not to be confused with DosBox) is an ongoing project to port bochs to MS-DOS (or rather FreeDOS) via the use of wxWindows (wxUniversal), perhaps using the Scitech MGL library.we are looking for volunteers to help get started with this project. any coders or assistance appreciated. no code base yet, just an idea. Let me know if you are interested in helping out with this idea. We are still in project planning stages so any feedback would be welcome. Open Source. (most likely GPL license). Please send your replies directly to Tom, he is not on freedos-devel yet. Thanks! Eric --- 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=5047&alloc_id=10808&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FORMAT problem
Johnson Lam wrote: I work for PC hardware since IBM PC was born. I learn too much program incompatible to some kind of hardware (especially Japan PC-9801 series). So being a programmer is tough. Ah yeah... I've heard of them. There's actually, I think, a customized version of FreeDOS for the PC98 series, called FreeDOS(98). I've used it a little in emulation. -uso. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FORMAT problem
On Fri, 27 Aug 2004 11:56:08 +0300, you wrote: Hi Lucho, >So BIOS uses some CHS translation mechanism here. What BIOS >brand/version/date you have? Acer Altos 300B (fade out model, 233MHz) I picked up our customer throw away PC for FreeDOS testing, it's USB totally sucks, almost all drivers failed. I work for PC hardware since IBM PC was born. I learn too much program incompatible to some kind of hardware (especially Japan PC-9801 series). So being a programmer is tough. >> LBA support Yes 3098.8MB of LBA addressable 3098.8MB in CHS mode >What a pity that your BIOS can't use LBA mode! Or can it? Nothing to choose, just AUTO or USER >This means UDMA. You could try the UDMA driver there but it will probably >insist on LBA and fail. Failed, what a pity. >FreeCOM doesn't affect FORMAT. If by "2035a" you mean the unstable kernel, >then this means that both the stable and the unstable kernels cause FORMAT >to complain. So, there is NO additional bug in the unstable kernel but a >common bug in both kernel branches. Or am I wrong? But I can't explain why I zero-fill the hard disk with SeaTools and one of my hard disk can format successfully (another Seagate still fail). Maybe FORMAT try to inspect the sector but look the wrong position? Or FDISK did some tricks that FORMAT think "It's BAD". I'm really not sure the Kernel or FreeCOM have bugs or not, sorry but it's beyond my ability, as I test them with some tough program such as Chinese system, it can produce the same failure everytime, as expected. So I think both of them reached a certain level of stability, say 84% of M$-DOS. Testing shows only M$-DOS can format, and the debug information is not enoguh (may need low-level tracing by debugger, step by step). Rgds, Johnson. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FORMAT problem
# of Cylinders__:6296 6296 787 # of Heads__: 1616 128 # of Sectors/Track__: 636363 So BIOS uses some CHS translation mechanism here. What BIOS brand/version/date you have? LBA support Yes 3098.8MB of LBA addressable 3098.8MB in CHS mode What a pity that your BIOS can't use LBA mode! Or can it? Congratulations, your drive supports ATA-2 This means UDMA. You could try the UDMA driver there but it will probably insist on LBA and fail. I've try 4 combination of kernel 2035/2035a, FreeCOM 0.82pl3 and 0.82pl3ak. Format still complain "5 consecutive bad sector" as before. But I can boot Win98 and using FORMAT 0.91s to format the hard disk. FreeCOM doesn't affect FORMAT. If by "2035a" you mean the unstable kernel, then this means that both the stable and the unstable kernels cause FORMAT to complain. So, there is NO additional bug in the unstable kernel but a common bug in both kernel branches. Or am I wrong? Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
