Subject: request for comments - LIM bridge Date: Fri, 07 Jan 2000 10:50:53 -0800 From: k3pbu@arrl.net To: fd-dev@topica.com Right now, it appears that the FDXMS memory-manager and the TDSK RAM-disk won't work together, because TDSK uses either an XXMS or an EMS interface, but FDXMS only supports XMS. (The acronyms are how FDXMS refers to the various memory types; they are somewhat non-standard.) What I propose is a "bridge" device driver, to be called FDLIM, that would be loaded after FDXMS but before TDSK. FDLIM would talk to FDXMS using the XMS functions (interrupts), and would talk to the rest of the world (including TDSK) using a subset of the Lotus- Intel-Microsoft 3.0 EMS Specification commands. That subset would consist of the functions contained in the Borland EMS.PAS demonstration program, plus any other functions that TDSK requires. I'd appreciate any comments from people who are familiar with expanded or extended memory programming, especially anyone who can see any problems with this approach. Marty ------------------------------------------------------------------- The following are replies to the above RFC ------------------------------------------------------------------- Subject: Re: request for comments - LIM bridge Date: Fri, 07 Jan 2000 11:32:54 -0800 From: "Louis P. Santillan" To: k3pbu@arrl.net CC: fd-dev@topica.com Thats pretty similar to what EMM386 & HIMEM do. I'm not sure if you mean that XXMS != XMS (I've seen XXMS written multiple times in this thread). I dont use TDSK for myself (I use XMSDSK, also available from simtel, no source but smaller when loaded) but it should work with the appropiate command line IIRC. I had been wanting to look at FDXMS to see if there were any problems and write another TC header file for it like I have for EMS. I'll be downloading the the B3 source disks to check it out. Louis ----------------------------------------------------------------------- FYI: The source is available at http://www.freedos.org/files/dos/himem/ ----------------------------------------------------------------------- Subject: Re: request for comments - LIM bridge Date: Fri, 07 Jan 2000 17:44:25 -0800 From: Joseph Morris To: fd-dev@topica.com --- k3pbu@arrl.net wrote: > Right now, it appears that the FDXMS memory-manager > What I propose is a "bridge" device driver, to be > called FDLIM, that > would be loaded after FDXMS but before TDSK. FDLIM > would talk > to FDXMS using the XMS functions (interrupts), and > would talk to > the rest of the world (including TDSK) using a > subset of the Lotus- > Intel-Microsoft 3.0 EMS Specification commands. That > subset > would consist of the functions contained in the > Borland EMS.PAS > demonstration program, plus any other functions that > TDSK > requires. This is what EMM286 does, if I understand your description. It is not GPL (as far as I know) but it is an EMS simulator that uses XMS services as a base. If the author can be contacted, perhaps they might allow the source to be GPLed. --------------------------------------------------------------- Subject: Re: request for comments - LIM bridge Date: Fri, 07 Jan 2000 18:19:09 -0800 From: k3pbu@arrl.net To: fd-dev@topica.com On 7 Jan 00, at 17:44, Joseph Morris wrote: > it is an EMS simulator that uses XMS services as a base. EMM386 does several things that I'd leave out of FDLIM: EMM386 has the equivalent of HIMEM built in, and, of course, it has the capability of managing the real thing -- actual Expanded Memory hardware. But, the more I play with FDXMS and get bad results, the less confident I become about using it as the basis for memory management. It might make more sense to build a stand-alone EMM386 clone from the ground up. I'm also toying with the idea of writing a small device driver in C, or perhaps mostly in C but with a small assembler "envelope" around it. I have a feeling that some of fdxms's problems arise because of how easy it is to make subtle mistakes in assembler. The program I'd write would be a "proof of concept" sort of thing, just to see what unforeseen problems crop up. I'll continue to think about it for a couple of days, and see how the idea ferments. Marty ----------------------------------------------------------------------- Date: Fri, 07 Jan 2000 23:49:51 -0800 From: "Louis P. Santillan" To: k3pbu@arrl.net CC: fd-dev@topica.com FWIW, I'm porting FDXMS to NASM. This will give me a better feel of the code. BTW, anybody know the NASM equivalent of MASM's "size myStruct"? I could just use an equ but the size syntax is a bit cleaner. Louis ------------------------------------------------------------------------ Subject: Re: request for comments - LIM bridge Date: Sat, 08 Jan 2000 05:48:18 -0800 From: Joseph Morris To: fd-dev@topica.com > EMM386 does several things that I'd leave out of > FDLIM: EMM386 > has the equivalent of HIMEM built in, and, of > course, it has the > capability of managing the real thing -- actual > Expanded Memory > hardware. No.. I meant EMM286, TWO-EIGHT-SIX.. it is a little-known freeware program that is designed to proved LIM functions on a 286 machine that cannot run emm386. > > But, the more I play with FDXMS and get bad results, > the less > confident I become about using it as the basis for > memory > management. It might make more sense to build a > stand-alone > EMM386 clone from the ground up. Possibly. FDXMS is 386-dependent and this should not be the case. On the other hand, it does work with Ultima 7, which uses the flat-realmode trick. > > I'm also toying with the idea of writing a small > device driver in C, or > perhaps mostly in C but with a small assembler > "envelope" around > it. I have a feeling that some of fdxms's problems > arise because of > how easy it is to make subtle mistakes in assembler. If you can enter protected mode in pure C as FDXMS does, I would be very interested to see it. It could probably be done with inline ASM, but I've never heard of anyone doing this before. ------------------------------------------------------------------ Subject: Re: request for comments - LIM bridge Date: Sat, 08 Jan 2000 18:31:33 -0800 From: "Louis P. Santillan" To: Joseph Morris CC: fd-dev@topica.com I completed (most of it at least ;) my port of FDXMS to NASM. And while perusing thru the code... I notice a few functions were left "unimplemented" and returned the proper error code for this situation per the XMS spec. Now, this may be what is causing problems for XMSDSK and TDSK. The offending functions are "Release UMB" & "Realloc UMB" which I could see as being quite useful to XMSDSK (I'm not well experienced w/TDSK) which has the ability to dynamically re-size the RAM-DISK while in DOS (probly also re-locating itself in the UMB too). I haven't tried to compile it yet but I have a few DUPS to convert to TIMES before that happens. Louis ------------------------------------------------------------------------ Subject: Re: request for comments - LIM bridge Date: Sun, 09 Jan 2000 06:55:19 -0800 From: k3pbu@arrl.net To: fd-dev@topica.com On Sat, 08 Jan 2000 "Louis P. Santillan" wrote: > ... I notice a few functions were left > "unimplemented" ... > Now, this may be what is causing problems for XMSDSK and > TDSK. Based on my experiments (especially #7 and #8), TDSK also has kernel-related problems, but I'm sure the unimplemented functions would be troublesome too. Marty ------------------------------------------------------------------------ Subject: Re: request for comments - LIM bridge Date: Sun, 09 Jan 2000 13:21:19 -0800 From: Charles Dye To: fd-dev@topica.com At 05:48 AM 1/8/00 -0800, jp_morris@yahoo.co.uk wrote: > >No.. I meant EMM286, TWO-EIGHT-SIX.. it is a >little-known freeware program that is designed to >proved LIM functions on a 286 machine that cannot run >emm386. I haven't seen EMM286 in many many years. There is, however, a similar program called UMB_DRVR.SYS which is available from major DOS archives like Simtel.net. I don't know whether it would be useful to you or not; I don't think source was included. But perhaps if the author is still reachable, he would be willing to release the source -- 80286-specific code can't be terribly lucrative these days! raster@highfiber.com ------------------------------------------------------------------- Joseph Morris posted the URL to download EMM286: http://www-user.tu-cottbus.de/~kannegv/sonst/index_e.htm (this is an arj file) ------------------------------------------------------------------- Subject: Re: request for comments - LIM bridge Date: Sun, 09 Jan 2000 13:38:19 -0800 From: k3pbu@arrl.net To: fd-dev@topica.com On 9 Jan 00, at 13:21, Charles Dye wrote: > I haven't seen EMM286 in many many years. There is, however, > a similar program called UMB_DRVR.SYS I now have EMM286 (Thank you, Joseph Morris!) and will soon make it available to anyone who wants it --it was in an .arj archive, and I'll make a .zip instead. It is freeware, but without source. I did the following experiments with it: Experiment #9: Running under DR-DOS 7.03, loaded the following in config.sys -- himem (ver. 2.78 from MS), emm286, and tdsk /A. This worked fine, and both xmstat and emstat reported that everything's working correctly. Experiment #10: Tried the same thing but under FreeDOS beta-4. Result -- emm286 and tdsk didn't load, giving the now-familiar "error in config.sys" message for each. I wonder, maybe the config.sys problems have nothing to do with what drivers are specified in config.sys. Maybe there's a kernel bug such that only one driver will load from config.sys, and ANYTHING following that first driver will fail. Testing that theory will be my next task. Marty ---------------------------------------------------------------------- Subject: Re: request for comments - LIM bridge Date: Sun, 09 Jan 2000 15:06:54 -0800 From: k3pbu@arrl.net To: fd-dev@topica.com On 9 Jan 00, at 13:38, I wrote: > I wonder, maybe the config.sys problems have nothing to do with > what drivers are specified in config.sys. Maybe there's a kernel bug such > that only one driver will load from config.sys, and ANYTHING following > that first driver will fail. Experiment #11: Running under FreeDOS beta-4, loaded NANSI and then HIMEM in config.sys. Both loaded OK, no obvious problems. Experiment #12: Running under FreeDOS beta-4, loaded HIMEM and then NANSI in config.sys. NANSI gave none of its "welcome" messages. After the message "Process 0 starting: command.com", the machine hung so bad that I had to do a hardware reset. Conclusion: either (unlikely) NANSI is doing something with extended memory that HIMEM doesn't like; or (more likely) there's a kernel bug in the code that loads device drivers. Marty ------------------------------------------------------------------ Subject: one more experiment Date: Sat, 08 Jan 2000 15:53:39 -0800 From: Marty Peritsky To: FreeDOS I told a fib when I said no more experiments today. Here's one more: Running DR-DOS 7.03, loaded HIMEM and TDSK from config.sys. Then started FreeDOS command.com as a secondary command processor. It is able to access the ram disk with no problems. Conclusion: the ramdisk problems in FreeDOS are due to the kernel, not to command.com. Marty ------------------------------------------------------------------ Subject: Re: request for comments - LIM bridge Date: Sun, 09 Jan 2000 15:46:39 -0800 From: Joseph Morris To: fd-dev@topica.com > I wonder, maybe the config.sys problems have nothing > to do with what drivers are specified in config.sys. > Maybe there's a kernel bug such that only one driver > will load from config.sys, and ANYTHING following > that first driver will fail. Testing that theory will > be my next task. That would explain why I can't use CDROM. I need two drivers in config.sys, and the second one always crashes.