Arkady V.Belousov schreef:

significant rewrite to regress the instruction set on all XMS 2.0 and
admin code down from 32-bit registers to 16-bit. Nowadays I would
For the microscopic percentage of 80286-level clients, just use
FDXMS286. Simple readily available solution. Fix it if it's broken,
no big deal. Why mug HIMEM when it's so unnecessary?


Isn't XMS 3.0 used if available anyway? Or only if detected by a certain program (which might lack a detection method for XMS 3.0 but not for 2.0).
A 'fast' 32bit register using XMS 3.0 implementation and slower 16bit register using XMS 2.0 implementation is feasable?
(a diff between fdxms and fdxms286 should show what changed, to begin with)


FDXMS286 is about 2.8KBin compressed form, and last updated in 2002.
So if an add-on to HIMEM would fit in this size, it doesn't matter if I put 'current HIMEM + current FDXMS286' on a bootdisk,
or 'unified 286+ XMS driver by Tom Ehlert and Michael Devore'.
Reasons for XMS, with regard to FreeDOS, are lack of UMBs (386-specific, but that's something I'm sure you know better than me),
and thus a more heavy burden on conventional memory. a XMS driver can provide access to HMA (for kernel) and XMS (for FreeCOM) to save about
50 + 125 = 175KB of conventional memory.


If only FDXMS286 ( http://www.ludd.ltu.se/~ams/freedos/fdxms286/ ) should be fixed, then:
*who's willing to do that?
*who's ABLE to test it (I can only do 386+)?
*which fixes have to be backported from HIMEM to FDXMS286. At least the following, I think.
- A20 methods Michael introduced
- remove that annoying PC speaker beep if there's already a XMS driver loaded
(yes I tried a config.sys before with loading first himem, then fdxms)


    "Me too". Me not hard to replace "himem" word in config.sys by
"fdxms286" on older machines. What we worries, is an universal boot
diskettes, which may be used on many machines, and there is unpractical to
pre-edit them before booting on next machine.

As temporary/partial solution, may be used warning in himem about
"non-386" CPU and immediate exiting.


Universal bootdisk would be very welcome. Eric Auer made some 'feature'-detection tools for processor generation, Syslinux/Memdisk, etc.
On the other hand, I don't require XMS on the bootdisk I have. I just know that booting from a real floppy will be VERY slow then without any caches
(which are 386+ anyway) and very low amount of conventional memory.


other modules, and thus all what you lost, is an space on disk for (bigger)
himem executable image.


CPU-specific branches in code?

I NOT say that FD-HIMEM SHOULD/MUST be at next day immediately include
compatability with more CPUs and/or how it should/may be performed. I just
express my personal opinion.


Indeed. Also if none of the HIMEM/EMM386 experts think it's worthwile, then all discussion here is probably meaningless,
except for 'hey external developer, deliver a complete tested patch and I might implement it'.
Hope you noticed how many people are currently working on KERNEL (only Jeremy, sometimes fewer people, sometimes more) and FREECOM
(haven't heared from Steffen in a long time)


ASM> (2) I don't think MS-DOS 5.0 is an improvement over 3.3, even if you

It is: HMA and UMB, config menus, new/documented APIs (and bugs) and
utilities.


You're talking about 6.00 (menu's and utilities). I crashed my dads system in '93 because it had no F5/F8 in kernel menu.
Luckily I just learned how to make a bootdisk. From that moment on, I became a lot more carefull with UMB inclusion..


Bernd


------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel

Reply via email to