Hi Shane(30 at hotmail), Blair(dude at gmail), Interesting that updating to JEMM386 and finding the right options (if that is what you mean by customizing memory management) fixed first 4DOS and then FreeCOM 0.84 stability... But then, why is only FreeCOM 0.84 affected and not 0.82pl3, did you modify any safety functionality from 0.82 to 0.84 which could explain this, Blair?
> I tried 4DOS, and found that most of the trouble I'd been having was due to > memory management > not having been customized for the machine. Once I got the memory management > customized, > I could change back to FreeCOM and it was stable... > but once it's right it's not only stable but there's LOTS > of memory available! More than default? That might be risky... Or more than in the no- HIMEM case? True, one should always load at least HIMEM :-). > It worked right out of the box on > an Intel D845WN, P4/1.70 GHz, 1GB RAM, 40 GB HDD. > I'm running it on Virtual PC 2007 under Windows XP on a laptop with a Pentium > M. > It crashed at first, but it's now solid as a rock with this line in > FDCONFIG.SYS: > DEVICE=C:\FDOS\BIN\JEMM386\JEMM386.EXE NOEMS X=CC00-CFFF NOINVLPG > The NOEMS is optional. NOINVLPG was written by Japheth specifically for this > emulator. > The X=CC00-CFFF was arrived at through testing by trial and error. Is it needed for Virtual PC, the laptop or both? Can you use other system information tools to find out WHAT is the reason why you have to exclude CC00-CFFF? I also wonder why it was not possible for JEMM386 to detect that area automatically... In particular PCI MMIO memory / IO / buffers might be in the way in the UMB area, tools like Linux lspci -v might help to check. I think Japheth also has some "int 15 memory map info" tool on his homepage. If not, ask him by mail for the tool. > I haven't had a lot of time to test the Compaq Armada with the Pentium 2, > but I'm going to assume it's stable until it does something to prove > otherwise. > It works with no upper memory. I'm experimenting with making a small section > of > upper memory available, but haven't had time to follow through on this. Interesting, keep us updated :-) > Then there's the Pentium 3 I mentioned in my last message. > It still doesn't work right. > I have removed all LOADHIGH/DEVICEHIGH/SHELLHIGH > and set JEMM386 to X=A000-FFFF Try to remove the UMB from the DOS=HIGH,UMB line, the DOSDATA=UMB line and (!) loading of JEMM386... > I can reliably generate a crash by running HELP It is possible that HELP itself has a bug. > Jemm386: exception 0D occured at CS:EIP=218F:00002C42, ERRC=00000000 > SS:ESP=3AE3:00000D6A EBP=00000D6E EFL=00033207 CR0=80000011 CR2=00000000 > EAX=00000004 EBX=00000002 ECX=00000004 EDX=00003392 ESI=0000FFFF > EDI=00000008 > DS=215F ES=617D FS=217F GS=115E [CS:IP]=F3 A5 73 01 A4 8E DA 8B > The segment of code at [CS:IP] is indeed from HELP.EXE (after decompressing > it) > and AFAIK it only occurs in one place. > It's a REP MOVSW instruction for moving words. > If you look at the source SI and the destination DI, > the source is set to FFFF > which means it's about to overflow the segment. Good analysis. I think somebody (Blair?) recompiled HELP at one point because somebody else had compiled it with a badly configured ZLIB which needed LOADFIX and/or showed errors similar to the one you found... Maybe Blair can comment on this, CCing him. > When FreeCOM is loaded and I crash HELP.EXE, it causes > the behavior you mentioned where internal commands work > and external ones like EDIT just return a command prompt. Interesting - I assume the crash overwrites some memory, but it is odd that it only breaks CERTAIN actions of the FreeCOM shell by doing so... I wonder if it is the same bug. Your finding "it is memory config stability related" would indeed point in that direction. > Another thing that happens is that if I try internal commands that refer to > files > it tells me it can't access the files, even though DIR shows the files to > exist. > COPY CON FILE.TXT does this. Interesting, too! Do you ever encounter one symptom while the other symptom is not there at the same time? Maybe they always happened at the same time but the failure to run external commands distracted people from the fact that not even internal commands can access files any more either. > Please let me know if there's any kind of tool I can run on my computer > that would help to determine what is causing this trouble. See above - system info tools of Linux and Windows are a good way to snoop around and find out why your PC might need a certain X=... area for JEMM386 for example. Still you can also get a good idea by using DEBUG and looking at the contents of the area that you found to be bad UMB. > The F3 key is supposed to get the last line, if available. > In most kinds of DOS, when you press the F3 key at the very > first commant prompt, nothing happens because there > is no "last line" available. > In 4DOS it beeps because there is no last line available. > In FreeCOM it prints garbage characters Now I get your point. Blair is the expert on FreeCOM :-). > Again, please let me know if there's any further testing I can do Updated lbacache and runtime, I guess... Pity that my homepage is still not properly working but I could mail zips or (if needed to bypass exe-filters) 7zips to you. Thanks :-) Eric ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Freedos-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-user
